On 23/01/13 02:45, Lawrence Mandel wrote: > As a mitigation strategy for sites serving non mobile content to B2G, > we added a UA override (domain whitelist) mechanism that allows B2G > to send a custom UA to a specific domain
...and then we file a bug on evangelising the site to fix itself. > 1. Should we continue to enforce a top sites threshold? If so, is 100 > the right number? Is it reasonable to rely on Alexa data? Yes, for the moment, and yes. :-) > 2. Should > we limit the whitelist to target B2G locales? Should we accept > overrides for any locale? I think we should limit overriding. When you override a site and thereby make it work, you reduce the pain for Joe Average user, but you also reduce the user's incentive to complain and also the site's incentive to fix itself. (And if they fix it right, it's good for the whole web and user choice, not just us.) Which is why it's good to file an evangelism bug when we add an override, to make sure the issue is not totally forgotten. Unless the pain for average B2G users in our target markets is great, I would rather have people contacting sites and asking them to fix themselves rather than being entirely unaware of the problem because the site has had an override put in place. Also, when we override, we are effectively lying to the site. If the site takes decisions based on that lie that actually work out badly for us, it's our problem, not theirs. The more overrides we have, the more we are going to have to do regular compatibility checking to make sure the lies we are telling aren't actually degrading the user experience where once they improved it. This is not simply about adding the word "Android"; for quite a few sites, we are currently pretending (for all versions of B2G) to be Chrome on a Galaxy Nexus! I worry that this will not end well. > 3. Should we limit the overall size of the > whitelist? Are the technical/performance implications? Each whitelist entry is a line in prefs.js. We'd need an engineer to tell us the impact on e.g. startup time of each additional line. Gerv _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
