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.
How GDPR Will Change The Way You Develop
681–690 of 710 posts
Re: How GDPR Will Change The Way You Develop
#682Earlier 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.
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
#683Earlier 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).
Re: How GDPR Will Change The Way You Develop
#684Earlier 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.
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
#685Earlier 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…
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
#686Earlier 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 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
#687Earlier 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…
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
#688Earlier 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…
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
#689Earlier 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.
Re: How GDPR Will Change The Way You Develop
#690Earlier 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…
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.