This bug is about implementing what I described in http://wiki.mozilla.org/User:KaiRo:Dynamic_UA_Spoofing_Mechanism which actually follows a blog post at http://home.kairo.at/blog/2007-06/a_possible_idea_for_user_agents I can't do (all the) work myself, but I may set up a bug bounty for this.

In http://wiki.mozilla.org/User:KaiRo:Dynamic_UA_Spoofing_Mechanism Robert Kaiser, a.k.a. KaiRo, wrote: > This can be adding " (like Firefox)" to the string or something like that, up to using a fully custom UA string specified by the list. SeaMonkey is NOT "like Firefox". If it was, there would be no need for SeaMonkey. Therefore I suggest adding " a Firefox sibling" (or even " a Firefox/1.5.0.12 sibling" if needed), because *that is* what SeaMonkey is.

I have a JS component which observes "http-on-modify-request" and set a temporarily HTTP User Agent with: httpChannel.setRequestHeader("User-Agent", this.tempHTTPUA, false); and a SQLite database for storage. Would that work for you as client side part? p.s. I have yet to look at the phishing detector for its update mechanism, but we use something similar I guess.

That approach at least sounds like a way to look into. If it would work is probably something that depends on reviews ;-) SQLite sounds interesting for storage if the update mechanism works well enough with it.

(In reply to comment #3) > That approach at least sounds like a way to look into. If it would work is > probably something that depends on reviews ;-) For the SeaMonkey project, clearly, but I do wonder why this can't be a mozdev.org project. What are the privacy implications for people using this feature? > SQLite sounds interesting for storage if the update mechanism works well enough > with it. That's still a puzzle, yes. p.s. I'm not working on this for the $1000 bounty, so if you go with my flow, you can use it for something different/more important.

Actually, I don't care if it's available somewhere else, but it's wrong in this bug if there is no plan to integrate it into the SeaMonkey codebase itself. We need a feature like that directly in the mozilla.org SeaMonkey code. If some version of it is also available elsewhere, that's nice, but doesn't really matter to this bug report.

> httpChannel.setRequestHeader("User-Agent", this.tempHTTPUA, false); Yes, that should work for the HTTP headers. But navigator.userAgent is a bit harder. http://mxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#8513 nsNavigator::GetUserAgent just makes an nsIHttpProtocolHandler and asks it for the user agent. nsNavigator can get to the URI, so it could be patched to do what we want. But I don't really see any way for us to hook into that (without changing nsNavigator).

- The UserAgent Switcher extension http://chrispederick.com/work/user-agent-switcher/ allows predefining any number of "spoofed" useragent strings and switching between them on the fly from a submenu of the Tools menu. I can load it on "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033001 SeaMonkey/2.0a1pre" (with extensions.checkCompatibility set to false in about:config) and it works AFAICT (at least, refreshing the about: page changes the UA string displayed at its bottom to the value chosen). By default, it predefines three UA strings, viz. IE7, NS 4.8 and Opera 9.25, all of them on Vista. Of course, you still have to explicitly select one of them in order to get something else than the compiled-in value (as modified by general.useragent.*). - For sites with b0rken UA sniffing, it is also possible to create a new about:config pref with e.g. the name "general.useragent.extra.firesomething" and the value "NOT Firefox/3.0pre" (or "a Firefox/3.0pre sibling:" or whatever). This will, IIUC, have sites mistake us for Firefox for purposes of access-control but not for market-share statistics. (This addresses comment #1 by means of a pref. No restart necessary.) - I believe this is the kind of thing that can be left for extensions to do and not included in the main browser (beyond what is there already). Therefore I move this be resolved WONTFIX, especially since there already exists at least one extension which does it, and about:config also provides a less fancy method for it, but still on-the-fly (i.e., without restart).

P.S. By "creating a new pref", I meant that the pref doesn't exist in about:config by default; but if the user creates it, it will be honored. No change necessary in the existing Sm code.

> since there already exists at least one extension which does it the extension doesn't do what this bug is requesting, which is to have the useragent depend on the remote hostname

Sorry, Andy, what you're talking about is bug 80658 (which I believe ought to be lmeft open but "Future" unless an extension can be found for it). I've seen nothing in _this_ bug's comments which requires automatic sitewise UA spoofing.

From the bug URL: "The goal of this project is to implement a solution that dynamically adjusts the User-Agent ("UA") HTTP header depending on which domain the data is being requested from, along with a mechanism to encourage users to actively take part in evangelizing." From my point of view, this bug would depend on bug 80658 (the core part). That one is to allow site-specific UA. This one is to apply site-specific UA's based on some mechanism, as black-list and domain black-list.

Tony: I reported this bug, I exactly know what it's about, and bug 80658 is an integral part of what this bug tries to achieve, but we probably wouldn't accept a fix for bug 80658 without the added notification to the user. Such an action should never happen without notification in UI.

(In reply to comment #13) > Tony: I reported this bug, I exactly know what it's about, and bug 80658 is an > integral part of what this bug tries to achieve, but we probably wouldn't > accept a fix for bug 80658 without the added notification to the user. Such an > action should never happen without notification in UI. > <shrug>If you say so...</shrug> I guess I misunderstood then. At least one more "old bug" got RESOLVED.

Then, "Phishing Protection" is working with SM? http://developer.mozilla.org/en/docs/Adding_phishing_protection_data_providers That URIs list mechanism is almost identical to this bug.

The "Phishing Protection" feature has not yet been added to SM, but the mechanism itself would surely work, and the mechanism for fetching the list could be the same, true. As a first step, it's more important to get the dynamic UA switching functionality itself into SM, the list fetching can be a second step. See also http://wiki.mozilla.org/Community:SummerOfCode08#SeaMonkey where I offer mentorship for someone who wants to attack that "anti-discrimination extenion" part for a student taking part in Google Summer of Code - applications wanted!

(In reply to comment #16) > and the mechanism for fetching the list could be the same, true. As > a first step, it's more important to get the dynamic UA switching > functionality itself into SM, the list fetching can be a second step. Dynamic UA switching is, in other words, how to *reload* a given page either with or without sniffed UA string. Threfore, the best place to invoke is the class which implements nsIWebNavigation::loadURI(...), i.e. nsDocShell. Indeed, Phishing Protection introduced a new flag LOAD_FLAGS_BYPASS_CLASSIFIER http://lxr.mozilla.org/mozilla/source/docshell/base/nsIWebNavigation.idl#204 to merge that functionality into error-handling UI. (bug 400731 and bug 413938) Then now it's easy to load a page with or without malformed-info-check, in terms of UI. All UI should do is to set the flag on calling loadURI(...). And that's what bug 398776 and bug 399233 mean to be. So I wonder whether extensions such as one hooking "http-on-modify-request" is the right way to go. That can be rather complicated than what we expected. If I caught "http-on-modify-request" at nsIObserver::observe in a extension, I have no idea how to communicate with the user, except just prompting a OK/Cancel dialog...

> Dynamic UA switching is, in other words, how to *reload* a given page No. The user agent sent in the http header when the page is loaded (the first time) should be dependent on the host. navigator.userAgent should match whatever was sent in the http headers. > invoke is the class which implements nsIWebNavigation::loadURI(...), Hmm, how would docshell set the useragent? Also, the user agent needs to get sent in http headers for things other than web pages (also css and js), which won't go through LoadURI. The observer might simply display a notification bar, with button(s) to change the user-agent for that site and/or provide info of what user agent was sent.

(In reply to comment #18) > The observer might simply display a notification bar, with button(s) to change > the user-agent for that site and/or provide info of what user agent was sent. A notification bar is immodal. So you can't *suspend* the http reqeust at obsever. You have to *cancel* the first request, and resend the request after user's decision. > No. i.e. You are wrong. And that's why I said "OK/Cancel dialog", which is a modal UI. Given UI is modal, there's no problem with "http-on-modify-request".

The user doesn't need to decide anything, we just send the request with the different UA string if the requested domain name is in the spoofing list (and we determine which spoof we use just by the requested domain name). The notification bar is just shown to tell the user that we needed to this and should provide him with info about what this means and hooks for anti-discrimination activities.

(In reply to comment #20) > The user doesn't need to decide anything, we just send the request with the > different UA string if the requested domain name is in the spoofing list (and > we determine which spoof we use just by the requested domain name). The > notification bar is just shown to tell the user that we needed to this and > should provide him with info about what this means and hooks for > anti-discrimination activities. Aha. Then it sounds more realistic. Andrew Schultz, I'm sorry for that.

KaiRo, now that we are permanently spoofing Firefox, is this bug still wanted?

Let's just assume that it won't be done.

Do you know which bug adds the spoofing of Firefox? I haven't been able to find it.

Core bug 581008 removed the ".extra." preferences to add arbitrary items to the user-agent string, then bug 591327 made the necessary adjustments to SeaMonkey along with a checkbox in the preferences UI and setting a "true" default.

Please leave that bug set to WONTFIX.

Sorry, wasn't intentional. I think my new installation of noscript kept the status as the default when I made a comment (I didn't get a mid-air collision).

Forward DUPing to Bug 786613