On Mon, 02 Jul 2018 22:17:01 -0700, Tim Bray said:
> 4. Section 4, 1st bullet point: â??HTTP 451 SHOULD NOT be used by an
> operator to deny access to a resource on the basis of a legal demand that
> is not specific to the requested resource.â?? Why is this a good idea? If I
> decide to respect a legal demand that I not give access to any resources
> that mention the existence of a certain person, or which are sourced from a
> subdomain of example.com, or from a server whose geographic location
> within the Vatican City, why should I not be able to use 451?
Amen to that. If anything, it's *vastly* more likely that the legal demand
won't be specific to just that one object, but will cover a large number of
objects (possibly into the thousands or millions). There's no sense in
allocating a return code for the presumably rare "a request was made to block
exactly one object" case, and not allocate one for "a request was made to block
every object of type FOO". For example, I've never seen Google reply with
"exactly one response was filtered" - if there's *any* hits, there's usually
*multiple* hits.
Perhaps "on the basis of a legal demand that is not directly applicable to
the specific requested resource" would be better? Or other wording that makes
it clearer that 451 can be used for any case where you have an object that you
can't serve up?
On Tue, 03 Jul 2018 10:23:23 -0700, Shivan Kaul Sahib said:
> HTTP 451 is being used to block users who reside in the European Union by
> websites that are not GDPR-compliant. There is no real "legal demand to
> deny access" to the resource.
If they can't provide access to a EU resident because they aren't GDPR
compliant (and thus have an actual legal exposure to penalties if they
provide access anyhow), they have two choices:
1) Deny access
2) Face the legal exposure.
You're going to have a really hard time explaining how a "Deny access to this
copyrighted information or face legal consequences" takedown notice is a legal
demand, and "Don't allow access that involves non-GDPR compliant data or face
legal consequences" isn't a legal demand. Maybe a lawyer understands the
difference, but it's a strong bet that the person who has to actually maintain
the list of 451-blocked objects won't.
> them to use it. If we think that the status code should be used for
> compliance with *any law whatsoever*, even if the law doesn't actually
> demand that the resource be taken down, then perhaps making that clear
> would be helpful for people seeking to use the status code.
I'll note that "demand that the resource be taken down" is subtly different
from "demand that the resource not be available" (in particular, if it's being
made *conditionally* unavailable to some users, but potentially still accessible
to other users).
This part of the draft is problematic as well:
demand. Note that while the introduction of [RFC7725] mentions
that the legal demand for denial of access should be related to
the resource being requested, the RFC's description does not make
it clear that the resource being denied access to must be directly
mentioned in the legal demand.
That's because in most countries, when the legal document arrives, it quite
likely *won't* itemize 48,374 separate URLs to fulfill a "directly mentioned"
requirement. It will have terms like "any and all documents concerning
<specific definition of documents involved>". And that's because if the legal
document says:
"Block access to https://www.example.com/this_data_is_banned.txt";
all they have to do is rename it to 'this-data-is-banned.txt", fix links to it,
and we're playing whack-a-mole. And it's guaranteed they can rename the file
and fix the links faster than you can go back to the judge and get a new order
signed. Especially the 7th or 8th time in a 48 hour time span. So the legal
order will often *not* "directly mention" the resource, but will instead give a
*description* of the object sufficiently specific to allow identification of
same.
Overall, I'm having a *really* hard time seeing how redefining 451 to only
apply to resources that have been directly identified in the legal demand
improves the situation over RFC7725.
Attachment:
pgpkf2CShjzHf.pgp
Description: PGP signature
