While this article is interesting, I strongly encourage anyone - from CEOs, to managers, to individual developers - to actually read the text of the GDPR.
This is not written in unintelligible legal-ese. It is very approachable, understandable by a layman, and organized such that relevant Articles are easy to find.
It might take an hour or two, yet may have a fundamental impact on how you approach your job for the foreseeable future. Time very well spent.
EDIT: for clarity, that site is accessible from an organizational point of view (i.e., broken out by articles, not one long string of text). I do not know if it is accessible by screen readers or alternate input devices.
If you work for a big company and are not a lawyer, you should listen to your lawyers and not try to interpret the law yourself. There are pitfalls and misunderstanding you will run into otherwise. If your company is large enough, they should meet with privacy regulators and work with them to show them implementation decisions and make sure the regulators are in alignment with the approach taken.
[1]: https://en.wikipedia.org/wiki/Article_29_Data_Protection_Wor... WP29 is "an advisory body made up of a representative from the data protection authority of each EU Member State, the European Data Protection Supervisor and the European Commission."
What's troubling to me is that it's very unclear what specifically is required. I know the linked post isn't legal advice, but in the page about 'privacy by design' linked to by the origin link, they list "Minimize the amount of collected data" as as an item (supposedly to be achieved to be in compliance with the law).
What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!
Can any site just 'do an end run around' the law by requiring their users to agree to allow them to collect whatever data they collect now or that they've already collected? If so, that seems like it'd be likely as helpful as current terms of service.
Another item mentioned is "Where possible, pseudonymize personal data.". What's a practical example of that?
Yet another item – "Don’t enable social media sharing by default.". Is the thinking that user's shouldn't be able to share something via social media without first explicitly enabling that option? That just seem unfriendly. Or is the idea that doing so protects someone from doing so accidentally? This seems a lot like the 'cookie law', itself an annoying mandated nagging that probably backfired (because everyone was effectively trained to just do whatever necessary to get rid of the corresponding notification on every site they visited).
Again from the privacy-by-design page:
> There is no checklist of ready-made questions that will get you there; General Data Protection Regulation requires developers to come up with the questions as well as the answers.
> ...they list "Minimize the amount of collected data" as as an item (supposedly to be achieved to be in compliance with the law).
> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!
The GDPR says when you collect data, you have to tell the user what you intend to use it for. "Minimization" applies within the context of those stated uses. So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.
As a corollary, if you can't link a piece of data to a business use, you shouldn't be collecting it. This was a good idea before, but GDPR makes it more relevant.
Note that this is similar to the ethical guidelines for medical research. "Harm Minimization" is a central pillar of ethical research. Harm, and risk of harm, is acceptable, but there is an affirmative duty to seek the least-harmful means of achieving your goal from those available.
> That's a really unsettling description of a law.
That's how HIPAA works, actually. I have a professor who argues this model of legislation is more effective than traditional sector-specific regulation, because it puts the onus of subject-matter expertise onto the people who are actually subject-matter experts, and because it allows for creative and adaptive solutions.
> So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.
I would also like to stress out that, from my understanding, this data would rather be deleted immediately after use. That is, not saved at all after the query, or the delivery, unless the user explicitly opted-in to give you such data for advertising, etc...
The GDPR, as with existing EU data protection law requires technical & organisational measures in place to protect data. The GDPR specifically calls out (Article 32 if you're interested) encryption as one measure that entities should consider in determining whether their technical & organisational measures are fit for purpose.
Generally speaking, encryption is an obvious choice when it comes to measures designed to protect user data.
Of course—if you don't store personal data (trivially).
In fact, encryption (security) is mostly orthogonal to how you track and handle personal and sensitive data (privacy protection). You could encrypt everything and still be wildly GDPR non-compliant, if the encrypted information you're storing lacks clear purpose and explicit consent.
A) leaves no room for misunderstanding with different regulators or their respective auditors, and
B) provides a computationally infeasible barrier against accidental personal information disclosure even if the storage system was improperly decommissioned
Point B in particular can be explained to auditors without problems. They understand both the intent and the technical measures put in place. But how we store data is only tangentially relevant to how we handle data. Let alone what we need to collect in the first place.
(The KYC/AML/SOW requirements in gambling are quite demanding; they impose significant data collection and retention needs.)
To further emphasize your point You could encrypt everything and still be wildly GDPR non-compliant, we need to be able to respond to a request by each and every individual user to delete the information that they no longer wish us to carry.
> The GDPR says when you collect data, you have to tell the user what you intend to use it for.
Then that part is worthless, just another click-through "agreement" practically nobody reads.
That part won't change anything.
> So if your business purpose is to mail something to the customer, full physical address is OK to collect. If your business purpose is to help them find a nearby store location, you may be expected to collect something less granular like ZIP code or metro area, depending on how many locations you have.
I always wonder one thing: Is the penalty going to be high enough to justify not breaking this law?
All business decisions are cost-benefit. If the costs of doing something outweigh the benefit, you don't do that. This includes following the law: If you can reliably get more money by breaking the law, you break the law, and pay the penalty if you get caught. Unless you're very unlucky, you're still right-side-up after you pay the penalty, so your behavior was, on the whole, justified.
GDPR requires that the use cases be itemized, and the user can opt out of each one individually. So if the user opts out of receiving a mailing but not the store locator, you have to manage how much data you collect about that person. I agree that for the most part this will just be another click-through like the cookie law was, but companies will be required to accommodate those minority that do care.
> Is the penalty going to be high enough to justify not breaking this law?
The penalty is up to 4% of annual global revenue. Global revenue.
Let me get it straight: if your global revenue is €10 million, you won't pay 4%(€400k) penalty, you'll pay €20 million, because it's greater of the two? It seems like this will be especially harmful to small companies.
Up to $20 million, depending on the severity of the infringement. I think the reason that floor is there is to handle cases where an organization doesn’t have much revenue, either through accounting shenanigans or because it is a non-profit (made up example: a free PDF to text converter that claims to be stateless but mines passwords and information to blackmail people with)
Not every little thing needs to be opted into individually. If you have a legitimate use of data for the user’s benefit, you can collect that data after a general consent as long as you provide a way for the user to see that data and delete it. If you use that data for your own benefits (like building an advertising profile), that needs to be opted into separately.
The fines are up to €20 million, or 4% annual global turnover – whichever is higher.
Of course, paying the fine doesn't mean that you can continue with the action - it'd also likely involve imposing a temporary or permanent ban on data processing and ordering the rectification, restriction or erasure of data gathered unlawfully.
> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!
Elizabeth Denham, UK's information commissioner in charge of data protection enforcement, had this to say:
"Having larger fines is useful but I think fundamentally what I'm saying is it's scaremongering to suggest that we're going to be making early examples of organisations that breach the law or that fining a top whack is going to become the norm. Our office will be more lenient on companies that have shown awareness of the GDPR and tried to implement it, when compared to those that haven't made any effort."
In other words, the compliance decision is not in your hands, but there's a promise of certain lenience. At least to start with.
A practical trouble is that once a company reaches a certain size, they no longer even know what data they have, never mind why. Do we already store personal data? Where? Is it important data such as "names + credit cards", or some god-forgotten IP addresses in a log? Email archives and attachments? How about GoogleDrive and SharePoint? Then, do we redact it, or delete it? How? How do we answer Subject Access Requests?
We've built a product to help companies take care of the most common "private data" cases (https://gdpr-tools.eu), but we're not fooling ourselves that we've solved "personal data". Or that the task is even solvable. That whole space is very much in turmoil and how hard the GDPR whip will get cracked remains to be seen.
Funnily, one of the common fears that clients have is not about the general public. It comes from disgruntled employees ratting on the company. Employees know best where personal data is stored (and often no one else in the company does), so they can really do some surgical damage by reporting their employer to the "authorities".
Indeed, and not only yours. The same issue crops up in B2B due diligence and risk management, irrespective of GDPR.
The automated inventory analysis tools, like ours and others, are only just becoming useful thanks to ML. The previous generation was mostly regex-based and mired by constant false alarms.
Except that's precisely 1/28 of the regulators to which you are subject if you are an American company and, therefore, most likely don't have a lead regulator.
> As one dramatic example, PayPal’s recent updated notice lists over 600 third-party service providers. The fact that PayPal shares data with up to 600 third parties is not news. That information is simply being brought into the open.
From what I can see of the list of those "600 third parties", a large number are banks and other financial institutions.
This is one of the things that's bothered me with it - in a similar vein to VATMOSS, GDPR will probably have more of a burden on smaller businesses, whereas larger business will have the development/consultant resource to get it right, and have those larger law firms to provide that "extra context" to brush things under the carpet if something goes awry.
The ICO seems reasonable, so hopefully they won't crush a small software shop for fucking up on something, but they're going to want to go after some people to send a message at some point. I'd guess you'd want to check that professional indemnity insurance policy, just in case.
It is, of course, all down to context. You need to show that you at least took the guidance seriously and tried to mitigate things. A notice of "collect ALL THE THINGS" won't fly, as you're basically admitting you're not prepared to consider it.
I think you're right on the social media sharing thing, it should be fairly well handled by the OAuth notices from most networks (I'd have guessed - "allow this app to post on my behalf" counts as consent?), but yeah, can't be taken as a given. IANAL, of course.
> This is one of the things that's bothered me with it - in a similar vein to VATMOSS, GDPR will probably have more of a burden on smaller businesses
In a weird way, VATMOSS and GDPR kind of work together on this...most things we collect at work that will be covered by GDPR are collected because of VATMOSS.
VATMOSS requires that we be able to justify what country's VAT we collect on a given online purchase with two pieces of "non-contradictory" evidence. So, right there we have to collect at least two things that provide location data about the customer, and GDPR expands the definition of personal data to include location data. I say "at least" because since it is required to have two non-contradictory pieces of evidence, it's prudent to collect at least three.
I think we currently use: (1) country the person selected from the "Country" drop-down on our site, (2) GeoIP at time of purchase, (3) GeoIP at time of filling out quarterly VATMOSS report, (4) GeoIP on IP addresses that they have used when downloading updates, (5) Country of bank that issued the credit card or debit card used for the purchase.
> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!
> Can any site just 'do an end run around' the law by requiring their users to agree to allow them to collect whatever data they collect now or that they've already collected? If so, that seems like it'd be likely as helpful as current terms of service.
Under the GDPR you're not allowed to store personal data.
However, if you have purpose, and need data to fulfil that purpose, you can.
You can also ask for data, in clear terms, and if an informed user, freely choose to share, you might store that.
So, you sell shoes and magazines online. You need an address to ship both. You need a shoe size to ship the right shoes. You can demand to know the shoe size before you ship shoes - but not before you ship a magazine.
You can store order information (indeed have to, due to financial regulation). So you have a record of shipped shoe size and customer data.
You may not, without consent, store a permanent profile with shoe size and magazine preference. But it's OK to let users opt in to a profile.
> Another item mentioned is "Where possible, pseudonymize personal data.". What's a practical example of that?
Good question. Off the top of my head I can't think of useful pseudonymyzation related to the GDPR.
Perhaps things like hashing IP addresses for traffic stats, or using opaque identifiers for storing session interactions rather than linking directly to IP or real names. Useful pseudonymyzation is hard.
In e-commerce, order data and item level data can be exported to reported engines to gather info but you can pseudorandom the names to prevent data leakage
> What do you do about users who have used plaintext or silly passwords?
I don't even know what to write about that. The whole tone of the page is lecturing – about "fundamental human rights"! – and yet it's suggested that developers handle "plaintext or silly passwords"!
> What's the minimum amount of data? Who decides that? Is it dependent on context? I'd hope so!
You decide, based on context and consent. I think consent now needs to be non-blanket.
> That's a really unsettling description of a law
I know it's not ideal, but it's far from the only vague area. The law of negligence is very important to anyone running a business and is almost entirely caselaw, for example.
It's also a lot like CE certification, which takes a while to get your head around but is similarly based around both standards and self-certification.
You must provide the user with a detailed description of what personal data of theirs you are collecting, who you are sharing it with and what your business purpose for collecting it is, and if the data is something that you need their consent to collect, you get their explicit consent to collect that data and you must let them opt-out of providing that consent without preventing them from doing business with you.
> Can any site just 'do an end run around' the law by requiring their users to agree to allow them to collect whatever data they collect now or that they've already collected?
No: a consent from a user must be for granular information with a specific listed purpose.
You’re thinking about it in terms of pieces of information, but GDPR thinks about it more in terms of the uses of that information. You wouldn’t expect to ask a user “Can we store your email address?“. The granular action for storing the email address is “Can we email you from time to time product offers?”. Once the user consents then that email address (and potentially full name, etc etc) can only be used for that consented action.
The problem I have is that a site could tie acceptance with allowance.
e.g., I run a free, ads and promotion funded site, but I actually supplement revenue by selling the user's actions on the site to a third party. users can also have accumulated virtual currency as rewards, which can be used for premium sections of the site.
then along comes GDPR, and I tie acceptance of some virtual currency rewards with acceptance of the GDPR consent, with the threat of site access being cut off if they don't consent.
is that still legal?
No, that's not presumed to be freely given consent.
https://gdpr-info.eu/recitals/no-43/ "Consent is presumed not to be freely given if ... the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance."
If the data is actually needed to execute the contract (i.e. a delivery address if you're mailing stuff to the user), then you don't need separate consent; but if it's not (e.g. just revenue) then any "confirmation clicks" that are tied to site access being cut off would be just that - simply clicks that don't count as freely given consent.
Also, if you consider giving a reward for acceptance of GDPR consent, then you must also consider that consent can be revoked at any time (including 5 seconds afterward) and it must be literally as easy to withdraw consent as it is to give it.
> Yet another item – "Don’t enable social media sharing by default.". Is the thinking that user's shouldn't be able to share something via social media without first explicitly enabling that option? That just seem unfriendly. Or is the idea that doing so protects someone from doing so accidentally? This seems a lot like the 'cookie law', itself an annoying mandated nagging that probably backfired (because everyone was effectively trained to just do whatever necessary to get rid of the corresponding notification on every site they visited).
Most social media sharing buttons are in fact scripts hosted outside the website currently visited. So even without using them a lot of data is send to Facebook, G+ and other social medias. If you want to see a good implementation of the idea, check Schneier's website: https://www.schneier.com/
If you want a practical example of psuedonymisation then consider a case where you have two internal systems that serve different purposes (say one is used as a CRM, the other is used for business reporting).
The CRM database is copied over to a separate database that the reporting system feeds from. Now in reality the reporting system (which will generally give you aggregated trend reporting) doesn't need a full copy of all production data as it only needs to utilise a limited subset of the overall data.
So instead of the full copy of the CRM database being copied over to the reporting database, you filter the data so you only copy over an anonymised dataset. That is pseudonymisation in a nutshell. Because you still retain the separate dataset in your system, the data is not truly anonymised, so is said to be pseudonymised. Overall I see it as linked to the requirement for data minimisation. Any particular system should only have access to the data it needs to perform its role.
>GDPR will require developers to know the legal and policy landscape of their profession. (This has been the norm for other fields for centuries: how embarrassing for us.)
The comparison is disingenuous. The internet makes anything you build automatically global. You're blasting software engineers for not knowing worldwide regulations. How many New York lawyers know the regulations of France? How many local UK construction companies know the building codes of Japan? None.
Knowing all regulations in the world for any given industry would be a full time job. The people you seem to be implying exist do not exist.
> How many New York lawyers know the regulations of France?
New York lawyers who do business in France do.
If you're accepting ~dollars~ euros to place French ads on your pages targeting French customers, seems reasonable to know the relevant French regulations.
It's a bit more strict than that. If I have customers in France, this affects me, no matter how many, no matter if it's one dude in Florida who happens to also be French. The reach is absurd.
Yes, that's incorrect, unless you are an EU business yourself. If not, you are only subject if your customers are in the EU. And more, "the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established" is not enough to show that you're targeting customers in the EU.
So, the GDPR is doing you a favour by forcing you to think in advance "who will my users be?". So far web applications were "accidentally" global, now you have to be more careful and deliberate. Which is a good thing.
Ah yes, digital isolationism and segregated networks are great. Have we given up on the idea of the internet being a force for global human interaction? Are vague and impotent privacy protections more important?
I live in EU.
-> Are vague and impotent privacy protections more important ?
More important than "global human interaction" ? Yes, in my opinion. "Global human interaction" doesn't mean it should be the Far-West gold rush. It aims at fair and equal human interactions with the respect for the freedom of each single human on Earth. Freedom means equality for all, and to ensure more equality, we created laws. Laws are not perfect, but sometime they are the only tool we have. Laws are not fixed in stone, they can be improved over-time. Essentially we want global human interaction with respect of individuals.
I assume GDPR would only impact you if you operate a business from European locations, right? Not like they can enforce their laws on my small business run from the other side of the planet.
So long as my country isn't willing to extradite me, I don't really care what their laws are and I will adamantly refuse to comply with them as they're entirely irrelevant to me.
Your reasoning sounds like an easy excuse to not bother looking at any regulations period. Because knowing every single regulation is too onerous and you probably know all your local ones intuitively, right?
Don't slurp up data worldwide, then. If you don't do that, you're fine. If you do business you'd better know the law of your target audience, isn't it?
You don’t see the humor (at least) of a privacy regulation requiring me to learn more about the consumers hitting the site? Previously they were so private I knew nothing but an IP.
Now I’m instrumenting my systems with geo lookup databases which usually also include much more fine grained data (such as home/business) than that.
In any case, your original point was to just not interact with those people, which requires active filtering and isn’t the same thing as saying ‘just don’t watch that tv show’ in that it demands actions on my part due to behaviors and preferences on someone else’s.
There is no active filtering required if you don't store anything. I don't understand why this is so hard to grasp.
You can learn as much as you want as long as you don't store it or provide that information to a third party.
I believe our industry has too long gotten away with a "store everything" mentality. I have zero sympathy for web sites which slurp up everything from their visitors.
A lot of what you might call 'avoiding recklessness' is demonstrably bad for some people so it's not clear that the current tradeoffs are optimal. And it's not at all obvious that, overall, regulation does much more than protect incumbents in a given field or industry at the expense of everyone else.
Based on my own experience, I've 'known' about regulations that governed the industries with which I've worked. I'm not sure what evidence specifically you or the author have that leads you to believe software developers should be embarrassed.
> A lot of what you might call 'avoiding recklessness' is demonstrably bad for some people
And? Making sure that the bridge will hold under the weight that its required to is demonstrably bad for my profits (if I were the construction company). That doesn't mean that we should loosen the regulations or whatever. We don't owe anyone the right to profits, regulations are meant to protect us and keep the playing field fair. Of course that will always negatively affect someone.
It isn't obvious that is a case. Some companies make bad short-term decisions. But many take a longer-term view. Who would hire the construction company again that made the bad bridge? Or consider food and drug regulation. Countries with more lax requirements for proof of drug efficacy and large-scale trails don't have worse health outcomes. In fact, the countries with stricter policy regimes are often slower to have receive life-saving drugs. Does the suppression of a drug with adverse effects that only shows up in a wider population or after more prolonged exposure have a stronger benefit than that the suppression of drugs without such downsides? Often countries optimize in the wrong direction here. Many licensing laws fall in this category too. Do barbers and hair stylists need a license? Probably not to ensure safety and we have plenty of comparable jurisdictions with and without such rules to prove it. People don't just start doing bad things in the absence of rules.
Construction companies circumvent this by going bankrupt all the time and setting up the next shell company. Big projects will often be done by a pool of companies. Which would you hold accountable then.
As well, some things are so bad that you don't want to punish after the fact.
> Construction companies circumvent this by going bankrupt all the time and setting up the next shell company.
This would be a much more difficult thing for them to do if it was easy to track the history of bad behavior of the relevant people. This seems like something that should be relatively easy to do nowadays, module some probably not-too-significant obstacles like the 'right to be forgotten'.
> Big projects will often be done by a pool of companies. Which would you hold accountable then.
In the absence of detailed information, one would reasonably hold them all partially accountable.
> As well, some things are so bad that you don't want to punish after the fact.
There's no perfect way to do this. Murder seems like it's "so bad that you don't want to punish after the fact" but I don't think either of us would want to live in a society that was perfectly capable of preventing any murders.
If we want to accept that privacy is important and valuable then we need to accept that it is not okay for our industry to continue to do what it has been doing.
I challenge you to give me an example of some "demonstrably bad" effect caused by "avoiding recklessness" that isn't the direct result of shirking responsibility.
To go along with your devil's advocate argument: I could argue that "taking extra measures to ensure the security of sensitive data" would have been "demonstrably bad" for Equifax. But don't you agree that it was extremely irresponsible of them to not do that?
> No. Professionals in engineering or the trades have to know the regulations that govern their industry and abide by them.
Eh, not substantially or consistently more than in software. It's possible to cherry-pick examples where engineers in other fields are more aware of relevant regulations, but overall, it's roughly comparable.
I'm generally very critical of the move-fast-and-break-things mentality, but engineers in other fields are generally not more knowledgeable about industry regulations than software engineers are.
American engineer building a bridge or tunnel in EU is certainly going to know EU regulations. An EE designing circuits for EU needs to know about lead-free solder requirements. On the other side, Mies van der Rohe needed to work with a US-certified architect to build the Seagrams.
Having been in the software industry for a while, it is often discouraging to see how both explicitly and often inadvertently move-fast-and-break-things has resulted in some pretty bad software industry wide.
Just look at the sense of most of the comments here--there seems to be a consensus of how to get around this, or how it doesn't apply to me.
Right, but the point is that you KNOW the country your bridge or tunnel is going to be used in, because you build it there. If I build a web app and deploy it on a server in California, it can immediately be used by people in almost any country in the world.
Is it my responsibility to follow the censorship rules from China on my webapp in California? Is it my responsibility to know all the regulations on web apps from Sri Lanka?
Building software with care and professionalism is unrelated to understanding all the rules in place all around the world.
That "recital" is still pretty vague; the relevant text:
> Whereas the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.
Note that "the use of a language or a currency generally used in one or more Member States ... may make it apparent that the controller envisages offering goods or services to data subjects in the Union". So simply using a language in use in a EU member country may be sufficient that you "envisage" offering your goods or services. That seems significantly different than your claim that one need merely not "specifically target those countries".
Yes, but these things are assessed by judged, not by dice-throwing. I'm sure we can devise contrived examples that fall into gray area, but for the most part I think what I wrote is correct.
EEs everywhere know about ROHS simply because it makes no sense to have seperate designs for Europe and everywhere else. Also lead free solder really isn't that bad...
> I'm pretty sure other fields rely on lawyers to know the relevant legal landscape just like we do.
I have plenty of friends and relatives who work in construction or architecture and knowing the building codes and everything related to it is something you learn at university, update every year and is something every person involved in planning and constructing a building is aware of. Lawyers only get involved if a building fails.
Construction workers and architects don't tend to work internationally. If they do, they hire lawyers to sort out legal requirements for them before they even sign a contract.
The same should be true for most software companies going forward. The approach to just assume it's the obligation of the user to ensure compliance won't work for much longer.
Imagine the EU made a law requiring every country in the world follow their building codes whenever an EU citizen enters one of their buildings, even if the building was made before the law was created. And if you don't comply, they will fine you millions of dollars.
McDonalds goes and retrofits all of their buildings in the world because they have shops in the EU at great cost. Some pizza shop that does delivery in the USA, and the owners go on vacation once in a while in Europe? ️They probably are not even aware of it.
> Imagine the EU made a law requiring every country in the world follow their building codes whenever an EU citizen enters one of their buildings
You are reaching. I give you a better example: it does not matter where a building part is being produced, if it ends up in a building in Europe it needs to be up to the local building codes and to the regulations of the single market.
You think I am reaching, but the GDPR does act this way.
Lets say your visiting the USA as an EU citizen and you get a pizza delivery from a local small pizza shop. They put your name and delivery address in their computer in an MS Access database that makes stickers, emails the delivery guy's gmail account and a person delivers a pizza to you.
They have no idea your an EU citizen and they just put enough information into their computer that would violate the GDPR. They have no real way to comply unless they retrofit their computer system to some vendor that is GDPR compliant, if it even exists. Just deleting your info from the msaccess db and asking the delivery guy to delete their emails isn't enough for the GDPR. And a computer system retrofit for most business might as well be like asking them to retrofit their building as far as costs go.
The end effect might be just outright banning all EU citizens from doing business with various places, because it's just not worth the hassle.
'Sorry you cant stay at our hotel, we are not GDPR compliant'
'Sorry we won't deliver to you, we are not GDPR compliant'
'Sorry you can't enroll in our classes, we are not GDPR compliant'
'Sorry we won't treat you at this hospital, we are not GDPR compliant'
'Sorry you can't get a bank account with us, we are not GDPR compliant' (Like a lot of EU banks with US citizens with FATCA)
You clearly don't know what you are talking about.
Article 3 clearly states that it applies to
> the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or
> the monitoring of their behaviour as far as their behaviour takes place within the Union.
It does not apply EU citizens while traveling outside of the EU. It applies when you are monitoring or offering goods or services to someone in the EU.
> Lets say your visiting the USA as an EU citizen and you get a pizza delivery from a local small pizza shop
If that pizza store has no relation to the EU then there is no legal ground by which the GDPR could become relevant. There is no treaty which would establish some sory of leverage here.
//EDIT: which btw is unlike FATCA for which there actually are bilateral agreements.
You don't need a treaty to enforce the law, you just need a pizza shop owner who likes to vacation in europe sometimes. You carry out the default judgement if they ever arrive in the EU. The GDPR explicitly has a very global scope because it is targeting companies in and out of the EU.
I wouldn't really have much of a problem with the GDPR if it had some small business and non-eu business exceptions. It doesn't and regulators saying 'trust us we wont prosecute the easy to prosecute!' makes most businesses uneasy.
It doesn't and regulators saying 'trust us we wont prosecute the easy to prosecute!' makes most businesses uneasy.
Indeed.
Let's not forget that the EU and national governments have form when it comes to this sort of thing. The new EU VAT rules on digital sales a few years back were similarly overweight, and they really did result in a lot of microbusinesses either literally shutting down or just plain breaking the law.
A lot of slightly larger ones, my own included, went to considerable lengths to update systems to comply, but with hindsight would have simply declined custom from any (other) EU nation instead because the overheads were and continue to be excessive.
Those same rules really did also result in national tax authorities abusing their new-found powers to go after businesses in other countries within the EU, sometimes through their own incompetence rather than any legitimate grievance, resulting in some very scary threats being received by other small businesses.
It's tough to give much credit to arguments about regulators exhibiting common sense and moderation when the evidence of previous sweeping EU rule changes suggests we shouldn't count on that.
The law itself does not even put itself into scope. You either need a treaty (Article 3, paragraph 3) or the data subject or processing is in the union.
How is that different from say Dimitry Sklyarov, a Russian who broke a US law while living in Russia, who later goes to the US for a convention and gets arrested and thrown in jail?
That's how it should be. Sadly the EU is taking a very different approach of trying to set laws for the whole world based on very unclear (and definitely unprecedented) requirements. It's true that they will have no jurisdiction over the pizza guy - just until he comes to the EU or to an allied country. Another comment talks about how it's very likely that GDPR will be a requirement of trade deals.
Even then not. The territorial scope in Article 3 of the GDPR is not that far reaching. It applies to processors with establishment in the EU, non union data processors who perform a service to data subjects in the union or the case of the pizza guy:
> 3. This Regulation applies to the processing of personal data by a controller not established in the Union, but in a place where Member State law applies by virtue of public international law.
So unless there is a treaty that puts GDPR into scope, the pizza guy is fine.
Unlikely. Lawyers are an invisible hand, always present.
They’re the ones who prepare the trainings for your relatives and the other architectural students, or at the minimum the changes that a policy-wonk will react to when creating curriculum.
The site operator has the limited range to act (we’ll call them decision rights) under the CEO who is ultimately guided by his counsel (firm or in-house).
Lawyers also oversee zoning, permitting, and certifying every step of the way - not limited to, but including licensing and contracting.
Sure, and it is one of the main reasons those professions require licensure. It seems to me that most people in the industry would like to avoid that for software development. Speaking purely for myself, I would welcome it. But it would be a large and disruptive change that we may not be ready for.
Developers should already know the "legal and policy landscape."
Sending email? You should know the CAN-SPAM act. Do business with CA citizens? You'd better know about CA's privacy policy requirements. Doing ecommerce? You need to learn about sales tax and PCI requirements.
Suppose you were a small startup based in America, accepting online payments from users/advertisers using American platforms or financial institutions. Suppose you make no effort to comply with GPDR - what realistic consequences can you face?
I suspect that this is the kind of thing which larger/established companies would worry about. If you're a seed/series-A startup, it seems like you have far more important things to focus on, because there's nothing that the EU can realistically do to you anyway.
So having been through the preliminaries of GDPR, I took away a few things.
First of all, the enforcement path is as yet unclear. If they (europe) see you are doing something (like not responding to "right to be forgotten" request) it is not clear what enforcement they will attempt.
Second, there is the customer perception. If you have one European customer that buys something from you, or enters their email for you to give them some product information, and they request later to be forgotten and you don't, there is then a chance of public perception that you don't comply.
But there can be other avenues of exposure. For example, if you are dealing with a US bank that does comply with GDPR and you don't, there may be some pushback from the bank. So while EU may not come for you directly, there could be a secondary effect.
From a little conversation with European partners, I got the sense that US was taking GDPR more seriously than some EU companies.
You attest so legally binding. The legal system does not function on mathematical proofs. If it turns out you did not speak the truth, you can be fined, and maybe even jailed. That's how it works.
Also, we are not talking about forgetting someone personally, but deleting their data. I assume that's clear.
Considering this is not about human memory but about computers and data storage, and those things are traditionally pretty bad at lying, it seems like a bad path to take, personally.
Depending on your industry, or your global customer requirements, you might have to have an audit that shows that you have such procedures in place. If you are small, don't get breached, and attest that you have done the deletion.
The realistic consequences would probably be the following:
1) When you grow sufficiently large to go global, it will suddenly start to matter a lot, as EU is one of the largest markets worldwide. In the best case scenario you'd have to change your processes and systems to comply (i.e. you'd have technical debt which you could've avoided if you did it properly in the first place); in the worst case you'd have some complaints from EU users resulting in fines that aren't enforced yet but would be as soon as you'd want to actually get money from EU. This would be a meaningful impact to your valuation at that point.
2) As the risks implied in the first part have an impact on your valuation if you succeed and go global (which is the only scenario that matters to investors, the exit valuation about which they're thinking), you'd expect this compliance to be included in the due diligence done by series B/C investors and any acquisitions; if you've made no effort to comply, this will result in a lower valuation in those rounds of funding.
If you're a high-growth startup whose valuation is not based on current revenue but on the (long) future market size and you declare that you're choosing to be incompatible with, say, 25% of the global market (to a very rough approximation, EU revenue share is something like that for many major tech companies), then investors will discount your future value (and thus current value) by 25%. So at the very least this is something that you should have on your roadmap for investors i.e. "we're planning to do that diligence and related work in quarter X after we've done A, B and C" instead of simply ignoring the issue.
It's hard to say at this point, or even after. It's on a nexus of vague things. First "internet laws" have a history of leading to nothing much, like the EU "cookie law" which everyone "complies" with by popping up a nag. Second because online jurisdictions and how these get enforced is ambiguous. Third, because the enforcement path is still pretty unclear. It may be all about a handful of high priority cases, with small sites getting a pass.
Ultimately, there are all sorts of laws all over the world. With an online, potentially global business, you're breaking some of them. Turkey does not really expect some international user generated content site to comply with their political content laws. A bigger site based in Istanbul... You'll get a knock on the door.
About ten years ago, I had a client with an e-commerce site, for workplace safety gear in Australia. They sold to the US, but rarely. During bird flue, they somehow got on the radar of some US advertising standard. There were some politicians actively policing it anyway they could (not courts).
Tldr is that they had their payment gateway and PayPal shut them down immediately (someone got scary phone calls). Even shutting off all US shipping, and adding a big red "No US" sign didn't help. They had to drop the products. So.. jurisdiction is often erratic.
I think the last (possibly most important) point is cultural. If it takes, GDPR may impact consumer expectations and you may need to do it for that reason.
If you want to avoid GDPR, just hold back for 3-6 months until after the date. It'll get clearer as it progresses and if you're as outside the purview as you suggest, you're probably going to be fine ignoring it at the start (or forever).
If you're consumer focused, you're probably fine and will just need to clean up some mess later when you get big enough to care.
If you're B2B, it's going to be a problem from day one. GDPR has a defacto viral component for service providers. Basically, any the business that wants to become your customer that is itself GDPR compliant needs to ensure that you too are GDPR compliant. Accordingly, GDPR will come up with a large portion of web-facing B2B sales, even for US companies.
The collective economic effect of that will be massive. Please do. And realize that you are ceding the single largest market to your competition.
That doesn't necessarily follow.
For example, EU but non-UK customers represent only a small fraction of the user base for one of my businesses. With hindsight, we would have done better to exclude those customers entirely, avoid spending time and money complying with ever-more-onerous EU rules, and invest that time and money in growing our business in more lucrative markets instead.
It is entirely possible for the EU to make itself so unattractive as a market that this will be the case for others too. Indeed several of the near-future measures it is already working on may have exactly that effect. The saddest part is that those running the EU have so little idea about how small business works that they don't even realise they're doing it.
Most businesses are tiny businesses. In the UK, 96% of all businesses are microbusinesses (classed as having 0-9 employees) and 99.9% of all businesses are SMEs (classes as having up to 250 employees).
Governments tend to obsess about big businesses, and the EU more than most. However, in the entire UK, there are only about seven thousand large businesses. Smaller businesses collectively contribute the majority of almost every important economic metric (jobs, tax revenues, etc.).
And of course, even the successful large businesses used to be successful smaller businesses.
Given that heavyweight EU regulations disproportionately affect those smaller businesses, because their compliance costs are relatively high, and given that excessive regulation makes it harder or in some cases impractical for businesses to trade within the EU, it is kind of crazy that the EU keeps putting these barriers up. Its own economic fortunes and those of its member states fundamentally depend on maintaining a good environment for smaller businesses to start and grow. Things rarely end well for economies that fail to do so.
That would be a plausible theory if the EU even realised that many thousands of these smaller businesses exist, but as we learned with the VAT mess, they literally didn't.
Yes, the VAT mess definitely does not deserve the beauty prize but with the MOSS it is actually manageable. I've done it for a couple of years and as long as your IPSP cooperates it shouldn't be more than 15 minutes of work per quarter.
I've done it for a couple of years and as long as your IPSP cooperates it shouldn't be more than 15 minutes of work per quarter.
That might be true if you're lucky enough to have a single third-party payment service that collects all of your revenues including administering the VAT parts for you. Unfortunately, there are many reasons why that might not be the case or even possible. Even if you do use one of those services, it can't magically cope with all the edge cases any more than you or I can, and of course they tend to take an extra cut out of your revenue.
For everyone who needs to manage their taxes a bit closer to home, it takes longer than your suggested time just to check the rates regularly in case some member state decided to increase them with about a week's notice again. There's not really any good answer to VAT MOSS, there are just more inconvenient and/or expensive and slightly less inconvenient and/or expensive.
We've had some emails from them as well, but we still assume it's our responsibility to check the rates weekly, based on the fact that at least one rate change has come into effect with little more notice than that and nobody (including HMRC) actively notified us first.
Publishing the rates is certainly better than not publishing them, but unless that information is updated in close to real time so it picks up those short-notice changes and unless it's supplied in a machine-readable format so that you can use it as a basis for automatically calculating correct VAT at the time of sale, it's of limited value for anything other than spotting mistakes retrospectively.
The EU really isn't a single large market though for most practical purposes. For the purposes of complying with regulations and accepting payment it is, but for every other practical consideration that matters to a company doing business there, it's a few dozen separate markets.
Are you arguing with my point or just trying to be contradictory? I never said blocking the EU was a good solution, but calling it a single market makes it sound more enticing than it is.
Some people may find that a valuable trade-off, because the alternative would be to permit their customers to demand that they rewrite their logs at any time. I, personally, believe that logs should be fundamentally append-only, and thus will not be doing business with EU subjects (since the GDPR requires that I delete records from my logs on demand).
Perhaps you could encrypt your logs after a predefined “live data” period passes. Each log line’s key would be derived from a key that is itself derived from the data subject’s unique identifier. If that subject invokes their “right to be forgotten” then the subject’s key is destroyed, rendering all thus-encrypted log lines irretrievable. This does mean analysis of “cold logs” would first require a potentially burdensome decryption process — but it would be possible, and the resulting logs would only contain data relating to permitted data subjects.
Guess what? The EU agrees with you. That's why the recommendation is that you strip PII from your logs for everybody. That way they can still be append only and you won't have to do any rewriting.
> I, personally, believe that logs should be fundamentally append-only, and thus will not be doing business with EU subjects (since the GDPR requires that I delete records from my logs on demand).
That statement does not hold a lot of force without a link to your business and how big a %age of your turnover you are willing to throw out.
> That's why the recommendation is that you strip PII from your logs for everybody.
The problem is that IP addresses — a fundamental requirement for an acceptable network logging system — are considered PII.
If this were about things like names, dates of birth &c. then I'd be in full agreement. But considering an IP address personal information which must be deleted on demand is IMNSHO insane.
> That statement does not hold a lot of force without a link to your business and how big a %age of your turnover you are willing to throw out.
I'm just a guy, y'know? I'm not going to pretend that it would be easy or cheap for others to make the same decision. But it is easy & cheap for me.
For a network logging system yes. But for a commercial entity on the web: no. Beyond a class 'C' you're not going to get much mileage out of IP addresses, unless you're trying to track people without using cookies and that would be one very good reason why you should not be keeping those IP addresses in the first place.
If you're an ISP that changes, in that case there is a retention requirement. But a regular business in the normal course of performing its expected activities has no business retaining IP addresses longer than necessary. If that to you is unacceptable because you want append-only logs that stretch back years then that's your choice.
But if I had to choose between cutting off roughly half of my turnover because I didn't want to comply with the law or complying with the law and slightly re-arranging my logging then I'd happily pick the latter.
So no need to delete on demand, simply don't store them longer than you feel you need to in order to meet your business goals. 30 days or so should do it. Six months or longer would require a detailed explanation.
And most importantly: disclose what you do. That way your customers can make informed decisions and you won't look bad in the eyes of the law if they decide to decide on whether or not you meant to act in good faith or if you took to interpreting things in the way that suits you best.
What you do or do not do should not be grounded in the consequences that you will face but in what's the best for your users.
If you feel that your users rights are of no concern to you then you are of course entirely able to ignore this law and to pretend it does not exist because in practice there will most likely not be any consequences whatsoever. You do not have a place of business in the EU, you do not transact any business there to begin with so you are free to ignore the law. And this is doubly true because you are 'small fry', nobody will notice.
Except for your customers maybe. And then that time that you got hacked and you lost all the data you collected over the years because you forgot to implement life cycle management. And this will then marginally affect the ability of other companies like yours to be able to do business.
And little by little the people that chose to ignore the law will start to become a large enough problem that something will be done about it (I hope). Which might mean harmonizing EU law and US law, or it might mean that you can be fined just as if you were in the EU for those breaches were you are clearly deficient.
In the end I don't think that you will enjoy the results much. But since you are small fry you probably will get away with it. But collectively, you and your buddies will harm American enterprise more than you probably realize.
> What you do or do not do should not be grounded in the consequences that you will face but in what's the best for your users.
I agree with the above. I disagree however that "what's best for your users" is universally a superset of GDPR regulations.
My personal view is that if your company/service becomes so powerful that people can't escape from its influence, the above regulations are a necessary evil in order to counter your outsized influence.
For a tiny startup on the other hand, you have so little influence on the world that if a consumer doesn't like the way you operate, they can just choose not to interact with you. Such startups can best serve both themselves and society at large, by focusing on building valuable features/services.
Reasonable people can disagree about the specifics of a law. As a EU citizen, I can understand your wishes for everyone to comply with EU regulations. It helps to put yourself in others' shoes, and ask yourself how much time/energy you, as a startup founder, would be willing to put into regulatory compliance with Canadian/Russian/Indian laws.
> It helps to put yourself in others' shoes, and ask yourself how much time/energy you, as a startup founder, would be willing to put into regulatory compliance with Canadian/Russian/Indian laws.
If I were to target my business at Canadians, Russians or Indians I would definitely make an effort to comply, especially if those laws in general did not originate from protectionism or were particularly hard to implement (which I don't think the GDPR is, at least not in spirit).
If you have a customer from the EU (...) you must comply with GPDR.
Nope, you have to specifically target people in the EU:
"In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union. (...) the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention"
He'd be exposed to increased risk by not complying(lawsuits, criminal action, etc.). It's based on his risk tolerance, the problem is it's hard to quantify at this point.
Based on a pretty thorough bit of search I can confidently say that no small (or even mid sized) US company has ever been fined or any executives detained or extradited because of breaking an EU law that would have not normally resulted in a criminal conviction.
The EU tends to go after the larger entities and tends to fine rather than arrest.
I've read most of it and I disagree that it has been written badly. As laws come it is accessible, has some pretty clearly defined goals and it is for the most part something you could easily comply with.
Yes the first 90% is reasonable, it is the last 10% that is a nightmare.
I comply with the general intent (always have), but the law as currently written is near impossible to comply with. My feeling is this will be realised by the EU and a more rational set of guidelines will emerge.
Acting in good faith is the best protection you can have. In your case if there are parts that you can not comply with I would note these as clearly as possible and disclose those specifically to customers and why you can't comply with them. And another thing you could do is to get yourself a $500/hour lawyer specializing in privacy for an hour or two to tell you what to do on a sheet of letterhead.
Since we are not based in the EU and don’t have a business presence there I think I might just keep following the intent and wait for the EU to be more sensible.
I really do wonder how EU companies are going to comply with all this. What an enormous waste of resources to catch a few bad actors.
It really does feel like a lot of policymakers don't actually realize how onerous their requirements are, and in turn, how much this hurts smaller businesses that can't afford dedicated resources to keep up with all these issues.
Of course, for the policymakers, it's a win, because as part of a rent-seeking bureaucracy, they can expand their empires as they produce more policies.
If your company is not targeting the EU as a market you are out of scope of GDPR.
If you explicitly accept Sterling/Euros, provide localisations for EU countries, talk explicitly about your EU shipping options etc. then you would probably be seen as accommodating the EU market and might find yourself in scope.
This is exactly what I was coming to HN to query about. Without some agreement with the US federal government, I don't believe they would have any mechanism of enforcement that would affect your business in the U.S. I imagine they could do something like block your site from EU ip addresses but nothing like coming after you or your company for damages.
This sort of argument is like saying you can commit murder then flee to Algeria, and the US will have no mechanism of enforcement. It's true, but heaven help you if they figure some mechanism out.
Technically true, but what does the enforcement action actually look like against the small town ice cream shop that doesn't know or care about the rights under the GDPR of a tourist from Spain?
So if I ignore a law in Canada or the EU (extradition request, default judgement, etc) as an officer of a corporation, I wouldn't get arrested when I show up on the border? Really?
For ignoring the GDPR as a small business owner operating on the internet the chances of individual consequences are nil.
High profile cases would have a much higher risk and companies that went out of their way to advertise the fact that they are going to break the law would run a significant risk.
Show me just one example of a company located outside the EU without a legal presence inside the EU that had an executive detained upon entry for breaking an EU law that does not normally result in criminal prosecution.
Does the EU have any other extra-territoral law as far reaching as the GDPR? Or any other extra-territoral law? A business shipping something to the EU doesn't count.
The only other extra-territorial laws I know of currently is FATCA and the FCPA, which are from the USA.
If the law applies outside the EU (for instance, if EU citizens travel to a non-EU country), then it is an extra-territorial law. As far as I understand the discussion here (which may or may not correspond with the actual law), the GDPR goes with the person. Wherever an EU citize goes, that EU citizen must be able to be forgotten, despite if the location they are in is outside EU jurisdiction. That is practically the definition of extra-territorial.
Now, would an EU court rule that someone who kept permanent records of an EU citizen be violating the GDPR if the business has no EU presence? In the American system (imagining if the US passed a GDPR and prosecuted a non-US citizen), no, because the government would not have standing to sue: the violation took place outside of US sovereignty. If the EU takes a similar approach, then the law is not extra-territorial in enforcement, otherwise it is.
No one is forcing you to follow it, but I suspect this is just the begining, GDPR is comming from EU due to history reasons, Europe has a lot of bad memories about keeping lists and tracking users. From Nazis to Stasi, USSR and so on and on. What is today done by google, fb, twitter is a light years ahead of that. Try to understand that GDPR is not something bad, it is rasing credibility for your bussiness and is doing something right. I bet a lot of, lets say, USA cityzens will value text "we are GDPR compliant for whole world" on web site. It is oportunity that Backblaze grabbed and soon sites that don't follow it will be on fishy side of the internet. And I also believe, a lot of non EU contries will adapt similar laws, the attack on privacy has gone too far, don't blame EU, blame ggl and fb.
It's not related to the Nazis. Please. If it were really related to memory of abusive governments they wouldn't have just written a law with phenomenal penalties and ultra-vague language that everyone can be argued to violate - exactly the sort of law that all totalitarian states love to have.
GDPR exists because the EU wants to be the primary legislating entity in Europe, replacing local governments, and because it likes the idea of funding itself through huge fines. It exists to serve political ends.
If you have a customer from the EU, you must comply with GPDR. Full stop.
Also, if any component of your cloud ecosystem(AWS, GCS, etc.) are based in the EU, you must comply with GPDR. Which in today's world means almost everyone is affected by this.
Make sure those "American" platforms you speak have every single component of their infrastructure based physically in America.
The whole thing may be difficult to enforce, but meh why risk it?
In the typical web/e-commerce context someone whose IP address geolocates to an EU based end point or someone who lists their delivery address as inside the union.
The problem is that the law applies to them even if they use a proxy. If they report/sue you afterwards, you might be looking at a huge amount of trouble.
That's not very comforting when your goal is avoid having unforeseen problems like being arrested on your European vacation due to violating a law that doesn't apply to your country but you still violated because it applies to all EU citizens regardless of their geographical location.
The general direction is correct, but not the specific implementation - since it applies to everyone in the EU, no matter what their citizenship, you can just reject all transactions where the shipping address (or credit card address for virtual goods) is in the EU; and that should probably be fine.
On the other hand, if you actually want to sell stuff to EU and get a nontrivial number of deals, then no amount of weird checkboxes is going to convince the regulator that it's okay, they aren't stupid.
Is it just me or does this article manage to give advice while saying nothing at all about what is required?
For example:
> The first half is the General Data Protection Regulation (GDPR), which becomes enforceable across Europe on 25 May 2018. This is an overhaul, modernization, and replacement of the existing framework, the Data Protection Directive of 1995 (yes, 1995.)
> All of the existing principles from the original Directive stay with us under GDPR. What GDPR adds is new definitions and requirements to reflect changes in technology which simply did not exist in the dialup era. It also tightens up requirements for transparency, disclosure, and process: lessons learned from 23 years of experience.
It's talking about the new definitions and requirements, but says nothing about what they are!
I have been through a number of GDPR resources and seminars and I am still of the opinion that there is nothing in it to worry people who are acting in good faith with their customers data. The organisations fined under existing laws seem to have been breathtakingly negligent or just deliberately callous.
Q: would I still be able to keep session logs of user journeys through my site without explicit consent? If not, this seems like huge issue for ecommerce analytics. If I need to obtain explicit consent, that the user isn't required to provide to continue accessing the site then I don't see how these technologies are not basically dead in the EU.
Can you even legally do a customer churn analysis under the GDPR without explicit consent?
One of the biggest complaints I have about this is that the uses for data keep growing, and legally, you can't even test a hypothesis before getting consent, which you won't be able to do frequently because users hate being asked about anything.
My intuitive response to this law is to want to split my data into EU/non-EU parts, do all my work on the non-EU parts and hope that the insights gained there can be applied to EU users.
Yes you can keep session logs, it is a 'legitimate interest'.
Are you just trying to see which deals interest people (zero issue, but you could annonymise this) or profiling the customer based on the logs and offering different prices (you are going to have to be more careful and transparent).
> Can you even legally do a customer churn analysis under the GDPR without explicit consent
There a lots of ways to look at churn with anonymised data. I do it with account ID's. If you are looking at churn rate of Asian people vs Afro-Caribbean then GDPR is going to be amongst your problems,
No, put up a “trap” page, tell the user you need to collect certain data to operate the site and make the user clicks Accept before they can use your it.
Funnily, one of the common fears our clients (https://gdpr-tools.eu) have with regards to GDPR is not about the general public. It comes from disgruntled employees ratting on the company.
Employees know best where personal data is stored (and often no one else in the company does), so they can really do some surgical damage by reporting their employer to the "authorities". GDPR introduces a whole new dynamic.
This is the case for every law. A disgruntled[1] employee at a coffee shop that has mold growing on the kitchen ceiling can, after being ignored by management for weeks, rat on the company. (And then get shitcanned, with no recourse, because none of their co-workers will testify to the truth on their behalf, because they are cowards who don't want to lose their jobs. Understandable, but sad.)
This doesn't mean that we don't need food health and safety inspection laws. It does mean that you actually need to run your business in a way that respects your customers.
Stop running your company with the attitude of "It's fine, as long as I can get away with it." I have no sympathy for that.
[1] You can be a disgruntled employee, and also be 100% in the right, if your boss is behaving illegally.
I am curious, if you offered a service that allowed users to post their own data to your service. How do you protect against customers posting data that violates the GDPR. I.e. peoples personal information being posted in plaintext?
Is this type of case covered by the GDPR?
Also how are things like access logs supposed to handled according to the GDPR? Our software records all requests made to our API, they log your userid, ip address, and what you were trying to do.
We have clients who are in the US who required the above feature for auditing purposes.
The GDPR defines two types of companies: processors and controllers. The crucial distinction is (roughly) if a company makes decisions. Someone performing targeting or operating a website is probably a controller, whereas AWS, who makes no decisions and just follows directions, is a processor.
If you don't want to be a processor, the best thing to do is probably in your contracts disallow usage of your service for anything containing GDPR covered personal data.
As for access logs, those will be some mixture of the two bases offered in the GDPR. Some will be required by legitimate interests (such as those collected for legal requirements) and some will be subject to consent. This is a complex discussion.
> I am curious, if you offered a service that allowed users to post their own data to your service. How do you protect against customers posting data that violates the GDPR. I.e. peoples personal information being posted in plaintext?
You ensure that those users have a way to delete the data again.
I'd actually considered implementing a "soft delete" function for my service (knowledge management SaaS), out of fear that a user would accidentally delete something important.
Now with GDPR pending, I think I won't. I'll just leave my 'no sh*t delete' function in place. If I get a request to restore any data I can say, "Sorry, the Europeans made me burn your data when you unwittingly clicked the red 'delete' button (as well as the confirmation dialog you didn't read)."
If you purge soft-deleted records after (say) 2 months, and don't use those records for anything unless they are undeleted by the users request, I don't think that should cause any problems with GDPR.
It should be very clear to the user how the data will be used and shared. If a hotel asks for free-form feedback, it shouldn't magically post the response as a review, under the user's name, on a public site, for example.
I am not a lawyer nor a security expert but we've decided at the place where I work that unstructured fields which are unlikely to contain personal data—but might in edge cases where a user chooses to enter it—don't fall under the GDPR purview.
An extreme example of this is in hosted email—if Alice writes an email to bob@gmail.com with some of Charlie's personal information, it would be absurd if Charlie could ask Google to remove the email. (Although maybe reasonable if Charlie could request to not have his data used by Google to target him or anyone else with ads.)
I have to guess this is why gmail stopped (or at least announced stopping) personalized targeting: the difficulty of deciding if anyone on the email is subject to GDPR.
Typically, privacy violations are instances where the user has not consented to sharing the information. In the scenario you describe, if someone willingly posts their own personal information they have forfeited their right to privacy.
The law is meant to protect people from companies rather than people from themselves.
Your joe blogger using somesmallwordpresshosting.com and you have a freeform comments page. People post 'private' comments of others. Who is responsible for what? How the fuck do you know if its of an 'EU citizen' if that isn't made obvious? Can you get fined literal millions because you fucked up some detail for your blog newsletter's email list?
I've been digging into GDPR for the last year or so and the major conclusion I came away with was that, in effect, it is a massive effort to educate the population about data collection and processing online while also beefing up guarantees for data security.
As in, it's not illegal to to do most of the same things we do now with data, however we now need to educate our users on what data we are using and exactly how we are using it, in a way that is understandable to the average user.
With all due respect to the average user, I cannot fathom how anyone doing anything with user data more complicated than a basic record will explain it simply enough to be in compliance.
In this article the author states: "The latter definition is important for developers. It includes things like IP addresses, mobile device IDs, browser fingerprints, RFID tags, MAC addresses, cookies, telemetry, user account IDs, and any other form of system-generated data which identifies a natural person.". This information does NOT automatically qualify as personal data. Information being unique is not the same as personally identifiable. A random cookie sent by the browser is not PII. A cookie stored in conjunction with say an email address could be.
Certain information can be classified as PII if it possible to cross reference it with other stored information to identity a user. For example a European court in a recent ruling stated that a full IP address could be considered PII because an ISP would have a record of IP address and time with a persons name.
To me it seems quite simple, if the information can be used to identify user it is personal information and you need explanation why you need it and opt in. If this is a problem for you, maybe avoid collecting what you don't need. The idea of "collect everything and audio & canvas fingerprint them, maybe I will need it later" wont pass, you will never get consent. Collect only what you really need.
Right. So you'd have to have a business case for the user to have a persistent login, if you want to offer login functionality, beyond simply "track the user to see what they want". It's ridiculous.
Very simplified, you can not use or give personal data to someone else without optin given consent (where you must state in non legal, non tech speech for what they will be used) and same goes for enabling others (ad networks, google,..) to get those data. Or you are breaking the law. Further, user must be allowed to view, change or delete those data and remove consent to use them in whole chain (your site, ad network used on your site,...) Furthermore the consent must be freely given (forget trackwalls).
And also, there's also the slightly grey-area requirement that (if you're using it as your legal basis) consent should not be required in order to utilise your product, merely to utilise the feature set that requires the data.
If you need everything, then you'll need to use "fulfilment of a contract" as the basis, and in that case, you probably need to make your ToS pretty tight too.
Question about the freely given consent -
Say I'm a car company like Tesla and I collect telemetry from the car to train a self-driving car model. I ask the user for consent to collect this data to train the self-driving model.
For the users that refuse this consent, can I prevent them from accessing the self-driving feature of the car? If not, how would the company deal with the free-rider problem - nobody opts in because they want their privacy but they also want the feature?
In that instance, I (personally, IANAL) wouldn't use consent as the legal basis. You could (esp with a legal team like Tesla could afford) pretty easily work that into either fulfilment of a contract, or legitimate interests.
AI and ML have to be careful [0], as you need to be explicit about the data's use and impact on the end-user. The most given example for this is ML algos that determine eligibility for financial products, but we could probably twist that Tesla example to fit a similar to be "my data is used to inform an algo that determines what the car does in a dangerous situation", so you might have to abide by rights to explanation and data editing.
The number of potential free-riders is tiny, so there's no reason to retaliate against them. The same problem exists in Internet services. If blekko (a startup search engine) saw a DNT do not track header from a user, we wouldn't even include their queries in our anonymized dataset. That slowed our learning-to-rank process, but only by a little.
GDPR has a lot of parallels to HIPAA and SOC 2. Many developers here have worked with companies subject to HIPAA, or that do SOC 2 reporting.
One big difference is that the material scope of GDPR is so extremely broad: it regulates any PII that can be touched by EU law. That's important because it means that all of your SaaS vendors that touch this data may be in scope, not just your hosting stack. If you're marketing or selling in the EU, your entire growth/CRM/customer success stack will be regulated. If you have EU employees or contractors, all of their HR data is covered. I'm not sure if most companies realize this. It may be less of a problem for B2B, we'll see.
Questions to ask yourself: What is the scope of GDPR personal data across your business? Are you marketing in Europe? Are you selling into Europe? What business processes touch that data?
What I like about GDPR is that it might help change the mindset that storing customer data is purel an asset - it should be a liability. Hopefully other countries will ratify similar laws. Then something like the Equifax breach could go unpunished!
I wonder if we will see a kind of dual universe privacy in implementations once countries like China become equal as a market for internet services, and they create some sort of a reverse GDPR law. Then for all customers from the EU you will have to completely anonymize and protect all data to the last bit, while for Chinese customers you'll have to implement the most rigid and total tracking possible?
The EU subsidiary would not be legally able to use any of that data (it can't take it from the China subsidiary in any way whatsoever); and the China subsidiary would not be practically able to use any of that data, since they don't have any users/customers in EU.
GDPR would apply if an EU company would track people in China (Article 3 section 1); it would apply if an multinational company tracks people in EU when offering goods or services to them (Article 3 section 2); but it wouldn't apply when that same multinational company tracks people in China.
I.e. Facebook can be fully GDPR compliant if it applies the privacy requirements only to people in EU and gratuitously violates the privacy of everyone else.
Furthermore, if China has a legal requirement for intense tracking of customers (I'm not sure what their legal requirements are), then GDPR would allow an EU company to do that without consent. (Article 6, 1c : "Processing shall be lawful [..] if ... processing is necessary for compliance with a legal obligation to which the controller is subject")
The EU is going to send over its army and force you to comply.
My understanding is the GDPR applies to residents of the EU, not just citizens, and it also applies when they are outside the EU. In practice this means it is impossible to determine if it applies unless you gather far more information than you really need from your users - “sorry we have to invade your privacy to protect your privacy”.
So a US company providing services to a US naturalized citizen in the US that is also a dual citizen of a country in the EU makes the company liable to follow these regulations?
Yep. It is worse that it can be a EU resident (non-citizen) visiting the the USA using a USA only service and the law as currently written still applies. Good luck.
The next fun job is working out how to remove the data from all your backups when you get a removal request.
I have taken the approach that I will comply with the general intent of the GDPR (which I did long before it existed), but not try to apply the ridiculous parts.
"Yep. It is worse that it can be a EU resident (non-citizen) visiting the the USA using a USA only service and the law as currently written still applies. Good luck."
You're going to have to provide proof to back up that statement.
The regulations are ridiculously broad [0]. They appear to cover everyone in the world no matter where they are or what their citizenship. The EU seems to be aiming for a universal human right.
"The principles of, and rules on the protection of natural persons with regard to the processing of their personal data should, whatever their nationality or residence, respect their fundamental rights and freedoms, in particular their right to the protection of personal data.”
It says it applies to the “...processing of personal data of data subjects who are in the Union…”.
If someone in the EU (say a visitor) asks to have their data removed that was collected while they were outside the EU, then the controller or processor is supposed to comply.
How is any business supposed to know if a user while they were in the USA of a service located in the USA will not later travel to the EU and make a data removal request while there? If the request comes from someone located in the EU then the regulations apply.
The practical result is you can’t just geo ban people from the EU and this is before we get to the problem of proxies.
You're leaving off the end of the sentence. Data collected about someone outside of the EU is not covered by GDPR even if they later enter the EU.
> where the processing activities are related to: the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or the monitoring of their behaviour as far as their behaviour takes place within the Union.
There is an “or” not an “and” between these two clauses. It applies if you offer any goods or service, OR monitor behaviour inside the EU.
It is interesting that the monitoring clause only applied if the subject is inside the EU when the monitoring is done, while the service or goods clause applies if the person is inside the EU with no requirement that the service or good was acquire or used within the EU. I can’t really think of any logical reason for this distinction. The “takes place within the Union” for one and not the other is strange.
No they don't. The first is limited to subjects in the EU while the second is limited to activity in EU. If the first clause was limited to activities that take place within the EU the clause would say this - actually there would be no need for two clauses as you would just have one clause that says sale, service and monitoring.
It clearly says offering goods and services to subjects in the Union. It only applies if they are in the Union when you are offering them goods or services. If you offer them goods or services outside of the Union and they later enter the Union, you didn't offer goods to someone in the Union, so GDPR doesn't apply.
If you offered them a service and they are in the EU then it is covered. There is no location exemption that this clause only applies when the service was offered when they are in the EU unlike the monitoring clause. Why do you think they broke this out into two separate clauses?
If you get a request from someone in the EU to remove their data you have to comply no matter where or when the data about them was acquired. The clause is quite clear on this point and it why it is written differently to the clause about monitoring.
Trade agreements don’t enforce laws, they just mean the countries are supposed to draft local laws that cover the action. This assumes that the GDPR is covered by trade agreement.
This is a great question that unfortunately doesn't have a good answer. Ignoring the question of backups, GDPR's requirements have the implication of imposing a workload on database engines that, in most modern architectures, is either pathologically expensive or not currently possible. Some companies are approaching this from a "best effort" standpoint rather than conforming to the spirit of the regulation because the technology simply isn't there to make it feasible for some cases. I've been working on this problem for the last year and this is (IMO) a major gap in the regulation; it presumes that something is possible that isn't for existing applications that are otherwise universally viewed as harmless and permissible.
Scalable database engines that can support the letter of the GDPR in terms of data handling don't really exist. This is not a problem that can be trivially solved by patching an existing database engine; the requirements of strict GDPR data handling violates fundamental design assumptions of common database architectures. If you look at, for example, high-assurance databases which have a similar set of requirements for data handling as GDPR, they are never used when at all possible because their performance and scalability is terrible. (These databases are conventional architectures with GDPR-like data handling controls added.)
A database engine capable of strict conformance with GDPR while maintaining vaguely comparable performance and scalability relative to what we are used to would require a comprehensive new database engine design from first principles. This is something only a small number of people are capable of designing and implementation would be a very substantial engineering effort. Possibly a business opportunity -- one of the reasons I've been thinking about it, having worked on high-assurance databases in the past.
Purging a user's data is probably a matter of writing a short SQL/Python/Bash script for most databases (don't forget the audit tables, though it kind of defeats the purpose of audit tables, but whatever). It's something I'd only do on request (I'd expect it to be a rare occurrence), certainly not going to automate that sort of thing.
I'm not about to go risk corrupting my backups trying to scrub old customer data out of them. Perhaps only keep the last X days of backups and let the paranoid customer's data attrit out naturally?
With a documented data retention and deletion policy. You don't need to keep your DB backups forever, and a request to delete someone's data comes with some reasonable amount of leeway as to how long it takes you to delete it. Obviously you can't drag that out for a year, but from what I've been hearing, a month or two isn't unreasonable.
If you're doing DB backups daily, expiring backups after a month (or even, say, two weeks), should be no problem and not an operational risk at all.
One approach may be to tokenize user information. Ensure that any personal data is separated from other data and mapped via tokens and kept in one place. Handle backups of this database with special care.
You can then have the rest of your systems work as normal.
All this is easier said than done if you have a large investment in existing systems, but it is probably a design approach you can enforce from the beginning if you are a startup.
A thought I had that I haven't heard elsewhere: this is the EU equivalent of the Great Firewall - an immensely powerful tool for governments to use against "foreign" companies that don't have the proper values.
The EU would love to have a tech company that could be compared to Google, Facebook, or Tencent, but its attempts to create one by fiat (Quaero, for example) have fallen flat.
The mechanism (legal rather than technical) and the claimed ideals (privacy rather than anti-pornography) are different, but the effect will be the same.
Depending on your perspective, this represents a tremendous opportunity for EU-based startups. Your government will almost certainly make things very difficult for your foreign competitors. Cozy up to your local Party officials!
It's probably safe to err on the side of caution and assume that any application that stores personal data in permanent storage is a data-intensive application.
Absolutely! Anybody who does business in Europe or even has users in Europe is subject to this law.
The amount of effort being put into GDPR compliance within my organization is just staggering. It really makes me think about these kind of laws from a new perspective, because they cost businesses so much to implement.
(I'm not saying whether GDPR is right or wrong! Just that it's expensive.)
I would (maybe naively) think that the cost of GDPR compliance would be small if your company is already safeguarding user data and respecting user privacy. If a company’s cost is “staggering“ doesn’t that say a lot about its existing privacy practices?
I'm not sure. I think this is a very absolutist and probably naive way to look at it, frankly.
For a simple example, let's say you use an immutable data store. What do you do if a customer wants every info about them redacted, but you did something like store their IP, name, or email. All common things. Now you must build mutability into your store and all assumptions that used to be made can be removed.
This is just a very small piece of something that even a small or medium company may be using or doing.
Will this satisfy GDPR requirements fully? What if that key had somehow been involved in an unknown leak in the past (of just the keys) and then the data is exposed somehow in the future?
Leaks are punished, as they probably should be, under gdpr anyways. But now do we have to account for all of the keys over time and have it be probably gone? What if we take backups of the systems that stores the keys? Do we have to purge those backups as part of the deletion request? What if they're terabytes in size?
Right, but you had assumptions built into your data store before, namely that you could keep all info about someone for eternity, and that you'd never have to correct it.
I presume you're talking about things like informing users how their data might be used, storing user data securely, and not selling it to third parties. That sort of stuff is relatively easy.
The GDPR imposes some new requirements that were not previously part of any privacy best-practices that I'm aware of, and that create some system complexity. Chief among these is the right for users to retract consent after it has previously been granted. This effectively requires processors to be able to delete individuals' data from their records, something that was not a design requirement of many systems. This becomes increasingly more difficult as user data has often been aggregated, and joined with other data sources.
Another key differentiation of the GDPR compared to previous legislation is that it applies not only to data that identifies a person (such as by containing a name or social), but to data that could in theory be linked back to the user through a common identifier. Previous best practices have considered the user's privacy protected if they were identified through a hashed email or an opaque database identifier, but the GDPR does not consider this sufficient anymore.
Thanks for the details! I can see how this could get costly for complex systems. As a user though I would think all those things you listed would be existing privacy best practices but I guess that’s being way too optimistic. Scary what companies are currently getting away with, too but not surprising.
I think you're right in that those things would be (or should be) considered "privacy best practices", but, unfortunately, most companies don't have "following privacy best practices" all that high on their list of priorities.
It's not even malicious; in the absence of regulation to the contrary, companies -- especially companies still in search of a revenue model -- have an incentive to collect as much information as possible.
Definitely not true. GDPR significantly broadens the types of data subject to legal requirements. Whereas yesterday I only had to protect PII and content, now even telemetry and performance data becomes subject to new rules.
This is a huge problem for an org that relies on huge amounts of such data to keep our product running and uses systems which were never built with these new rules and classifications in mind.
Furthermore, there are huge complications surrounding "data processor" scenarios (in other words, Enterprise SaaS products). For example, what takes precedence, GDPR deletion or our contractual security/auditing obligations?
Again, I'm not saying that any of this isn't worth while, just that when you get down into the weeds things look a little different.
I think the main issue that I see is that whilst GDPR doesn't massively expand the scope of what is personal data beyond that under existing data protection law, it does expand the territorial reach of data protection law.
US companies who previously had the narrow scope of PII to handle, now have to consider the much broader scope of 'personal data'. I am sure that for lots of US companies providing services to EU citizens/residents that will definitely represent a substantial burden.
Even for EU companies, the reality is that many will have previously taken a view that the size of potential fines was not high enough to warrant giving certain matters that much attention or at least spend money on areas they considered more important. For example, if I have a choice between implementing additional security measures to protect my network versus building functionality to delete on command, many companies will have gone with the former.
On retention, my view is that if you consider it necessary to retain information for purposes of auditing/security, and have made that clear in your contract with the client (who would then should make that clear in their privacy notice if they don't already have a general caveat around that), then the right to delete under Art 17 does not kick in because Art 17(1)(a) is not engaged. Also, dependent on the grounds on which you are looking to retain Art 17(3) gives a controller a clear ground to retain.
Also the right to erasure is one that will generally be directed at the controller. The controller would then flow down that request to a processor but that is where the contractual protections would come in, which in my experience, most clients are generally willing to accept.
From the article, the thing that jumped out at me was documenting it all. Sure, your processes may be perfectly pristine. Where's your document that shows that you considered everything? Don't forget to include development processes. And don't forget to update your documentation when your processes change.
Changing the processes may not be hard, if you're doing things close to right to begin with. Complying with the documentation requirements? That's going to be painful.
Just for starters, you will need to decide which data you have to process and which is optional. Some data will need to be kept for compliance purposes. How much anonymization will be applied. What data is in every single internal db in your org? Do you even know of all the internal dbs? Each data will have to be tagged with the collection basis, either legitimate interest or consent.
The GDPR is also -- as I've complained on here before -- less of a regulation and more of a framework for 30-odd individual country privacy regulators. Some parts of the GDPR, eg on consent, are laid out in black and white. Other parts aren't at all. And the EU wankers have declined to issue final guidance on the latter even by this date, less than 3 months from the compliance deadline.
There's also cute stuff in there like if you have more than 250 employees or engage in "widespread processing of personal data" (widespread processing left, of course, undefined) you will have to hire a Data Protection Officer. Said DPO must be in the EU and report to the ceo. This will be quite a nice cottage industry for EU lawyers.
American companies are probably unable to pick a lead regulator and hence will be subject to the individual regulators of each EU country. What happens when some french person (France has a very aggressive privacy regulator) complains to the regulator, and you are dealing with a regulator in a language you don't speak? I hope you enjoy paying legal $600/hour.
The GDPR does specify enough around consent (ie all consent-basis contacts must be default opt-out) to make it highly unlikely that any of your email or newsletter opt-ins are compliant. You will have to re-consent all of your marketing emails, and this may come with significant attrition. This will be painful for outbound sales, even outbound sales that currently is very respectful of opt-outs.
Data subjects can also do things like request a copy of all data (a so-called Subject Access Request or SAR), request deletion, and even freeze processing, which is supposed to stop processing without deletion. This must percolate through all third party systems, of which most companies will have a lot. Just start with your two mailing systems (transactional + marketing), logs, analytics, billing, salesforce, billing, etc. And as mentioned above, it is required to percolate through internal systems.
You will have to have an ugly discussion about backups. Are you going to roll backups at 30 days? That's probably not ideal. But what should happen when a data deletion request is received and that data is, of course, sitting in backups?
The short story is this is expensive and painful enough that, if I only had incidental European customers, I'd probably ignore it and close their accounts if they complain. This is very much not GDPR compliant, but as an American company, I'd do it anyway because of the expense of dealing with the above.
It says a lot about the cost of privacy, period. The cost would be staggering whether they're modifying existing things, or creating new things, just in terms of ensuring "Yes, we're doing this correctly".
I just find it hard to believe that the law is a significant cost to companies already doing the right thing. Sure, there is a non zero cost to ensuring your existing practices are lawful, which everyone must pay. But companies already in compliance shouldnt have to modify or create anything.
The companies that have to spend significant coin are the ones who are not already complying.
Part of the cost is -documenting- what you're doing. Ensuring the right stakeholders are involved and signed off on it. Etc. When there's a regulation to do it, suddenly you have to involve legal, and the business stakeholders want to better understand it, whereas before it may have just been the developers.
> Anybody who does business in Europe or even has users in Europe is subject to this law.
Anybody? Sure technically in the same way that going 58 in a 55mph zone is speeding and could get you a ticket. So the question remains assessing the probability of enforcement of a hypothetically a small US based organization who has European customers. As I read the replies on this page it seems to be a mix of people who have a great deal of theory and not a large amount of practical experience assessing the probability of something actually happening given breaking a European law.
Yeah, but is it expensive because of how you were set up before? In other words, if you weren't set up to be so cavalier with user's data before, would it be as expensive now?
Any multinational is working on mitigation right now (including my own company) since GDPR compliance is based on having customers in affected regions, not being located/headquartered in those regions.
Will the GDPR eventually make bitcoin or other immutable public distributed databases illegal in the EU? Do you have default judgements on thousands john doe node operators around the world? Will EU ISPs be required to censor any kind of blockchain node eventually when someone has a GDPR complaint for that network? Will we arrest teenagers for running ethereum miners on their gaming computers after all of this?
"the personal data are no longer necessary in relation to the
purposes for which they were collected or otherwise processed"
The data you submitted to a blockchain database is inherently needed
forever for it to function, so I think there's zero chance that this
will be interpreted as to make Blockchains illegal.
What might happen is that this in combination with the "Conditions
for consent"[1] will force people who ship blockchain software to have
prominent warnings saying that you're about to ship data that'll be
public forever.
Will any information that enables identification of the individual (or the other ancillary information spelled out in the article and regulations) be in the blockchain? If not, doesn't sound like it.
Here is one way to think of this. Any EU citizen has a "right to be forgotten". If there is nothing in your records to identify that person, the you don't need to provide that ability.
OK, but what the parent is suggesting is that someone might store someone's personally identifiable information on "the blockchain", thus making the entire bitcoin network in violation of GDPR. It's a fairly on-point criticism, IMO.
it's not Bitcoin network that's in violation, but the company that owns the transaction in which the data is in.
let's say I'm a shop and i allow btc payments, but I include the customers info in the transaction or something to such an effect. then I'm in violation, and must pay a fine (since I can never delete that info). The network has nothing to do with this, and nobody else on the network is party to the violation.
There are also blockchain style social networks such as steem that create things that are like reddit: https://steem.io / https://steemit.com . Again, freeform public text blobs that can have private info.
If you create any censorship resistant publishing software, lets say to report on human rights violations in some sort of dictatorship, you also create something that can be used to violate the GDPR.
Isn't a public key a potentially identifiable piece of info that becomes personal information if anyone (like an exchange) stores it in conjunction with other personal information? I don't see how it is any different than an IP address.
You've raised a really good point with this. Honestly, the whole "right to be forgotten" thing is utter BS. Might as well call it "the memory hole act". Or better yet, "the right to silence the opposition".
Note that this doesn't actually provide any useful anonymization. That feature is a placebo designed to give minimal compliance with privacy policies and pre-GDPR data protection requirements.
They're anonymized for things like logs. When the computers aren't talking to each other, the reasons to know the exact IP address are rather minimized. If you feel you have a real need to do so, then you just need to inform your users what you're doing.
Follow OWASP, encrypt in motion and at rest, use key-manager appliance, implement access logging and store separate from systems, backups of data, define lifetime of data, physical controls to data storage facilities, access controls in system, manage multi-tenancy as the situation requires, sensible password policies / multi-factor authentication, background checks on employees, train staff on security, perform regular scans, restrict ports, intrusion detection system, penetration testing, have plans for business continuity and disaster recovery and practice implementing them, be aware when third party libraries are being used and have a policy for applying software/os patches.
I don’t see this helping at all. The big companies will just get consent and then it’s business as normal. Sites that can’t comply due to lack of resources will just block EU access. Really this is just a bullet point for the big guys and stifling for the small guys.
I built an app that displays geolocations of tweets on an OpenStreetMap. That data is publicly available from Twitter and users share their location willingly, I presume. Will an app like that become illegal, as far as European tweeters are concerned?
It's unclear. The GDPR definitely covers personal data even if publicly available, so just because you grabbed it from twitter doesn't make it kosher.
That said, realistically, I'd have a hard time imagining you would have too much difficulty as long as you allowed people to delete their data upon request. If they post something to twitter, the obvious intent is to make it very public.
For a real life example, there is a group of people that collect Facebook posts and process them through a ML filter which judges if the post contains hate speech, and if it does, it reports the post to the police, supposedly after manual review.
Does this processing comply with GDPR? I'm pretty sure none of the people would allow this processing to take place if they were asked for permission.
My best guess is they will be able to shut this down hard, unless there is some alternative processing basis to be leaned on. See (6)1 for a list of potential bases.
For your particular scenario, the main impact of GDPR would be not on your actions but on Twitter obtaining the data (which is personal information at the tweet level) and distributing it publicly to third parties like you.
I don't see any clear restrictions for you, but perhaps GDPR will result in your data source becoming unavailable.
What? Of course not. This law doesn't make apps "illegal".
What the law does is put regulations around what kind of personal data you can collect and store from your users, require you to explain what you're doing with that data, and allow your users to opt out of having that data collected.
Unable to direct attack freedom of expression, the spread of informations and small business, the EU developed another bureacratic layer on top all the bureaucratic layers already in effect. This layer is pretty hard to comply with, and requires a lawyer always on retaneir for peace of mind, ensuring that publishing online is de facto reserved to few players. Every other interpretation of the law is naive, just like with the cookie law, if they really wanted to stop the abuses of the big players they could have done so. Instead they're ruining normal people, because that's the real objective.
>Online identifiers ... is important for developers. It includes things like IP addresses, mobile device IDs, browser fingerprints, RFID tags, MAC addresses, cookies, telemetry, user account IDs, and any other form of system-generated data which identifies a natural person.
What if one exclusively collects telemetry IDs (unique per application), with which usage stats are sent. To what extent is this personal data? On who does the burden of proof for 'being able to identify a natural person' fall?
"The extraterritorial nature of these two frameworks..."
I've noticed that this is something the EU has tried to do lately, to just sort of push their regulations on the rest of the world. I don't see what sort of authority they'd have to impose this on citizens of other countries.
I wonder if Europe pushes the issue, if this will be treated like libel tourism, where US citizens and companies without a Eurpoean nexus will be explicitly protected from judgements against them.
It's quite simple. If you want to do business in the EU or with people who reside in the EU, you need to comply with the EU's regulations.
Don't like it? Don't do business in/with the EU. Then you're free to ignore their frameworks, rules and regulations.
They are not trying to "impose their regulations on the rest of the world", they're trying to protect the privacy of their inhabitants. That this leads to measures that need to be taken by companies doing business with (the data of) their inhabitants is a side-effect and only logical.
If a business decides to opt-out of doing business with the EU as a result, what measures do they need to take? Would a banner asking "Are you an EU citizen? Yes/No" suffice? Or would we have to use some kind of Geo IP tool? How would that defend against EU citizens using a VPN or Tor, and what would a business's liability be in that case?
What kind of business exists where it would be cheaper to drop European revenue than comply with GDPR?
The major tech companies impacted by the law are already likely taking steps to comply. Is anyone seriously saying they’d rather just wave goodbye to an entire continent?
Not all organisations will need to be compliant with GDPR. By that I mean, if your organisation only do marketing in, for example, the US and Canada, only accepts USD/CAD and they are no legitimate appearance that you do/want to do business in Europe, you are not required to be GDPR compliant, even if an european customer goes on your website and purchases a product/service.
If your website accepts Euros, has multiple european languages (e.g. spanish, german, etc.), you do marketing in Europe, then we can conclude that you legitimely do business in Europe, you are then required to be GDPR compliant. This is indicated in one of the GDPR article (can't remember which one)
This are all limitation/qualification upon whether you qualify as providing goods/services.
Yet, that is only one of two reasons why you would be subject to GDPR, the other is "the monitoring of their behaviour as far as their behaviour takes place within the Union".
As far as I can tell, logging a european IP address together with urls (i.e. an access log like every server has) would qualify you even if you aren't doing business there.
"[...]Whereas the mere accessibility of the controller's,
processor's or an intermediary's website in the Union, of an email address or of other contact details, or the use
of a language generally used in the third country where the controller is established, is insufficient to ascertain
such intention, factors such as the use of a language or a currency generally used in one or more Member States
with the possibility of ordering goods and services in that other language, or the mentioning of customers or
users who are in the Union, may make it apparent that the controller envisages offering goods or services to data
subjects in the Union."
So what, English and French? Those are the two major languages of the union, but are also the two official languages of canada. Seems like you can easily get hamstrung on a technicality.
Those are factors, not hard and fast rules. If you are a Canadian company and you provide services in English and French, that alone wouldn't indicate that you are targeting EU users. There would need to be other factors indicating your intent to target EU users.
You might need to add something to your terms asking the lines of users certifying that they are not EU residents or citizens and agree to not move to any EU country, and if they do any of those things they agree to indemnify you for any legal expenses or fines resulting from that.
Simply stop accepting European credit cards. Just like many EU online shops do not accept non-EU (or what blacklist do they have) cards. At least I haven't been able to buy an ebook without a proper European card and/or billing address.
ok, but maybe combined with the notice that if you're from EU, you should leave, that would be an effective measure to show you mean it when you say 'no business with EU'.
There's a big difference between "in the EU" and "with people who reside in the EU". When I come to the EU to do business, sure, I'll comply with their laws.
But it's very different to expect people who live outside the EU to respect EU laws, just because someone from the EU happens to choose to visit their website. I don't see this as any different than if someone in the EU was to visit a convenience store in the US - should the convenience store owner be bound by EU regulations in that case?
The comparison to the convenience store fails because in the digital realm, the customer does not need to physically travel outside the EU to do business with somebody outside the EU.
Or, to look at it another way: If it weren't extraterritorial, ad providers (for example) could simply close their local branches, and EU citizens would not be protected from consent-less data gathering. To realistically be able to fulfill its mission, the GDPR _has_ to be global in scope.
Why don't ad providers simply close their local branches, stop accepting these tainted Euros, and collect the data anyway? As mentioned elsewhere in the thread, there's limited mechanism of enforcement.
For the same reason that downloading a song is different than stealing with a CD. Digital stuff is innately different.
You aren't doing business unless you're accepting payments/selling/shipping things to people in the EU. And as with any law, if you're sufficiently small fry the EU isn't going to care about you until you actually screw up. Don't accept euros as currency. Don't offer to ship to EU nations. Done. If you do accept payments/ship/etc, unless you're a multinational, the EU probably won't care anyway, as you'll fly under the radar, unless you leak customer information. Do that in a sufficiently extravagant way, and they -will- care, but unless you have assets in the EU they can't/won't do anything about it anyway.
> You aren't doing business unless you're accepting payments/selling/shipping things to people in the EU.
This is false.
If you offer a free product and one of the companies you publicly list as a user has a presence in the EU, then you need to be compliant.
If your signup page has been localized to Estonian, you also probably need to be compliant.
"Whereas the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union."
I see multiple comments mentioning this. Do American banks restrict which currencies your credit card can be charged in? As far as I've been able to tell, my bank lets me pay in any currency I'd like, and they will convert the amount to SEK before charging my account.
If dealing with digital products, allow people to purchase without creating an account, or require them to select a country as part of account creation (and prevent those selecting the EU, or don't make it an option). If the bank processes the payment, but you've collected no information, you can't run afoul of the law (since you have no information).
> If the bank processes the payment, but you've collected no information, you can't run afoul of the law (since you have no information).
Don't have server logs with IP addresses? Don't collect an email for the user to use to log in? Don't receive customer support recieve from these users?
> You aren't doing business unless you're accepting payments/selling/shipping things to people in the EU.
I wonder how ads play into all this. E.g. are people who watch an ad on YouTube considered YouTube customers? Are they considered customers of the ad company?
My concern is that we will see more (non-EU) companies implement something where users "pay" for services/features by watching ads. I do also wonder how it then affects the ad companies if they collect personal information about the user. Does the user count as a "customer" if the ad company is the one paying?
The simple answer to that is that the advertisers pay you to show ads to EU users because they want to get money from EU users; so these advertisers are/have to be GDPR compliant, especially if they're using user information to target ads, and they'll have to be sure that this user information is legal for them to use.
The advertising networks are clearly doing business in EU as they're getting paid by these advertisers - so all the major advertising networks will have to be GDPR compliant. So in this regard, the ads (and user info used for these ads) shown to EU users will (in practice) have to be GDPR compliant even if your site doesn't care about it, because everyone who'd want to pay for these ads has to be compliant.
> advertisers pay you to show ads to EU users because they want to get money from EU users; so these advertisers are/have to be GDPR compliant
This is the part I'm not sure is true.
Sure, if the ad agency's company motto is "delivering ads to EU users since XXXX", they obviously have to be compliant, but what if they are a US-based ad agency and none of the companies selling them ad space are in the EU? How many layers does one need to circumvent this?
I'm not talking about ad agencies, but about the actual advertisers. Why would a company buy ad impressions if they're not selling to these users?
Almost every ad I see is from some company that is actually eager to sell stuff to me, so they're doing business in EU, and have to be compliant.
All advertisers who care about me won't be allowed to buy my data from US-based ad agencies, so even if such US-based agencies can gather the data, it's worthless, since noone would buy that.
Geoblocking IPs is not a solution, unless you're willing to let some people slip through and block people who you don't need to block. Also, not everyone connecting from a EU country is a citizen thereof.
GDPR doesn’t just apply to citizens of EU countries, it also applies to residents and potentially people just passing through (e.g. changing flights at an EU hub).
The GDPR applies to transactions with a nexus in the Union. If a US or Chinese traveler books a hotel in Germany, the GDPR protects their data. If a Chinese hotel chain offers a room to a German guest, the GDPR applies to processing of that guest’s data, even if the chain has no other presence in the Union. If that chain stays out of EU data protection agency reach, enforcement is a non-issue. But if Germany and China were to enter a bilateral agreement (as the US will), or if the Chinese hotel chain wants to establish a presence in Europe, then compliance is not optional. Fines are up to 4% of “global turnover”, which is a serious risk to take lightly.
> If that chain stays out of EU data protection agency reach, enforcement is a non-issue. But if Germany and China were to enter a bilateral agreement (as the US will).
this is a very good point actually, GDPR will probably also be used in trade agreements as a requirement, in which the EU has a lot of leverage compared to most other nations/trading blocks across the world.
In the end, the reason the EU can do it is simply because it has enough political leverage to make this happen.
edit: To add to this, I think these kind of things will be good in the long run, especially when the EU starts more trading talks with smaller nations, which are usually very eager to get into a trade agreement with the EU, especially for african nations as it usually allows more ways for legal migration and includes foreign aid a lot of the times.
It's something that basically every big block is trying to do, the US has enforced DMCA and other stuff on other providers as well.
Though in principle, GDPR only covers EU citizens - if you would be selling a product from Australia that exploded upon using it for the first time to an EU citizen, wouldn't you expect EU authorities to go after you as well?
Hmm, if you're selling into the EU, it's EU regulations that you have to follow, not Australian. Maybe we just misunderstood each other, I'm talking about shipping a product to the EU.
> I don't see what sort of authority they'd have to impose this on citizens of other countries.
The authority they have is that delegated by the sovereign members of the EU, and the fact that the authority of a sovereign power is limited only by its own decisions and it's practical capabilities.
(The US also imposes it's ruled extraterritorially when it feels like it.)
I agree but I think a similar question would be: how would this ever be enforced on a US based company/website where it had a EU visitor. I wrote this in another comment but I think outside of just blocking your site in the EU, they would need a further agreement (or I guess precedent) with the US government to actually enforce a penalty on the US company.
> but I think outside of just blocking your site in the EU, they would need a further agreement (or I guess precedent) with the US government to actually enforce a penalty on the US company.
The US has given lots of precedent cases for that. The usual approach the US takes is to force the banks the foreign site is operating with to seize all assets. The EU likely would do the same.
If you have ever opened a bank account in Europe, you have come across a checkbox, where you have to specify that you are not an American citizen. The US pushes their regulations on companies outside their jurisdiction, too.
the result for banking is that European banks refuse to let Americans open bank accounts
depending on the levels enforcement I suspect the same will be true of many popular online services for GDPR: you check the "EU citizen" checkbox and you're banned
What really strikes me is the fact that we spend so many years getting good at remembering things, and now we have to get good at forgetting things. Seems to me that forgetting is way easier than remembering. But I could be wrong.
I can't find a definition of "erasure". Do these count as erasure?:
1) copying a subset of items Y from a set X stored at location A to a new location (e.g. a new disk or another computer) B, then deleting location A (e.g. reformatting disk A)
2) storing all information encrypted with per-person keys, then deleting a person's key
I think the key here is to think of this in obvious terms: can you (easily) recover the data? Are you trying to trick customers/regulators into thinking you got rid of the data, but really have a secret copy for later? Did you make a good-faith effort to comply with the law? If your answers are no, no, and yes, you’ve got nothing to worry about.
Law isn’t, despite what TV would have you believe, a game of pure technicalities (especially outside the US).
This rules out encryption+key-deletion as erasure because while you may not be able to (easily) recover the data, someone with more computing power could (now or in the future)
What about old magnetic disks and tape backups ? Even if you erase them they could possibly be recovered by someone else with the right resources
There literally isn't enough energy in the solar system to run a counter from 0 to 2^256. Computers may still get faster for some time, but in the absence of new cryptographic weaknesses, 256 bit symmetric encryption can be considered to be safe from brute-force attacks forever.
There is some trick using quantum computers that could help, but doubling the key size counters that, putting your encryption beyond the reach of brute-force once again.
What about things explicitly designed in a way that there is no option to be forgotten. What about commits in version control sites? What about mailing lists?
From skimming over the spec, it seems that politicians haven't thought about any other sites than social networks or some other profit making sites. Even in that case, if some ML system is trained on the data of the customer, do they have to re-train after anyone invokes right to be forgotten.
I think more there developers; it is operational burden for companies. GDPR discuss about the lifecycle of customer data and trying to draw boundaries who, how, when, where the user data is going to used.
Our product https://www.StegoSOC.com helps in automating cyber threat detection. That is also one of requirement for GDPR.
How is this law okay with international trade agreements? Why doesn't US say that this (rather fuzzy law) is meant to hurt tech companies which is disproportionally based there? In retaliation couldn't they come up with some law that impacts EU businesses?
It doesn't breach current international trade agreements.
In the long run, however, we'd expect to see international trade agreements attempting to harmonize these requirements worldwide, and likely include some mechanism that makes cross-border enforcement easier.
Either these laws or will be ignored or more and more business will move out of European countries to abide by this law, which Europe really can't afford.
You can make your own decisions about who you want to trust with your data without that law being in place.
The only thing that law does is wall off Europeans from the rest of the world.
This is the just the beginning of "protection" laws from bureaucrats in Brussels. You can believe that these laws are there to "protect you", but the rest of us know better.
Stop letting politicians run your lives, and you'll be better off.
This article is all very well and good, my only concern is that, imagine in a few years someone wants to find the list of all the laws and regulations and frameworks and whatnot that they need to comply with to run a truly international website... where would they find that information?
I think that problem will in some ways solve itself.
Ideally you want to consult with a lawyer to ensure you're in compliance. Certainly that's what we're doing where I work (we have dedicated in-house legal staff dedicated to privacy issues who have been taking point on this), but when you're smaller that can be prohibitively expensive.
Within a couple years, though, I expect any serious commercial or open source platform available that deals with data to have GDPR-related features. It's already starting to happen, and hopefully GDPR compliance won't be something you have to go out of your way to do; it'll just be a normal part of doing business that everyone understands.
The transition period will likely be rocky, and it's my hope that the EU will be initially lenient dealing with honest mistakes that companies work to quickly fix once discovered.
There is a fundamental truth that no one seems to accept.
But it is the truth, and the majority of the planet's ignorance of this fact makes it no less true.
(I am not arguing about what is legal or not, or proposing any illegal behavior, rather just observing that many things legal in the past were absurd/ wrong or still are in certain places on the planet - eg - women not being allowed to drive in certain countries. ie. I repeat, I am not arguing about what is legal or not, I am arguing about the disconnect between reality and the law).
The hard truth:
There is no such thing as privacy - it was just not so apparent until now. I can know whatever I want, you cannot stop me from knowing the color of your shirt, your bank pin, or seeing pictures of you naked if they exist. I am free to know whatever I want, and so is everyone else.
When everyone understands that this is in fact the case, then the world will be a better place.
There are lots of interesting topics and conversations that arise from this (sometimes people call them counter arguments, or try and tell me that what I am calling for is wrong). I am not calling for anything, and I understand the ramifications. But most importantly, I am not talking about how I want to world to operate. I am observing how the world DOES operate. Einstein did not invent relativity (I am not comparing my (probably far far lower) IQ to that of Eintein's like you will deflect to as I use this analogy to get my point across). Einstein merely observed what was there for anyone to observe, and his observation made the world's societies of people a better place (because humanity increased it's understanding of existence).
I repeat privacy is a fallacy. I can and will know whatever I want to know. So will others. Currently people in power have an unfair advantage because they can know anything about anyone and the rest of us go to jail if we also know it. The way to level the playing field is to realize this fact, remove the laws (in theory, that is my proposal, but I don't know how), realize everyone has a naked version, has been bad, can be taken out of context. In the end, the importance of context will return and the novelty of nudity (and all other things (location that abductors can find you, etc) and intimate knowledge will reduce. But we will all be better off because the difference between the person who knows your bank pin and the person who steals your money will be clearly understood.
Currently this is not the case.
My observation is correct. Although you will not agree, and be played as a sucker, continuing to fight for privacy, being ashamed of your past while making yourself more and more at the mercy of the bullies (I mean governments and information curators like wikipedia, fb, twit,goog - they are nothing more than storers of user generated content) that make laws and use them against you.
Another observation that you will dislike me for, but that I ask you to, at the least, just meditate on, repeating in your head a few times, before dismissing it:
Laws are a cheap substitute for understanding.
I really don't think (and I am developer, I will need to comply) that anything in GDPR is hard to understand. Treat data from others in same way as you would treat (and you are treating) yours. You are not selling your personal details to 3rd parties, you are not keeping painfull pictures of yourself climbing to garbage bin and doing diving completely drunk, you are not storing them into pastebin or unsecured databases. You edit them if they are wrong, you delete them if you don't like them. You dont photo yourself if you dont want to be. You change the passwords if you suspect someone stole them. The only thing that GDPR wants from you is to handle others data with same RESPECT as you handle yours.
Every complaint about it shows that you don't respect others and you dont care about them. And this is the reason it became legislation.
If only it was that easy. A reasonable reading of GDPR makes standard web server logs (which contain IP addresses) a punishable offense, even if you don’t have a nexus in Europe.
GDPR is a wonderful idea that will be insanely expensive to comply with, act as a continuous drag on developing new technologies, and end up offering only nominal protection to end users. This is just going to be another way for EU regulators to smack around Google and Facebook. They probably deserve it, but the potential fallout for the rest of us is really going to hurt.
Don’t get me wrong, treating user data with respect is the right thing to do. But we’re all going to be paying for this overly broad and under specified legislation for years to come.
Web logs are not a punishable offence under the GDPR, if you have a legal basis for retaining those logs and reasonable retention and data minimisation policies. If those are in place and you've documented them, you have nothing to worry about.
Why? You have a legitimate interest (one of the six legal bases under the GDPR) to combat fraud and maintain information security. That's the primary reason you have those IPs in your logs in the first place.
If you're using those logs for analytics purposes, things get slightly murkier, but if you're just using IP addresses to enrich your log data with GeoIP, you should be fine. You might even be able to get away with more granular third-party databases, but the more detailed you get, the closer you get to profiling (which is not where you want to be, if you want to minimise your legal fees).
More to the point, I don't understand all this talk about web logs being illegal. If people have collected and processed personal data without thinking about the whys and wherefores, isn't it just a good thing this makes one think about what one is logging and what it's used for? Granted, IP addresses are far from sensitive (depending on your threat model), but I've seen things in technical logs that make me happy about reliable automated retention policies. Also, granted, it's a hassle - that's the price you pay for privacy.
I'd still be glad if nginx et al shipped with more GDPR-compatible defaults.
> If people have collected and processed personal data without thinking about the whys and wherefores, isn't it just a good thing this makes one think about what one is logging and what it's used for
If people are creating software that burns fossil fuels without thinking about the whys wouldn't it be a good thing to have a law that regulates how we use electricity? Shouldn't an EU regulator have input on whether you can release your new blockchain app? You should be fine if its purpose falls into one of the covered categories...
People are creating online communities that enable abuse of members. Do we need statues and regulations to mandate abuse protections in online interactions and punish platforms that allow users to abuse other users?
> If people are creating software that burns fossil fuels
They aren't. Only hardware burns fossil fuels, and computing hardware doesn't inherently do so, for the most part, only if you choose to hook it up to a fossil fuel power plant rather than something else; the software isn't the thing directly to address.
OTOH, the personal data use you are drawing a poor analogy to is the direct point of concern.
I don't want to torture this metaphor any further, but you're kinda proving my point that software developers do not consider the energy and environmental impact of their work. Software that uses significant CPU time uses more electricity and is worse for the environment.
Misuse of personal data is a problem. Wasting electricity is a problem. Online harassment is a problem.
If wasting electricity becomes such a big problem for the society as misuse of personal data already is, sure, let's introduce regulations on that, too.
In some European countries, there are regulations already on how to insulate new buildings to avoid energy waste.
> If wasting electricity becomes such a big problem for the society as misuse of personal data already is, sure, let's introduce regulations on that, too.
Sure, what could go wrong there? Regulator, "We're going to need to look closer at that for-loop to see if it complies. And you do realize that n+1 queries are a violation of EU law?"
Your example is obviously unrealistic, but even when buying it, it rather supports my position. Imagine a regulator indeed pointing out where you can optimize your algorithms and thus save energy, money and achieve faster query processing. What is the problem with that?
Fire safety regulator: "we're going to need to look closer at that door seal glue component to see if it complies...". Nobody complains here about a regulator looking into details.
When stuff like this comes up it always seems so weird to me that with all the work that regulators put into this, why can't they at least scratch the surface of providing some specific examples? Of course there are legal documents, and maybe some "for dummies" versions written up about it.
But would it be so crazy for these regulators to hire someone who knows something about commonly used open source software and building web apps, to help provide a little bit of actionable technical advice? For instance, the majority of the internet is running on Apache or Nginx, why not have an official, EU-sponsored blog post explaining "here's how to set up a LAMP stack, or nginx and rails on a linux server, that complies with GDPR". Of course they can't cover every obscure language or framework, but it would be a starting point. And it would probably end up a lot cheaper than having to investigate and/or penalize people who didn't read the fine print of the law and/or didn't understand how it translates to actually running software.
Because despite how "simple" this post is saying these laws are, there still seems to be quite a bit of confusion on this thread, among smart developers, about questions like whether or not we're allowed to keep collecting webserver logs in the default format or not.
As others have noted: Laws with examples would be to specific to survive fast technological changes. Laws do mostly contain the 'spirit' of the idea and are applicable to many different situations and times.
This is of course no nginx configuration. But the thing is.. there is no one size fits all example configuration. The situation depends on: 1) What do you use the data for? 2) How long do you really need it? 3) Can you securely handle it? 4) Has the user consented?
Saving ip adresses in log files can be fully complaint IF you only use them for legal reasons (sue an attacker, ...), have severe access restrictions on the files, delete them as fast as possible and get consent from the user prior to saving the logs.
It depends on your goal, workflow and abilities if you are allowed to store this data, and you must decide for yourself. If in doubt.. don't store it.
>Saving ip adresses in log files can be fully complaint IF you only use them for legal reasons (sue an attacker, ...), have severe access restrictions on the files, delete them as fast as possible and get consent from the user prior to saving the logs.
You do not need consent for saving the IP, user agent and URL (including GET values) in Apache logs because, as someone said above, you have a "legitimate interest to combat fraud and maintain information security".
Legitimate interest and consent are only 2 of the 6 legal bases under which you can collect and store (process) personal data. Art. 6 contains all 6 https://gdpr-info.eu/art-6-gdpr/ .
> When stuff like this comes up it always seems so weird to me that with all the work that regulators put into this, why can't they at least scratch the surface of providing some specific examples?
Technology is something which constantly changes. From the point of view of the legislator, legal text that is too concrete will stagnate innovation and progress by "locking" people into current technological assumptions. The text becomes inappropriate/outdated when the next wave of technologies come along.
Thus legislators try to document the spirit behind a legislation and try to stay away from concrete implementation details as much as possible, in order to give people maximum freedom to decide how they should implement things, and maximum freedom in technology choices.
So yes, to us implementors it is a hassle because we have no idea what we should concretely do. But we can also see this as freedom to explore how to best implement an idea.
I expect that in the next few months/years, domain experts such as us will debate and decide on implementation best practices.
That doesn't work though. Sure, if it was some industry initiative then a broad statement of intent and people figure out the details as they go would be OK.
But this one comes with massive, company destroying fines attached.
If you and other domain experts debate and decide on a best practice, and then some EU commissioner disagrees and destroys your company with a fine you cannot pay, will you be so sure that vague laws are a good idea then? Will it seem like freedom to explore, or will it seem more like walking through a minefield?
The EU wants to regulate the precise details of data handling in software firms. It can do that. But it's trying to have its cake and eat it - micromanaging the tech industry at the same time as refusing to be precise about what it wants. It just expects everyone to intuit what they want, on pain of corporate death if you fail.
They are not company destroying for large companies though. By raising fixed cost (and risk) of doing business, regulations of this kind are an absolute godsend for large companies.
Ask your chat provider if he is GDPR compliant, he will provide you the confirmations that you need to add to your page. Regarding google analytics, you are risking getting banned if you feed it with personal data (including ip).
If I were you, I would add my own chat (there is bunch of them on github) and use piwik instead of google analytics.
(By the rule of the thumb, for each 3rd party provider, ask them about gdpr compliancy and purge all the data you are not getting user consent - GDPR is retroactive)
There are several grounds on which you can legally process data in addition to consent, so it is unhelpful to talk in general terms about purging data where you are not getting user consent. If you are using data to provide a service, then generally it will not a consent-based processing for example.
You have to assess each use to which you put any personal data and determine the correct processing basis for that usage. Often there are more relevant bases than consent.
I do appreciate that the definition of 'consent' in this regard is often thought of in different terms though. When I think of consent I think of the narrow data protection consent, whereas I think often in layman's terms it has a broader definition which is often linked to disclosure requirements in relation to privacy policies etc.
> But would it be so crazy for these regulators to hire someone...to help provide a little bit of actionable technical advice?
Didn't you know? They do. Large corporations are always happy to help regulators write laws in such a way as to benefit them to fend of those pesky innovators. [1] Raising compliance costs as high as possible is highly desired by large companies.
> This is just going to be another way for EU regulators to smack around Google and Facebook.
Actually, it's more like a giant gift to Google and Facebook: GDPR borders on regulatory capture, with only the giants really having the resources to comply properly. This will hurt startups and smaller firms far more than it will the big dogs with their armies of compliance lawyers.
I lack legal experties, but I'd assume you will easily be able to sue any company and claim they infringe somehow on your rights as stated by this GDPR; maybe I'm wrong.
I attended a GCP event and I could practically see the hipsters pupils dilate/mouth foaming as they went in the hisper frenzy "this GDPR is a huuuge opportunity".
You can write a complaint to responsible institutions that then chose how to act (send a warning to violating company, issue them fine, start an investigation etc.) You cannot sue companies yourself, unless you can prove that (big) damage was done to you as a direct consequence of violation, then you can seek compensation via civil lawsuit.
Only without consent from the user. Previously it was an ethically grey area to be logging IP addresses anyway. If you are preventing malicious use, then that is allowed as long as you are not using that data outside of the bounds of the user's consent.
If, however, a company is storing IP addresses to identify users without their consent and are found to be specifically targeting them without their consent, then that is a misuse of data.
You are right that companies will be paying for this for a long time and it does take effort to comply, but if that's what it takes to protect user data, increase security across the board to prevent data breaches and kill off the players that never should be in the business to begin with then I'm all for it.
You appear to be suggesting that "intent" defines the shape of law here, but I really don't think that's the case.
By my reading, information becomes personal —and therefore subject to GDPR— when it can be used to identify people. If you've got login timestamps, IP addresses and user records, for legitimate reasons, any other logging that includes IPs is tainted because it takes anybody with that data two minutes to munge them together.
Intent, and actual business use-case play second fiddle to the worst-case, or "what could that data be used for?".
Worst case usage determines what information is subject to GDPR, but actual business use-case is what determines what data you are allowed to collect.
IP addresses are subject to GDPR, but that just means that you have to have either a legitimate business need for keeping them or to have the user's consent to keep them and you need to disclose to the user that you are keeping them and for how long.
You probably do have a legitimate need to keep IP address logs for some period of time to allow troubleshooting and possibly for a longer period of time to allow for fraud detection. As long as you are disclosing to the user that you are collecting that information and are abiding by the retention period that you are disclosing to users, then you will be allowed to collect logs of IP addresses.
Your intention and how you actually use the data are critical to an entity's compliance with the GDPR. If I am only using IP addresses for legitimate purposes of monitoring/protecting my network then that is very different to using IP addresses to assist in my tracking of users for advertising purposes for example.
The classification of data of personal data is likely beyond dispute but you are then under obligations on how you actually make use of that data.
Entities should have in place relevant protective measures to ensure that if you have only collected data for a limited purpose, it should not be used for purposes beyond that.
In my experience of having lived all my life in the EU and mostly in 3 countries of the union, all law enforcement here is about intent, unlike the US for instance (as far as I read online ofcourse, like the Nintendo copyright case linked here a week ago). Copyright, drugs, bankrupting your company etc, judges look at intent not literally what the law says. So this will not be different. Nothing will change if you are not trying to actually go against what the law intents to protect.
Mens rea (i.e. intent) is part of common law criminality (along with actus reus, which is the actual doing of something illegal). The United States, having its legal system derived from that of England’s (and thus being a common law legal system), absolutely requires intent when considering whether or not someone or some organization has committed a crime.
I’m not familiar with the referenced Nintendo case, but mens rea is usually only considered in criminal cases. Unless you’re prosecuting someone for illegally downloading copyrighted material or some such thing, intent wouldn’t be considered (it can increase liability in civil cases, though).
Now that you mention it; I do see it in crime shows. But the case I mentioned was about if a Nintendo modchip could be used for good or only for evil according to the EU while the US court just yelled copyright infringement and put some hacker in jail. Those are the cases we read about in the press over here and most people find it ridiculous over here to go to jail (aka ruin lives) over something as small as copyright infringement. Courts agree as they usually mostly slap on a fine based on the intent.
And it even gets more interesting: The question is not if you can identify a user by merging your different data sets. The question is if you can identify a user if you merge one of your data sets with any other data set, even if this set is currently not in your possession. (This can happen if the provider is able to mach IP addresses to personal information.)
Intent comes into play when you determine the appropriate processing basis; for eg preventing abuse, the basis isn't consent and therefore consent is not required. So GP is partially wrong. If your intent is to use the data for marketing purposes, then you are much more likely to require consent. See LI balancing tests.
Leaving the last three digits out of logs gives you all the information you might need without making it possible to tie it back to a specific user. Google Analytics actually has an option for that.
IP logging is not ethically ambiguous in any way. It's 100% okay. You chose to connect to that IP. If you don't want your IP logged don't send an IP packet to that address. It's very simple.
This is beyond ridiculous. The entitlement I see here is cancerous in the literal sense.
Holy shit can't you read up before complaining without knowing the details? There is the exception that you may use and store data that is necessary for providing the service. Thus, since ip is necessary for talking to a server, you don't need to explicitly ask for consent. However you MUST NOT do anything else with that IP, like logging it for longer than necessary or tracking users across sites (without consent).
Why do you need to log ip? To prevent abuse? That's ok. For how long? That's up do you to decide, but it must be motivated and documented.
What's so hard to understand? How is this not perfectly reasonable already? Why are you entitled to not respect other's personal data?
Because 1) your analogy is off. People forget, a machine does not 2) GDPR is about privacy; tracking people's behaviour, linking things together without explicit consent is not allowed according to GDPR.
1. If I am writing it down, as my analogy suggests, it is not forgotten.
2. I understand what it's about.
If you want to make tracking people and linking things together illegal, great.
However, my argument in response to the OP intended to illustrate that recording information about someones actions, particularly when it's a party who is part of the interaction creating the recording, does not seem to have some preexisting moral expectation or attached to it.
Hence, to me at least, the GDPR's directives are not objectively reasonable or obvious in some way as suggested by the OP.
I also think forbidding certain uses of the data is more reasonable than to regulate its collection and storage. But yes, that's probably riskier and harder to enforce.
It's ok to take a picture of the street out of your front window
It's not ok to take a picture of everyone that walks in front of your house, timestamped and on top of that you search their picture on Facebook (supposing you could do that) and keep all that info forever
> It's not ok to take a picture of everyone that walks in front of your house, timestamped and on top of that you search their picture on Facebook (supposing you could do that) and keep all that info forever
Why not? It's certainly not obvious why this is the case.
I guess that's a fair question. Two reasons come to mind:
1. If the by-passers where to discover what you've done they might feel violated. This is why there are laws against stalking. Thus in this example it would be all about intent.
2. What if your database leaks? Have you considered that event, the probability of it happening, and the impact? How can you minimize the risk? Is it encrypted? How long do you need to store it for? Can it be anonymized? Do you even need to look up name? Is the potential privacy intrusion proportional to the purpose of collecting the data?
To be GDPR-compliant you must have answered all those questions and documented it.
The EU is very consumer protection focused, which is very different from the US. It's just a point of view I don't see how you can perceive it as entitlement. Not everyone knows how privacy works and how much data is available by not using a VPN.
Keeping a log of visitors to your own computing resources is an ethical grey area since when? IP Addresses themselves are most useful for deanonymization/violating privacy when shared across organizations, or converted to accounts from ISPs. Why does GDPR target the storage of them and not the sharing or conversion of this type of data?
One other interesting thing to keep in mind is that GDPR does not exempt public, government organisations. It will be interesting to see what happens with that, if anything.
Standard server logs with IP addresses must be disclosed in a privacy policy but you do not have to seek consent for them because you collect them as part of a business critical need to prevent fraud. See Recital 47, which includes the language: "The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned." https://www.privacy-regulation.eu/en/r47.htm
The user can request I delete all of the data related to them without “undue delay”. Are you ready to purge all references to certain IP addresses in your logs? Don’t forget backups.
GDPR blows up a lot of assumptions we make about writing software and managing servers.
Again, you do not have to if is business critical and used for fraud prevention. You must routinely delete logs before they get too old (60-90 days maybe), but you do not need to take special action beyond that. I’m not saying the GDPR isn’t troublesome, but having spent the better part of the last 6 months combing through the law and interpretations of it, I think the concern over IP addresses in log files that can be used for security and fraud-prevention is unfounded. Data portability requests are likely where it will get onerous and expensive. Even with those, there is flexibility build in to prevent users from repeatedly requesting their data at short intervals.
I believe that you're okay in that case. Some countries in the EU require that you have financial records stored for five years, and they will always contain personal identifiable information. The GDPR states, if I recall correctly, that because some other law requires you to store the information for X number of years, the customer can't force you to delete it.
Similarly credit agencies aren't required to comply with deletion requests either. You can't simply GDPR your way out of a bad credit score.
But it's a total mess, when you read the GDPR it's clear that it's written by people with limited understanding of IT. Of cause it has to be extremely strict, otherwise you'll end up with a Cookie-law 2.0. The cookie law from the EU was read by the industry in a way that clearly wasn't intended. It made zero different to user tracking, we just got a bunch of pop-ups stating that the site uses Cookie. If you read that law as I believe it was intended, the idea would be that you could say yes to cookies or no. If you choose no, the site would disable the use of tracking cookies. But was to much work, so people just slapped a cookie pop-up on their sites.
The cookie law was never well thought out, that's why nobody read it in the way it was "intended" (what was the intent anyway). The distinction between a regular cookie and a tracking cookie doesn't exist except in the minds of the EU regulators, so no surprise that all they achieved with this was making the EU web experience horrible by default instead of opt-in horrible - browsers have let you request notification of cookies being set since forever, after all, and you can create extensions to notify you in whatever way you like.
Thanks for the clarification. This is definitely going to make lawyers rich and make it much harder to startup. The legal cost overhead benefits the establishment at the cost of startups and SMEs
Data portability is no more work than a SAR. Nothing says you have to give them the data in a convenient format; you can perfectly well hand a pg or mysql dump to them that is nothing more than the unformatted output of your SAR process and call it a day. In particular, it doesn't have to be convenient at all to do data interchange; it just has to be "structured, commonly-used and machine-readable format."
I wouldn’t worry about individuals requesting access or deletion of the Apache logs concerning a certain IP as I see no possible solution for the “reasonable measure to verify the identity of a data subject” against an IPv4 IP and, as per the GDPR, providing data to the wrong person could “affect the rights and freedoms of others” in which case you shouldn’t provide the data.
Look at the paragraph you're quoting - you have to comply with the request if "one of the following applies", which means:
1) if you have a legitimate reason that allows you to process the data without consent (which would be the expected scenario; if not, then any sane organization would likely just choose to don't have that data in their logs at all), then none of the following applies, and you can refuse the request;
2) if you had a legitimate reason but "the personal data are no longer necessary", then you must comply.... but that's just duplication, you should not have had that data anymore since if you're compliant, you should have cleared the data out already. E.g. if you believe that you need (and are allowed) to store data for 6 months for purpose X; then you'd ignore the request for 5 month old data as you need it, and ignore the request for 7 month old data as you already purged it as a routine operation.
3) if you didn't have a legitimate reason and actually needed consent, then you follow the same process as you do for scrubbing references to all IP addresses which didn't give you consent. If you're compliant with the other requirements (which is tricky in this case), then the deletion request doesn't add anything meaningfully different.
The user can request whatever. If you are processing the data via consent, you have to obey. If you processing the data under a different basis, then you may well not; you have to figure out. I hope you like paying lawyers!
Of all the wonderful things that we're capable of as technologists, I think we can figure out a way to strip raw-IP addresses from log-files once we don't need them any more.
I'll need to figure out to handle this on the data I'm responsible for at the moment. It's boring and it doesn't help the product, but it's not supposed to. In idlewords' terms, I feel like I'm finally purging toxic waste: http://idlewords.com/talks/haunted_by_data.htm
It's left ambiguous, but it's likely that any aggregate computed from personal data may also be considered personal data (i.e. how many unique IPs you've seen).
If you are looking to derive aggregated insights from data then you need to be clear on your anonymisation processes and understand whether or not you any derived dataset is capable of identifying individuals whether in isolation or through reasonable means. To me if you are taking a tally of the volume of unique IPs alone that would never be sufficient to identify a person but maybe I don't have the full context?
What you're saying makes sense. Any data derived from PII should considered as PII itself if it can be used to identify users, and even if it cannot be used for that, it needs to be cleared frequently enough such that you don't end up with data derived from information for which you received a deletion request, for instance.
In practice, you can achieve this by simply refreshing your derived data frequently (ever ~30-60 days), and for aggregated data k-anonymity is a good way to enforce this privacy constraint.
Also, you can keep just a hash(seed + IP address) - enough to uniquely identify user session (so you can debug possible problems) but not enough to pinpoint a specific user.
Of course in reality nothing is that simple, but it can be done, and it can be done automatically. I am sure there will be GDPR nginx plugins/configs available soon.
Unless you use IPv6 hashing IPv4 address space is way, way too narrow. Hash+seed is trivial to have the original IP recovered
So whoever advises that got no idea how hashing (and collision of the latter) works.
(Brute force of few billion hashes in the days of crypto currencies is a walk in the park)
> A reasonable reading of GDPR makes standard web server logs (which contain IP addresses) a punishable offense, even if you don’t have a nexus in Europe.
IP addresses are deemed personally identifiable information. All web servers log these by default - before asking users for permission to do so - and are therefore, bafflingly, about to become illegal.
How does this work out for Git repos and other things with encryption backed histories? If I run a software project and a developer wants an identifying section of a repo back-edited, do I have to edit and rebase the whole repo, and what does this do to the trust in a project that is based on a verifiable history?
Also, I can't help but notice that currently there is a hell of a lot of money being bet on immutable public ledgers.
> Also, I can't help but notice that currently there is a hell of a lot of money being bet on immutable public ledgers.
I've been pondering the same thing. You have to be extremely careful about building a new product on blockchain technology, because, depending on what you're building, you may be required to delete stuff from it in the future.
Source repositories in many (most?) companies include the full names of the employees who authored every particular commit. This is PII. GDPR refers to all personal information you're handling, not excluding information of your employees.
Also, looking up, you can undo a rebase with reflog, so even editing commits with an interactive rebase may not be enough to purge a git repo of identifiable information that people have entered.
But you generally cannot build a system that intentionally does not have a certain capability and then successfully claim that laws don‘t apply to you, because your beautiful system does not accomodate them.
If this is an opern source repo on GitHub/GitLab, I think you could argue that the developer "made the data public" in giving it to you in the first place. That's an exception to the requirement to delete data. The same goes for public ledgers.
The tricky situation is when someone puts personal data not about themselves, but about a third party into a public ledger...
I've been reading through the text of the act, and while there is an exception allowing you to process data that has been made explicitly public by the person it relates to without asking them for permission, it seems to indicate that you still have to give them the ability to edit it later.
AS per the GDPR I see no possible solution for the “reasonable measure to verify the identity of a data subject” against an IPv4 IP and thus to reliably act on IPv4 related data subject access/deletion requests.
Also per the GDPR, providing data to the wrong person could “affect the rights and freedoms of others” in which case you shouldn’t provide the data.
> a continuous drag on developing new technologies
Any and all of them? Because of anonymized IP addresses in server logs? I wouldn't even buy that when it comes to the web, but certainly not to mention talking about computers and software in general, or even "tech in general", whatever that would be.
What's an anonymized IP address? As others have pointed out, there is a sufficiently small number of IP (v4) addresses that any hash function output of them can be easily brute-forced nowadays. So the only 'anonymous' IP address is the one you never collect in the first place.
In principle, yes. The intention behind and the principles outlined by the GDPR are good.
However, the devil's in the details, specifically in how these principles are supposed to be implemented. Some of these details are not quite clear yet. It's almost impossible to navigate these issues without getting at least some basic legal advice and investing a fair bit of time.
Unfortunately, as often is the case with EU regulations these seem to be targeted mainly at larger companies or corporations, which can easily afford this because they have legal departments anyway.
As a company that uses third-party services for data processing (which includes almost every piece of SaaS-type software) you have to sign a data processing agreement with each of those, which can mean considerable effort.
Some suppliers unfortunately are not as well-prepared yet as they should be.
Therefore now a company's processes continuing to run smoothly might depend on some third party getting their internal affairs in order. It's true they should've done this long before and one shouldn't continue to work with them if they fail to do so. Still, it's a problem you have to deal with.
I agree that GDPR makes sense and it's a good idea to follow through with these measures. It won't be easy in each and every case though and it might be a bumpy ride at first, which is why I sincerely hope that in the beginning authorities will be lenient with parties that act in good faith.
> As a company that uses third-party services for data processing (which includes almost every piece of SaaS-type software) you have to sign a data processing agreement with each of those, which can mean considerable effort.
At least for SaaS it's pretty clear-cut. For freelancers, contractors and consultants the situation is way more confused.
AFAICT I need a data processing agreement with every client, even if I only log into their servers once a month to update WordPress and check their logs, because I am now deemed to be processing personal information.
These details need talking about, and I've yet to see industry bodies doing so.
IMHO it simply requires companies to make a clear choice.
Either they have the organizational capacity to handle private information properly, or they should not do it at all.
There's no reason for every company to get a data processing agreement with every SaaS they use as long as they're not putting private data of other people inside; and in most cases (except CRM and payment systems) they should not do so. There's no reason for every random company to get a data processing agreement with the contractor maintaining their WordPress site if that site doesn't contain any private information, and it probably should not. On the other hand, if it does, then giving full access to that data should be more difficult than simply giving the keys to a random contractor; the company is fully responsible for whatever you do ("Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject."), so that includes vetting you, being able to supervise what you've done, and probably some liability requirement. On the other hand, if that's a standard service you're providing, it all means that your standard agreement form just needs a few extra paragraphs to cover that data processing part.
The log/IP address issue has technical solutions - you can use logrotate in combination with gnupg to ensure that logs are available if you need to analyze them, but are encrypted and not available to everyone logging on that server.
"Either they have the organizational capacity to handle private information properly, or they should not do it at all."
While I admire the intent here, in the world at large it seems that multinationals and governments fail at this one with monotonous regularity and Blanche's final line - 'Whoever you are, I have always depended on the kindness of strangers', has been adopted by the computer security industry as the unofficial motto.
What I've seen from the world at large is not large multinationals failing at handling private information properly, but rather them not trying to handle private information properly. I.e. it's not because they're incapable of doing so if they wanted, but that they didn't even attempt to do so. GDPR is a way of forcing some of them to stop handling the information, and forcing those who do to actually start trying.
And what happens when anything of that changes in scope? You gonna resend the consent form to each and every past user?
Of corse not. What will happen instead is that behind a consent box a lengthy disclaimer will ask consent for every piece of information and blanket every length of scope, triggering a cascade across providers and contractors.
No it will not. For consent it is explicitly forbiden to use legal / technical speech and you can't cascade it. Allowing you to use my data has nothing to do with you giving my data to google. The more 3rd party "providers" the more fishy will your site look. And you can bet the user wont give consent for 100 tick boxes - you can't pretick them, it needs to be opt-in.
Many of the things listed above (legal requirements, etc) don't actually require consent, so they have different criteria - in essence, Paypal just needs to clearly inform the user what they're doing. Consent is just one of six criteria that may allow you to use private data; the actually necessary (as opposed to merely desirable/profitable) use cases of the data fall under one of the other criteria and don't require obtaining consent.
Consent is mostly relevant to all the marketing and customer analysis activities, which aren't essential to the service, so can be refused, and would be severely curtailed as users stop consenting to these uses of their data.
Check it a little bit better, grep for "market". Google? Facebook (i dont have FB account, never had!)? I can hardly wait to NOT tick those and demand view of shared data.
They are already profiting from the service they provide but they still give (Sell! I bet they can use a different terminology but essentially this is it) the users data to other companies.
Those are the companies that brought GDPR on all of us, and those are the parties that should be punished with 4% global revenue, multiple times.
I bet everyone will be shocked what the companies are doing with our data, from our banks, credit card companies, insurance companies,... i think that everyone (or most) will stop complaining about GDPR and want it for their country too.
Just an example, what gets delivered just for Facebook:
"Advertising ID and device ID to segment user groups based on app behaviour, encrypted e-mail address associated with PayPal users (without indicating account relationship), IP Address, Anonymous ID generated by cookies, pixel tags or similar technologies embedded in webpages, ads and emails delivered to users. Mobile advertiser ID, IP Address and other metadata via Facebook SDK in mobile apps."
Encrypted e-mail address? Why encrypted, not hashed? IP? Why the FB needs my IP on connecting to paypal? And the list goes on and on. If GDPR will stop this the whole world will benefit.
Can you elaborate about what exactly do you mean by "anything of that changes in scope"?
If you have the same use case of private data but have technical changes (i.e. a different subcontractor handling the processing) then you do not need a new consent.
If you have a new use case, then yes, you get to use only the data of those users who agree to it. Which will not be all users anyway, as consent must be freely given, i.e. with an opportunity to refuse consent but keep the service.
The expected result of "a consent box a lengthy disclaimer will ask consent for every piece of information and blanket every length of scope" would be the TL;DR reaction - since all of that must be opt-in, the user would just click "Continue", keeping the default settings that don't give you any consent.
> If you have the same use case of private data but have technical changes (i.e. a different subcontractor handling the processing) then you do not need a new consent.
That is not how some are reading it. It's not how I've understood Article 28(2) either, though getting new consent each time is nuts (e.g. I change from Mailgun to Postmark and have to ask all SaaS customers for consent).
Ah, okay, I was more focused on the user-controller relationship and not on the controller-processor deal.
If a company legally holding private data (i.e. a controller) gets a different subcontractor (a processor), they do not need new consent from the user; and the controller is still fully responsible for the data privacy.
In your example, you're a processor who operates the data with controller's authorization (let's avoid the word "consent"; this is a quite specific term in context of GDPR with a different meaning) - and they are responsible for ensuring that you will safeguard this data properly, so they can't transfer data to you if they don't have solid guarantees about what you'll do and not do with the data they're responsible for.
And the particular situation seems reasonable to me. You do not need to ask all SaaS customers for some action; as your links directly quote ".. or general written authorisation of the controller" i.e. your agreement can specify (if your customers are okay with that) that you're allowed to use other processors and change them. You do have to inform them about such changes (just as you informed them about the current subcontractors touching their data before they signed up, right?). If you change from Mailgun to Postmark, all you have to do is to send a notification to all your SaaS customers, and nobody is going to cancel over that. On the other hand, if you change from Mailgun to NigerianPrinceMailings Inc., then they might reasonably want to decline, so that's why the notification is required.
> That is not how some are reading it. It's not how I've understood Article 28(2) either, though getting new consent each time is nuts (e.g. I change from Mailgun to Postmark and have to ask all SaaS customers for consent).
This makes sense from the user's perspective. Maybe they trust Mailgun but do not trust Postmark. If they have explicitly agreed to you sharing their personal data with one company you shouldn't be able to start sending that customer's personal data to another company without their consent.
If you sign up for my service and I ask for consent to send specific data to SecuriCo for "user analytics and tracking" I shouldn't be able to change that to sending the data to the NSA without telling you. The whole point is that the user should be in control of what businesses are doing with their personal information.
OPs point is that if you act responsibly in good faith you'll probably avoid any issues, and likely be warned before they target you for maximum fines :)
I hope so. Unfortunately, that won't necessarily be the case.
Small businesses have been specifically and routinely targeted by dubious law firms for not complying with certain regulations like legal notice requirements or disclaimers on websites.
The EU and local as well as member state authorities also often are oblivious to problems smaller companies might have.
That's heavily dependent on the regulator in question, and there's 30-ish of them. Since American companies are very unlikely to have a lead regulator, you will need to comply with conflicting rulings from each. In half a dozen languages.
You will need to have a lead regulator (or I suppose a Privacy Shield listing while that is still legal) if you are doing significant business with EU data subjects’ personal data. See recital 80 and article 31 of the GDPR.
> Every complaint about it shows that you don't respect others and you dont care about them. And this is the reason it became legislation.
Ok, that is just silly. This sounds so much like the 'Why do you want privacy if you have nothing to hide?' arguments. It is very reasonable to both have a company that handle customer data responsibly AND have issues with the GDPR.
Imagine if every time you walked down the street, the police stopped you and made you prove that you hadn't murdered anyone that day. You might get get annoyed at the 10 minutes it takes to prove our innocence. If you complained about the extra time and intrusion, would a fair response be "Every complaint about this check shows you don't care about murder"
No, you can both agree with a goal of a regulation and disagree with the mechanism that they implement it. It is certainly NOT the case that 'the only thing GDPR wants from you is to handle others data with the same RESPECT as you handle yours'... they want you to DEMONSTRATE this in a particular manner. Those particulars are important, and we can disagree on them without it being some sort of moral conflict.
If my web app can kill you, sure we should add regulations that I have to follow and prove that I am following.
That is beside the point, though; I wasn't saying regulations were wrong, just that it is unfair to say "If you don't like this particular regulation than you don't care about customers"
That is wrong. You can disagree with how a regulation is implemented and still agree with the idea of having a regulation.
If my web app can kill you, sure we should add regulations that I have to follow and prove that I am following.
The Ashley Madison leak has been linked to at least one suicide. But in any case, even if your data can't gravely harm someone by itself, it can when it's linked with other datasets. As the U.S. Privacy Protection Study Commission presciently wrote in their 1977 report,
"The real danger is the gradual erosion of individual liberties through the automation, integration, and interconnection of many small, separate record-keeping systems, each of which alone may seem innocuous, even benevolent, and wholly justifiable."
Actually, you don't need to do that proof. The construction plans need to be signed off on by certified (government-accredited but still fully private practice, not even necessarily a different company) engineer. But the government doesn't look at those plans and check your work.
What happens instead is that you need to be inspected by the government before it's allowed to be occupied or put into use. And if it ever should happen that it does collapse, then the structural engineer who signs off on the plans faces criminal liability particularly in extreme cases (Kansas City Hyatt is the most memorable experience).
Sentiments like yours are the reason why GDPR is problematic. One of the things that legal experts quickly realize is that there are as many definitions of common sense as there are people in the room. As this thread shows in great detail, there is wide variation in understanding what it's meant to cover. The real problem is that the regulatory agencies, in response to this confusion, are essentially refusing to issue any clarifications in guidelines. The GDPR is at risk of becoming a law that says "You have to follow my rules, but I'm not going to tell you what they are," which is counterproductive to its own ends.
Not really true :) $20mil or 4% global revenue whichever is higher. $20mil is nothing for ggl/fb/...
This time EU did it right, I doubt some small local shop will ever get max punishment but the % of global revenue is on the other side still something that can bite global corporations.
Could you elaborate on how this is a restriction on freedom of speech? How is an 'information site' affected? Take HN for example, when I signed up they didn't even ask my name. They probably log IP addresses and would be entitled to, for the purposes of analyzing malicious use.
It's all PII. People post personal details about their lives here, some use their real names as their username, the site asks for email addresses, how is it not PII?
As for IPs. Any website could claim they need IP addresses for analyzing malicious use. So either it'll be a new cookie law in which they all use the vagueness of the new rules to loophole themselves out, or the EU will decide that this is only "reasonable" sometimes. The law effectively says nothing so whether or not HN would be entitled to store this data is essentially undefined.
Here's what will really happen to HN - nothing. But Google will get huge fines for doing exactly the same thing, and everyone will be left wondering if they're next.
> People post personal details about their lives here
Which they explicitly choose to do
> some use their real names as their username
Which is not required to use the site
> the site asks for email addresses
But you don't have to give one. If you do give one it is only used for password resets. Write that in your privacy policy and keep the email safe.
> Any website could claim they need IP addresses for analyzing malicious use
Yes they can, and the law allows it. Don't sell them to data aggregators and put it in your privacy policy why you are keeping it. If you don't want to then send the logs to /dev/null
> or the EU will decide
The courts will decide.
> The law effectively says nothing so whether or not HN would be entitled to store this data is essentially undefined.
What do you want from the EU? A law that references the internet protocol explicitly, and every possible use of it? What happens when the protocol changes, or someone invents a new protocol, or a new way of exploiting it? Pass another law that says the same thing? Laws in the EU are generally principle based for exactly this reason, they age much better.
The company from PA (USA) needs a EU VAT number to operate in the EU... The VAT registration would be revoked in the specific member state where it was issued.
If there is a tax agreement between a specific member state (EU) and the US, IRS can show interest in Joe.
If there are like a thousand sales in a specific member state (the taxation is not EU wide global), no one will show interested, so if Joe is small - it's very likely Joe is safe.
Operating w/o the VAT could also spring money laundering interests -- the institutions concerned with anti-money-laundering cases tend to have rather long reach.
No, it does not. A company in PA, USA does not give two cents about EU VAT. It charges EU customers in the US and provides services in the US and tells EU to shove it. Actually, it does not even do that. It simply ignores everything that EU does.
Like I've said if you are small enough to avoid any interest, it's ok - but selling electronic services to EU residents without VAT in the EU is not legal.
Overall VAT is taxation on the consumption, the consumption is within the EU member state, the state receives the tax.
Summary:
When US companies encounter European VAT: When doing business in the territory of the EU a company will deal with VAT: when selling something, the company will have to charge the customer with VAT... [0]
Also: The EU’s VAT law considers everything that is not a good (generally a tangible property) as a service. Services can include everything from the licensing for intellectual property to downloadable software to consulting – to name but a few examples. The VAT requirements for services depend on the final customer
U.S. Foreign Commercial Services for U.S. Companies [1], [2]
This is not at all what I’ve encountered at several jobs, and the auditors have confirmed.
The VAT structure in the EU is the responsibility of the EU. An EU customer buying something or some service in USD from a US company with no presence in the EU is responsible for handling their own tax liability with the EU.
Conversely, I have bought many items and services online from EU companies who don’t have presence in the USA. Not one has charged me VAT nor the local “use tax” the People’s Republic of Chicago charges for internet-based services.
In short, my experience is you’re just plain wrong. A bunch of expensive and competent accountants hired by my various employers agree that you’re wrong.
>The VAT structure in the EU is the responsibility of the EU. An EU customer buying something or some service in USD from a US company with no presence in the EU is responsible for handling their own tax liability with the EU.
If you import goods (receive them via mail), there is a customs clearance required + VAT for prices over N euro (where N varies on the country but usually less than 25e). Indeed that's a direct responsibility of the receiver.
>Not one has charged me VAT nor the local “use tax” the People’s Republic of Chicago charges for internet-based services.
Please don't mix the laws in different jurisdictions. VAT is quite different than sale/use tax. Try and buy goods from USA (even ebay suffices) and receive it within the EU w/o paying VAT (unless explicitly exempt from the tax)
Electronic services have no customs clearance or physical presence and what I explained above (VAT number, etc.) applies.
>A bunch of expensive and competent accountants hired by my various employers agree that you’re wrong.
Proof by authority ain't cool. VAT does apply to the end user (companies can receive it back, etc.), so I am unaware if your employers used to sell to end users directly. If selling services was that easy, registering outside EU would so temping as pricing ~20% less would be great. As proof goes: I consulted an accountant about US offered services to a local EU member state. (didn't have to pay anything)
Examples of not being able to sell services to US residents are forex and gambling. Non-US companies practically can not take US customers. Selling services online ain't that easy even to US.
> Like I've said if you are small enough to avoid any interest, it's ok - but selling electronic services to EU residents without VAT in the EU is not legal.
You are confused. Selling services to EU residents without VAT is perfectly fine if the company has no nexus to EU. Just like it is perfectly fine for a company that has no nexus to the United States to sell services to residents of New York City without collecting NYC sales tax. Not only is this done all the time, it is a standard tax minimization strategy peddled by the likes of DT and BDO.
It's HipNewStartupLLC in Delaware that's got more to worry about. VCs will want growth, and at the start things go up. Then they want to expand to the EU, and they've hit the road block.
Maybe they can do that, but that would require piercing corporate veil first which is costly. JoeSchmoeLLC is probably judgement proof. Any attempt to force it to comply would cost a boat load of money.
However, it is a lot more likely that the LLC is owned by those with no nexus to Europe it is extremely unlikely that EU can do anything to punish this company. Hell 99% of web forums have European users.
Maybe it will have teeth against Google/Facebook/Tinder/Match/etc because those companies actually have assets in Europe but it won't be effective against companies with no nexus.
Not really a problem for EU if JoeSchmoeLLC is really treating this as not a law for them. US and pretty much every country in the EU have excellent extradition agreements. [0]
Can you point me to a definitive source as to what websites that have access log that include IP addresses (which is pretty much everyone) have to do to be compliant? If there are steps that must be taken, who has to taken them?
I've been looking, and I have found a bunch of contradictory explanations. My best guess is that if you have a disclaimer that says you log IP addresses for security purposes, you can keep your access logs indefinitely. (see: https://community.spiceworks.com/topic/2041760-access-logs-i...)
This seems like the sort of concern that should be clearly addressed with an official answer before the regulation takes effect.
Backups of various kinds are in a similar position.
The reason GDPR is a bad law is that its real effect is so ambiguous.
Read literally, it imposes significant burdens on data controllers, particularly because of things like the right to erasure. Those burdens may be disproportionate particularly for smaller organisations that only handle a limited amount of data in the first place.
The alternative, which I've noticed GDPR's defenders tend to favour as understanding has grown, is something to the effect that regulators won't actually enforce the rules in a draconian fashion and will only go after serious infringement in practice. But that's a dangerous position to adopt in legal matters, because ultimately it means if you go too far in complying when others don't then you are at a disadvantage, but if you don't go far enough then you are subject to being punished at any time, and there is no objective standard for how far we're talking about either way.
> The alternative, which I've noticed GDPR's defenders tend to favour as understanding has grown, is something to the effect that regulators won't actually enforce the rules in a draconian fashion and will only go after serious infringement in practice. But that's a dangerous position to adopt in legal matters, because ultimately it means if you go too far in complying when others don't then you are at a disadvantage, but if you don't go far enough then you are subject to being punished at any time, and there is no objective standard for how far we're talking about either way.
Exactly this. As a consumer, I really like most of the protections that GDPR provides and I want them to be widely followed and enforced.
As a freelancer who works with mostly small clients, I really wish that there was clear, official communication on what sorts of common practices need to change (or not) and examples of solutions that small businesses can implement to be compliant. Just telling them to not worry because they're too small for enforcement actions isn't a good solution since it limits privacy protection and compliance to large companies.
> As a freelancer who works with mostly small clients, I really wish that there was clear, official communication on what sorts of common practices need to change (or not) and examples of solutions that small businesses can implement to be compliant.
As a freelancer/consultant, I wish there was official guidance on when we are a data processor for our clients, and when we're not. Which employment situations make a difference (if any do).
It's not just our industry; anyone who's self-employed is in the same position if they see any personal data from their clients' businesses.
Sounds like you have a legitimate interest in logging IP addresses for security purposes, it is an effective measure and that your legitimate interest on balance outweighs the interests of the data subject. If that is the case you could probably rely on the “legal basis” called legitimate interest and do not need consent or anything like that. Do:
- Make a link to a privacy policy clearly accessible (eg on your website footer) and make sure it contains all of the required elements of information (see Article 13)
- Do not store the data longer than reasonable
- Do not worry too much about logs/backups etc as long as what you do is reasonable and you do have a reasonable delete schedule - no lawyers I have met seems to worry about this.
- Worry instead about for what purposes you actually use data you collect (what other orgs do you share data with, why, what do you do with the data that produces an effect on the data subject (eg marketing) etc)
>
Sounds like you have a legitimate interest in logging IP addresses for security purposes, it is an effective measure and that your legitimate interest on balance outweighs the interests of the data subject. If that is the case you could probably rely on the “legal basis” called legitimate interest and do not need consent or anything like that.
Assuming you are right, that answers part of my question. Yet, I would prefer to see this detailed by an official source.
The other part of my question still remains unanswered. The GDPR limits who qualifies as providing goods/services, but I don't see any limitation on who qualifies under "the monitoring of their behaviour as far as their behaviour takes place within the Union."
It seems like this create a legal liability for every single website with an access log unless it displays a privacy policy.
[...] In order to determine whether a processing activity can be considered to monitor the behaviour of data subjects, it should be ascertained whether natural persons are tracked on the internet including potential subsequent use of personal data processing techniques which consist of profiling a natural person, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes.
It appears like monitoring is closely related to profiling, defined in Article 4 as:
‘profiling' means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements
If you are trying to eg. predict preferences of data subjects by collecting the logs you are probably monitoring their behavior.
If you are doing this it should be pretty clear to you from the purposes you are collecting information for. Security purposes (such as preventing DDoS attacks) are probably not purposes of monitoring data subjects behavior or profiling.
> potential subsequent use of personal data processing techniques
Not a lawyer, but doesn't every access log with IPs and urls have the /potential/ to be parsed to aggregate a profile of site usage?
Even if you aren't actually doing or intending to do any profiling, the potential still exists.
You may well be correct about all this (and I suspect you are). I'm specifically trying to push back against the assertion: "I really don't think ... that anything in GDPR is hard to understand"
Yes and no. One of the most important principles in GDPR is “purpose limitation” (Article 5.1b):
“Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes“
If a company starts collecting IP addresses for DDoS protection purposes, and then figures out that the data could also be used for marketing - that is most certainly in violation with this principle and therefor forbidden.
A “lawful basis” for the marketing purpose will not save you from this principle.
This is also where the public privacy policy/notice plays a role - for the company to be able to prove that the IP addresses where also originally collected for marketing purposes and fair information was given about this purpose at the point of collection.
In terms of GDPR’s territorial scope I guess at the point in time you start to use the DDoS prevention IP logs for profiling you come into GDPR scope. You would also be immediately be in violation of the purpose limitation principle if it is for marketing purposes.
> If a company starts collecting IP addresses for DDoS protection purposes, and then figures out that the data could also be used for marketing ...
Charitably, I think your sentence is just unclear. It seems much more reasonable that someone just thinking or realizing "that the data could also be used for marketing" isn't legally prohibited. Right?
Someone would actually need to use the data, in some concrete specific way, for something illegal to have taken place.
And no, GDPR is from my own experience not easy to understand or apply in practice - except for PPT toy problems.
There is a lot of more behind the articles in GDPR since it is partly based on legal instruments on data protection from 1981(!), “Convention 108” and EU legislation from 1995. Case law, opinions from data protection authorities etc. are important.
In general though, I would not be worried about big fines or anything as long as you try to follow GDPR and you are not doing things the data subjects does not want you to do with their data.
In general, the best GDPR compliance test is how it feels in your gut, after learning the principles.
At the point in time you process personal data against the interests of the data subject (for example building marketing profiles, sharing data with third parties w/o request from the data subject, etc) it is time to start worrying and make sure you cross the i’s... GDPR is pretty permissive in general IMO but make sure you know the details.
Predicting and profiling for the purposes of security defense is then illegal? It’s not a legitimate interest?
Then every system implementing fail2ban or email tarpitting (so everyone running Ubuntu or MS exchange in default configs) is automatically violating GDPR.
Never mind the built-in catch-22 where you can’t store any identifiers of persons who have opted out, so you cannot remember they opted out and have to ask them repeatedly!
This law is completely unenforceable, and that is the worst kind of law. It results in inconsistent, politicized and malicious enforcement.
Again, the GDPR isn't really a set of rules per say. It's some rules (eg on consent), plus some frameworks (legitimate interest balancing test). The country-specific privacy orgs are figuring out the balancing tests and are promising final guidance, like, totes any day now. Meanwhile, the deadline is 25 May.
The biggest question is: why do you need indefinite amounts of IP addresses logged? You don't even need to ask yourself if it's compliant or not by just not doing it. The usefulness of ip addresses that old is very limited.
The usefulness of ip addresses that old is very limited.
Either the old IP addresses can be tied to a specific individual, which means they are potentially useful for legitimate security purposes such as helping to identify someone who has previously tried to scam you, or they can't, in which case what is the risk of keeping them around anyway?
> in which case what is the risk of keeping them around anyway?
GDPR wants you to think differently about it: if you want to keep data, ensure that you actually need it. Do not treat data as an asset but as a liability.
We've been careful about what data we collect since day one, long before the GDPR was an issue. We're not doing anything shady with the data we do have, and we actively avoid questionable practices particularly around marketing, where we have ethical problems with being intrusive or compromising people's privacy regardless of any legal constraints. And yet having read the GDPR and much commentary about it, we're still concerned about the potential risks it introduces.
I think it's important to remember that GDPR itself doesn't want anything. GDPR is not a person, it's a set of legal regulations. What matters most about laws is what they actually say. Intent, as has been demonstrated countless times, is secondary.
Now, the people who wrote the GDPR might have wanted people to change their minds or think differently about privacy issues. However, that doesn't make the GDPR itself any less dangerous, and as I've argued elsewhere in this discussion, essentially those same authorities do have form already for being heavy-handed in other areas of EU law, and have caused real damage to plenty of businesses as a direct result.
> We're not doing anything shady with the data we do have
But you can never guarantee that someone else won't do. The biggest issue to user's privacy has traditionally been data breaches. So even if you don't want to do something shady, a data loss might still be highly problematic for users.
I agree that IP addresses are unlikely to be the biggest concern here however.
The biggest issue to user's privacy has traditionally been data breaches.
I'm not convinced that's true, but let's assume it is for the sake of this discussion.
In that case, wouldn't a better approach be to mandate reasonable safeguards to protect against data breaches, and to penalise those who are seriously negligent in that respect?
Otherwise again I think you're aiming at the wrong target. Deleting stale data might have some marginal benefit in terms of privacy in the event of a breach, but the risk and consequences are surely much greater for the organisation that has only recent data but uses admin:admin for their root credentials. Meanwhile, the overheads of updating long-standing logging or backup systems where that older data might lurk to fully isolate everything could easily be among the highest practical costs for compliance, particularly for a lot of smaller organisations.
The biggest issue to user's privacy has traditionally been data breaches.
Peoples lives and most intimate details is going to be stored as bits. Get used to it.
Whether for targeting purpose (Facebook) or personal reasons (Strava). Whether stored on remote servers or home. It wont affect likeliness of data breaches. Focus on good software designs and let programmers design such systems in peace.
All this needed was fine for data breaches. Not the mess called GDPR.
GDPR is designed to not simply accept that "Peoples lives and most intimate details is going to be stored as bits. Get used to it." but instead try to change that.
Changing that is nontrivial, since it requires changing the behavior of everyone handling this data - so, something that can be done only by law. It will restrict Facebook, it will restrict Strava, it will restrict data stored on remote servers and home. While it won't affect likeliness of data breaches, it will affect the impact of data breaches - realistically speaking, many of the breached companies should not have had most or even all of that private data in the first place.
A data breach can't reveal information that you don't store; so a push to ensure that less companies are storing sensitive data, and those who do are storing less of it - that's something long overdue. GDPR is not designed to have people do X, Y and Z so that they can keep doing business as before; it's designed to ensure that many (most?) places where private data is used simply stop doing so.
Not all private data is stored for commercial reasons. People themselves want to store their lives, make use of advancement in IT and improve their lives. Now what about those data ? If its stored in a computer connected to internet then its at the risk of data breaches. Its even easier as a typical user is not capable nor can he detect such attacks (see botneting toasters).
So if the rationale for GDPR to reduce data breaches or to deny private data to future rouge govt, then it fails. Private data will still exist even if its not commercialzed. Its irrelevent who control it (user or company) as long as its connected to internet, there is risk of data breaches.
Unless you propose to go back to storing actual photos in actual albums. ITT im not sure.
> What matters most about laws is what they actually say. Intent, as has been demonstrated countless times, is secondary.
That's different per legal system. In some the text is more relevant. In various others the intend behind the law is very much relevant. I highly suggest to not follow your advice!!
The parent comment is saying we shouldn't rely on the intent of implementors of the law for our continued well being.
Pattern: propose easily misused overly broad law. When people express concern claim that the law is only to deal with problem foo and would never be used to do what it says in plain language. Proceed to do what it says you are allowed to do.
It could possibly be expressed as don't accept intent and goodwill in place of plainly expressed limits on government or regulatory power.
Quit storing ips unless you are legally obliged to do so (audit trial, mandated surveillance, like that other EU directive...). Generally security audit purposes will likely let you keep logs for "reasonable time" (weeks).
You know for things like being able to do analysis. For example, last week I wanted to know where to locate our next local server and so needed to know where the usage growth was coming from. I happen to noticed that the usage over the last few weeks was quite different to the historical data. If I only had 2 weeks of data I would have made our service worse for our customers.
You might be a good candidate for storing aggregated (anonymized) data.
[ed: incidentally you're kinda sorta in the area GDPR wants to combat: "it'd be nice to know what x want to buy next, and where - for logistical and marketing purposes. Why can't we just store a full profile of everything x does, where and when?]
The problem becomes if you make a mistake or aggregate in the wrong way you end up losing the ability to do later analysis. If I had thrown out my logs I would have provided my customers with a worse experience.
I am supportive of the intent of the GDPR and we have always gone out of our way to minimise the data we collect, but as currently written the law has a whole lot of very negative downstream effects.
Really the law seems to have been written to catch a few bad players and has ended up netting everyone in the world.
Performance data is not going to tell me where the users are located.
Yes it was only because I had the logs was I able to do this analysis. The issue is not over these sort of analyses which I am sure nobody would object to, but that GDPR casts such a wide net.
The complication is that I have a client-based fallover where when one server becomes overloaded the client is switched automatically over to a different server (client based load balancing). This make it hard to sort out where the load is coming from without looking at the IP address.
The lawful basis of consent are a joke. You could capture all data under "legitimate interests" and then allow all further processing under "statistical purposes”.
It's a nice symbol, but not nearly enough emphasis is being put on these values (and how to defend them, in work day practice) as part of the curriculum.
Undergrad engineering culture elevates the ring into a mythical embodiment of the deliverance that is graduating. Then, naturally, the moment you have it on your pinky, it's a status symbol – you're 23 now, old enough to act real casual about it, but man, shit feels like you're 13 and just emptied a can of Axe spray on yourself. The noble humility is very shortlived, in my experience.
Somehow those in medicine seem to be doing a bit better, with their Hippocratic oath. Maybe it's a maturity thing. But yeah, I think actually teaching these kinds of practical ethics more would have a bigger effect.
As you can see in the article, it already exists in Canada. Some engineering schools like École de technologie supérieure (ÉTS) offers a 4 year Software Engineering program that enable you to become a member of the Ordre des ingénieurs du Québec. It's a self-regulatory body that governs Quebec's professional engineers. There is a ceremony where they give you an iron ring, mostly to remind you to be humble and to always consider the public interest first when making decisions. Can software engineers become P.E. in the U.S ?
Software Engineers can theoretically become PEs, but it's very recent. Practically speaking, it's difficult right now.
NCEES recently created a PE exam for software engineers in 2013, in collaboration with IEEE and IEEE-CS. However, it's up to state engineering boards whether or not to administer the exam. California does NOT yet the administer the Software Engineering PE exam.
Yes. Most CS/CE/SE programs in the USA are part of the school's engineering college and are ABET accredited, which is the governing body of professional engineering in the USA. To become an PE in the USA, one needs to first graduate from an ABET program, take the Fundamentals of Engineering exam, work for at least four years in their field of study, then they make take the PE exam.
Now, almost nobody does this right now. Only 32 people took the Oct 2017 exams in Software, and Computer & Electrical Engineering. For reference, about 4000 people took the various Civil Engineering exams.
There's really no incentive to become a licensed engineer the USA. I've never seen a job posting mention one at all. So I think the exercise would be purely academic (though, I'd love to hear from someone who has a license and uses it).
Many CS programs are accredited by ABET, but they're covered by the Computing Accreditation Commission which doesn't qualify graduates to sit for the FE exam. And many top CS programs, including CMU and Stanford, aren't ABET accredited at all.
Nationwide, there's only 27 Software Engineering programs accredited by ABET. So graduates of those programs could sit for it but until graduates from top programs qualify, no one is going to require it.
> but they're covered by the Computing Accreditation Commission which doesn't qualify graduates to sit for the FE exam.
Wait, are you sure about this? When I was in school, they pushed CS/CE students to take the FE Electrical and Computer exam. I never signed up, but why would the school nag students to do something they weren't allowed to do?
Yes, but there's little point to it. There's a secondary exam, and unless you're going into a field involving safety-critical applications, they don't need P.E.s.
This is very self-righteous. At my company, we respect our customer's data immensely. What happens is that some non-PCI data (but still PII like email addresses) data leak naturally into our log files, and I've been told his means that we need to clear our logs of that as well. We use this for debugging and data analytics, and email address is our primary username, so it's a huge undertaking for us to make this shift. I've been told this requires us to clear tape backups as well.
So it's not anything to do not respecting our customer data, it has everything to do with not seeing the unintended consequences.
I certainly don't create a long living policy document for my own personal data though. There seems to be additional paper and process requirements above and beyond the technical aspects, at least according to the article.
It's not easy at all to understand. I'm a developer and have spent 40+ hours in meetings with lawyers because the interpretation of the law isn't easy at all. There is a whole team of lawyers looking into this. 40% of my team is working on GDPR implementation.
Just figuring out if users are allowed to use my service is hard. There is a different age of consent in different EU countries, and apparently some haven't even decided on an age of consent yet. What happens if I am in a country that has age of consent of 14, but then they vacation and use the app in a country that has age of consent of 16? We are required to offboard users if they aren't of the age of consent. What is the support flow for letting those users back into the app if they accidentally said they were born in 2016? What if the company owns multiple apps, and the user users the same OAUTH account to login into each app? If in one app they enter their birthdate as underage, now I have requirements to delete the user from all apps.
My default mindset is to avoid collecting any data that I don't need so my app stores almost no info about where users are located. But EU regulations have told me I need delete all EU user accounts who don't agree to the new terms in X days after May 25th. Does this mean I have to go delete all user accounts who haven't logged in since a certain date since I can't differentiate EU vs non-EU? Those users aren't going to be happy. Some users log in through email so we are able to email them, but other users use phone number login where we can't contact them. We are potentially deleting huge numbers of accounts.
We host our help center site using a third party service. Does that third party service happen to store IP address in the logs? Now I have to care about that as well.
Lets say my company built an Apple TV or Xbox 360 app two years ago. There is a small group of dedicated users but it doesn't make us any money and we haven't updated it. Now we have to go build an interstital making them agree to new terms before they can use the app. None of the developers who built the app are still around, I guess we need to just delete the app now.
It turns out that there were a bunch of Russian accounts who tried to manipulate the election and we only found out months later. Good thing this happened before GDPR. After GDPR all they have to do is claim they are in the EU, and then delete their account, and there data won't be completely unaccessible 30 days later.
I am a big advocate for privacy and a member of the EFF for a decade. Maybe my company just already has good privacy practices, these regulations are making development much slower, without providing additional privacy benefits. If you want to see some change, I would think massive fines for data breaches would be the way to go.
Ah, age laws. I remember when the USA brought in COPPA, I worked on the Google account system at the time. What a mess. Turns out lots of people register Gmail accounts for local businesses that aren't big or sophisticated enough to use their own top level domain and hosted email solution - they just grab a free webmail address and paint it on the side of their plumbing van or whatever.
Oh, and when asked for a date of birth, they don't know what to put because it's a company account and not a person.
So they put the founding date of their company.
Which is often less than 13 years old. So now the account is locked because they need "parental consent". Or maybe they're trying to create an account, in which case they need to be locked out from creating an account because they "lied" about their age. But they aren't logged in, so how do you do that?
The already existing account doesn't have a parent of course. And it's owner is already an adult. No problem, you think, the owner will just have to prove they're an adult and it's OK.
But COPPA specifies precisely how you can check if someone is an adult, and it was written by a bunch of US regulators who don't appear to know much about life outside the USA. For instance one acceptable age verification mechanism is a credit card, but lots of people around the world don't have credit cards. Everyone having 5 cards is a US thing. So that doesn't work. You could also do a video conference with them, but good luck hiring enough people to do that at anything like a workable cost (per user margins are ultra thin). And so on. Pretty quickly you realise there's no way to recover that is both cheap enough to be deployed, and globally usable. That ignores the fact that some techniques hurt privacy far far more than any website ever normally would e.g. demanding and verifying government ID.
So people just lose their business email.
I've never seen a government pass data related regulation that wasn't a complete disaster. All such laws I'm aware of are riddled with contradictions, collateral damage and total absence of evidence that it actually helped anyone, anywhere.
To be honest, I can't imagine a situation in which I would need a new law in order to have follow age of consent laws. Like, you are really complaining that if a user says they're underage, you have to treat them as such? Or that if you operate in multiple countries you have to look up the relevant laws? All of this seems like a basic requirement, and I'm honestly shocked that it was never an issue before.
We already comply with age of consent laws. GDPR changes the law and adds lots of edge cases around users transitioning from valid user -> invalid user as I described above.
I'm not complaining. I'm just saying it's not basic or simple. I often see the attitude that, "Oh that should be easy" when someone hasn't implemented something.
It reminds me of people who have taken the programming 101 class telling me, creating Amazon is easy, its just a webpage. Or I could completely run Twitter off of just 4 machines.
The problem is you are required to prove that you follow the rules, which would take your effort and your money. This is a "guilty until you prove you are not" thing.
What do you mean one-offs? Pretty much every company with an engineer on staff is collecting as much data as they can with zero regard to the user's expectations of privacy. The regulation exists to stop an epidemic, not to act on a few one-offs.
You're referring to express consent. However, the user is granting implied consent - they're the ones visiting our website, they're the ones requesting our images and executing our javascript, and they're the ones filling out our forms. We're not forcing them to do any of these things.
It certainly is, and any reasonable person would agree.
If you send me an email, am I allowed to keep your email address in my mail logs, archives, and inbox? Hell yeah I am, you gave me implied consent to do that by sending me email.
Am I allowed to spam the email address you gave me? Of course not. But I can keep it.
Placing an automatic and extreme burden on the recipient of a communication like a website visit or email, which is exactly what the GPDR does, is just plain bananas.
Just switch on developer mode in the browser and watch the network activity while visiting an arbitrary site. I don't think it's a few one-offs. The few sites who don't do malicious tracking (thanks HN) are one-offs.
This is my biggest question about HIPAA and GDPR about deleting specific user records and data.
How are others planning on deleting data from all backups. It seems like any automatic process that modifies all existing backups has the potential to accidentally corrupt all backups in the process.
Is there any safe way to safely delete a record out of my prior database snapshots, or is there a reason I don't actually need to do this?
Encrypt the data element using a nonce, encrypt the nonce using a public key whose private key will be purged from your HSM/SCD/key management system on a scheduled basis. You will need to retain metadata about the key ID too.
Don’t leak private keys, so you should generally use a decryption service if you need access to the data record. Handy to prove access too!
That works and survives fairly intense audits at least in my experience.
Do you maintain your database backups indefinitely? If they rotate out after a month or so you will likely be inside the realm of what GDPR considers reasonable compliance. The live data is removed ASAP and the data will rotate out from the backups in a reasonable time frame. At least from the legal advice we've had.
We have no plans to retroactively fix our backups. But we will have to make damn sure that if we need to use a database backup we do not reintroduce user data that we've purged. For that purpose we will have to maintain a list of which users have been purged until the backups rotate out.
According to the advice we've had, this is acceptable.
> But we will have to make damn sure that if we need to use a database backup we do not reintroduce user data that we've purged. For that purpose we will have to maintain a list of which users have been purged until the backups rotate out.
This is the approach we've generally taken as well.
Two options:
a) use a reasonably short retention period, e.g. 6 weeks
b) if you key your entries in Kafka, a new entry with the same key will overwrite the old one. That way you could overwrite PII content with an empty message.
Once you have a way to backup data per user, just encrypt them with random key and once the account is deleted, delete the random key. We have done it this way, with having multiple live copies of backup key table on multiple locations and beeing backed up daily purging previous backup. The hard thing was to group the data in a way where we can encrypt them with users random key.
Yeah, but isn't it possible to trivially and inadvertently combine a bunch of systems S1 ... Sn which are all respecting the GDPR into a new system which doesn't?
We will see, new regulation is coming after GDPR and I bet they will plug the missing holes there. There was a cookie law that everyone circumvented. Now the same people are complaining about GDPR. The next round is going to put even more restrictions, and the regulation is going to be blamed. But the ones to be blamed are the ones who abuse it.
I'm not sure what you mean by "holes". It seems like it's a fundamental and intended feature of the GDPR that you can't achieve compliance-by-default. You have to explicitly audit every interaction between every system you have, to ensure that either no personal information is present or the interaction complies with GDPR standards.
"...you have to explicitly audit every interaction between every system..."
But would you though? If you're a large co. you'd have a configuration management system where you just pull the specs/data rather than do an audit. If you're a small co. you'd know already, and if not you'd just go look. Right?
My experience is that anyone complaining about the amount of work GDPR is causing is a. not compliant anyway (and knows it) and/or b. has terrible or no IT governance.
Not right; you can't just review the specs of each system. It's very easy to accidentally combine compliant systems in a way that isn't compliant.
Just to pick one example I've seen in practice, system A might have an integration bug causing system B to periodically emit error logs, containing data which system A knows is personal but system B does not.
The law applies to business entities so it will go and cover every piece of infrastructure they run retroactively.
Imagine having a dev with contributions and commits in a dozen projects calling github to exercise his newfound right of removing all personal identifiable information from the system.
I will show you another case, company that isnt "bitching" over laws that are good for all humans not just EU and does the right thing, you know backblaze, right?
"The changes that are being made by companies such as Backblaze to comply with GDPR will almost certainly apply to customers from all countries. And that’s a good thing. The protections afforded to EU citizens by GDPR are something all users of our service should benefit from."
Get it? It is shamefull what a couple of technological leeches did to basic human right for their profit, not to mention turning the whole internet into clickbait maze. Stop complaining, it is right thing to do, like it or not.
It's good to see Backblaze confirming that their GPDR compliance will benefit all of their users. That's definitely been a hope of mine as someone who doesn't live in the EU, so hearing that is encouraging.
For any greenfield development, why would we develop it twice? We have to solve every business problem we have for the EU; why would we solve it differently, to address the same problems, elsewhere?
For non-greenfield development, why would we keep two codebases and sets of infrastructure around that we have to support? Better to consolidate. Especially given the positive word of mouth it would generate compared with "Yeah, we're not as careful about your privacy because you're not in the EU".
The -only- case where it makes sense to do something different outside of the EU is if there's a key bit of value that we literally can't capture in the EU due to the GDPR, and we want to capture it elsewhere. Now, that's still alarming (in that we could have the privacy haves and have nots), but I just don't know how common that will be, or whether companies would find it worth doing.
And remember that GDPR applies to EU citizens outside the EU too, so you’d need to confirm with the user upfront that they aren’t an EU citizen before capturing the information.
"This Regulation applies to the processing of personal data of data subjects who are in the
Union by a controller or processor not established in the Union..."
That’s not what it means: A company in the US could aquire a US citizen as customer and consider itself safe. Now that customer moves to the EU - et voilá, the company is subject to the GDPR.
There’s many other regulations that only apply to citizens and not based on location.
So nice to see progress in privacy but please someone explains how GDPR will help EU startups!
GDPR is inevitably going to hinder any new company forced to abide by it. So the next Uber/Wechat will first flourish in US/China/Russia and then come to the EU, not the other way around.
Entrepreneurs / investors also want their time & money to be used to build value first rather than solve yet another accidental complexity that is irrelevant until your revenue model is proven.
What am I missing? Is GDPR implementation cost marginal?
I wouldn't say marginal, but it is a lot easier to implement GDPR if you do it up-front, from day one. If you start off with a policy of just not collecting or storing information unless you've made a conscious decision that you really do need it, that's a huge start. From there, you your main obligations are to ensure that any personal data you do collect can be deleted at a reasonably granular level, and that you document your policies around data storage.
Is it free? No. But if you're spending a significant amount of time on it as a new startup building from scratch, something is very wrong.
And hell, if you started a company recently, you were given the chance to catch up to the incumbents in your market while they've slowed down to retrofit all their systems for GDPR compliance. ;)
Let's say you're a business in the EU that needs a sales management system. In it, you store personal data of your clients. You are considered a "controller"; the SaaS sales management system (that will store this data for you) is considered a "processor."
GDPR states that to remain compliant, Controllers must only use GDPR-compliant Processors.[1]
Assuming that EU startups will take GDPR more seriously than non-EU companies (a safe assumption judging from the posts here on HN), non-tech EU companies (Controllers) will tend to gravitate towards EU tech companies (Processors) to ensure they remain compliant.
It is non-EU (primarily US) tech companies' game to lose. If US tech companies get a reputation for not caring about GDPR, there could be a real sea-change in EU buying behavior.
[1] Article 28, paragraph 1: "Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject."
> Assuming that EU startups will take GDPR more seriously than non-EU companies
It’s also easier in terms of jurisdiction. A non-EU company might just pretend they’re compliant but your legal options in case they’re not are somewhat limited.
"So nice to see progress in privacy but please someone explains how GDPR will help EU startups!"
Why does everything have to help startups?
"GDPR is inevitably going to hinder any new company forced to abide by it."
I disagree. You simply shouldn't be collecting that data in most instances anyway. And if you truly do need it, you should have been asking permission before. Somehow we got it into our heads that it was perfectly acceptable to just take things without asking. I'm fairly certain I learned not to do this in Kindergarten.
"Entrepreneurs / investors also want their time & money to be used to build value first rather than solve yet another accidental complexity that is irrelevant until your revenue model is proven."
The GDPR has no impact on this, unless the only way you can create "value" is by disrespecting your users. You can still build value the old fashioned way, by providing something of use to your users.
It is very costly for existing (!) companies, for startups it comes with fraction of cost, if taken into account from first line of code, from first create table. In few years it will be normal.
One more interesting thought. If you are using ad provider/tracker/data reseler X/... located in USA which is GDPR compliant and is doing bussiness with EU, and you are feeding them with toxic information you didn't get consent for, the EU can pick on them. As you have damaged their bussiness they can sue you. In USA.
As always EU regulations are efficiently point out why Europe will always be an inferior place to do business compared to America. I guess at least Brexit is making more sense now.
It won’t change the way I develop because I was never a data-stealing sleazebag in the first place. But I hope it drives Google and Facebook out of the UK/EU for good.
So here in Sweden (and I imagine a couple other EU countries) there is the Patient Data Law (PDL) that regulates the use of health data.
This will probably have to change a bit with GDPR but will still supersede GPDR when it comes to health data. Are you providing compliance with those laws as well?
Apart from the deserved mocking in the other answers, I'd like to point out that GDPR applies to Chinese companies doing business in the EU as much as US companies doing the same.
It should also be said that China has far more onerous regulations of commerce than the EU and US, for example in regards to foreign ownership. But you actually know that, otherwise you wouldn't preface "China" with "communist". Which, however, isn't terribly accurate, because modern China really have much of all to do with communism.
It seems that since the gpdr requires deletion of data upon user request, companies will not be able to send recall notices when, say, a medical device starts killing customers.
The GDPR does not require deletion of all user data on request. There’s still data that can and must be preserved, for example business records, thus records of sale. A recall should be possible with those records. The customer might request that these records cannot be used for unrelated purposes, though.
You’re generally allowed to keep data that is required to provide a service. So in my understanding, yes, if you provide such a service and the user requests that, you should generally be allowed to keep that info _for exactly that purpose_ You can’t use it for anything else though.
This is not written in unintelligible legal-ese. It is very approachable, understandable by a layman, and organized such that relevant Articles are easy to find.
It might take an hour or two, yet may have a fundamental impact on how you approach your job for the foreseeable future. Time very well spent.
Here is an accessible version of it: https://gdpr-info.eu/
EDIT: for clarity, that site is accessible from an organizational point of view (i.e., broken out by articles, not one long string of text). I do not know if it is accessible by screen readers or alternate input devices.