Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Aug 2014 13:14:33 +0100

Hiya,

Belatedly catching up on this. I suspect this is getting
repetitive so probably no need to follow up and whoever's
calling consensus on this can just take this into account.

On 29/07/14 15:55, Barry Leiba wrote:
>>>> Yes, the specific new concern that I raised there relates to
>>>> equating this signal emitted from a browser with the "safe"
>>>> concept of networking in general that seems to be espoused
>>>> by for example the Chinese govt, where "safe" is apparently
>>>> interpreted to mean quite a few things with significant
>>>> impact on networking in general. A server-side or a n/w that
>>>> did that could badly impact on interop.
>>
>> The fact that the signal term suggested clashes with that used
>> (in a translation) to describe general network controls such
>> as used in e.g. China is a concern. That has two aspects: 1) the
>> colliding but undefined term indicates a specific actual problem
>> that could otherwise be considered only a potential issue and
>> 2) the signal emitted could well be (mins?)interpreted as being
>> much more broad than http or than this request/response pair and
>> I don't see how to rule that out without assigning at least some
>> semantics to the signal and thereby invalidating the stated goal
>> of the proponents that this signal does not have defined
>> semantics. (If one tried to tie "safe" to one http request/response
>> then presumably a page-load could result in not-"safe" content
>> being seen. If one broadens it out then, how much, for how long
>> etc? Both seem problematic.)
> 
> Stephen, I think this is a real stretch.

I can see how reasonable folks could differ on that.

> The document doesn't just throw out "safe" with no explanation at all,
> and more explanation of what's intended could easily be added to make
> it yet clearer.  

I thought avoiding that rathole was part of the proposal
myself.

> But if we're trying to make it so that nothing we do
> could be misinterpreted and abused by parties inclined to abuse it,
> we're going to fail, and we'll do nothing.

That last, IMO, *is* the correct outcome for "we" == IETF.
Some earlier suggested this as an ISE thing, which would
make sense perhaps.

>>>> I also think the similarity with DNT is worrying. We were
>>>> absolutely correct to not take that one on, as its troubled
>>>> history within W3C I think shows.
> 
> There's very little similarity with DNT.  DNT said, "I know you want
> to track the user, but the user doesn't want that.  Please don't."
> Safe-hint says, "You have a 'safe' setting that you offer the user.
> The user is hereby opting into that."  

The above is not quite accurate IMO. There's a missing "If"
since the UA doesn't know what the site does or does not do
when emitting the value. And the "user" opting in to an
undefined "that" is quite an odd proposition since the user
presumably set the safe checkbox six months previous to ever
visiting this site which may have changed its definition
in that period. And of course this is liable to be the kind
of thing that some govt might mandate be turned on by the
UA, causing yet another mess and definitely taking out any
user choice.

The whole thing is ill-defined and a likely source of future
trouble IMO.

> They vastly different things,
> with the only similarity being that they're both using HTTP headers to
> request a feature.

No. They are both similar in a) not being required for interop,
b) being deliberately ill-defined at the protocol level and c)
having no enforcement or checking mechanism at all.

And while some of the incentives may be better aligned compared
to DNT, not all are, e.g. those of users and governments perhaps.

>>>> And I think this topic ought be considered by the IETF as
>>>> a whole and not only on appsawg, before the work is adopted.
>>>> Looking at appsawg's charter I think its fair to say that
>>>> this is not a "small-scale addition" to HTTP - while it may
>>>> appear so in terms of bits on the wire, the impact of that
>>>> one new bit in a request is arguably large-scale.
> 
> I think this is a stretch also.  

Again we disagree about that. IMO area WGs should not adopt
work that is likely to be significantly controversial. The
reason being that if that work is adopted and developed within
an area WG then that effort and history distorts consideration
by the IETF as a whole during an eventual 2-week LC. For
controversial things forming a WG or AD sponsoring seem to me
to be much better as that allows broader IETF consideration
at the appropriate time, at the start of the (collective) work.
I think the HTTP Forwarded header demonstrates that this is
not at all a stretch. Someone else mentioned WebFinger as
another.

I do agree it can be hard to determine whether or not a bit
of work is sufficiently controversial that it ought not be an
area WG item.

> In any case, I'll point out that what
> little objection there is, is from a vocal minority; 

Vocal is purely pejorative though, right? And minority implies
vote counting. I'd also point out that most of at least my mail
has been in response to questions asked.

> that this *is* a
> small-scale addition with one person (you) trying to argue that it's
> more than that; 

I interpret some of the other arguments against doing this as
possibly being in agreement with me on this point. While that's
not definitive, I don't think you can say that I am the only
one who thinks this controversial and someone else at least has
also suggested the ISE route.

> that appsawg has quite broad participation; 

True. However, again I think HTTP Forwarded showed that there
are limits there in terms of there being interests that are
not well represented in this or any area WG.

> and that
> the IETF community outside appsawg will be able to comment during last
> call, which is likely to happen very quickly.

See above.

Cheers,
S.

> Barry

---

From: Eric Burger <[email-masked]>
Date: Sat, 9 Aug 2014 09:29:22 -0300

How about this to get us out of the rabbit hole? Instead of calling this the "safe-hint" header, let us call it the "pink-hint" header. When a server receives a request with the pink-hint header, it [fill in the current proposed behavior of safe-hint]. That gets us out of the layer 8 and 9 issues that attempt (at layer 5) to answer the question of "what is 'safe'?"

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

> On Aug 9, 2014, at 9:14 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "John Levine" <[email-masked]>
Date: 9 Aug 2014 23:38:11 -0000

In article <[email-masked]> you write:
>How about this to get us out of the rabbit hole? Instead of calling this the "safe-hint"
>header, let us call it the "pink-hint" header.

No such luck.  We seem to have a fairly deep disagreement between the
faction that wants to write up this tiny hack as is since it's already
implemented in two of the most widely used browsers, and the faction
that insists we can't do that, we have to do something more
complicated and probably different.

I find the latter position baffling, but there are clearly people who
feel strongly about it, so if we're going to do this, one side needs
to wear the other down and that's more messiness than we can do in
appsarea.

R's,
John