Hacker News Reader

Comment by WA | Hacker News Reader

This is a very interesting list, especially the part about the GDPR increasing the attack surface and where the data gravity center is.

The part about "compliance cost" should be taken with a grain of salt. If you were compliant before, because you respected the users‘ privacy, the effort was relatively low.

The study about VC having dropped by 50% in the EU because of the GDPR sounds pretty weird to me. Unless of course there’s selection bias and we’re talking AdTech companies mostly.

An interesting number would be: how many people closed down forums and moved their discussion boards to Facebook?

View on HN

> If you were compliant before, because you respected the users‘ privacy, the effort was relatively low

This is not true. Even if you are perfectly compliant, you need a complaint-response mechanism and lawyers in the EU ready to react to invalid accusations.

Given GDPR took a complain-investigate model, one also needs to be ready for power-tripping regulators. (Recall the Romanian data protector using GDPR to seize sources from a newspaper investigating corruption allegations [1].). Protecting against that requires, if not active lobbying, keeping lobbying connections warm. That costs money.

Ironically (and predictably), I’m seen more data being funnelled to Google than before. They have the scale to deal with this crap in each of the EU’s (currently) twenty-right member states.

[1] https://www.techdirt.com/articles/20181114/01491541047/yet-a...

> Given GDPR took a complain-investigate model

Ironically, when GDPR came into effect so many on HN were spreading fake news that companies would be litigated to death by users. Of course, to remove that possibility and ensure only legitimate claims are pursued, the data regulation authorities act as middle-man. Such cases of abuse could also just as easily be done when people could sue. For example, nowhere does the GDPR imply that you need to hand-over a source - that goes for journalists as well as non-journalists. Companies sued have the right to appeal and, if GDPR wouldn't have existed, the Romanian authorities would've probably just used e.g. tax law to stifle the RISE project.

> nowhere does the GDPR imply that you need to hand-over a source

Complain-investigate compliance regimes tend to result in deference due to the cost of investigations and other informal expenses regulators can rain upon the regulated. (It works in finance because financial firms have the margins to support it. Also, the industry regulators are checked by both the courts and a public regulator, the SEC.)

Complain-investigate is thus a terrible structure for a general business law. Strict liability for data loss or mis-use (including the rights to data transcripts and deltion) would have been simpler. (Albeit, less profitable for European law firms.)

Long story short, GDPR’s aims and technical costs (e.g. deleting user data from backups) are fine. The problem is the compliance structure. It’s fundamentally incumbent-biased, commercially and politically.

GDPR is just the 1995 Data Protection Directive with teeth. If you were compliant with the DPD, you were almost certainly compliant with the DPD by default. The principles are the same and many parts of the legislation were carried over verbatim. GDPR came as a shock only because many businesses had been flagrantly disregarding the (weakly enforced) DPD for many years.

https://en.wikipedia.org/wiki/Data_Protection_Directive

>Even if you are perfectly compliant, you need a complaint-response mechanism and lawyers in the EU ready to react to invalid accusations.

Did American businesses really think that they were immune from prosecution under EU law prior to GDPR? No European business was under any illusions about the extraterritorial reach of American courts.

> Did American businesses really think that they were immune from prosecution under EU law prior to GDPR?

Prosecutors need to build a case before causing costs for the suspected noncompliant. Complaints, and regulators in complain-investigate regimes, can incur costs with zero evidence. This is why most systems reserve such structures for high-margin, high-risk applications, like banking regulation. Deploying it as a general business law is aggressive.

I don't know about it being low effort to be compliant. We spent most of a year with a significant portion of our software engineering teams devoting time to GDPR even though we are not any kind of data collection company. It's the legal requirements -- we had to audit every last piece of software, make little tweaks if necessary, etc, just to ensure we were demonstrably compliant with the law.

I wouldn't be surprised if 150B is actually a low estimate.

> even though we are not any kind of data collection company

Are you collecting data on your customers? If you are, then one of the things your company does is data collection, even if that's not what's in your business plan.

We store enough identifying data to do business with our customers, we do not collect data for data's sake. Not for metrics, nor for ads, not to sell, etc.

Does having a table called "users" with usernames, emails, password hashes, and last logged in timestamps count as customer data?

Yes. Emails are 100% PII. Even user names can be argued to be.

The term "personally identifying information" does not occur anywhere in the text of GDPR; the regulations use the term "personal data", which is defined differently.

I raise this issue in almost every thread about GDPR, because although it might seem pedantic, the error strongly implies that people have not read or understood the legislation. The difference between personal data and personal identifiers is integral to GDPR and the legislation cannot be understood without fully understanding that distinction and the implications that follow from it.

https://gdpr-info.eu/art-4-gdpr/

It counts as personal data, and as such, under the GDPR you have a duty to handle that data sensibly and responsibly.

Every single company in the world collects data on their customers.

Every company receives data about their customer, usually leaked by the customers themselves. How they handle it and what they choose to store / delete differs wildly.

> If you were compliant before, because you respected the users‘ privacy, the effort was relatively low.

Why? Don't you still have to build systems to be able to comply with user requests in a timely matter?

First, if you cared about user privacy, you would store as few data points as possible.

Second, it’s very likely that you have APIs in place that can request all data for a user anyways. If you don’t know what data you have of your users, you don’t give a shit about their privacy, no?

Third, user requests are usually: a) what data do you store about me? B) Export all data. C) delete all my data (for real).

At any kind of scale that is 100% not the case.

The orchestration of a data extract from even a midsized corporation is a significant endeavour.

Someone in the company knowing what data we have on an entity is a significant step away from the entire company being able to access that, because, you know, we take data privacy seriously, so we don’t make it easy to access all data on a single entity.

If your approach to privacy is putting all the eggs in a basket, allowing easy extraction of everything from that basket, and hoping the basket can be kept secure I’d argue your model is weird to begin with.

This is so simplistic. There are many storage solutions for many different use cases.

Some of these are write once and immutable afterwards.

There are relational structures for transaction history that may also link to customers.

These all have to be re-designed in such away that information can be removed from the system and exported from the system, while keeping essential information (such as past sales records).

This is not an easy problem to solve.

> Some of these are write once and immutable afterwards.

Got an example of something like that that'd make it impossible to soft delete a person? I'm struggling to think of any datastore in regular use that's write only.

https://aws.amazon.com/qldb/

Yeah, as I thought, it's a blockchain/distributed ledger related technology. Hence why I said "regular use". I doubt large numbers of EU businesses are suddenly having to move data from their core ledger to another datastore because of this.

>Third, user requests are usually: a) what data do you store about me? B) Export all data. C) delete all my data (for real).

Are you implying that those 3 requests are simple to fulfill in a business running a modern software architecture?

Backups usually aren't designed for deletion of individual records. Until recently this was considered to be ok.

If your backups age out and are deleted over time it is ok (as long as that timeframe is reasonable).

_if_ you can ensure that you can re-execute deletion requests if the data needs to be restored.

With GDPR no backup can be kept more than 60 days.

It still is.

they aren’t but this is actually quite easy. PD gets encrypted on a per user basis. to forget a record, throw away the key.

>The study about VC having dropped by 50% in the EU because of the GDPR sounds pretty weird to me. Unless of course there’s selection bias and we’re talking AdTech companies mostly.

It's really that surprising to you that when the EU effectively bans one of the most profitable models of business that venture capital investment will drop by 50% in the EU?

To be fair, it's probably just not GDPR but all of these regulations combined. Venture capital can move across borders, why would you invest in a startup in the EU when you could just do it in the US?

> The study about VC having dropped by 50% in the EU because of the GDPR sounds pretty weird to me. Unless of course there’s selection bias and we’re talking AdTech companies mostly.

Could just be noise in the data?

Could be VCs determining that fewer products are actually worth pursuing if the main monetization model for everything is ads?

I dunno.

One thing my company did (we are US-based, but have an international operation as well) to try and mitigate the volume of compliance work to be done was section off software that would be used in the EU from everything else. Previously we had been working on making all of our software 100% internationally universal, but GDPR made that difficult, going forward we're kinda cutting loose the guys in the UK (there's some irony, I guess) to keep up the code that has to be GDPR compliant while the rest of the company focuses elsewhere.

So... anecdotally, I'm not at all surprised if the increased compliance cost made some people reconsider investments in EU businesses, even if they don't rely on ad revenue as a business model.

Personally, I'm totally fine with that lost investment. Especially since it's likely to be temporary.

Funny to read this in a US VC investment forum.

This isn't a US VC investment forum. This is a US forum subsidized by a startup accelerator, but otherwise quite generally about tech and geeky stuff, and frequented by lots of people from outside US.

Indeed. I'd even wager that a considerable portion of the userbase here has no idea what Ycombinator in the address stands for.

Only around 50% of the people in this forum are from the US.

https://news.ycombinator.com/item?id=16633521

The problem I think is happening with the compliance cost/VC stuff is that it's also tainted by the other internet junk (Article 13) that the EU passed soon after when they started doing this whole internet regulatory push.

Anecdotally, I thought that many companies just decided to exit the European market because the costs of GDPR were so high.

We did. We shut down our SaaS product in the EU and have no plans to reinstate it.

Reply on news.ycombinator.com