Personal Effort Announcement

General
1

NOTICE: funsign.org is NOT my project, this site is fraudulent

It’s no secret I’ve been slowly working on a project I call funsign. Due to the recent revelations on funscripted.com and funscript.org I’m going to start learning web development to have a web front end to the project to make it easier to use. Funsign is going to be my own personal project. It will be opensource and anyone will be able to use it. Eroscripts will host an instance to stand as a trusted authority.

What is funsign?

Funsign is a trusted authority that establishes cryptographic authenticity to funscripts authorship.
The database will not store scripts themselves, just the hashes and public metadata.
Below in the features when I say “upload” or “download” everything is happening client-side and the server is not doing anything, everything happens locally. The only operations that happen server-side is updating the database, checking the database and serving database information.

Features

Keygen

  • Funsign will generate cryptographic key pairs for you in the form of ed25519 keys
  • I will build the app to store your keys in your browser session
  • Your keys are your username/password, so store them somewhere safe

Sign

  • Using your public/private key pair you can cryptographicly sign the script
  • This cryptographicly ensures the authenticity of your authorship
  • Funsign will be available to a closed group when it first releases so you can make your script claims
  • Some claims will be included in the cryptographic signature: timestamp, authorname, source URL
  • After signature you can download the signed funscript to publish it.

Validate

  • You can upload a signed funscript and we will verify the signature embedded from the script
  • If the script was modified (timestamp, source, author, data, etc were changed) the check will fail

Diff

  • Upload 2 scripts regardless of whether they were signed, and you will visibly see what is different between the 2. A difference score will be calculated as well.

Identify

  • Any funscript can be uploaded and we will check if a script already exists in the database.
  • If your uploaded script is identical to one that exists, we can generate a signed copy of the identified script and you can download it.

Publish

  • Upload a signed script to public record, this action is permanent unless you update a script
  • Publishing a script with identical data or similar enough data will result in an error.

Update

  • If a script was already published and you want to update the metadata, or the keys, you can upload the script that’s signed with the new key, provide the old key (to prove authorship) and the new script will update the old script in database

API

There will be a read only API that can serve the validate, diff and identify functions of the app.

How does it work?

As we all know funscripts are just plaintext json. What makes this a very flexible format is we can act on individual components of a script and handle operations in isolation.

Any funscript has 2 blocks. The data block (containing points in a graph) and the metadata block (containing arbitrary information about the script). You can review this under the 2.0 spec thread

A script being signed will have the meta block updated with authorship, source URL, and timestamp.
Then the data and meta blocks will be hashed, and with both together a new json object will be made:

{ "datahash": "", "metahash": "" }

This object is what will be encrypted with a private key (signed) and the hashes and public key will be added to the script’s metadata block and made available for download
The ending result will be a funscript where the file itself is not signed, but the data inside it is.
This is important since we only want to verify authorship and tie it to the data.

Disclaimer

This whole project is way outside my skillset, and will likely take a long time. I know some go programming but not very strong with it yet. I know very little about web development beyond html/css, and related security things I do on the daily.

This project will be written with go / htmx. I will not use ANY AI written code.

20 Likes
Funscript.org post-mortem
2

I support any effort to protect hard-working scripters from this new wave of people who think they can just scrape the entire forum for scripts and then paywall them without permission or compensating the actual authors.

I have no skill overlap to help with this but I wish you luck on this project!

3 Likes
3

Did you know some of the stolen scripts on funscripted.com had funsign verification and hashes?

4

Also since this project aims to associate scripts with original authors is it possible for someone malicious to remove identifying information in the signed funscript files? (If my question is dumb go easy on me I do not code) I think this topic should be pinned if it isn’t already.

5

This is not yet an available application. I have a partially written commandline app I wrote in python, only available to me.

I have a vibe-coded prototype that I don’t think should be released because I have no idea how it works.
I’m going to do a full rewrite and learn web dev to complete that.

possible? Yes. But just by uploading to funsign you can identify the real original creator. The goal is to verify authenticity with encryption and hash checksums.

The “identity” of the script is the checksum of the datablock. If the datablock changes, it’s not the same script. I will implement a similarity check to determine if a script is “close enough” to another script.

But the idea is if a script is not signed, you can’t trust the authorship. It might be some effort but I will also probably implement a discourse plugin to intercept funscript uploads to the forum and auto-sign them.

2 Likes
6

I still have cached pages of funscripted.com open I can give you the funsign hashes.

7

That’s actually impossible DM me.

8

It’s come to my attention that telemacy has used my prototype in their application.
I have asked them to cease this, the cryptography wouldn’t work anyway the script creator needs to hold the private key for that to work correctly.

The prototype was 100% AI slop code, just my testing out ideas.
I’m going to do a full re-write in code I actually understand what it’s doing.

2 Likes
9

What happens if the script thief gets the stolen script signed first? Obviously, this will only be a problem for previously made scripts, as authors will and should get their new scripts signed before posting them.

10

A select number of creators on this forum will be given access to claim their scripts first. As well scripts can have updated metadata if they have the private key. Worst case scenario we can manually intervene, and update a script to a new keypair from the rightful user.

1 Like
11

what stops someone from opening the funscript in a text editor and stripping the metadata, or making enough small adjustments in OFS to fall outside the similarity threshold? Furthermore, how exactly does this prevent people from sharing scripts other people made? I guess I’m missing the point here. Is the point just to be able to tell if someone uploaded the same script as you? Because that’s already pretty easy to do.

12

Eventually an API can be used to proactively stop uploads from happening if a script is just blatant theft.

It also provides a single place where you can look up a scripts authorship.

2 Likes
13

How about additionally signing the creator’s signature of their script with a private key of the funsign service itself?

That way you could verify if a signature is known to the funsign service without hitting the API, just need to download a single public key in advance. Would cut down on load.

If revocation is needed, take a page out of the root CA’s books and distribute revocation lists.

14

That’s a bunch of added complexity and would mean re-signing all the scripts every time we have to make new root certs.

I don’t want to make a chain of trust. Just a timestamped signature scheme. I hate root CAs anyway. It’s a bad legacy system

15

Okay I guess I’m still missing the whole point. Sure, you can have an API on this site specifically to stop dupe uploads but is that really an issue here? What exactly is this for? A single place to look up script authorship already exists- the original eroscripts post. Is this just to protect paid scripters’ profits? I see a lot of technical jargon but I don’t understand the end goal of this project.

16

You know what it’s actually worth an in-depth explanation:

Why not a root CA?

Chain of trust is useful in some contexts. The most notable example we use is in TLS with https. The chain of trust is used to certify that some company somewhere is “vouching” for the fact that you have done some level of proof that you control the domain you are certifying control over.

I have opinions about this already but they’re frankly not relevant. The issue is this does 2 things that don’t actually help our problem.

This establishes a trust in a third party to avoid man-in-the-middle (MITM) issues with socket connections over the internet. We are not doing that.
In addition to this the established trust is in a single entity which in this case actually harms us.

How does trust work in cryptography?

In all crypto schemes you must have an anchor of trust. Someone or something you know you can trust and rely on. In the case of TLS a root CA (microsoft, commodo, EFF, digicert, etc.) Are the trusted certificate authorities. There’s a number of mechanisms they use to try and build a competent and reliable crypto scheme to establish trust and encryption on the internet.

The problem they are solving is preventing MITM attacks, a notoriously difficult problem to solve.

So why a timestamped signature?

We are not concerned with MITM attacks. Our concern is authenticity which is a different problem. We can easily prove authenticity, but we have a different threat. Anyone can sign something and pretend to be the creator of something.

So we need 2 things. An anchor of trust, and an anchor in time.
If you trust Eroscripts and the timestamp. You can trust the signature.

Trust in the signature is proof that someone certified their authorship at the given timestamp and newer signatures that can’t be validated are untrustworthy.

1 Like
17

The goal is to hold people accountable for theft.

1 Like
18

If someone steals a script and posts it externally, the theft site has no reason to check or care about funsign. And within EroScripts, script theft isn’t really a problem to begin with.

I’m also still curious, what stops someone from stripping the metadata in a text editor, or tweaking enough points to bypass detection?

If the goal is proving authorship, your original post timestamp already does that. If you’re filing a DMCA, that’s your evidence. What does funsign add?

Who actually benefits from this? It makes more sense for scripters selling their work, but for free scripters what’s the upside?

The technical side is genuinely interesting, but “holding people accountable for theft” doesn’t really hold up as a justification. If the honest answer is that this is a cool project you want to build, that’s completely valid, but the problem it’s solving isn’t clear to me.

19

Any sites that work with eroscripts would become required to use the API for uploads to their site.
In addition to this, It would give anyone the ability to simply look up who made a given script by just uploading it to funsign.

The signature verification would fail. It would no longer be a valid signature, so someone checking against the API would know this is not a script they can trust isn’t stolen.

There’s a number of techniques to detect similarness to other things like fuzzy hashing and levenshtein distance.

That timestamp is not cryptographically tied to the content of that script and doesn’t have a hash lookup function.

Creators who want to have stronger tools to quicker and easier theft detection.
Anyone who wants to quickly look up who made the script they have when the metadata is wrong, or manipulated.

The problem I see is that there’s no quick and easy way to lookup the metadata to a script, nor any kind of authorship verification. This assists platforms and individuals to combat users blatantly uploading stolen content, and gives creators stronger tools to hold thieves accountable.

By no means will this “solve” the problem but I think it will help the problem and provide stronger infrastructure to curb the issue.

Imagine a scenario where you buy a script. You lookup the script on funsign and learn that it was stolen and re-sold. You can inform others, the original creator, etc.

1 Like
20

what about sites that just don’t bother? And what about scripters who don’t want to go through the signing process? This creates a system where non-participation gets treated as suspicious by default, which seems like it could cause more problems than it solves. I don’t care if my scripts are reuploaded, but I would still have to go through the whole signing process, keep track of yet another password (after enforced mfa this is a particular sore spot) and comply to your system just to avoid it looking like I stole my scripts?

if someone makes an alternate version of a script, or two people independently script the same scene, wouldn’t that cause false positives? Scripts for the same video are naturally going to share a lot of the same timing and stroke structure. (And this would discourage scripters from creating free alternatives to paid scripts)

If you’re trying to prove to a DMCA agent or a community that you made a script, “I posted it here on this date and here’s the thread” is sufficient. Nobody filing a takedown is going to be asked to provide a cryptographic hash. It’s a technically correct distinction that doesn’t matter in any real world application of proving authorship. And that cryptographic guarantee evaporates the moment someone strips the metadata or tweaks enough points anyway.

The actual concrete benefit here seems to be quick metadata lookup, which is useful but pretty modest for the scope of the project. Everything else depends on bad actors voluntarily cooperating with a system designed to catch them, which isn’t really how bad actors work. The idea of a proper script database with metadata and authorship is genuinely interesting, though isn’t that kind of what eroscripts already is?