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/