Closed Bug 799899 Opened 12 years ago Closed 12 years ago

Add Device-Stock-UA header

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

User Agent: Opera/9.80 (X11; Linux x86_64; Edition Next) Presto/2.12.388 Version/12.10 Steps to reproduce: Visit http://john.uat.phone.mobi using Firefox for Android Actual results: The logo image has been resized to the lowest usable value as no device specific information has been provided. (Compare with visiting site using default Android or Opera Mobile 12.1) Expected results: The 3rd party mobile user agent should include the additional HTTP header "Device-Stock-UA", as per the RFC below, to aid developers in the server-side adaption of content for consumption on mobile and deliver a better user experience to users. https://github.com/operasoftware/Device-Stock-UA-RFC/blob/master/draft-brown-http-device-stock-ua.txt
URL: http://john.uat.phone.mobi
OS: Linux → Android
Hardware: x86_64 → ARM
I don't know anything about the merits here, but "someone invented a header and wrote a draft RFC for it" is not enough reason to implement it.
The stock UA generally contains information that we have deliberately kept out of our HTTP headers for reasons including privacy/fingerprinting, and discouraging fragile browser-sniffing practices that harm competition by locking out newer or less common browsers. Implementing the Device-Stock-UA header would eliminate most of the benefits of those decisions.
Blocks: http-fingerprint
I believe that the lock-out argument might be weak in this case. In fact, reading the blog from comment #1 sounds like this might actually help fight lock-out. The concerns about privacy and fingerprinting remain still strong, though. the RFC even states: "This header field may reveal more information about the hardware or firmware of the device that can be used for tracking purposes." It is also interesting to note that the first paragraph in the section about possible uses refers to "web analytics". Adjusting content only comes after that.
This is similar to bug 625238. The decision there was that this hurts web compatibility.
(In reply to Matt Brubeck (:mbrubeck) from comment #3) > The stock UA generally contains information that we have deliberately kept > out of our HTTP headers for reasons including privacy/fingerprinting, and > discouraging fragile browser-sniffing practices that harm competition by > locking out newer or less common browsers. Implementing the Device-Stock-UA > header would eliminate most of the benefits of those decisions. I think this about sums up my thoughts on the matter.
I would disagree that including the device header would lead to a lockout for newer/less known browsers. In fact, I would argue that it would increase acceptance and compatibility as at present, for me as a developer that uses server-side content adaptation, when a 3rd party browser, such as Firefox Mobile or Opera Mobile are encountered, the minimum device capabilities must be assumed to guarantee the best user experience. By including device specific information in the header, it enables developers to deliver a richer experience to users of Firefox for Android. As a user, the alternative has been to download Addons such as Phoney and change the browsers useragent, thus hiding the user-agents identity from the site owner.
Consider the case of Firefox OS (aka Boot2Gecko), where Firefox *is* the stock browser. It has all the same capabilities of Firefox for Android. It would generally be incorrect for web sites to treat Firefox on B2G differently from Firefox on Android simply because of this proposed header. Firefox users will usually have the best experience if web sites treat Firefox the same on all platforms, rather than assuming it has certain capabilities based on the "stock browser" (which exists on only a few platforms). (We do have several ways to detect basic differences in form factor and other capabilities in a platform-independent way, such as CSS media queries, feature-testing, and the "Mobile" and "Tablet" tokens in the User-Agent header.)
I think this proposal is wrong-headed in several ways, only some of which have so far been touched on :-) It's 9.20pm here, but hopefully tomorrow I will find time to list some of the others. Gerv
OK. Everything people said above. Capability detection via putting a phone's model name into a big database is fundamentally broken, and will always disadvantage new players in the market. It's opposed to Mozilla's aim of user choice. We should be encouraging proper feature detection at runtime rather than proxy guesswork. Add to that the fingerprinting and privacy issues, the fact that it would lead to us having to send very different user-agent-identifying strings for browsers which should be treated identically (Firefox on B2G and Firefox on Android), and the increase in request size for every request, and this is pretty clearly a WONTFIX. This is not the direction Mozilla wants the web to go in. Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Gerv, Thanks for you response, however I'm disappointed that this bug has been set to WONTFIX so quickly. Surely a developers choice of technology is being restricted by forcing them to use client-side detection, even if it results in poor performance for the end user. There also seems to be an assumption that the DOM is always available to query, for image transcoding the UA is the only clue at the the requesting device's properties i.e. screensize, resolution. As for Boot2Gecko, I would be very surprised if vendors shipped handsets that lacked any device identifiers or X-WAP-PROFILE header. This will leave users who choose to download Firefox as a 3rd party browser on another platform at a disadvantage, as anyone using client-side detection would assume the lower common device properties. Paddy
Privacy/fingerprinting concerns ++ Implementing this change would also require privacy review.
Keywords: privacy-review-needed
Paddy: the bug has not been WONTFIXed quickly due to lack of consideration; the issues which this header raises have been debated many times in the Mozilla community, and again only quite recently. So we are fairly clear where we stand. If client-side detection results in poor performance, then clearly that's something which needs addressing. Our DOM and WebAPI teams would be very interested to hear about the use cases you have where the current detection methods are non-existent or don't meet your needs. Your image transcoding point presumably only applies to the first page load, of course. Gerv
-privacy-review-needed as this is wontfix
Keywords: privacy-review-needed
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.