Live data from Hacker News

Ask HN: Why are law documents (GDPR) so difficult to understand?

news.ycombinator.com

71–80 of 85 posts

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#71

I found this regulation put too much burden on small businesses. It's not. You are wrong. What if this law will be abused as a tactic to attack business competitions? Why would that happen? How do you understand this "security appropriateness" of the above text? How can you be sure your understanding is correct? You use your knowledge or regulation to read and make decisions. If you don't have the required experience…

The hiring a consultant/lawyer thing has potential to be troublesome for a lot of solo devs. Such services are not cheap and it’s not uncommon for independent devs to be very much cash-strapped.

I wonder if this means we’ll start to see sites/services start out as US only and only become available in Europe once finances are no longer an issue.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#72

I have 2 concrete questions to ask on this topic: 1. is email address considered personal information? 2. is cookie, in a form of random hash code, be considered personal information?

Yes and yes, as both are "personal identifiers" -- "anything that you could conceivably use to identify a person within a larger group".

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#73
My favorite website is this: https://ico.org.uk/for-organisations/data-protection-reform/...

They have explained GDPR in reasonably everyday language, with checklists and examples. That site should be your first choice.

If you are a developer, you should check https://github.com/gdprhq/GdprHq.Io.ClientSdk - you can find interfaces and default implementations. For example, to implement the right to erasure (to be forgotten) in your app, you'll need to erase personal data and to inform an individual that you've done so. Even though actual erasure might be tricky, at least you know what you need to implement to be compliant. However, note that having the app GDPR compliant isn't the same as having the business compliant; primarily, GDPR is a set of rules and processes that apply to organizations.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#74
post #21

I found this regulation put too much burden on small businesses. There's a very simple way around that problem - don't ask for your user's data. The GDPR is about making sure you do your best to protect what they share with you. If they don't need to share anything then there is no burden on you to protect anything. In my opinion this is the ideal outcome. If you gather their data then there really should be a burden…

Most websites ask for users' email used as the account name. From what I have read on this topic, email address is considered a personal information. > the necessary work to make sure you've done at least the minimum to protect what they've shared, > especially if you're profiting from that data. The OP was willing to comply, she asked what "necessary work" means and how to define "minimum". Also it seems to me that…

So what? Don't ask for an email address. Use an OAuth provider instead. Or let people use the server without signing up. Or assign users a random number as their log in.

There are plenty of options available if you don't want the "burden" of securing your users private data, but ignoring if isn't one of them any more. This is a good thing.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#75
post #21

I found this regulation put too much burden on small businesses. There's a very simple way around that problem - don't ask for your user's data. The GDPR is about making sure you do your best to protect what they share with you. If they don't need to share anything then there is no burden on you to protect anything. In my opinion this is the ideal outcome. If you gather their data then there really should be a burden…

Most websites ask for users' email used as the account name. From what I have read on this topic, email address is considered a personal information. > the necessary work to make sure you've done at least the minimum to protect what they've shared, > especially if you're profiting from that data. The OP was willing to comply, she asked what "necessary work" means and how to define "minimum". Also it seems to me that…

> Most websites ask for users' email used as the account name.

> email address is considered a personal information.

As another poster mentioned - just don't use email.

Or if you must then just make sure you only do the minimum you have to with it - e.g. Don't send it to a third party, have a way to delete it when a user wants to close their account (unless you have a good reason to keep it - e.g. to match to a financial transaction).

What's the difficulty?

GDPR shouldn't be a burden for a small business unless the business is in the personal data space.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#76
post #35
post #3

You don‘t really expect a law to specify which hash algorithm you‘re supposed to use, do you? The answer is simple: the law will stand for a long time, and legislators know their limits. Unlike many engineers, unfortunately. Having courts interpret laws, with help from experts, is not a bug, but a feature!

Exactly. The law should express the intent, not the implementation means, which can—and does—improve over time. Imagine a law mandating SHA-1 in 1999; it would end up enforcing a security problem today.

South Korea did a shockingly similar thing to your example in 1999, which enshrined Internet Explorer's use long after the rest of the world had moved on.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#77
The magic phrase you want for Mr. Google is “legislative drafting”. In fact there is a long-existing methodology in government for writing laws and regulations. Here, for example, is the US House of Representatives’ guideline document: http://legcounsel.house.gov/HOLC/Drafting_Legislation/Drafti...

Chesterson’s Fence.

Having said that, I am a tax lawyer and I view the output of the Federal government as astonishingly bad. Poorly-written laws cause millions or billions of dollars of friction to taxpayers.

There are many reasons for why laws are written so poorly:

- the people are stupid or malicious or lazy (appealing but this conclusion reveals more about its holder than its object)

- the task of writing the law is impossible

- the people writing the law are technically deficient in this style of writing

I’m sure you can think of others.

There is another factor. After you have been a lawyer for a long time, you see the folly of believing it is possible to write binary yes/no rules to govern human behavior. Politicians believe this. An economist would call this a belief in a static economic model.

Thus, politicians think “we will impose this tax and collect a lot of money”. Then they are shocked because people change their behavior and avoid paying the tax. I do not mean maliciously. I mean like a toll-road. Imposing a toll for driving on a road will affect the traffic patterns and fewer people will drive on the road. Less money will be collected. Economists think that way. Politicians are not as . . . astute. (That statement reveals more about me than it reveals about politicians as a group). :-)

Back to why laws are so badly written. There is a second reason and it is mentioned in another comment. Lawyers and judges are comfortable with ambiguity. In tax law, we often ask for penalties to be waived for “reasonable cause”. WTF is that? Yet it (more or less) works. At the margin, some people get away with stuff that “should” be penalized. And some people are penalized “unjustly”.

This discovery in law is the result of centuries of evolution. It works. So if you see ambiguity, understand that it is a feature, not a bug.

But for tax law, quite often I think of the rules as a broken set of algebra rules written by teenage sociology majors while drunk, for bribes. Over decades. Again, this reveals more about me than the United States Code and the Treasury Department.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#78
When reading a regulation your first priority always needs to be, answering the question, "Who does this apply to?"

If the rule applies to people who do x, and you encounter a requirement that is clearly burdensome, then you should reevaluate whether or not your really want to do x.

ie... The new liquor regulation is 10^100 pages long, but page 1 says we dont have to read the rest if we just serve wine and beer.

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#79
post #2

Lawyers wished to create a 'walled garden' for their knowledge and methods. Doctors do the same and the churches also did it. These people charge fees for access to this knowledge and do not want easy access to the general public. recent advances in AI endanger many jobs at law firms and medical practices and may result in fewer jobs - at law firms at least. I expect the medical and legal lobbyists will bribe our ele…

This is utter nonsense and you have no basis for stating any of it.

I see, I gored your sacred cow. It is well know that all the trades and professions had their private languages so they could discuss things and their customers did not know what they discussed. Latin for the church and medical trades. Lawyers still have their arcane tongue. Most of the others, butchers, tinkers, bakers etc had their trade language. I am from England and had a butcher and a baker in my family, and they told me bits of their language. True, it was not as comprehensive as English. I also grew up in a Yiddish speaking family, as my father was a major on the Burma Road and we housed a family of displaced persons from Poland. Mother, Father, Bubba, and two young boys - all Jewish, and me and my Mom - I soaked up yiddish and by the time the war was over I could speak it as well as most kids of 9. I used to startle the Jewish shop keepers, after WW2, when we emigrated to Canada, when this little Brit kid could know whatever they said. They were in the habit of carrying on conversations, secure in their privacy - Hah.

It stood me in good stead because I made many Jewish friends in Toronto in high school and college, because in those days there was a major barrier to many Jewish people in business circles. No brokers etc. This all changed in the mid 60's after a few prosecutions, and now it is wide open to all.

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

Re: Ask HN: Why are law documents (GDPR) so difficult to understand?

#80
post #29

Earlier quoted context omitted.

I really like this explanation. I think code could be thought of as extremely formal requirements interpreted by the computer extremely rigidly (called instructions). And the process of making software is a translation from high level requirements specified in all sorts of ways (like this law text) to gradually lower levels of abstraction. We meet somewhere in the middle by using apis/sdks. And I think programming la…

I disagree with “code can be thought of as formal requirements” - perhaps if you twist the meaning of the word requirement, yes. This analogy puts us into a place where we mix intent and implementation and make them the same. It doesn’t allow for bugs in a sense. This is why I dislike analogous thinking!

I was thinking requirements in the sense of «tell don’t ask». And I reslly believe that if we can define intent as implementation (on a high level of course) we have solved many problems. For example if you want to sort transactions by time in a accounting system you should only have to ask for a sorted collection ( sort(transactions)) and not worry about what way the data is sorted. Then the people developing the library for sorting will be able to optimize the implementation independently. This is something we do today, but I think this concept can be taken a lot further if we think of avstracting even higher. At the same time I think this requires rigor and extremely well defined boundaries between layers, so we dont end up with a mess like java null pointers.
Post reply on HN