Discourage centralization

[ahsane]

In order to discourage centralization of the web, authors should have an incentive to keep their websites active.

One way is to make sure is that the author's server provides the client with the decryption key to decrypt the package.

i.e:

1. example.com signs and packages example.com/index.html and submits to google.com
2. google.com distributes example.com/index.html
3. users downloads example.com/index.html from google.com
4. user connects to example.com for the index.html's decryption key
5. browser decrypt the index.html package supplied by google with the decryption key supplied by example.com

This all should be optional to the author. Some authors might only want google.com to distribute the html/css/js for faster loading but ensure that the client has a first party contact with example.com too.

It is already possible to do the same with javascript, but the web should also provide a native way to do this.

[sleevi]

I’m afraid this is confusing some of the cryptography, such as the notion of a “decryption” key. It sounds like you aren’t concerned about the cryptography, per se, but want to ensure origins remain in control, correct? This property is already maintained, by requiring fresh signatures over the package, which are distributed by `example.com` in your example. Does that address your use case?

[ahsane]

I am no expert in cryptography, but used a non-detailed overview to convey what I wanted (had no other words to explain) and know if it is practical.

It sounds like you aren’t concerned about the cryptography, per se, but
want to ensure origins remain in control, correct?

We'll if control means that user can only access the site/content after pinging to the author's server, in this case "example.com".

[sleevi]

I see. That's the opposite of the design goal for the use cases.

[ithinkihaveacat]

@ahsane A signed exchange package is valid for up to 7 days. (The exact period is controllable by the author, but this is expected to be >0 days.)

This means that users may see content that appears to be from example.com (i.e. the URL bar of the browser reads example.com) up to 7 days after example.com has lost network connectivity and completely disappeared from the net.

[cramforce]

For all practical purposes the content in a web packages also has to be available at the packaged URL. If you load a package in a browser and hit reload, it would be a terrible user experience if the content wouldn't load again. While this certainly can happen theoretically, any practical use would try to avoid this problem as much as possible.