Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)

MikkelFJ <> Tue, 05 November 2019 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E37612022E for <>; Tue, 5 Nov 2019 00:40:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 usyycE4e8P1x for <>; Tue, 5 Nov 2019 00:40:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDA001201E5 for <>; Tue, 5 Nov 2019 00:40:30 -0800 (PST)
Date: Tue, 05 Nov 2019 00:40:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572943229; bh=TYLPBGJxm3I3O6UDU3DU8nwG9QwVAdwzngWkVzV5jQ0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZgvR76LybuySzam6PFQw4NukekEIassWJ0suoVRViTMXTnab+UqlNFA6ZMXd/nS91 /TvxHoVFRyBfk75tyMp0/7PMIXOG2d9VgMKoXNr3eSdbhmcuxb52b0cfijpM63t8zT pxVofZbTFeeCEBocofYTOvulnnGmTOVUkla5kjLk=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3155/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc1357dde10a_2b5f3fb1ff8cd96c661948"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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, 05 Nov 2019 08:40:32 -0000

> The latter condition is where the various linkages come into play, but the point remains that the client is responsible for making an assessment. This text is about setting a common baseline for that.

I think it is a good thing to cover multiple networks because you can hide from external observers. But, if you are on a corporate or government MITM proxy matters are only going to get worse. That said, QUIC cannot possibly accommodate deliberately broken networks.

Also, clients have interests adverse to users as well - for example Google and Facebook need qualified advertising traffic and if QUIC tokens can slip under the Cookie radar, they will. I can't manage a Google cloud cluster without logging in to Youtube on an account that has never signed up for Youtube, and now I can't watch cat videos without getting cluster management commercials which really goes against the point of watching cat videos in the first place (or something roughly equivalent), so on.

So, there is tension in how much to leave for the client to decide vs actual user privacy.

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