focus-android
focus-android copied to clipboard
Block EU cookie banners
Why/User Benefit/User Problem
What / Requirements
Acceptance Criteria (how do I know when I’m done?)
Checklist:
- [ ] #1497
Websites show "Install our app" and "This page uses cookies" overlays and banners. Often you can click them away and then they won't come back.
Focus doesn't store any data (in this case cookies) and therefore those overlays/banners come back in every browsing session. This is pretty annoying if you frequent such pages often.
There are block lists for such things, e.g.: https://www.fanboy.co.nz/fanboy-cookiemonster.txt
Explanation of Adblock filter rules: https://adblockplus.org/filters
Blocklist for Cookie banners etc: https://www.fanboy.co.nz/fanboy-cookiemonster.txt
The cookie blocking list updates frequently. We might want to think about updating it from a server (and without an app update) or shipping updates in every dot release and somehow automating this.
@eleemoz, as it relates to blocking the "This page uses cookies", are we going against any EU privacy laws? By default, we do not store them.
Also, can we use the fanboy txt list?
We wouldn't do this without a setting - I guess. So I added the "needs strings" label.
The UI is pretty straightforward. It will be an item under the “Privacy” heading that you can toggle on and off.
And in the case of blocking “install our app”, we already know what the OS calls them: “App install banner”.
So we can call the menu item something like:
Block app install banners Embedded on sites to ask you to install their apps
In the case of cookie warnings, we will use a third-party source, so this creates an interesting situation:
- Do we need the author’s approval to include it in our APP?
- The list has two names: “Anti-Cookie Filters” and “Fanboy’s Cookiemonster List”. Do we have to use the names above, or can we come up with our own?
- How do we title and caption this item, so it’s consistent with the rest of the items under the “Block” headings?
Here are some strawman titles for us to get started with:
- Block cookie notification banners
- It has the word “block” and the word “banner” – consistent with other menu items
- Hide cookie warnings
- Remove annoying cookie alerts
- Filter obtrusive cookie notices
- Get rid of cookie notifications
@bbinto The third party source for blocking cookie warnings would be something like this, as @pocmo had mentioned:
https://www.fanboy.co.nz/fanboy-cookiemonster.txt
@pocmo can you please confirm the following how Disconnect blocks first party cookies
- Does it download the cookie to the device or blocks it before it is even downloaded?
- If the app does download it, will it at least block the domain from reading it after?
We are thinking of starting simple and only block EU cookie banners for sites that block cookies from the Disconnect list.
friendly ping, @pocmo :) ^
@bbinto We do not do any Cookie blocking based on the Disconnect lists directly. We block all requests to URLs that are listed in the Disconnect lists - unless the user is not going to any of those pages directly, e.g. on facebook.com we wouldn't block requests to facebook itself.
So while browsing example.com a third-party service from the disconnect list won't be able to set a cookie because we will never load any resource etc. from any of their listed URLs.
Does that help?
@pocmo - Not sure, let me rephrase what you said and please correct/confirm
- We cannot use the Disconnect list to block EU banners (assuming the banner sets first party cookies)
As for smart app banners, do we need a block list or can we block this via the checking the meta data of the HTML page?
Splitting this up into 2 different issues (#2534)
@brampitoyo @ekager looks like we already have an issue open for this item as discussed earlier. Will bring up with GV team.
There's an addon for FFox called "I don't care about cookies" that does exactly this. Unfortunately, it's not for the Android version, but I think it's worth commenting it here just in case it helps anyhow.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Here's a comment so it won't be closed. This issue is important to be addressed imo
Chiming in to keep the issue alive, this sounds like a good feature
Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1802033
Change performed by the Move to Bugzilla add-on.