Re: [dns-privacy] Deborah Brungard's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Wed, 04 March 2020 13:31 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5F3A0F22; Wed, 4 Mar 2020 05:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 U2nE1dXfuUOD; Wed, 4 Mar 2020 05:31:24 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FB33A0F32; Wed, 4 Mar 2020 05:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=1XSezpZUPJeax1CBVDqbli9JkzbH/iXU/3az06UCpUA=; b=ZFX0FZsiaeVOVXIJ4J0xYL968v 0tio+svafVGwj/HFAg+vEOO6Ip7WLx9s54dMeGAxheh3CQ4PKhSWZO+ecal1BI+0MJCBb2ITr3bXz dDW9TJWxdInBai3CiYTloaGmuvc8dwvkDXpQla3WFbsx6lvtrQ6X5dSh8+ZLLEUf8T2XaJLJOfqds F4XgLVi2NtMF4S5M80CCWZJ8sDCWcBC/Jb2NtrlWJzMH+MUGDbIC6PnYJXUHUEP70wyCbRVhknhyO YYrA3DXakJmAGXbavp1ZDDDZZT4w4ZxcLh9+be8x0SoVdx9se1hNQzn9HPymdwhqd+/n8hFLLKqBc wDpcNwFQ==;
Received: from [2001:b98:204:102:fffa::2] (port=63226) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1j9U7K-0001Dt-RU; Wed, 04 Mar 2020 13:31:22 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <A525DAD8-FBA1-42CB-8A96-75C703042523@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8FDB72CA-7044-4AF4-A551-93FFEBD8F281"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 4 Mar 2020 13:31:17 +0000
In-Reply-To: <158093707970.12775.12544642589807279004.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
To: Deborah Brungard <db3546@att.com>
References: <158093707970.12775.12544642589807279004.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/HWNdbfH9a9C3CD-_t3B21FglVe8>
Subject: Re: [dns-privacy] Deborah Brungard's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 13:31:34 -0000


> On 5 Feb 2020, at 21:11, Deborah Brungard via Datatracker <noreply@ietf.org> wrote:
> 
> Deborah Brungard has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In general, I support this document. It is good to help educate folks on what
> should be included in a privacy statement, but as Alissa notes, there is no "one
> size fits all". Especially if one implies a cookie cutter type of form with check
> marks will be adequate to compare offerings. I don't think this is what was
> intended - considering the detailed assessment on the DROP form - but
> there's a couple of sentence stragglers that infer the DROP form is the form
> *for all*.
> 
> Support Alissa's and Ben's Discuss.
> 
> A couple of my concerns:
> 
> 5.3.3 Both Alissa (and Stephen previously) noted there is no meaningful way to obtain
> explicit  "consent". Considering this document is a "best practice", suggest simply
> removing, and recommending as Alissa says "not share".
> 
> 6.1.2 #5 agree with Alissa - this should be removed.
> 

Please see the responses to Alissa on these two points. 

> 
> 6.2 "We note that the existing set of policies vary widely in style,
>   content and detail and it is not uncommon for the full text for a
>   given operator to equate to more than 10 pages of moderate font sized
>   A4 text.  It is a non-trivial task today for a user to extract a
>   meaningful overview of the different services on offer."
> 
> I'm not sure what this is trying to say? The purpose of this document is
> to advocate for comprehensive privacy statements. As Alissa notes (2), this document
> alone is not sufficient to give adequate description for a service.  
> This sentence implies
> a 10-page document is bad because it is 10 pages (yet this document's DROP example
> has 5 pages requiring detailed information and lists to complete). And the last sentence
> negatively prejudges a user's reading capability or specific interest. Suggest drop the last
> sentence and it will remove the negativity as I don't think the DROP example is any easier
> on a user to read.

One of the other key goals is to provide _consistent_ document structure that can be easily compared or used to find specific bits of information. I personally read all the privacy policies as part of creating this matrix
https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements+2019 <https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements+2019>
and it was a non-trivial and very time consuming task for me! Every policy uses a different layout, language, and can be spread over multiple separate webpages.

If section 5 of 6.1.2 is removed then I think the example DROP would be ~3 pages in comparable text...I really do like to think that DROP statements would make this process easier and it was a genuine motivation behind this work….

Best regards

Sara.