4 ms·

> It does solve the problem with some businesses not offering exports in machine-readable formats and which data should businesses allow users to export in mac

by toolz 5y ago

> It does solve the problem with some businesses not offering exports in machine-readable formats and which data should businesses allow users to export in machine readable formats, every click, view, views on other sites with that sites cookie/callback? what is a common machine readable format? Literally all data is machine readable - what if the "common" format is purposefully complex and hard to implement right and you have to use paid libraries to do it correctly? These are things big companies can afford to do that kill small competition. and since they are a big company simply them using it makes it "common" by some definition since more people will use it by virtue of more people using their services. > If company A is "anti-social" (I guess), doesn't offer an export and want to kill their competitor B (who does offer export), how does the export tie into company A being able to kill company B? company A, being the dominate evil-corp can pay lobbyists to define the protocol for export in a format they define....company B (the small good willed company) already exports in a format, but now they are forced to change their existing systems resulting in a lot of work lost - that is effectively money stolen from company B Now, a reasonably pro-social reaction would be to allow both exported formats, but how difficult would it be to have lobbyists convince a non-technical governing body that their format is superior and should be used? Imagine a non-technical family member is overseeing some committee and facebook shows up with their amazing analytics and awesome data export tool with graphs, charts, everything. Do you think your non-tech family member will recognize that the underlying format is bad for small businesses? I don't think I'd expect a non-techie to understand the costs there. edit: further, are there SLAs for export uptime? what happens when bad PR hits a company and data export laws effectively mean a company is expected to export terrabytes of data within a day or so? Is that small company now legally liable because they can't handle that kind of load - which is further compounded by the fact they are getting data export requests because of bad PR to begin with? Does that company now have to choose between serving exports or keeping their service running? I'm sure if I spend an hour thinking of scenarios that could hurt businesses that are otherwise doing the best they can I can come up with plenty.

capableweb 5y ago
> and which data should businesses allow users to export in machine readable formats, every click, view, views on other sites with that sites cookie/callback? "‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;" https://gdpr-info.eu/art-4-gdpr/ https://gdpr-info.eu/art-4-gdpr/ - (1) > what is a common machine readable format? JSON, XML and a few others are candidates that are generally considered common. If you haven't heard about the term before you can find more information here: https://en.wikipedia.org/wiki/Machine-readable_data https://en.wikipedia.org/wiki/Machine-readable_data > what if the "common" format is purposefully complex and hard to implement right Then I guess the company is shooting itself in the foot if they make it harder to build the export functionality than it has to? The directive is not about being able to import data from any service, the directive is about being able to export your data in a machine-readable format. Not sure how much more clearer I can make this. > company A, being the dominate evil-corp can pay lobbyists to define the protocol for export in a format they define Company A is allowed to export the data in whatever data model they want, no lobbyists required. What it has to be though, is machine-readable. > company B (the small good willed company) already exports in a format, but now they are forced to change their existing systems resulting in a lot of work lost No, the directives nor laws around GDPR won't force a small company to change their export format. The directives are aimed at larger businesses that don't allow export at all, to get those companies to actually become user-friendly instead of user-hostile. You should really give reading the full GDPR a go, it's not that long nor complicated and explains everything you're worried about (seemingly at least). Here is the full version: https://gdpr-info.eu/ https://gdpr-info.eu/ And here is a simpler quickstart explaining broadly what GDPR is: https://termly.io/resources/articles/gdpr-for-dummies/ https://termly.io/resources/articles/gdpr-for-dummies/ Edit: > edit: further, are there SLAs for export uptime? what happens when bad PR hits a company and data export laws effectively mean a company is expected to export terrabytes of data within a day or so? Is that small company now legally liable because they can't handle that kind of load - which is further compounded by the fact they are getting data export requests because of bad PR to begin with? Does that company now have to choose between serving exports or keeping their service running? Again, I invite you to actually read GDPR before commenting further as both you and me spend more time answering each other than the time you could have taken to just read the resource you're commenting about now. Article 12 (3): > 1 The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. 2 That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. 3 The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. 4 Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject. If you can not handle running your service + the export in a way so people clicking the export gets their data within 30 days, I don't feel so bad about you actually just closing down your service instead, as the uptime in general must be very bad.
TeMPOraL 5y ago
I think you're approaching GDPR with a wrong mindset, perhaps one rooted in the US legal system. EU countries tend to put more weight to the spirit of the law than US does. In GDPR, many of the things seem technically underspecified, because they aren't describing implementation details - they're describing the principle behind them. For instance, what "common machine-readable format" means is obvious to everyone who does anything with digital data. For generic data, it's XML, JSON, CSV, you could probably get away with XSL(X) or DOC(X); for images it's BMP, PNG, JPG. Etc. If you think you have a valid reason to use something more niche, you can. If you're afraid someone will contest it, you can request an interpretation from appropriate regulatory body. If someone contests your choice, you can justify yourself - but if you're being purposefully obtuse, the ruling will be against you. The legal system gives you plenty of time to prepare, seek clarification, complain, dispute, get reprimanded - and ultimately comply, or, if you stubbornly refuse, get punished. Consider what would have happened if GDPR actually defined what "common machine-readable format is". Plenty of companies would have a valid reason to complain that the list of allowed formats is too narrow, and unsuitable for their particular use case. The law would have to be updated to reflect the fast-changing landscape of computing technology, or risk slowing progress by forcing everyone to maintain legacy technologies. Instead, GDPR, focuses on the guidelines to achieve the intended results, while leaving the implementation details for the industry to figure it out. It's better this way, than having regulators figuring out what's the difference between "cookie" and "local storage".

by toolz 5y ago

capableweb 5y ago

> and which data should businesses allow users to export in machine readable formats, every click, view, views on other sites with that sites cookie/callback? "‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;" https://gdpr-info.eu/art-4-gdpr/ https://gdpr-info.eu/art-4-gdpr/ - (1) > what is a common machine readable format? JSON, XML and a few others are candidates that are generally considered common. If you haven't heard about the term before you can find more information here: https://en.wikipedia.org/wiki/Machine-readable_data https://en.wikipedia.org/wiki/Machine-readable_data > what if the "common" format is purposefully complex and hard to implement right Then I guess the company is shooting itself in the foot if they make it harder to build the export functionality than it has to? The directive is not about being able to import data from any service, the directive is about being able to export your data in a machine-readable format. Not sure how much more clearer I can make this. > company A, being the dominate evil-corp can pay lobbyists to define the protocol for export in a format they define Company A is allowed to export the data in whatever data model they want, no lobbyists required. What it has to be though, is machine-readable. > company B (the small good willed company) already exports in a format, but now they are forced to change their existing systems resulting in a lot of work lost No, the directives nor laws around GDPR won't force a small company to change their export format. The directives are aimed at larger businesses that don't allow export at all, to get those companies to actually become user-friendly instead of user-hostile. You should really give reading the full GDPR a go, it's not that long nor complicated and explains everything you're worried about (seemingly at least). Here is the full version: https://gdpr-info.eu/ https://gdpr-info.eu/ And here is a simpler quickstart explaining broadly what GDPR is: https://termly.io/resources/articles/gdpr-for-dummies/ https://termly.io/resources/articles/gdpr-for-dummies/ Edit: > edit: further, are there SLAs for export uptime? what happens when bad PR hits a company and data export laws effectively mean a company is expected to export terrabytes of data within a day or so? Is that small company now legally liable because they can't handle that kind of load - which is further compounded by the fact they are getting data export requests because of bad PR to begin with? Does that company now have to choose between serving exports or keeping their service running? Again, I invite you to actually read GDPR before commenting further as both you and me spend more time answering each other than the time you could have taken to just read the resource you're commenting about now. Article 12 (3): > 1 The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. 2 That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. 3 The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. 4 Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject. If you can not handle running your service + the export in a way so people clicking the export gets their data within 30 days, I don't feel so bad about you actually just closing down your service instead, as the uptime in general must be very bad.

TeMPOraL 5y ago

I think you're approaching GDPR with a wrong mindset, perhaps one rooted in the US legal system. EU countries tend to put more weight to the spirit of the law than US does. In GDPR, many of the things seem technically underspecified, because they aren't describing implementation details - they're describing the principle behind them. For instance, what "common machine-readable format" means is obvious to everyone who does anything with digital data. For generic data, it's XML, JSON, CSV, you could probably get away with XSL(X) or DOC(X); for images it's BMP, PNG, JPG. Etc. If you think you have a valid reason to use something more niche, you can. If you're afraid someone will contest it, you can request an interpretation from appropriate regulatory body. If someone contests your choice, you can justify yourself - but if you're being purposefully obtuse, the ruling will be against you. The legal system gives you plenty of time to prepare, seek clarification, complain, dispute, get reprimanded - and ultimately comply, or, if you stubbornly refuse, get punished. Consider what would have happened if GDPR actually defined what "common machine-readable format is". Plenty of companies would have a valid reason to complain that the list of allowed formats is too narrow, and unsuitable for their particular use case. The law would have to be updated to reflect the fast-changing landscape of computing technology, or risk slowing progress by forcing everyone to maintain legacy technologies. Instead, GDPR, focuses on the guidelines to achieve the intended results, while leaving the implementation details for the industry to figure it out. It's better this way, than having regulators figuring out what's the difference between "cookie" and "local storage".