Ask HN: Why don't browsers extend “This site wants your location” to all data? | Hacker News Reader

Ask HN: Why don't browsers extend “This site wants your location” to all data?

40 pointsrapht70 comments

Time and again, users on the Internet are shown to be uniquely identifiable through new and old data leakage from their browser.

And I'm wondering: just like browsers already display "do you want to share your location" when websites try to access this info, why don't they have this kind of security mechanism for every information that could make the user uniquely identifiable such as "This site wants to know [the list of installed [fonts|plugins] | the battery status of your device | ...] ?"

Are there some technicalities that make this a particularly hard problem?

View on HN

I've been developing and releasing consumer software for a few years now, and the key rule about popup messages is: Nobody reads them.

A significant number of users will, upon seeing any kind of message that does not mean something totally obvious to them (as a non-techie), just click cancel. Either they panic or they don't understand or they don't care. For example our software used to have a particular kind of error that as clearly as possible stated that it could be solved by visiting a URL and installing some update. Cue lots of support messages: "I see some error, what do I do?"

Browsers are consumer software. If it asks "this webpage wants to use your camera", that's just about obvious enough. However if it asks "this webpage wants to run plugins", user thinks "WTF are plugins" and presses cancel, then wonders why their video is not playing. (Reasonable question from the user's perspective: why didn't the browser say "this webpage wants to play video"?) If it asks "this webpage wants to access your WebGL renderer string" or "this webpage wants to know your hardware information" or something, the user thinks "WTF" and presses cancel, then Google Maps can't work around a graphics driver bug on their system and the map glitches up.

So as far as is possible, consumer software should not prompt the user for anything, and if it does, it should be totally obvious to someone with little to no technical knowledge.

This comment reflects a general philosophy of making things as simple as possible in consumer UX for the past 10-20 years. That principle is generally sound and arises from a problem where UI was being created by developers for developers, and as a result was often needlessly complicated and obtuse. Businesses realized that simpler UI geared toward less technical users could expand their markets as well as increase user engagement.

Taking this philosophy to the extreme, however, has led to problems. At its most draconian, the implementation of "simpler is always better" results in features being removed or never implemented, walled gardens being created, and the gradual erosion of the general purpose computer.

No it's probably not the right mass market UX, but I am TOTALLY down for a browser which asks me, "This site wants to access (insert some data about me like my browsing habits, Facebook account ID, or stuff that contributes to a unique browser footprint). Allow or disallow?" and then lets me say NO.

So I don't want to dismiss the idea that simpler is better: for mass market UX designed to reach as many users as possible, this is a key principle. But at the same time I believe we need to start considering the fact that in UX one size might not fit all, even when it may not maximize corporate profits.

Maybe shipping your software with a 'developer mode' toggle is the right way to do it!

Regarding the philosophy, I am of opinion that the "default" UX guidelines are way too far into the extreme already. As you noted, at some point making things easier to use means dumbing them down and cutting out features until only the trivial stuff remains. It makes for an easy sale, which is why businesses are doing it, but it also makes close-to-useless products. The key here is that businesses in general care only about whether the UX is good enough to make you pay them (directly or indirectly, through "user engagement") - they absolutely do not give a damn about whether the product actually helps you in any way.

In my perfect world, developers wouldn't prioritize the amoral business needs so much and would take into account whether or not the product actually does something worthwhile. In our imperfect world, I could settle for the "advanced/developer mode" toggle. But those too are going away, since pro users aren't usually a large part of the group of paying customers...

> Maybe shipping your software with a 'developer mode' toggle is the right way to do it!

Well, Firefox's incognito mode goes in the right direction. It's nice to be able to put the browser in a mode where it does the right thing without prompting (where right = respects the user's privacy by default). It would be even better if incognito mode was the default and instead users had to go out of their way to put their browser into "unsafe mode" in order to expose all these nasty bits to web sites.

Yeah, I think locking down the private browsing/incognito modes is a good compromise. Things like the battery level, WebGL render string etc. (anything that can be used to improve tracking) could return fake data in incognito mode, but real data in normal mode. IMO that's the best compromise between "keep my information private" and "things work usefully by default". I don't know if browsers already do that though?

You are generalizing. Perhaps some users do care about what a popup says?

I think you missed the point of his comment. It's not merely that users don't care. It's that most users don't even understand what a popup is saying. The average user doesn't know what a cookie or a plugin is.

That kind of misunderstanding is the fault of the speaker, not the listener.

The current paternalistic trend of removing agency from the user and making choices for them is lazy and perpetuates ignorance. Write better popups that do a better job explaining the problem, educating the user, and expressing the necessary information so the user can make an informed choice.

A good explanation doesn't matter-- users frequently don't even read the message. They just hit the button, because they just want to get on to whatever it is they want to be doing.

You are generalizing. Perhaps some users do care about what a popup says?

The point is that if the browser asks for permissions and the majority (or even just a significant minority really) say no because they don't understand the question then it has a tremendously negative impact on every application that could be built using that browser feature. It's better for progress if browser vendors make an intelligent call when and where browser's let applications access things.

Personally I'd rather browsers did ask permission, but in a way that affords application developers a way to explain why they need access. The difficulty would be how to stop rogue apps trying to scare users in to accepting things.

> but in a way that affords application developers a way to explain why they need access

I think this just won't work. Most developers will end up with "need this to work correctly" excuse and proceed in all-or-nothing manner. Maybe with a small room for compromise, but not much. Heck, we already have this quite common with OAuth, when many sites ask you for your name, your contact/friends list, permission to post on your behalf and your first newborn's soul - in "grant all of this or go away" manner.

This will only continue the unnerving trend to train common users to mindlessly agree to whatever they're asked (already happened to license agreements, didn't it?) for because they'll be continuously told that it's "necessary".

https://news.ycombinator.com/item?id=12026876

Sad but true. My guess is that if the alternative to "run the site/app letting it violate your privacy" is "run the site/app, NOT letting it violate your privacy", users will choose the second one. If the alternative is GTFO, they'll just run the app fully exposed.

Actually, there's the third option - heavy sandboxing with privilege spoof.

Let the app think it gets access to all it wants. E.g. fake battery stats, never ringing buzzer, empty or fake contact list, throwaway email address, geolocation in random place (around the world or city of user's choice), random per-installation device IDs, etc.

He explained clearly that a browser is "consumer software". That is generic software.

If you're writing an application where your users care about what a popup says, then you should use them.

Not only do users not read pop-ups, but the more words you put on them, the less likely it is they'll read. The browser should 1. if at all possible make the best* choice for the user by default, 2. provide a setting somewhere power users go so they can change that choice. Popping up a dialog should be like punting--do it only when no other options are sufficient.

* Obviously what's "best" is the tricky part

> I've been developing and releasing consumer software for a few years now, and the key rule about popup messages is: Nobody reads them.

Really? For mobile applications, users are very wary of them. Granted, they can't do anything until they either accept or deny location (or whatever other thing the app is asking for) data.

It'd take getting used to but, I think it'd be something users would appreciate long term.

I should have specified - we build desktop software! But I think the principle of "don't ask the user questions they can't answer" still stands.

This website wants to know your screen resolution. [allow] [deny]

This website wants to know the list of fonts installed on your system [allow] [deny]

This website wants to access your location. [allow] [deny]

This website wants to use the css attribute a:visited [allow] [deny]

This website wants to record more than 1 mouse event per second. [allow] [deny]

This website wants to read your battery status. [allow] [deny]

This website wants to disable your ad blocker. [allow] [deny]

This website wants to know your timezone. [allow] [deny]

This website wants to know your device temperature. [allow] [deny]

This website wants to open more permission requests. [allow] [deny]

You're exactly right that this would be incredibly annoying, but I think that should be the point. 99% of sites have no business accessing a lot of that stuff and popping up warnings every time they try to would make it a whole lot more obvious when a site is taking advantage of your personal data.

Popups like this act kind of like side effect disclaimers in pharmaceutical advertisements. The ad tries to gloss over them as quickly as possible because they're confusing and scary to the potential customers - for good reason! It's annoying to have to hear that list of crazy side effects in every commercial, but it serves a purpose and it would be a mistake to remove it in the name of "convenience".

> 99% of sites have no business accessing a lot of that stuff and popping up warnings every time they try to would make it a whole lot more obvious when a site is taking advantage of your personal data.

I agree, sites should not have access to that data. I would prefer if those features would be removed again instead of introducing more popups.

As a side note, I've often noticed that the disclaimers in the pharmaceutical advertisements state the side effects in a slow, calm voice while the actor calmly walks though an abstract world which functions as a metaphor for living with the disease in question. In the end, the effect is that the listener stops paying attention to the words being said. The speed reading of the disclaimer is especially prevalent other types of advertisements though.

Right, and I can see times when I'd really prefer this behavior. Especially in incognito mode. But let's say at worst case we could categorize those or allow a settings page where I could switch these to opt-in-by-hostname/opt-out-by-hostname.

Try using the uMatrix browser plugin for fine grained control of what external scripts/frames/etc a website may request.

I'm using it (along with uBlock Origin, EFF Privacy Badger and custom Tampermonkey scripts), and while I like the sense of control, I also think it's obvious that fine grained control for such details or further details like battery status is not what most users want or even could handle.

Sometimes it becomes really annoying and I give up on figuring out what minimal set of features a site needs, and I open it in an incognito tab where only uBlock Origin is active.

I run uMatrix too and I agree it gets annoying at times (and it gives you first-hand insight into how rotten the web industry is). That said, pretty much all the stuff from your comment upthread are things 99% of websites have no business accessing. So an uMatrix-like (default-deny) control for permissions should work well IMO, with only occasional cases when you need to whitelist something.

I'm also thinking about another kind of plugin - one that simply monitors access to browser API calls required to get information like resolution, mouse pointer position, battery level, etc. and that would display you only the "spying level" of a site as an icon. Like the padlock icon, changing colors from green to yellow to red or something, and that would expand when clicked to show something like this:

  Spying level: MODERATE.

  This website has accessed following information about your system:

  - screen resolution - 256 requests
  - mouse pointer position - 8192 requests
  - location - 42 requests
  - battery level - 16 requests

  [CLICK] to send an e-mail to webmaster (webmaster@example.com) asking for
  information about how they're using your data.

I'm not sure if current plugin infrastructure has enough power to hook JS APIs like that though.

What about being able to say "Block everything" or "Allow everything", and allow the user to default to one or the other.

I would find it weird if a random blog or ecommerce website wanted to know my battery level or device temperature, but frequently I can only block them finding out by blocking JavaScript entirely, and that often means the site doesn't work at all. So I'm caught between giving them access to all sorts of stuff which they can use to identify for me (and I have no idea whether they're doing that or not), or not using the site at all.

It would be nice to be able to say "let the site execute JavaScript, but don't give access to my machine or OS data".

This would cause site designers to consider if they really need the access (they don't). Problem is, as soon as one browser stops asking, the idiots would flock to it and site designers will stop supporting the good browsers.

None of those things are what a typical website has any business accessing. Even the screen resolution for responsive layouts could (should) presumably be handled by correct application of CSS.

How do you explain what "this site wants to know the list of installed fonts/plugins" means to the person using the browser? How would they make the decision to allow or disallow this?

If you show too many confusing popups like this, people will get in the habit of clicking "ok" without reading at all.

AFAIK there isn't an API call to enumerate fonts. There are a number of methods developed over the years to do that.

If there were an API call I think any browser shouldn't implement it, but how to block any possible font sniffing method?

There is an API to enumerate plugins: navigator.plugins returns them into an array. I'd like to be warned about sites asking that and I'd like to return an empty array and see if something breaks. Better: tell me which plugin you need and why and I'll decide which one to let you know I have.

>How do you explain what "this site wants to know the list of installed fonts/plugins" means to the person using the browser?

Do the fonts on the site look wrong? Click here to correct (warning: <a href='explanation'>showing correct fonts may have privacy implications</a>).

What privacy implications? Your dialog has either annoyed me or gotten me vaguely scared of something, but I still don't know whether I should click yes or no.

Message appears at the top of the screen where it can be safely ignored. Click on the link to see what the privacy implications are.

Not difficult at all... unless you're being intentionally obtuse.

In Europe we have "This site uses cookies" popups. Not browser based, not asking for permission, but, universally they are annoying. It depends on your definition of 'sensitive data' i guess.

I mean, i have noticed the HN crowd to be trigger happy against paywall popups, imagine if you prevent them from getting to their favorite site every time.

The worst is not that they are annoying, it is that I have to give explicit permission to use cookies. I am OK with them using cookies, but I don't want to give them permission. I'd like to leave it a grey area.

They can use cookies all day long. If I don't grant them permission, then I can accept it, but complain about it. But if I click "allow", I feel that they take away my moral right to complain about it.

It's like being pat down / searched by the police. It is annoying, but I'd let it happen, because they probably have good reasons to do it - but I'd still be grumpy about it, and if it happens too often, I'd protest. But if I had to sign a waiver that gave them explicit permission to do so, then I'd have a much worse standing if I wanted to complain.

Does anyone understand what I mean?

I do the same. It's definitely irrational, but I often even leave a site, if it wants me to click "Agree" on some (Cookie-)dialog, before I can use the site.

I've also come to hate "truste", whatever company/CDN/thing that is, solely because their Cookie-dialog is one of those offenders that I see the most.

Yes , its like the transgender bathroom debate in a way ;)

The whole cookie popup thing is so stupid: a user already has the ability to instruct his browser to allow or deny cookies. Adding a bit of HTML and JavaScript regarding cookies is a layering violation.

I like the cookie popups that have a "I don't want cookies" button that only works when cookies are enabled.

I use a browser extension that gets rid of the vast majority of them.

Cookies are the wrong target, and the EU knows it. It's a matter of wanting to be seen doing something, rather than actually doing something useful. Their grasp on technology is ridiculously poor.

As someone who lives in Europe and faced hundreds of them, I've developed total blindness to them, so they hardly have any value at all. Good intentions, poor implementation.

Sort of a different thing, though, as it's not "Allow Cookies?", but rather "We use Cookies. Stop using our service, if you don't like that.".

How is the law in your country for cookie handling? In Norway we have no laws actually requiring web sites to have popups like that but they still use them for some reason.

The law he's talking about is enforced by the EU, so it's the same across most of Europe. And the website-owners probably just didn't put an exception in for Norway...

Because they might get EU visitors

I think the solution is not to ask the user for permission but to automatically create an anonymous sandbox that does what the site requests — except that sensitive information is faked or reduced.

And if a web application is complex and has weird dependencies, it should be necessary to “install” a sandbox ONCE with those dependencies (e.g. needs plug-ins X and Y), and at that time the user can see everything that is being exposed and essentially only has to approve once.

It will not work to constantly ask the user. They will just opt-out, or worse opt-in without really knowing or caring what they have done. And usually, they will not know where to go to change their mind later (probably buried in preferences somewhere).

It doesn't seem technically difficult. Many browsers are native applications and can request hardware information the same way that tools like speccy can.

This isn't exactly what you're asking, but I'd say a lot of sites don't or shouldn't need that information anyway. If you're building a web app that requires battery status or processor architecture or what have you, is a web app really the best format for your program?

> Are there some technicalities that make this a particularly hard problem?

No but there are major user experience problems with it. Today the web "just works". You go to a site, you read and do stuff with it, you leave. Now imagine going to one of your favorite sites that tracks this after changing the security model. You're going to get multiple pop ups. Pop ups that regular users are not going to understand. It's easy to understand if it's asking for your location but have you ever tried explaining what plugins are to non techies? Absolutely painful.

There is usefulness to this data and there are abuses. Gotta take the good with the bad. Yeah this data can make them mostly identifiable but it's not perfect and unlikely good enough to be admissable in the court system.

If you really wanted to protect this data then in my opinion access would need to be removed completely. But this could break many things.

I think the solution would not be fine-grained permissions, but very coarse grained. There would be two HTML6 profiles: Document and Application.

Application can do everything a JS app can do now. Examples include Gmail, Dropbox etc.. The browser would clearly show that it is an application, and to access platform APIs it would have to be "activated" / "run" (just click OK). The browser might ask for additional permissions if it tries to do something egregious (access camera, or, what's not possible today, open sockets etc.).

Documents can only use very limited javascript (if at all) for presentation purposes (like DHTML of the 2000s, or Google AMP). A lot of stuff will not be possible, like advanced tracking, silly stuff like access to light sensor / vibration, etc.. Examples of this would be newspapers, blogs, etc..

I'm sure the ad companies (and therefore the online news networks) will have no problem with this.

This suggestion is completely orthogonal to what ad companies want or need.

For example, you could include a unique identifying user ID with each request (for either profile) - this would actually make it easier and more explicit to track users, instead of trying to create an identifier out of 10 sources (cookies, fonts, localstorage, ...) in JS. You would probably also allow HTTP cookies in such a profile.

Incidentally, the push towards fast HTML subsets (Google AMP and Facebook Instant Articles) comes exactly from these big advertising / content companies! I think it is because it allows them more control over how ads are included in pages, and it allows them to keep users in their apps for longer.

No need to ask all ad companies. The biggest ad company in the world owns the most widely used browser. They can single-handedly prevent something like this from being standardized.

There's no need to standardize here? This could be implemented purely on client side.

In addition to the many replies observing that it would just confuse the user, I would also add that it wouldn't do anything.

I don't worry about the battery API that you are probably posting in response to, because there are already a crapton of ways to track users. Here's a list of ways to "tag" a user with something cookie-like: http://arctic.org/~dean/tracking-without-cookies.html There's also a lot of ways to statistically analyze users even without tagging them, if you put your mind to it.

The horses have left the barn, had lots of horse babies together, and grown into a stampeding herd. Bit late to try to close the door.

Because most users don't want that level of granularity. Do you really want to have to give every single site you touch permission to know your screen resolution, viewport, browser type, browser version, js enabled/disabled, fonts available, whether jquery/etc. are cached, etc.

There are so many pieces of data like those that you don't even think about which combine to make you uniquely identifiable. Many of them the site is going to have to know for the page to even render properly. Do you really want to have to give permissions for all of them for every host name your browser contacts?

Even if your answer is yes, for the vast majority of people the answer is no.

> Many of them the site is going to have to know for the page to even render properly

Which illustrates that something has gone very wrong in the logical division between "the site" and "the user agent".

Technically, the site has no business asking about screen resolution, cache status or installed fonts etc That is information which should be relevant only to the user agent in constructing the view for the user.

But browsers do not make a distinction between rendering-domain data and those data which do validly dictate what functionality the site provides to the user agent. Except for location, which is somehow perceived as sacred.

Which brings us back to the original question; why are all the data elements thrown into the general Javascript bucket and made fair game for grabbing, except location data? Why not draw the boundary around data that should be private to the user agent? The user should never be interrupted by a prompt to share a list install fonts because, frankly, that information should never be divulged.

But I think it would be the right way to do it. Maybe you could have some permissive settings by default, but it would be good to have an easy way to let you pick what you want to communicate and to whom.

For example I don't think such a popup for battery level would be a problem. Very few websites legitimately need it, and for those who don't requesting it is a red flag.

Given the assorted methods of sniffing a fingerprint, and the tiny subset of people who even go into options to seek privacy settings, blocking this would probably be a good identifier in its own right. Add locale, IP, even if on VPN, and you've probably near uniquely identified yourself.

I don't have an answer, short of a plugin that sends bland global top 5 answers to any such request instead of legit data. I can forsee that breaking some sites though.

I would really like to see a decent solution to this though, but I think it is far too late.

Isn't Tor a fairly good solution? They have thousands (at least) of users all using identical user agents.

Meta: Is the browser my client, or someone else's?

Increasingly, while I use it, it feels like it is the latter.

As my friend is fond of saying, "No bueno."

That's the key issue.

Welcome to the War on General Purpose Computing.

http://boingboing.net/2012/08/23/civilwar.html

We do want to take an approach like this in gngr(1). We already have fine-grained permission control in the Request Manager (inspired by uMatrix, nee httpSwitchBoard).

But your question is about even more finer control. Some thoughts:

* I believe some of these APIs shouldn't be implemented at all, or should have very limited precision. Eg, Battery Status need not be implemented at all, or if implemented, should return just two values: [high, low].

* In our Request Manager, we could add an extra column for advanced APIs. This would include, for example, Canvas, WebRTC, etc.

* @captainmuon's idea of having two different profiles (document/app) is interesting. Though the choice of profile should be on client side. The default should be conservative (document) and the user should get to choose if a site should be promoted to app or not.

[1] : https://github.com/uprootlabs/gngr

>Are there some technicalities that make this a particularly hard problem?

I think the hard problem (probably unsolvable) is that the browser is allowed to exfiltrate the collected data.

I assume this was prompted by the battery status information leak. That sort of behaviour is likely illegal under EU privacy regulations without explicit concent.

In firefox, you can disable this nasty behaviour by editing the "dom.battery.enabled" setting in about:config. IMO this should be a MUCH more obvious setting in the settings menu, along with any other information that can be accessed without concent.

There's a lot of things that a site can access that can be personally identifiable.

Whilst it has good intentions if you think back to UAC in Windows Vista. People just clicked allow for everything without reading after getting tired of the number of requests.

I think there may be demand for a web browser plugin to have this functionality similar to how Ghostery, NoScript etc. have keen users.

Prepend an "Ask HN: "

They will probably start asking for more things (or just blocking or anonymizing, like the battery level information leak)

But yeah, you don't want to overwhelm the user with popups, that will just make them click ok whenever one appears

Popup fatigue.

Chrome is made by people who want that information. Mozilla is heavily funded by people who want that information. Safari is made by people who want to keep things as 'simple' as possible. Internet Explorer is made by idiots.

I don't use IE, but think the people behind it are far from idiots. Also Edge is actually a nice browser, I just don't use Windows.

Agreed. Personalization is the promise, monetization is the priority.

Blend into the crowd: https://addons.mozilla.org/en-US/firefox/addon/blender-1/

Reply on news.ycombinator.com