[whatwg] security for scripts with elevated permissions

Glenn Maynard glenn at zewt.org
Thu Jan 6 19:45:45 PST 2011

On Thu, Jan 6, 2011 at 5:21 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> An XSS attack can still get IP address, and thus usually rough
> location, so most of what I said still holds.

My IP address points to an area several towns wide.  IPs for mobile
devices (where geolocation is more often used) often tell next to
nothing.  Geolocation will give my location to a few meters--they're
not even in the same category.

I don't care about this enough to worry about it, but I understand why
some people do.

> Lots of people have written extensive explanations of why browsers do
> this.  Here's one I submitted as a comment to lwn.net a while back,
> maybe it will clear things up: http://lwn.net/Articles/413600/

I'm not sure I find that entirely convincing, though I understand the
logic.  In any case, I don't expect this to change for HTTP/HTTPS.
Maybe SPDY will improve this, if it ever gains wide use.

>> By the way, another real-world issue with SSL is that it's
>> considerably more computationally expensive: handling encrypted
>> requests takes much more CPU, especially for high-bandwidth servers.
>> Not every service can afford to buy extra or more powerful servers to
>> handle this.
> Apparently this isn't a real issue anymore in practice.  CPUs are fast
> enough that SSL is no big deal.  Google saw only a small load increase
> when it turned on HTTPS by default for all Gmail users:
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Without knowing the load characteristics of Gmail front-end servers,
I'm not too convinced.  I've seen significant load differences simply
between using sendfile and not on a server pushing around 150-300
mbit, and that's just one side-effect of SSL.

Regardless, I do think it's reasonable to require SSL for particularly
sensitive APIs.  If the costs of using it are annoying, that'll just
have to be lived with.  However much you trust a site, you don't want
to elevate its permissions to grant, say, broad local file access on
an unencrypted connection.  (Well, unless it's an intranet or
localhost service, of course.)

Whether SSL is *enough* for sensitive APIs like that--that, I think,
is the open question.

Glenn Maynard

More information about the whatwg mailing list