Julian Aubourg <[email protected]> skreiv Tue, 09 Oct 2012 15:32:42 +0200
I agree the use cases do not seem compelling. But I know I'm generally
surprised by what people can and will do. What problem did you encounter
that would have necessitated to change the User-Agent string, Hallvord?
I've had trouble writing extensions and user scripts to work around
backend sniffing, due to being unable to simply set User-Agent for a
specific script-initiated request and get the "correct" content. As I've
attempted to explain to Anne, I think this experience is relevant to
scripts using CORS, because they also want to interact with backends the
script author(s) don't choose or control.
Interacting, in a sane way, with a backend that does browser sniffing is a
*very* compelling use case to me.
Just think what a
malicious script could do to browser usage statistics
The changed User-Agent will of course only be sent with the requests
initiated by the script, all other requests sent from the browser will be
normal. Hence, the information loss will IMO be minimal and probably have
no real-world impact on browser stats.
Also, there actually
are security concerns. While I trust open-source browsers (and mainstream
close-source ones) not to try and trick servers into malicious
operations,
I can't say the same for the whole web, especially malicious ad scripts.
If your backend really relies on User-Agent header values to avoid being
"tricked" into malicious operations you should take your site offline for
a while and fix that ;-). Any malicious Perl/PHP/Ruby/Shell script a
hacker or script kiddie might try to use against your site can already
fake User-Agent.
A malicious ad script would presumably currently have the user's web
browser's User-Agent sent with any requests it would make to your site, so
unless you want to guard yourself from users running
HackedMaliciousEvilWebBrowser 1.0 I don't see what protection you would
loose from allowing XHR-set User-Agent.
--
Hallvord R. M. Steen
Core tester, Opera Software
