Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

171–180 of 202 posts

Re: GDPR – A Practical Guide for Developers (2017)

#171
post #131

Earlier quoted context omitted.

4) If you are not living in the EU you are not obligated to implement any of the changes. Being a small time developer, what is the worst that can happen?

If you service any users in the EU or process any personal information of EU citizens, you must comply with GDPR.

What will they do if you don't comply?

Re: GDPR – A Practical Guide for Developers (2017)

#172
post #154
post #131

Earlier quoted context omitted.

4) If you are not living in the EU you are not obligated to implement any of the changes. Being a small time developer, what is the worst that can happen?

Banned from the majority of the world's developed countries.

What will happen? They will block your website?

Re: GDPR – A Practical Guide for Developers (2017)

#173
post #160

Earlier quoted context omitted.

> How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose? By first coming to grips with the fact that this isn't your data. Keeping data is always a risk. You risk being hacked and jeopardising losing control of people's personal data. The longer you keep it, the longer you are putting that data at risk. How long can you be expected to…

By first coming to grips with the fact that this isn't your data... The trouble is that you haven't adopted any objective or actionable position here. It's easy to pass the buck with more questions. What small organisations need is simple, verifiable answers. The absence of such answers from authoritative sources is possibly the single greatest criticism being made of the GDPR. Why do you say something is not necessa…

> The trouble is that you haven't adopted any objective or actionable position here.

What, that you don't own someone else's personal data?

If someone signs up for your service, you do not own their email address and cannot use it in a way they wouldn't want.

What part of that is unclear?

> You said it was good advice to mask off the bottom bits of the IP address

If it wasn't needed.

You keep dropping this, so maybe it's because you didn't read it when I wrote it or when you wrote it.

> I don't think that is good advice in general, for the reason I gave: either the full address has a legitimate use for identifying specific threats, or it probably isn't specific enough to constitute controlled personal data in the first place.

Well, you're wrong. The ICO has recommended it in general for exactly this reason:

https://ico.org.uk/media/1061/anonymisation-code.pdf

But again, the GDPR allows for an exception if the data is being used to eliminate fraud:

https://www.privacy-regulation.eu/en/r47.htm

> What small organisations need is simple, verifiable answers

Which is convenient that the ICO is offering simple, verifiable answers: https://ico.org.uk/for-organisations/business/

> The absence of such answers from authoritative sources is possibly the single greatest criticism being made of the GDPR.

Possibly, but also possibly not. So what?

It's still law.

> I can't see how your reply fits with anything I wrote. What point were you trying to make here?

I said: "You should be able to delete usernames, passwords and email addresses on request. You should be able to remember that request if you restore from backups."

You said I can't do that without storing a hash of every user name or email address that has had deletion requested, and querying a database of such hashes during the restoration process which is bonkers: How many complaints and requests for deletion are you going to get? You might get two or three. Ever. How often do you restore backups? Monthly? Yearly? How hard is it to search two or three requests whenever you do a database restoration if you do something a dozen times a year?

If you're a bigger company you might do it more frequently, but then it's clearly no longer onerous.

Re: GDPR – A Practical Guide for Developers (2017)

#174
Practical guide to developers - build your product in the US then expand to Indo-Pacific. Don't bother with rolling out to Europe. AI is the future of business & healthcare, which, due to inherent need for data, is incompatible with anti-data sharing laws such as GDPR. Population is rapidly aging in Europe (47.1 year old average in Germany, 42.9 in EU), so might as well set your business up for the long term by pivoting to the region where growth will take place (and where general population is more acceptive of emerging technologies that rely on easy access to data).

Re: GDPR – A Practical Guide for Developers (2017)

#175

Earlier quoted context omitted.

> Moreover, if compliance with the law is so onerous that small organisations can't reasonably be expected to do it anyway, that's a pretty clear case that the law is too strong. The text on the GDPR is actually super reasonable. The whole thing is pretty short for how big people say it is, every article is sub 1-page, and essentially everything comes with "within reason" asterisks of various kinds (deadline extensio…

Just to be clear: I'm in the UK (as are my businesses), I'm generally an advocate of strong privacy protections, I can and do put my money where my mouth is by supporting various organisations that defend such protections, I have read the entire GDPR and a large amount of guidance related to it, I have consulted with other experts on it, and from day one my businesses have always followed careful practices in terms o…

> In short, my view that the GDPR is bad law doesn't come from a culture shock

I wasn't implying that. I'm saying that the poster I was initially replying to is getting culture shock; overwhelmed by the sudden need to care about their customer's privacy.

It's a regulation document, of course it's not going to be perfect, I don't know a single one that is. Overall as far as these go, I don't see major problems with it (other than yes, some of the terms in it are loosely defined, including what kind of data is covered under it; these will be things I expect will be learned over time).

Re: GDPR – A Practical Guide for Developers (2017)

#176
post #64

Earlier quoted context omitted.

I would. I'm doing some GDPR consulting at the moment and most of my conversations are "I don't think it's as complicated as you do". Americans tend to read law very pathologically unless they are familiar with how European legislation works, and every programmer out there thinks they are an armchair lawyer since there are "obvious" skillset similarities between decoding software and decoding law. "Forget me" is very…

You keep mentioning how you're consulting on this issue at the moment and claiming that those of us more cautious than you just don't understand how European law works. Would you mind sharing a little more to justify that authority -- what qualifications do you have that we don't, what sorts of business are you consulting with and how much is compliance (including your advice) costing them, and why is your interpreta…

Hi Silhouette,

I'm not claiming anyone more cautious than me doesn't understand how European law works. That's just silly.

I also don't know what qualifications I have that you don't. What qualifications do you have?

The sorts of business I am consulting to are sales and marketing agencies based in the US. As an SME I work with their in-house council to help them understand what the business is doing. I also help define process designed to make compliance obvious and transparent surrounding areas of my expertise.

I have no idea how much compliance is costing them. I don't know if they look at it this way.

Your last "question" consists of some more straw man and a little too much hand-waving: By all means, feel free to point to any contradiction with a specific recital and I can try to address it. If you have another source who claims to be an expert, I can also try to explain why I may have a different opinion than them.

Re: GDPR – A Practical Guide for Developers (2017)

#177

I’ve been reading the EU’s General Data Protection Regulation, and it seems to contain certain loopholes that may be exploited by less than honest agents. The sad possibility is that the mere existence of such loopholes can push an otherwise law-obedient small companies towards mostly-ignoring GDPR in order to remain competitive. For example, there’s this huge “if” concerning personal data removal, reiterated in mult…

These sort of cases will be decided on by a judge. You'll at the very least have to make your decisions sound reasonable.

But yeah, these loopholes do exist nonetheless. The GDPR has been reported on as the most lobbied law in the history of the EU. It scares Google, Facebook, Microsoft et al.

Re: GDPR – A Practical Guide for Developers (2017)

#178
post #67

Earlier quoted context omitted.

If you're a European citizen, in a couple of months they'll legally have to (assuming they don't want to just ignore any European court judgements, which is possible but risky). I believe you can already delete your account and comments though?

Plus Hacker news doesn't ask for personally identifyable information in order to use it, unless you choose to put your full name in as a user.

HN has everyone's email.

With modern language usage analysis it would probably not be too difficult to work out who everyone is on HN who posts regularly. This is one of the reasons I post under my real name.

Re: GDPR – A Practical Guide for Developers (2017)

#179

Earlier quoted context omitted.

Plus Hacker news doesn't ask for personally identifyable information in order to use it, unless you choose to put your full name in as a user.

HN has everyone's email. With modern language usage analysis it would probably not be too difficult to work out who everyone is on HN who posts regularly. This is one of the reasons I post under my real name.

HN only has email addresses for members who provide it. It's not a requirement for account creation.

Re: GDPR – A Practical Guide for Developers (2017)

#180
post #91

Earlier quoted context omitted.

And it's also protected by the right of freedom of speech: the entity operating the git server has the right to inform the public of who committed which changes. The GDPR explicitly recognizes "exercising the right of freedom of expression and information", although I'm not sure how European courts would interpret this provision. But for an American entity without a physical presence or assets in Europe, any EU judgm…

How would the judgement be quashed by american courts? No american court has jurisdiction over European courts. For an entity without presence or business in Europe, enforcing a european court decision might be a problem, but that’s a different matter. I’m sure the EU will find a way if the sum is sufficiently high.

Sorry, I was sloppy in saying that the judgment itself would be quashed. What I meant is that any attempt to enforce the judgment would be quashed. Since (by assumption) the defendant doesn't any assets in Europe to pay the fine, enforcing the judgment would require going after the defendant's assets located in the US. American courts will typically enforce foreign judgments from 'friendly' jurisdictions, but if the judgment is incompatible with American law, American courts will quash any attempt to enforce the judgment in the US.

Of course, Facebook and other large American corporations can be expected to comply with GDPR, since the cost of compliance is much less than the opportunity cost of being excluded from the EU market.

Post reply on HN