Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block Floc checks in Chrome/uBO #1553

Closed
8 tasks
ryanbr opened this issue Apr 10, 2021 · 24 comments
Closed
8 tasks

Block Floc checks in Chrome/uBO #1553

ryanbr opened this issue Apr 10, 2021 · 24 comments
Labels
fixed issue has been addressed

Comments

@ryanbr
Copy link

ryanbr commented Apr 10, 2021

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue
    • Your issue may already be reported.
  • I tried to reproduce the issue when...
    • uBlock Origin is the only extension
    • uBlock Origin with default lists/settings
    • using a new, unmodified browser profile
  • I am running the latest version of uBlock Origin
  • I checked the documentation to understand that the issue I report is not a normal behavior

Description

Block FloC requests within uBO

A specific URL where the issue occurs

Test case: https://amifloced.org/ But will eventually occur on various sites.

Steps to Reproduce

  1. Expect uBO to block requests using Floc
  2. Open : https://amifloced.org/
  3. Detects FloC

Expected behavior:

uBO should block FloC for privacy.
Have an option to counter google's tracking. Would recommend a default option for Chrome, but if not available a configurable option.

Actual behavior:

FloC isn't being blocked in uBO.

Your environment

  • uBlock Origin version: 3.10.2
  • Browser Name and version: Brave V1.22.71 (Apr 1, 2021)
  • Operating System and version: Windows

Maybe too generic, but something like this:

! Remove Floc checks by websites when using Chrome
!#if env_chromium
*##+js(aopr, document.interestCohort)
*##+js(aopw, document.interestCohort)
!#endif
@uBlock-user
Copy link
Contributor

uBlock-user commented Apr 10, 2021

Is this a POC(Proof Of Concept) ? We don't fix POCs.

@uBlock-user
Copy link
Contributor

uBlock-user commented Apr 10, 2021

As per https://developer.chrome.com/blog/floc/ setting Permissions-Policy header -- Permissions-Policy: interest-cohort=() will cause to opt-out/disable this tracking.

@mapx-
Copy link
Contributor

mapx- commented Apr 10, 2021

brave/brave-browser#14942

@mapx-
Copy link
Contributor

mapx- commented Apr 10, 2021

https://www.ghacks.net/2021/04/10/duckduckgo-extension-blocks-google-floc-in-latest-update/

@ryanbr
Copy link
Author

ryanbr commented Apr 10, 2021

Is this a POC(Proof Of Concept) ? We don't fix POCs.

While this has Proof of Concept website from EFF, Google is rolling this out as we speak.

@uBlock-user
Copy link
Contributor

This is a good opportunity to implement Permissions Policy(formerly Feature-Policy) support in uBO.

@uBlock-user uBlock-user added the something to address something to address label Apr 10, 2021
@gorhill
Copy link
Member

gorhill commented Apr 10, 2021

These are way too likely to cause page breakage, since they are meant to abort JS execution midway:

! Remove Floc checks by websites when using Chrome
!#if env_chromium
*##+js(aopr, document.interestCohort)
*##+js(aopw, document.interestCohort)
!#endif

Following solution probably is better, since I gather that websites will have to check for the existence of interestCohort before using it:

! Remove Floc checks by websites when using Chrome
!#if env_chromium
*##+js(set, document.interestCohort, undefined)
!#endif

The only issue is whether this is too often ineffective due to race condition. I do not have Chrome on my side and can't test this. Whoever is found to be part of the trial could try and report.

Given this is a trial, not sure adding a specific setting in uBO to address this is a good idea at this point, there could be changes in the future which would require to re-work the setting.

@ryanbr
Copy link
Author

ryanbr commented Apr 10, 2021

*##+js(set, document.interestCohort, undefined) worked for me.

@gorhill
Copy link
Member

gorhill commented Apr 10, 2021

I suppose we could add it to the "uBlock filters -- Privacy" for now, that's the purpose of the list, to create privacy-related filters optimized for uBO.

gorhill added a commit to uBlockOrigin/uAssets that referenced this issue Apr 10, 2021
@gorhill
Copy link
Member

gorhill commented Apr 10, 2021

I am going to add a scriplet specifically for this purpose:

This way document.interestCohort will be overriden if and only if it exists, and it will return a promise which rejects, the expected behavior when opting out of floc.

gorhill added a commit to gorhill/uBlock that referenced this issue Apr 11, 2021
gorhill added a commit to gorhill/uBlock that referenced this issue Apr 11, 2021
Related issue:
- uBlockOrigin/uBlock-issues#1553

This commit ensures FLoC is opt-in. The generic filter
`*##+js(no-floc)` in "uBlock filters -- Privacy" ensures
the feature is disabled when using default settings/lists.

Users can opt-in to FLoC by adding a generic exception
filter to their custom filters, `#@#+js(no-floc)`; or they
can opt-in only for a specific set of websites through a
more specific exception filter:

    example.com,shopping.example#@#+js(no-floc)
@ghost
Copy link

ghost commented Apr 11, 2021

@ghost
Copy link

ghost commented Apr 11, 2021

@ghost

This comment has been minimized.

@mapx-

This comment has been minimized.

@hvjufg

This comment has been minimized.

@Spacefish
Copy link

Would be great if this could be configurable via Advanced Config, such the the scriptlet for redefining Document.prototype.interestCohort isn´t executed.
There might be some legitimate reasons to use FloC apart from Ad-Targeting. Like filling suggestion boxes with likely values other people in the same FloC ID have selected most commonly or such.
It´s good to block it by default, but would be nice to have ad-blocking + FloC :)

@gwarser
Copy link

gwarser commented Jun 25, 2021

gorhill/uBlock@bfdc81e

This commit ensures FLoC is opt-in. The generic filter
*##+js(no-floc) in "uBlock filters -- Privacy" ensures
the feature is disabled when using default settings/lists.

Users can opt-in to FLoC by adding a generic exception
filter to their custom filters, #@#+js(no-floc); or they
can opt-in only for a specific set of websites through a
more specific exception filter:

example.com,shopping.example#@#+js(no-floc)

@h1z1
Copy link

h1z1 commented Dec 23, 2021

Should have called it floc-off :)

@mapx-
Copy link
Contributor

mapx- commented Jan 25, 2022

https://github.com/jkarlin/topics

FLoC ended its experiment in July of 2021

https://techcrunch.com/2022/01/25/google-kills-off-floc-replaces-it-with-topics/

gorhill added a commit to uBlockOrigin/uAssets that referenced this issue Jan 26, 2022
@krystian3w
Copy link

Now we must follow Topic API, maybe community wrote draft for no-topic scriptlet.

@uBlock-user
Copy link
Contributor

@gorhill
Copy link
Member

gorhill commented Feb 8, 2022

For years I've pointed out that Chrome is an adtech agent, not a user agent, however hard they try to spin it as the latter. This ever present motivation to have adtech API embedded in it just further illustrate that point.

@uBlock-user
Copy link
Contributor

uBlock-user commented Feb 8, 2022

The intent of the Topics API is to provide callers (including third-party ad-tech or advertising providers on the page that run script

I don't think API needs to be foiled, as per the example, it needs to send a fetch request to an ad-server, so as long as we block the ad-server, no need to add yet another scriptlet for this.

gorhill added a commit to gorhill/uBlock that referenced this issue Jan 31, 2023
@fulldecent
Copy link

For all of this discussion of FLoC and v3 manifest, I would much prefer if @gorhill maintained a clear and visible recommendation of what browsers you should use.

He does not owe anything to Google. And if he thinks other browsers are better I would love to see that in the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed issue has been addressed
Projects
None yet
Development

No branches or pull requests

10 participants