4 ms·

On 1) There are parts of the stack that do some of the things you describe here. For example, on HTTP level there is ETAG http://en.wikipedia.org/wiki/HTTP_ETag

On 1) There are parts of the stack that do some of the things you describe here. For example, on HTTP level there is ETAG http://en.wikipedia.org/wiki/HTTP_ETag http://en.wikipedia.org/wiki/HTTP_ETag and there is offline web app proposal http://www.w3.org/TR/offline-webapps/ http://www.w3.org/TR/offline-webapps/ They are used for different purposes and they work (whether they work well is a different matter), but in a way they can be used for "constant resources". I don't really see how such mechanism can be used as a guarantee against sending a password in the clear. On 2) I would rather see someone work on solving the underlying problem, which in a nutshell is security. That's a hard problem and I don't really see it solved with iframes. All that said, you are absolutely right: these are problems and should be worked on.

EGreg 16y ago
The thing is, the ETAG and other headers are sent by the server. They may be different tomorrow. Technically we don't have to have a different scheme like httpc:// ... although it would be better to have it, because people can see at a glance the httpc:// and know that guarantees have been made (as opposed to headers having been sent). The only guarantee we need to make is that the file is constant. That is easy enough to check without even having a web of trust. Since something is constant, just add a couple of authorities on the internet to each browser, and if even one of them disagrees, show the warning. (A rogue "authority" can of course mess up someone's login screen by claiming it changed, but the similar things can be done by rogue dns servers.) Anyway once you guarantee the constant-ness, other authorities can guarantee things like "safety". And the best part is, httpc:// files should be the same to everyone, regardless of cookies, IP, etc. so ANYONE can go and verify their properties. There is NOTHING like this in user agents right now (automated verification of guarantees about a resource) but there should be!!

EGreg 16y ago

The thing is, the ETAG and other headers are sent by the server. They may be different tomorrow. Technically we don't have to have a different scheme like httpc:// ... although it would be better to have it, because people can see at a glance the httpc:// and know that guarantees have been made (as opposed to headers having been sent). The only guarantee we need to make is that the file is constant. That is easy enough to check without even having a web of trust. Since something is constant, just add a couple of authorities on the internet to each browser, and if even one of them disagrees, show the warning. (A rogue "authority" can of course mess up someone's login screen by claiming it changed, but the similar things can be done by rogue dns servers.) Anyway once you guarantee the constant-ness, other authorities can guarantee things like "safety". And the best part is, httpc:// files should be the same to everyone, regardless of cookies, IP, etc. so ANYONE can go and verify their properties. There is NOTHING like this in user agents right now (automated verification of guarantees about a resource) but there should be!!