Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> >
> >
> > The document says about the HTML content in a 403 "but browsers are
> unwilling to show this to end users, since doing so would subject them to a
> potential man-in-the-middle attack."; this same reluctance seems to me
> likely to apply to the URL in the proposed JSON structure.  You note the
> issue considerations section, but seem to come down on the side of
> including it anyway.  Can you explain more about why? What's the other side
> of this trade-off look like, in your thinking?
>
> Browsers are unwilling to show HTML because it has the ability to
> masquerade as the origin; displaying a raw link doesn't, and there's
> significantly less chance that the user will be confused about that.
>
> Still, it'd be good to have a discussion about whether / when the URL
> should be displayed. I included it to have that discussion, mostly :)
>
> If we don't include it, I *suspect* it's going to be more difficult to
> meet some use cases (e.g., get support HERE, complain HERE), and I
> *suspect* proxies will just put links in the text anyway, to cut-and-paste.
>
> That kind of indicates that there may be a need for more than one URI, so
having a single "moreinfo" URI may not help avoid the cut-and-paste.  I
kind of suspect that the best thing to do is to provide the facility for
bare URIs in text, and ruthlessly suppress any ability to use anchor text
to hide what's in the URI.   That remains a bit of risk, but might be the
best balance.


>
> > I found it odd that the document talked about forbidding origin servers
> from generating the media type, rather than returning it a response.  Below
> you say it MUST NOT be used with 2xx or 3xx responses; it seems like you
> could also use similar language for origin server/CDN use.
>
> What's the use case for origin servers generating it?
>
> I don't have a use case for that, I was commenting on the oddity of
preventing them from generating it, rather than saying that MUST NOT return
it in a response (or even use it, as you say for 2xx and 3xx responses).  I
am perfectly willing to save my paint for other bikesheds, though.


>
> > The document says that "Clients MAY selectively support this media type.
> For example, an implementation might deem it only useful (or safe) in
> CONNECT requests."  Given the other restrictions, I don't use case outside
> of CONNECT, and I would normally say that you shouldn't send an accept
> header where you're not willing to receive the type; am I missing some of
> your thinking here?
>
> Interception proxies.
>
> So, a client should send this accept request with all queries in case
there is a friendly enough man in the middle to tell them that the traffic
is being prevented and why?  I can't picture that being the right
trade-off, personally, but I'd be interested in whether this sounds
plausible to other folk.

regards,

Ted



> Cheers,
>
>
>
> Mark Nottingham   https://www.mnot.net/
>
>