Adding $uuid$ to set-cookie (and maybe other set- options)

[ryanbr]

snowandrock.com##+js(trusted-set-cookie, consent_identifier, 16f69085-c6f2-42f6-a4cd-807b24a37c0b, , , reload, 1)
snowandrock.com##+js(trusted-set-cookie, consent_setting, analytics%3A0%7Cfunctional%3A1%7Cmarketing%3A0)

Too something like:

snowandrock.com##+js(trusted-set-cookie, consent_identifier, $uuid$, , , reload, 1)
snowandrock.com##+js(trusted-set-cookie, consent_setting, analytics%3A0%7Cfunctional%3A1%7Cmarketing%3A0)

If we could generate a random uuid rather share the same uuid, would improved user privacy.

[gorhill]

@ameshkov Thoughts?

[ameshkov]

The point makes sense to me, this consent_identifier is http-only so it's analyzed server-side. But honestly, I'd wait for at least a couple more cases when a dynamic random value may be useful so that we weren't adding new things for the sake of a single rule.

One more thing, if dynamic values introduced to trusted-* scriptlets, I'd prefer to be able to mix them with string literals, something like this: sometext${randomInt(0,10)}, I have a gut feeling that it'd be required anyways.

@ryanbr are there any other examples? Is there need for other random dynamic placeholders? Random dates or decimals for example?

[ryanbr]

Not a lot of sites so far, Found https://www.asadventure.lu/ & https://www.cotswoldoutdoor.com/ using the same style of consent.

Only referencing uuid, since its a specific unix format uuidgen might be easier to implement. Could get a bit messy if we then include or not include hex characters, or just numbers, then various lengths, maybe that's more a work in progress.

Using the same uuid could be a way to track uBO/Brave/ADG users

[ameshkov]

Three websites is better than one. But there's another point. This cookie is not shared with other websites and can only be read by the website that the user visits. If the website decides to track content blockers, I doubt they'll use the cookie angle, is is much more likely that they will instead use the standard bait approach and it will give them a more precise result. It may be that we're trying to defend from something that is not an issue.

[ryanbr]

I guess its one tracking angle , not the only one though. Tracking users on consent details (if they're using a consent blocker). May not be a issue currently, just aiming to avoid future/potential tracking vectors.

If implemented, do we generate a uuid on page load?

Just using a uuigen, uuid: (just confirmed these work with a random uuid)

asadventure.lu,cotswoldoutdoor.com,snowandrock.com##+js(trusted-set-cookie, consent_identifier, 39bc3240-9f26-4109-9eab-d33b87a86346, , , reload, 1)
asadventure.lu,cotswoldoutdoor.com,snowandrock.com##+js(trusted-set-cookie, consent_setting, analytics%3A0%7Cfunctional%3A1%7Cmarketing%3A0)

[stephenhawk8054]

Another reference: https://github.com/uuidjs/uuid

I saw this being used in https://www.lse.co.uk/ but for anti-adb (fs.adb), the value is in local storage tho

[Yuki2718]

easylist/easylist#12871 (comment) requires a rule like

ryobitools.eu##+js(trusted-set-cookie, OptanonAlertBoxClosed, 2024-07-07T12:10:00.641Z)

[peace2000]

@Yuki2718

Does the value have to be different for everyone or are you just worried it will stop working at some point because the value has a specific date on it?

Any date and time value seems to work for that site. Can set any "neutral" value on it.

E.G.:
ryobitools.eu##+js(trusted-set-cookie, OptanonAlertBoxClosed, 1970-01-01T00:00:00.000Z)
or
ryobitools.eu##+js(trusted-set-cookie, OptanonAlertBoxClosed, 2000-01-01T00:00:00.000Z)

Though if privacy is a concern, maybe a random generated value for everyone is the best.

[Yuki2718]

you just worried it will stop working at some point

Yes this, and as you said using the same value for everyone can be fingerprint.

[gorhill]

Note that ryobitools.eu##+js(trusted-set-cookie, OptanonAlertBoxClosed, $currentDate$) works on my side, so they are just passing whatever string is in OptanonAlertBoxClosed to Date constructor. I will still add $currentISODate$.