Closed Bug 1485827 Opened Last year Closed Last year
Content Blocking onboarding shows up on the firstrun page of all new profiles
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?
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
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.
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>m=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?
Putting down as P1 until we decide what to do about this.
Priority: -- → P1
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.
(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>.
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.
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.
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).
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
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.
Attachment #9004562 - Flags: review+
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?
(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.
Other than that, yes, if we decide on 2) and implement that it should probably get uplifted to 63.
(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.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/e442e45cd61e Don't show content blocking shield when no blockers are enabled. r=Gijs
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.
You need to log in before you can comment on or make changes to this bug.