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

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Oct 2014 10:49:23 +1100

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/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Oct 2014 14:10:02 +0100

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])
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/apps-discuss/current/msg12628.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.
> 

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.

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

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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Oct 2014 10:41:31 -0400

> (Bad as it is, we can't and shouldn't try prevent it.)

What you've offered can be used to defeat any and all proposals:

     Some unknown person might, at some unknown time in the future, do
something that might be problematic.

Any spec can be abused.  Some actually are.  Some aren't.

There is a concrete specification in front of the IETF.  It is simple
and it minimally builds on existing practice.

Evaluation of the spec should be of the spec.  Not on some vague and
hypothetical fear that someone might abuse it.

If you have concrete data to substantiate your fear, please provide it.

> they proposed DNT to the IETF. 

DNT was a ready-fire-aim effort.  It created a reporting mechanism but
without any follow-through to formulate and assure back-end benefit.

The current specification is fundamentally different because it is based
on existing practice.  So there is already a basis for believing that
users will want it and find it useful.

> to censor the Internet, and they will I think, welcome this.

So now you are arguing that some unknown set of actors might have
questionable motives.  Again, that's irrelevant. The issue is whether
the specification makes sense.

The specification enables a voluntary mechanism, tapping into an
existing capability that has already been shown to be desired and useful.

> I have explicitly heard some government folks equate the word

The specification defines its use of the term, as IETF specifications
usually do.  So the fact that someone, somewhere has used the term
differently isn't all that relevant.

(What is ironic about your vocabulary objection is how comfortable you
remain with use of the word 'security' in 'opportunistic security' in
spite of its having no precise meaning and long-established usage that
is ambiguous and wrong. Even better is that the actual substance of the
draft using the term is only about encryption.  So you are equating
encryption and security, which is a particularly unfortunate ambiguation...)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Oct 2014 22:25:57 +0100

Hi Dave,

Just on this point (I think on the others there's just not much
more to say:-)

> encryption and security, which is a particularly unfortunate ambiguation...)

I think that Viktor's draft does define the OS term sufficiently well.
This draft deliberately does not define the meaning of safe, and is
not needed for, or possibly very slightly damaging to, interop. OS OTOH
explicitly aims for and will help with better interop. So I see no
irony, but I think I can see how you might, given the way in which
you and I seem to disagree about the OS draft.

S.

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Oct 2014 09:41:05 +0900

i tried to look at this draft but my browser would not show it to me.

< decode >

in a diverse and multi-cultural world, norms differ.  widely.  those of
the sender may be quite different than those of the receiver.  this is a
feature, not a bug.

there are cultures in which pictures of unclothed children are highly
objectionable.  there are others which have no problem with this but
where pictures of underclothed adults are inappropriate.  some where
imgages of gods are admired, others where they are forbidden.  and even
some where internet-drafts which impose one culture's mores on others
are objectionable.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Oct 2014 14:14:36 +1300

> some where internet-drafts which impose one culture's mores on others

Exactly. So how this well defined and interoperable single-bit
indicator is going to achieve anything that is the slightest bit useful
baffles me completely. As far as I can see, the semantic is identical
to RFC 3514.

On balance I don't think that this is harmless. Since it will create
an illusion of "safeness" with absolutely no guarantee, I think it
is highly likely to be abused by scurrilous sites purporting to
provide "safe" material.

    Brian