Timeline for Is there a protocol that provides data integrity, but not encryption for HTTP?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 6, 2023 at 22:18 | comment | added | supercat | Basically. If a web page says it needs a script file foo.js with a certain SHA hash, and an intermediate proxy supplies what's supposedly a cached copy of the file, that has the required hash, there's no need to trust the proxy in order to trust the contents of the supposed cached file. | |
| Dec 24, 2020 at 22:35 | comment | added | supercat | @josh3736: Except that BitTorrent (not sure about IPFS) use a completely different protocol and addressing scheme. I was envisioning something that would be processed like http, but with browsers deferring processing of received content until the hash could be validated, and with the URL containing a hash, but also containing information sufficient to locate the information in a manner not reliant upon the hash. | |
| Dec 24, 2020 at 21:55 | comment | added | josh3736 | @supercat you've basically just described BitTorrent or IPFS | |
| Dec 24, 2020 at 20:54 | comment | added | supercat | I wonder what the pros and cons would be of a protocol which encapsulates within a URL a hash of a file header which would in turn be expected to contain a hash for the entire file or a list of hashes for segments thereof? One would use https:// to receive a page or script containing the URL, but the page itself could be served by anyone. If the document was updated, the page containing its URL would need to change, but there would be no danger of a cached copy of the referred-to page being mistaken for a fresh one. | |
| Oct 18, 2020 at 15:17 | comment | added | MikeSchem | Wow, that's an uncomfortable use case, but thanks that does answer my question. | |
| Oct 16, 2020 at 19:54 | history | answered | josh3736 | CC BY-SA 4.0 |