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

[Stephen Farrell <[e-mail]>]

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/
> 
>