It's up to residents of other to demand their governments give equal protections. We all know that won't happen in America.
And really, I've done all I can do. I've talked it up, given powerpoint presentations, and emailed a comprehensive report about penalties for failing to comply as well as a project outline for becoming compliant.
In the beginning of Camarades.com/WW.com we had a lot of interaction with LE because of all the stuff our users got up to online and we tried very hard to comply with the various laws. It did not always work perfect but it worked well enough that we earned the respect of the various LE contacts that we had. I can only imagine how it would have ended if we had thumbed our nose at them. Going global means you need to change your attitude.
It's been quite some effort but for my business so far it's been a net positive because it made me rethink, clarify and streamline my processes.
Secondly, though not always the case, I might have to process their respective customers' data in some way in order to do my job (by having access to a production database, for example).
So, yes, GDPR absolutely does apply to my business.
Basically, it means that what's been best practice all along is made explicit. So, in most case this doesn't affect the actual workflow all that much.
However, in the past occasionally clients could be quite liberal in handing out access to their production data. GDPR definitely has raised awareness that this isn't something to be taken lightly.
No, I didn't say that. GDPR doesn't mean that you have to ask for consent in each and every case. If as a business you have a legitimate interest to store client data for a specific purpose you don't have to ask for explicit consent. Being able to contact clients in the future who contacted you first constitutes such a legitimate interest.
As for the right to be forgotten: Sure, why wouldn't I? If they don't want to be contacted anymore and want me to delete their contact info I'm happy to oblige.
I don't actually want to be profitable for you if I'm not paying for the service.
Certainly, some folks have opted into some heroics getting all our microservices and datastores audited. But it's good to do that periodically anyways, so we made the audit a multi-purpose affair.
On the development side, we've had to accelerate some 'nice to have features' that we had planned for later, to this month. Things like scheduled deleting of old customer data, migrating to a more robust SQL system that supported 'encryption at rest' etc. Things that would have had to be done anyway.
As we are a 'processor' for our clients, we reviewed and updated some of our existing infosec policies and procedures, and produced a very detailed set of 'GDPR' docs to satisfy customers asking for evidence of our compliance efforts, and to provide data mappings, impact and risk assessments etc. We already had most of this done internally anyway so we just needed to 'prettify' it and change the language/terms in our 'Electronic Information Security Policy' document to match the GDPR.
We also wrote up a DPIA document about our internal systems.
All of this work took time - perhaps about the equivalent of 2-3 weeks to plan, collate and draw the diagrams and workflows for things like our security incident response plan and how we would sub-process subject rights requests; like when a client receives a 'Right to erasure' request and asks for assistance.
Overall that work was not difficult and did not cause any headaches. What has been a pain has been responding to all the clients who send us various compliance 'questionnaires' (spreadsheets) expecting tailored responses - fortunately, in the main I was able to answer "see document ref xxxxxx, section nnn".
What I am seeing now is the late-arrivals throwing in (demanding) 'for compliance' every conceivable infosec feature they have read up about - one today insisted we must now implement in-memory encryption! Many of these recent demands are not mandated by the GDPR and so are being handled as contractual changes and new feature requests so the sales team are having discussions to explain our stance and see if the customer wants a quote to amend their service and contract!
not a load of work, but we have to pause some business development opportunity so that we have hands to put on this.
We didn't have much trouble. Someone was assigned last year from our security team to teach and consult other teams within the company to keep their products compliance.
Even before going for GDPR everything about user data was very strict so don't remember if we (at least my team) did anything new.
We always had data anonymization pretty much everywhere, no production access even to our deployment team, no third party company is allowed to store information or even cookies from our users, a clear and short page for our users to tell them which companies have access to some of their data (ex. delivery company). We always have been obligated to report a data breach to the government and users if it happens.
It is a very long list, and goes down to stuff like even HR recruiter is not allowed to keep applicant information after X amount of time.
All of that also means sometimes we are unable to do something fancy with users data to improve our products. Or use some third party services because the third party company doesn't look reliable or they want to access user data.
Both my colleagues and I have much stricter personal guidelines to data protecting than required by our employer, our chief security office and the GDPR, so it's not really an issue.
I'd say this is all good stuff, and in most cases we were already doing it, but it is difficult to retrofit in one go.
Going forward it will be a lot easier though as new projects will simply be designed better from a security-perspective.
Does GDPR made all NNTP services illegal?
I'm asking it because I was developing an online forum application that will publicly display your posting IP and registered email address, and sync posts with other sites.
If GDPR made that illegal, that could be a bad news for me.
Please don't do this.
Apart from my own rational self-interest, I'm saying this as a subscriber to various free-software mailing lists, which occasionally get requests from someone to remove archives of support emails they sent 10 years ago. It's pretty rude to publicize the problems someone had and their frustrated response from years in the past, and make it Googleable by their name.
(Also, if by any chance you want to publicly display this as a means of deterring bad behavior of any sort, spam, rudeness, etc., it's unlikely to work - the people intent on bad behavior have proxies and anonymous email accounts, and the non-technical folks who never even thought of bad behavior won't think to protect their identity this way, so it will only hurt the people you don't want to hurt.)
Thus, a mechanism must be setup to allow users to manage their content on other sites. The mechanism that I currently planed was to use email verification (if (User's email === poster's email): They're the owner of the post), which requires all sync sites knows the email address (as an universal identifier) of the content owner.
To me, that means I need to share user's email with other sync parties which may not under my control. Because of that, I think it's sanctimonious to tell user that their email is under protection, I rather letting user be very aware about their email will be publicly displayed.
Another reason to publicly display users email is because I don't want to implement private message features (Which require to save private information), so if user's can know each other's email, they could just make content with their emails.
(If you're worried about not just servers changing but clients changing, and needing to get the key over, there are protocols for efficiently and securely transferring information between client computers, using a very short password that doesn't need to be kept private after the transaction. magic-wormhole implements this sort of thing.)
This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to. Requiring that my email is public does not provide me this control. You can do what HN (which doesn't implement PMs) does and let people have an optional public profile, where they can list a way they want to be contacted by other users if they want.
It can, as long as the email change request can be synced as well. It may have some security problem need to be resolved, but I think it can be worked out.
> Can you do the same thing with a cryptographic signing key or something, instead?
It's actually an better idea. If I can implement something like PGP (With maybe WebAuth), then user only needs to submit their public key. When authentication is needed, server will sends challenge (Message encrypted by user's public key), then user decrypts it with their private key, send the decrypted message back to server for verification.
However, I'm still figuring out the whole WebAuth thing, so no decision is made yet.
> This may or may not apply to your site, but, in general I don't want other users of a website to be able to PM/email me unless I specifically authorize them to.
I actually like to encouraging user to make contact by themselves with their emails, because service email is decentralized and controlled by users (At least they have better control of it than a website). Also, user may left a website but still using their email.
However, I know in real world, people don't like to be bothered, so make their email public could be a problem. I guess I need to rethink it a little.
They're actually not hurt by doing this: their business model is selling you a pdf report in exchange for money. The transaction handling is literally only reason to touch any personal data.
The only difference is that we will have higher fine if we don't comply. And we have had an external Data Protection Officer for a long time already.
As a result we have have been triggerered to perform some well-over-due security reviews, thinking about security processes and data compartmentalization, documenting some procedures etc. I think it's by far a net-good, even as relatively small company.
I am easily tracked to my place of employment so I don't want to get into too many details, but we were doing things ethically but still had a non-trivial amount of going through, dotting our i's and crossing our t's, making sure that there weren't pockets of unknown data, putting together plans in case someone asked for data retrieval or deletion, etc.
The longer a company's been in business, the more onerous the task is. I can't imagine what it would be like for a large company with mainframes still around.
It helps that collecting data on individuals was never a part of our strategy to begin with.