Implement support for cookie-related filters

[fanboy]

Have noticed that some sites will use cookies to set cookies if adblock is used, a website will either show different ads, or show anti-adblock by using Cookies.

Not sure how it'll check on either on-load or checks site realtime.

Possible allow regex also?

||website.com^$cookie-set="Name, variable"

Could set a filter Name and variable on load of website

||website.com^$cookie-remove="Name"

Remove a cookie.

||website.com^$cookie-hide="Name"

Hide a specific cookie from a site, but dont remove it? (not sure if this would be possible)

||website.com^$cookie,third-party

Block all third-party setting cookies to the site.

||website.com^$cookie

Stop cookies on a site.

Thoughts?

[fanboy]

Example of how it'd work, Blocking the cookie-consent dialog message from showing:

On www.mymuesli.com, the site will set a range of cookie names. But the one that is used is cookies_consent_set, if this set to true. It won't show the consent/gdpr warning.

||mymuesli.com^$setcookie="cookies_consent_set","true","noexpire"

Since I can't reliably block the message via css or standard filters. Having a cookie set/delete option would be pretty handy. Tested with the "Cookiebro" firefox extension.

[mjethani]

There is of course a security risk with letting filter list authors set cookies.

[fanboy]

seems Adguard has a similar feature; see: ​https://github.com/AdguardTeam/AdguardFilters/blob/master/AnnoyancesFilter/sections/cookies_specific.txt#L1621

neckermann-reisen.de#%#document.cookie = "useOfCookiesAccepted_live = true";
dm.hu#%#document.cookie = "dmDrogeriemarkt_euLaw_userDidNotOptIn = true";

[fanboy]

Here is a testable use case (for cookies)

If you're from the EU, theverge.com will set 2 document.cookie's; to determine whether it show a cookie warning message. If you try and hide the element (##.m-privacy-consent & ###privacy-consent) it'll remove the message but also prevent content like videos from playing.

The 2 theverge.com document.cookie's set:

_chorus_geoip_continent:EU
_chorus_privacy_consent:1539677377873-a9326516419003202124200154273271

Which in theory I could by pass the cookie message with something like; (using similar adguard syntax as a example)

theverge.com#%#document.cookie = "_chorus_geoip_continent=EU"; document.cookie = "_chorus_privacy_consent=111111111111-a9999999999999999999999999999999";

[greiner]

That appears to be more of a workaround on their end by using their JavaScript filters that allow filter authors to inject arbitrary JavaScript into a web page.

While we could technically offer a similar functionality using snippets - thereby avoid injecting arbitrary scripts - the more ideal approach would be to use the ​browser.cookies extension API.

That doesn't mean that such a functionality should be offered though since mjethani's argument remains valid. Presumably it'd require limiting the capabilities of such a feature to only a predefined set of values that a cookie can be set to.

[fanboy]

I do understand the privacy concerns, given ad companys (and cookie-message checks) rely on cookies being set, i thought it would be an easy way easily bypass. How would using snippets would fix the issue?

[greiner]

It wouldn't. JavaScript filters, snippets and the extension API are merely ways to implement such functionality. Privacy and security are overarching topics that affect how such functionality is exposed to filter authors and restrict which of the aforementioned techniques can be used.

For instance, as you pointed out, it is technically possible to implement such a feature using JavaScript filters but they aren't suitable concerning privacy and security since they allow/require filter authors to inject their own JavaScript code into web pages.

While snippets and the extension API reduce that risk (e.g. by not allowing arbitrary script injection), they'd still require sound design choices to limit the functionality as much as possible. That's necessary to allow only the use cases we need to support while preventing any potential misuses.

[sebastian]

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the ​new issue tracker.