W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

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

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Wed, 13 Jun 2012 09:44:38 +0000 (UTC)
To: ietf-http-wg@w3.org
Message-ID: <loom.20120613T110345-438@post.gmane.org>
Willy Tarreau <w <at> 1wt.eu> writes:

> I don't completely agree here : for me, 5xx means that the error is not
> the client's fault and that it might randomly work if the client tries
> again, which is why network errors fall into this category, as opposed
> to the 4xx error by the user/user agent as you explained (and which I
> agree with).

I'd say there is not a sliver of technical difference between the blocking done
by an hotel wifi portal, by a school gateway on lab internet accesses, by a home
proxy on pornography accesses by children gadgets, by a corporate proxy on
facebook accesses, by a conference gateway for visitors, by an isp or country
filtering infra on stuff the country decided is not legitimate (and in all those
cases the equipments used are pretty much the same and marketed by the same

At every point the web client requested a web resource and it was denied by some
intermediary for violating the terms of use.

What varies is only the ultimate human justification behind the blocking
(financial, organisational, legal…): what the terms of use are based on, how to
get the level of access to bypass it (I'm pretty sure that even in
politically-challenged countries spooks get to see what is blocked), etc But
this justification is not something software should act on, it's something for
humans to act on (and I'm not saying I agree with all the possible kinds of
blocking, just that technically they are all the same).

It is completely wrong to try to enshrine political assessments in technical
protocols, the protocols must provide the technical means to communicate there
is some form of blocking, where the (human) justification can be found
(law/terms of uses), and where the user can provide credentials to lift the
blocking in the case it has this possibility (prove he paid the bill in case of
hotel accesses, prove he is staff for school labs/conferences, prove he is
marketing for facebook access in the Enterprise, that he is of legal age to see
nudity etc)

So the semantics should be the same as error 511 and I'd go as far as to say
error 511 should be generalised to handle those cases.

What error 511 is missing is:

1. a clear definition of 'terms of use' (what humans needs to read to understand
why access is blocked) and 'authentication means' (where the user or software
can provide credentials to get elevated access). This is especially important in
russian doll scenarii where the blocking can occur at different levels and the
different levels are not the same at all for users (a conference in a repressive
country for example: blocking can occur at the conference gateway level, at the
isp used by the conference, or at the national firewall level)

2. how this information is conveyed to users (a free-form html page does not
work for dumb clients or fat clients that use an http library such as curl).
'terms of use' and 'authentication means' location need to be specified in http
headers so the http library can pass it up the stack and the developer can
choose to display it (or not) in a browser window, an app popup or whatever he
deems appropriate

3. guidance to web client implementers on the security precautions to apply when
conveying this info to the user, and how to convey it even when the blocking
occurs mid-browsing in an https session

And it is not helping the user to refuse to acknowledge reality and hide this
information (when it is available). If the user does not even know it is blocked
and why he can not act at all (politically or otherwise)


Nicolas Mailhot
Received on Wednesday, 13 June 2012 09:46:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC