3 ms·

There is no way to have a web-document-embedded map that can usefully show a user things near their device's location without leaking that location to any entit

There is no way to have a web-document-embedded map that can usefully show a user things near their device's location without leaking that location to any entity with access to execute JavaScript in the context of that document. Browsers have had to learn the hard way that getComputedStyle and even the animation timing APIs are essentially un-close-able privacy leaks (hell, even HSTS is abusable as a way to set and check "supercookies"). Any useful map would have similar problems.

LordDragonfang 9y ago
>getComputedStyle It looks like Firefox actually closed those security holes a while ago[1], and WC3 changed the standard to reflect this. [1] http://www.h-online.com/security/news/item/Firefox-developers-block-old-CSS-leak-968670.html http://www.h-online.com/security/news/item/Firefox-developer...
- ubernostrum 9y ago
  Simple use of :visited has been closed off, yes, but that actually took multiple attempts. See this bug, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=557287 https://bugzilla.mozilla.org/show_bug.cgi?id=557287 And about a year ago it was discovered that in Microsoft Edge the :visited hack was alive and well again. And that's still very far from fixing the problem. There are still occasionally properties which pop up that are accessible and can reveal visited/unvisited state. There were a whole bunch of background-image tricks where observing what image was requested from the server side would tell you visited/unvisited. There have been timing attacks which could reveal recently-visited sites based on load times (faster when coming from browser cache). Then there are the the techniques which use animation APIs and still work today. The core of the trick there is to 1) get a link in the page which you know will use unvisited style, 2) register a callback for the next repaint with requestAnimationFrame(), 3) change the link to point at the URL you want to test, and 4) see if your callback executes (which indicates the link was repainted to a different style due to now pointing at a visited URL). The ability to do visited/unvisited styles differently, along with the style-inspection and timing APIs, while useful, are basically always going to provide ways to do this. If you poke around you'll find that aside from the most basic variants there's a tendency for these reports to end up closed out or just left in limbo forever because there's no practical way to close off the privacy leaks they create.
  - mcphage 9y ago
    Right now everything with maps is completely wide open. So if they added a feature which provided security most of the time, but which sometimes leaks information if you jump through the right hoops, that’s still 100x better than where we are today. You’ll note that nobody is using the existence of requestAnimationFrame() exploits to argue we should just give sites whatever browsing history they want—yet that’s what you’re arguing here for location history.
zeveb 9y ago
> There is no way to have a web-document-embedded map that can usefully show a user things near their device's location without leaking that location to any entity with access to execute JavaScript in the context of that document. So disable JavaScript. A web-document-embedded map in a browser which doesn't execute JavaScript wouldn't leak user location. This isn't an argument against a map element; it's an argument against JavaScript. Which is fine with me: I think that JavaScript is the drug-resistant syphilis of the web. It's been an unmitigated disaster for privacy & security.
- ubernostrum 9y ago
  The parent comment was suggesting it's possible to have a map element built in to the browser which would not leak the user's location. That is probably not possible.

LordDragonfang 9y ago

>getComputedStyle It looks like Firefox actually closed those security holes a while ago[1], and WC3 changed the standard to reflect this. [1] http://www.h-online.com/security/news/item/Firefox-developers-block-old-CSS-leak-968670.html http://www.h-online.com/security/news/item/Firefox-developer...

ubernostrum 9y ago
Simple use of :visited has been closed off, yes, but that actually took multiple attempts. See this bug, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=557287 https://bugzilla.mozilla.org/show_bug.cgi?id=557287 And about a year ago it was discovered that in Microsoft Edge the :visited hack was alive and well again. And that's still very far from fixing the problem. There are still occasionally properties which pop up that are accessible and can reveal visited/unvisited state. There were a whole bunch of background-image tricks where observing what image was requested from the server side would tell you visited/unvisited. There have been timing attacks which could reveal recently-visited sites based on load times (faster when coming from browser cache). Then there are the the techniques which use animation APIs and still work today. The core of the trick there is to 1) get a link in the page which you know will use unvisited style, 2) register a callback for the next repaint with requestAnimationFrame(), 3) change the link to point at the URL you want to test, and 4) see if your callback executes (which indicates the link was repainted to a different style due to now pointing at a visited URL). The ability to do visited/unvisited styles differently, along with the style-inspection and timing APIs, while useful, are basically always going to provide ways to do this. If you poke around you'll find that aside from the most basic variants there's a tendency for these reports to end up closed out or just left in limbo forever because there's no practical way to close off the privacy leaks they create.
- mcphage 9y ago
  Right now everything with maps is completely wide open. So if they added a feature which provided security most of the time, but which sometimes leaks information if you jump through the right hoops, that’s still 100x better than where we are today. You’ll note that nobody is using the existence of requestAnimationFrame() exploits to argue we should just give sites whatever browsing history they want—yet that’s what you’re arguing here for location history.

zeveb 9y ago

> There is no way to have a web-document-embedded map that can usefully show a user things near their device's location without leaking that location to any entity with access to execute JavaScript in the context of that document. So disable JavaScript. A web-document-embedded map in a browser which doesn't execute JavaScript wouldn't leak user location. This isn't an argument against a map element; it's an argument against JavaScript. Which is fine with me: I think that JavaScript is the drug-resistant syphilis of the web. It's been an unmitigated disaster for privacy & security.

ubernostrum 9y ago
The parent comment was suggesting it's possible to have a map element built in to the browser which would not leak the user's location. That is probably not possible.