Closed Bug 572665 Opened 14 years ago Closed 14 years ago

Make the UA string of non-Firefox-branded builds say "Firefox"

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 588874

People

(Reporter: hsivonen, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: privacy) 

Steps to reproduce:
 1) Load http://www.delorie.com:81/some/url.txt in a nightly build.
 2) Load http://www.delorie.com:81/some/url.txt in a Firefox release.
 3) Load http://www.delorie.com:81/some/url.txt in a browser installed from a package called firefox-3.5 in jaunty-backport on Ubuntu Jaunty.

Actual results:
The UA string of the release build says "Firefox", the UA string of the nightly says "Minefield" and the backport says "Shiretoko". The variability can by used for fingerprinting. See https://panopticlick.eff.org/ Furthermore, putting the best-know name (Firefox) in the UA string gives sites an opportunity to sniff for "Firefox" and cause breakage in nightlies and in technically equally capable non-Firefox-branded builds. When this happens with nightlies, there's a risk that the breakage gets treated as a code regression by mistake, which wastes people's time.

Expected results:
Expected either Firefox-branded builds not to have the string "Firefox/" followed by version in the UA string or expected builds made without turning Firefox branding on to say "Firefox" where the un-branding name is currently used.
See bug 385999 for a discussion. Note that the name Firefox is trademarked, it should *not* be used by other browsers.
(In reply to comment #1)
> See bug 385999 for a discussion.

If that WONTFIXing holds, then I think other non-Firefox-branded Gecko-based browsers need to say "Firefox" in their UA string in order to enjoy full Gecko functionality on the Web. It's unfortunate, but the way the UA string reacts with sites is functionality-relevant and less of branding issue.

> Note that the name Firefox is trademarked, it
> should *not* be used by other browsers.

Do the lawyers say it can't be put in the UA string? Note that various competitors put "Mozilla" in their UA strings and Chrome puts "Safari". Opera ships with a built-in feature to optionally put "Firefox" in the UA string. Is there a true legal problem with Mozilla itself making the build system put "Firefox" in the UA string of otherwise unbranded builds?

Even if we didn't care about downstream distributors who don't build with Firefox branding, I think it would make reduce our rate of false regression bugs if nightly builds and self-built builds were indistinguishable from Firefox release builds for the purpose of UA sniffing.
The page is broken if it does UA sniffing based on the string "Firefox" -> http://geckoisgecko.info/
(In reply to comment #3)
> The page is broken if it does UA sniffing based on the string "Firefox" ->
> http://geckoisgecko.info/

Maybe, but it's an obvious outcome of putting the most-recognized name of the most popular Gecko-based browser in its UA string while not putting it in the UA string of every Gecko-based browser.

See also http://en.wikipedia.org/wiki/Attractive_nuisance . Blaming the sites doesn't help with the waste of bugs mistakenly thought to be code regressions on the Gecko side.
If a site checks the UA string for "Firefox" in order to know whether the browser has Gecko capabilities, what is broken is the site, not Firefox and not the non-Firefox Gecko browser. The site in question should be evangelized, see http://www.mozilla.org/projects/tech-evangelism/site/procedures.html , and shown hrrp://geckoisgecko.org/ as part of that evangelization.

The fact that Firefox's UA includes "Firefox" (but only in release builds), and that SeaMonkey, kazehakaze et al. don't, is intentional. => INVALID.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
oops: s/hrrp/http/
Reopening. See comment #4.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to comment #7)
> Reopening. See comment #4.

I believe that comment #4 is mistaken, see comment #5.

Mike, as "owner" of the Firefox module, you have more authority than I do. What do you think?
I don't believe there is any trademark issue with Firefox in the UA string of non-branded builds; it is not a representation to the consumer, it's a piece of protocol data.

Of the two options, I support having Firefox be in the UA for non-branded builds, but I'm not entirely sure that we need to pick one of the options.  It's a topic for some more discussion, and then probably I end up picking something and being hated by the 49.5% of the world on the other side of the decision. :-)
Hm, all right. What do you think of the reporter's idea of making "Firefox" a mandatory part of every Gecko browser's UA? It's hard for me to believe that the makers of SeaMonkey, Galeon, K-Meleon, et al., would like it much, not to mention the trademark issues, e.g. in relation with IceWeasel.
As I said in comment 9, I don't think that there *are* trademark issues in the protocol elements.  Furthermore, I don't think I am in a position to make any part of it mandatory for other browsers.  They might choose to include the string, as others have chosen in the past (IE, WebKit, etc.) for greater compatibility with naive sniffing, or they might prefer to remain distinct to show up better on usage surveys.  It's up to each project to choose their trade-offs on these.

I believe that this is a Firefox app-policy issue, rather than an HTTP technology one, so recategorizing appropriately.
Component: Networking: HTTP → General
Product: Core → Firefox
QA Contact: networking.http → general
(In reply to comment #10)
> Hm, all right. What do you think of the reporter's idea of making "Firefox" a
> mandatory part of every Gecko browser's UA?

I think the Gecko codebase should default to having the same UA string as branded Firefox builds. I also think that it wouldn't be Open Source-y to make a certain UA string mandatory for downstream. If other Gecko-based browsers don't want to be successful with sniffers that look for "Firefox", other Gecko-based browsers should be free to use a different UA string. 

If SeaMonkey wants to make its usage known and wants to be successful with sniffing, it would make sense for SeaMonkey to say "Firefox/x.y SeaMonkey/i.j". But if they instead want to say just "SeaMonkey/i.j", that's their decision.

(It's not really productive to argue the sites shouldn't be looking for "Firefox" if Firefox puts "Firefox" there. See http://en.wikipedia.org/wiki/Affordance and http://en.wikipedia.org/wiki/Attractive_nuisance )
IMHO, it's just as wrong for SeaMonkey or Camino to state "Firefox/x.y" as it is wrong for MSIE to state "Mozilla/x.y". The right way is to do targeted spoofing for those sites that suck enough that they can't cope with correct US strings (and warn the user about that site being sent a faked browser ID because it can't cope with the real one, possibly even enabling the user to tell the site how to improve), and use a simple and clear UA where possible.
I have put down my opinion a long time ago in http://home.kairo.at/blog/2007-06/the_fight_for_the_suckiest_ua_string
I also proposed the targeted spoofing mechanism in http://home.kairo.at/blog/2007-06/a_possible_idea_for_user_agents but currently, our platform forbids implementing it by making navigator.* immutable.
It is not Mozilla's responsibility as a browser vendor to stop UA sniffing in its browser design: that is a job for outreach programs like Tech Evangelism.

Firefox is Firefox; Seamonkey is Seamonkey.  The two are different and should not both have Firefox in the UA string or both lack it.  The need for this discussion is caused by poor design by web developers, and removing "Firefox" from the UA string or adding "Firefox" to all UA strings will only make that worse by breaking more web sites with the former or encouraging more poorly designed sniffing with the latter.
Some site are also just sniffing the browser version or the gecko version.
Note that the patch in bug 581008 currently up for review would introduce boolean prefs for compatibility tokens, thus adding a Firefox/x.x.x token if the user desires, it while retaining the original application identification.
rsx, see bug 572659 comment 19.

FWIW, I'm for removing the "Firefox" from the UA string, in the spirit of comment 4. It should not make any difference to the site whether it's a Firefox or IceWeasel or Seamonkey, so there's no legitimate interest to know.
... don't underestimate SeaMonkey and Camino users proudly showing in their user-agent strings that they are /not/ using Firefox.   ;-)

> see bug 572659 comment 19.

Which part? I'm not talking about overriding the entire UA string, and having both application tokens or just the main one shouldn't be significant enough
for fingerprinting.
> > see bug 572659 comment 19.

> Which part?

The first part that says 'change *anything*, and you're much more likely to be detected'. Seamonkey may differ (towards the website) in minor ways from Firefox, and a Seamonkey user changing a pref to pretend Firefox is rare and detectable and thus fingerprintable.
It's not rare, it's the standard advise given to SeaMonkey users running into issues with sites, as it's simply needed to make certain sites work. On the contrary, making it a boolean preference with a standard additional token as proposed in the other bug would make SeaMonkey users less fingerprintable given that there would be less variation on what the individual users adds.

I'd vote for WONTFIX on this bug here if bug 581008 makes it as proposed.
(In reply to comment #17)
> FWIW, I'm for removing the "Firefox" from the UA string, in the spirit of
> comment 4. It should not make any difference to the site whether it's a Firefox
> or IceWeasel or Seamonkey, so there's no legitimate interest to know.

That would implode the perceived market share of any non-Firefox Gecko browser to ZERO, as the only market share measure common on the web is statistics made of UA strings.
You'd be free to add "Seamonkey/1.0" to the UA string, if you like.
I personally would rather use the updater stats and publish these numbers. (As it stands, the perceived market share is already zero in many minds, otherwise the sites wouldn't be so stupid to equate Firefox = Gecko.)
As long as we still have Gecko in the UA, I don't see the need to remove productNames from the end of the UA, though i hope it can be coded now instead of using the extra.* or override to deal with it.  The problem I see is if we remove the productName altogether will certainly affect such stats, with stats, its easy to see if multiple or differentiating products are worth all the volunteer efforts.
(In reply to comment #18)
> ... don't underestimate SeaMonkey and Camino users proudly showing in their
> user-agent strings that they are /not/ using Firefox.   ;-)

This bug is about the app you get when you build the default browser product from mozilla-central or from a relbranch for that browser product.

Camino already puts "Firefox/" in its UA string and SeaMonkey can do whatever the leadership of the SeaMonkey project decides with its UA string.
Most Mozilla sites (AMO, SUMO, mozilla.com) need to know when the user is actually using Firefox vs. something else kinda like Firefox. If this is adopted, these sites will need a way to figure that out easily as with bug 572659.
(In reply to comment #25)
> Most Mozilla sites (AMO, SUMO, mozilla.com) need to know when the user is
> actually using Firefox vs. something else kinda like Firefox. If this is
> adopted, these sites will need a way to figure that out easily as with bug
> 572659.

What's the problem scenario? That is, why would a user with a browser whose user-facing branding doesn't say "Firefox" come to Firefox support forums and ask a question without mentioning that (s)he isn't using Firefox? Note that non-MoCo supported builds already say "Firefox" in the UA string (in Linux distros). How do you handle Camino users?
The sites listed there do not target Camino anyhow, so that's not a topic for them. That said, e.g. AMO warns users of FF < 3.6 that they need an add-on to support personas, and will warn SeaMonkey users < 2.1a3 (or so) that personas are not supported for them. Things like that tend to come along.
BTW, we currently are detecting the used browser, UI locale, and OS on the SeaMonkey website to display the preferred download for them - one of those is already impossible with the ongoing crippling of the UA, and it looks like user experience for that will need to become even worse thanks to so-called "improvements" that are not really in the interest of most users. Anyone who never looks into Cookie settings or clicks any Facebook "Like" button anywhere clearly doesn't care a bit about fingerprintability, but you seem to assume everyone does.
Blocks: 584683
Blocks: 586165
Changing summary to reflect reality. We'll never drop "Firefox" from branded builds, but making nonbranded builds use it might be possible.
Summary: Either make the UA string for Firefox not say "Firefox" or make the UA string of non-Firefox-branded builds say "Firefox" → Make the UA string of non-Firefox-branded builds say "Firefox"
> We'll never drop "Firefox" from branded builds

That's fair, but I think it at least warrants a reason.
(See e.g. comment 4 and comment 17 for opposite reasons. Adding "Firefox" to IceWeasel is ugly, welcomes misuse and doesn't solve the problem long-term.)
Doesn't need to block b5.
No longer blocks: 586165
(In reply to comment #0)
> Steps to reproduce:
>  1) Load http://www.delorie.com:81/some/url.txt in a nightly build.
>  2) Load http://www.delorie.com:81/some/url.txt in a Firefox release.
>  3) Load http://www.delorie.com:81/some/url.txt in a browser installed from a
> package called firefox-3.5 in jaunty-backport on Ubuntu Jaunty.
> 
> Actual results:
> The UA string of the release build says "Firefox", the UA string of the nightly
> says "Minefield" and the backport says "Shiretoko". The variability can by used
> for fingerprinting. See https://panopticlick.eff.org/ Furthermore, putting the
> best-know name (Firefox) in the UA string gives sites an opportunity to sniff
> for "Firefox" and cause breakage in nightlies and in technically equally
> capable non-Firefox-branded builds. When this happens with nightlies, there's a
> risk that the breakage gets treated as a code regression by mistake, which
> wastes people's time.

Bug 588874 addressed this.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.