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

Bjoern Hoehrmann <derhoermi@gmx.net> Mon, 02 February 2015 22:44 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D941A1AF0 for <ietf@ietfa.amsl.com>; Mon, 2 Feb 2015 14:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 87xxSQ2mEMxz for <ietf@ietfa.amsl.com>; Mon, 2 Feb 2015 14:44:21 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3883A1A1AAC for <ietf@ietf.org>; Mon, 2 Feb 2015 14:44:21 -0800 (PST)
Received: from netb ([89.15.237.44]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0ME33j-1YRQOW3kyN-00HQnn for <ietf@ietf.org>; Mon, 02 Feb 2015 23:44:18 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard
Date: Mon, 02 Feb 2015 23:44:17 +0100
Message-ID: <s1rvca57bmdur9v5go4t40junu8ivhcskv@hive.bjoern.hoehrmann.de>
References: <20141021213356.16262.50640.idtracker@ietfa.amsl.com>
In-Reply-To: <20141021213356.16262.50640.idtracker@ietfa.amsl.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:hf0sRnOywpjW3yH7FwBvwv4C28P7hg7tZN4eaU7oBvCkoquZo0m 948sRBjPzsjGEzoJe8y4sNvz+cDKxuB44Upe3T7QcpNCR64lVKYPT4mBUwR3+q1XHwa2/wi wUVc1Ykwh/SCyrvfR4Ep0SUA27JNmcgPzEw4YcrJVhe/5e0JCClOod3q3dm/Pzs4EJuUX/G Q9cc5Rk16213X50Qh5ISA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UfdMiaHv5UOeiK0v2Hb5B7Eevcg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 22:44:23 -0000

* The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'The "safe" HTTP Preference'
>  <draft-nottingham-safe-hint-05.txt> as Proposed Standard

I think the document should not become a Proposed Standard.

In addition to what others have said I would like to note that the
proposal fails to describe how the header is implemented in practise.
For instance, in the Firefox implementation the header broadcasts that
the user's system is in "parental control mode". That is very different
from expressing the user's content preferences.

I also note the lack of "privacy" considerations with respect to such
implementations in the document. It is unlikely that the User Agent is
actually acting on behalf of the user in sending this header. In fact,
the proposal contradicts itself, it claims this is a user preference,
and then notes that it is important to ensure that users cannot actually
state their own preference. According to the draft it is not permissable
to obscure, say, NSFW content for users sending the header and also have
a "show anyway" button.

What should we tell children asking what to do if they do not want
random web sites to know they are most probably a child? I would expect
the draft to provide an answer to the affected users, a better one than
saying that sites cannot be 100% certain. I note that in some legal
environments an almost perfect indicator that the visitor is a child may
imply obligations that sites can currently avoid because so far there
was no such indicator. I think it is misleading to avoid discussing this
in the draft.

The Microsoft documentation referenced in the document says "Web sites
that receive this header should filter out adult material that is
unsuitable for children when the web sites respond to the HTTP requests"
while the draft tries to cast the header as something much more generic.
I do not think it is unreasonable to expect some consensus around the
semantics of the header prior to becoming a Proposed Standard.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/