Re: [quicwg/base-drafts] "External observers" is undefined (#3448)

ekr <> Tue, 11 February 2020 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14D82120168 for <>; Tue, 11 Feb 2020 07:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMoHmSc_63E6 for <>; Tue, 11 Feb 2020 07:23:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 879C6120164 for <>; Tue, 11 Feb 2020 07:23:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 83586C60350 for <>; Tue, 11 Feb 2020 07:23:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581434586; bh=X3rpiapn7PtXCnBcZXoPTpFleySfFa5cRvYM2DzEnr8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=shGcHyDMX6u7c6MmoDGPeLfwN1Tkkq6YwsYvh1dW7NpoR4k0gBjpWOUPvCe/IplwD sc5/8LBM5ilrAZfuQDHeGpaWAsXm/xFoCBa0aw/Vs3dj0uJjBl+/CMWxh2rUK8494M ROaT/0sPjCNpziXekOdtcw1hER2TWczFK3Ob466g=
Date: Tue, 11 Feb 2020 07:23:06 -0800
From: ekr <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3448/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] "External observers" is undefined (#3448)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e42c6da74965_5b4c3f98f70cd9681477d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 15:23:09 -0000

On Tue, Feb 11, 2020 at 7:05 AM D. Ebdrup <> wrote:

> On Tue, Feb 11, 2020 at 6:31 AM D. Ebdrup *@*.***> wrote: Thanks for
> pointing me here, Martin. :) Cooperation, to me and seemingly according to
> the second definition of Merrian-Webster
>, seems to imply
> that even just two parties (one first-party and one third-party, for
> example) are cooperating on something, especially considering the example
> underneath given involves trade and economy.
> I agree with your definition, but I don't understand your point.
> My point in the initial email to Martin was that the language seems to
> provide for companies to share Connection ID data, or data derived from it,
> with third parties - so long as the companies have legal contracts defining
> that they are cooperating.
Yes, or without contracts for that matter. The point of "cooperating" is
not to restrict commercial agreements but to technically define the privacy
properties we expect CID construction to provide.

> That doesn't seem, to me at least, to be a good idea when a bit of more
> precise use of language (such as the regular expression above by Martin,
> with a modification to allow for load-balancers, as rightly pointed out)
> could very easily nip it in the butt, as it were. :
I'm not particularly a huge fan of tracking either, but that's not the
issue here. We're not the protocol police and this text is not about
setting business policy. It's a technical requirement to forbid designs
which would be insecure.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: