Is HTTP 451 suitable for GDPR blocking?
By @edent
· 451 gdpr standards · 14 comments · 800 words · read ~5,582 times.
Hello, it's me - the idiot who helped inspire the HTTP 451 status code. I graciously allowed Tim Bray to do the hard work of getting it through the IETF process, and now it is an official RFC.
Recently, I've seen lots of people getting het up about its "misuse" - so I want to clarify a few things.
The GDPR (General Data Protection Regulation) gives people in the EU strong data protection rights.
Some companies do not wish to comply with these laws. Those companies block content to people within the EU.
Here's the kicker - they use HTTP 451 "Unavailable for Legal Reasons".
Well, this is the first time I've seen a website use the "451: Unavailable For Legal Reasons" HTTP status code. Who would've thought that it would be a result of the GDPR... pic.x.com/nzv7obo9a0
Is this the correct use of the status code? Some people are quite sure that it is not right.
I've had extended discussion with people on social media who are convinced that 451 should only be used in the case of government censorship. Those people are wrong.
Here's what I reckon
The RFC which specifies HTTP 451 does not mention censorship once. Similarly, there are no mentions of governments whatsoever.
From the introduction:
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.
What is a legal demand? And what does it mean to receive one? (I don't want this to go all "It depends upon what the meaning of the word 'is' is" - but I think this is important).
If a court orders you to remove an illicit photo of me wearing a mankini, you would have received a legal demand. 451 would be appropriate.
What about if my lawyer sends you an email which says "Take down that photo of Terence wearing a mankini or we'll sue you for a million quid"? I think 451 would be appropriate.
Let's read further. The actual specification is (emphasis added):
This status code indicates that the server is denying access to the resource as a consequence of a legal demand.
- One does not have to have specifically received a demand. I've never personally been instructed by the courts not to deface money - it's just what UK law demands.
- The specification says nothing about the validity of the demand. Perhaps the demand is mistaken, or wrong, or legally deficient - you can still use 451 while attempting to clarify.
- The RFC doesn't mention specificity. Perhaps the law bans a single page on your site - using 451 on the whole site may make sense for you.
These companies have seen a legal demand from EU countries that their citizens' rights must be protected. If they want to continue to abuse their users' privacy without legal consequence, they should block users who could successfully sue them. 451 is appropriate.
If the only way to access a resource would involve serving content which breaks the law, then 451 is appropriate.
We can take another theoretical example. UK law bans the sale of pistols and some other weaponry. A US site may choose to use 451 to refuse service to users in the UK - even if the site believes in the right to arm bears. They may not have specifically received a legal demand, but UK law does demand that they don't sell to people in its territory.
The easiest fix would be for these companies to comply with the law and respect their users' privacy. That's what the law demands of them.
Media comprehension
I suspect that lots of people get hung up on the number 451 being a direct reference to Ray Bradbury's famous novel about censorship. Except, like in this case, Fahrenheit 451 is not about censorship.
Luckily, the Internet works due to rough consensus and running code. No one gets damaged if an http code is used incorrectly. And if the majority of sites use 451 to protect users from endless data mining, well that's just fine with me.
Anyway, that's what I reckon. Feel free to disagree with me - I promise I won't sue you. This does not confer any legally binding protection against lawsuits brought by me. All rights reserved. See back of packet for full terms and conditions. Errors and Omissions Excluded. Not valid in the state of Kentucky. Nil illegitimi carborundum.
Andrew McGlashan says:
There should be a 551 or similar equivalent. Doesn't the 400 series errors generally denote temporary errors and 500 series permanent errors? That is, of course, assuming that the intention is to treat the bug as a "not fix" error, we're done.... 😉
@edent says:
No... 400 is nothing to do with "temporary" errors. A 404 indicates that the file is not found, for example. There may or may not be anything temporary about that. https://en.m.wikipedia.org/wiki/List_of_HTTP_status_codes
4XX is a client-side error. The client may be able to change or correct their request to get a successful response from the server.
5XX is a server-side error. The client did nothing wrong, but the server couldn’t fulfill the request at this time.
In HTTP terminology, these publishers are blaming the client and suggest they move to outside the European Economic Area (EEA) to get a 2XX successful response.
403 is a server-side condition - "server rules dictate you are not allowed to have this material". The client side fix might be to log in or otherwise gain permission, but it isn't given. 404 is a server-side condition in that the material sought does not exist. The fix is to request something that does exist, but if the client wants what was but no longer is at the requested URL it's a server condition, and fundamentally not fixable by the client. Equally, 451 is also a server-side condition - "we have determined you are in a location we are not willing to serve". That could be fixed, in much the same way, by the user moving to a location (or even an egress IP representing a location) which they can and will serve. Even in your framework interpretation a 400-series response is appropriate.
Joe Lee-Moyet says:
The issue is that GDPR doesn't impose any "demand to deny access to a resource or to a set of resources" in these cases (unless the page in question would be unlawfully distributing personally identifiable information in which case 451 would be appropriate). Instead the problem is that GDPR prevents the site owner and its affiliates from collecting and using the users data in illegal ways - it would be fine to return the resources as requested if the server(s) refrained from collecting and processing your data illegally.
It's a bit like claiming "it's against the law for me to give you my phone number" with the reasoning "if you call me up I'll try to sell you drugs which is illegal"...
451 seems right here, but are there cases where this doesn't represent them illegally keeping the user content that was intended to be wiped via GDPR? Like, are there cases where this response code doesn't represent someone definitely doing something illegal on the server-side?
Raj Rijhwani says:
It's not a question of legality or not. It simply means that given legal considerations the entity responsible for the server has decided they are not willing to serve the client under current circumstances. In GDPR terms it doesn't even necessarily mean that they aren't willing to comply, or are specifically doing anything to contravene the regulation. It could simply mean they can't be bothered with the cost of finding out and ensuring they don't. It might simply be the cheapest and most practical path - especially for a small entity on small budgets - to not falling into a trap having operated under much more liberal (to them) conditions. It doesn't automatically imply that they want to do anything illegal.
If you're a small entity, and you built your service around other building blocks you have never had to consider the consequences of using, you might reasonably just want to say "nah, can't be bothered".
Joris W says:
Not the easiest fix. The proper fix.
Easiest, apparently, is for non-EU-facing business to install some kind of EU IP blocker. Sad state of affairs, but not entirely unexpected from a business standpoint.
I can see that you're setting cookies and collecting user names and email addresses, so I assume you're processing my personal data now that I've placed this comment.Would you be able to tell how shkspr.mobi is complying with the law and respecting my privacy? I've had a bit of a look around your site but I can't seem to find a GDPR compliance notice, or indeed a privacy policy of any kind.
You link to Akismet's privacy policy (https://automattic.com/privacy-notice/), but that doesn't tell me what you yourself do with the information your site collects.
I realise the GDPR has a personal use exception, but as far as I can tell one can't safely assume it applies to a blog on work-related topics, especially if it earns any kind of income (https://law.stackexchange.com/questions/28070/would-gdpr-affect-my-own-personal-website).
What does this comment have to do with your post?
I write a blog in my spare time. For the reasons stated above, I believe it needs to be GDPR compliant, but I don't really have the time or knowledge to comply -- so I've been seriously considering geo-blocking EU residents.
If you know of an easier way to comply with the law, respect my user's privacy, and still serve the site to EU residents, I'm eager to hear it.
@edent says:
That's an interesting question. The law as it is currently written says that it:
This blog is run by me - an individual. It is not published by a company, or other legal entity. Any money that I earn from it is part of my household finances. I am not a data controller.
I've turned off most external resources, and the site works if you reject cookies & 3rd party scripts. If you have suggestions for how I can do better, I'm happy to hear them.
As for your site - reduce the amount of personal data you collect. Don't include untrusted content. Respect your users.
David Silverman says:
GDPR merely requires you to tell EU citizens that you use tracking cookies and why you use them. That's it. No coercion, no potential lawsuits. I like tracking cookies, not because they provide me with adverts I want to see, they don't but the results are hilariously absurd. Virtally everyone automatically accepts them.
HTTP 451 used for GDPR isn't legal compliance, it's politics.
GDPR is the law. There are legal penalties for not complying with it. If you don't want to follow the law, blocking people from accessing your illegally operating service seems reasonable to me.