Re: Windows XP and Vista Long Term Support Plan

[Peter Dolanjski]

>
> Chutten is not as categoric as you are:
>
>   It is also possible that we’ve seen some ex-Chrome users fleeing
>   Google’s drop of support from earlier this year.
>
This is possible, but I'd still expect to see the biggest impact when
Chrome started including the scary persistent notification that the user
will no longer get updates.


>   Deseasonalized numbers for just WinXP users are hard to come by, so
>   this is fairly speculative. One thing that’s for certain is that the
>   diminishing Windows XP userbase trend I had previously observed (and
>   was counting on seeing continue) is no longer in evidence.


Chutten, if you have some other stats on this, I'd love to take a look.
The longitudinal data still shows the following trend:

*Changes to **Daily Active User proportion of WinXP to total Windows
population from previous month:*
Week of Jan. 20th, 2016: -4.3%
Week of Feb. 20th, 2016: -2.5%
Week of Mar. 20th, 2016: -2.6%
Week of Apr. 20th, 2016: -3.2%
Week of May 20th, 2016: -1.3%
Week of June 20th, 2016: -3.3%
Week of July 20th, 2016: -2.3%
Week of Aug. 20th, 2016: -4.9%
Week of Sept. 20th, 2016: -1.1%
Week of Oct. 20th, 2016: -1.2%

Sure, there were larger drops in the summer that seemed to have eased off
in Sept./Oct. but it's too early to tell if that's just some weirdness from
seasonality.

Peter





On Tue, Nov 1, 2016 at 9:56 PM, Mike Hommey  wrote:

> On Wed, Nov 02, 2016 at 09:28:40AM +0800, Peter Dolanjski wrote:
> > On 10/31/2016 3:54 PM, juar...@gmail.com wrote:
> >
> > >
> > > Discontinuing support for 10% of users sounds like shrinking 10% of
> > > customers, lay off 10% of employees, reduce 10% of funds for
> > > investments.
> >
> >
> > I can tell you that the evidence we have does not support the notion
> > that end of life (or the approach we are proposing) will actually
> > result in the attrition of those users.  We examined the impact of
> > Chrome's end of life on Windows XP users.  The majority of users
> > planned to stick with Chrome even without security updates.  We also
> > saw almost zero evidence of Chrome's end of life causing an uptick in
> > Firefox usage or downloads among XP users.
>
> Chutten is not as categoric as you are:
>
>   It is also possible that we’ve seen some ex-Chrome users fleeing
>   Google’s drop of support from earlier this year.
>
>   Deseasonalized numbers for just WinXP users are hard to come by, so
>   this is fairly speculative. One thing that’s for certain is that the
>   diminishing Windows XP userbase trend I had previously observed (and
>   was counting on seeing continue) is no longer in evidence.
>
>   https://chuttenblog.wordpress.com/2016/10/28/firefox-
> windows-xp-exit-plan/
>
> Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Mike Hommey]

On Wed, Nov 02, 2016 at 09:28:40AM +0800, Peter Dolanjski wrote:
> On 10/31/2016 3:54 PM, juar...@gmail.com wrote:
> 
> >
> > Discontinuing support for 10% of users sounds like shrinking 10% of
> > customers, lay off 10% of employees, reduce 10% of funds for
> > investments.
> 
> 
> I can tell you that the evidence we have does not support the notion
> that end of life (or the approach we are proposing) will actually
> result in the attrition of those users.  We examined the impact of
> Chrome's end of life on Windows XP users.  The majority of users
> planned to stick with Chrome even without security updates.  We also
> saw almost zero evidence of Chrome's end of life causing an uptick in
> Firefox usage or downloads among XP users.

Chutten is not as categoric as you are:

  It is also possible that we’ve seen some ex-Chrome users fleeing
  Google’s drop of support from earlier this year.

  Deseasonalized numbers for just WinXP users are hard to come by, so
  this is fairly speculative. One thing that’s for certain is that the
  diminishing Windows XP userbase trend I had previously observed (and
  was counting on seeing continue) is no longer in evidence.

  https://chuttenblog.wordpress.com/2016/10/28/firefox-windows-xp-exit-plan/

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Peter Dolanjski]

On 10/31/2016 3:54 PM, juar...@gmail.com wrote:

>
> Discontinuing support for 10% of users sounds like shrinking 10% of
> customers, lay off 10% of employees, reduce 10% of funds for investments.


I can tell you that the evidence we have does not support the notion that
end of life (or the approach we are proposing) will actually result in the
attrition of those users.
We examined the impact of Chrome's end of life on Windows XP users.  The
majority of users planned to stick with Chrome even without security
updates.  We also saw almost zero evidence of Chrome's end of life causing
an uptick in Firefox usage or downloads among XP users.

- Someone has the statistics details of this "10% user base" for supporting
> this decision? What service pack? Where they are? What are the demographics
> numbers? How often the browse web?


We did look through the data.  Yes, there is a geographic skew in XP usage
towards countries like Russia and China.  In addition, on average, XP users
search less and have lower engagement rates than non-XP users, but the
difference isn't massive.

Peter

On Tue, Nov 1, 2016 at 6:48 AM, Aaron Klotz  wrote:

> Disclaimer: I am not a decision maker on this, these are my personal
> opinions, etc, etc
>
> On 10/31/2016 3:54 PM, juar...@gmail.com wrote:
>
>>
>> Discontinuing support for 10% of users sounds like shrinking 10% of
>> customers, lay off 10% of employees, reduce 10% of funds for investments.
>>
>> - Is really necessary to abandon all XP users?
>>
> Shifting XP users to ESR is different from "abandonment" FWIW, but IMHO
> this move is necessary. As I pointed out earlier in this discussion, the
> problems have become more complicated than simply disabling certain pieces
> of code when XP does not support them.
>
> - Is possible to discontinue the most hard to support components?
>> Somenthing like "Video conferencing will not work in XP" or like is planned
>> for flash.
>>
> Again, that is not the problem. The problem is more like, "Sorry 90% of
> users, we can't give you a better sandbox because of the 10% of users
> running an obsolete and unsupported OS," or "This feature is going to be
> delayed a release because it mysteriously fails on Windows XP." Meanwhile,
> our competitors *do* deliver that better sandbox or *do* release that new
> feature before we do. Now we're preserving that 10% of users at the expense
> of the other 90%, and it's in the latter category where the growth will be.
> That sounds like a pretty lousy growth strategy to me.
>
> - Is possible restrict the user base affected? Like only XP SP2 and
>> older...
>>
> Existing Firefox system requirements are for XP SP2, so we already
> restrict older revisions, but that isn't really the issue here. The issue
> is the gulf between all XP releases and newer versions.
>
> As somebody who has first-hand experience with this, let me assure you:
> Debugging XP-specific problems has become very unpleasant. Most developers
> don't just have an XP machine sitting around to work with. We can request a
> loaner from Release Engineering and debug it through there, but that is
> very tedious and time consuming. Turnaround on try builds for Windows XP is
> sometimes terribly slow. As XP continues to die off, this will only get
> worse, not better.
>
> I see how Mozilla is important for open web and how firefox user base is
>> shrinking. This worries me.
>>
> Do not confuse shrinking market share with shrinking user base. That is
> only the case when the total number of users on the web remains constant,
> which is not the case. Having said that, I don't want to see shrinking
> market share either.
>
> I do not believe that we can offer the highest quality experience to the
> vast majority of our users by continuing to expend resources on the past.
> One of our top-line goals for 2016 has been to build our core strength. I
> don't know how we're supposed to do that by intentionally tying one hand
> behind our back to support Windows XP.
>
> Supporting XP might curb short-term market share losses but it will hinder
> our ability to deliver long-term market share gains.
>
> Maybe hiring one or two developers for supporting this user base is
>> cheaper than loosing these users.
>>
>
> Hopefully my other remarks in this post have made it clear that XP support
> is not an issue of headcount.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Scheduling requests misbehaving in the last two days

[Armen Zambrano G.]

Spreading the original information beyond the original mailing list.

Unfortunately, requests to backfill jobs or adding new jobs (and 
similar) are not keeping up. The requests are not being processed fast 
enough.


I will email again once it is resolved.

If you're curious, here's the bug I'm using
https://bugzilla.mozilla.org/show_bug.cgi?id=1314396

My apologies for this inconvenience.

regards,
Armen

 Forwarded Message 
Subject: Scheduling requests misbehaving in the last two days
Date: Tue, 1 Nov 2016 14:21:12 -0400
From: Armen Zambrano G. 
Organization: Mozilla Corporation
To: dev-tree-managem...@lists.mozilla.org
Newsgroups: mozilla.dev.tree-management

If you've tried to add new jobs, backfill or similar special scheduling 
requests from Treeherder, you might have noticed improper behaviour.


Unfortunately, I've introduced a bug in the last few days that has been 
a bit difficult to recover from.


I've changed the design of pulse_actions to help handle these situations 
better in the future.


I believe we're back to normal. My apologies for the inconvenience.

Please let me know if you're interested on more details.

regards,
Armen

--
Zambrano Gasparnian, Armen
Engineering productivity
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Eric Rescorla]

On Tue, Nov 1, 2016 at 3:53 PM, Martin Thomson  wrote:

> On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor  wrote:
> > Taking a step back: is fingerprinting really a solvable problem in
> > practice?  At this point, are there a significant fraction of users
> > who can't be fingerprinted pretty reliably?  Inevitably, the more
> > features we add to the platform, the more fingerprinting surface we'll
> > expose.  At a certain point, we might be taking away a lot of features
> > for the sake of trying to stop the unstoppable.  (I have no idea if
> > this is actually true now, though.  This is a genuine question.  :) )
>
> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
>
> The conclusion: it's probably a lost cause, but we still shouldn't be
> building more of these.
>

I'm not sure I agree with this characterization of the link above. Here's
the relevant text:

"Believes that, because combatting fingerprinting is difficult, new Web
specifications should take reasonable measures to avoid adding unneeded
fingerprinting surface area. However, added surface area should not be a
primary factor in determining whether to add a new feature."


The more principled position is that we shouldn't have to rely on UA
> sniffing (which this is) to determine what a browser can and cannot
> do.  That there are bugs is the main reason we have these things.
>

I agree people shouldn't  be using UA sniffing for this purpose, but it's
very useful for determining what the heck is going on when there are
inevitably bugs.


Fixing the buildID to the major version (52) plus the channel
> (Nightly) would be the simplest fix without adding lots of extra
> complexity.
>

Maybe. The nightly population is pretty small and inherently has less
privacy, and release tends to be fairly homogenous. I'd like to see
some real analysis of the privacy impact before removing a useful
diagnostic surface.

-Ekr

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Martin Thomson]

On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor  wrote:
> Taking a step back: is fingerprinting really a solvable problem in
> practice?  At this point, are there a significant fraction of users
> who can't be fingerprinted pretty reliably?  Inevitably, the more
> features we add to the platform, the more fingerprinting surface we'll
> expose.  At a certain point, we might be taking away a lot of features
> for the sake of trying to stop the unstoppable.  (I have no idea if
> this is actually true now, though.  This is a genuine question.  :) )

https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

The conclusion: it's probably a lost cause, but we still shouldn't be
building more of these.

The more principled position is that we shouldn't have to rely on UA
sniffing (which this is) to determine what a browser can and cannot
do.  That there are bugs is the main reason we have these things.

Fixing the buildID to the major version (52) plus the channel
(Nightly) would be the simplest fix without adding lots of extra
complexity.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Gregory Szorc]

On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino 
wrote:

> So the Battery Status API has just been removed, I think now is a good
> time to think about navigator.buildID again, which bug [1] has been
> inactive for a whole year.
>
> 4 years ago, Firefox 16 removed a minor version number from the user agent
> string to mitigate fingerprinting [2][3]. However, the build ID unique to
> each minor version is still exposed via the non-standard navigator.buildID
> property. Since trackers can easily retrieve build IDs from Mozilla Wiki
> [4] to map them to minor version numbers, the fix in Firefox 16 was totally
> meaningless.
>
> There were some legitimate use cases on Mozilla properties, for example,
> warning visitors who are using an outdated Firefox, but those usages have
> been replaced with the UITour API [5]. A comment in the bug [1] explains
> that Netflix was also using the build ID to detect a specific playback bug
> in Firefox, but it's probably not longer relevant. Given that, I believe
> the buildID property should be removed, or at least made chrome-only.
>
> Thoughts?
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=583181
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=728831
> [3] https://www.fxsitecompat.com/en-CA/docs/2012/ua-string-no-lo
> nger-contains-patch-level-version-number/
> [4] https://wiki.mozilla.org/Releases/Firefox_49/Test_Plan#Milestones
> [5] https://bedrock.readthedocs.io/en/latest/uitour.html


This is buried in bug 583181, but since Mozilla only ships ~1 build per
version+platform, the buildID adds little fingerprinting potential to
binaries that Mozilla distributes. The main fingerprinting concern is
around Firefox builds not produced by Mozilla. e.g. if you compile Firefox
from source, your buildID has a good chance of being unique. There is also
an increased fingerprinting risk on channels like Nightly with lower
distribution. However, this may be offset by those channels updating daily
and not providing a stable fingerprint to anchor off of.

A compromise position might be to require a configure flag to enable
navigator.buildID (or enable it being non-static). The flag would be
disabled by default but enabled in Mozilla's distributed builds. Downstream
builders would have to explicitly enable it. We could also only enable
"real buildID" on Nightly and Aurora channels, since there appears to be
some benefit to this API there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Aryeh Gregor]

On Mon, Oct 31, 2016 at 4:00 PM, Henri Sivonen  wrote:
> On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor  wrote:
>> If the concern is fingerprinting, perhaps it could be exposed only to
>> sites that the user is logged into (assuming we have a good working
>> definition of "logged in")?
>
> I think that's over-engineering it.
>
> I suggest we make it behave the current way for chrome,
> https://*.mozilla.org and https://*.netflix.com origins and make it
> return a constant otherwise.

This only helps us and Netflix.  Other sites that want to track fixes
will be left out in the cold.

Taking a step back: is fingerprinting really a solvable problem in
practice?  At this point, are there a significant fraction of users
who can't be fingerprinted pretty reliably?  Inevitably, the more
features we add to the platform, the more fingerprinting surface we'll
expose.  At a certain point, we might be taking away a lot of features
for the sake of trying to stop the unstoppable.  (I have no idea if
this is actually true now, though.  This is a genuine question.  :) )
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Gijs Kruitbosch]

The buildID changing rapidly provides a bigger, rather than a smaller, 
fingerprinting surface.


~ Gijs

On 01/11/2016 08:09, Chris Pearce wrote:

It's not just Netflix that the media playback team has used
navigator.buildID in order to validate fixes; we've used it with other
large video sites too. It's invaluable for determining whether a bug has
been fixed in a build. Can we only disable navigator.buildID in release
builds? Don't users on pre-release versions of Firefox update more
often, and thus the buildID changes too rapidly to be useful?

cpearce.

On 11/1/2016 7:01 AM, Domenic Denicola wrote:

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > wrote:



On 10/29/16 9:21 AM, Kohei Yoshino wrote:

I think now is a good time to think about navigator.buildID again
Thoughts?


Seems like we'd potentially end up breaking legacy sites that sniff

that to mean "isMozilla".
I suggest returning a constant value to general Web sites to avoid this
problem.

I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla

If Gecko has no plans to remove this and conform to the spec, could
someone file an issue or pull request on
https://github.com/whatwg/html requesting that buildID be added to
Gecko compatibility mode?
https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Chris Pearce]

It's not just Netflix that the media playback team has used 
navigator.buildID in order to validate fixes; we've used it with other 
large video sites too. It's invaluable for determining whether a bug has 
been fixed in a build. Can we only disable navigator.buildID in release 
builds? Don't users on pre-release versions of Firefox update more 
often, and thus the buildID changes too rapidly to be useful?


cpearce.

On 11/1/2016 7:01 AM, Domenic Denicola wrote:

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > wrote:



On 10/29/16 9:21 AM, Kohei Yoshino wrote:

I think now is a good time to think about navigator.buildID again
Thoughts?


Seems like we'd potentially end up breaking legacy sites that sniff

that to mean "isMozilla".
I suggest returning a constant value to general Web sites to avoid this
problem.

I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla

If Gecko has no plans to remove this and conform to the spec, could someone 
file an issue or pull request on https://github.com/whatwg/html requesting that 
buildID be added to Gecko compatibility mode? 
https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform