On Thu, Sep 13, 2012 at 7:21 AM, Gervase Markham <g...@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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
