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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
