

Two proposals for browsers - it's about time - EGreg

I've been reading a bunch of stuff on HN about user privacy, etc. and trying to build something myself which lets the user feel secure and in control, but current web technology doesn't let me do it. So I wanted to propose two things on here, and maybe someone here would run with the idea.<p>1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same. 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 resources. Sites all over the world can download resources from httpc:// urls 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://<p>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. Right now, the web forces us to trust a remote server completely, when interacting with a website. For example, when I enter a password, I have no assurance that the server won't misuse it. (See http://xkcd.com/792/)<p>This simple change would make possible a variety of applications that we haven't even thought of, besides these two.<p>2) The second proposal is to have iframes that are on top of everything else in the containing window, no matter what. That would enable 3rd party logins (such as OAuth) do be done in the iframe, without worrying about clickjacking. The javascript inside the iframe should have a way of checking whether the iframe is of this type. At most one such iframe can be shown in any given window.<p>This would lead to much more pleasant interfaces, and once again, the user would receive the extra protection. Of course, this means that Flash and other plugins would have to play nice with this. We could implement this rather easily with a browser extension that causes a borderless window to appear (like Flash does) above the actual browser window.<p>Thoughts?
======
selectnull
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> and there is offline web app proposal
<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
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
About proposal #2 ... technically, all we would have to do to implement
"topmost iframes" is to make their z-order highest in the browser renderer.
Now that I think about it, flash and other commonly installed plugins that may
create a window "on top of" the browser would not make clickjacking possible,
since those windows receive the mouse inputs.

