geolocation API & iframes: another privacy consideration

Folks,

for a talk at the local university, I've been looking at some of the current geolocation implementations, and that made me look again at a question that had been asked at the July API privacy workshop: What's the right authorization behavior when the geolocation API is invoked from within a third-party iframe?

The consensus at the workshop (including folks from various implementers) seemed to be that Chrome's behavior is probably the right approach to that case:  Actually, scoping the permission to the pair of the top-level Web page's origin, and then the origin of the resource from which the API is invoked.  Checking out a few implementations, I'm fearing that we collectively didn't carry that ball forward.

Example: If maps.google.com has permission to get my location, then maps.google.com running in an iframe off does-not-exist.org still needs a new permission.  The permission for that pair can be persisted separately.

This approach addresses an otherwise fairly creepy tracking risk:  Assume I give a site that gets iframes widely deployed (advertising, some sort of widget, ...), let's say f.com, permission to get my location without asking.  Then f.com can acquire my location without any interaction or consent whenever I visit another site that merely has an iframe from it.

From a quick test, it looks like, as of now, at least Safari (5.0.3), Opera (11.01) and Minefield (4.0b11pre, 2011-02-02) simply persist permissions on a per origin basis. (All tested on a Mac.)

I guess this might be worth some discussion about a spec fix (though CR is obviously quite late for it) after all, or a change in v2.  It might also be worth a fix in the implementations that are getting deployed; it strikes me that the choice that the Chrome team has made doesn't break conformance with the spec as it stands now.

Cheers,
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)

Received on Saturday, 5 February 2011 00:28:36 UTC