Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Adding hardware tokens to UA string

218 views
Skip to first unread message

Jonas Sicking

unread,
Sep 13, 2012, 2:27:44 AM9/13/12
to dev-platform, Gerv Markham
Hi All,

For Firefox OS, we are getting requests from partners to add tokens to
the UA string which identify the hardware device on which Firefox OS
is running.

There are at least reasons for this:

* Some content providers strike deals with hardware manufacturers
which allow devices made by the manufacturer to access content for
free. One way that this is implemented is by looking for tokens in UA
strings and serve content based on this. This is obviously terribly
insecure and easy to spoof, however the hurdle is large enough that
this is a "good enough" solution in many cases. I.e. the cost of
developing a more secure solution, and the cost of losing users due to
having to ask them to enter passwords etc is higher than the lost
revenue due to people hacking the system by changing their UA string.

* App stores only want to deliver applications to devices which they
know will run on the device. Today many stores in our target market
(Brazil) apparently do this by looking at hardware tokens in UA
strings. This is a scenario where we strongly want people to do
capability checking by using the DOM for reasons that we are all way
too familiar with. However this isn't what stores do today and so we
would have to convince them to switch to this system. Additionally
capability checking isn't always perfect, since currently it's hard to
detect performance metrics.

Unfortunately I haven't been able to receive any concrete examples of
either of these. Hence it's hard to evaluate the tangible benefits.

However this apparently is a pretty wide-spread pattern in existing
mobile devices. I don't have any hard data on how much this is done,
but I did receive two examples:

This is the UA sent by IE browser on a HTC device:
Mozilla/5.0(compatible; MSIE 9.0;Windows phone OS 7.5; Trident/5.0;
IEMobile/9.0; HTC; HD7 T9292)
Here "HTC" is a token to identify the hardware manufacturer and "HD7
T9292" is a token which identifies the device.

UA sent by a built in browser on a Samsung Galaxy device:
Mozilla/5.0(Linux; U; Android 2.3.6;es-es; GT-S5830i
Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0
Mobile Safari/533.1
Here "GT-S5830i" identifies the device.

Let me know what you think.

/ Jonas

Kyle Huey

unread,
Sep 13, 2012, 2:31:43 AM9/13/12
to Jonas Sicking, Gerv Markham, dev-platform
On Thu, Sep 13, 2012 at 8:27 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> Hi All,
>
> For Firefox OS, we are getting requests from partners to add tokens to
> the UA string which identify the hardware device on which Firefox OS
> is running.
>

During the UA discussions for Firefox for Android we explicitly decided not
to do this (after much debate and discussions of the merits). Why should
Firefox OS be different?

- Kyle

Lawrence Mandel

unread,
Sep 13, 2012, 5:08:53 AM9/13/12
to Kyle Huey, dev-platform, Gerv Markham, Jonas Sicking
> > Hi All,
> >
> > For Firefox OS, we are getting requests from partners to add tokens
> > to
> > the UA string which identify the hardware device on which Firefox
> > OS
> > is running.
> >
>
> During the UA discussions for Firefox for Android we explicitly
> decided not
> to do this (after much debate and discussions of the merits). Why
> should
> Firefox OS be different?

As we've seen, sites can be very specific in how they sniff the UA. While I can't say with certainty, differences in the UA between devices has the potential to break mobile Web sites/apps for specific devices.

Another consideration is that we really want our UA to be as stable as possible so that the introduction of new platform support (say, Windows phone) will not require a new evangelism effort.

(Yes, through our evangelism efforts we are promoting feature detection instead of UA sniffing but, as Jonas noted, many sites use UA sniffing and this is the low bar to cross for sites to support Firefox for Android and B2G.)

Lawrence

Dirkjan Ochtman

unread,
Sep 13, 2012, 5:20:06 AM9/13/12
to Jonas Sicking, Gerv Markham, dev-platform
On Thu, Sep 13, 2012 at 8:27 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Let me know what you think.

Since Firefox OS is openly accessible to hardware vendors, wouldn't it
be easy for them to override any decision made by Mozilla if they or
their content partners would prefer it that way?

Putting hardware tokens in the UA certainly seems like something
Mozilla should dislike given earlier discussions on the UA contents.
Maybe Mozilla should offer a credible alternative for the use cases
you mention?

Cheers,

Dirkjan

Lawrence Mandel

unread,
Sep 13, 2012, 5:43:36 AM9/13/12
to Dirkjan Ochtman, dev-platform, Gerv Markham, Jonas Sicking
> > Let me know what you think.
>
> Since Firefox OS is openly accessible to hardware vendors, wouldn't
> it
> be easy for them to override any decision made by Mozilla if they or
> their content partners would prefer it that way?

We have the ability to set the terms for use of the Firefox brand. (As opposed to shipping a phone based on B2G code that does not use any of the Mozilla branding.) I think device identification, in this case through the UA, is a reasonable item to include in the terms of use. However, this is just me thinking out load. I do not know that the UA will be included in those terms.

Lawrence

Nicholas Nethercote

unread,
Sep 13, 2012, 5:49:23 AM9/13/12
to Jonas Sicking, Gerv Markham, dev-platform
On Thu, Sep 13, 2012 at 4:27 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>
> * Some content providers strike deals with hardware manufacturers
> which allow devices made by the manufacturer to access content for
> free. One way that this is implemented is by looking for tokens in UA
> strings and serve content based on this.

I think this is the worst abuse of a UA string I've ever heard of.

Nick

Ben Hearsum

unread,
Sep 13, 2012, 8:16:33 AM9/13/12
to
On 09/13/12 02:27 AM, Jonas Sicking wrote:
> For Firefox OS, we are getting requests from partners to add tokens to
> the UA string which identify the hardware device on which Firefox OS
> is running.

I am very far from an expert here, but I recall during some discussions
a few years ago that specific feature probing was a better way to do
things rather than making assumptions based on the UA string.

Benoit Jacob

unread,
Sep 13, 2012, 9:49:28 AM9/13/12
to Nicholas Nethercote, dev-platform, Gerv Markham, Jonas Sicking
2012/9/13 Nicholas Nethercote <n.neth...@gmail.com>:
This. Also, there is a precedent in the WebGL strings that may be
worth recalling here.

OpenGL exposes some strings, giving the GPU model, vendor name, and
precise driver version. Application developers repeatedly said they
wanted us to expose these through WebGL. At some point, the WebGL spec
called for these strings to be exposed. We argued against this for the
following reasons:

1. any UA-string-like solution is known to give more trouble than it
solves in practice, with applications mis-parsing them or becoming
overly reliant on accidental details of these strings, creating
artificial portability issues.

2. there are privacy issues with this too, both explicit (what you
point out above) and implicit (increasing the number of
uniquely-identifying bits is never great, needs to be justified).

In the end we won this "battle" and the WebGL spec no longer calls for
exposing this info.

That doesn't mean that the application developers' problem wasn't
legitimate, but there should exist better solutions to it: solutions
that don't rely on the fragile parsing of a string and that don't
expose more personal information than is strictly needed.

Again, that was a digression on the WebGL precedent --- hope that was
not too off-topic.

Cheers,
Benoit

>
> Nick
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Gervase Markham

unread,
Sep 13, 2012, 10:21:40 AM9/13/12
to
On 13/09/12 07:27, Jonas Sicking wrote:
> * Some content providers strike deals with hardware manufacturers
> which allow devices made by the manufacturer to access content for
> free. One way that this is implemented is by looking for tokens in UA
> strings and serve content based on this. This is obviously terribly
> insecure and easy to spoof, however the hurdle is large enough that
> this is a "good enough" solution in many cases. I.e. the cost of
> developing a more secure solution, and the cost of losing users due to
> having to ask them to enter passwords etc is higher than the lost
> revenue due to people hacking the system by changing their UA string.

We are in the middle of implementing per-site user agent overriding.
This affects this question in at least two ways.

Firstly, it will be even easier for users of Firefox for Android and/or
B2G to spoof UAs and so get content for free. I can easily imagine
simple instructions on how to set the relevant pref circulating,
especially as one would be able to get free stuff with no side effects
for one's other browsing. (If you set a global pref, you might get
broken content on other sites.)

A minor point: implementing this mechanism might be seen by some as a
way of allowing our users to "bypass security checks" unless we also
come out against this form of 'security'. Or, to put it another way,
saying "yes, sure, do this form of detection" and then implementing an
override mechanism could look shifty.

Secondly, it means that if there is a store or site which categorically
refuses to implement good detection practice, we could put in an
override rule for them which contains some sort of device identifier.
That would be if and only if we decided that this wasn't still
counter-productive, given that they might then shoot us by accidentally
locking out other devices.

> * App stores only want to deliver applications to devices which they
> know will run on the device. Today many stores in our target market
> (Brazil) apparently do this by looking at hardware tokens in UA
> strings. This is a scenario where we strongly want people to do
> capability checking by using the DOM for reasons that we are all way
> too familiar with. However this isn't what stores do today and so we
> would have to convince them to switch to this system. Additionally
> capability checking isn't always perfect, since currently it's hard to
> detect performance metrics.

Can we provide additional mechanisms? It would be awesome if someone
(hello, lazyweb!) could put together a document of common requirements
for which UA sniffing is sometimes used, and the "right" way of finding
the same data. This would allow us to see where the gaps were.

Gerv

Jonas Sicking

unread,
Sep 18, 2012, 4:37:33 AM9/18/12
to Nicholas Nethercote, Gerv Markham, dev-platform
On Thu, Sep 13, 2012 at 2:49 AM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 4:27 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> * Some content providers strike deals with hardware manufacturers
>> which allow devices made by the manufacturer to access content for
>> free. One way that this is implemented is by looking for tokens in UA
>> strings and serve content based on this.
>
> I think this is the worst abuse of a UA string I've ever heard of.

Actually, I would say this is one of the stronger use cases that I've
seen for UA sniffing.

Pulling a random hardware manufacturer name here since I honestly have
no idea who has been creating deals like this. Say that HTC wants to
market their phones towards soccer enthusiasts. They could do this by
paying the local soccer league access to a set of games which will be
streamed from HTCs website.

There is no practical way for them to enforce that only HTC users
access this content. There is no way they could get even a fraction of
HTC customers by chasing down all telephony providers and asking them
who they have been selling HTC devices to. Then getting the home
addresses or phone numbers of all of these people and sending them
mail or text messages with username/passwords for accessing this
content. This is especially true in a country like Brazil where
prepaid accounts are very common. As is people having multiple sim
cards (this is by far more common than just having one sim card).

And even if they did manage to do this, the credentials for how to
access this content would immediately be widely spread among friends.

Filtering on UA tokens is most certainly not a "safe" solution here.
But it seems like information about how to "hack" this would be much
harder for people to figure out, and so would abuse is unlikely to be
nearly as widespread.

So it seems to me that not putting hardware tokens in the UA string
effectively disables this business model.

I can't say that I hold this business model particularly high in
regard. But I also don't feel that it's terrible enough that I can say
that it's a business model I obviously feel ok with disabling.

/ Jonas

Jonas Sicking

unread,
Sep 18, 2012, 4:48:18 AM9/18/12
to Gervase Markham, dev-pl...@lists.mozilla.org
On Thu, Sep 13, 2012 at 7:21 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 13/09/12 07:27, Jonas Sicking wrote:
>>
>> * Some content providers strike deals with hardware manufacturers
>> which allow devices made by the manufacturer to access content for
>> free. One way that this is implemented is by looking for tokens in UA
>> strings and serve content based on this. This is obviously terribly
>> insecure and easy to spoof, however the hurdle is large enough that
>> this is a "good enough" solution in many cases. I.e. the cost of
>> developing a more secure solution, and the cost of losing users due to
>> having to ask them to enter passwords etc is higher than the lost
>> revenue due to people hacking the system by changing their UA string.
>
>
> We are in the middle of implementing per-site user agent overriding. This
> affects this question in at least two ways.
>
> Firstly, it will be even easier for users of Firefox for Android and/or B2G
> to spoof UAs and so get content for free. I can easily imagine simple
> instructions on how to set the relevant pref circulating, especially as one
> would be able to get free stuff with no side effects for one's other
> browsing. (If you set a global pref, you might get broken content on other
> sites.)
>
> A minor point: implementing this mechanism might be seen by some as a way of
> allowing our users to "bypass security checks" unless we also come out
> against this form of 'security'. Or, to put it another way, saying "yes,
> sure, do this form of detection" and then implementing an override mechanism
> could look shifty.

I'm not terribly worried about looking shifty here. I think we should
be clear about saying that this isn't a safe mechanism. If people
still want to use it it's their choice, but we should be clear about
that there's nothing safe about it. We can also point to precedence
set by Opera and various Firefox addons which allow easily customizing
the UA string as proof that people using this as a protection
mechanism should expect abuse.

> Secondly, it means that if there is a store or site which categorically
> refuses to implement good detection practice, we could put in an override
> rule for them which contains some sort of device identifier. That would be
> if and only if we decided that this wasn't still counter-productive, given
> that they might then shoot us by accidentally locking out other devices.

I don't think there's a "good detection practice" for detecting what
hardware the user is running.

I'd also add a third way that per-site UAs affects this.

It means that if we hear about some website deploying content which is
intended to only be exposed to a certain hardware vendor, and that
it's a hardware vendor which we run Firefox OS on, we could change the
UA only for that website to make Firefox OS "work" on that website.
This is especially true if we know about these websites before the
initial deployment of v1.

>> * App stores only want to deliver applications to devices which they
>> know will run on the device. Today many stores in our target market
>> (Brazil) apparently do this by looking at hardware tokens in UA
>> strings. This is a scenario where we strongly want people to do
>> capability checking by using the DOM for reasons that we are all way
>> too familiar with. However this isn't what stores do today and so we
>> would have to convince them to switch to this system. Additionally
>> capability checking isn't always perfect, since currently it's hard to
>> detect performance metrics.
>
> Can we provide additional mechanisms? It would be awesome if someone (hello,
> lazyweb!) could put together a document of common requirements for which UA
> sniffing is sometimes used, and the "right" way of finding the same data.
> This would allow us to see where the gaps were.

That would indeed be awesome.

/ Jonas

Henri Sivonen

unread,
Sep 18, 2012, 5:49:19 AM9/18/12
to dev-pl...@lists.mozilla.org
On Thu, Sep 13, 2012 at 9:27 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> For Firefox OS, we are getting requests from partners to add tokens to
> the UA string which identify the hardware device on which Firefox OS
> is running.

We already had this debate for Firefox for Android. I think we should
apply the same decision (not to expose hardware name) to Firefox OS
for the same reasons.

> * Some content providers strike deals with hardware manufacturers
> which allow devices made by the manufacturer to access content for
> free. One way that this is implemented is by looking for tokens in UA
> strings and serve content based on this. This is obviously terribly
> insecure and easy to spoof, however the hurdle is large enough that
> this is a "good enough" solution in many cases. I.e. the cost of
> developing a more secure solution, and the cost of losing users due to
> having to ask them to enter passwords etc is higher than the lost
> revenue due to people hacking the system by changing their UA string.

Whoa. This has to be one of the worst UA string abuses ever. I think
facilitating this kind of device-dependent Web would be against the
Mission. It would be sad if this sort of thing was permitted for
devices licensed to use Mozilla's trademarks. Remember how we felt
about Chrome/car cross-promotion where a car's site told users to get
Chrome even though Firefox had the relevant features or about Cut the
Rope/IE cross-promotion that required the use of IE to get to levels
that technically would have worked in Firefox.

> * App stores only want to deliver applications to devices which they
> know will run on the device. Today many stores in our target market
> (Brazil) apparently do this by looking at hardware tokens in UA
> strings. This is a scenario where we strongly want people to do
> capability checking by using the DOM for reasons that we are all way
> too familiar with. However this isn't what stores do today and so we
> would have to convince them to switch to this system. Additionally
> capability checking isn't always perfect, since currently it's hard to
> detect performance metrics.

If the app store case ended up being considered legitimate somehow,
app stores have special privileges anyway, so the information could be
exposed via a privileged API instead of broadcasting it to every UA
sniffer around the Web, so I think app store-motivated reasons
shouldn't be treated as reasons put stuff in the UA string.

> However this apparently is a pretty wide-spread pattern in existing
> mobile devices.

And that's a problem, as seen in the threads that lead to the decision
not to expose hardware name in Firefox for Android. When you give Web
developers the opportunity to goof in ways that hurt users, they will:
Exposing the device name is sure to create situations where a site
works/fails depending on device name.

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

Henri Sivonen

unread,
Sep 18, 2012, 5:55:18 AM9/18/12
to dev-pl...@lists.mozilla.org
On Thu, Sep 13, 2012 at 12:20 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:
> Since Firefox OS is openly accessible to hardware vendors, wouldn't it
> be easy for them to override any decision made by Mozilla if they or
> their content partners would prefer it that way?

The code is available, but it doesn't follow the "Firefox OS" name has
to be available for all sorts of modified systems. Consider how the
Firefox name is guarded when it comes to Linux distros shipping
desktop builds.

Henri Sivonen

unread,
Sep 18, 2012, 6:17:16 AM9/18/12
to dev-pl...@lists.mozilla.org
On Thu, Sep 13, 2012 at 9:27 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> * App stores only want to deliver applications to devices which they
> know will run on the device.

This would make sense in an Apple-esque walled garden with relatively
few different device models. However, if Mozilla's app initiative is
successful, there will be more devices than any store has the capacity
to test specifically on. It would be bad if users of less common
devices couldn't get apps just because they haven't been specifically
tested. (Remember Web sites in the 1990s that blocked access from
browsers that the authors hadn't tested. Those were not cool.)

Henri Sivonen

unread,
Sep 18, 2012, 6:30:13 AM9/18/12
to dev-platform
On Tue, Sep 18, 2012 at 11:37 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Say that HTC wants to
> market their phones towards soccer enthusiasts. They could do this by
> paying the local soccer league access to a set of games which will be
> streamed from HTCs website.
...
> I can't say that I hold this business model particularly high in
> regard. But I also don't feel that it's terrible enough that I can say
> that it's a business model I obviously feel ok with disabling.

FWIW, when preferential content access is tied to ISP instead of
hardware brand, Mozilla has gone as far as sending letters to D.C.
against such tying. (Yes, preferred access by HW vendor isn't the same
as by ISP, but I think it's in the ballpark or at least near the
ballpark as far as the Mission goes.)

Mike Hommey

unread,
Sep 18, 2012, 7:22:18 AM9/18/12
to Henri Sivonen, dev-pl...@lists.mozilla.org
Such sites still exist, and they still aren't cool.

Mike

Gervase Markham

unread,
Sep 18, 2012, 8:04:55 AM9/18/12
to Jonas Sicking, Nicholas Nethercote
On 18/09/12 09:37, Jonas Sicking wrote:
> So it seems to me that not putting hardware tokens in the UA string
> effectively disables this business model.

I'm not sure that's true. Having no way to detect the underlying
hardware platform effectively disables this business model - or perhaps,
"business model feature", as it probably doesn't by itself rise to the
level of an entire model.

That takes us back to the question in my other message.

Gerv

Gervase Markham

unread,
Sep 18, 2012, 8:04:57 AM9/18/12
to Jonas Sicking
On 18/09/12 09:48, Jonas Sicking wrote:
> I don't think there's a "good detection practice" for detecting what
> hardware the user is running.

So either:

1) we need to invent one; or

2) we think that there is no legitimate use for the information (or
perhaps that there are a small number, but the usefulness is outweighed
by the footgun potential)

>> Can we provide additional mechanisms? It would be awesome if someone (hello,
>> lazyweb!) could put together a document of common requirements for which UA
>> sniffing is sometimes used, and the "right" way of finding the same data.
>> This would allow us to see where the gaps were.
>
> That would indeed be awesome.

Anyone? :-)

Gerv

Robert Kaiser

unread,
Sep 18, 2012, 12:53:33 PM9/18/12
to
Mike Hommey schrieb:
Right, just nowadays Firefox is usually tested browser that they let in.
Once you browser without the "Firefox" token in a UA string (e.g. try
using SeaMonkey with the "pretend to be Firefox" pref turned off), you
see that those practices are still around.

Robert Kaiser

Robert Kaiser

unread,
Sep 18, 2012, 12:57:47 PM9/18/12
to
Jonas Sicking schrieb:
> For Firefox OS, we are getting requests from partners to add tokens to
> the UA string which identify the hardware device on which Firefox OS
> is running.

I think using the UA is surely the wrong place for this. If we allow the
models that want to be achieved with this at all (and there are good
arguments in this thread against it), I think this should be something
exposed from the navigator object in JS only (e.g.
navigator.manufacturer=ZTE, navigator.vendor=Vivo,
navigator.devicename=foobar or similar).

Robert Kaiser

Jonas Sicking

unread,
Sep 18, 2012, 12:59:25 PM9/18/12
to Henri Sivonen, dev-platform
Do you have links to this. That would be very helpful.

/ Jonas

Justin Dolske

unread,
Sep 18, 2012, 10:35:14 PM9/18/12
to
On 9/18/12 1:37 AM, Jonas Sicking wrote:

>> I think this is the worst abuse of a UA string I've ever heard of.
>
> Actually, I would say this is one of the stronger use cases that I've
> seen for UA sniffing.
...
> So it seems to me that not putting hardware tokens in the UA string
> effectively disables this business model.

I would turn this around: If there are business models that really do
require UA changes, then we should be looking for ways to improve the
web/browser platforms so that there are alternatives. Not every business
(or project, or app, etc) has the luxury of controlling the system
software of end-users. For example, your example was perks for specific
hardware, but what about employee-discounts or subscriber-benefits?

I'd question if a UA change is the only reasonable solution. You could
build an (bundled) add-on that sets a magic Cookie or magic HTTP Header
for various content providers. Or load an carrier.com iframe, and listen
for a postMessage granting a perk (based on having a carrier.com cookie,
or maybe carrier.com is whitelisted for an API to look at hardware specs
-- since that's probably going to be wanted for support/service anyway?).

If I was a content provider, I'd not be thrilled about having to be
fiddling with UA sniffing details for constantly-changing partner deals,
anyway.

Justin

Henri Sivonen

unread,
Sep 19, 2012, 2:12:50 AM9/19/12
to dev-platform

Benjamin Smedberg

unread,
Sep 19, 2012, 11:38:50 AM9/19/12
to Henri Sivonen, dev-platform
I don't believe these statements are relevant to the question.

Net neutrality is about ISPs blocking or throttling content. The danger
is that the ISP can close the internet and coerce website owners into
bad relationships. This is a threat to the internet as a whole. Mozilla
has and should continue to fight against this form of paywall internet.

Content access is about a server owner selling users content through an
ISP. The danger is that popular websites might have the power to coerce
ISPs into paying for popular content. This is a business problem, but
isn't really a threat to the internet in general and is not something
that I think Mozilla should take a stand on or try to prevent.

--BDS

Jonas Sicking

unread,
Sep 20, 2012, 10:26:26 PM9/20/12
to Benjamin Smedberg, Henri Sivonen, dev-platform
Indeed. I think this is a somewhat different issue than net
neutrality. With net neutrality there's a middle party trying to build
a business model by disrupting the traffic between a user and the
content the user is accessing.

Here there's a content provider choosing to distribute its content
using different policies to different groups of people.

The latter is much more similar to how some content providers choose
to only distribute content to people from a particular country. It's
annoying as hell, but it's not a net neutrality issue as I see it.

/ Jonas

Henri Sivonen

unread,
Sep 21, 2012, 4:27:46 AM9/21/12
to dev-platform
On Fri, Sep 21, 2012 at 5:26 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Indeed. I think this is a somewhat different issue than net
> neutrality. With net neutrality there's a middle party trying to build
> a business model by disrupting the traffic between a user and the
> content the user is accessing.
>
> Here there's a content provider choosing to distribute its content
> using different policies to different groups of people.
>
> The latter is much more similar to how some content providers choose
> to only distribute content to people from a particular country. It's
> annoying as hell, but it's not a net neutrality issue as I see it.

It's not an net neutrality issue. I said it was in the ballpark or
near the ballpark. Tying Web site access to a particular hardware
seems very anti-Mission. After all, the Web is supposed to be device
independent. In particular, device independence is both a key strength
of the open Web and a prerequisite for an open Web.

If this is the sort of thing where principles need to be bent in order
to work with hardware partners, I suggest this be accomplished by
sending the business model enablement tokens only to the sites
participating in such arrangements instead of broadcasting them to the
whole Web and giving every site the opportunity to goof with UA
sniffing, since site *will* goof with UA sniffing given the
opportunity.

Benoit Jacob

unread,
Sep 21, 2012, 3:41:11 PM9/21/12
to Henri Sivonen, dev-platform
2012/9/21 Henri Sivonen <hsiv...@iki.fi>:
I would like to +1 on Henri's answer to make it clear that the outcome
of this thread is not quite a nod to go ahead. I feel really
uncomfortable about this, and I haven't heard/understood any reason
yet why this problem can't be solved by using user identifiers
(password/cookies) in the same way as every existing website with
user-specific content does. We even have a user identifier solution
(Persona nee BrowserID), I would like to hear why we're not just
pushing that if our partners do not wish to run their own
authentication system.

Benoit



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

Nicholas Nethercote

unread,
Sep 23, 2012, 9:02:09 PM9/23/12
to Benoit Jacob, Henri Sivonen, dev-platform
On Fri, Sep 21, 2012 at 12:41 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
>
> I would like to +1 on Henri's answer to make it clear that the outcome
> of this thread is not quite a nod to go ahead.

I'd upgrade your "not quite" to "definitely not" :)

We got a bit distracted by the net neutrality comparison, but I'd
summarize the thread as "lots of opposition and little (if any)
support". In the past we've fought tooth and nail to (a) simply the
UA and (b) get people to stop looking at it, for good reasons. We'd
be crazy to change tack now.

Nick

Jason Smith

unread,
Sep 24, 2012, 3:06:17 PM9/24/12
to Benoit Jacob, Henri Sivonen, dev-platform
Just to quickly add in the conclusion that was brought up in the mobile web compatibility meeting about this thread:

We concluded that this isn't a good idea to go forward with for the following reasons:

1. It could promote UA sniffing behavior, which is exactly what were trying to move away from.
2. We're getting lots of push back from WURFL that we need to finalize a consistent UA. Right now, we can't complete our outreach to WURFL because the assumption is that we changing our UA too much too quickly right now.
3. For v1, we probably need to still stick to the original plan for the UA that does include Android in the UA, even though that's sub-optimal to receive Android specific content. We should move to the optimal UA in long-term though without the platform identifier.

Jason Smith

unread,
Sep 24, 2012, 3:06:17 PM9/24/12
to mozilla.de...@googlegroups.com, Benoit Jacob, Henri Sivonen, dev-platform
On Sunday, September 23, 2012 6:02:35 PM UTC-7, Nicholas Nethercote wrote:

Gervase Markham

unread,
Sep 25, 2012, 8:22:32 AM9/25/12
to Jason Smith, Benoit Jacob, Henri Sivonen
On 24/09/12 20:06, Jason Smith wrote:
> 3. For v1, we probably need to still stick to the original plan for
> the UA that does include Android in the UA, even though that's
> sub-optimal to receive Android specific content. We should move to
> the optimal UA in long-term though without the platform identifier.

Do we really think we will be able to make this shift post-v1? Surely
shipping Firefox OS v1 with an Android-containing UA will simply embed
the problem, as lots of sites will assume that the Firefox OS UA
contains the word "Android"?

Gerv


Lawrence Mandel

unread,
Sep 25, 2012, 10:39:53 AM9/25/12
to Gervase Markham, Benoit Jacob, Henri Sivonen, dev-pl...@lists.mozilla.org
I would prefer to look at the specific problems introduced with the OS agnostic UA (drop the "Android" token) and, if a small subset need a workaround, use the whitelist mechanism to solve this for v1.

Note that the "Android" token is not a silver bullet to fix the mobile Web compatibility problem. This is simply one mitigation strategy for obtaining mobile content - and, as we've seen on Firefox for Android, the Firefox for Android UA still falls very short of the mobile Web content served to the Android stock browser and iPhone.

Lawrence

Jason Smith

unread,
Sep 25, 2012, 12:57:18 PM9/25/12
to Gervase Markham, Benoit Jacob, Henri Sivonen, dev-platform, Lawrence Mandel
Hi Gerv,

Don't know. We probably should define a strategy of how we're going to
get web content to move towards supporting the UA without the platform
identifier, so that we don't get endlessly stuck with Android in the UA
for FF OS in the long term.

For the v1 shipment - I originally nominated a bug in triage to ship v1
with the UA without the platform identifier with the whitelist
implemented, but it got unnominated due to a need for a larger
discussion if that's what we want to do for v1. Perhaps it's time to
revisit that discussion and push for v1 support.

Sincerely,
Jason Smith

Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.org/

Gervase Markham

unread,
Sep 26, 2012, 8:57:20 AM9/26/12
to
On 25/09/12 17:57, Jason Smith wrote:
> Don't know. We probably should define a strategy of how we're going to
> get web content to move towards supporting the UA without the platform
> identifier, so that we don't get endlessly stuck with Android in the UA
> for FF OS in the long term.

I've just posted a proposal for a way forward and a policy for adding
sites to the list.

Gerv

Dirkjan Ochtman

unread,
Sep 26, 2012, 9:05:08 AM9/26/12
to Gervase Markham, dev-pl...@lists.mozilla.org
On Wed, Sep 26, 2012 at 2:57 PM, Gervase Markham <ge...@mozilla.org> wrote:
> I've just posted a proposal for a way forward and a policy for adding sites
> to the list.

This is likely to be a stupid question, but: posted where?

Cheers,

Dirkjan

Henri Sivonen

unread,
Sep 26, 2012, 9:25:42 AM9/26/12
to Lawrence Mandel, Benoit Jacob, dev-pl...@lists.mozilla.org, Gervase Markham
On Tue, Sep 25, 2012 at 5:39 PM, Lawrence Mandel <lma...@mozilla.com> wrote:
> I would prefer to look at the specific problems introduced with the OS agnostic UA (drop the "Android" token) and, if a small subset need a workaround, use the whitelist mechanism to solve this for v1.

I think this is the reasonable way forward. Dropping “Android” won’t
get easier after v1. It will get harder.

fbender

unread,
Sep 26, 2012, 12:28:00 PM9/26/12
to dev-platform, Gerv Markham
Am Donnerstag, 13. September 2012 08:28:23 UTC+2 schrieb Jonas Sicking:
> * Some content providers strike deals with hardware manufacturers
>
> which allow devices made by the manufacturer to access content for
>
> free. One way that this is implemented is by looking for tokens in UA
>
> strings and serve content based on this. This is obviously terribly
>
> insecure and easy to spoof, however the hurdle is large enough that
>
> this is a "good enough" solution in many cases. I.e. the cost of
>
> developing a more secure solution, and the cost of losing users due to
>
> having to ask them to enter passwords etc is higher than the lost
>
> revenue due to people hacking the system by changing their UA string.
>
>
>
> * App stores only want to deliver applications to devices which they
>
> know will run on the device. Today many stores in our target market
>
> (Brazil) apparently do this by looking at hardware tokens in UA
>
> strings. This is a scenario where we strongly want people to do
>
> capability checking by using the DOM for reasons that we are all way
>
> too familiar with. However this isn't what stores do today and so we
>
> would have to convince them to switch to this system. Additionally
>
> capability checking isn't always perfect, since currently it's hard to
>
> detect performance metrics.
>

When Microsoft fixed IE, they implemented (A) a compat mode and (B) an updateable white/blacklist containing sites that are always served in compat mode. IMHO this is a good solution for this problem, too.

Fx should go with a platform agnostic UA but, based on a special list, serves a tailored UA. This list should update with newly found incompatible and newly fixed sites. Users can report a problem they have on a site and try the Android-token-UA-string. Mozilla can add the site to the list and even evangelize the creators of the website to update it to feature detection.

The "list feature" can be implemented similar to the phishing protection service.

Other posts mentioned a whitelist but the key feature is the globally updated list, otherwise the user experience degrades enormously.

Shall I file on bug on that?

fbender

unread,
Sep 26, 2012, 12:28:00 PM9/26/12
to mozilla.de...@googlegroups.com, Gerv Markham, dev-platform

Gervase Markham

unread,
Sep 27, 2012, 12:17:25 PM9/27/12
to
On 26/09/12 14:05, Dirkjan Ochtman wrote:
> This is likely to be a stupid question, but: posted where?

I can now say: in this group. Sorry for the delay :-) Dodgy wifi.

Gerv


0 new messages