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

On 2012-06-14 14:45, Nicolas Mailhot wrote:
>
> Le Jeu 14 juin 2012 12:14, Mark Nottingham a écrit :
>>
>> On 14/06/2012, at 7:04 PM, Nicolas Mailhot wrote:
>>
>>> Mark Nottingham <mnot@...> writes:
>>>>
>>>> So, again -- what's the use case for a machine consuming these? I haven't
>>>> seen
>>> one yet, unless I've missed something.
>>>
>>> 1. the block cause must be reflected in headers to be available in (legal or
>>> debugging) logs. With today's spaghetti web sites that shard their content
>>> over
>>> multiple servers and delegate more and more bits to nebulous cloud platforms
>>> with fuzzy limits having to read all the html pages exchanged to debug a
>>> block
>>> is increasingly un-practical
>>
>> The device doing the blocking can log its own actions without making it
>> machine-readable on the wire.
>
> That's pretty much useless for the web app/web client developer the users will
> complain at since he won't have access to the device logs and often won't even
> know where to ask for them.
>
> Also, as soon as you have a multi-tiered network architecture, or one
> organisation making some web resources available to another through two
> separately-managed networks, that's the road to log correlation and
> multi-organisation coordination hell.
>
>>> 2. the block cause must be reflected in headers so all the web clients that
>>> use
>>> http as transport via some other middleware can be notified of the block
>>> cause
>>> (ie the not-html-capable http middleware needs something it can easily parse
>>> and
>>> pass up the stack so the web client presentation layer gets a chance to do
>>> something with it and inform the user)
>>
>> Yes; this is the most compelling case I can see for a separate status code,
>> similar to the one we had for 511. However, I don't yet see where the client
>> will actually *do* something with the response that might require making this
>> distinction. It was necessary in 511 because sites were interpreting the
>> redirect as coming from the origin server, which has all sorts of nasty side
>> effects for non-browser agents; what are the corresponding side effects here?
>
> To be honest I don't think the problem-space is any different from error 511.
>
> In my opinion the current discussion just shows that error 511 didn't go far
> enough to handle gracefully all real-world blocking scenarii and assumed
> (wrongly) that a blocking error with human content that would not necessarily
> be displayed to the user was sufficient, because no one cared why the blocking
> occurred. When in fact the only reason Tim Bray launched this discussion was
> because he wanted to convey the blocking rationale.
>
> After spending quite a lot of time thinking about the problems error 511 does
> not solve in our context (which admittedly is a lot more complex than the home
> office case), and getting varied feedback from the developers of some of the
> web clients I asked implementing error 511, and having to solve a few more
> problems caused by current web client inability to interact gracefully with
> blocking gateways, I'd really love to see a design such as the following:
>
> %<-----
>
> 1. a generic 'blocked by intermediary' error code web clients are forbidden to
> retry on (same rationale as error 511)
>
> 2. a header containing a free-form short sentence describing the blocking
> rationale ('Blocked due to law 666', 'Upgrade your access', 'Too young for
> this', whatever). If you want to get fancy this header should be localizable
> by suffixing/prefixing it with an iso 639 code (we don't need this but I'm
> pretty sure it will be a requirement in countries with multiple official
> languages where it is forbidden to discriminate between them, or on
> transnational networks; that makes it a candidate for UTF-8 encoding by
> default BTW)
>
> The only purpose of this header is to give dumb web clients something to
> display or log in case of blocking, and to leave no room for javascript or
> complex html those clients can not understand (though for logging you'll also
> want the two next headers)
>
> I don't think there is any point in trying to define a set of standard values
> for this header as humans are very good at inventing new
> political/social/organizational/religious reasons to block some accesses.
>
> 3. an optional header containing the location of the full explanation of the
> blockage (can be a pdf with terms of service, a web site with lots of fancy
> chrome, a video statement of the local leader, some cartoons to explain kids
> why they don't have access to adult content, the local three-strikes law
> excerpt, an helpdesk wiki page, whatever)
>
> IMHO it is a huge mistake to try to put the pretty explanation in the error
> page itself as networking equipments are not all able to host the rich content
> needed to explain a situation to many users, and current computers access
> stuff right and left so any user on a network subject to blocking is likely to
> receive the error multiple times in a row. Better to offload it somewhere the
> user will only consult once or twice in a full browser, and that is able to
> withstand the load if the blocking is too extensive. The gateway always has
> the option to host this page itself and transmit its own IP as location
>
> 4. an optional header containing the location of a web portal the user can use
> to elevate his access (when it is possible). Can be a full auth portal, a
> payment portal, a form where a visitor can enter the token printed on the card
> given to him by the hotel personnel, a web page with a button stating 'I agree
> that pirating hollywood films is the ultimate sin', whatever
>
> Some organisations will set a cookie (meaning only the web client used to
> access the elevating access portal will work), others will authorize all
> accesses from the ip that was used to elevate the access (for a time), there
> are many possible variations and this scheme is not restrictive at all.
>
> This way any web client can display at least 1. without requiring an html
> engine, it is possible to provide users a more complex rationale
> representation, and the web client is informed on how to elevate its access
> when it is possible.
>
> And it also works fine when you stack multiple levels of blocking gateways
> that obey to different rationales and have different ways to trigger
> un-blocking
>
> Finally, that permits the writing of password managers and other browser
> chrome extensions that auto-supply credentials when they recognize a trusted
> portal location in 4. (and 4. also permits the use of https auth portals the
> password manager can check the certificate of before injecting credentials).
>
> 5. To be complete you also need to define a status code that the portal in 4.
> will emit when it is satisfied by the token presented by the user, so browsers
> can implement the obvious logic of:
> “after receiving a blocking code on any access, if the portal location was
> loaded and returned the ok code, retry the access that was previously
> blocked̆”
>
> %<-----
> ...

This really, really smells like over-engineering to me. Also, HTTP 
header fields are a very bad solution to transporting human-readable 
text; that's what we have markup languages for.

It probably would be useful if you could walk us through a concrete use 
case where a status code + response body is not sufficient. (And if you 
did before, sorry, then please provide a pointer).

Best regards, Julian

Received on Thursday, 14 June 2012 13:03:33 UTC