Closed Bug 625238 Opened 14 years ago Closed 14 years ago

Add device info to User-Agent

Categories

(Firefox for Android Graveyard :: General, defect, P2)

Product:
Firefox for Android Graveyard
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ama, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: 

As a web developer I would really like to see device info beeing added to the user agent. Now it says, "Android" but what we mobile developers need is some more device info. Why?

- We have advertisers wanting to target a specific device
- We may serve different content to a HTC Desire and a Samsung Galaxy Tab
- We have device statistics
- We scale images, adapt content, serve video and change font size depending on the device and screensize. 

All other major mobile browsers does this (including Opera that add a header that contain the original UA) so I don't see a reason why it should not be added in Firefox? 

Reproducible: Always
This will probably not address all your use cases, but using CSS media queries allows you to adapt your content to the device screen characteristics sanely without device ID. This is what the fennec front-end UI uses to switch from portrait to landscape mode for instance.
Blocks: 71569
Sounds similar to bug 549578.
Adding Doug
Priority: -- → P2
For what its worth, we had in the past tried to add device information to the UA string.  When we did, it had undesired consequences.  For example, on the Nokia n900 and n810 series devices, the word "nokia" as a string in the UA typically resulted in us getting back content that was for the nokia candybar phones.

I worry about adding more attributes to the UA will result in similar parse failures.

Also, most of the use cases adds more of a footprint for panopticlick-like targeting.  Not very interesting to me or our users (at least according to the studies I have seen regarding behavioral advertising.  Maybe this sort of information should be provided to websites using something like system info?  (http://www.w3.org/TR/2010/WD-system-info-api-20100202/)

Dan, do you have any insight into this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think adding more specific info to the UA is the way to go here. We need some better way to reveal this information without sending very specific information with each HTTP request. The stock Webkit browser on my Incredible is successfully identified by Facebook, without that information appearing in the UA; how are they doing that?
(In reply to comment #6)
> I don't think adding more specific info to the UA is the way to go here. We
> need some better way to reveal this information without sending very specific
> information with each HTTP request. The stock Webkit browser on my Incredible
> is successfully identified by Facebook, without that information appearing in
> the UA; how are they doing that?

The stock WebKit browser *does* send a device identifier in the UA header.  For example:

Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us; Nexus One Build/ERE27) AppleWebkit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
I'd rather look into using HTTP headers to send extra information and stop adding stuff to the UA.
(In reply to comment #7)
> The stock WebKit browser *does* send a device identifier in the UA header.  For
> example:

Indeed you're right, the cryptic ADR6300 is the device string in my case.
adding a new header is non-trival in terms of figuring out to send and setting expectations of recipients. I don't really like Wurfl or uaprof.

(strawman) Is something like

X-Device-Hint : Nexus One Build/ERE27

Good enough?
(In reply to comment #10)
> adding a new header is non-trival in terms of figuring out to send and setting
> expectations of recipients. I don't really like Wurfl or uaprof.
> 
> (strawman) Is something like
> 
> X-Device-Hint : Nexus One Build/ERE27
> 
> Good enough?

MS has a few mobile headers:
http://msdn.microsoft.com/en-us/library/bb159684.aspx

But I have to wonder if any of this is really worth the effort.
(In reply to comment #11)
> (In reply to comment #10)
> > adding a new header is non-trival in terms of figuring out to send and setting
> > expectations of recipients. I don't really like Wurfl or uaprof.

For your info, Facebook is using WURFL.

> > 
> > (strawman) Is something like
> > 
> > X-Device-Hint : Nexus One Build/ERE27
> > 
> > Good enough?
> 
> MS has a few mobile headers:
> http://msdn.microsoft.com/en-us/library/bb159684.aspx
> 
> But I have to wonder if any of this is really worth the effort.

An alternative is to do like Opera and MS, I do not beleive that will break any existing site, but you still give us web developers a way to find out what device it is. The Opera header:

X-OperaMini-Phone-UA: SonyEricssonK750i/R1AA Browser/SEMC-Browser/4.2 Profile/MIDP-2.0 Configuration/CLDC-1.1

See also: http://dev.opera.com/articles/view/opera-mini-request-headers/

So:
X-Firefox-Phone-UA: <original UA>
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > adding a new header is non-trival in terms of figuring out to send and setting
> > > expectations of recipients. I don't really like Wurfl or uaprof.
> 
> For your info, Facebook is using WURFL.
> 
> > > 
> > > (strawman) Is something like
> > > 
> > > X-Device-Hint : Nexus One Build/ERE27
> > > 
> > > Good enough?
> > 
> > MS has a few mobile headers:
> > http://msdn.microsoft.com/en-us/library/bb159684.aspx
> > 
> > But I have to wonder if any of this is really worth the effort.
> 
> An alternative is to do like Opera and MS, I do not beleive that will break any
> existing site, but you still give us web developers a way to find out what
> device it is. The Opera header:
> 
> X-OperaMini-Phone-UA: SonyEricssonK750i/R1AA Browser/SEMC-Browser/4.2
> Profile/MIDP-2.0 Configuration/CLDC-1.1
> 
> See also: http://dev.opera.com/articles/view/opera-mini-request-headers/
> 
> So:
> X-Firefox-Phone-UA: <original UA>

This would be best and optimal scenario for most developers. As we all search the user-agent string as a default instead of other values. I would hate to have to detect multiple places like another header value for user-agents. Look at the hell we web-devs go through when having to do things like rounded corners on css. Should be centralized........
I have decided that we do not want to expose this additional information at all, either as a change to the UA string or as an additional header.

* If websites need to make per-device changes based on the features of that device (keyboard, multi-touch, whatever), we should expose DOM feature detection.
* We do not wish to allow websites to target specific android devices differently "just because": it will lead to lots of specific device detection which will end up with a poorer web overall.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
FWIW - I just had someone from a mobile web design/dev shop come up to me at web2.0 expo and ask us to please consider this -- that they love firefox, but still have to recommend other browsers to people because they can't adapt their sites for different screen sizes, etc., because of it.
(In reply to comment #15)
> FWIW - I just had someone from a mobile web design/dev shop come up to me at
> web2.0 expo and ask us to please consider this -- that they love firefox, but
> still have to recommend other browsers to people because they can't adapt their
> sites for different screen sizes, etc., because of it.

CSS media queries can be used for this, client-side
I'm working for a content site that needs to target as many different devices as possible, we're using a WURFL-based library. 

Now, mobile devices vary in many significant ways - using that library (which does need to detect what device it is targeting) helps us deliver device adapted content. 

Deliberately withholding significant and useful information from the UA string to prevent WURFL from working because of your beliefs about how websites will end up doing things is IMHO wrong. 

Now you code, and you own the project. But as far as I can tell you are still wrong.
Benjamin: I highly recommend that this issue is reconsidered. I understand that most issues can be resolved through the dom by detecting screen sizes and such but let me bring you to the world of content providers. Content providers that have web storefronts for mobile, display available content depending on the detected device. This cannot be done through a simple screensize detection. We as web developers don't have access to the MSIDN like applications developers do and we're bound to relying on the device string of the user-agent. This has been the de-facto standard since the early WAP browsers days. Even the default android browser shows the device name in the user-agent string. 

Please think about this one more time and hope you consider modifying the Status: "Resolved, Wont Fix"

Thanks
-James
I emailed the person I met at web2.0;  here is his response (with permission!):

For background, our product (http://deviceatlas.com) and others like it (e.g. WURFL) are used by countless sites all over the world (including Facebook) to modify pages on the server side before sending to the client. To to this, they use the browser UA string to look up the properties of the device. This technique is used by every major mobile site I know i.e. the device adaptation is done server side rather than assuming that things can be worked out on the client 

I think I understand the Mozilla position here but I would make the case that it reflects lack of experience in the mobile world. For about 12 years mobile browsers have been very careful to send device-identifying information out  with every request, for good reason. This is considered so important that there is even a standard way to point to a property set for the device (UAProf) in the HTTP headers.

There are a number of reasons why I think a device-identifying (rather than just browser identifying) UA is important:
It lets you tailor image sizes to the screen dimensions on the server side, saving b/w and client-side resizing overhead
It lets you decide what content formats can be served to the device. This is something that the browser does not necessarily control e.g. a content provider may want to provide an app download link if you're on an Android 2.2 device, but not other devices (even though they're running Firefox) because their app doesn't support other versions of the HW or OS. 
Client-side detection/adaptation is of course possible, and getting more popular, but not everyone wants to do this—for some people server-side adaption is easier and more comfortable. Making the UA string generic precludes this option. Server-side adaptation is arguably also more efficient because you only send what's needed. 
Not all HTTP interactions allow access to the DOM or JS in the browser. As an example, mobile ad companies like to serve ad images tailored to the device (both in terms of content of the ad and the ad dimensions). In this use case the server serving up the ad image typically is not the one generating the page, and hence has no access to information in the DOM or JS. Many ad providers create images saying e.g. "Get apps for your XX device" where XX is filed out based on the UA string. 
Analytics is a very important use case in mobile—people like to know what devices are hitting their site for a number of reasons. Again, using a generic UA prevents this.

I mentioned that client side detection and adaptation (using JS) is getting more important (progressive enhancement is one label for this) but progressive enhancement only works if you can assume good JS support. Since this is generally not the case (apart from smartphones) many (almost all, AFAIK) mobile web sites use 100% server side adaptation because this works on *all* devices (Firefox mobile aside, that is) as long as your device database knows the device, and they generally do.

These are just a few reasons off the top of my head as I sit in my hotel lobby. Do they make sense to you? As a long-time FF uses (since Phoenix) I think it's really important that FF Mobile gets this right. As it stands, FF Mobile is going to get served lowest common denominator pages from many current mobile web sites simply because they use 100% server-side adaptation and can't tell anything about the device in question. 

I welcome your thoughts on this, and thanks for listening!
Hi All,

Here is my viewpoint as a Mozilla employee (my own opinion):

Using server-side user agent sniffing is not the preferred method of adapting layout and content to mobile devices. We much prefer using CSS media queries to adapt layout, showing and hiding content dependent on screen size or screen orientation. Media queries in CSS can also be used to pull the "optimal" image sizes.

Another argument for adding UA (or HTTP header) information is limiting the amount of resources downloaded from the server. For example, don't download the big images or JS libraries for mobile browsers. A very common solution to that problem is separate URLs for desktop and mobile web content. Many large web properties are using touch.*.com or m.*.com or mobile.*.com URLs for mobile browsers. You even have enough information in the current UA to redirect to a mobile specific URL and let CSS media queries handle the rest.

IMO, you should also allow mobile users to access the standard (or desktop) version of the webite if they desire.

I think you will find Mozilla is pretty solidly against adding UA or HTTP header data. You will need to provide very solid use case examples of why such changes are needed. As a recently released mobile browser, we are currently negatively affected by bad UA sniffing and we really don't want the practice to continue.

Just telling us "we need it" is not enough. We think you don't.
Mark,

This is agreeable. However, the solution being provided is to tell the development to switch to what mozilla wants. Clearly, all other browsers that I've tested supports the device string in the user-agent. I hate having to compare mozilla to ie but this is why so many web-developers hate ie. As developers we wish to have as much flexibility and compatabiilty. FF moving towards straying away from the common mobile browser standard is really forcing developers to make mobile sites differently. 

Even if mozilla wished that mobile sites are the actual desktop sites, and I question that it displays it properly. However, there are many other people out there that wished to have a separate mobile experience. 

With the mobile boom and the the appstore, many new concepts have come into play into the mobile sites. Where mobile sites, almost have the same feel as a mobile application. This is just one example but the larger issue for me is that, I cater applications and specific content, dependent on the specific device. Due to the large number of devices out in the market right now, applications many times are built specifically per device or per device family. Being able to detect the user's device is crucial.

(In reply to comment #20)
> Hi All,
> 
> Here is my viewpoint as a Mozilla employee (my own opinion):
> 
> Using server-side user agent sniffing is not the preferred method of adapting
> layout and content to mobile devices. We much prefer using CSS media queries to
> adapt layout, showing and hiding content dependent on screen size or screen
> orientation. Media queries in CSS can also be used to pull the "optimal" image
> sizes.
> 
> Another argument for adding UA (or HTTP header) information is limiting the
> amount of resources downloaded from the server. For example, don't download the
> big images or JS libraries for mobile browsers. A very common solution to that
> problem is separate URLs for desktop and mobile web content. Many large web
> properties are using touch.*.com or m.*.com or mobile.*.com URLs for mobile
> browsers. You even have enough information in the current UA to redirect to a
> mobile specific URL and let CSS media queries handle the rest.
> 
> IMO, you should also allow mobile users to access the standard (or desktop)
> version of the webite if they desire.
> 
> I think you will find Mozilla is pretty solidly against adding UA or HTTP
> header data. You will need to provide very solid use case examples of why such
> changes are needed. As a recently released mobile browser, we are currently
> negatively affected by bad UA sniffing and we really don't want the practice to
> continue.
> 
> Just telling us "we need it" is not enough. We think you don't.
Hi Benjamin,

I hope you will reconsider and identify Firefox Mobile in the User Agent. I run a forum and I have written a script that shows which browser my logged in members are using. This is very helpful in that I can see how popular one browser is over others and can see trends based on that information over time. It's also very useful to know what browser a member is using so that I can help troubleshoot usage problems.

Not having a way to identify Firefox Mobile will most certainly alienate those early adopters which Firefox Mobile really needs at this time.

Thank you for your consideration.
Mark,

I disagree with your viewpoint that user-agent sniffing is not the preferred method of adapting layout and content to mobile devices. I would say it is the preferred method. I think it is a de facto standard. But hey, I could be wrong... but is one of the most popular mobile sites in the world wrong?

The new mobile facebook site(m.facebook.com) relies on device detection. I just tested it using firefox on a Nexus One. And the result was pretty poor. The site works like a charm with the standard Android browser since facebook knows which device is accessing the site.

Read more about how facebook implemented the new site here: http://www.facebook.com/note.php?note_id=10150122073713920

So... don't you want Firefox to deliver the best mobile experience for facebook users? ;)


(In reply to comment #20)
> Hi All,
> 
> Here is my viewpoint as a Mozilla employee (my own opinion):
> 
> Using server-side user agent sniffing is not the preferred method of adapting
> layout and content to mobile devices. We much prefer using CSS media queries to
> adapt layout, showing and hiding content dependent on screen size or screen
> orientation. Media queries in CSS can also be used to pull the "optimal" image
> sizes.
> 
> Another argument for adding UA (or HTTP header) information is limiting the
> amount of resources downloaded from the server. For example, don't download the
> big images or JS libraries for mobile browsers. A very common solution to that
> problem is separate URLs for desktop and mobile web content. Many large web
> properties are using touch.*.com or m.*.com or mobile.*.com URLs for mobile
> browsers. You even have enough information in the current UA to redirect to a
> mobile specific URL and let CSS media queries handle the rest.
> 
> IMO, you should also allow mobile users to access the standard (or desktop)
> version of the webite if they desire.
> 
> I think you will find Mozilla is pretty solidly against adding UA or HTTP
> header data. You will need to provide very solid use case examples of why such
> changes are needed. As a recently released mobile browser, we are currently
> negatively affected by bad UA sniffing and we really don't want the practice to
> continue.
> 
> Just telling us "we need it" is not enough. We think you don't.
This is a bug tracker, for discussion please use the newsgroup. There you can debate whether Mozilla should go the pragmatic or the idealistic route on this issue.
Have a look around you and pick your 5 best "real" web solutions for mobile. I think many of you would choose some of these: Facebook, Google, New York Times, Flickr. Do they use server side adaption? Yes. Do they use feature detection: Probably. And that is exactly how the world works now. We rely on both these techniques.

"Progressive enhancement" probably works for your blog and your fancy test site, but I have been working on a large scale video site project that uses "progressive enhancement". We very quickly realised that we needed two things: image scaling and device detection for serving the devices the correct video. Sony Ericsson X10 mini (240x320 screen) and Samsung galaxy tab (600x1024) should not be given the same images and videos. This is a real life example. For firefox mobile we would have to choose something and probably end up with 320 images and video.

And we have more and more Android devices that is coming out that is not a phone, for example Samsung with it's WiFi devices. Should we give them a clickable phonenumber or ask them to send us an SMS? No. Real life example.

We have logs and analytics systems that generate reports. One problem with these logs is that the old IE only has a generic UA and we cannot determine the device and give our customers a complete "top devices" list. Now FF mobile has joined this club. IE has listened an learned this with Windows Phone 7. Nokia also tried having a generic UA for a short period of time. They also listened the the developers.

And most of the web sites we build serve ads. We have advetisers that serve ads for Apps. They need to know screensize and Android version. Most mobile ads systems cannot use feature detection.

I would have thought you would look more at the mobile world around you before you decide to close this issue. Look at one of the most successfull mobile browsers out there: Opera Mobile/Mini. Also look at the Netfront browser for Android. 

We all think Firefox is a great browser and that's why we are asking you to change this. The mobile web is very extremly fragmented, but we have tools an techniques to deal with that and server side detection is one of them. I would have expected that Mozilla would listened to the developers.
****

Please read comment 24 BEFORE posting anything further into this bug.

****
Here is a newsgroup thread for discussion of this issue:

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/43d566ca1333234e
Bug 671634 has landed in direct contradiction with the WONTFIX decision here.
(In reply to Henri Sivonen (:hsivonen) from comment #29)
> Bug 671634 has landed in direct contradiction with the WONTFIX decision here.

No, this bug is asking for device specific information such as "HTC Nexus One" in the UA String. bug 671634 adds "Tablet" to the UA strings of tablets, that's quite different.
(In reply to Brad Lassey [:blassey] from comment #30)
> (In reply to Henri Sivonen (:hsivonen) from comment #29)
> > Bug 671634 has landed in direct contradiction with the WONTFIX decision here.
> 
> No, this bug is asking for device specific information such as "HTC Nexus
> One" in the UA String. bug 671634 adds "Tablet" to the UA strings of
> tablets, that's quite different.

scratch that, bug 671634 does add the device specific name
(In reply to Brad Lassey [:blassey] from comment #31)
> (In reply to Brad Lassey [:blassey] from comment #30)
> > (In reply to Henri Sivonen (:hsivonen) from comment #29)
> > > Bug 671634 has landed in direct contradiction with the WONTFIX decision here.
> > 
> > No, this bug is asking for device specific information such as "HTC Nexus
> > One" in the UA String. bug 671634 adds "Tablet" to the UA strings of
> > tablets, that's quite different.
> 
> scratch that, bug 671634 does add the device specific name

And also didn't add "Tablet" for tablets.
(In reply to Henri Sivonen (:hsivonen) from comment #32)
> (In reply to Brad Lassey [:blassey] from comment #31)
> > (In reply to Brad Lassey [:blassey] from comment #30)
> > > (In reply to Henri Sivonen (:hsivonen) from comment #29)
> > > > Bug 671634 has landed in direct contradiction with the WONTFIX decision here.
> > > 
> > > No, this bug is asking for device specific information such as "HTC Nexus
> > > One" in the UA String. bug 671634 adds "Tablet" to the UA strings of
> > > tablets, that's quite different.
> > 
> > scratch that, bug 671634 does add the device specific name
> 
> And also didn't add "Tablet" for tablets.

Adding "Tablet" for tablets is not the intention. Firefox would be the only browser supporting such a flag. Adding more single-browser cruft is not the goal here.
(In reply to Mark Finkle (:mfinkle) from comment #33)
> Adding "Tablet" for tablets is not the intention. Firefox would be the only
> browser supporting such a flag.

(Going off-topic in this bug, but Opera Mobile says "Tablet" in the UA string when run on an Android tablet.)
You need to log in before you can comment on or make changes to this bug.