1520497 - [Content blocking] Blocking is displayed when not blocking

Status: NEW

(Firefox :: Protections UI, defect, P3)

Description

[David Olah]

Attachment: simplescreenrecorder-2019-01-16_17.18.48.mp4

[Affected platforms]
Ubuntu 16.04, Windows 7/10, Mac OS 10.13

[Steps to reproduce]

1. Open Firefox with a new profile
2. Go to Content Blocking from Hamburger menu
3. Set Strict
4. In a new tab go to: https://patrickhlauke.github.io/recaptcha/
5. Open Shield menu

[Expected result]
Shield icon appears because a cookie was detected.
Trackers don't appear because there are none.
Cookies appear and blocking is not shown, because no cookie is being blocked

[Actual result]
Shield icon doesn't appear.
Trackers are shown in 66 and when opened, no trackers are shown. In 65, the trackers don't appear.
Cookies appear but blocking message is shown, even if when opened there is only one detected cookie that is not blocked.

Comment 1

[(no longer active)]

Yet another problem caused by the presence of the labels.

The reason why https://www.google.com shows up as not being blocked here is that it is actually not being blocked, since Recaptcha has a site-specific workaround which was added in bug 1507013. But of course, this label incorrectly leads the user to believe that we would block any cookie that we see from a tracker, which actually doesn't completely match with how Gecko's cookie policy works.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 66; it seems likely we will ship with this issue in 65 but it would be nice to clarify for 66.

Comment 3

[Tanvi Vyas[:tanvi]]

In Firefox 65 beta 10, I use the Content Blocking: Strict setting. I go to https://patrickhlauke.github.io/recaptcha/. The Shield does not appear in the url bar. This is correct. Nothing is blocked, so the shield should not appear and unnecessarily alert the user. The Cookies section appears in Control Center and says "Blocking Tracking Cookies". The submenu shows there are no tracking cookies detected. It shows that their is a third party cookie from google.com that loaded. Hence, in this scenario, there is no bug.

Now instead, if I

1. go to about:config and change urlclassifier.trackingAnnotationTable to "test-track-simple,base-track-digest256,content-track-digest256" (this is the Disconnect Strict List)
2. go to about:url-classifier and trigger an update on the list
3. refresh https://patrickhlauke.github.io/recaptcha/

I get:

• No shield, which is good because nothing is being blocked.
• Trackers listed in the Control Center menu. The Trackers subpanel saying "None detected on this site".[1]
• Cookies listed in the Control Center with "Blocking Tracking Cookies". The Cookies subpanel showing google.com as a Tracking Cookie, but showing that it is not blocked.[2]

[1] This is a known bug that we should try to fix before we move to the strict list. When detecting trackers, we are using the list in urlclassifier.trackingAnnotationTable. But Trackers are actually from the urlclassifier.trackingAnnotationTable, which is set to something else in this case (The Disconnect Basic List).

[2] This is because we have put in a sight specific work around for recaptcha. There is an about:config pref urlclassifier.trackingAnnotationSkipURLs with the value "google.com/recaptcha/,*.google.com/recaptcha/". Even though, according to the Strict list, google.com is a tracker, we have whitelisted the recaptcha case. As a consequence, it is showing up as Tracking Cookie. We could find a UX solution for this specific case, or rethink our UI. Needinfo Betsy and Bryan for this part.

We haven't done user testing on the Disconnect Strict list yet, so it has some ways to go before putting it in release. We will not be exposing the strict list for cookie restrictions in Firefox 65 release or Firefox 66 release. This bug will exist in Nightly and early beta 65 and 66 (where we do default to the strict list). Hence, here we have uncovered 2 bugs, but I think we can wait until 67 or after to fix them since we aren't using the Strict list before that.

Comment 4

[Tanvi Vyas[:tanvi]]

Marking 65 and 66 as wontfix.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks Tanvi! That's so helpful.

Comment 6

[David Olah]

Ryan, was marking 65 and 66 as disabled a mistake or is it a specific reason for this?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Per comment 3, we're not using the strict list for non-Nightly, so the feature in question is effectively disabled.

Comment 8

[zybersup]

Attachment: content-blocking-status-blockable-detected-but-none-detected.png

I would like to give other example which might be from nearly the same cause. I have been using Firefox on my developing machine with my internal back-office web app that means no 3rd party tracking at all. There is only my own JavaScript setting cookies via document.cookie = 'key=value'. But the label says 'Blockable content on this site' and when we click to see which content is blockable, it says nothing.

See the captured images.

Comment 9

[Johann Hofmann [:johannh]]

(In reply to zybersup from comment #8)

Created attachment 9102779 [details]
content-blocking-status-blockable-detected-but-none-detected.png

I would like to give other example which might be from nearly the same cause. I have been using Firefox on my developing machine with my internal back-office web app that means no 3rd party tracking at all. There is only my own JavaScript setting cookies via document.cookie = 'key=value'. But the label says 'Blockable content on this site' and when we click to see which content is blockable, it says nothing.

See the captured images.

This will be different in 70, probably in a way that feels better to you.

Comment 10

[demarco575]

was this ever resolved in newer versions? i noticed bad captchas today and editing this annotation corrected the issue but im wondering its unsecure to use this workaround on a daily basis?

thanks

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:prathiksha, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Comment 13

[Joceyln]

I am facing the difficulties in blocking the ads from Firefox on this website https://streameastguide.com