Similar to how we have https:// blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant files. Sites all over the world can download urls from httpc:// and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like https://
I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Currently with web tech it's impossible to be sure you aren't revealing sensitive info to the server. This simple change would make possible a variety of applications that we haven't even thought of, besides these two.
I don't really see how httpc:// would make HTTPS logins work better. Can you explain?
Some sort of "distributed checksumming" like your first example may be useful for myapp-1.0.0.dmg or jquery-1.4.4.js, but how would you handle upgrades?
distributed checksumming is what I am talking about
upgrades should be done by putting the new version at a DIFFERENT url. As tim berners-lee says, cool uris don't change: http://www.w3.org/Provider/Style/URI
what is the advantage of magazines having to review every new version of software?
httpc:// would be used for logins and distributing software. People already publish checksums, this would just be an automatic way of verifying every file that the server claims is constant.
Comments
Yes, I have a proposal.
Similar to how we have https:// blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant files. Sites all over the world can download urls from httpc:// and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like https://
I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Currently with web tech it's impossible to be sure you aren't revealing sensitive info to the server. This simple change would make possible a variety of applications that we haven't even thought of, besides these two.
I don't really see how httpc:// would make HTTPS logins work better. Can you explain?
Some sort of "distributed checksumming" like your first example may be useful for myapp-1.0.0.dmg or jquery-1.4.4.js, but how would you handle upgrades?
distributed checksumming is what I am talking about
upgrades should be done by putting the new version at a DIFFERENT url. As tim berners-lee says, cool uris don't change: http://www.w3.org/Provider/Style/URI
EGreg - if everyone will have to re-establish trust for each new release, what's the advantage?
what is the advantage of magazines having to review every new version of software?
httpc:// would be used for logins and distributing software. People already publish checksums, this would just be an automatic way of verifying every file that the server claims is constant.