How does this work in line with your views on registration systems? I'm about to be releasing a product which also is a one-time digital purchase and I plan on just having a generous guarantee. I was planning on having no licensing system because frankly it's more headache than it's worth - the target audience will be happy to pay for the product and people who don't want to pay won't be paying anyway. Do you think this is a fair assessment? Do you think it's worth having a very basic registration system or none at all?
> Although what Spotify has done, or failed to do, by handing over data to whoever is logged in on an account, could be considered irresponsible, it is in no way illegal – and, in all likelihood, is generally the norm.
Standard security practices: not allow delivery to a new address without reconfirming credit card details, sending email confirmation upon login from a new location/device, and in the more extreme cases, 2 factor auth.
It sounds very much like this journalist is trying to make a mountain out of a mole hill.
The real story is that Deliveroo does not handle fraud properly. This is a much lesser crime than what they are being accused of.
The author wants to make it seem like Deliveroo has had a data leak and are trying to hide the fact. There is no evidence of this, but if it did turn out to be true then the author would be able to claim that they broke the story.
Yeah - it boils down to ye olde case of people reusing passwords. Half of the article talking about GDPR and the ICO is irrelevant.
What's happened is she has an easy/reused password that's ended up in a breach, fraudster locks her out of the account and offers discounted deliveroo orders to their customers and she gets charged. That's it.
It sounds like Deliveroo could step up their security then, as they don't seem to be doing much to catch credential stuffing, suspicious/fraudulent orders, etc. They could be doing way more.
If I recall, there's no distinction between an en masse data leak and someone being able to access your personal info without authority under GDPR. Both are a data breech. It seems like many people have been affected by this too so clearly Deliveroo doesn't have the mechanisms in place to protect user information. The fact unauthorized people can spend your money through Deliveroo is even worse.
Deliveroo are responsible for the data you give them. If they fuck up and allow unauthorized people access to that data, they're in breech of the GDPR.
If they haven't informed ICO (and equivalent in any country within GDPR rules) within 72 hours of each breech, they're in even deeper shit. First, they have to be clear about the scale of the breech and what exactly has gone wrong. They've got to be able to demonstrate the steps they've taken to mitigate the issue and prevent it happening in future. If people are complaining on a regular basis for months, they've not done that.
Do you have a source for that? If that is the case then pretty much every major website is in breach. Credential stuffing is rampant and very easy to do these days. It's not the website's fault that the user gave out their password.
However, I do agree that Deliveroo needs to do more to protect users against this. 2-factor authentication, email confirmation from a new IP, re-entry of card details when ordering to a new address are all simple ways to handle this. Deliveroo has not prioritised this because their main priority is growth.
"A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data."
The key part being "unauthorised disclosure of, or access to, personal data."
So does credential stuffing qualify - In my opinion yes, as it is unauthorised access to personal data.
They then go on to say
"When a personal data breach has occurred, you need to establish the likelihood and severity of the resulting risk to people’s rights and freedoms. If it’s likely that there will be a risk then you must notify the ICO;"
And again, the ability to place orders and deliver them to a new address charging the existing credit card I think qualifies as a severe and likely risk.
Edited to add: In the absence of any legal precedent I’d challenge you to find any lawyer who’d confidently say that credential stuffing definitely doesn’t meet the criteria.
That would be an interesting development. It means that either:
- is it illegal to not have 2FA; I’m not against that, but it feels… excessive;
- every website, including small irrelevant ones, with a password (like HN) needs to crawl the darker internet to check for leaked lists of email/passwords; that would make those unsavoury forums crawl with solution vendors; it would also make it illegal to not find the most obscure ones; in other words, a non-option;
"establish the likelihood and severity of the resulting risk to people’s rights and freedoms. If it’s likely that there will be a risk then you must notify the ICO;"
So if it's a small irrelevant website, there isn't likely to be a high or severe risk to that "breach", so they should be ok.
In terms of options, I think there are more, mostly around sites getting more sophisticated at defending against credential stuffing attacks - treat logins as more suspicious if they are from a new device, new ip, use a password that you know is in a breach list (have i been pwned), etc. and put in place a 2nd factor like email confirmation of the login even if they haven't turned on 2FA. Or at least restrict access to sensitive parts of your site if the login was suspicious until you can verify it was an authentic login.
'So if it's a small irrelevant website, there isn't likely to be a high or severe risk to that "breach", so they should be ok.'
To be clear, no website, depending on passwords alone, can know if an access was authorized by the person who is the subject of the account. Therefore, it would seem that the only sites that can use password-only authentication without risk are those that hold no personal information about their customers. According to your own interpretation of the law, some of your proposed mitigations would not be sufficient to eliminate the risk, if any personal information is held.
>> According to your own interpretation of the law
Look, I am not a laywer, and I am happy for someone to correct me here, but this is the wording of the law:
"A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data."
Is there anything in that sentence that means a successful credential stuffing attack would not fit the criteria?
a) the data wasn't breached through the credential stuffing attack, it was breached at an earlier time on another site.
b) the credential stuffing attack itself is authorized access (because from the site's perspective, the user provided the correct username and password), not unauthorized access.
>> a) the data wasn't breached through the credential stuffing attack, it was breached at an earlier time on another site.
Remember GDPR is specifically concerned with "A personal data breach"
The original breach that led to the password being leaked was likely also a personal data breach (unless the only thing the hackers managed to access was the username/password database - and even then email address can constitute personal data in some cases), but there is definitely a personal data breach as a result of the credential stuffing attack (in the Deliveroo case, more than likely full home address, possibly other addresses too like work, possibly name, some level of credit card data, order history, etc.).
>> b) the credential stuffing attack itself is authorized access (because from the site's perspective, the user provided the correct username and password), not unauthorized access.
It's certainly authenticated access, but I think you'll struggle to convince a lawyer that it was authorised.
I am not disagreeing with your position that such an access is not authorized by the person whose confidentially is compromised, but the phrases from the UK ICO that you quote in making your argument do not say that the mitigations you propose would provide an adequate defense for the website provider, either. Taken in isolation and at face value (which is what you do to make your case), those phrases lead inevitably to the conclusion that password-only authentication cannot possibly suffice as ICO-compliant authorization for access to any personal data whatsoever.
So if someone hacks your email because you didn't have sufficient protections in place, does that make the email provider liable? Seems like an argument that falls apart very quickly.
Yes, exactly that if the email provider hasn’t put in place sufficient defences. Why wouldn’t they be liable? They have a duty of care under GDPR to protect your personal data. If they are negligent in that duty then absolutely they should be liable.
I'm not saying Deliveroo isn't in the wrong here - they absolutely should have more defenses, but I still think this argument makes little sense. What if they have the defences in place but you choose to disable them? Who is liable then? I personally have 2FA on my GMail, but plenty of people choose not to - is it Google's fault for not forcing it on them?
You’re forgetting something. This isn’t my argument. This is what GDPR states. Unauthorised access to personal data constitutes a data breach. Does someone accessing your personal data who is not you using a stolen password count as unauthorised? Yes.
It will ultimately come down to a test case, but as I said before, you will be hard pressed to find a lawyer who would tell a company that they definitely won’t be liable.
I think unauthorised has a fairly clearly defined definition in the English language (without permission or authority). And I’m fairly sure that’s the definition already used in courts of law. So in the absence of any contradicting definition in GDPR (and there isn’t) I would be pretty confident that is the definition that would be used.
But even so I struggle to think of a definition where accessing someone else’s account without their permission or authority wouldn’t be classed as unauthorised.
For what it’s worth, it’s very common for close people to share their Deliveroo account, a bit like Netflix.
I would never but one of my two housemates was very confused why they couldn’t have my password so that they could look at the menu and each add their option to the order. (The third housemate was also a developer so he was surprised that I could remember it and I got sermoned about 1Pass over pizza.)
I also have heard of cases of close (female) friends who know each other’s password; when one had a health incident (miscarriage), the other took upon herself to order for the first one, to comfort her. She tried from her own account but failed (couldn’t remember the name of the restaurant), so connected to her grieving friend’s account, changed it to use her debit card. It was fully appreciated, but a surprise.
“Authorised” in that sense falls somewhere between:
- I know who those people are;
- we are part of the same household;
- I know that they can have access to my account;
- they made sure that I know they are on my account;
- I actively allowed them to be on my account right now;
If someone steals a key and unlocks a lock, is that considered "unauthorized access?" From the perspective of the person whose key was stolen, absolutely. From the perspective of the lock, no, the access was authorized.
We define terms in statutes and contracts for a damn good reason.
That's the problem with GDPR. It leaves much to be defined by ratifying member states. For example, it says you need a Data Protection Officer if you do "large scale" processing. There's no definition, no threshold defined for "large scale". You might not find the definition for unauthorized access in the GDPR and it may depend on jurisdiction.
I'm not sure why this is being downvoted. All I am doing is pointing out what the current law is under GDPR. You may not agree with the law, but that doesn't change what it says.
> there's no distinction between an en masse data leak and someone being able to access your personal info without authority under GDPR. Both are a data breech. It seems like many people have been affected by this too so clearly Deliveroo doesn't have the mechanisms in place to protect user information. The fact unauthorized people can spend your money through Deliveroo is even worse
Well, the distionction can be as easy as someone hacking the company vs. guessing your password. What is the company to do to protect against the latter?! After all, the password is the authorisation, so I would even claim it's not unauthorised access...
There are many things they could do. For starters they could verify (email, 2 factor, something) unusual sign ins - for example sign ins from a new IP, especially if that IP has a higher risk profile (data center, known vpn, tor exit nodes, different registered country, etc.), or sign ins from a new device.
That'd be a valid excuse if you're not safeguarding personal and sensitive data. But is that the most you can do to protect the addresses and some level of access to somebody's money?
I have lived in central London for 25 years and never experienced this, nor do I know anyone who has.
However, I know the problem exists and I have just been lucky. I am not claiming that my experience invalidates that of others - just adding my anecdote to the pile.
I think it partly comes down to what you look like and how you act on the street. Of the people I know who have had their phones snatched the common denominator was usually being too comfortable standing on a street staring at their phones. It's hard to miss kids on bikes/mopeds if you're watching for them, but if you're not and they appear then they'll go for you.
Depends how used to living in a big city you are. I think those of who live here have a bit more situational awareness (that said, the moped thing is new and maybe they roll up so fast situational awareness won't help).
I attempted to move to Ubuntu on my XPS 13, but couldn't manage to get the DPI scaling to work properly. Weirdly, if I run Ubuntu in a VM under windows it scales fine.
There are still too many of these small problems to justify making the move for me fully.
Preach. Currently running Ubuntu 18.04 on an XPS 15, and it's been.... interesting. Disappointing, in some respects, as having set up the system to dual-boot into Windows 10 and having seen what the hardware can accomplish, I feel as if I've had to try remarkably hard to get close to that in a Linux environment.
My problem with FastMail is that if you stop paying for your email address, they recycle it. This means that someone else could potentially buy your old email address (if you migrate away) and use it for nefarious purposes.
I do this and make a new alias for everyone I give an address to (such as hn@domain.com). It can be interesting to see who leaks/sell your email address. You can also shut down alias that get out of control.
Indeed! This is why I stopped using it. I love Fastmail, but who knows if I feel that way in 5 years. The entire point of Fastmail + own domain is never being locked in again. Using subdomain addressing locks you in once again.
I'm with @rb666; Don't rely on it as most will support plus+ addressing but not the the fast mail subdomain addressing as I am now in the process of migrating to Migadu.com and I need to go and unsubscribe and resub using the plus+tag. It's a PITA... lesson learned, stick with best industry practices even if there is an easier method because you'll thank yourself later.
catchalls are great. In addition to allowing the use of arbitrary custom addresses on a whim they make it really easy to identify spam and train spam filters. Anything that arrives on multiple random/unused addresses at your domain is spam.
I do this too but sometimes companies reject my replies because the from address isn't the same address they have on record. Maybe there's a way to make the "reply's from" the same as the "original's to" but idk.
With FastMail, you can select your wildcard as your "from" address on their web app, and just directly edit the `*` to be `<whatever>` and it will work fine :)
FastMail lets you change the from: address on the fly if you’ve set up a catch all.
And if you are not with fadtmail, there’s are several “multiple identities” add-ons for thunderbird (and recently a built in one, though it is still buggy) which let you add from addresses on the fly.
Huh, I haven't had that problem in about 7 years of using a custom domain name. Maybe the distinction is that mine is a .com? I feel like enough businesses themselves use custom domain names that dropping unknown .coms would break a ton of legitimate B2B traffic, but perhaps .me less so.
I use a .me domain myself but I haven't had any spam problems. Although I share it very very sparingly and have a catchall on another domain that I use for signing up with any service / sharing with non-trusted contacts. Even there, the spam problem isn't bothersome.
Surprisingly difficult for a personal-professional email if you have a somewhat common name. Nearly everything under the main TLDs was bought up ages ago. The issue can be mitigated with some creative branding work, but that’s arguably not any easier.
I've used .io and other "unusual" TLDs for a while and never had an email bounce or flagged as spam.
As someone else pointed out, make sure you setup spf, dkim, and all the other jazz. Some providers will host and setup the dns for you but its always best to use your own dns provider as the records are relatively easy to setup.
I haven't had any issues with my personal domain in years, ever since I moved it from random web host to GApps, to deal with IP reputation issues, and have SPF+DKIM setup. (but my domain is a .net one)
Agreed 100%. After losing multiple emails addresses in the past due to ISP changes, having an email on your own domain is nice. You can then even switch email providers as you wish and your address will follow.
Well, my Gmail account dates to 2004 but my personal domain dates to December 2000! I've lost domains that I continued to pay for, in fact I'm pretty sure that Zoho was paying for their domains as well.
Huh I haven't even thought about that. That's really bad, especially since I have a popular fastmail.com address where every other month I get an email asking for the account
Something to note here is that it is not just gay sex that is legalised - the prohibition was on "carnal intercourse against the order of nature" which included straight anal sex as well as oral sex. Of course, these are less important as this was never enforced, but weird to think that these things were technically illegal.
How about things like bestiality and Pedophilia? (1) Were they "against the order of nature" in the first place, and (2) are only specific practices allowed (The ones you mention) or just everything?
Edit: I'm not sure Wikipedia [1] agrees with you. The original law was:
> Whoever voluntarily has carnal intercourse against the order of nature with any man, woman or animal shall be punished with imprisonment for life
So bestiality seems to have been prohibited initially. The judgement [2] says:
> Section 377 of the Penal Code, in so far as it criminalises consensual
sexual conduct between adults of the same sex, is unconstitutional
So I'm not sure it decriminalizes anal and oral heterosexual sex as well.
