Earlier quoted context omitted.
This seems to be a very common misconception, but the cookie consent dialogues are not part of GDPR.
https://gdpr.eu/cookies/ Cookie compliance To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies. Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received. Document and store consent received from users. Allow…
Statement on 4 Years of GDPR
151–160 of 195 posts
Re: Statement on 4 Years of GDPR
#152Earlier quoted context omitted.
Yes, each request can explicitly (well, not for the end user) carry the session id - or, say, one of the previous request ids. Cookies do that automatically, but have side effects by remaining in the system.
Is there any way of maintaining session IDs across requests without JavaScript other than cookies? My understanding is, the whole point of cookies is that they're automatically sent by the user agent, anything else that was stored (such as in LocalStorage) could only be used by JS scripts.
Re: Statement on 4 Years of GDPR
#153Earlier quoted context omitted.
Yes, each request can explicitly (well, not for the end user) carry the session id - or, say, one of the previous request ids. Cookies do that automatically, but have side effects by remaining in the system.
Is there any way of maintaining session IDs across requests without JavaScript other than cookies? My understanding is, the whole point of cookies is that they're automatically sent by the user agent, anything else that was stored (such as in LocalStorage) could only be used by JS scripts.
EDIT: What I originally wrote is somewhat off. It was directly in PHP: https://www.php.net/manual/en/session.idpassing.php
I don't know if I'm remembering right, but I seem to remember some early PHP framework or templating system, $_SESSION variables could be configured to use query parameters instead of cookies. So every link generated by the framework automatically inserted a "?SESSIONID=12345" at the end of the link. The backend translated this into the PHP $_SESSION object.
Re: Statement on 4 Years of GDPR
#154Earlier quoted context omitted.
One option would be to collect less data on users, which should make it easier to manage.
Easy peasy unless your system was built before it became illegal to "haphazardly" process PII. Even organization that take GDPR very seriously and invest a lot on compliance do not generally really know all the places where their legacy systems are storing PII. The law is draconian.
- GDPR-like legislation existed in most EU countries waaaaaay before GDPR.
- It was known for years that GDPR is coming.
- GDPR specifically gave companies two years after going in effect to get their act in order.
- We are now 4 years after GDPR went in effect.
If you're still complaining that it's "a drakonian law that doesn't let your company do haphazard PII processing aka collecting PII wholesale with no consent", then you company deserves to be sued and fined out of existence.
Re: Statement on 4 Years of GDPR
#155Earlier quoted context omitted.
Amazon Europe Core S.à.r.l. Industry and Commerce LUXEMBOURG 746,000,000 euro Non-compliance with general data processing principles 16 Jul 2021 WhatsApp Ireland Ltd. Media, Telecoms and Broadcasting IRELAND 225,000,000 euro Insufficient fulfilment of information obligations 02 Sep 2021 https://www.enforcementtracker.com/?insights
Are those fines given or fines collected? I remember reading that fines collected are really tiny portion of those given.
Re: Statement on 4 Years of GDPR
#156Earlier quoted context omitted.
Is there any way of maintaining session IDs across requests without JavaScript other than cookies? My understanding is, the whole point of cookies is that they're automatically sent by the user agent, anything else that was stored (such as in LocalStorage) could only be used by JS scripts.
If your whole website doesn't use JavaScript and every request reloads the page, that reloaded page can contain current session id, right? Why do we need to rely on automation which does this thing, with known drawbacks, but can't do that ourselves?
Right, through cookies - unless you want to embed the session ID in every single link or button in the whole page. The way pages "contain" session data like that _is_ cookies! snapetom mentions embedding in query parameters, which while a possible solution, seems even worse to me, as it means sharing a link to the current page you're on leaks your session token. I'm really not sure I'm following what you're saying here.
Re: Statement on 4 Years of GDPR
#157Earlier quoted context omitted.
Lots of people on HN work for advertising companies such as Google, Facebook etc, tech savvy or not has little to do with it.
I don't work for an adtech company and I think GDPR has made the web demonstrably worse for everyone. I'd rather void EU clients altogether than put up a cookie banner/popup.
2. It's not GDPR that made it worse but ad-tech and similar leeches who want to continue vacuuming up all available data without reprecussions
Re: Statement on 4 Years of GDPR
#158Earlier quoted context omitted.
Yes, GDPR is very clear until it's not. Tell me for example how would you respect the right to be forgotten for web server access logs? The information "IP x.y.z requested /index.html at dd/mm/yyyy" is PII under GDPR. Meaning you have to a) declare that you are collecting it, b) be able to produce all data for the person using IP x.y.z upon request, and c) be able to delete all log rows relating to x.y.z when they as…
Tell me for example how would you respect the right to be forgotten for web server access logs? The information "IP x.y.z requested /index.html at dd/mm/yyyy" is PII under GDPR. Meaning you have to a) declare that you are collecting it, b) be able to produce all data for the person using IP x.y.z upon request, and c) be able to delete all log rows relating to x.y.z when they ask you to. Unless you have built your sys…
This is an inversion of the rule for legitimate interest processing, where the processing is legal unless there is an overriding interests, rights, and freedoms by the data subject. Basically, in the middle ground where neither set of rights and interests clearly override the other, the controller can legally process, but can also be forced to delete via the objection mechanism.
The fact that there is little clear guidance as to in what circumstances one set of interests, rights, or freedoms should override legitimate interests or vice versa, it does make this area of the law basically come down to somewhat arbitrary decisions of the relevant DPAs.
Recital 47 seems to suggest that for the normal direction of overriding interests, most situations where the average person would not be surprised/annoyed if informed about this processing in the specific circumstances is likely to be be permissible. But with Art 21(1)'s reversed burden, the guidance is simply "It should be for the controller to demonstrate that its compelling legitimate interest overrides the interests or the fundamental rights and freedoms of the data subject." No guidance at all about how much or low little this differs from the what is permissible via Art 6(1)(f). Clearly some difference is intended since the wording is clearly reversed from Art 6(1)(f).
It leaves legitimate interests processing (which is by far the one of the most common processing reasons, and probably is common than all the other lawful reasons combined) as basically a giant minefield until the DPAs have established enough "case law" (for lack of a better term) to make sufficiently clear how they balance these competing interests and rights and freedoms.
Re: Statement on 4 Years of GDPR
#159I shouldn’t have to tell people I don’t want to be spied, nor I should have to install privacy extensions and PiHoles and whatever.
Re: Statement on 4 Years of GDPR
#160There are signs that it's getting better. I started seeing cookie dialogs with a Reject all button. Sometimes it's a big one, sometimes it's almost white on white, but it's there. Anyway the vast majority of those dialogs is still misleading. The usual We care about your privacy, accept all, settings thing.
Even YouTube now has a REJECT ALL button. Which is quite nice for folks like me, who always clear browsing data upon exit.
I have noticed that despite having all the settings to wipe data, not just cookies, cookies are still left.
These are my start page tabs in this order.
edge://settings/clearBrowserData tab all I have to do is click "Choose What to Clear", get the popup window, Time Range - All Time, all options ticked. Once completed but this can hang the browser for upto several minutes once done I switch to the second tab.
edge://settings/siteData tab hit refresh (F5) to see what cookies get left behind and thats when I see sometimes, cookies get left behind, usually youtube.com cookies, they will be blank but loads of youtube cookies.
edge://favorites/ tab, positioned to Favourites bar and have nothing on there because the browser pulls down site icons so you can identify people (browser fingerprinting) from the icon combination that gets pulled down.
edge://application-guard-internals/#status tab can see if its working properly, noticed when its on, youtube video's dont work its always trying to get get data, the stats for nerds show nothing comes downs or minimal 1kb amounts.
edge://policy/ tab because I like to switch these around to create a different fingerprint from the devices that are accessible.