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

Mark Nottingham <mnot@mnot.net> Thu, 24 July 2014 23:35 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74D21A0A98 for <apps-discuss@ietfa.amsl.com>; Thu, 24 Jul 2014 16:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWHK9V9IqQWJ for <apps-discuss@ietfa.amsl.com>; Thu, 24 Jul 2014 16:35:03 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22241A0648 for <apps-discuss@ietf.org>; Thu, 24 Jul 2014 16:35:02 -0700 (PDT)
Received: from [172.30.75.83] (unknown [23.79.231.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 01C1450A73; Thu, 24 Jul 2014 19:35:00 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CA+9kkMBDwbfPEcrQkLKCBTNxduRci25n43F_qYJcg4UffCLDiw@mail.gmail.com>
Date: Thu, 24 Jul 2014 16:34:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A21A001-3025-4668-943D-04F432810267@mnot.net>
References: <CAL0qLwZtqm5apMhET+QSu2wsmLUWysXdsJzBsrU5oi4p0xsAEg@mail.gmail.com> <CA+9kkMBDwbfPEcrQkLKCBTNxduRci25n43F_qYJcg4UffCLDiw@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0bGn_icBI_jW-AcHNDp-hSr1-IY
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 23:35:06 -0000

Hi Ted,

On 23 Jul 2014, at 12:49 pm, Ted Hardie <ted.ietf@gmail.com> wrote:

> Note:  the very first time I came to the IETF in person was to argue against Nathaniel Borenstein's KidCode
> https://datatracker.ietf.org/doc/draft-borenstein-kidcode/.   The scars I got from the politics, backstabbing, and insanity that lead through that discussion to the IETF VAC effort (voluntary access control, see:  http://lists.w3.org/Archives/Public/www-talk/msg01707.html) and on to the spin up of p3p (http://www.w3.org/P3P/) still throb on cold nights.  
> 
> There is not even a single bit of good to be done here.  The amount of misapprehension and mischief available is simply too high.  Forget it and walk away.
> 
> I oppose adoption of this draft.
> 
> With all respect to those not quite so scarred,

I was a member of the P3P WG, and I bear the scars as well, so I’ll assume that your appeal to authority above wasn’t directed at me.

Let me construct my own appeal to authority below — the authority of *implementor interest*.

This discussion represents my main concern around asking for this draft to be standards track — defining the vocabulary to use when describing policy like this is a hornet’s nest for any standards activity, particularly when the set of people standardising it are NOT well-educated in this area, just bystanders (yes, being a parent makes one a stakeholder here, but that doesn’t make one educated on the underlying issues).

Note that I’m not really a stakeholder either; I just wrote down a mechanism that had some interesting properties:

* It is simple and single-bit, avoiding the pain of P3P
* It aligns the interests of the parties involved (unlike DNT)
* it works well with HTTP 

After I wrote it down, I let it sit. After a while, I got interest from the people at Microsoft who implement Family Safety; they are very well-educated in the issues here, and they decided it was interesting enough to implement. Then Mozilla came on board.

That told me that it might be worth standardising. I brought this draft here to see if we could do something small and simple to allow preferences to be expressed and then acted upon; the use case is very clearly defined in the draft. 

I did not do this to open up a can of worms of inventing a taxonomy for Web content safety; my scars and yours tell me that doing that is an especially stupid thing to do. This draft, however, does not do so; it’s just a bit, and it’s site-defined. If this devolves into an exercise of describing different levels of safety, etc., I’ll do my best to shoot the entire thing in the head personally, as that smacks of the worst of this process. 

Anyone suggesting a “NSFW” preference should identify the use cases and convince implementers. So far I’m hearing people with opinions and “good ideas" being answered by crickets on the implementer side.

In my estimation, it should take this draft a few weeks to get through the WG; there are a few editorial issues, but it’s substantially ready to get to the IESG. If it takes longer than that, it tells me that something is very, very wrong.

Cheers,

P.S. Some big Web sites have privately expressed to me that if this is standardised, some jurisdictions will require Web sites to honour it with jurisdictional (not site-specific) semantics. This very well may happen, and in that case, I’d encourage those big Web sites to use their (extensive) lobbying capabilities to make sure that there were a carve-out of an appropriate shape, so that the site retains its ability to define what “safe” is. I don’t, however, think that that’s a valid reason to resist standardisation here. After all, a sufficiently motivated jurisdiction can already do that with Cookies today; all this mechanism does is relieve end users of the burden of setting cookies for multiple sites.


--
Mark Nottingham   http://www.mnot.net/