Cookie consent options

[anthonypkeane]

Description:

In the EU, almost every website displays a pop up asking users to agree to their cookies. As a user this is v annoying. There are many product that offer this consent management, one being Quantcast Choice (https://www.quantcast.com/gdpr/consent-management-solution/)

Can we have an option in Privacy that allows users to not see these pop-ups? The text can be something like: Hide Cookie consent pop-ups

cc @johnnyryan and @tomlowenthal for approval

[jamesmudgett]

Might be better as a shield?

[johnnyryan]

I answered on Slack in this thread https://bravesoftware.slack.com/archives/C4EE00THC/p1565345327108900?thread_ts=1565340552.108800&cid=C4EE00THC

If we target the adtech 3rd parties using the IAB consent design, which most companies are using, and if we make it very clear to the user what they are deciding to switch on, then I think this is a very good idea.

[anthonypkeane]

See: https://github.com/brave/brave-browser/issues/5318 for more info

[kylehickinson]

1. Needs design: Where is this going? Is it a shield?
   • If it is a shield, will it be domain level with a master switch as other shields are (i.e. user can enable it for N site, or enable it for all and disable it for N site, etc.)
   • If it isn't a shield, will it be a master toggle for all web pages such as "Block all Cookies" and "Private Browsing Only"
2. Needs info:
   • What lists are we using, are they using CSS rules?
   • Do we have the necessary support in https://github.com/brave/ab2cb to support converting these rules correctly?
   • Do these lists need to be maintained and therefore added to the pipeline which converts rules and uploads them to the adblock s3 bucket? (which is not yet fixed btw: https://github.com/brave/devops/issues/1658)

[jamesmudgett]

"Block Cookie Dialogs" toggle in settings under "Block all Cookies"

[anthonypkeane]

The settings text is: Under Block all Cookies add Block Cookie Dialogs (On|Off)

@snyderp can you please reply to @kylehickinson on 2) Needs info above. Thanks

[pes10k]

@kylehickinson there are two (2.5?) approaches here broadly:

1. Do what Cliqz is doing and just auto tell the IAB the user doesn't consent by setting those cookies for users. This has a bunch of nasty side effects, including it undoes a lot of our 3p cookie protections (since need to notify these folks, via 3p cookie, that the user has opted out). We'd need to punch a hole in shields (not impossible, but something to be very cautious about…). It also wouldn't address non IAB folks, and other similar popups

2. Do what @ryanbr does with his anti-cookie message list, which is basically block as much related to the whole system as possible, at any possible vantage point (cosmetic, network, etc). This has the benefit of being pretty easy to deply given our current infrastructure, but I think would cut against @johnnyryan's legal concerns (it also has the typical coverage concerns of filter lists, but thats a "solveable problem" [hand wave])

There are a couple of hybrid options we could consider

• Still keep the 3p cookie blocking with shields (e.g. don't punch an IAB sized hole in them) but just have the browser inject the relevant cookie into those network requests.

• go hard on the filter lists, i can build up automation to target these kinds of annoyances. Would be an interesting Brave distinguishing feature (again assuming it doesn't make us go to jail, re @johnnyryan jkjkjkjkj)

If none of those appeal, let me know and I can keep brainstorming

[anthonypkeane]

We plan on doing 2 @snyderp for now.

@kylehickinson wants to know about the list and has it been set up for iOS, converted etc. He can explain more.

[ryanbr]

Submitted 2 PR's, to replace Prebake (the exisiting cookie list in brave://adblock), given prebake hasn't been updated since 2018.

https://github.com/brave/adblock-rust/pull/67 https://github.com/brave/brave-core/pull/4431

[pes10k]

@ryanbr just to double check, these new lists target cookie consent dialogs, or the whole wider set of dialogs (GDPR, CPAA, cookies, etc)?

@kylehickinson these are not currently pulled into iOS at all. Should they be?

[kylehickinson]

@snyderp We don't currently convert cosmetic rules in ab2cb, if we pull in these lists at the moment, it'll only block loads. If that's fine, we can pull them in. Otherwise we will have to first update ab2cb to convert cosmetic rules as well (including testing these)

[pes10k]

If that's fine…

I think that'll have to be a decision the iOS team makes.

update ab2cb…

I think this would be a good capability to have, even if we don't fully exercise it right now

[kylehickinson]

☝️ cc @brave/ios @anthonypkeane

[ryanbr]

@snyderp Like current prebake list, the Easylist cookie list will just hide the cookie div messages/consent dialogs.

Some sites can't be fixed due to cookies being checked by a website (see: quantcast messages).

[anthonypkeane]

For a setting add

Block Cookie Dialogs toggle in settings under Block all Cookies Default is On

[anthonypkeane]

Hi @pes10k Has there been a decision on whether we are doing this?

[pes10k]

There is no short term iOS plan currently. In brave-core, the immediate option is for users to enable the cookie blocking filter list in brave://adblock (knowing it comes with some webcompat risk). The longer term option is to build smaller, higher confidence list we can check through automation.

For iOS the possible paths i can see are either:

1. enable custom filter lists on iOS (so that iOS users can enable the same useful-but-sometimes-webcompat-risking), and / or
2. wait until we have a higher confidence list (no immediate time frame) and we can incorporate that into the default iOS filter lists

[anthonypkeane]

Hi @pes10k Do you know if there has been any update on either 1 or 2 above? Thanks

[pes10k]

GPC, and the fanboy notification lists are the closest we've done at this point. My sense is that adding the fanboy cookies list would add non-trivial compat risk, and would only be partially useful without cosmetic filtering on iOS.

my suggestion for how to proceed here is:

1. implement cosmetic filtering on iOS
2. add custom filter list support on iOS

My understanding is that neither have been implemented on iOS; i do not know what the current timeline is for those features

[anthonypkeane]

Linked to

https://github.com/brave/brave-ios/issues/2683

[anthonypkeane]

Given the comment on https://github.com/brave/brave-browser/issues/5318#issuecomment-849375469 it seems we can now implement an option to not show the cookie dialogue to users.

Under DISPLAY Show Cookie Consent Dialogues? (On/Off) Enabling this setting aims to prevent websites from asking you to consent to their cookies

Default off for now

[kylehickinson]

Blocked by #2683

[slimal]

Hello,this feature would save a lot of time for European users and #2683 is closed, thus not blocking anymore. Is it possible to unblock it? Thanks a lot!

[Uni-verse]

Verified using version 1.45 (22.11.8.15) on the following device(s):

iPhone 12 - iOS 16.x iPhone XR - iOS 15.x iPhone X - iOS 14.x iPads - iPadOS 16.x, 15.x

Acceptance Criteria: https://github.com/brave/brave-ios/pull/5839#issue-1336364313

Case: user clicks on "Yes block cookie consent notices" on the popup:

• Verified that the setting is enabled in shields
• Verified the cookie notice blocking filter list is enabled
• Verified the animation plays and then the popup disappears

Case: user clicks on "No thanks" on the popup

• Verified the setting is not enabled in shields
• Verified the cookie notice blocking filter list is not enabled
• Verified the popup is dismissed

Case: User enables the settings:

• Verified - the popup doesn't appear on second launch (Note: you will need to enabled it on first launch)
• Verified - the cookie consent notices are blocked

Case: When the setting is not enabled:

• Verified - the popup appears on a second launch (note that depending on timing other full screen popups might appear in priority)

• Verified - Cookie consent notices are not blocked

• Verified synchronization between the cookie blocking setting in shields and the filter list is enabled in filter lists screen

• Verified setting is held when app is terminated/relaunched.

Example	Example	Example	Example	Example

Example	Example	Example	Example