breaking sites for what?

[Asa Dotzler]

I'd like to better understand why we think it's the right trade-off to
break major websites in order to shave a some bits off of our HTTP headers.

http://hsivonen.iki.fi/accept-charset/
https://bugzilla.mozilla.org/show_bug.cgi?id=572652

What is the user benefit here that outweighs the loss of compatibility
with a major site -- in this case, the second most popular translation
service on the Web? When a user who depends on this site moves to IE or
Chrome, have we helped Firefox or the Web?

I don't think this is the right trade-off. I think we've become far to
comfortable breaking compatibility for minor or non-wins. We do it with
add-ons, changing interfaces for "code cleanup" and other changes with
no obvious user benefit and here we're apparently doing it to websites
because we want a bit less "cruft" in our HTTP headers.

- A

[L. David Baron]

On Tuesday 2012-02-07 00:09 -0800, Asa Dotzler wrote:
> I'd like to better understand why we think it's the right trade-off to
> break major websites in order to shave a some bits off of our HTTP
> headers.
>
> http://hsivonen.iki.fi/accept-charset/

My understanding is that the major benefit is that reducing the
number of bytes in the initial HTTP request can (depending on the
other data in the request, which varies) push it across the
threshhold of being a lower number of packets, which can improve the
latency of starting an HTTP connection (particularly important for
mobile).

> I don't think this is the right trade-off. I think we've become far
> to comfortable breaking compatibility for minor or non-wins. We do
> it with add-ons, changing interfaces for "code cleanup" and other
> changes with no obvious user benefit and here we're apparently doing
> it to websites because we want a bit less "cruft" in our HTTP
> headers.

Code cleanup has major benefits: it improves our ability to
implement new things that benefit users and to get new contributors
working on Mozilla, and leaving extra code for compatibility has
costs in code size and can have costs in memory use or speed as
well.

(Also, it seems like this discussion belongs on dev-platform rather
than dev-apps-firefox.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Asa Dotzler]

On 2/7/2012 12:34 AM, L. David Baron wrote:
> On Tuesday 2012-02-07 00:09 -0800, Asa Dotzler wrote:
>> I'd like to better understand why we think it's the right trade-off to
>> break major websites in order to shave a some bits off of our HTTP
>> headers.
>>
>> http://hsivonen.iki.fi/accept-charset/
>
> My understanding is that the major benefit is that reducing the
> number of bytes in the initial HTTP request can (depending on the
> other data in the request, which varies) push it across the
> threshhold of being a lower number of packets, which can improve the
> latency of starting an HTTP connection (particularly important for
> mobile).

Without data about how often we get improved latency benefits, I can't
see knowing breaking the second most popular (and original, if my memory
serves) translation service on the Web as a win for our users.

>
>> I don't think this is the right trade-off. I think we've become far
>> to comfortable breaking compatibility for minor or non-wins. We do
>> it with add-ons, changing interfaces for "code cleanup" and other
>> changes with no obvious user benefit and here we're apparently doing
>> it to websites because we want a bit less "cruft" in our HTTP
>> headers.
>
> Code cleanup has major benefits: it improves our ability to
> implement new things that benefit users and to get new contributors
> working on Mozilla, and leaving extra code for compatibility has
> costs in code size and can have costs in memory use or speed as
> well.

And breaking features our users depend on improves all the other
browsers' ability to poach our users. I realize it has costs. I'm
questioning the balance here. I think we're being too cavalier with
compatibility.

> (Also, it seems like this discussion belongs on dev-platform rather
> than dev-apps-firefox.)

Probably so.

- A

[Henri Sivonen]

On Tue, Feb 7, 2012 at 10:09 AM, Asa Dotzler <a...@mozilla.org> wrote:
> I'd like to better understand why we think it's the right trade-off to break
> major websites in order to shave a some bits off of our HTTP headers.
>
> http://hsivonen.iki.fi/accept-charset/
> https://bugzilla.mozilla.org/show_bug.cgi?id=572652
>
> What is the user benefit here that outweighs the loss of compatibility with
> a major site -- in this case, the second most popular translation service on
> the Web?

First of all, breaking one major site is nothing new. For example
Facebook pokes at the edges of the Web platform so hard that sometimes
in order to make the platform better, we break Facebook. Native JSON
and the unification of namespaces in HTML and XHTML DOMs come to mind.
With Facebook this is OK, because developing a Web site is a core
competence of Facebook and they are remarkable quick to adapt to
browser fixes.

Also, we break various Google properties all the time. Often because
Google is doing it wrong with browser sniffing but also because we
first added some moz-prefixed stuff and then take it away or change
it. In the case of Firefox 10, various Google properties had breakage
because the version number started having double digits. The situation
with Google is pretty much OK, too. Developing Web apps is a core
competence of Google, too. They can and do adapt to browser changes.

Because developing Web sites/apps is the core competence of companies
like Facebook and Google and because the changes usually involve them
choosing a code path *they already have in place* for WebKit or IE,
"breaking" Facebook/Google sites/apps in a way that causes us to ask
them to put us on their already-existing WebKit (or IE) codepath is,
in my view, *much* less of a problem than breaking random long-tail
sites that aren't actively maintained and that belong to people or
companies who don't have Web stuff as their core competence.

Moreover, Facebook and Google are pushing the boundaries of the Web
platform harder than the long tail is. If we couldn't ask them to make
a change once in a while, it would make evolving the Web much harder
than keeping the long tail working is.

In the case at hand, the only known breakage was on the properties of
a company that's supposed to be in the same bucket as Facebook and
Google. Keeping Web stuff running should be a core competence of
Yahoo! Also, the nature of their breakage was similar to what we see
with Facebook/Google: Since Babelfish already worked in IE and Safari,
Yahoo! has to have a code path that works without Accept-Charset
already. Also, keeping sending Accept-Charset only to keep Babelfish
working would mean bloating our HTTP requests for all of the long
tail.

Also, it's not new that making the call of which big sites should be
capable of fixing their stuff goes wrong. For example, I broke a
MySpace feature in the 3.6 cycle. I had a patch ready that changed the
platform so that the (crazy) MySpace feature would have worked (i.e.
the breakage never had to reach a release), but the code review
process blocked me from changing Gecko to accommodate to the
(remarkably silly) code at MySpace. But as it turns out,
https://bugzilla.mozilla.org/show_bug.cgi?id=542875 is still open.
(But then, MySpace isn't that relevant anymore.)

When the only known breakage is a major site that should have the
capability to adapt by putting us on their WebKit or IE code path, I
think refraining from changing Gecko is the wrong call. I'd even
rather start doing the Safari thing with site-specific hacks than stop
evolving Gecko because one big site makes a bad UA-sniffed assumption.

(Let's move this to dev-platform.)

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Gian-Carlo Pascutto]

On 7/02/2012 9:09, Asa Dotzler wrote:

> What is the user benefit here that outweighs the loss of compatibility
> with a major site -- in this case, the second most popular translation
> service on the Web? When a user who depends on this site moves to IE or
> Chrome, have we helped Firefox or the Web?

If the site is "doing things wrong", I do think we'll have to break
things eventually. Bug for bug compatibility will easily end up at odds
with promoting actual web standards.

If we're allowing sites to get by with buggy programming that depends on
the exact behavior of Firefox, we're closing the web down, not opening
it up.

For this specific case (which I admittedly know nothing about), the
question for me would be why we have been unable to get Yahoo to fix
things. If they're unwilling to fix their stuff, I don't think we have a
real choice. We can warn them and delay the fix, but that's what we did,
right? We can't delay indefinitely.

> I think we've become far too comfortable breaking compatibility for
> minor or non-wins.

s/compatibility/workflow of our users/

Yes. This produces a predictable reaction: Users get upset and
outrageously flame the developer into oblivion in Bugzilla. The
developer gets upset at the exceedingly mean reaction, gets discouraged
or starts ignoring the users. The issue doesn't get fixed and Firefox
"breaks" in any number of meanings.

I'm *very* happy that you're calling out this problem. I just think that
"breaking buggy websites" is the one issue we can't actually compromise
on. Can we please compromise more on all the others, though?

--
GCP

[Asa Dotzler]

On 2/7/2012 1:02 AM, Henri Sivonen wrote:
> On Tue, Feb 7, 2012 at 10:09 AM, Asa Dotzler<a...@mozilla.org> wrote:
>> I'd like to better understand why we think it's the right trade-off to break
>> major websites in order to shave a some bits off of our HTTP headers.
>>
>> http://hsivonen.iki.fi/accept-charset/
>> https://bugzilla.mozilla.org/show_bug.cgi?id=572652
>>
>> What is the user benefit here that outweighs the loss of compatibility with
>> a major site -- in this case, the second most popular translation service on
>> the Web?
>
> First of all, breaking one major site is nothing new. For example

I don't accept that as justification for doing more of it. "We get a
major win" might be good enough justification but "We've done it in the
past" isn't good enough, IMO.

> Facebook pokes at the edges of the Web platform so hard that sometimes
> in order to make the platform better, we break Facebook. Native JSON
> and the unification of namespaces in HTML and XHTML DOMs come to mind.
> With Facebook this is OK, because developing a Web site is a core
> competence of Facebook and they are remarkable quick to adapt to
> browser fixes.

You're making a case for breaking sites when there is a clear win for
the platform AND we have reasonable confidence that the major sites will
fix themselves. I'm arguing against the case where breaking sites comes
with a non-obvious win and we already know the site isn't likely to be
fixed immediately.

> Also, we break various Google properties all the time. Often because
> Google is doing it wrong with browser sniffing but also because we
> first added some moz-prefixed stuff and then take it away or change
> it. In the case of Firefox 10, various Google properties had breakage
> because the version number started having double digits. The situation
> with Google is pretty much OK, too. Developing Web apps is a core
> competence of Google, too. They can and do adapt to browser changes.

Sometimes breakage is hard to avoid. I get that. Sometimes breaking
sites gives the platform a big boost. I get that. This, IMO, is not one
of those cases. We could have avoided the change and the breakage with
no immediate penalty. Instead, we're asking our users to absorb pain
(they won't) for gains they probably won't ever notice. The result is
users moving to other browsers because we broke them.

> In the case at hand, the only known breakage was on the properties of
> a company that's supposed to be in the same bucket as Facebook and
> Google. Keeping Web stuff running should be a core competence of
> Yahoo! Also, the nature of their breakage was similar to what we see
> with Facebook/Google: Since Babelfish already worked in IE and Safari,
> Yahoo! has to have a code path that works without Accept-Charset
> already. Also, keeping sending Accept-Charset only to keep Babelfish
> working would mean bloating our HTTP requests for all of the long
> tail.

When this broke yahoo search with non-ascii characters and babelfish we
backed it out. I was there when we did it the first couple of times. I
wasn't there advocating for backing it out later because I'd assumed we
all agreed that breaking Yahoo was not an acceptable cost for this
"win". At some point, half of the Yahoo breakage was fixed by Yahoo and
people decided that was good enough. Had I been there when that changed,
I would have continued to fight against landing this and breaking
Babelfish (and potentially others that were too long tail for us to ever
hear about).

This is not new bloat. We've been carrying it forever. We could have
continued to carry it. Apparently Chrome isn't in a hurry to drop it and
they're hyper-sensitive to performance issues. I just don't get the rush
knowing it was going to break things that were not likely to get fixed
with haste.

> Also, it's not new that making the call of which big sites should be
> capable of fixing their stuff goes wrong. For example, I broke a
> MySpace feature in the 3.6 cycle. I had a patch ready that changed the
> platform so that the (crazy) MySpace feature would have worked (i.e.
> the breakage never had to reach a release), but the code review
> process blocked me from changing Gecko to accommodate to the
> (remarkably silly) code at MySpace. But as it turns out,
> https://bugzilla.mozilla.org/show_bug.cgi?id=542875 is still open.
> (But then, MySpace isn't that relevant anymore.)

I'm sorry that happened. If I'd have known about that, I would have
helped advocate for a non-breaking solution.

> When the only known breakage is a major site that should have the
> capability to adapt by putting us on their WebKit or IE code path, I
> think refraining from changing Gecko is the wrong call.

Except that we knew about it ahead of time and they weren't in any hurry
in fixing it. (Do we even have data that gives us any confidence at all
that other much smaller sites weren't broken by this?) If we know of a
major site that breaks because of a change we made before we ship it to
final, I lean towards assuming that other smaller sites are broken just
haven't reached us yet or may never reach us.

We're not in a good position to toss out hard-earned web compatibility.
Maybe a few years ago when it was just us and IE and we were the
developer favorite. But things are a lot harder today. Winning over
users is much more difficult and losing them is a whole lot easier.

- A

[Henri Sivonen]

On Tue, Feb 7, 2012 at 11:31 AM, Asa Dotzler <a...@mozilla.org> wrote:
> On 2/7/2012 1:02 AM, Henri Sivonen wrote:
>>
>> On Tue, Feb 7, 2012 at 10:09 AM, Asa Dotzler<a...@mozilla.org>  wrote:
>>>
>>> I'd like to better understand why we think it's the right trade-off to
>>> break
>>>
>>> major websites in order to shave a some bits off of our HTTP headers.
>>>
>>> http://hsivonen.iki.fi/accept-charset/
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=572652
>>>
>>> What is the user benefit here that outweighs the loss of compatibility
>>> with
>>> a major site -- in this case, the second most popular translation service
>>> on
>>> the Web?
>>
>>
>> First of all, breaking one major site is nothing new. For example
>
>
> I don't accept that as justification for doing more of it. "We get a major
> win" might be good enough justification but "We've done it in the past"
> isn't good enough, IMO.

I agree that that's not justification enough. I responded that way
because your message made it look like you were saying this was some
kind of new phenomenon. Upon re-reading what you said, I don't think
the wording of your message actually suggested anything about the
recency of the phenomenon. Sorry.

(Quotes re-ordered below.)

> You're making a case for breaking sites when there is a clear win for the
> platform AND we have reasonable confidence that the major sites will fix
> themselves

...

> Sometimes breakage is hard to avoid. I get that. Sometimes breaking sites
> gives the platform a big boost. I get that. This, IMO, is not one of those
> cases.

...

> This is not new bloat. We've been carrying it forever. We could have
> continued to carry it.

The DOM namespace unification thing that broke Facebook (and that
Safari had already done so Facebook had a code path for it) was bloat
we had been carrying around forever. Before making the change *and
some further changes that it enabled*, we didn't know what the full
benefit would be. The change turned out to be an overall DOM
performance win even though it was originally motivated by code
aesthetics, simplicity and maintainability.

As for breaking Facebook by introducing native JSON, we *could* have
told TC39 to give the entry point to native JSON a different name
since the name they used was taken by Facebook.

We don't *have to* break some Google code by taking away or changing
moz-prefixed animation APIs. We *could* keep the moz-prefixed stuff
around forever while *also* implementing the W3C spec without prefix.

We didn't *have to* break some Google code by moving the version
number in the UA string to double digits. We *could* have done what
Opera did and carry around a longer UA string around forever.

What's out of the ordinary here is that the patch got backed out from
four release trains.

> Apparently Chrome isn't in a hurry to drop it and
> they're hyper-sensitive to performance issues. I just don't get the rush
> knowing it was going to break things that were not likely to get fixed with
> haste.

The more likely explanation is that there's a ton of stuff in a
browser and they didn't happen to notice the situation around this
particular thing. A couple of people on their team seemed to act as if
they considered sending Accept-Charset a bug in Chrome after the
correction in http://hsivonen.iki.fi/accept-charset/ alerted them to
it.

In a way, it's sad that we can't be leading on stuff like this. This
wouldn't have happened if IE hadn't already been the leader. And now
it seems that we should be waiting for Chrome to move before us, too.
:-(

> When this broke yahoo search with non-ascii characters and babelfish we
> backed it out. I was there when we did it the first couple of times. I
> wasn't there advocating for backing it out later because I'd assumed we all
> agreed that breaking Yahoo was not an acceptable cost for this "win". At
> some point, half of the Yahoo breakage was fixed by Yahoo and people decided
> that was good enough.

FWIW, I was a bit surprised to see that patch made it to release
before Y! fixed Babelfish.

> Except that we knew about it ahead of time and they weren't in any hurry in
> fixing it.

Although I was surprised that the patch made it to release before
Babelfish had been fixed, in retrospect, I think deferring the patch
indefinitely would have set a bad precedent. I think we shouldn't be
signaling to Google / Facebook / Yahoo! / Live.com/Hotmail/Bing that
we'll refrain from aligning Gecko with IE or Safari behavior if they
put us on a different code path by browser sniffing and are slow to
fix it.

If we are no longer OK with breaking sites/app in a "too big to fail"
category, I think we should start doing Safari/Chrome-style (not
IE-style or Opera-style) site-specific hacks instead of letting others
make us defer alignment with IE/Safari by multiple release trains.

> (Do we even have data that gives us any confidence at all that
> other much smaller sites weren't broken by this?)

We never have confidence beyond not seeing an influx of bug reports.

> Winning over users is much more
> difficult and losing them is a whole lot easier.

Indeed.

(Trying to move this to dev-platform again, since this thread is
really about how we change Gecko instead of how we change Firefox
around it.)

[Asa Dotzler]

On 2/7/2012 2:26 AM, Henri Sivonen wrote:

> If we are no longer OK with breaking sites/app in a "too big to fail"
> category, I think we should start doing Safari/Chrome-style (not
> IE-style or Opera-style) site-specific hacks instead of letting others
> make us defer alignment with IE/Safari by multiple release trains.

I would like to hear more about this. Can you explain how Safari and
Chrome do it and why that's superior to how IE and Opera do it?

- A

PS, I don't know what the heck I'm doing here but I think I've set
followup-to to be m.d.platform.

[David Rajchenbach-Teller]

On 2/7/12 11:26 AM, Henri Sivonen wrote:
> We don't *have to* break some Google code by taking away or changing
> moz-prefixed animation APIs. We *could* keep the moz-prefixed stuff
> around forever while *also* implementing the W3C spec without prefix.

What is the rationale for dropping the moz-prefixed stuff, btw?

I tend to believe that it makes sense to keep it (at least for sume
buffer period) – not all web apps/sites can afford to have someone on
watch for such tiny-but-frequent changes.


Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[B.J. Herbison]

On Tuesday, February 7, 2012 6:03:11 AM UTC-5, David Rajchenbach-Teller wrote:
>
> What is the rationale for dropping the moz-prefixed stuff, btw?

I don't know the official stance, but from my point of view the benefit of dropping is encouraging an open web.

If we keep supporting moz-prefixes that are the same as standards then some people will keep using them, and the pages just work for Firefox. Drop support for the prefix, force them to change, and the pages work for everyone.

[Dao]

On 07.02.2012 10:04, Gian-Carlo Pascutto wrote:
> For this specific case (which I admittedly know nothing about), the
> question for me would be why we have been unable to get Yahoo to fix
> things. If they're unwilling to fix their stuff, I don't think we have a
> real choice. We can warn them and delay the fix, but that's what we did,
> right? We can't delay indefinitely.

AFAIK nobody contacted them.

Also, some user accidentally removed tracking-firefox10 and it was never
reset.

[Henri Sivonen]

On Tue, Feb 7, 2012 at 3:34 PM, Dao <d...@design-noir.de> wrote:
> AFAIK nobody contacted them.

Interesting. https://bugzilla.mozilla.org/show_bug.cgi?id=572652#c38
made it look like there was some kind of communication going on.

[Gervase Markham]

On 07/02/12 14:21, Henri Sivonen wrote:
> Interesting. https://bugzilla.mozilla.org/show_bug.cgi?id=572652#c38
> made it look like there was some kind of communication going on.

We _really_ need an evangelism team...

Gerv

[Asa Dotzler]

And we broke Google. Nice. And for what user benefit?

https://bugzilla.mozilla.org/show_bug.cgi?id=728972

- A

[Dao]

This is a red herring. We didn't break google for any of our end users
and are/were in the process of making sure it wouldn't hit end users.

[Asa Dotzler]

Like we did for Yahoo where we just filed a Tech Evangelism bug and said
"good enough"?

And you're doing what to make sure it doesn't break a long tail of
websites?

- A

[Boris Zbarsky]

On 2/20/12 9:11 PM, Asa Dotzler wrote:
> Like we did for Yahoo where we just filed a Tech Evangelism bug and said
> "good enough"?

Oh, c'mon. The Yahoo thing was backed out from release branches
multiple times, precisely to avoid breaking users. It was only shipped
once one of the two Yahoo sites involved was fixed and the other was
apparently judged unimportant.

That's exactly what would ideally happen with this change if Google
doesn't fix it, but....

> And you're doing what to make sure it doesn't break a long tail of
> websites?

This is a much more important question. :(

-Boris

[Dao]

No.

> And you're doing what to make sure it doesn't break a long tail of
> websites?

Landing on central so that we can extrapolate. Bug 572652 and bug 690287
suggest that we wouldn't see an unexpected amount of breakage after
shipping it. We can even prophylactically back it out a few times from
aurora, then beta, to get more time and feedback, as we don't have the
same pressure that bug 690287 had.

[Daniel Cater]

On Tuesday, 21 February 2012 01:27:14 UTC, Asa Dotzler wrote:
> And we broke Google. Nice. And for what user benefit?

- Moves inline with Fennec (minimises web-visible differences between mobile and desktop)
- Reduces fingerprint-ability by removing the minor version
- Makes testing on trunk and Aurora more representative of beta and release by removing the "a1" string
- Saves bytes (can save RTTs due to packet boundaries)
- Removes the potentially confusing string "20100101"
- Plans for the long-term by allowing future user-agents to be more succinct
- Gets sites to fix sniffing that is already broken (perhaps even by removing it entirely thus providing benefits to more than just desktop Firefox users)

[Asa Dotzler]

This seems like an awful lot of effort for little to no actual benefit.
We won't know the long tail of sites that break. Even our release
audience won't tell us that. They'll simply walk away when a site that's
important to them stops working.

We're not in 2006 any more. Many users have multiple very capable
browsers on their machines and if we make even one
important-to-that-user site break, Chrome an IE are just a click away.
Why on earth are we now deciding that breaking sites and driving users
away is OK. If there was ever a time to back off from these efforts and
instead focus on adding compatibility rather than killing it, now is
that time.

This whole effort is misguided IMO. There are far more important things
to be working on like *increasing* web compatibility. We don't have the
users to spare on wild goose chases like this.

- A

[Asa Dotzler]

On 2/20/2012 7:39 PM, Daniel Cater wrote:
> On Tuesday, 21 February 2012 01:27:14 UTC, Asa Dotzler wrote:
>> And we broke Google. Nice. And for what user benefit?
>
> - Moves inline with Fennec (minimises web-visible differences between mobile and desktop)

to what end? we're explicitly differentiating the fennec UA from desktop.

> - Reduces fingerprint-ability by removing the minor version

fingerprinting is the least effective and least used method for user
tracking on the web. it's almost laughable how much attention this gets
when it's simply not a problem today.

> - Makes testing on trunk and Aurora more representative of beta and release by removing the "a1" string

Where has this bit us in the past? How many release users should we
sacrifice to solve this problem in this way?

> - Saves bytes (can save RTTs due to packet boundaries)

Got data? How many users will notice an increase in performance? How
does that weigh against the number of users it will cost us? Without
data, that's a tough selling point, IMO.

> - Removes the potentially confusing string "20100101"

Confusing to whom?

> - Plans for the long-term by allowing future user-agents to be more succinct

What does succinctness buy anyone?

> - Gets sites to fix sniffing that is already broken (perhaps even by removing it entirely thus providing benefits to more than just desktop Firefox users)

And there are no better ways to accomplish this?

I don't consider any of these items worth losing unknowable numbers of
users.

- A

[Henri Sivonen]

CCing dev-platform, since this is a Gecko change.

On Tue, Feb 21, 2012 at 9:02 AM, Asa Dotzler <a...@mozilla.org> wrote:
> On 2/20/2012 7:39 PM, Daniel Cater wrote:
>>
>> On Tuesday, 21 February 2012 01:27:14 UTC, Asa Dotzler  wrote:
>>>
>>> And we broke Google. Nice. And for what user benefit?
>>
>> - Moves inline with Fennec (minimises web-visible differences between
>> mobile and desktop)
>
> to what end? we're explicitly differentiating the fennec UA from desktop.

This goal could be achieved by having Fennec and desktop Aurora and
Nightly all say Gecko/20100101.

>> - Reduces fingerprint-ability by removing the minor version
>
> fingerprinting is the least effective and least used method for user
> tracking on the web. it's almost laughable how much attention this gets when
> it's simply not a problem today.

Minor version could have been hidden while keeping the frozen
Gecko/20100101. Obviously, removing the minor version can't break us
worse that shipping a normal non-chemspill release.

>> - Makes testing on trunk and Aurora more representative of beta and
>> release by removing the "a1" string
>
> Where has this bit us in the past? How many release users should we
> sacrifice to solve this problem in this way?

Removing the "a1" part is a pure win. Obviously, it can't break us
worse than shipping a release, since we don't say "a1" in release
builds. However, not having the "a1" or "a2" part there means that
we'd test what we are going to ship all the way from Nightly through
to Release.

>> - Saves bytes (can save RTTs due to packet boundaries)
>
> Got data? How many users will notice an increase in performance? How does
> that weigh against the number of users it will cost us? Without data, that's
> a tough selling point, IMO.

Gecko/13.0 is 4 bytes shorter than Gecko/20100101.

>> - Removes the potentially confusing string "20100101"
>
> Confusing to whom?

(Personally, I think this is a very unpersuasive argument.)

>> - Plans for the long-term by allowing future user-agents to be more
>> succinct
>
> What does succinctness buy anyone?

Fewer bytes per request. But if we are ever going to go for that kind
of succinctness, we'll need to have the guts to attack the
"Mozilla/5.0" part. That's the most dead weight bytes up for grabs.

>> - Gets sites to fix sniffing that is already broken (perhaps even by
>> removing it entirely thus providing benefits to more than just desktop
>> Firefox users)
>
> And there are no better ways to accomplish this?

We could make all Gecko builds of *any* kind say Gecko/20100101 and
keep that part frozen forever, make no kinds of builds say "a1" or
"a2" and make no builds report the chemspill version digit in the UA
string. (If this was my decision, that's what I'd do knowing what I
now know, because I believe we can never get rid of the rv: part
without causing breakage at "definitely not worth it" levels.)

[Dao]

On 21.02.2012 08:23, Henri Sivonen wrote:
> Fewer bytes per request. But if we are ever going to go for that kind
> of succinctness, we'll need to have the guts to attack the
> "Mozilla/5.0" part. That's the most dead weight bytes up for grabs.

The date's 4 bytes plus "; rv:13.0" is actually more... Anyway, I'm not
even sure what the point of that comparison is. Any reduction helps. If
we can attack this from multiple angles, that's all the better. If
there's reason to believe that the web doesn't depend on Mozilla/5.0
anymore, then lets take a closer look there regardless of what we're
doing elsewhere.

>(If this was my decision, that's what I'd do knowing what I
> now know, because I believe we can never get rid of the rv: part
> without causing breakage at "definitely not worth it" levels.)

I don't buy that scripts will depend on rv: to all eternity if we freeze
it and give them Gecko/<version>. (I suspect most of the existing ones
won't be changed but rather cease to exist over the years.)

The last time I read "never" was yesterday in dwitte's last comment in
bug 572659 from 2010.

[Dao]

On 21.02.2012 07:56, Asa Dotzler wrote:
>> Landing on central so that we can extrapolate. Bug 572652 and bug 690287
>> suggest that we wouldn't see an unexpected amount of breakage after
>> shipping it. We can even prophylactically back it out a few times from
>> aurora, then beta, to get more time and feedback, as we don't have the
>> same pressure that bug 690287 had.
>
> This seems like an awful lot of effort for little to no actual benefit.

It seems pretty reasonable, assessable and not like an awful lot of
effort to me. (Benefit has been brought up elsewhere, I'll leave it
alone here.)

> We won't know the long tail of sites that break. Even our release
> audience won't tell us that. They'll simply walk away when a site that's
> important to them stops working.

I think this is reaching FUD stages now. John Jensen got hard data for
server-side sniffing on the global top 1000 sites and we can ask him to
expand this. The google thing didn't hit us by surprise; zimbra did,
because Henri didn't test with the "a1" modifier, which we've
consequentially removed.

[Gijs Kruitbosch]

On 21/02/2012 07:56 AM, Asa Dotzler wrote:
> <snip>

> This seems like an awful lot of effort for little to no actual benefit. We won't
> know the long tail of sites that break. Even our release audience won't tell us
> that. They'll simply walk away when a site that's important to them stops working.
>
> We're not in 2006 any more. Many users have multiple very capable browsers on
> their machines and if we make even one important-to-that-user site break, Chrome
> an IE are just a click away. Why on earth are we now deciding that breaking
> sites and driving users away is OK. If there was ever a time to back off from
> these efforts and instead focus on adding compatibility rather than killing it,
> now is that time.
>
> This whole effort is misguided IMO. There are far more important things to be
> working on like *increasing* web compatibility. We don't have the users to spare
> on wild goose chases like this.
>
> - A

All of these changes were discussed very, very extensively on these newsgroups,
including (as Dao pointed out) lots of data to motivate these changes (see the
archives for September-February (last post in relevant threads was on 2/2)).
Ironically, AIUI one of the reasons to change the UA string *was* compatibility,
especially for mobile.

I feel it would have been better if you gave feedback then. If you want to give
feedback now, it would be nice if you made more of an effort to understand the
reasons for the changes and how they were decided upon, rather than implying
that the people involved are actively trying to break web compatibility 'for
little to no actual benefit' when, reading the past threads, that just isn't the
case.

Gijs

[Gervase Markham]

On 21/02/12 07:02, Asa Dotzler wrote:
>> - Moves inline with Fennec (minimises web-visible differences between
>> mobile and desktop)
>
> to what end? we're explicitly differentiating the fennec UA from desktop.

In specific ways ("Mobile" vs "Tablet" vs another platform identifier).
In all other ways, we should be identical, because we are the same
browser. That's one of our big selling points vs. the multiple
fragmented WebKits.

As others have said, it would be nice if you didn't imply with every
message that anyone involved in this work is just tinkering randomly
like the Chaos Monkey.

>> - Reduces fingerprint-ability by removing the minor version
>
> fingerprinting is the least effective and least used method for user
> tracking on the web. it's almost laughable how much attention this gets
> when it's simply not a problem today.

The privacy team care about it, and so decisions about the UA are taken
with that in mind. If you think we are wrong-headed here, take it up
with them.

>> - Makes testing on trunk and Aurora more representative of beta and
>> release by removing the "a1" string
>
> Where has this bit us in the past? How many release users should we
> sacrifice to solve this problem in this way?

Now you are just ranting. The change he refers to here doesn't affect
release builds in the slightest.

>> - Saves bytes (can save RTTs due to packet boundaries)
>
> Got data?

We discussed the impact of this with the networking team, yes.

> I don't consider any of these items worth losing unknowable numbers of
> users.

By your argument, we would never make any changes _at_all_ to our web
platform, because any change might break something somewhere which would
cause an unknowable number of our users to hit their pain threshold and
depart. That seems unlikely to be a productive way forward.

Can we instead consider each change on its merits, based on the data
we've managed to gather?

Gerv

[Gervase Markham]

On 21/02/12 07:23, Henri Sivonen wrote:
> Fewer bytes per request. But if we are ever going to go for that kind
> of succinctness, we'll need to have the guts to attack the
> "Mozilla/5.0" part. That's the most dead weight bytes up for grabs.

We have data which suggests we might be able to do that. We probably
need more, but it's possible.

Gerv

[Asa Dotzler]

On 2/21/2012 1:51 AM, Dao wrote:
> On 21.02.2012 08:23, Henri Sivonen wrote:
>> Fewer bytes per request. But if we are ever going to go for that kind
>> of succinctness, we'll need to have the guts to attack the
>> "Mozilla/5.0" part. That's the most dead weight bytes up for grabs.
>
> The date's 4 bytes plus "; rv:13.0" is actually more... Anyway, I'm not
> even sure what the point of that comparison is. Any reduction helps.

Any reduction helps *what*? Fingerprinting? Are we really saying that
making a completely unused (outside of the eff) form of web tracking is
worth losing users? If this is really about fingerprinting, I'd like to
make a proposal: when we've solved all of the user tracking problems
that actually exist in the real world today, we tackle fingerprinting.

- A

[Asa Dotzler]

On 2/21/2012 6:47 AM, Gervase Markham wrote:
> On 21/02/12 07:02, Asa Dotzler wrote:

>> fingerprinting is the least effective and least used method for user
>> tracking on the web. it's almost laughable how much attention this gets
>> when it's simply not a problem today.
>
> The privacy team care about it, and so decisions about the UA are taken
> with that in mind. If you think we are wrong-headed here, take it up
> with them.

Yes. I think we are completely wrong-headed here. Why would anyone
anywhere go to the effort (outside of the eff) to set up a massively
difficult and horribly inaccurate tracking system based on
fingerprinting when they can just drop a cookie on your system?

> By your argument, we would never make any changes _at_all_ to our web
> platform, because any change might break something somewhere which would
> cause an unknowable number of our users to hit their pain threshold and
> depart. That seems unlikely to be a productive way forward.

No, that's not my argument. There are plenty of changes where there are
obvious user/developer benefits that we don't make because they might
break parts of the Web. These changes don't have, IMO, obvious user and
developer benefits and we're breaking sites and losing users over them.

Shaving a few bits of entropy out of our headers and UA to defeat a
tracking system that isn't used anywhere for anything is not the same as
fixing a longstanding cross browser bit of incompatible HTML or CSS to
delight developers everywhere is one thing. Tackling the latest EFF
bogeyman at the expense of users is something entirely different.

- A

[Dao]

On 21.02.2012 18:05, Asa Dotzler wrote:
> On 2/21/2012 1:51 AM, Dao wrote:
>> On 21.02.2012 08:23, Henri Sivonen wrote:
>>> Fewer bytes per request. But if we are ever going to go for that kind
>>> of succinctness, we'll need to have the guts to attack the
>>> "Mozilla/5.0" part. That's the most dead weight bytes up for grabs.
>>
>> The date's 4 bytes plus "; rv:13.0" is actually more... Anyway, I'm not
>> even sure what the point of that comparison is. Any reduction helps.
>
> Any reduction helps *what*? Fingerprinting?

Fewer bytes per request. See also the discussion on this in the
mozilla.dev.platform part of this thread.

[Christopher Blizzard]

I have two very specific complaints about how the UA change is being
handled:

First - and most important - I don't understand why we're doing this
right now given the number of other more important things that we have
going on. It breaks web sites, creating a really bad experience for our
users. It's just borrowing trouble. If we want to invest in privacy
let's implement basically anything else on this list:
https://wiki.mozilla.org/Privacy/Features - basically anything in there
will help far more than fingerprinting entropy in our UA string.

Second, on approach: UA changes are acceptable, but they need to be done
in a very deliberate fashion. The last time we did this we gave lots of
warning, did a lot of early outreach and clearly documented what we were
doing. We also kept a lot of the string because it maintained
compatibility with a lot of sites and UA parsers. (Hence rv:<ver>
instead of Gecko/<ver>!) The final UA string document we did for
Firefox 4 was done 6 months before the release and our beta population
during that time was far larger than our Aurora or Beta population today
so the impact on real-world web sites was far greater and the dark
matter we can't see had time to adjust as well.

What I've seen so far doesn't include a coordinated outreach plan or a
time frame for people to adjust. "Surprise, here comes Firefox 13!"
isn't enough.

--Chris

[Asa Dotzler]

On 2/21/2012 6:47 AM, Gervase Markham wrote:

> On 21/02/12 07:02, Asa Dotzler wrote:

>>> - Saves bytes (can save RTTs due to packet boundaries)
>>
>> Got data?
>
> We discussed the impact of this with the networking team, yes.

I'd like to learn more about this. Where is this data? What are the
actual performance benefits we get from this change today?

- A

[Justin Dolske]

On 2/21/12 2:51 AM, Gijs Kruitbosch wrote:

> All of these changes were discussed very, very extensively on these
> newsgroups, including (as Dao pointed out) lots of data to motivate
> these changes (see the archives for September-February (last post in
> relevant threads was on 2/2)). Ironically, AIUI one of the reasons to
> change the UA string *was* compatibility, especially for mobile.

The context for these discussions, as I remember it, was _only_ for
mobile. Perhaps I missed it buried within -- it wasn't really relevant
to me, seemed like bikeshedding to avoid, and I'm basically happy to let
mobile solve the exciting new challenges they encounter.

What _was not_ clear to me was that the desktop UA was going to change.
Or that there was known breakage on major sites. Or that people were
assuming we were willing to live with the breakage as a way to force
change. These are all pretty serious issues that surprised quite a few
of the people intimately involved with owning and shipping desktop
Firefox, and indicates that some communication which should have
happened apparently didn't.

Now, for better or worse, people have noticed and here we are.

Justin

[Gervase Markham]

On 22/02/12 02:55, Justin Dolske wrote:
> What _was not_ clear to me was that the desktop UA was going to change.
> Or that there was known breakage on major sites. Or that people were
> assuming we were willing to live with the breakage as a way to force
> change. These are all pretty serious issues that surprised quite a few
> of the people intimately involved with owning and shipping desktop
> Firefox, and indicates that some communication which should have
> happened apparently didn't.

Entirely fair point.

Gerv

[Dao]

On 22.02.2012 03:55, Justin Dolske wrote:
> On 2/21/12 2:51 AM, Gijs Kruitbosch wrote:
>
>> All of these changes were discussed very, very extensively on these
>> newsgroups, including (as Dao pointed out) lots of data to motivate
>> these changes (see the archives for September-February (last post in
>> relevant threads was on 2/2)). Ironically, AIUI one of the reasons to
>> change the UA string *was* compatibility, especially for mobile.
>
> The context for these discussions, as I remember it, was _only_ for
> mobile. Perhaps I missed it buried within -- it wasn't really relevant
> to me, seemed like bikeshedding to avoid, and I'm basically happy to let
> mobile solve the exciting new challenges they encounter.

You didn't miss it, there was no immediate implication for non-mobile.
At /some/ point, though, the platform should converge.