Live data from Hacker News

How GDPR Will Change The Way You Develop

smashingmagazine.com

681–690 of 710 posts

Re: How GDPR Will Change The Way You Develop

#681
post #633

Earlier quoted context omitted.

You need the IP records for jurisdictions that require long term retention for law enforcement requests including copyright infringement. So you must delete them and also keep them.

Do you know which jurisdictions and laws that includes? This sounds like the Investigatory Powers Act in the UK, though I haven't heard of similar laws in other liberal democracies.

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

Re: How GDPR Will Change The Way You Develop

#682

Earlier quoted context omitted.

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.

Re: How GDPR Will Change The Way You Develop

#683

Earlier quoted context omitted.

The collective economic effect of that will be massive. Please do. And realize that you are ceding the single largest market to your competition.

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.

Re: How GDPR Will Change The Way You Develop

#684

Earlier quoted context omitted.

How would that be useful to you? 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.

The China subsidiary would be able to use the data in China, to advertise and acquire more Chinese customers. Of course, I suggested that more for the situation where the EU had data privacy laws, and China required intense tracking of customers.

You don't need subsidiaries for that.

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")

Re: How GDPR Will Change The Way You Develop

#685

Earlier quoted context omitted.

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 give…

> 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). Some discussions: https://seql…

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.

Re: How GDPR Will Change The Way You Develop

#686
post #572

Earlier quoted context omitted.

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 techni…

"can you (easily) recover the data" 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.

Re: How GDPR Will Change The Way You Develop

#687
post #634

Earlier quoted context omitted.

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 some…

> 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.

Re: How GDPR Will Change The Way You Develop

#688
post #452

Earlier quoted context omitted.

> Can software engineers become P.E. in the U.S ? 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 tak…

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…

> 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?

Re: How GDPR Will Change The Way You Develop

#689
post #387

Earlier quoted context omitted.

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 tha…

Holy shit what. 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.

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.

Re: How GDPR Will Change The Way You Develop

#690
post #177
post #81

Earlier quoted context omitted.

No. Professionals in engineering or the trades have to know the regulations that govern their industry and abide by them. What many SVers call "innovation", other industries would call "reckless". How embarrassing for us! EDIT: In terms of regulation, we're practically chiropractors.

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 imp…

> How many local UK construction companies know the building codes of Japan? None.

If those local UK construction companies want to do business in Japan they'll have to know the building codes of Japan.

But seriously, the GDPR standardize the body law for the whole Europe. That makes thing easier for devs.

Post reply on HN