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

Eliot Lear <lear@cisco.com> Tue, 18 November 2014 18:43 UTC

Return-Path: <lear@cisco.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 203ED1A1B13 for <ietf@ietfa.amsl.com>; Tue, 18 Nov 2014 10:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ZbqXUwfHLjZY for <ietf@ietfa.amsl.com>; Tue, 18 Nov 2014 10:43:46 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A3A1A6F0A for <ietf@ietf.org>; Tue, 18 Nov 2014 10:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1827; q=dns/txt; s=iport; t=1416336211; x=1417545811; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ceEDKyVvJFn0Ksqa4Ic+0MBs2gFiLxSyS41OPNV5OXM=; b=G0zTK7vsRf+PqkOnsqSwKTk7s+cY2IB+5UkHJtHDrRqpGMsxtLf3m/xq Sqpm9eMOnZ3aRNhiqtipXvD67JfOIN3wm3Ww+fADttSDOLehszjl++tSM gLSgJVdDhWULUCdtoWa4UURkmJDKmgla4JlbWpRAQEwmWUFX8NPeAgp3H U=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAASTa1StJV2Z/2dsb2JhbABbgw5Vg1/QZQKBERYBAQEBAX2EAwEBBCNJChMLEgYJGgcCAg8COA4GAQwIAQGIPbo6lwMBAQEBAQEBAwEBAQEBAQEbkBt0gneBVAEElG+BUogViAGOeII2gUY8gnsBAQE
X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="asc'?scan'208";a="373327544"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 18 Nov 2014 18:43:30 +0000
Received: from [10.61.102.18] (dhcp-10-61-102-18.cisco.com [10.61.102.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAIIhSVq012357; Tue, 18 Nov 2014 18:43:29 GMT
Message-ID: <546B9350.80702@cisco.com>
Date: Tue, 18 Nov 2014 19:43:28 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Doug Barton <dougb@dougbarton.us>, Mark Nottingham <mnot@mnot.net>, IETF <ietf@ietf.org>
Subject: Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard
References: <F4F3F5AD-C50A-49F5-A3CD-8DE337D7EA36@mnot.net> <546B87F2.3010800@dougbarton.us>
In-Reply-To: <546B87F2.3010800@dougbarton.us>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="OE5p6R2kfwQBwakHojkxNTpoqdkQMShuS"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/-B-srMQJ04WtoYcIsD02qiNfdhw
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: Tue, 18 Nov 2014 18:43:49 -0000

On 11/18/14, 6:54 PM, Doug Barton wrote:
> So what's to stop that malicious site owner from putting up a block on
> their site unless you fill out the form that tells them the PII they
> want to know?

The research in this space is far from simple.  It is true that for very
little in return users will tend to share.[1]  And it is also well
established that users will overshare.[2]  And so what you say is likely
to be true IFF users gain something of value to them.  But this being
the case, I think what you're asking is actually not relevant in this
case.  Users have the option of setting or not setting a bit, and
content providers have the option of honoring or ignoring it.

Eliot
[1] Egelman, et. al, "Choice Architecture and Smartphone Privacy", WEIS
2012.
[2] Preibusch, et. al, "The privacy economics of voluntary
over-disclosure in Web forms", WEIS 2012.