Hiya,
On 24/10/14 00:49, Mark Nottingham wrote:
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,
Yes. So I'll try not be too repetitive, Barry (as the
responsible AD) has seen it I'm sure and can factor the
earlier discussion into his evaluation of the LC, all I
wanted to do was record that my objections remain.
So I don't think there's a need for us to discuss this too
much as we've both I think made our thoughts clear. That is,
no need to answer this if you don't think that's useful. Or
do if you do, either's fine:-)
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).
I think that's wishful thinking. There is nothing to stop
someone writing code or an I-D that extends this say to
have a UA to emit "Prefer: safe+religion-porn+crypto" as a
string and nor should there be something to prevent that.
(Bad as it is, we can't and shouldn't try prevent it.)
If we declare rough consensus for dipping our toes in this
water, it's inevitable that we get asked to standardise
that sort of extension I think. And it'd not be pretty if
we ever tried. And we'll probably get asked over and over.
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.
I am not convinced of that. The proponents of DNT turned out
to be wrong, but presumably didn't think they were wrong when
they proposed DNT to the IETF. The IETF was right to pass on
that one I think. And the similarities here are for me much
more compelling that the differences.
I'll also note that there are some actors here who are incented
to censor the Internet, and they will I think, welcome this. I
consider that a negative. (Note: I'm not saying that all uses
of this amount to censorship.)
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
You have not defined semantics so therefore cannot really
object to any interpretation of the signal nor even call
something a misinterpretation.
I have explicitly heard some government folks equate the word
safe with "unencrypted."
Using an English language word here as the signal where such
interpretations of that word are known to exist is a bad idea.
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.
Yes. The question is whether or not they can credibly claim we're
helping them I guess, and how much we might care about that.
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?
So does the preference only apply to this one HTTP request or
more? Why can't you say?
I have seen lots of weirdness with caldav and TLS in the
case of hotspots that want to fake TLS at first to get paid.
I can see this causing similar fun, esp. if you keep that
concept of a proxy injecting this.
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.
I think my objection remains unanswered tbh. You ought at minimum
say that a proxy MUST NOT add this IMO.
All in all, I think the ISE is the proper route here to document
the existence of what some folks have implemented and deployed and
there is no need for, and there is harm from, the IETF standardising
this.
Cheers,
S.
Regards,
-- Mark Nottingham https://www.mnot.net/