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

[Dave Crocker <[e-mail]>]

On 10/24/2014 9:10 AM, Stephen Farrell wrote:
>> 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.)

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.


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

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.


> I'll also note that there are some actors here who are incented
> 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
> safe with "unencrypted."

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