254 karma · joined August 2, 2017
I agree with you though. It's sad that content is being reformulated for those reasons.
If they get caught lying (and that tends to happen in the end) that's another violation that is taken seriously nowadays.
For example, my e-mail server started picking up messages from DELETEDmyname@mydomain.org. Making it pretty clear a company did not respect my wishes to completely delete all data and user account references. They simply changed my email in the DB.
That's the only mechanism one can use to really be compliant as GA (and other providers) stick identifiers onto the session as soon as the script has been loaded.
Many "cookie banners" have finally started to work in the EU. Once you deny PII processing many sites don't load GA etc... The time of malicious compliance is starting to pass. Some sites have figured it out and realized they really don't need personalized analytics and have replaced implementations with privacy respecting ones(ex, plausible). This lets them remove the dark-patternish banner and no additional consent is required as all data is pooled together and one persons actions truly can't be singled out.
GDPR obviously has other good effects but as PII processing through cookies is what most people know, I chose that as an example. Email tracking links & pixels are another good example.
There's also a big difference between 2018 and 2025 when discussing GDPR in work contexts and saying that implementing this or that tracking would be illegal.
It's a slow process, but it's working as intended.
I agree that they should really be asking for consent as well, but they don't seem to be doing that. We've got no way to use legitimate location related functionality and deny advertising related usecases. Remember, consent must be specific and granular.
It'll be a while, until enforcement catches up. It's taken ~6 years for cookie banners to get a "reject" button and those are really easy to review and enforce.
It'll happen though, enforcement is just slow. GDPR is a fairly well written regulation, as far as corner cases and catching workarounds goes. So unless the laws change, enforcement will catch up eventually.
They also removed a promise to "never sell your data" in their FAQ[2] 2 weeks ago.
[1] - https://news.ycombinator.com/item?id=43326230
[2] - https://github.com/mozilla/bedrock/commit/d459addab846d8144b...
Two of the possible 3rd party choices are "Advertising or marketing" and "Personalization". These two have been chosen for firefox. This includes sharing data with advertising partners.
https://support.google.com/googleplay/android-developer/answ...
A change to those options is what triggered the notification. It's not a requirement for using location features.
I'd say a part of figuring out what they are doing is reading such information. Even if the code itself doesn't reflect it yet, it's usually listed in preparation.
It's also a good way to figure out the code needs to be reviewed :)
Opening the "data safety" section another pop-up[1] comes up and the specific use-cases listed are "advertising or marketing" and "personalisation".
Once it's used for other (technically non-essential) needs as well, one needs to find another basis for processing or ask permission for that second purpose(consent basis).
Also, if the LB cookie can be non-identifying, while fullfilling the stated technical purpose, it must not allow identifying users. So for LB cookies, one must not use a unique ID per user, but an LB ID instead. Something like "node1", "node2" etc...
GDPR Article 7, 3, conditions for consent.
> It shall be as easy to withdraw as to give consent.
If the lower don't suffice, we will get closer & closer to the maximum.
Currently, it seems like the iphone SE is alone in the segment?
https://www.iccl.ie/news/gdpr-enforcer-rules-that-iab-europe...
https://www.gegevensbeschermingsautoriteit.be/publications/b...
So here we'd just block "tag manager web container" no?
While I agree, that a full audit would be difficult for smaller operations, it took me 2-5 minutes to do a quick check on what is being stored client-side and to come to a logical conclusion if individual users are being tracked or not.
It's a decision, one that you can (probably) make. For me, in the EU, it's no longer a choice and I personally think regulation(GDPR) was needed because, without it, no one took user-privacy seriously.
> As for your second point, yes, that is precisely what I referred to in my original post - that we could deal with the end of IDFA / that we just want to make sure ads are effective - SKAN which provides aggregated statistics is mostly ok for us.
GDPR would also apply here. If there's an option to process less data and achieve a similar result, one should use that option and using a more invasive method(identifying individuals) for tracking would be illegal. It's called "the data minimisation principle"
So it's not enough to allow them to opt-out with an e-mail exchange or an unsubscribe link, you must allow the user to opt out when you initially gather the contact information.
If that wasn't done, it's illegal (and unethical) to send marketing e-mails, even from a paid service.
Neither feeling is invalid.
My real point is, if you use a service to provide your own service, you give them your blessing to do whatever they want with your brand. This includes facebook and their tracking scripts.
Thus we need to audit what our service providers are doing and limit their impact once we've completed the evaluation, making sure they don't alter the deal later.
Also tracking ad conversions is as simple as using a unique parameter per campaign, when buying the add. Just append `?campaign=facebook_campaign-name_202202` to your link and that's enough to measure the ads effectiveness. No need to attach unique ID's to users, sessions etc... Aggregates keep the users anonymous and give you enough actionable insight.
well. if your goal isn't tracking individuals, then why are you attaching unique ID's (in cookies) to track individuals on your website?
And I'm not talking about third-party cookies disguised as first-party.
logglytrackingsession (lifetime: session)
notion_experiment_device_id (lifetime: 1 year)
Both are unique to a specific user and are used to identify a single individual. The first one is short-lived, but obviously meant for tracking and the second one can be used for tracking, identifies a single individual and is long-lived.
edit: turning off my adblocker, some more appear.
_ga, _ga_4GMCF7E1GC, intercom-id-gpfdrxfd, notion_browser_id, amp_af43d4
none of these are listed or explained in your privacy policy.[1]
[1] - https://shared-crater-f3a.notion.site/Sticky-Privacy-Policy-...
So now that we have confirmed that they do indeed process PII and use the consent string as the unique identifier that ties the whole profile together we can start doing what you want. Going after the companies that attach other datasets to the consent string.
Before this ruling, the companies/controllers would have said that we process no personal data, thus GDPR doesn't apply. Now we have a ruling, saying that this is not a valid excuse.
Actually, this is not left blank at all...
--------------------
Consent means offering individuals real choice and control. Genuine consent should put individuals in charge, build trust and engagement, and enhance your reputation.
Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent.
Keep your consent requests separate from other terms and conditions.
Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough.
Be clear and concise.
Make it easy for people to withdraw consent and tell them how.
Avoid making consent to processing a precondition of a service.
https://ico.org.uk/for-organisations/guide-to-data-protectio...
It's a cycle and I can confidently say, working in a company that has used the same approach to win customers over, it's really hard to keep the honest culture going.
Personalized analytics and tracking roll-out (including on-prem) was pulled back ~2 years ago[0], they're on another try[1] currently with a heavy-handed hiding approach. Including small additions to release notes[1], short lived and hard to find feedback threads[2] etc...
Including deleting/hiding tickets that get posted on HN[3][4] and contain plans/info that users might take negatively/provide negative feedback on.
[0] - https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/5672
[1] - https://about.gitlab.com/blog/2021/07/20/improved-billing-an... - "4. operational data"
[2] - https://forum.gitlab.com/t/updates-to-de-identifying-service...
[3] - https://gitlab.com/gitlab-org/gitlab/-/issues/342078 - "Pseudonymization MVC Rollout Plan"
[4] - https://news.ycombinator.com/item?id=28840685 - issue submitted to HN[3] that got deleted/hidden quick.
PS: full disclosure, I've been an active opponent of these changes, as they are illegal in the EU and make it impossible to self-host the service while protecting our users privacy.
Some EU countries require that you offer a simple and effective option to opt-out when gathering the contact details. Depending on the content, that can be a required to be an opt-in toggle.
It's not enough to offer users a way to unsubscribe once you've already started spamming them, there should be a way to not have the first spammy newsletter/newsletter group.
This works really nice with a docked/undocked setup. When the additional monitors are disconnected, all workspaces move to the main(laptop) display.
eg, I have workspaces 1,2,5,9 on monitor 1 and screens 3,4,6,7,8,10 on monitor 2. When undocked all 10 workspaces move to the laptop screen.