site.com
list of versions, paired with signatures of versions, e.g.:
{
version: 7a5179eecc0fe18760ba615f92603372ae3fe302860098a019e15927551fee3b,
signatures: [
{
signer: 60ba615f92603372ae3fe302860098a019e15927551fee3b7a5179eecc0fe187,
signature: 3372ae3fe302860098a019e15927551fee3b7a5179eecc0fe18760ba615f9260
}
]
}
site.com/app/HASH
the site, running at this version
site.com/doc/HASH
any document
When you go to any URL, e.g. "site.com/doc/HASH", you'll get back a text response.
You would need to extract the HASH from the URL, and then hash the text response and verify that the two hashes are identical.
You might want a static header that gives you a single-group regex that will get you the hash, e.g.:
X-Eternal-Site-Regex: "//site.com/(?:doc|app)/(.*)"
So then, you can verify that the document hash is correct, so you can confirm that you have the exact correct document.
So for example, if you had index.html and it looked like:
<!DOCTYPE html>
<head>
<script src="//site.com/doc/e302860098a019e15927551fee3b7a5179eecc0fe18760ba615f92603372ae3f"></script>
</head>
</html>
You would be able to confirm that JS file you downloaded was exactly the file the index.html wanted.
Then, you would take that index.html file and store it as a collected app, e.g.:
site.com/app/0098a019e15927551fee3b7a5179eecc0fe18760ba615f92603372ae3fe30286
And then the developer could sign that hash, and publish that as a document as well.
Now on your front page, you have a link to the latest app, and you have these proofs:
- the developers published it at that version, because you have their signatures
- the app version you request is exactly the version you receive, because you have the hash
- every source the app uses is exactly the source you receive, because you have those hashes as well
One issue might be knowing what the
doctype
of asite.com/doc/HASH
is supposed to be.Technically, the one creating the document could know what it was for, and submit that information as part of the "create document" call. So that, e.g., the one posting the document would say "this is JS", and then whenever requests were made for that document, the X headers would set the type to JS.
Another option might be to say something like
site.com/doc/EXT/HASH
, so that you could specify what header type to return. This is possibly open to abuse, but in a similar way that you are trusting thesite.com/app/HASH
, you would be trusting that the developers are calling the correct header file type.Perhaps a better way is to simply say
site.com/doc/HASH/MIME_TYPE
, e.g.:Then you would need to change the other header to something like: