Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard

[Mark Nottingham <[e-mail]>]

Stephen wrote:

> I think doing this is a bad idea and commented on that before
> on apps-discuss. [1] (Start of that mega-thread is [2])
> 
> I think all the same objections apply other than the one that
> called for the discussion to be had here rather than in appsawg.
> (And thanks Barry for doing that.)
> 
> S.
> 
> [1] https://www.ietf.org/mail-archive/web/apps-discuss/current/msg12628.html
> [2] https://www.ietf.org/mail-archive/web/apps-discuss/current/msg12512.html

We had that discussion before, but to recap where I think we're at:

> While it may be deployed, I suspect that standardising this
> will lead us down a bad path where effort is wasted on trying to
> develop more fine-grained values. I think the discussion so far
> indicates that such a development is highly likely no matter that
> the proponents of this would like it to remain a single bit
> signal forever.

This isn't relevant, as it's in LC now and no extensibility is allowed (as John points out).

> And while DNT is different from this in some respects, in others,
> they are the same - an underspecified signal is emitted by a browser
> in the hope that an unspecified and unenforceable action is taken
> by a server. The IETF did exactly the right thing in rejecting the
> idea of standardising DNT and should do the same here. (In fact,
> I bet if you asked W3C folks now, they might agree that taking
> on DNT was a mistake;-)

DNT doesn't work because the incentives are very poorly lined up; the user is asking the site to do something against its own interest. It needs legislative / regulatory cover to actually work.

Safe lines up the incentives very well; sites want to give the users the content they prefer. This is demonstrated on search engines, social network sites, and so on.

> Separately, (in terms of arguing against adoption), I don't believe
> this is required for interoperability, and could do some damage
> to interoperability, if badly implemented on the server side,
> and given the unspecified nature of the server side here that
> seems not unlikely.
> 
> For example, I'm concerned that the word safe may be interpreted
> in a way that is not intended and that is applied to more than
> just one request/response pair or even more than just the web.
> I've heard various Chinese folks, some government, some not, talk
> where translators have used the word safe to mean what appears to
> me to specifically denote a government controlled Internet. I would
> therefore be concerned that a browser emitting this signal might
> be treated as preferring a network where e.g. the use of encryption
> is at best frowned upon, where middleboxes interepting everything
> is considered the norm etc.

I really don't know what you're talking about here, Stephen. People who want to willfully misinterpret semantics will do so; we can't prevent that, and more to the point, someone in a position to perform a hostile MITM with legal cover will do so whatever the client says it wants.

> I don't know if that's likely or not but haven't seen this aspect
> raised. And I'm not sure that documenting that the prefer value
> is only meant to apply to *this* HTTP request/response pair will
> help much. If a single prefer header were to affect more than one
> request/response pair, then if e.g. my calendar emitted that signal
> (on the basis that it'd be no harm) that might cause a server to
> fail to send content to my browser that I need.

Again, I think you're seriously off base and hand-waving here, Stephen. Do you have any evidence that this will actually happen -- keeping in mind that this is already deployed on extremely large Web sites, and in major Web browsers?

> I'd also object to the text in the draft that says that a proxy
> "can be used" to enforce this, but doesn't say how. That could
> of course be deleted or maybe fixed if this is adopted, but I'd
> not be surprised to hear someone saying that adopting this means
> that we have already agreed to specify how a proxy can force this
> setting for all browsers. FWIW, I do not accept that proposition.


The obligations and capabilities of proxies are reasonably well-defined in HTTP, and we're currently looking at making that better.


Regards,

--
Mark Nottingham   https://www.mnot.net/