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