|Adding hardware tokens to UA string||Jonas Sicking||9/12/12 11:28 PM|
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
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
Here "GT-S5830i" identifies the device.
Let me know what you think.
|Re: Adding hardware tokens to UA string||Kyle Huey||9/12/12 11:31 PM|
On Thu, Sep 13, 2012 at 8:27 AM, Jonas Sicking <email@example.com> wrote: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?
|Re: Adding hardware tokens to UA string||Lawrence Mandel||9/13/12 2:08 AM|
> > Hi All,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.)
|Re: Adding hardware tokens to UA string||Dirkjan Ochtman||9/13/12 2:20 AM|
On Thu, Sep 13, 2012 at 8:27 AM, Jonas Sicking <firstname.lastname@example.org> 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
|Re: Adding hardware tokens to UA string||Lawrence Mandel||9/13/12 2:43 AM|
|Re: Adding hardware tokens to UA string||Nicholas Nethercote||9/13/12 2:49 AM|
On Thu, Sep 13, 2012 at 4:27 PM, Jonas Sicking <email@example.com> wrote:I think this is the worst abuse of a UA string I've ever heard of.
|Re: Adding hardware tokens to UA string||Ben Hearsum||9/13/12 5:16 AM|
On 09/13/12 02:27 AM, Jonas Sicking wrote: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.
|Re: Adding hardware tokens to UA string||Benoit Jacob||9/13/12 6:49 AM|
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
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.
> dev-platform mailing list
|Re: Adding hardware tokens to UA string||Gervase Markham||9/13/12 7:21 AM|
On 13/09/12 07:27, Jonas Sicking wrote: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.
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.
|Re: Adding hardware tokens to UA string||Jonas Sicking||9/18/12 1:38 AM|
On Thu, Sep 13, 2012 at 2:49 AM, Nicholas Nethercote
> On Thu, Sep 13, 2012 at 4:27 PM, Jonas Sicking <firstname.lastname@example.org> 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.
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.
|Re: Adding hardware tokens to UA string||Jonas Sicking||9/18/12 1:48 AM|
On Thu, Sep 13, 2012 at 7:21 AM, Gervase Markham <ge...@mozilla.org> wrote: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.
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.
That would indeed be awesome.
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/18/12 2:49 AM|
On Thu, Sep 13, 2012 at 9:27 AM, Jonas Sicking <email@example.com> wrote: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.
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.
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.
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.
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/18/12 2:55 AM|
On Thu, Sep 13, 2012 at 12:20 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote: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
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/18/12 3:17 AM|
On Thu, Sep 13, 2012 at 9:27 AM, Jonas Sicking <firstname.lastname@example.org> wrote:
> * App stores only want to deliver applications to devices which theyThis 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.)
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/18/12 3:30 AM|
On Tue, Sep 18, 2012 at 11:37 AM, Jonas Sicking <email@example.com> wrote:...
> I can't say that I hold this business model particularly high inFWIW, 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.)
|Re: Adding hardware tokens to UA string||Mike Hommey||9/18/12 4:22 AM|
Such sites still exist, and they still aren't cool.
|Re: Adding hardware tokens to UA string||Gervase Markham||9/18/12 5:04 AM|
On 18/09/12 09:37, Jonas Sicking wrote: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.
|Re: Adding hardware tokens to UA string||Gervase Markham||9/18/12 5:04 AM|
On 18/09/12 09:48, Jonas Sicking wrote: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)
|Re: Adding hardware tokens to UA string||Robert Kaiser||9/18/12 9:53 AM|
Mike Hommey schrieb:
> On Tue, Sep 18, 2012 at 01:17:16PM +0300, Henri Sivonen wrote:
>> (Remember Web sites in the 1990s that blocked access fromRight, 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.
|Re: Adding hardware tokens to UA string||Robert Kaiser||9/18/12 9:57 AM|
Jonas Sicking schrieb:
> For Firefox OS, we are getting requests from partners to add tokens toI 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.devicename=foobar or similar).
|Re: Adding hardware tokens to UA string||Jonas Sicking||9/18/12 10:00 AM|
Do you have links to this. That would be very helpful.
|Re: Adding hardware tokens to UA string||Justin Dolske||9/18/12 7:35 PM|
On 9/18/12 1:37 AM, Jonas Sicking wrote:...
> So it seems to me that not putting hardware tokens in the UA stringI 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,
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/18/12 11:13 PM|
On Tue, Sep 18, 2012 at 7:59 PM, Jonas Sicking <firstname.lastname@example.org> wrote:
>> FWIW, when preferential content access is tied to ISP instead of2009: https://blog.mozilla.org/gen/2009/10/19/mozilla-signs-pro-net-neutrality-letter-to-fcc/
|Re: Adding hardware tokens to UA string||Benjamin Smedberg||9/19/12 8:39 AM|
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.
|Re: Adding hardware tokens to UA string||Jonas Sicking||9/20/12 7:27 PM|
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.
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/21/12 1:27 AM|
On Fri, Sep 21, 2012 at 5:26 AM, Jonas Sicking <email@example.com> wrote: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
|Re: Adding hardware tokens to UA string||Benoit Jacob||9/21/12 12:41 PM|
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
|Re: Adding hardware tokens to UA string||Nicholas Nethercote||9/23/12 6:02 PM|
On Fri, Sep 21, 2012 at 12:41 PM, Benoit Jacob <jacob.b...@gmail.com> wrote: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.
|Re: Adding hardware tokens to UA string||Jason Smith||9/24/12 12:06 PM|
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.
|Re: Adding hardware tokens to UA string||Jason Smith||9/24/12 12:06 PM|
On Sunday, September 23, 2012 6:02:35 PM UTC-7, Nicholas Nethercote wrote:
|Re: Adding hardware tokens to UA string||Gervase Markham||9/25/12 5:22 AM|
On 24/09/12 20:06, Jason Smith wrote: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"?
|Re: Adding hardware tokens to UA string||Lawrence Mandel||9/25/12 7:39 AM|
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.
|Re: Adding hardware tokens to UA string||Jason Smith||9/25/12 9:57 AM|
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.
Desktop QA Engineer
|Re: Adding hardware tokens to UA string||Gervase Markham||9/26/12 5:57 AM|
On 25/09/12 17:57, Jason Smith wrote:I've just posted a proposal for a way forward and a policy for adding
sites to the list.
|Re: Adding hardware tokens to UA string||Dirkjan Ochtman||9/26/12 6:05 AM|
On Wed, Sep 26, 2012 at 2:57 PM, Gervase Markham <ge...@mozilla.org> wrote:This is likely to be a stupid question, but: posted where?
|Re: Adding hardware tokens to UA string||Henri Sivonen||9/26/12 6:25 AM|
On Tue, Sep 25, 2012 at 5:39 PM, Lawrence Mandel <lma...@mozilla.com> wrote:I think this is the reasonable way forward. Dropping “Android” won’t
get easier after v1. It will get harder.
|Re: Adding hardware tokens to UA string||Florian Bender||9/26/12 9:28 AM|
Am Donnerstag, 13. September 2012 08:28:23 UTC+2 schrieb Jonas Sicking:
> * Some content providers strike deals with hardware manufacturers
> * App stores only want to deliver applications to devices which they
> know will run on the device. Today many stores in our target marketWhen 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?
|Re: Adding hardware tokens to UA string||Florian Bender||9/26/12 9:28 AM|
|Re: Adding hardware tokens to UA string||Gervase Markham||9/27/12 9:17 AM|
On 26/09/12 14:05, Dirkjan Ochtman wrote:I can now say: in this group. Sorry for the delay :-) Dodgy wifi.