101–110 of 239 posts
Earlier quoted context omitted.
> If password is lost then tough luck This is your personal opinion of how it should work, not GDPR.
I doubt that a black-hat attacker is going to file a lawsuit to obtain someone else's personal information.
If you tell someone requesting their own data under GDPR “tough luck, you lost your password,” that could invite remedies under the law.
Earlier quoted context omitted.
One of the major goals of GDPR is to discourage firms from retaining personal data in the first place. It did not used to cost them anything so they kept it regardless of its use. Now that there are big risks to keeping it these firms have to think twice about it. This "cobra effect" is one more reason NOT to retain personal information in the first place.
And yet other laws require the collection and retention of sensitive user data, in particular any service that allows for transmission of large amounts of money (crypto exchanges were a good example).
GDPR identity verification as a service would be an amazing thing to have. Articles like [0] bring up a sad irony: in order to verify someone's request to delete their information, you need to obtain information from them in an unusual way that you may not have built infrastructure to easily or automatically delete.
[0] https://www.braze.com/perspectives/article/gdpr-compliance-d...
Earlier quoted context omitted.
This was actually one of the risks we identified when looking at GDPR for my own businesses last year. Given that in some cases all we have is an online account with minimal personal details, how can we possibly verify their identity to an acceptable standard if someone does send us a GDPR subject access request of any kind? If they have some sort of account with us already and that has associated ID and security che…
Government officials created an untenable law in the name of the technological boogey man?!
Earlier quoted context omitted.
> it also makes companies think twice whether it's really necessary and worth it The simple fact that someone has an account at a service can be private information. For anything requiring even a modicum of persistence, keeping these data is tough to avoid. I think most of HN agrees GDPR’s goals are good. It was just sloppily drafted, passed and implemented.
GDPR does not care about privacy. It cares about personal identification. Such as full name and address, and a bunch of other protected things. Why would any random service request, process or more importantly store these?
So they can identify users for purposes of complying with GDPR? (For example, to handle the data requests highlighted in this post.)
This is the problem with overly aggressive legislation. The big companies performed well, the small companies ignored the law, and the medium sized companies tried to comply and failed. You can’t legislate good behavior because people will always find a way around the laws. The legal philosophy behind GDPR seems to be nothing more than to make everyone a criminal and then choose who to prosecute, and in that case why…
I wouldn't agree that the medium sized companies tried to comply with the GDPR and failed. Yes, they tried to comply with that particular request but the failures suggest that they didn't even try to be GDPR compliant in the first place - if they had done so, then they would have had assigned a data protection officer who would have long ago asked themselves the question "what do we do in case of a personal informati…
Then I see stuff like:
>if they had done so, then they would have had assigned a data protection officer who would have long ago asked themselves the question "what do we do in case of a personal information request?"
If I have to hire/create an entirely new position at my company these laws are not straightforward or common sense.
Earlier quoted context omitted.
> You can install it on your PC or Mac if you want. 1. Same problem. There is still no Linux client, for example. 2. It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there. 3. Many applications are only useful on the go, such as Swish. > Access delegation not being part of BankID itself is a feature not a deficiency, it would undermine the concept…
> It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there. I'm not sure which point you're referring to with the mention of differing API. Mobile BankID is the same API as regular BankID (but services can choose which they accept); as for other Swedish e-ID services, there are aggregator services. Re: most, really? There are some that don't accept n…
And therein lies the problem.
> Re: most, really? There are some that don't accept non-mobile BankID, but it is uncommon in my experience.
You already refuted this yourself in https://news.ycombinator.com/item?id=20656033.
> I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
BankID could have designed their API such that "person performing the action" and "subject the action applies to" are different fields.
But even that is unnecesary. Who actually requested the action only concerns the subject, not the third party carrying it out. BankID could simply log "Delegate A requested entity B to perform action C on behalf of subject D" and show it to D, while keeping B completely in the dark.
This is a reflection of the fact that we have no good way for someone to digitally prove their identity. Some countries are getting close-ish - Denmark's NemID system, for example, is used by a lot of financial institutions. However, there remains no easy way to make ad-hoc verifiable statements like 'I am John Smith and I authorise you to send this data to xyz@example.org'. Governments, please solve this problem! Es…
It was also marred by very bureaucratic policies, for example to get information on account usage (e.g. how many times was my account used, from which IP, to access which site) you would need to file a police report first, and it supported 2FA very early (through SMS service, now via mobile app as well) but the end user could not forcibly enable 2FA, only the target service could determine if they wanted two-factor authentication on their site. Luckily, those have been fixed.
Would be nice if they supported open standards like OAuth though.
Earlier quoted context omitted.
BankID is horrible. It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5. It also doesn't support anyway to delegate access, either to people ("my partner should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").
> BankID is horrible. The rest of your post does not back up this claim IMO. > It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5. At least here in Norway you can get a standalone hardware 2-factor key. > It also doesn't support anyway to delegate access, either to people ("my partner shou…
You can get the key embedded on a smartcard, but it's still coupled to their proprietary driver (which only works on Windows or macOS, of course).
It's also a separate API and not as widely supported as Mobile BankID.
This is pretty appalling, really: "Overall, of the 83 firms known to have held data... 24% supplied personal information without verifying the requester's identity." Want someone else's personal data? No need to "hack into" any systems; just ask for it!
This was actually one of the risks we identified when looking at GDPR for my own businesses last year. Given that in some cases all we have is an online account with minimal personal details, how can we possibly verify their identity to an acceptable standard if someone does send us a GDPR subject access request of any kind? If they have some sort of account with us already and that has associated ID and security che…
1. The user requests information about them but claims that they lost the password and the email address.
2. The company sends a form (in English) that basically asks for the information on the id (name, date of birth, etc) and the information being requested (ex: password reset).
3. The user prints this form, fills it out and attach a copy of their ID.
4. The user goes to a notary in their country to get the signature and ID verified.
5. The user sends the form to the client's country Ministry of Foreign Affairs to get the notary's signature verified.
6. The user sends the form to the embassy of the company's country to get the Ministry of Foreign Affairs seal/signature verified.
7. The user takes a picture of them holding the form and sends that picture via email or similar to the company.
8. The user sends the form via snail mail to the company.
This process can be shortened if both the company's country and the client's country have ratified the Apostille Convention, formally known as the Hague Convention Abolishing the Requirement of Legalisation for Foreign Public Documents.