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

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 24 October 2014 20:13 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 277B41A0A6A for <ietf@ietfa.amsl.com>; Fri, 24 Oct 2014 13:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.259
X-Spam-Level: *
X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
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 BPH8jMv2KrjV for <ietf@ietfa.amsl.com>; Fri, 24 Oct 2014 13:13:00 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F161A6F3F for <ietf@ietf.org>; Fri, 24 Oct 2014 13:12:59 -0700 (PDT)
Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C3ADA8A035 for <ietf@ietf.org>; Fri, 24 Oct 2014 20:12:58 +0000 (UTC)
Date: Fri, 24 Oct 2014 16:12:56 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard
Message-ID: <20141024201256.GP2240@mx1.yitter.info>
References: <20141023140635.10188.qmail@ary.lan> <87A3AD2B-5747-46EB-A165-50D35A29DBA7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87A3AD2B-5747-46EB-A165-50D35A29DBA7@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/gaY-bJGsaMMYVSZIF0WBLs1HzbM
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: Fri, 24 Oct 2014 20:13:02 -0000

On Fri, Oct 24, 2014 at 10:49:08PM +0300, Yoav Nir wrote:
> 
> no way to use it properly. The drafts does not specify what “safe”
> content is and what “unsafe” content it, and some people treat this
> as an advantage. 

Not as an advantage, but the whole point of the feature.

> The result is that there’s no way for a content
> provider to know what a user means when their browser emits the
> “safe” hint, and no way for the user to know what kind of content
> they are going to get.

This is true.  It is also what is the case on the Internet today.

Suppose the feature, instead of being called "safe", was called
"userflag".  Sites had a local policy that provided one set of
functionality when userflag=1 and a different set of functionality
when userflag=0.  What the policy was varied from site to site, and it
was up to users to know, for any site, what the policy would be if
they turned userflag on.  But once they did, then they'd get the
userflag-enabled service from that site.

"Ah," you might reply, "but what the user actually wants is a
fine-grained preference control system.  So the userflag feature is
stupid and bad and we should prevent it."

Moreover, suppose that there already was a mechansism that permitted a
user to expose all the things that he or she did and did not want to
experience in using a site, and that its main problem was that nobody
used it.

The story above is roughly what we have here.  There is already at
least one well-specified, comprehensive vocabularly for you to express
all the things you think to be safe and non-safe:
http://www.w3.org/PICS/.  It is, in commercial terms, almost a total
failure in the sense that it's too hard to use and doesn't solve the
problem people think they have.

As a result, sites offer a "safe mode" that does whatever it is that
the site does.  It isn't anything that I personally find at all
useful, and I think that trusting sites to have the same judgement as
I do suggests a touching faith in humankind.  But the full-bore system
is already there, it doesn't get used, and people are already using
this one-bit style of approaching the problem.  All the draft does is
say, "If you're going to use this one bit style, please signal it
thus."

If the goal is interoperability on the Internet, it seems to me that
getting all the dumb ways to "protect" yourself to signal "dumb
protection, please" the same way is a good thing.  

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com