Re: Fwd: New Version Notification for draft-tbray-http-legally-restricted-status-00.txt

Tim Bray wrote:
> http://www.tbray.org/tmp/draft-tbray-http-legally-restricted-status.html

> This document specifies an additional Hypertext Transfer Protocol
> (HTTP) status code for use when resource access is denied for
> legal reasons.

I think the description is too specific. While many of the instances
under recent discussion will be due to legal constraints, this code
may be applicable for other reasons: local policy, elective
filtering, etc.

To me, the defining aspects of the usefulness of this code are:

1) The code is generated by an intermediary outside of the control
of the origin server.

2) The content is being blocked due to the nature of the content
itself, whether that nature be assumed, suspected, reported,
spidered, analysed on attempted access or something else.

(I wonder if "3) users not downstream of the intermediary(s)
can expect to be able to access the content" is significant.)

Remember that non-legally mandated content filters are already
using various non-standardised status codes for this already:
they *might* want to switch to a standardised code should it
become available.

Consider the following cases:

1) A government agency provides technical information, but for
national security reasons does not want to allow access to IP
addresses within embargoed foreign states. It is neither an
intermediary, nor though it may appear so is the block directly
related to the nature of the content (which it would normally be
happy to serve to anyone else), but to the nature of the
requester. 403 would be more appropriate here.

2) A media company has negotiated broadcast rights for a piece
of content to certain territories, but not to others. Much as
above.

3) An internet cafe provides unrestricted normal browsing, but
blocks access to video/* responses unless "premium" access has
been paid for. Again this is not actually "content related":
they don't care whether it's kittens or anti-government
propaganda, their main motivation is financial and so 403 is
still appropriate.

4) A company implements a filtering web proxy. The CEO's
computer is allowed unfiltered access. Unlike (1),(2), it *is*
the nature of the content that causes block here, and although
the block is not evenly enforced, it is the CEO's access which
is exceptional, it is not generally the nature of the requester
that causes the block: the block is the normal case. This new
status code *is* appropriate here.

5) An ISP provides content-based filtering as a value-add feature.
It may be either opt-in or opt-out. The user is essentially
imposing the block on themselves in a sense, but the new code
is appropriate as the two defining aspects are met. Obviously
the response body should contain enough information to request
to opt out again.

6) A CDN with a direct relationship with the origin server blocks
content the origin attempts to serve due to contractual restrictions
chosen by the CDN itself on the types of content the CDN is willing
to serve. This could be argued either way perhaps, but I would
say the CDN and origin are closely enough related that 403 is
more appropriate.


> the server in question may or may not be an origin server

While I wouldn't say it is never appropriate for an origin server
to generate this code, I would expect that to be a highly unusual
case. In most cases an origin that does not want to serve the
content would simply return 403 or 404 directly. (An origin that
would normally serve the content, and wants to do so, but finds
itself under a temporary court injunction, for example, might
be one case.)

> Responses using this status code SHOULD include an explanation,
> in the response body, of the details of the legal restriction;
> which legal authority is imposing it, and what class of resources
> it applies to. For example:

I would say:

* details of the <del>legal</del> restriction and class of resources
  it applies to are likely to be very closely related, and may
  perhaps be treated as the same piece of information
* the party implementing the block
* the party imposing the block (if different)
* (the party requesting the block maybe: say the plaintiff if the
  block is due to a court injunction. The "party imposing" would
  be the court itself. Or maybe "party imposing" just has to be
  very specific about how the block came about.)
* sufficient information to contact/find contact details of the
  appropriate agent to complain about/request removal of the block

Any and all of these items are optional (as is the code itself) at
the discretion of the block implementing party based on what they
want to disclose, or what they are allowed to disclose.

> 4.  Security Considerations

For entities imposing a block locally, and inspecting status codes
from access logs to identify block hits, it should be remembered that
the given status code may also be generated externally so mere
presence of the status code does not necessarily imply an attempt
to violate local policy.

For all entities, blocks of any type have been known to generate
frequent false positives, so generation of the given status code
does not necessarily imply an attempt to access blocked content.

John
--

Received on Tuesday, 12 June 2012 13:53:01 UTC