Choice of Best User-Agent for Mobile Firefox: data for discussion

[John Jensen]

Hi all,

With this email I hope to kick off a conversation regarding Fennec's
User-Agent string, by summarizing some of the data that has been
collected. I am just going to be presenting the data, no opinions. :)

To cut to the chase, the latest summary and dataset can be found here:

https://docs.google.com/a/analysis.net/spreadsheet/ccc?key=0AushOZLFQoR0dGQ0Ry1HYmZGUEg5dXJDYUstS2dwcWc&hl=en_US#gid=0

*Background*
To assess the current state of affairs, I wrote a simple tool that,
using the latest UA strings from Mobile Fennec, Android Browser, iPhone
Mobile Safari and Desktop Firefox, downloaded the homepages from each of
the Alexa Global Top 1000 [1], following any redirects that were
delivered to save the HTML that was eventually presented to each UA.

The tool then used Python's difflib.SequenceMatcher.quick_ratio [2]
method to compute "similarity" measures of the HTML served to each UA.
If the ratio was 0.0, then there was nothing in common between the two
HTML bodies, and if it was 1.0, they were identical.

Once the distance measures were collected I conducted a K-Means cluster
analysis, which grouped the list of sites into three main clusters:
1) those that served pretty well the same HTML to any UA
2) those that appeared to serve different HTML to all mobile UAs
3) those that appeared to serve different HTML to iPhone and Android only

The third group comprised about 19% of all the sites, including nine of
the top twenty. The spreadsheet summarizing this can be found at [3].

The next iteration was to conduct the same analysis, using 40 different
possible Fennec UA strings. The URL to the summary Google Docs
spreadsheet is above.

This time, the results are summarized on a mean and a weighted mean
basis, using a Zipf-like weight distribution -- the most popular site
(google.com) has 1000 times the weight of the the 1000th site.

While this approach does not cover all the bases, it should be
sufficient to start narrowing down specific options.

[1] Alexa Global Top 1000
http://code.google.com/p/httparchive/source/browse/trunk/lists/Alexa%20Global%201000.txt

[2] Python difflib.SequenceMatcher.quick_ratio
http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio

[3] First spreadsheet
https://docs.google.com/a/analysis.net/spreadsheet/ccc?key=0AushOZLFQoR0dGFpTWpCQXI4elZUTTJubXlWTkl1MVE&hl=en_US#gid=0

John

--
John Jensen
Web Technology Competitive Analyst
Mozilla Corporation
+1 604 218 0400

[Gervase Markham]

On 20/01/12 19:09, John Jensen wrote:
> Hi all,
>
> With this email I hope to kick off a conversation regarding Fennec's
> User-Agent string, by summarizing some of the data that has been
> collected. I am just going to be presenting the data, no opinions. :)

Good separation. :-) Here's some attempts at extracting data from the
data, to try and work out which alterations to the UA string have most
effect. I'll also try and save opinions for a follow-up post :-)

The below is an analysis of data set "Fennec User-Agent strings that
receive content most similar to that served to Android Browser, measured
by mean difflib ratio" from this file:
https://docs.google.com/spreadsheet/ccc?key=0AushOZLFQoR0dGQ0Ry1HYmZGUEg5dXJDYUstS2dwcWc#gid=0

Thanks very much to John Jensen for his hard work in putting this together.

I will take each UA string "component" and try and work out what
difference altering/adding/removing it makes. Where a set of N numbers
is given in brackets, they are absolute differences in the "MEAN" score
for N pairs of UAs which differ only by the aspect in question.

A higher "MEAN" score means "the HTML you get is more often closer to
that which is served to the Android stock browser". (There is room for
argument about whether this constitutes the best thing that could happen
or not.)

"Android"

The biggest factor is the presence or absence of the word "Android"
(0.1400 difference points). Perhaps unsurprisingly, having "Android"
makes it much more likely that you will get content similar to Android's
stock browser. However, it also makes it much more likely that you'll
get content similar to iPhone; this agrees with earlier research which
shows that most sites have a single mobile site and serve it both to
Android and iPhone.

"Mobile"

The second biggest factor is presence or absence of the string "Mobile"
(0.0400 points).

"like AppleWebKit"

This has a fairly small effect (0.0077, 0.0054, 0.0074).

'Firefox/X Mobile/X' vs. 'Firefox Mobile/X'

This has only a small effect (0.0033, 0.0036, 0.0037), with 'Firefox/X
Mobile/X' being better - perhaps because the latter means that an
attempt to parse a Firefox version number will fail, or perhaps because
people are looking for "Firefox/".

Android version number ("2.3")

This had only a small effect (0.0011, 0.0017, 0.0013), and it varied in
sign - in some cases, it made it better, in others it made it worse.

"U"

This has only a small negative effect (0.0011, 0.0005). Given that
no-one is likely to be checking specifically for strong crypto, as all
browsers now have it, any difference is likely to be down to people
checking for exact UAs.

"Linux"

What data there is suggests that this has little effect. The test user
agent from my set which said "Android" jumped into the middle of the
pack. This suggests that "Linux", which was in the other strings tested
but which I did not add, has negligible effect - certainly compared to
"Android".

Removing "Mozilla/5.0"

This has only a very small negative effect (0.003).

Removing the Gecko date

This actually had a tiny positive effect (0.002).

Gerv

[Gervase Markham]

On 23/01/12 11:43, Gervase Markham wrote:
> effect. I'll also try and save opinions for a follow-up post :-)

And here they are :-)

Summary: the proposed string at
https://wiki.mozilla.org/Fennec/User_Agent is good enough to adopt,
given its other beneficial properties. But the big question is: when are
we going to do the massive evangelism we are going to need for B2G, and
do we use Fennec in that fight or not?


Let us assume for a moment that "the right thing" is getting the same
content as the Android stock browser. I'm not entirely sure that's true,
but it's probably the best simple measure of "the right thing" that we
have. (At any point where iPhone and Android differ, it's probably
because people are doing iPhone or Android-specific content or styling,
and we want the Android version.) If we assume this, then a higher MEAN
score vs. Android stock is "better".

The original proposal for what we should do with the Fennec UA is here:
https://wiki.mozilla.org/Fennec/User_Agent

The justifications for the proposal are laid out on that page; briefly,
we are trying to balance accuracy, brevity, privacy,
non-foot-shootingness and compatibility.

The "Mobile" string from that proposal was tested by John, along with
three variants of it:

Base: Mozilla/5.0 (Mobile; rv:12.0) Gecko/0 Firefox/12.0
+Date: Mozilla/5.0 (Mobile; rv:12.0) Gecko/20100101 Firefox/12.0
+Android: Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/0 Firefox/12.0
Rearrange: Firefox/12.0 (Mobile; rv:12.0) Gecko/0

Looking at the results vs Android stock, then, the best of my proposed
strings is the "+Android" string:

Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/0 Firefox/12.0

This string had a MEAN score of 0.9401, which is 6th best when ordered
by the weighed measure, and only 0.0120 points from the string which is
at the top of the weighted measure. In other words, it did pretty well. :-)

Using the analysis in my previous post as to the effect of various
individual changes, we can see whether it's possible to make this string
more compatible.

The only possible change that could be made which would have any
significance would be to add "like AppleWebKit" - that would account for
over half of the (small) gap between this and the top-rated string -
around 0.007 points. However, I would suggest that this lie is not
helpful enough to us to deal with the significant confusion it would
cause, particularly for people who are already trying to get this right
and distinguish between WebKit and Gecko. Breaking the code of those
already well disposed towards us would not be an awesome way to start an
evangelism programme. It is pleasing to see how little difference this
makes; it removes the pressure on us to add such a string.

The proposed string above has the advantage of being in line with the
latest thinking on minimal UA strings, to reduce fingerprinting surface
<https://wiki.mozilla.org/Fingerprinting#User_Agent>. Fortunately, it
seems, John's data shows us that those removals (language, crypto level,
etc.) have little or no effect on compatibility. It also removes the
Gecko date, as we promised we would do when we froze it for release
builds some time ago. These changes make this string significantly
shorter than other proposals, which is a small speed and bandwidth
advantage, when added up over trillions of requests.

There are two further changes we need to consider, one fairly
inconsequential, one massive:

Rearrangement
-------------

The evidence suggests that removing the Mozilla/5.0 string does not
actually have much effect. So, we could switch it to:

Firefox/12.0 (Android; Mobile; rv:12.0) Gecko/0

without seeing a significant decrease in compatibility - if we wanted
to. (The tested string in which this change was made did badly in
absolute terms, but only a tiny bit worse than a similar string without
the change. Its poor showing overall was because it didn't have the word
"Android" in it.)

The advantage would be 12 bytes less on every HTTP request Firefox
sends, and the removal of a redundancy. The disadvantage is nostalgia :-)

"Android"
---------

This is a big deal.

Having "Android" in the string makes a massive difference - 0.1400
points, 1/7th of the sites tested. B2G is not Android. So, if the B2G
user agent is not going to lie and include the string "Android", then we
have a big evangelism task ahead of us. The question is: do we take it
on now, by not putting "Android" in the Fennec UA, and pave the way for
B2G (which would then have exactly the same UA), or do we put "Android"
in the Fennec UA, and put off this big evangelism job for a few months?

The Fennec and B2G teams, and Mozilla's product management, need to make
a decision and when we are going to take this burden on - now, or later?

Gerv

[Dao]

On 23.01.2012 13:03, Gervase Markham wrote:
> The original proposal for what we should do with the Fennec UA is here:
> https://wiki.mozilla.org/Fennec/User_Agent
>
> The justifications for the proposal are laid out on that page; briefly,
> we are trying to balance accuracy, brevity, privacy,
> non-foot-shootingness and compatibility.
>
> The "Mobile" string from that proposal was tested by John, along with
> three variants of it:
>
> Base: Mozilla/5.0 (Mobile; rv:12.0) Gecko/0 Firefox/12.0
> +Date: Mozilla/5.0 (Mobile; rv:12.0) Gecko/20100101 Firefox/12.0
> +Android: Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/0 Firefox/12.0
> Rearrange: Firefox/12.0 (Mobile; rv:12.0) Gecko/0
>
> Looking at the results vs Android stock, then, the best of my proposed
> strings is the "+Android" string:
>
> Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/0 Firefox/12.0

Since I haven't heard back on this and it looks like the proposal is
being pushed further, I'll repeat it here: Please don't introduce
Gecko/0. This is a kind of cruft we've tried to get rid of. The size
advantage over Gecko/12 is merely one byte and can easily turn into a
loss if you take into account that with Gecko/0, rv:$version will need
to be carried around forever. I also summarized this on
https://wiki.mozilla.org/Fennec/User_Agent#Gecko_Date_2

[Gervase Markham]

On 23/01/12 15:57, Dao wrote:
> Since I haven't heard back on this and it looks like the proposal is
> being pushed further, I'll repeat it here: Please don't introduce
> Gecko/0. This is a kind of cruft we've tried to get rid of. The size
> advantage over Gecko/12 is merely one byte and can easily turn into a
> loss if you take into account that with Gecko/0, rv:$version will need
> to be carried around forever. I also summarized this on
> https://wiki.mozilla.org/Fennec/User_Agent#Gecko_Date_2

I'm not sure I see the advantage of freezing the rv: token and moving
the number over to Gecko/XX.X. OK, so logically that's a better place
for it, but is the pain of everyone updating their (working) scripts
worth the logical improvement?

I can see that using Gecko/12.0 is better (if we say we carry on
incrementing rv:), but that does put the version number in 3 places in
the string!

We could go with "Gecko/", although apparently that's technically in
violation of the spec. Other options are Gecko/# or Gecko/!, although I
suspect you don't see them as an improvement over Gecko/0.

Gerv

[Dao]

On 23.01.2012 17:22, Gervase Markham wrote:
> On 23/01/12 15:57, Dao wrote:
>> Since I haven't heard back on this and it looks like the proposal is
>> being pushed further, I'll repeat it here: Please don't introduce
>> Gecko/0. This is a kind of cruft we've tried to get rid of. The size
>> advantage over Gecko/12 is merely one byte and can easily turn into a
>> loss if you take into account that with Gecko/0, rv:$version will need
>> to be carried around forever. I also summarized this on
>> https://wiki.mozilla.org/Fennec/User_Agent#Gecko_Date_2
>
> I'm not sure I see the advantage of freezing the rv: token and moving
> the number over to Gecko/XX.X. OK, so logically that's a better place
> for it, but is the pain of everyone updating their (working) scripts
> worth the logical improvement?

They'll only need to update it if they want to sniff recent Gecko
versions. This seems ok to me, but hopefully they won't even want to do
this.

There's pain on the other side, too. The illogical structure isn't bad
just because it's ugly but because it isn't self-explanatory and
confuses people. It's only a few weeks ago that I saw somebody (who
wasn't even a stranger there) ask in #developers what Gecko/20100101
meant and where to find the Gecko version.

> I can see that using Gecko/12.0 is better (if we say we carry on
> incrementing rv:), but that does put the version number in 3 places in
> the string!

Unpleasant, indeed, and so I proposed freezing the rv: token. Why
exactly would having the version in three places be a problem, though?

> We could go with "Gecko/", although apparently that's technically in
> violation of the spec. Other options are Gecko/# or Gecko/!, although I
> suspect you don't see them as an improvement over Gecko/0.

Not at all...

[Ehsan Akhgari]

On Mon, Jan 23, 2012 at 7:03 AM, Gervase Markham <ge...@mozilla.org> wrote:

> "Android"
> ---------
>
> This is a big deal.
>
> Having "Android" in the string makes a massive difference - 0.1400 points,
> 1/7th of the sites tested. B2G is not Android. So, if the B2G user agent is
> not going to lie and include the string "Android", then we have a big
> evangelism task ahead of us. The question is: do we take it on now, by not
> putting "Android" in the Fennec UA, and pave the way for B2G (which would
> then have exactly the same UA), or do we put "Android" in the Fennec UA,
> and put off this big evangelism job for a few months?
>
> The Fennec and B2G teams, and Mozilla's product management, need to make a
> decision and when we are going to take this burden on - now, or later?
>

Would it make sense to adopt something like "like Android" for B2G as a
measure to address the compatibility problem there?

--
Ehsan
<http://ehsanakhgari.org/>

[Gervase Markham]

On 23/01/12 18:52, Ehsan Akhgari wrote:
> Would it make sense to adopt something like "like Android" for B2G as a
> measure to address the compatibility problem there?

It's a possibility, of course; but I'd prefer to avoid going down that
route if we can at all avoid it - partly because I think there is value
in eliminating OSes from the UA entirely (if we don't, each new platform
we port to will require updated evangelism), partly because there's a
possibility we might run into marketing issues ("this phone claims it's
like Android!") and partly because I just hate the "like X" thing. :-)

We should certainly look at other options first.

Gerv

[Doug Turner]

On Jan 23, 2012, at 10:52 AM, Ehsan Akhgari wrote:

> On Mon, Jan 23, 2012 at 7:03 AM, Gervase Markham <ge...@mozilla.org> wrote:
>

>> "Android"
>> ---------
>>
>> This is a big deal.
>>
>> Having "Android" in the string makes a massive difference - 0.1400 points,
>> 1/7th of the sites tested. B2G is not Android. So, if the B2G user agent is
>> not going to lie and include the string "Android", then we have a big
>> evangelism task ahead of us. The question is: do we take it on now, by not
>> putting "Android" in the Fennec UA, and pave the way for B2G (which would
>> then have exactly the same UA), or do we put "Android" in the Fennec UA,
>> and put off this big evangelism job for a few months?
>>
>> The Fennec and B2G teams, and Mozilla's product management, need to make a
>> decision and when we are going to take this burden on - now, or later?
>>
>

> Would it make sense to adopt something like "like Android" for B2G as a
> measure to address the compatibility problem there?
>

> --

We need to pass Android on the UA string to ensure that we get the users the content that they expect. I am not sure what B2G should do.

Doug

[Robert Kaiser]

Gervase Markham schrieb:

> On 23/01/12 15:57, Dao wrote:
>> Since I haven't heard back on this and it looks like the proposal is
>> being pushed further, I'll repeat it here: Please don't introduce
>> Gecko/0. This is a kind of cruft we've tried to get rid of. The size
>> advantage over Gecko/12 is merely one byte and can easily turn into a
>> loss if you take into account that with Gecko/0, rv:$version will need
>> to be carried around forever. I also summarized this on
>> https://wiki.mozilla.org/Fennec/User_Agent#Gecko_Date_2
>
> I'm not sure I see the advantage of freezing the rv: token and moving
> the number over to Gecko/XX.X. OK, so logically that's a better place
> for it, but is the pain of everyone updating their (working) scripts
> worth the logical improvement?

I think the win is that it not only would match the spec better than
with a date as the "version" part and that we could start advocating to
move any Gecko sniffing over to that instead of the "rv:" so at some
point in the future we'll be able to fade it out (just as we can very
possibly fade out the Mozilla/5.0 part now).

Robert Kaiser

[Robert Kaiser]

Gervase Markham schrieb:

> Firefox/12.0 (Android; Mobile; rv:12.0) Gecko/0

I'd really like that (with a change from Gecko/0 to Gecko/12 - using
only the major number as we shouldn't give anyone any reason to sniff
for minor/security updates as we can do that easily here).

> Having "Android" in the string makes a massive difference - 0.1400
> points, 1/7th of the sites tested. B2G is not Android. So, if the B2G
> user agent is not going to lie and include the string "Android", then we
> have a big evangelism task ahead of us. The question is: do we take it
> on now, by not putting "Android" in the Fennec UA, and pave the way for
> B2G (which would then have exactly the same UA), or do we put "Android"
> in the Fennec UA, and put off this big evangelism job for a few months?

I think every UA string should always include the OS just because e.g.
download sites (or documentation/FAQs or such) often sniff for it and
can make the experience way easier for users (and those we care about,
after all) by providing the resources that fit best for a user on this
OS. This means having "Android" in the UA on Android and not having it
on B2G.
And yes, this means evangelism with B2G - but I'm pretty sure we'll need
to do a lot of evang/marketing work to get the system in the market anyhow.

BTW, I think the UA of the B2G system itself should be something like

B2G/1.0 (Linux; rv:12.0) Gecko/12

(maybe with a Firefox/12.0 compat token added at the end but not
necessarily) while the B2G _browser_ should have a different UA that
would be like

Firefox/12.0 (B2G; Mobile; rv:12.0) Gecko/12

That's speaking what I'd think it to be ideally in my mind, but I'm not
even sure if we can implement it this way, let alone what it would mean
in terms of browser vs. installed app and things like that.

Robert Kaiser

[Ben Bucksch]

Instead of going the 1994 route, why not just put out a new UA string and let sites adapt? Mobile is still new, sites need to be constantly behind and adapt.

I would suggest a different approach: What the site *really* want to know is how large the screen is (and maybe which input methods the user has, but it's mostly the screen), because they want to deliver a page layout without the excessive top, left, right, bottom bars, so that the user has to scroll less. That's all that it's about.

So, I would just make a new field that gives them exactly that: One gives the approx. browser window size, e.g.

• tiny (e.g. 2" / 320x240)
• smartphone (e.g. 4" / 800x480)
• tablet (e.g. 10" / 1024x786)
• desktop (e.g. 20" / 1280x1024)

i.e. a small list of device *classes*.

Also, the screen orientation is just as relevant.

We already have the exact window size in JavaScript, but the site needs to know before it delivers the page.

Please note that B2G would want to run on tablets and smartphones, but the site may want to deliver different pages, so this is strictly better than switching based on browser implementation.

We could then also make this a UI pref "use desktop | tablet | smartphone versions of pages" without confusing site admins and webpage authors horribly and triggering more hacks.

Last but not least, we're in here to further the web. This approach helps everybody else entering the market, as well as us when we want to innovate in the future.

[Ben Bucksch]

On 23.01.2012 13:03, Gervase Markham wrote:

> Summary: the proposed string at
> https://wiki.mozilla.org/Fennec/User_Agent is good enough to adopt

+1

[Henri Sivonen]

On Mon, Jan 23, 2012 at 2:03 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Summary: the proposed string at https://wiki.mozilla.org/Fennec/User_Agent
> is good enough to adopt, given its other beneficial properties.

I agree.

> Let us assume for a moment that "the right thing" is getting the same
> content as the Android stock browser.

That's a very big assumption. Does the content the Android stock
browser gets work better than the content desktop Firefox gets? Right
now? What about if Fennec's ability to deal with desktop layouts was
as good as Opera Mobile's.

Especially with the tablet form factor, the best customization I can
make to Fennec as a user is to make sure the substring "Android"
doesn't appear in the UA string.

> (At
> any point where iPhone and Android differ, it's probably because people are
> doing iPhone or Android-specific content or styling, and we want the Android
> version.)

That's an even bigger assumption. iPhone is the Web developers'
darling, so they can easily be sending different content to iPhone and
Android just because they care about and test with iPhone more. The
most visible example is perhaps Bing. If Bing sees "Android" in the UA
string and they don't "support" that exact UA string, they send
content geared for unknown legacy mobile browsers instead of content
for the Android/iPhone class.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Doug Turner]

Hey Ben,

I think the short answer is: because we are trying to make a browser that people will use today. :)

I am sure you recall that it took *years* for us to get sites to adopt gecko and nscp/aol spent millions on evangelism. I don't think we have years. I want to be able to use Fennec today. I don't want to see WAP-dumb-down content. I want Fennec to get content similar to that of the iPhone. We have data that shows us how to optimize this experience and we are going to execute on it.

I do like the minimalism of Gerv's proposal. It is neat. But I also love the idea that we can build a browser that gets content today that users expect.

Thanks

[Ben Bucksch]

Hey Doug,

thanks for your response. Long time no see.

On 24.01.2012 16:17, Doug Turner wrote:
> I don't think we have years.

My point was that mobile is new and moving rapidly, and not many sites
have content specifically for mobile yet, and those that do are adapting
quickly.

So, if we use a new approach, it will be picked up in a matter of
months, not years.

It's a matter of approach. If we try to improve things, we'll have an
easier time later.

Please note that the "adjust to current hacks" approach does not even
cover the current usecases, because it doesn't distinguish between a 4"
smartphone and a 10" tablet. So, I argue, it doesn't even *work* *now*.

[Gervase Markham]

On 24/01/12 13:04, Ben Bucksch wrote:
> I would suggest a different approach: What the site *really* want to
> know is how large the screen is (and maybe which input methods the user
> has, but it's mostly the screen), because they want to deliver a page
> layout without the excessive top, left, right, bottom bars, so that the
> user has to scroll less. That's all that it's about.
>
> So, I would just make a new field that gives them exactly that: One
> gives the approx. browser window size, e.g.
>

> * tiny (e.g. 2" / 320x240)
> * smartphone (e.g. 4" / 800x480)
> * tablet (e.g. 10" / 1024x786)
> * desktop (e.g. 20" / 1280x1024)

One of the big things about HTML is supposed to be its device and screen
size independence. There are limits to that - sites seem to have a
"large version" and a "small version". But I don't think encouraging
more fixed-width layouts and non-adaptable markup is a win for the web.

FWIW, this argument has been had already, and AIUI, we decided against
supplying more detailed data of this nature. (As well as being bad for
the web, one other reason was that it's an increased fingerprint surface.)

> Also, the screen orientation is just as relevant.

And that can change between the request being sent and the content being
received. Web pages are going to need to adapt to screen orientation
changes - and we already have the CSS and events for them to do it.

Gerv

[Gervase Markham]

On 23/01/12 20:00, Robert Kaiser wrote:
> I think every UA string should always include the OS just because e.g.
> download sites (or documentation/FAQs or such) often sniff for it and
> can make the experience way easier for users (and those we care about,
> after all) by providing the resources that fit best for a user on this
> OS. This means having "Android" in the UA on Android and not having it
> on B2G.

It has been argued that the "software download" point is much less
relevant on mobile, because most mobile software comes from app stores.
It also seems to me that, when driving people to those stores, most
sites just have buttons or links marked "iPhone" and "Android" for
people to click rather than trying to do UA sniffing.

> BTW, I think the UA of the B2G system itself should be something like
>
> B2G/1.0 (Linux; rv:12.0) Gecko/12
>
> (maybe with a Firefox/12.0 compat token added at the end but not
> necessarily) while the B2G _browser_ should have a different UA that
> would be like
>
> Firefox/12.0 (B2G; Mobile; rv:12.0) Gecko/12

What advantage would there be in having different UAs for the B2G system
and the B2G browser? That sounds like it would just confuse webdevs and
increase the evangelism necessary.

> That's speaking what I'd think it to be ideally in my mind, but I'm not
> even sure if we can implement it this way, let alone what it would mean
> in terms of browser vs. installed app and things like that.

Well exactly. You need to give us some pretty strong reasons!

Gerv

[Ben Bucksch]

On 24.01.2012 16:41, Gervase Markham wrote:
> One of the big things about HTML is supposed to be its device and
> screen size independence.

Tell me all about it :).

Compare www.beonex.com with www.cnn.com and tell me again, please. :)

And I can convincingly claim that I didn't adjust my website for mobile,
although it works very well there, because I haven't changed it *at all*
since about 7 years! ;-) So, yes, you're right. Please tell the big sites...

Coincidentally, this is another advantage with this browser-neutral
approach: I want the "lean and mean" version of the website even on my
3200x1200 desktop, because my browser window is actually just 600x800.
So, I could tell my desktop browser "please give me the
smartphone/tablet version" without posing my desktop Firefox as Android.

Ben

[Ben Bucksch]

On 24.01.2012 16:41, Gervase Markham wrote:

> we decided against supplying more detailed data of this nature.

> [screen size]

But in fact, you do, implicitly, when you send "Android" as UA string.

[Doug Turner]

On Jan 24, 2012, at 7:44 AM, Gervase Markham wrote:

> It has been argued that the "software download" point is much less relevant on mobile, because most mobile software comes from app stores. It also seems to me that, when driving people to those stores, most sites just have buttons or links marked "iPhone" and "Android" for people to click rather than trying to do UA sniffing.

Well, I'd caution that kind of assertion about app stores. I don't believe that UA is the best place for this sort of thing… but if you are building a app store, you are going to want to have lots of information about the device. If you looked at the Market android application, you'd notice it doesn't ask you about your device type. However, the Market application doesn't serve you up content/apps that won't run on your device. For example, we put Firefox in the market. We can assert that it should only be installed on x, y, z devices.

So, for app stores need lots of device specifics. Does the web at large, probably no.

Doug

[Doug Turner]

On Jan 24, 2012, at 7:31 AM, Ben Bucksch wrote:

> Hey Doug,
>
> thanks for your response. Long time no see.

:)

> On 24.01.2012 16:17, Doug Turner wrote:
>> I don't think we have years.
>
> My point was that mobile is new and moving rapidly, and not many sites have content specifically for mobile yet, and those that do are adapting quickly.
>
> So, if we use a new approach, it will be picked up in a matter of months, not years.

We have had Fennec in the market for a while and still get crap content.

It is kind of a chicken and egg problem. Currently we have near zero marketshare. Most sites don't care about a browser with near zero marketshare. Users are not going to use us if a large percentage of the top 250 serves up crap content.

So, we can't get adoption if we can't get the right content, and we can't get sites to fix their UA parsers if we don't have adoption.

On a personal note, I wouldn't use Fennec if all i got was dumb-wap content -- and I have invested more than most into Fennec. Why would a normal person undergo the pain when the default browser get better content?

It is not ideal. And it kind of sucks. :(

Doug

[Robert Kaiser]

Ben Bucksch schrieb:

> My point was that mobile is new and moving rapidly, and not many sites
> have content specifically for mobile yet, and those that do are adapting
> quickly.

Also note that we still need to stick with a lot of the previous choices
in UAs, as a lot of web sites out there do sniffing for them - and we
don't only care about those probably fast-moving ones that have mobile
versions, but also the more general, not-so-fast-moving ones that only
have one version. People want to view and use those sites just as much
on their mobile devices (on tablets even more so than on phones, as IMHO
people's behavior on the devices is different).

Robert Kaiser

[Robert Kaiser]

Gervase Markham schrieb:

> What advantage would there be in having different UAs for the B2G system
> and the B2G browser?

Well, the agent of the user is an OS in one case, while it's a web
browser in the other, and this string *ought* to be meaningless for
anything else than telling the agent of the user. But then, we are in
ideal la-la-land with this view, and the web is different, I know that. ;-)

>> That's speaking what I'd think it to be ideally in my mind, but I'm not
>> even sure if we can implement it this way, let alone what it would mean
>> in terms of browser vs. installed app and things like that.
>
> Well exactly. You need to give us some pretty strong reasons!

In the end, except some utopian idealism, I'm not sure I can. (And I
know it's pretty strange in my message above to first argue with how
things are in the real web/world where people display things differently
because of a UA and then suddenly go into this utopian idealistic
argument - you might even call me inconsistent there...)

Robert Kaiser

[Henri Sivonen]

That people think that you can infer screen size from "Android" is an
excellent reason not to send "Android" and the reason why removing
"Android" is the single most effective way to make the Fennec
experience better on Android tablets.

[Gervase Markham]

On 24/01/12 17:09, Ben Bucksch wrote:
> But in fact, you do, implicitly, when you send "Android" as UA string.

There is currently a debate going on whether this is the right thing;
but anyway, "Android" says next to nothing about screen size.

Gerv

[Gervase Markham]

On 24/01/12 17:31, Doug Turner wrote:
> We have had Fennec in the market for a while and still get crap
> content.
>
> It is kind of a chicken and egg problem. Currently we have near zero
> marketshare. Most sites don't care about a browser with near zero
> marketshare. Users are not going to use us if a large percentage of
> the top 250 serves up crap content.

Yep. We have a big evangelism problem, whatever. So perhaps it's worth
picking the Fennec UA so that once we have done all that hard work, we
don't have to do it again for B2G, or Fennec/iPhone (if that ever
happens), or Fennec/OtherNewPlatform.

Gerv

[Daniel Cater]

https://wiki.mozilla.org/Fennec/User_Agent doesn't discuss the possibility of "Gecko" (without a version component) as one of the product strings.

It says: "reduce to "Gecko/0" - as having something after the / is required by the HTTP spec" - that is true ("Gecko/" is invalid) but "Gecko" on its own is not. WebKit doesn't have the slash.

If Gecko/version is not being considered (my personal preference as it makes the most sense in terms of product/version and then the rv string may one day disappear) then why not "Gecko"? Carrying another nonsense string around when now is a real opportunity to get rid of the nonsense seems silly.

[Dao]

On 26.01.2012 15:11, Daniel Cater wrote:
> It says: "reduce to "Gecko/0" - as having something after the / is required by the HTTP spec" - that is true ("Gecko/" is invalid) but "Gecko" on its own is not. WebKit doesn't have the slash.

Exactly, Webkit has "Gecko" without the slash. So people look for
"Gecko/" rather than "Gecko" to identify the real Gecko.

[Gervase Markham]

On 26/01/12 14:11, Daniel Cater wrote:
> It says: "reduce to "Gecko/0" - as having something after the / is
> required by the HTTP spec" - that is true ("Gecko/" is invalid) but
> "Gecko" on its own is not. WebKit doesn't have the slash.

And that's why lots of sites sniff for "Gecko/" to make sure they are
getting the real Gecko. We may even have advised this at one time.

I suspect reducing ourselves to "Gecko" would lead to a lot of mis-sniffing.

Gerv