Closed Bug 1141515 Opened 5 years ago Closed 5 years ago

Feature request: Detailed system information in user agent string


(Firefox :: General, enhancement)

Not set





(Reporter: gaborca, Unassigned)


(Keywords: feature)

User Agent: Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.12
Firefox for Android

Steps to reproduce:

In order to have a better user experience, browsers should send more detailed information about the environment in (a secondary) user agent string. For example:

	os-name="Apple iOS";
	browser-engine="WebKit 534.46.0"

Actual results:

All browsers should implement this feature. Additionally the information above should be accessible from javascript.

Expected results:

The original idea appeared on a hungarian developer website:
Severity: normal → enhancement
Component: Untriaged → Developer Tools
Keywords: feature
OS: Windows XP → All
Hardware: x86 → All
+1 :-)
I assume you're wanting this information always present in the user agent string, not just while debugging a site or something like that?
I think it would be best to this kind of information always present in the user agent string. Important pieces are: screen resolution, screen size in inches, DPI, connection quality (mobile/ethernet).
Flags: needinfo?(gaborca)
Okay, this is a request for the Firefox product overall then.  It doesn't really match the DevTools team's scope, since it affects all requests sent by any user, not just developers.

I'll move this back to Firefox :: Untriaged.  Gijs, maybe you know the correct component for something like this?
Component: Developer Tools → Untriaged
Flags: needinfo?(gijskruitbosch+bugs)

But really, this is better off as a spec suggestion. The user agent string isn't really the right place for this, though the navigator object could be (insofar as JS access is concerned). As such, I think you should probably email the relevant "specifications" whatwg list: . *However*, I would strongly advise you to research past work in this area, including but very much not limited to the links in my final paragraph.

For now, this is wontfix considering no spec work or clear idea about how/where this would go.

I have further CC'd gerv (who is buck-stopper when it comes to UA string things) in case he wants to comment.

Finally, I personally feel that the privacy trade-offs here are such that implementing this is a bad idea. It would make people a lot more trackable online, and that is a Bad Thing. See also earlier bug 625238 (of which this is arguably a duplicate). See also fingerprinting concerns in e.g. bug 572661. And finally, .
Closed: 5 years ago
Component: Untriaged → General
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → WONTFIX

I think the real issue here, that web developers can only guess the settings by serving web pages. We lack of information like screen resolution, screen size, browser engine (which we could use to infer the quality of js support), js enabled, cookie enabled, connection speed, and so on... It is harder to serve any webpages without knowing what the browser supports. These are the most basic things yet after 25 years they are not implemented in any of the browsers. What we can do is tricking with javascript if it is enabled, or asking the user to navigate to the mobile view, since the current user agent is an obfuscated text, which can be used only as a unique id by tracking users... ;-)
To begin with, most of these are entirely the wrong things to put in any device capabilities string. If we were to do anything like this, we'd want to put the actual data people seek, not things like os-name="Apple iOS" or device-model=iPhone, because if people try and map that information to capabilities, they'll screw it up.

Secondly, all of that info is a massive passive fingerprinting problem.

The important stuff in your list like screen size can be determined by JS. (Yes, it is Ok to write web pages which depend on JS. It's 2015.) If it can't, file bugs and we can consider each request on its merits.

A agree that os-name, etc... are not needed.

I don't agree that we should use js to detect browser capabilities and after that send back the same data which we could get in a header out of the box. (And I haven't talked about the js API differences by each of the browsers. Yes it is 2015, and developing js for browsers is still about writing polyfills, workarounds and adapters for each of the browsers.)
I think this discussion is muddied by the large list of things mentioned in comment 0.

Each item you might want to know has a different level of impact on user privacy and may warrant a different mechanism for exposing the information.  It's best to break this up into specific requests for exactly the data you are looking for.

Along with these points, it is unlikely that such a change would be made in Firefox without agreement from other browser vendors.  That's why discussing this in a standards groups is likely a better path forward.
I agree with you Ryan. Can you provide us a link or a contact where we can continue this discussion and maybe reach a conclusion and probably a standard as well?
The WHATWG list Gijs mentioned in comment 5 is good place I think.
According to various case studies about browser fingerprinting (e.g. User Agent Strings already supply enough pieces of information so that most users can be identified uniquely. Thatswhy privacy as argument is not so valid.

In comment 0 the list might be too verbose, the minimum set of useful data (additional to the current User Agent String) is:
network-type=limited; (e.g. cellular 3G where you pay for amounts of data transferred)
You need to log in before you can comment on or make changes to this bug.