1485827 - Content Blocking onboarding shows up on the firstrun page of all new profiles

Status: VERIFIED FIXED

(Firefox :: Protections UI, defect, P1)

Description

[François Marier [:francois]]

Attachment: cb-onboarding-on-firstrun.png

As a result of:

- the Shield being shown even when TP is OFF (i.e. DNT also OFF)
- Mozilla properties gating Google Analytics on DNT=1

we are now showing the onboarding for Content Blocking on the very first tab that a new profile will open.

Is that the desired behaviour?

Comment 1

[François Marier [:francois]]

Incidentally, we will be showing the CB Shield on _all_ Mozilla properties due to https://mana.mozilla.org/wiki/display/DATAPRACTICES/Additional+Cross-Organization+Practices#AdditionalCross-OrganizationPractices-MozillaWebPropertiesTrackingPolicy

Comment 2

[(no longer active)]

I think this is a very recent regression.  I didn't get it on the 20180822221004 Nightly but I did get it on the 20180823220048 Nightly.

Comment 3

[(no longer active)]

FWIW that page includes resources below which TP annotations should mark as tracking...

  * https://www.google-analytics.com/analytics.js
  * https://www.google-analytics.com/plugins/ua/linkid.js
  * https://www.google-analytics.com/r/collect?v=1&_v=j68&aip=1&a=1174238687&t=pageview&_s=1&dl=https://www.mozilla.org/en-US/firefox/nightly/firstrun/&dr=&ul=en-us&de=UTF-8&dt=Firefox Nightly First Run Page&sd=24-bit&sr=1920x1080&vp=1268x622&je=0&_u=SCCAAEAj~&jid=438465418&gjid=609653053&cid=788879043.1535067979&tid=UA-36116321-1&_gid=932170070.1535067979&_r=1&gtm=G86MW3R8V&cd40=1&cd41=63.0a1&cd42=default&cd43=1&cd44=0&cd51=false&cd53=false&cd54=false&cd55=false&cd56=Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0&cd58=/firefox/nightly/firstrun/&cd59=61.0.2&cd64=UA Pageview - Core Tracking&cd65=Not logged in&cd66=(not set)&cd67=0&cd68=(not set)&z=1218006202
  * https://www.googletagmanager.com/gtm.js?id=GTM-MW3R8V&l=dataLayer

Note that our requests do not include DNT:1.

After looking at the network panel, I am not at all surprised by the shield behavior.  Looks to me that the shield is behaving exactly as designed.  The Mozilla property should probably stop deploying tracking resources?

Comment 4

[François Marier [:francois]]

Putting down as P1 until we decide what to do about this.

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for 63 since it's a new regression.

Comment 6

[Tanvi Vyas[:tanvi]]

It looks like if Content Blocking is on (which it appears to be by default in a new profile) and Tracking Annotations are detected, the Shield pops up.  Really it should be:
Content Blocking ON
Tracking Annotations detected
TP on in the current browsing mode (normal or private) OR FastBlock ON


Otherwise, you see the shield even when the individual protections are turned off and presumably disable protection does nothing.

Comment 7

[(no longer active)]

(In reply to Tanvi Vyas[:tanvi] from comment #6)
> It looks like if Content Blocking is on (which it appears to be by default
> in a new profile) and Tracking Annotations are detected, the Shield pops up.
> Really it should be:
> Content Blocking ON
> Tracking Annotations detected
> TP on in the current browsing mode (normal or private) OR FastBlock ON

The logic that is implemented in the product is:

If browser.contentblocking.ui.enabled is true:
  If browser.contentblocking.enabled is true:
    If trackers are detected/blocked:
      Show shield
Else
  If TP on in the current browsing mode (normal or private):
    If trackers are detected/blocked:
      Show shield

Right now the shield appearance never depends on FastBlock *or* reject tracker cookie behavior in any way.

> Otherwise, you see the shield even when the individual protections are
> turned off and presumably disable protection does nothing.

Yes, that's what's happening in comment 0.

I think the bug could basically be summarized to this line of code: <https://searchfox.org/mozilla-central/rev/1410bb760a5e77236b74999807f5500bd285a57d/browser/base/content/browser-contentblocking.js#299>.

Comment 8

[François Marier [:francois]]

My guess is that we should only show the Shield if:

1. TP, FastBlock or 3rdparty cookie restrictions is enabled, AND
2. A resource has been blocked.

Essentially ignoring the content blocking pref entirely for this purpose.

Comment 9

[Johann Hofmann [:johannh]]

I don't think we can call this a regression. The feature works as intended, with all Mozilla properties happily deploying tracker scripts on first run.

I agree that we might want to avoid showing the Shield if none of the blockers are enabled. I somehow thought it was specified like this in the UX spec but I can't find it now, must have been my fault. Anyway, that's easy to fix. However, it won't do us any good here, since we're planning to enable FastBlock by default.

I'm very hesitant to only show the Shield if trackers were really blocked (vs. trackers are present). With the random nature of FastBlock this can quickly become an annoying and inconsistent experience for users, IMO.

If really necessary I would rather find a way to work around showing this on the landing page somehow, like adding a delay before the UI tour gets shown.

Comment 10

[Johann Hofmann [:johannh]]

Ok, summarizing the conversation we had yesterday:

1) We're sure that we DON'T want the shield to show when all content blockers are turned off (but the main content blocking toggle is on)
2) We were not 100% in agreement over whether we really want to show the shield "intermittently", e.g. only when FastBlock actually blocks something. I raised concerns over user confusion when the shield is gone after reload, while Tanvi argued that we don't want to indicate that we might be breaking something when nothing was actually blocked.

Since we're stalled on 2) both technologically (we don't have the means to tell if FastBlock blocked something right now) and in discussion, I'm going to resolve 1) which will solve this bug for default profiles in Beta and Release (with FastBlock off) and file a follow-up bug to figure out issue 2).

Comment 11

[Johann Hofmann [:johannh]]

Attachment: Bug 1485827 - Don't show content blocking shield when no blockers are enabled. r=Gijs

Comment 12

[Johann Hofmann [:johannh]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=13e568a0d393a0cabeba57b5c4441763856ba8f1

Comment 13

[:Gijs (he/him)]

Comment on attachment 9004562 [details]
Bug 1485827 - Don't show content blocking shield when no blockers are enabled. r=Gijs

:Gijs (he/him) has approved the revision.

Comment 14

[(no longer active)]

So this bug as filed will come back as soon as any of our content blockers is preffed on by default (e.g. fast block or default cookie restrictions).

Also it would mean that we would show the shield for Mozilla properties on private windows in a new profile, no?

Comment 15

[Johann Hofmann [:johannh]]

(In reply to :Ehsan Akhgari from comment #14)
> So this bug as filed will come back as soon as any of our content blockers
> is preffed on by default (e.g. fast block or default cookie restrictions).
> 
> Also it would mean that we would show the shield for Mozilla properties on
> private windows in a new profile, no?

Tracking Protection is already on by default in private windows and we don't show the onboarding there.

Comment 16

[Johann Hofmann [:johannh]]

Other than that, yes, if we decide on 2) and implement that it should probably get uplifted to 63.

Comment 17

[François Marier [:francois]]

(In reply to :Ehsan Akhgari from comment #14)
> Also it would mean that we would show the shield for Mozilla properties on
> private windows in a new profile, no?

For that case (tracking protection), we are sending the DNT header. Mozilla properties don't load GA when DNT==1.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e442e45cd61e
Don't show content blocking shield when no blockers are enabled. r=Gijs

Comment 19

[Eliza Balazs [:ebalazs_]]

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

Comment 20

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm this issue is no longer reproducible, I verified using Fx 63.0b12 and Fx 64.0a1, on Windows 10 x64, Ubuntu 16.04 LTS and mac OS 10.13.