Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mapping in HTML – A Proposal for a New Element

shkspr.mobi

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Mapping in HTML – A Proposal for a New Element

#51

Post by ubernostrum »

LordDragonfang wrote: post #49
ubernostrum wrote: post #44

Earlier quoted context omitted.

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 c…

>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-developer...

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

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.

Re: Mapping in HTML – A Proposal for a New Element

#52

Post by mcphage »

ubernostrum wrote: post #51
LordDragonfang wrote: post #49

Earlier quoted context omitted.

>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-developer...

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 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 visit…

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.

Re: Mapping in HTML – A Proposal for a New Element

#53

Post by zeveb »

ricardobeat wrote: post #3

This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland. Example: https://www.webcomponents.org/element/keanulee/good-map

> This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland.

'Userland' isn't really the right word here: web components aren't from my land; they just execute there — they are from some server.

And that's the problem: to display a map (which is, really, just an image, something HTML has been able to display inline since the late 90s) I have to grant execute permissions on my computer to some random piece of JavaScript written by a programmer of unknown competence and beneficence, and reviewed by precisely no-one.

If it's in-browser, the implementation is auditable. It doesn't change on a per-page-load basis. It doesn't require JavaScript. It can be made to work for anyone, on any platform (even if all 'work' means on a particular platform is 'there's a map of $LAT, $LONG here'). It is far less likely to be an intrusion vector. It is far less likely to violate my privacy. It is far less likely to beacon to half a dozen advertisers.

JavaScript isn't just killing the Web: it's murdering it. I sometimes think that JavaScript developers would like to just get rid of HTML entirely: just build the entire page dynamically. HTML is just their bootloader.

Re: Mapping in HTML – A Proposal for a New Element

#54

Post by zeveb »

ubernostrum wrote: post #44
mcphage wrote: post #42

Earlier quoted context omitted.

> Even if there was some sort of opaque position-in-the-browser-but-not-sent, how would, say, nearby businesses show up? The tag would contain (or link to) a listing of locations, and the map could choose to display nearby ones. > People don't have built-in mapping software installed on their computers. Some do (Macs, for instance), but I think the author was proposing that the browsers themselves would implement the…

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 c…

> 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.

Re: Mapping in HTML – A Proposal for a New Element

#55

Post by zeveb »

aphextron wrote: post #6
ricardobeat wrote: post #3

This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland. Example: https://www.webcomponents.org/element/keanulee/good-map

Agreed. There should (and probably will) never be another new element added to the spec after HTML5.

That's a remarkable perspective, and one I happen to disagree with. The great thing about standardising elements is that we can standardise behaviour without having to grant every server in the world execute access on clients. HTML can be used simply as a bootloader to start up a JavaScript DOM-manipulator, but it shouldn't be, because it is far more secure and private to read a static web page than it is to execute untrusted code.

Re: Mapping in HTML – A Proposal for a New Element

#56

Post by j4ybee »

shabbyrobe wrote: post #19
j4ybee wrote: post #11

Earlier quoted context omitted.

yeah, those came a little later, but 2000 was the first year ICANN was ready to accept proposals for TLDs beyond the original 7. They made a call for innovative new uses of the domain system. My colleagues proposed .geo, ICANN went with .biz, .info, .name, .pro, .aero, .coop, and .museum. Full list of proposals that year here: http://archive.icann.org/en/tlds/app-index.htm

Oh, I was joking about .moe, etc - I reckon .geo would be far more useful! But my main question about the moon was quite serious - how would you access the moon with this? I couldn't quite understand how this part from the executive summary would translate to an actual DNS request: "One special GeoRegistry must have a server assigned to every cell on the planet. This GeoRegistry will be called the default GeoRegistry…

the overall program also included a 3D terrain browser built on top of .geo that pre-dated Google Earth by 4 or 5 years.

http://www.ai.sri.com/digital-earth/

those were great times... sadly, the Principal Investigator passed away, one of the lead devs left the company for greener (for-profit) pastures, and the program was de-funded when DARPA priorities shifted post-9/11 and it all just kinda evaporated.

re: the moon - I honestly forget how that part was supposed to work....

Re: Mapping in HTML – A Proposal for a New Element

#57

Post by ubernostrum »

zeveb wrote: post #54
ubernostrum wrote: post #44

Earlier quoted context omitted.

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 c…

> 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…

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.

Re: Mapping in HTML – A Proposal for a New Element

#58

Post by chrismorgan »

zeveb wrote: post #53
ricardobeat wrote: post #3

This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland. Example: https://www.webcomponents.org/element/keanulee/good-map

> This is the exact use case for web components, except it doesn’t require browsers shipping their own implementation and updates - it’s all in userland. 'Userland' isn't really the right word here: web components aren't from my land; they just execute there — they are from some server. And that's the problem: to display a map (which is, really, just an image, something HTML has been able to display inline since the…

> I sometimes think that JavaScript developers would like to just get rid of HTML entirely

Well, the DOM is still useful. Controlling all rendering using a canvas is going too far for most things. But yes, the actual serialised HTML that the browser loads is commonly merely bootstrapping.

Re: Mapping in HTML – A Proposal for a New Element

#59

Post by chrismorgan »

tmcw wrote: post #38

The solution proposed doesn't match the problems stated, or take much of the technical realities into consideration. Which is fine - maps are complicated, and hard to understand. - As a user, I don't want to share my location with a website. The proposed element doesn't seem to address this at all, or suggest how it might address the problem down the line. Even if there was some sort of opaque position-in-the-browser…

> People don't have built-in mapping software installed on their computers.

Actually, I think the substantial majority of users do now; recent macOS, Windows 10, iOS, most Android—and having browsers fall back to using an existing mapping website (similar to its being an iframe) would not be terribly difficult.

Post reply on HN