This is kind of the subtlety that I'm getting at here: what the GDPR says is you need to say how you (as a controller operating a website) are tracking people.
Because the minute you throw down a technical rule it's trivial to route around it. Case in point: say you allowed only 1st party cookies (as defined by cross domain browser behavior and cookie setting). I could setup a CNAME for analytics.my-domain.com that points to FB's ad retargeting servers and they could include in the actual cookie data my id, ip or whatever else they'd need to lookup a user's information across domains.
Same with IPs: every GDPR discussion devolves into someone saying: "Well every site uses IPs! We have them in our logs, etc.! It's stupid to say that they're personal data" Which is how I thought of them until getting a glimpse into some of the ad networks/bidding where they are treated as more or less a currency for targeting, demographics, etc.
With GDPR it's not the data it's what done with the data.
I mean, there's nothing wrong with statutes and regulations being worded generally as long as they are not vague. Getting too prescriptive in this particular context would be counterproductive as the technology issues change over time.
What GDPR should say: things like "do not allow third-parties to track your users" or "warn users about third-party tracking". That would be exceedingly clear and actionable.
Now, "do not allow third-parties to track your users" might require some additional regarding implementation via contractual clauses. For example, if site A uses resources from site B and has a contract with B stipulating non-tracking of A's users, is that good enough? What if B is outside the EU? And so on. But aside from such side issues, "do not allow third-parties to track your users" is trivial to implement: a) only embed resources from third-parties that agree not to track your users, b) do not embed resources from any other third-parties.
"Warn users about third-party tracking" is even easier to implement: if you embed resources from third parties, you must warn.
> With GDPR it's not the data it's what done with the data.
Good! You can use contracts to manage this with all the third-parties you deal with.
Now, what about links to [non-embedded] external resources? We must not kill the web.
You can't make a first party cookie work the same as a third party cookie. They wouldn't follow you across sites, which is the whole point of a third party tracking cookie. Facebook wouldn't know it's you visiting a site or know the same person visited site A and site B.
My point was that it could be combined with the other tracking means (say a browser fingerprint or HSTS fingerprint or both) and that value be transferred in a "first party" domain that was really just a CNAME'd third party server -> and you have a solution that would meet the requirement to "only set 1st party cookies" but would miss the intent of the regulation.
Because the minute you throw down a technical rule it's trivial to route around it. Case in point: say you allowed only 1st party cookies (as defined by cross domain browser behavior and cookie setting). I could setup a CNAME for analytics.my-domain.com that points to FB's ad retargeting servers and they could include in the actual cookie data my id, ip or whatever else they'd need to lookup a user's information across domains.
Same with IPs: every GDPR discussion devolves into someone saying: "Well every site uses IPs! We have them in our logs, etc.! It's stupid to say that they're personal data" Which is how I thought of them until getting a glimpse into some of the ad networks/bidding where they are treated as more or less a currency for targeting, demographics, etc.
With GDPR it's not the data it's what done with the data.