In that bug, developers of mobile websites are asking that information
about the specific device being used be made available to websites via
the user agent. They are asking for this for the following reasons:
*
We [want to] have advertisers wanting to target a specific device
*
We may serve different content to a HTC Desire and a Samsung
Galaxy Tab
*
We [want to] have device statistics
*
We [want to] scale images, adapt content, serve video and change
font size depending on
the device and screensize.
* Content providers that have web storefronts for mobile, display
available content depending on the
detected device.
Technically, exposing the device via the UA string allows websites to
use frameworks such as WURFL (http://wurfl.sourceforge.net/) to provide
content customized for various devices. Apparently, the other major
mobile browsers (opera, opera mini, mobile safari, and IE for windows
phone) currently include this device information in the UA string.
I WONTFIXed the bug after consulting with dougt, because I do not
believe that serving content based on device capabilities is a solution
that we should be promoting, and that it will eventually lead to a very
bad/fragmented web for users.
* Device repositories are going to cater to devices with high market
share, leaving users with new, older, and less common devices out
in the dark.
* We want websites to work towards providing common content and
styling it using CSS media queries and other device-sensitive
styling information, so that existing content will automatically
be available to other device factors as they are developed.
* Websites which customize content based on device characteristics
are extremely bad for testing, especially on new devices.
* Exposing device information adds several bit of entropy for
unwanted user tracking.
I am now getting a lot of pushback in the bug from web developers who
are using WURFL or similar libraries and believe that we are just
shooting our users is the foot by not providing the information that
they want (need) to customize their site per-device.
Please discuss:
* What principles should we use to make this decision?
* Is there other information that we can expose which would solve
most author problems without being strictly device specific? e.g.
screen size, presence or absence of various features such as
keyboard or multi touch screen, etc.
* If we do expose additional information, how much of this
information should be made available via the client side (CSS
media queries, DOM data, etc), and how much needs to be made
available immediately to the server via the UA string and/or HTTP
headers?
--BDS
http://blog.mozilla.com/dwitte/2010/08/24/user-agent-string-changes-coming-in-firefox-4/
We have been reducing information in the UA string.
*
*
*
*
Please discuss:
--BDS
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Having the device and browser information in the UA allows me to be
able to help my forum members with troubleshooting questions. This is
an important requirement and unless the User Agent provides this
information like all the other mobile browsers do, I would have to
discourage users from using Firefox Mobile.
Thank you.
I feel... unmoved.
> We may serve different content to a HTC Desire and a Samsung
> Galaxy Tab
That's not a reason unless it's a disguised form of one of the other
reasons.
> We [want to] scale images, adapt content, serve video and change
> font size depending on
> the device and screensize.
That is a more reasonable request; but these things should be done
in-page, not server-side, and should be based on device-independent
values like screen size.
> I WONTFIXed the bug after consulting with dougt, because I do not
> believe that serving content based on device capabilities is a solution
> that we should be promoting, and that it will eventually lead to a very
> bad/fragmented web for users.
I think you did the right thing.
> * What principles should we use to make this decision?
Exactly the ones you used - what best aligns with our mission to have
one, open web across all access methods?
> * Is there other information that we can expose which would solve
> most author problems without being strictly device specific? e.g.
> screen size, presence or absence of various features such as
> keyboard or multi touch screen, etc.
A complete list of "etc" might help the debate. What features are we
considering exposing?
Screen size can change a lot - if the user rotates, or (on desktop) if
they resize the window. Content has to cope with that dynamically, not
take some cheating server-side best guess shortcut. And you can get this
through the DOM anyway.
Keyboard is irrelevant. If there were devices with no method of text
input whatsoever, we might want to indicate that - but given that those
devices would be unable to interact with much of the existing web, I
doubt they will ever appear.
I can imagine serving a very different UI to multi-touch (or rather,
multi-pointer) screens...
> * If we do expose additional information, how much of this
> information should be made available via the client side (CSS
> media queries, DOM data, etc), and how much needs to be made
> available immediately to the server via the UA string and/or HTTP
> headers?
The privacy point is a good one. UAs can, at least in theory, detect if
their interfaces are being strip-mined for identifying data. But if you
send it to the server, you have no idea what they are doing with it. So
I'd say that someone would need to make a very, very good case to put
something in the UA string.
Gerv
Thank you for your comments. Discovering more information about your user's devices via the UA string so that you can troubleshot problems as a moderator is an interesting use case. What specific bits of information do you actually need to troubleshoot the issues you are seeing?
We tend to think that adding more information to the UA continues to fragment the web. We also tend to think that it is a potential privacy leak (search for Panopticlick).
Doug
Hi Benjamin,
Thank you.
_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Cheers,
Shawn
I would guess that they would like to distinguish between phones and
tablets. This seems the most compelling of the arguments (having used
an iphone and an ipad, they do feel different and require different
UIs). I suspect detecting screen size would work here.
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
Both screen size in pixels and inches (or dpis) would be useful.
Mike
Cheers,
Shawn
I read the abstract, and I don't think so. I believe one would want to
create quite different apps based on the form factor (think games, not
web pages), not just have different CSS. However, I know very little
here, so I can't argue definitively.
I tend to think that it's "one web". I don't think that we should advocate that people write a game or a website so that it only works on one phone or one screen size, or only if it supports a web content feature, like offline-storage.
----- Original Message -----
From: "Paul Biggar" <pbi...@mozilla.com>
To: "Shawn Wilsher" <sdw...@mozilla.com>
Cc: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 10:22:59 AM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
I think very "different apps" could be handled by different URLs. Why
have one URL try to do everything? We see major web properties using
different URLs for mobile version of their websites.
Web clients can also delay load chunks of content and JS based on
screen size. CSS media queries can be used to auto-request the right-
sized images as well.
We have a bug on exposing media queries to JavaScript as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=542058
I have about a quarter of a patch for this in my tree; I've been
meaning to write the rest.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
You said the Operating System and Browser type will be included in the
User Agent. Will the browser type differentiate between the Firefox
and Firefox Mobile?
Thank you.
Great in that case I'm happy. Sorry I misunderstood the original post
as implying that the User Agent would only show Firefox and not
distinguish between the Firefox and Firefox Mobile.
Thank you.
And let me ask you a simple question. Would it be ok for iPhone and
iPad to have the same UA? (I think you know the answer)
And then have a look at Android. We have small screen devices (240px)
and tablets up to 1024px. You have Blackberry Playbook Tablet that is
going to run Android. Google TV has Android. Android is even going to
be used in cars. They would run the same browser but the context is
completely different. The world is fragmented. Taking deviceinfo out
of the UA is not going to make the world less fragmented, but more
fragmented because you will be the only browser that does this.
Device != Browser
regards
Anders / @amaMobile
> We have a bug on exposing media queries to JavaScript as well:
> https://bugzilla.mozilla.org/show_bug.cgi?id=542058
>
> I have about a quarter of a patch for this in my tree; I've been
> meaning to write the rest.
>
Please! :-)
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Just like the exact version number, this should not be in the UA but in
a JS object that is only exposed after a geolocation-style prompt to the
user, IMHO. Privacy matters.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
What specifically are you interested in? Just the h/w of the screen? It is hard for me to tell what you are asking for.
Doug
----- Original Message -----
From: "anders" <anders.m...@gmail.com>
To: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 3:16:48 PM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
Device != Browser
regards
Anders / @amaMobile
see the w3c dap systeminfo draft. probably is exactly what you are interested in.
----- Original Message -----
From: "Robert Kaiser" <ka...@kairo.at>
To: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 3:36:17 PM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
Robert Kaiser
The Web developers want to sniff for the device type. I thought that
the general philosophy within Mozilla was to discourage sniffing. This
is a good philosophy because Web developers usually sniff incorrectly
(e.g., sniffing for "Firefox" when they should instead sniff for "Gecko").
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
- Video capabilites of the device (video codec, bitrate, aspect ratio,
audio codec, streaming protocol (http or rtsp)
- Our advertisers need to serve correct ads to the device (this could
be based on screensize, android version, hardware properties, or just
a specific device. There are for instance some apps tailored for
Android tablets that advertisers want to market.
- Our advertisers and site owners need to know if the user can sms or
call with the device (not all devices are phones)
- I need to know if it's a touch device, clickwheel or stylus
(different interaction model)
- I need to compress images serverside to send as few bytes as
possible over the wire
And this is just me, Ask around and you will probably get more
practical examples.
Look at how Facebook is approaching this (written yesterday)
http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
There is no way they could rely on "progressive enhancement" and
feature detection to build that site. In 5 years? Mayby, but not now.
-Anders / @amaMobile
> dev-platf...@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-platform
are you looking for something like "the device id", or a listing of each of these features in various http headers?
Doug,
-Anders / @amaMobile
_______________________________________________
> - Video capabilites of the device (video codec, bitrate, aspect ratio,
> audio codec, streaming protocol (http or rtsp)
>
HTML5 video deals with content negotiation.
- Our advertisers need to serve correct ads to the device (this could
> be based on screensize, android version, hardware properties, or just
> a specific device. There are for instance some apps tailored for
> Android tablets that advertisers want to market.
>
I'm sure advertisers would like to know everything about the user, but we
aren't going to tell them.
- Our advertisers and site owners need to know if the user can sms or
> call with the device (not all devices are phones)
>
Ditto. We do need an API to let the user initiate a call or SMS from Web
content, though.
> - I need to know if it's a touch device, clickwheel or stylus
> (different interaction model)
>
We need new DOM API to detect what kind of events you can get.
> - I need to compress images serverside to send as few bytes as
> possible over the wire
>
How is that affected by the device? If it's about screen size or density,
CSS media queries cover that.
Look at how Facebook is approaching this (written yesterday)
>
> http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
>
That's a great example of how sniffing is likely to go wrong:
For example, on the latest WebKit based devices, like iPhone and Android, we
> use CSS3 and vendor-specific rules for display and animation as well as some
> of the new JavaScript APIs included in HTML5 for local caching and history
> management. For example, to animate out a deleted comment, all it takes is:
>
> .deletable.deleting { -webkit-transition: translateX(-200%); }
>
If they sniff for "Android" and serve -webkit-transition, that's going to
fail for any non-Webkit browser running on Android. That (sniffing for one
thing and using that to determine behavior for unrelated features) is
exactly the sort of bug we see all the time with UA sniffing, and it will
repeat with device sniffing.
A claim that media queries make server-side adaptation unnecessary is
extremely naive, if only for one logical reason: when I dispatch my
resources, how am I going to know that the browser supports media
queries at all if I don't even know what it is?
Other examples: should I be sending the highest resolution of my
images to every device hoping that the browser's CSS will resize them
down to size once (if ever) they get there? Should I send multiple
encodings of a single video to each browser in the hope it will be
able to pick the most suitable one and ignore the others? Should I
even be sending progressively enhancing JavaScript if I don't know
your browser supports it well? (Most mobile browsers still do not).
In all honesty, contemporary server-side recognition (WURFL,
DeviceAtlas etc) is probably far better than you're imagining - it's
not just looking for plain keywords with a broad brush... and the
quality of browser information keyed off these agent strings is
generally very high, fast, and accurate.
"Just telling us 'we need it' is not enough. We think you don't."
... is baffling, and insulting, logic in the bug report. http://phon.me/?p=44
says that one consolation might be your likely lack of traction. I
believe that this decision and arrogance won't help prove him wrong.
On the other hand, you could help the world imagine and build a rich,
responsive, beautiful and clever web which has escaped its homogenous
desktop tethering and document-centric assumptions and which you'll
have been instrumental in helping to bring to life. Given that you're
pretty much the only mobile browser vendor left that doesn't have an
interest in native applications (and therefore no tactical reasons for
throttling your browser's development accordingly), I'd been betting
on you being the ones that would re-seize this vision.
Suffice to say, this isn't a good start.
James
Are you? I recommend http://www.mozilla.org/about/ (watch the video).
> I presume it would cost next to nothing to implement this
It would not cost us much in the way of work, no. It would cost our
users something, though, and we would feel that we are selling them out.
> in the same way that every other browser on the planet ever has
No desktop browser I'm aware of being used in any quantity in recent
memory has sent the sort of information that is being asked for here.
If you have data to the contrary, I would love to see it.
> and that the HTTP spec clearly suggests you should.
Oh, c'mon. If you want to get all spec-pedantic here, what the spec
"suggests" (RFC 2616 section 3.8, which is referenced from section 14.43
as the normative section for what goes in this field) is that
applications "identify themselves by software name and version".
Now maybe you're making the argument that in this case the exact
identity of the piece of hardware used is a "subproduct which forms a
significant part of the user agent"? I think that's a bit of a stretch,
personally.
One other note: the RFC in question dates back to 1999 and assumes good
faith on the part of the server. It's been 12 years since then, and
this assumption may or may not be all that justified in light of our
experiences over that time....
> A claim that media queries make server-side adaptation unnecessary is
> extremely naive
I don't have a good feel for the set of server-side adaptations that are
commonly performed, and would love to learn more about them. Is there a
good resource for that?
> if only for one logical reason: when I dispatch my
> resources, how am I going to know that the browser supports media
> queries at all if I don't even know what it is?
You assume that it does, going forward.
In any case, this is a complete and utter straw man. You certainly know
what "Gecko" is and that it supports media queries. It says the "Gecko"
part right in that User-Agent string that we _do_ send, after all.
> Other examples: should I be sending the highest resolution of my
> images to every device hoping that the browser's CSS will resize them
> down to size once (if ever) they get there?
I'll assume this was a non-rhetorical question.
Whether the images get there has nothing to do with the hardware of the
device; it's a property of the network between you and the device. So
exposing the identity of the hardware tells you nothing about whether
the images will get there. Communicating properties of the network to
the server would be great. In fact, communicating them to the _browser_
would be great! We could both optimize better given that information.
I'm very interested in ways we could get that working.
You should in fact assume that the browser's CSS will resize them down
to the size desired. That's a pretty basic CSS thing; having it not
work would be ... surprising.
If you send your images to that phone with a 200px by 300px screen and
resize them server-side to that size and then the user saves the page as
PDF and looks at it on their desktop or prints it you probably end up
with an unhappy user.
> Should I send multiple encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
You should tell the browser which encodings you have available and it'll
pick the ones it supports, right? That's how HTML5 <video> works. If
you're talking about encodings in the same format but at different
bitrates, then that's not something that depends on the destination
hardware but rather on the intermediate network. If you're talking
about encodings in the same format at different resolutions, that's why
<source> elements in HTML5 have an attribute called "media" which takes
as its value one of those media queries that people seem to think are
useless So you can explicitly say which video streams to use for
various screen resolutions.
> Should I even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
This is, once again, a strawman. You know the rendering engine, so you
know whether JavaScript is enabled (unless the user has turned it off,
or installed NoScript, or ...).
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
You may wish to read the thread at
http://lists.w3.org/Archives/Public/www-style/2011Apr/0002.html which is
oddly on-topic here. I have no doubt that your tools give you a wealth
of detailed and correct information! Based on my experiences with
"non-mobile" sites, I have doubts about how that information ends up
being used.
The comments so far in this thread have allayed some of those doubts (in
the sense that people are sounding much more competent than what I tend
to see out there), but strengthened others (in that their goals seem to
be fairly different from mine).
> "Just telling us 'we need it' is not enough. We think you don't."
>
> .... is baffling, and insulting,
No, it's an invitation to convince us that we're wrong. Just telling us
"you're wrong" is not very convincing. Information about the actual
technical issues and why the solutions involved are a good thing for our
users (as opposed to, say, your advertisers) would go much better.
> logic in the bug report. http://phon.me/?p=44
> says that one consolation might be your likely lack of traction.
He also has lots of concerns about low-end devices running UAs with
limited JS capabilities. But if you see a mobile Firefox UA string,
which we DO send, you know:
1) It's not a 2011-era low-end device.
2) It supports JavaScript.
So he too is arguing against the same strawman you have chosen.
> On the other hand, you could help the world imagine and build a rich,
> responsive, beautiful and clever web which has escaped its homogenous
> desktop tethering and document-centric assumptions and which you'll
> have been instrumental in helping to bring to life.
I think we agree that this is desirable.
We happen to think that sending the hardware identifier of the hardware
we're running on is not the right way to get there.
We're open to discussion of what said right way is.
-Boris
And one other comment, on the idealism angle.
The sense I'm getting is that people are concerned about how to get
their existing body of content rendering well in UAs on phones that are
several years old at this point as well as the new Firefox. Adding the
hardware identifier to our UA is expedient for this purpose, because it
lets all your existing infrastructure "just work".
I think the differences arise from two issues.
First, the comments I've seen make it sound like the infrastructure is
being used in ways that seem harmful to our users, as well as in ways
beneficial to them.
Second, while your focus on the here and now is understandable, we as an
organization are also thinking about how things will look 3 years from
now or more. And from that point of view, adding the hardware
identifier seems actively harmful. This is why we're more interested in
figuring out a solution that will solve your short-term problems while
not creating long-term ones. I understand that this is more work for
you than having us just play along with the established setup, and you
see little benefit for doing that work. You are of course free to take
a "my way or the highway" approach on the issue, as the phon.me post you
cite seems to. But I think that it would be more productive to talk to
us about the specific problems your existing infrastructure is solving.
-Boris
> I'm more than a little surprised by the idealism here.
You must be new here :-).
But seriously, it's not so much idealism as years of bitter experience with
the failures of UA-sniffing, and a desire to not see those mistakes
repeated.
Boris said most of what I have to say here, but I'd like to make an
important point: Adding content to every HTTP request's headers does
not cost 'next to nothing'. And end user's browser makes thousands of
requests every day and you're adding extra weight to all of those
requests that can't be removed. Given that almost every mobile network
charges for bandwidth (or imposes aggressive limits) this bandwidth is
the opposite of free. There's also the question of whether bloating
the HTTP headers could degrade the browsing experience by increasing
the number of TCP packets required for each request.
Given that this information is only used for a small subset of cases,
the potential risks are not justified by the benefits presented thus
far. All the device information being asked for also seems like stuff
that you could query once on the client side using JS, and then send
back to the server - once - reducing the cost of such a feature
significantly. If I were to advocate this kind of device information,
it would be client-side, not in HTTP headers. If you want to generate
device-targeted content on the server, it should be as an optimization
- not as the only way you do it.
Also, sending device information in headers ignores the fact that
every modern smartphone I've used supports display rotation, which
changes the dimensions of the browser. If you're using display size to
customize the content you serve to the browser, your page is going to
break horribly when I rotate my phone.
-kg
See http://yiibu.com/ and this associated presentation for some practical examples of how Media Queries are used to build adaptive mobile sites that still work in legacy browsers with no Media Query support:
http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu/
(The most relevant point is starting on slide 79: "The absence of support for @media queries is in fact the first @media query.")
> Other examples: should I be sending the highest resolution of my
> images to every device hoping that the browser's CSS will resize them
> down to size once (if ever) they get there?
You can use media queries and JavaScript to determine which image to request and to ensure that only the correct image is downloaded (and yes, you can still provide a fallback that works in browsers without media queries or JavaScript).
> Should I send multiple
> encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
You can use the Accept: header to determine server-side which video encoding to use. Anyway, using the name of the hardware device to determine would be incorrect; for example, Firefox and WebKit running on the same device support different audio and video codecs.
> Should I
> even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
Again, this has nothing to do with the current debate about device info in the User-Agent header; adding information about hardware to the Firefox User-Agent header will not tell you anything new about its JavaScript support.
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
And yet past versions of Firefox that included device information in the User-Agent string were penalized for it, at least as much as they benefitted from it. For example, we included "Nokia N800" in the User-Agent string for old versions of Firefox on Maemo. This caused sites like YouTube to assume that it was some unrelated Nokia N-series browser, and send video content that it couldn't play.
Server-side detection is fine for the default browser on a known device, but it creates a major barrier to entry for brand new browsers (or browsers that are new to a specific device).
I'm missing some context here. Comments higher up the thread make it
sound like every other mobile browser exposes all this info and
Mozilla is being recalcitrant by not exposing it. Is that true?
Nick
> And let me ask you a simple question. Would it be ok for iPhone and
> iPad to have the same UA? (I think you know the answer)
...Yes? The iPhone was around for 3 years before the iPad came out, and
the rest of the web for another decade or two before that. Who'd want to
get an iPad if it was unable to use the web because it was neither a
desktop nor iPhone?
No one doubts that sending more info can be useful for some people
wanting to do some things in certain ways. [Good heavens, can you
imagine the awkwardness of a site recommending a *black* case for my
*white* iPhone?!] The question Mozilla is concerned with is if that's
good or bad for the web in the long run, and if there are other ways of
exposing such data that are less problematic.
Justin
It's not just idealism. It's also experience and foresight.
Mobile sites are notorious for trying to do more sniffing than they have
competence for. http://xkcd.com/869/ wouldn't be funny if the problem
wasn't so common. It's not good to give sites too much rope to shoot
their users in the foot with. I have concerns that even revealing the
distinction between "desktop" and "mobile" versions of Firefox is too
much sniffing surface that allows sites that assume that "mobile"
implies bad browser to send dumbed-down content to Firefox on Android or
Maemo.
Minefield tends to have the substring "pre" in its UA string, so some
sites think it's Palm Pre's default browser and sends downsized content.
Guessing how exactly sites trip themselves over so that they can be
evangelized appropriately would become even harder if there were a
zillion device identifier strings an arbitrary subset of which triggers
something special on some sites.
Suppose Firefox 4 for Android told sites that it's running on HTC Desire
when it is running on HTC Desire. The default browser on HTC Desire
doesn't support SVG but Firefox 4 for Android does. I think it would be
virtually certain that sites would show up serving SVG to Mobile Safari
but not to Firefox 4 for Android because they had some fancy device
capability database telling them that "iPhone supports SVG" but "Desire
doesn't support SVG".
There's really no point in setting up the possibility for sites to make
that mistake and then going on the evangelism treadmill to tell sites
not to make that mistake.
Note that Opera Mobile 11, which is the other mobile browser besides
Firefox 4 for Android/Maemo whose value proposition is being better than
the default browser on mobile devices, doesn't advertise the device make
and model in the UA string, so it evades sniffing that naively assumes
browser capabilities from the device name.
(Opera 11 is also interesting from the sniffing point of view in the
sense that both the Opera 11 with the desktop UI and Opera Mobile 11
with the mobile UI are available for tablets running Windows 7. The
choice of version is a matter of user choice, but both have the same
engine and both have zooming capabilities, so it doesn't make much sense
for sites to send different content to the two.)
> I presume it would cost next to nothing to
Stuff in the UA string is bytes sent out on every HTTP request.
> implement this in the same way that
> every other browser on the planet ever has,
Browsers typically don't tell the site what computer make and model you
are using.
> and that the HTTP spec
> clearly suggests you should.
Can you cite chapter and verse, please? I'm pretty sure the spec doesn't
suggest stuffing a device model identifier in the UA string.
> A claim that media queries make server-side adaptation unnecessary is
> extremely naive, if only for one logical reason: when I dispatch my
> resources, how am I going to know that the browser supports media
> queries at all if I don't even know what it is?
You can write your CSS in such a way that if media queries aren't
supported and the browser doesn't sniff as an old version of desktop IE,
the layout is left in a very simple state and media query support
enables enhancements. And these days, all mobile browsers worth using on
a daily basis support media queries anyway.
> Should I send multiple
> encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
At least as far as the format axis of selection goes, you should offer
URLs to all the formats you have in the HTML markup and let the browser
pick the format. (So only single encoding of the video gets transfered.)
Even in this case, the evidence doesn't inspire confidence in sites
doing better with UA sniffing than leaving the choice to the browser's
HTML5 media selection algorithm. A site (http://vid.ly/) whose core
competence such sniffing is supposed be got it wrong in all the three
*desktop* browsers I have tested so far (two suboptimal choices and one
choice so wrong that the video didn't play). I tested Firefox 4, Chrome
12 dev and Opera 11.10 on 64-bit Linux (and I've reported the problem to
the site). Had the site offered the formats it had and left the choice
to the HTML5 media selection algorithm, the results would have been
better.
Unfortunately, there isn't yet automation for choosing among different
bandwidth version of a video. As an approximation, you could do what
YouTube does: offering 360p by default and letting users ask for a "HD"
version from the site UI.
> Should I
> even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
All mobile browsers worth using on a daily basis support JavaScript
anyway. And if that's not enough for you, it should be sufficient to
sniff for "Gecko" on any platform.
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
Here's a competing client info repository breaking a site:
http://www.rohanradio.com/getting-aspnet-to-play-nice-with-opera-wget
(The same client info repo has a history of breaking sites with nightly
builds of Firefox, too, back when nightlies didn't say "Firefox" at all
in the UA string.)
> Suffice to say, this isn't a good start.
I think bsmedberg made the right call when he WONTFIXed the request to
add stuff to the UA string. (Thank you bsmedberg!)
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Oh? So much for the claims that all other mobile browsers do that....
-Boris
The solution is then simple:
1. Add a new HTTP header called -X-firefox-phone-UA that contains the
original UA
2. If you're concernced about traffic load and the users phonebill,
then just add the header when you get a Vary:User-Agent response from
the server
You would not break anything since this is a new header that no one
sniffs and only mobile sites that know what they are doing will use
this.
This is how Opera mini/mobile does it and it works well.
-Anders | @amaMobile
On Apr 4, 10:35 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> On Fri, 2011-04-01 at 21:27 -0700, James Pearce wrote:
> > I'm more than a little surprised by the idealism here.
>
> It's not just idealism. It's also experience and foresight.
>
> Mobile sites are notorious for trying to do more sniffing than they have
> competence for.http://xkcd.com/869/wouldn't be funny if the problem
> hsivo...@iki.fihttp://hsivonen.iki.fi/
Opera do expose the device, they add device info in another header
field:
http://dev.opera.com/articles/view/opera-mini-request-headers/
This was mentioned in the original bugreport and is also mentioned as
a suggested solution to this problem that would not mess up existing
sites.
-Anders
> 1. Add a new HTTP header called -X-firefox-phone-UA that contains the
> original UA
This is just a syntactic transformation that would enable pretty much the same anti-patterns as putting the same information in the UA string.
> 2. If you're concernced about traffic load and the users phonebill,
> then just add the header when you get a Vary:User-Agent response from
> the server
It's too late to add a request header based on a response header.
> You would not break anything since this is a new header that no one
> sniffs and only mobile sites that know what they are doing will use
> this.
For each mobile site that knows what it's doing, there are generally many more that don't.
> This is how Opera mini/mobile does it and it works well.
This isn't true. I just tested this on Symbian (Opera Mobile 11 and Opera Mini 6, the Symbian-native version--not the Java version).
First, neither Opera Mobile nor Opera Mini puts the device make or model in the User-Agent request header.
Opera Mobile does not send the UA string of the default browser in any request header. Further, Opera Mobile doesn't put the make or model of the device in *any* request header.
Opera Mini sends a request header called X-OperaMini-Phone that contains the make and model of the phone. Opera Mini also sends a header called X-OperaMini-Phone-UA that contains a value that looks like a UA string. However, it is *not* the UA string of the default browser! It is a different string that contains sniffing surface to identify the device make and model, the operating system & version and the MIPD & CLDC versions. That is, it's a string that has enough sniffing surface to cater for the use case of offering the right Java or Symbian-native installation package for the phone for software downloads, but it is not what it is labeled to be and that you, too, appear to have been tricked to believe it to be.
>> Oh? So much for the claims that all other mobile browsers do that....
>
> Opera do expose the device, they add device info in another header
> field:
>
> http://dev.opera.com/articles/view/opera-mini-request-headers/
I said "Opera Mobile 11". The article you are pointing to is about Opera Mini.
> On Apr 4, 10:58 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
>> On 4/4/11 1:35 AM, Henri Sivonen wrote:
>>
>>> Note that Opera Mobile 11, which is the other mobile browser besides
>>> Firefox 4 for Android/Maemo whose value proposition is being better than
>>> the default browser on mobile devices, doesn't advertise the device make
>>> and model in the UA string
>>
>> Oh? So much for the claims that all other mobile browsers do that....
>>
> If you send your images to that phone with a 200px by 300px screen and
> resize them server-side to that size and then the user saves the page as
> PDF and looks at it on their desktop or prints it you probably end up
> with an unhappy user.
Which is what media="print" is for, surely?
> > logic in the bug report.http://phon.me/?p=44
> > says that one consolation might be your likely lack of traction.
>
> He also has lots of concerns about low-end devices running UAs with
> limited JS capabilities. But if you see a mobile Firefox UA string,
> which we DO send, you know:
>
> 1) It's not a 2011-era low-end device.
> 2) It supports JavaScript.
And it's just one of over 2000 unique user-agents our site sees daily,
which represents some 1300 devices. Creating exceptions for devices
that don't do things the same way as others costs time and money that
we don't have, especially as the state of the art is progressing so
rapidly.
> So he too is arguing against the same strawman you have chosen.
Not a strawman - even when media queries are assumed to work, the
whole process of sending more data than the phone actually needs to
display a properly formatted page is abusive to the end user, who may
be on a very limited connection, and may be paying by the byte.
Further up the thread someone argues against adding the twenty bytes
or so required to indicate the device on precisely these grounds: it
works both ways.
I've slightly reordered your original post as I think this is the real
crux of the matter, so I've saved it for last:
> It would not cost us much in the way of work, no. It would cost our
> users something, though, and we would feel that we are selling them out.
This is the main issue for me. I can explain the positive use-cases
associated with device identification as much as I like (faster pages,
lower usage bills, better focussing of my team's R&D), but you won't
let me identify the device because it's become a privacy issue. I have
some sympathy with this viewpoint, but I think the balance between the
extra benefits the user gets from having right-sized pages is a valid
tradeoff against the few extra bits of info a blackhat would gain if
they were trying to track someone through their device user-agent.
So, obviously, your media="print" stylesheet will surely override all of
the settings inferred by the User-Agent request headers, plus developers
worried about wasting dozens of bytes will surely include a link to the
media="print" stylesheet to every page to handle this rather uncommon
use case, especially when they are already unwilling to use media queries.
If you aren't willing to put "Firefox" is general into the "supports
stuff that desktop browser support" bucket, why should we believe you'd
cater for "Firefox on device Foo", "Firefox on device Bar", "Firefox on
device Quux" more carefully as opposed to treating them the same as
"default browser on Foo", "default browser on Bar" and "default browser
on Quux"? For a product that is trying to be better than the default
browser, it doesn't make sense to enable sniffing that's likely to
result in getting lumped together with the default browser. (Consider,
for example, the SVG example from my earlier email to this thread.)
> Not a strawman - even when media queries are assumed to work, the
> whole process of sending more data than the phone actually needs to
> display a properly formatted page is abusive to the end user, who may
> be on a very limited connection, and may be paying by the byte.
Firefox hasn't really been designed for "pay by the byte" scenarios. For
example, Firefox Sync does uses connectivity in the background without
prompting the user about byte tallies.
Users who are paying by the byte are more likely to choose Opera Mini
than Firefox in order to deal with sites that aren't trying to
specifically optimize for "pay by the byte" users regardless of what
*your* site does.
> This is the main issue for me. I can explain the positive use-cases
> associated with device identification as much as I like (faster pages,
> lower usage bills, better focussing of my team's R&D), but you won't
> let me identify the device because it's become a privacy issue. I have
> some sympathy with this viewpoint, but I think the balance between the
> extra benefits the user gets from having right-sized pages is a valid
> tradeoff against the few extra bits of info a blackhat would gain if
> they were trying to track someone through their device user-agent.
If your concern is sizing stuff, why are you asking for the device name
and assuming you know how to correlate it with the size instead of
asking for the size?
That said, I don't really expect Firefox on any platform to start
sending screen or connection characteristics in an HTTP header. However,
if you really want to customize resource size to the screen size, you
could read the size in JavaScript and put it in a cookie. Then you could
optimize the responses to subsequent requests. As a bonus, this approach
would work across multiple pre-existing browsers without browser changes
and without having to maintain a device database.
I don't know if you've been following this thread closely, but the
whole point about the lack of device info in the Fennec headers is
that there are no "settings inferred by the User-Agent request
headers". All the author of a page is allowed to know is that the
browser is a mobile variant of Firefox. The author doesn't know how
big the screen is, so can only hint as to how it should be represented
on different screens.
The save to PDF example can be solved by including it in a cascade of
media-queries, or by simply declaring a print media type on import, in
which case the browser is free to ignore it completely. The latter
seems like a more economical approach.
> If you aren't willing to put "Firefox" is general into the "supports
> stuff that desktop browser support" bucket, why should we believe you'd
> cater for "Firefox on device Foo", "Firefox on device Bar", "Firefox on
> device Quux" more carefully as opposed to treating them the same as
> "default browser on Foo", "default browser on Bar" and "default browser
> on Quux"? For a product that is trying to be better than the default
> browser, it doesn't make sense to enable sniffing that's likely to
> result in getting lumped together with the default browser. (Consider,
> for example, the SVG example from my earlier email to this thread.)
By being on a certain device Firefox would end up with some, but not
all, of the same characteristics as the default browser, because they
both share the same root constraints - those of the device. But we
wouldn't want to bracket the default browser together with Firefox
(unless there was no discernible difference in required output, and
even then I'd be nervous). Screen size would be the same on both
browsers, but available screen might be different because they might
have different chrome.
As to your core point, which is whether I would assign Firefox Mobile
to a "desktop-like" bucket, there are two responses: one is that the
majority of devices we provide content for aren't as clever as
Firefox, and do need a non-desktop approach. While I can see the
attractiveness of using desktop techniques, I'd rather keep our code
consistent across all devices (I'm aware that this argument is really
down to how we choose to develop rather than an architectural
principle, but I'm disappointed that Mozilla don't want to allow us
the option). The second point is more architectural: just because a
device can do something, should we implement it? I'd say yes to this
only of it seemed appropriate in a mobile context: as the desktop
techniques encouraged by Mozilla result in a lot of unused data being
sent to the device, I'd say that it wasn't appropriate to mobile.
> Firefox hasn't really been designed for "pay by the byte" scenarios. For
> example, Firefox Sync does uses connectivity in the background without
> prompting the user about byte tallies.
That is actually a rather shocking statement. Surely when designing a
mobile-specific browser you should consider the circumstances under
which it will be used?
> Users who are paying by the byte are more likely to choose Opera Mini
> than Firefox in order to deal with sites that aren't trying to
> specifically optimize for "pay by the byte" users regardless of what
> *your* site does.
Agreed, and one thing I don't want to say is that my way is the *only*
way to approach mobile development. Media queries, adaptive design etc
may well be more appropriate for other sites. My problem isn't that
Mozilla are *encouraging* progressive web development, it's that
they're *blocking* the kind of approach we and much of the industry
take (such as Facebook -
http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
)
> If your concern is sizing stuff, why are you asking for the device name
> and assuming you know how to correlate it with the size instead of
> asking for the size?
>
> That said, I don't really expect Firefox on any platform to start
> sending screen or connection characteristics in an HTTP header. However,
> if you really want to customize resource size to the screen size, you
> could read the size in JavaScript and put it in a cookie. Then you could
> optimize the responses to subsequent requests. As a bonus, this approach
> would work across multiple pre-existing browsers without browser changes
> and without having to maintain a device database.
The reason for not requesting characteristics is that what's regarded
as useful and interesting keeps changing, and the amount of data that
would need to be sent would be regarded as excessive by browser
vendors. The mobile industry tried that approach with UAProf and user-
agent sniffing and device database grew despite the fact that almost
every device advertises its capabilities in a separate header.
In the firefox case we probably will end up using the cookie solution
if it gains enough traction to require special handling. That doesn't
seem like a very satisfactory solution to me, but it would be
workable.
That works for background images, but for <img src> that doesn't work.
All you can do in your print stylesheet is rescale the image, and if it
was downsampled on the server you get ugly results.
> And it's just one of over 2000 unique user-agents our site sees daily,
> which represents some 1300 devices. Creating exceptions for devices
> that don't do things the same way as others costs time and money that
> we don't have, especially as the state of the art is progressing so
> rapidly.
As I said earlier in this thread, I appreciate your position and the
reasons for it. But I think that sending the hardware identifier would
not fit us into your existing infrastructure well (because you would
still need to tell us apart from the defaul browser), and would be
harmful to the web in the medium to long term and to our users throughout.
>> So he too is arguing against the same strawman you have chosen.
>
> Not a strawman - even when media queries are assumed to work, the
> whole process of sending more data than the phone actually needs to
> display a properly formatted page
The thing is, knowing the screen size (which I agree may be a legitimate
thing to want to know, by the way) doesn't tell you much about how much
data the phone needs: that also depends on the zoom level, on whether
the user wants to print, and so forth.
And as someone pointed out earlier, even for a given piece of hardware
the screen size is not constant....
>> It would not cost us much in the way of work, no. It would cost our
>> users something, though, and we would feel that we are selling them out.
>
> This is the main issue for me. I can explain the positive use-cases
> associated with device identification as much as I like (faster pages,
> lower usage bills, better focussing of my team's R&D), but you won't
> let me identify the device because it's become a privacy issue.
More precisely, privacy is one of the things we should consider and a
drawback (along with other drawbacks) that we need to balance against
the benefits of identifying the device. It's not a hard line,
obviously; we do identify various other information about the device.
-Boris
https://addons.mozilla.org/en-US/mobile/extensions/?sort=popular
-Anders
> take (such as Facebook -http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to...
What would be interesting is to see data on what values users are
setting it to send.
-Boris
There are two main categories of mobile browsers: those that have
limited engines (including severely outdated snapshots of desktop
engines) and those that have a full up-to-date desktop engine but differ
from the desktop by being adapted to a different device form factor.
Firefox 4 for Android and Maemo, Opera Mobile and Mobile Safari are in
the latter category. As a user, if I'm using a browser in this latter
category but your site caters to desktop browsers and the mobile
browsers that have limited engines, I'd rather get the desktop version
of your site.
Since I know that's what I want as a user, I think Mozilla (or any
vendor of a mobile browser that has a full engine) should avoid getting
put onto the same code path as mobile browsers with limited engines on
sites that don't specifically cater to the category that Firefox for
Android/Maemo, Opera Mobile and Mobile Safari are in.
Again, if we look at what the most similar competing product, Opera
Mobile 11, is doing, it calls itself "Opera Mobi" instead of "Opera
Mobile" in its UA string--presumably because the string "Mobile" is
toxic and would result in getting lumped together with mobile browsers
that have limited engines.
(I'm generalizing above. There are notable mobile browsers that don't
fit into a "limited engine vs. full desktop engine" dichotomy, e.g.
Opera Mini and the Android default browser. The former has a full engine
on the server but can't use all its interactive features due to the thin
client architecture. The latter uses a real desktop engine but has a
substantial part of it disabled and lacks polished system-specific back
ends for some features.)
> > Firefox hasn't really been designed for "pay by the byte" scenarios. For
> > example, Firefox Sync does uses connectivity in the background without
> > prompting the user about byte tallies.
>
> That is actually a rather shocking statement. Surely when designing a
> mobile-specific browser you should consider the circumstances under
> which it will be used?
Firefox requires an ARMv7 CPU, so it's limited to devices that are
currently at the high end of the spectrum. I'd be rather surprised if
someone who buys a high-end device would be too cheap to get a data plan
that doesn't cost by the byte. After all, what's the point of a high-end
device if you aren't using it for Web browsing so much that you need a
data plan that doesn't cost by the byte? (Where I live, a device
suitable for running Firefox costs 450 euros or more with taxes and
suitable data plans start at less than 10 euros per month with taxes.)
> > Users who are paying by the byte are more likely to choose Opera Mini
> > than Firefox in order to deal with sites that aren't trying to
> > specifically optimize for "pay by the byte" users regardless of what
> > *your* site does.
>
> Agreed, and one thing I don't want to say is that my way is the *only*
> way to approach mobile development. Media queries, adaptive design etc
> may well be more appropriate for other sites. My problem isn't that
> Mozilla are *encouraging* progressive web development, it's that
> they're *blocking* the kind of approach we and much of the industry
> take (such as Facebook -
> http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
> )
That article seems to be about also trying to support both mobile
browsers that have limited engines and mobile browsers that have
desktop-grade engines. Firefox provides quite enough sniffing surface to
let anyone who cares to put it in the "desktop-grade engine" bucket
together with Mobile Safari and Opera Mobile--where further tuning can
be done using media queries.
--BDS
Firstly, images, and more specifically, img tags.
With CSS background images, you can of course use media queries to load up different stylesheets based on screen width. It's still a bit clunky, as you get devices with all kinds of different widths and they don't all conform to one standard size. But you can kind of get around this.
img tags are another matter though, or at least from what I can tell they are. What I'm trying to do is build up a path to an image, so that when the page is rendered, the img tag points to a path of an image that not only fits in terms of screen dimensions, but is also the right file size.
I could use a CSS media query to set the max-width, or just have max-width:100%. But it's still going to load up my original image, which may have to be 1000 px x 1000 px to accomodate - it's going to be big. If everyone on a mobile phone had a broadband speed connection it wouldn't be a problem, but they don't, so it is.
I could also display a whole bunch of images on the page, and use media queries to hide them if they are less than or greater than a certain width. This is probably a worse scenario than the previous idea.
Another solution is to add some JavaScript that runs at the top of the page and changes all of the img src paths based on the screen width. This potentially could work, but it's a massively hacky way of doing what you want.
If someone has a solution to this, I'm all ears.
The 2nd issue I have is not knowing what the actual device is.
There are plenty of instances where someone has a mobile app, and wants to promote it on the mobile version of the website. There might be different builds based on the version of Android - but the useragent passed through only contains "Android", and that's it. I don't know for sure if you have different versions of apps on different versions of Android, so that may be a moot point, but I may be right.
The last thing is how are you supposed to know whether the browser hitting your site is a mobile? Sniffing the Fennec useragent and using that? Surely that is as bad as providing the original device UA..
I'm sure the response will be to use media queries to work out screen width, etc, but I want to actually deliver a different experience on a mobile handset. I have a website that when someone is using it on a mobile device, I want it to do very different things to when they are on a desktop.
I might have a web app that allows you to keep score at a baseball game - who brings a laptop to a baseball game? And when you get home, you can compare how you scored against the actual scoring... I want the same URL for both, I don't want an m. sub domain and the only way I can do it is to sniff the Firefox UA.
If possible, I'd like the device info actually supplied in http headers, so at the very least, the vendor and model, and anything else that might help - so screen size for sure. It's not giving away anything that isn't being done on the desktop Firefox - after all, Google Analytics knows all about the screen sizes of the browser. The difference of course with GA on a web browser, is that it doesn't need these at page execution, whereas a mobile web page probably does.
Thanks.