Closed Bug 1530050 Opened 8 months ago Closed 7 months ago

Extend Content Blocking API to provide sensible anti-tracking defaults

Categories

(GeckoView :: General, defect)

Unspecified
Android
defect
Not set

Tracking

(firefox66 wontfix, firefox67 wontfix, firefox68 fixed)

RESOLVED FIXED
mozilla68
Tracking Status
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: dholbert, Assigned: esawin)

References

()

Details

(Whiteboard: [geckoview:fenix:m4] )

Attachments

(1 file)

STR:

  1. Install Android Reference Browser
    (https://groups.google.com/forum/#!forum/mozilla-reference-browser)

  2. In its settings, turn on tracking protection "in normal browsing"

  3. Visit https://anightatthegarden.com/

EXPECTED RESULTS:
There should be an embedded video from vimeo.com at the top of the page.

ACTUAL RESULTS:
The embedded video is blocked.

I get "expected results" from:

  • Firefox Nightly on Android (with tracking protection)
  • Firefox Focus on Android (with all possible blocking enabled, including "other content trackers" which weren't blocked by default)
  • Firefox Nightly on Desktop (with content blocking bumped up to "strict, may break pages")
  • Reference browser if I don't have tracking protection turned on.

I only get "actual results" in Reference-Browser-with-tracking-protection-enabled.

Flags: needinfo?(snorp)

Can Gecko View team please take a look at this?

FWIW, I can reproduce this issue on default-configured Fenix as well (which I believe has tracking protection enabled by default and uses geckoview, so it's functionally equivalent to Reference-Browser-with-Tracking-Protection, from this bug's perspective).

Eugen, can you take a look?

Flags: needinfo?(snorp) → needinfo?(esawin)

The video is blocked by ContentBlocking.AT_CONTENT which should not be enabled by default (it's not enabled in GeckoView by default).
I assume that the apps use ContentBlocking.AT_ALL to set up tracking protection, which is not advisable since the content category will cause issues on some sites. ContentBlocking.AT_CONTENT can be added optionally through a more strict, non-default, setting.

Flags: needinfo?(esawin)

Maybe it's worth splitting the catch-all AT_ALL into AT_DEFAULT and AT_STRICT or similar to prevent that issue and increase awareness for potential issues at the API level.

In bug 1536488, I'm working on something similar where, AT_CONTENT is always enabled, but it's not notified and it's not considered as a tracking resource if privacy.trackingprotection.strict_list.enabled is set to false.

Depends on: 1536488

(In reply to Andrea Marchesini [:baku] from comment #6)

In bug 1536488, I'm working on something similar where, AT_CONTENT is always enabled, but it's not notified and it's not considered as a tracking resource if privacy.trackingprotection.strict_list.enabled is set to false.

This might break and limit the options of the current GV API. Please make sure that we can still combine arbitrary tracker options in the GV Content Blocking API.

To clarify, this bug is not an API issue, it's an app configuration issue and doesn't require GV changes for the fix.

The proposed API change from comment 5 would just make the API clearer to the app developer, as it seems that AT_ALL is used as the default configuration by convenience and/or lack of a warning the in the AT_CONTENT documentation.

I'll re-purpose this bug to address the API improvement.

Assignee: nobody → esawin
Component: Privacy: Anti-Tracking → General
Product: Core → GeckoView
Summary: Video embed at anightatthegarden.com is blocked by Android Reference Browser (with tracking protection), though not in other Firefox builds → Extend Content Blocking API to provide sensible anti-tracking defaults
Target Milestone: --- → mozilla68
Pushed by esawin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2ce7f6ee895d
[1.0] Add recommended and strict content blocking categories selections for safer app defaults. r=snorp,geckoview-reviewers
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED

67=wontfix because these new blocklist categories are experimental and not needed for Fenix MVP.

(In reply to Chris Peterson [:cpeterson] from comment #12)

67=wontfix because these new blocklist categories are experimental and not needed for Fenix MVP.

I think you mean bug 1538337, but this bug is wontfix, too, because it's a non-essential change.
I've marked bug 1538337 67=wontfix.

Duplicate of this bug: 1541632
Duplicate of this bug: 1528585
OS: Unspecified → Android
Whiteboard: [geckoview:fenix:m4]
You need to log in before you can comment on or make changes to this bug.