1070138 - only send version number in "appinfo" payload

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

See bug 1065525 comment 14. The product requirement here is that we are able to filter out outdated Firefoxes, and nothing more. We should only send enough information to be able to answer that question. I think the version number should be sufficient for that, but we may also need "is this ESR?", or the release channel.

Comment 1

[Matthew N. [:MattN]]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #0)
> See bug 1065525 comment 14. The product requirement here is that we are able
> to filter out outdated Firefoxes, and nothing more.

I think it's different: We want to identify users who are running the same build as what they would be downloading. I can see us wanting to take the various fields into account to deal with partner, third-party, and/or unofficial builds. The release channel e.g. ESR is also necessary. I don't see how this information hurts given it's only for whitelisted sites.

Comment 2

[Justin Dolske [:Dolske]]

(In reply to Matthew N. [:MattN] from comment #1)
> [...] I can see us wanting to take the
> various fields into account to deal with partner, third-party, and/or
> unofficial builds.

Why are partner builds (repacks, really) be interesting? Seem irrelevant for what bug 1062345 is doing.

Also not sure why 3rd-party or unofficial builds are worth spending time on -- they're an extremely tiny minority of usage.

> The release channel e.g. ESR is also necessary.

Hmm. Is it actually? The page driving this is still going to need have it's own knowledge of what the current ESR version is. For example, a client saying "I'm version 10, but I'm ESR!" is still out of date. ESR clients can also generally be determined through the version number, since it increments by 0.1 per non-ESR version. (EG, When Firefox 33 is released, Firefox 31.2 will be the equivalent ESR release).

I suppose there's a small window of ambiguity when right after a new ESR version jump (right at Firefox 32's release, you wouldn't know if a 31.0 client was ESR or not since AFAIK the versions are identical). But again, for what bug 1062345 is doing, does that matter?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to Matthew N. [:MattN] from comment #1)
> I think it's different: We want to identify users who are running the same
> build as what they would be downloading.

That's probably the core of the disagreement. I don't think that degree of precision is necessary or useful.

Comment 4

[Alex Bardas :alexbardas]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #0)
> I think the version number should be sufficient for that, but we may also need 
> "is this ESR?", or the release channel.

I think "version" and "defaultUpdateChannel" params should satisfy those conditions.

Comment 5

[Alex Bardas :alexbardas]

Attachment: Send version and update channel in "appinfo" payload

Comment 6

[Matthew N. [:MattN]]

FWIW, I still haven't heard reasons for why to remove this info, only reasons why some may not be used for the basic case.

I'll reply in detail in a bit.

Comment 7

[Matthew N. [:MattN]]

(In reply to Justin Dolske [:Dolske] from comment #2)
> (In reply to Matthew N. [:MattN] from comment #1)
> > [...] I can see us wanting to take the
> > various fields into account to deal with partner, third-party, and/or
> > unofficial builds.
> 
> Why are partner builds (repacks, really) be interesting? Seem irrelevant for
> what bug 1062345 is doing.

The point of bug 1062345 is to change the messaging on www.mozilla.org when a user is trying to re-download the same build of Firefox as they are already using. The idea is that we think that those users are trying to fix an issue by doing a reinstallation but since the installer currently doesn't touch the profile(s), in many cases a reset would be more useful.

See my original rationale:
(Quoting Matthew N. [:MattN] from bug 1065525 comment #4)
> I think it would be useful to include some other properties such as ID (to
> be sure it's Firefox), defaultUpdateChannel, distributionID,
> isOfficialBranding, isReleaseBuild in case we want to prevent offering a
> reset for unofficial, non-release, and/or partner builds.
> 
> e.g. Suppose I'm running a partner build with a default search engine other
> than Google. If I go to mozilla.org to download vanilla Firefox, I should be
> able to easily download it instead of being redirected to do a reset which may
> leave me with partner customizations that I don't want.

> Also not sure why 3rd-party or unofficial builds are worth spending time on
> -- they're an extremely tiny minority of usage.

I was trying to save time so when the scenario arises where mozilla.org wants to distinguish between build variations then they are able to immediately. This allows quicker turnaround to respond to issues. I wasn't saying that the website should use all of these properties on day one.

> > The release channel e.g. ESR is also necessary.
> …
> I suppose there's a small window of ambiguity when right after a new ESR
> version jump (right at Firefox 32's release, you wouldn't know if a 31.0
> client was ESR or not since AFAIK the versions are identical). But again,
> for what bug 1062345 is doing, does that matter?

Right, I think the first ESR release is a problem and yes it is a problem IMO: If I'm an ESR user and I want to switch to normal Firefox (e.g. I'm at work and want a more modern Firefox), I shouldn't be distracted/redirected into doing a reset.

My main concerns is that we're actually going to be not helping as many people by making it harder for them to install a new clean official build of Firefox. There are many cases where users want a fresh download instead of a reset:
* user who are not on the release channel (e.g. ESR/Aurora/Beta) but want to switch to it. The page in question is for release Firefox so shouldn't be offering resets for Nightly/Aurora/Beta users. That should be done on their respective pages or not at all due to the nature of the audience.
* users with a build that has an unwanted default search engine (including partner and malware builds)
* malware builds (perhaps the appinfo exposed will be identical though)
* user has a build with a defaultUpdateChannel that we don't support. e.g. "default"

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to Matthew N. [:MattN] from comment #6)
> FWIW, I still haven't heard reasons for why to remove this info, only
> reasons why some may not be used for the basic case.

The base premise is that we shouldn't report information we don't need.

(In reply to Matthew N. [:MattN] from comment #7)
> My main concerns is that we're actually going to be not helping as many
> people by making it harder for them to install a new clean official build of
> Firefox. There are many cases where users want a fresh download instead of a
> reset:
> * user who are not on the release channel (e.g. ESR/Aurora/Beta) but want to
> switch to it. The page in question is for release Firefox so shouldn't be
> offering resets for Nightly/Aurora/Beta users. That should be done on their
> respective pages or not at all due to the nature of the audience.

The Firefox version is sufficient for filtering these cases.

> * users with a build that has an unwanted default search engine (including
> partner and malware builds)
> * malware builds (perhaps the appinfo exposed will be identical though)

I don't know what you mean by "malware builds" or how common you expect them to be, but nothing about bug 1027318 is making it impossible for the users we prompt to download a new build.

> * user has a build with a defaultUpdateChannel that we don't support. e.g.
> "default"

This should be close to zero users, unless there are some cases I don't know about.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 8493278 [details] [diff] [review]
Send version and update channel in "appinfo" payload

Thanks!

Comment 10

[Alex Bardas :alexbardas]

Here is the try run output:

https://tbpl.mozilla.org/?tree=Try&rev=9f447c3e89d7

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/c72f3b42770c

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c72f3b42770c