From nobody Mon Mar 2 10:53:28 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F63A0EDA; Mon, 2 Mar 2020 10:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TK7p3H-iT0tW; Mon, 2 Mar 2020 10:53:20 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C8D3A0ED7; Mon, 2 Mar 2020 10:53:20 -0800 (PST) Received: from p200300dee7239a00fcc74dc47cb342f6.dip0.t-ipconnect.de ([2003:de:e723:9a00:fcc7:4dc4:7cb3:42f6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j8qBl-0002ym-VZ; Mon, 02 Mar 2020 19:53:14 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 2 Mar 2020 19:53:13 +0100 Cc: wpack-chairs@ietf.org, wpack@ietf.org, The IESG , Alexey Melnikov Content-Transfer-Encoding: quoted-printable Message-Id: <0E1EB5BC-F62A-4A47-BDC9-1D660767B0BA@kuehlewind.net> References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583175200;94a18141; X-HE-SMSGID: 1j8qBl-0002ym-VZ Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 18:53:22 -0000 Hi Jeffrey, hi all, The proposed changes work for me and would clarify what=E2=80=99s meant. = However, I=E2=80=99m wondering if all these details need to go into the = charter but that=E2=80=99s a different questions and nothing I would = block on. Mirja > On 28. Feb 2020, at 22:32, Jeffrey Yasskin = wrote: >=20 > On Fri, Feb 28, 2020 at 1:20 PM Jeffrey Yasskin = wrote: > On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov = wrote: > Hi Mirja, >=20 > I am only replying below to your blocking comments: >=20 > On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker = wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > charter-ietf-wpack-00-14: Block > >=20 > > 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.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > BLOCK: > > = ---------------------------------------------------------------------- > >=20 > > Thanks for all the discussion that happen on the charter so far, = unfortunately > > there are still a few points that are not fully clear to me from a = transport > > perspective: > >=20 > > 1) It not clear to me how you plan to address low latency. I assume = you don't > > want to optimise anything in the lower layers but it does sound a = bit like it. > > Can you clarify this point? >=20 > WPACK is working on a bundle format, so there is no transport protocol = here.. Can you suggest how to clarify this? >=20 > We could split this into two requirements: >=20 > >>>>> > * When a bundle is streamed, the client must be able to start using a = subresource before the entire bundle is downloaded, and for large = subresources, before the entire subresource is downloaded. >=20 > * When a bundle is loaded from random-access storage, the client must = be able to use a subresource without necessarily reading the entire = prefix of the bundle before that subresource. > <<<<< >=20 > I missed the "whether or not the package is authenticated" aspect. = That needs something like: >=20 > * When a bundle is authenticated, the client must be able to validate = the authentication without extra requests over the network. > =20 > This drives the ability to include certificate chains, SCTs (for = certificate transparency), and OCSP responses (for revocation) in the = bundle. >=20 > Jeffrey=20 From nobody Mon Mar 2 11:06:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B53A0F1A; Mon, 2 Mar 2020 11:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gmQri5M48aSL; Mon, 2 Mar 2020 11:06:37 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728033A0F00; Mon, 2 Mar 2020 11:06:37 -0800 (PST) Received: from p200300dee7239a00fcc74dc47cb342f6.dip0.t-ipconnect.de ([2003:de:e723:9a00:fcc7:4dc4:7cb3:42f6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j8qOe-0006Yk-Hs; Mon, 02 Mar 2020 20:06:32 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 2 Mar 2020 20:06:31 +0100 Cc: Alexey Melnikov , wpack-chairs@ietf.org, wpack@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583175997;1c3a6517; X-HE-SMSGID: 1j8qOe-0006Yk-Hs Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 19:06:41 -0000 Hi Jeffrey, hi Alexey, See inline. > On 28. Feb 2020, at 22:20, Jeffrey Yasskin = wrote: >=20 > On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov = wrote: > Hi Mirja, >=20 > I am only replying below to your blocking comments: >=20 > On Thu, Feb 27, 2020, at 3:07 PM, Mirja K=C3=BChlewind via Datatracker = wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > charter-ietf-wpack-00-14: Block > >=20 > > 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.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-wpack/ > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > BLOCK: > > = ---------------------------------------------------------------------- > >=20 > > Thanks for all the discussion that happen on the charter so far, = unfortunately > > there are still a few points that are not fully clear to me from a = transport > > perspective: > >=20 > > 1) It not clear to me how you plan to address low latency. I assume = you don't > > want to optimise anything in the lower layers but it does sound a = bit like it. > > Can you clarify this point? >=20 > WPACK is working on a bundle format, so there is no transport protocol = here.. Can you suggest how to clarify this? >=20 > We could split this into two requirements: >=20 > >>>>> > * When a bundle is streamed, the client must be able to start using a = subresource before the entire bundle is downloaded, and for large = subresources, before the entire subresource is downloaded. >=20 > * When a bundle is loaded from random-access storage, the client must = be able to use a subresource without necessarily reading the entire = prefix of the bundle before that subresource. > <<<<< >=20 > Those were roughly what I had in mind when I wrote "low latency=E2=80=9D= . I replied to this in the other mail. I think this much more clear than = just taking about =E2=80=9Clow latency=E2=80=9D (but might be too = detailed=E2=80=A6?) >=20 > The current format achieves the first by putting the index of = subresources at the start of the bundle (unlike ZIP) and by using = https://tools.ietf.org/html/draft-thomson-http-mice-03 to protect = subresource integrity. >=20 > It achieves the second by having an index (unlike multipart/*). >=20 > > 2) I think "Being extensible and crypto agile" is a requirement we = have for any > > protocol we design. Is there anything special here, or why is this = listed? >=20 > Nothing special in this case, but in order to avoid any doubts. Actually I will not block on this one. But given the charter is already = collecting a bunch of very different requirement on different level, = maybe take this out of the list and rather add a sentence at the end=E2=80= =A6 >=20 > > 3) I also don't really understand this point > > "Specifying constraints on how clients load the formats without = describing > > specific loading algorithm to help achieve the above goals" > > Can you further explain? I assume there are no transport = implications here but > > as I'm not sure what is meant, I'd like to double-check! >=20 > No transport implications. By "load" this means from disk/web browser = cache. Does this help? >=20 > See also the discussion on the IESG list under "WG Review: Web = Packaging (wpack)" and at = https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/. Looking at that mail, maybe it would more appropriate to talk about = "security constrains=E2=80=9D instead of only =E2=80=9Cconstrains". For = me it would also help if the word browser would show up in the sentence = e.g. =E2=80=9Cwith specifying algorithm for the brewers on how to load = the format=E2=80=9D. However, again I find the chosen format of using bullet points only = instead of text (at least for the main goals) not really = reader-friendly... >=20 > > 4) Again here I'm not sure what is meant and I assume you don't plan = for any > > transport protocol changes or extension but double-checking! = "Optimize > > transport of large numbers of small same-origin resources." What = does this > > mean? What's the solution you have in mind? >=20 > I might need Jeffrey's help to reply to this one. I am pretty sure = there are no transport protocol implications. >=20 > This was about improving compression by letting the compression = algorithm keep state across many resources. There have also been a few = attempts to get the same benefits in HTTP directly, whose difficulties = have led to = https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00. It would really help me if this would say anything about compression = rather than just =E2=80=9Coptimising transport=E2=80=9D=E2=80=A6 Thanks! Mirja >=20 > Thanks for the transport-oriented review! >=20 > Jeffrey From nobody Wed Mar 4 11:13:28 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753543A14FF; Wed, 4 Mar 2020 11:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=Krq1BLpr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yd3lRPjk 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 WNLzAux8E3Ai; Wed, 4 Mar 2020 11:13:18 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55E73A14FC; Wed, 4 Mar 2020 11:13:17 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3BCC021B8B; Wed, 4 Mar 2020 14:13:17 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Wed, 04 Mar 2020 14:13:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=EVnzh WrQMtEUwlR535wkrNRG9UGRBjY7sVtWRq4sM6I=; b=Krq1BLpr/wChEzzTlAf8k K40N7fO+xvfFt10It/eBdcLDHptpGulyz6Ytf22wqxwfYcdJGmFEI4NtbM/nrvVJ aOCbnxuA374qaKCobOXaOwvGWVASCKNgnQvcuY5nsQCYuMOAulbLGzFPcfdQi1+/ mbVU1KU0NtAt/2NgVmaVKuD5xo+oTVmiGYWmQVWJxDVt+8X+4rxi9cOdMoeOYBXW 4xrSBVsQpHsdtK/BmVJN4mBZQUe88C/CZFFxv4xUQMBjF0b6cs3DUzEzNviEjhPh dxQtGYdg+3rYjViKu+4sshBIef/N6awL8i9r7c+3S7u74tmpvW337620bd4D3rLc w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=EVnzhWrQMtEUwlR535wkrNRG9UGRBjY7sVtWRq4sM 6I=; b=yd3lRPjkEiBuvByYHYia5EeScl3L6qICnxu7CCJZMaTQh0qz9b5eC1mXZ peKWJPh57HN5H9So421tCIDtOanZOxjDJxrPNV8EN0TTSbybQa1MbxfmTKYcDWd9 IXCB7RhadEwuakYI0Lf6y9OhWStJ8AGYOlq63nB5i7FX2y7BXsLO3Tw05c4dopPx jgJghigNar6tTzHaqBwhLdXSp+1iRYAEC7bEGNxFYL6XCvzUCqTO7ays4LyAS9Q8 JDt2cs1FhSf29QCP1ELkTU+V8G3yqNT6OcRt/rOFQX6RI2eTTcst7IIcuDhlLm+5 Zhk+OMZbcUJ5iAXqfdtqgjdG2fltg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtkedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet lhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmh grihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 80728660069; Wed, 4 Mar 2020 14:13:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-986-gfc2d493-fmstable-20200304v3 Mime-Version: 1.0 Message-Id: <567843f8-b5b1-4540-a00d-99bd500ab3fd@www.fastmail.com> In-Reply-To: <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> Date: Wed, 04 Mar 2020 19:12:54 +0000 From: "Alexey Melnikov" To: "Mirja Kuehlewind" , "Jeffrey Yasskin" Cc: wpack-chairs@ietf.org, wpack@ietf.org, "The IESG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 19:13:21 -0000 Hi Mirja, Just replying to your point #4 below: On Mon, Mar 2, 2020, at 7:06 PM, Mirja Kuehlewind wrote: > Hi Jeffrey, hi Alexey, >=20 > See inline. >=20 > > On 28. Feb 2020, at 22:20, Jeffrey Yasskin w= rote: > >=20 > > On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov wrote: > > > 4) Again here I'm not sure what is meant and I assume you don't pl= an for any > > > transport protocol changes or extension but double-checking! "Opti= mize > > > transport of large numbers of small same-origin resources." What d= oes this > > > mean? What's the solution you have in mind? > >=20 > > I might need Jeffrey's help to reply to this one. I am pretty sure t= here are no transport protocol implications. > >=20 > > This was about improving compression by letting the compression algo= rithm keep state across many resources. There have also been a few attem= pts to get the same benefits in HTTP directly, whose difficulties have l= ed to https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00. >=20 > It would really help me if this would say anything about compression=20= > rather than just =E2=80=9Coptimising transport=E2=80=9D=E2=80=A6 I've changed that to read: Optimize storage of large numbers of small same-origin resources (e.g. = using compression) Hopefully this is clearer. Best Regards, Alexey From nobody Wed Mar 4 11:15:17 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E893A1503; Wed, 4 Mar 2020 11:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SjEF2q8VRgLj; Wed, 4 Mar 2020 11:15:00 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E4F3A1508; Wed, 4 Mar 2020 11:14:59 -0800 (PST) Received: from p200300dee7239a0084809b28d0f22131.dip0.t-ipconnect.de ([2003:de:e723:9a00:8480:9b28:d0f2:2131]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j9ZTs-0002N0-Dz; Wed, 04 Mar 2020 20:14:56 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <567843f8-b5b1-4540-a00d-99bd500ab3fd@www.fastmail.com> Date: Wed, 4 Mar 2020 20:14:55 +0100 Cc: Jeffrey Yasskin , wpack@ietf.org, wpack-chairs@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> <567843f8-b5b1-4540-a00d-99bd500ab3fd@www.fastmail.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583349300;a4dde7ce; X-HE-SMSGID: 1j9ZTs-0002N0-Dz Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 19:15:12 -0000 Thanks! > On 4. Mar 2020, at 20:12, Alexey Melnikov = wrote: >=20 > Hi Mirja, > Just replying to your point #4 below: >=20 > On Mon, Mar 2, 2020, at 7:06 PM, Mirja Kuehlewind wrote: >> Hi Jeffrey, hi Alexey, >>=20 >> See inline. >>=20 >>> On 28. Feb 2020, at 22:20, Jeffrey Yasskin = wrote: >>>=20 >>> On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov = wrote: >>>> 4) Again here I'm not sure what is meant and I assume you don't = plan for any >>>> transport protocol changes or extension but double-checking! = "Optimize >>>> transport of large numbers of small same-origin resources." What = does this >>>> mean? What's the solution you have in mind? >>>=20 >>> I might need Jeffrey's help to reply to this one. I am pretty sure = there are no transport protocol implications. >>>=20 >>> This was about improving compression by letting the compression = algorithm keep state across many resources. There have also been a few = attempts to get the same benefits in HTTP directly, whose difficulties = have led to = https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00. >>=20 >> It would really help me if this would say anything about compression=20= >> rather than just =E2=80=9Coptimising transport=E2=80=9D=E2=80=A6 >=20 > I've changed that to read: >=20 > Optimize storage of large numbers of small same-origin resources (e.g. = using compression) >=20 > Hopefully this is clearer. >=20 > Best Regards, > Alexey >=20 >=20 From nobody Wed Mar 4 11:21:38 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95AD3A151C; Wed, 4 Mar 2020 11:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=LwlbZV02; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nztzlqWn 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 eje2d7ELbZ3E; Wed, 4 Mar 2020 11:21:30 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341023A1519; Wed, 4 Mar 2020 11:21:30 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4BD49210DC; Wed, 4 Mar 2020 14:21:29 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Wed, 04 Mar 2020 14:21:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=NQKWQ 6ipANAxs9vapMxes50k1L2bEP0wmyS9znDSJ1U=; b=LwlbZV02eTcXZ5vX5fy+b oHouXOnn81/vuXtgE21QXVWVdfRC4ktWm0WKb1BE/V186IQ2mvtFZpPORApsbZoX j21CCsYVbl4DIAx3pkLiSTRSHoOEbbAgneFo5FUHYNjrwi6NlVcCOQUo/fLdFQEq woEPaVhiaLR/1Iv9j2Cl38LckbhpX/tj+70a0U+RsTzSnrYC7vtXkCK2G/oQsrTC w+w8I6HRwAqDbVb6Vef+6XZ9LA2PENM91vrtAX2lI734U2M3cAolkQUX6j5N8ESC fDN39EzWjUafhCr/NTSVndGSrdoeGbttNK0RBwmFKRGRd3FX9vVy2oCObvds/Rr6 A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=NQKWQ6ipANAxs9vapMxes50k1L2bEP0wmyS9znDSJ 1U=; b=nztzlqWnrlkCiS1LqyKKpdpXv/KJMzKLkpRAk2XFwrfWHYb1/ozkUFzvs XCisBfOEAcixytkct50JN9/zmYtQSHrzmPbEfK51BWqEMo7KfN7oa2rF3hM5DLvT V/laAPzjEU8ntZ0GQy0YDvikIoHZuX4wJ4VQQt3UiUXgq0rXrF2rJHGlf4EWacZv F6pqPk5GkDMzuaLROLNzd4jjM03OTqTTzMwzZvpPmaF365Bsx2Wkoh6dl6kwm39p 7RVHuV/wNrxhCf7N3R5tJxjdfcRWU+vljfX/X8YfBIjyZKWmf5jsTv0MndLoDrKQ dJfKhIppURE7kzxzUADA3C5ElrIQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtkedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet lhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmh grihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE92F660069; Wed, 4 Mar 2020 14:21:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-986-gfc2d493-fmstable-20200304v3 Mime-Version: 1.0 Message-Id: <04e76ac1-4237-441f-bdf2-26941edc2159@www.fastmail.com> In-Reply-To: <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> Date: Wed, 04 Mar 2020 19:21:08 +0000 From: "Alexey Melnikov" To: "Mirja Kuehlewind" , "Jeffrey Yasskin" Cc: wpack-chairs@ietf.org, wpack@ietf.org, "The IESG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 19:21:32 -0000 Hi Mirja, I addressed your point #1 as per Jeffrey's suggestions. You agreed no ch= anges for #2. #4 was addressed in my previous email. Replying to your remaining point #3 below: On Mon, Mar 2, 2020, at 7:06 PM, Mirja Kuehlewind wrote: > Hi Jeffrey, hi Alexey, >=20 > See inline. >=20 > > On 28. Feb 2020, at 22:20, Jeffrey Yasskin w= rote: > >=20 > > On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov wrote: > > > 3) I also don't really understand this point > > > "Specifying constraints on how clients load the formats without de= scribing > > > specific loading algorithm to help achieve the above goals" > > > Can you further explain? I assume there are no transport implicati= ons here but > > > as I'm not sure what is meant, I'd like to double-check! > >=20 > > No transport implications. By "load" this means from disk/web browse= r cache. Does this help? > >=20 > > See also the discussion on the IESG list under "WG Review: Web Packa= ging (wpack)" and at https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6= vSxHz3jC3eqcVhYkIF1s/. >=20 > Looking at that mail, maybe it would more appropriate to talk about=20= > "security constrains=E2=80=9D instead of only =E2=80=9Cconstrains".=20= I am not sure that only security constrains are intended here. > For me it would=20 > also help if the word browser would show up in the sentence e.g. =E2=80= =9Cwith=20 > specifying algorithm for the brewers on how to load the format=E2=80=9D= . We do have other HTTP clients which are not browsers, so I think saying = browser above would be too restrictive... > However, again I find the chosen format of using bullet points only=20= > instead of text (at least for the main goals) not really=20 > reader-friendly... Best Regards, Alexey From nobody Wed Mar 4 11:51:37 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14263A03F2; Wed, 4 Mar 2020 11:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1mCvfQ_wYTFi; Wed, 4 Mar 2020 11:51:31 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8233A02BC; Wed, 4 Mar 2020 11:51:30 -0800 (PST) Received: from p200300dee7239a0084809b28d0f22131.dip0.t-ipconnect.de ([2003:de:e723:9a00:8480:9b28:d0f2:2131]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j9a3E-0008MU-1w; Wed, 04 Mar 2020 20:51:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <04e76ac1-4237-441f-bdf2-26941edc2159@www.fastmail.com> Date: Wed, 4 Mar 2020 20:51:27 +0100 Cc: Jeffrey Yasskin , wpack@ietf.org, wpack-chairs@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158281607227.2144.7066471693425440365.idtracker@ietfa.amsl.com> <9449bb04-4b54-4a50-8273-fb368d91fd8b@www.fastmail.com> <91281DDF-3075-40A3-9F3D-8E0BD8DFA2B6@kuehlewind.net> <04e76ac1-4237-441f-bdf2-26941edc2159@www.fastmail.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583351490;fc53f079; X-HE-SMSGID: 1j9a3E-0008MU-1w Archived-At: Subject: Re: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf?= =?utf-8?q?-wpack-00-14=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 19:51:33 -0000 Hi Alexey, I just cleared my block. Thanks for the additional edits and = explanations! I hope these latest changes do help to make thing clearer for any = potential future charter-based discussions during the wg=E2=80=99s life = time! Mirja > On 4. Mar 2020, at 20:21, Alexey Melnikov = wrote: >=20 > Hi Mirja, >=20 > I addressed your point #1 as per Jeffrey's suggestions. You agreed no = changes for #2. #4 was addressed in my previous email. >=20 > Replying to your remaining point #3 below: >=20 > On Mon, Mar 2, 2020, at 7:06 PM, Mirja Kuehlewind wrote: >> Hi Jeffrey, hi Alexey, >>=20 >> See inline. >>=20 >>> On 28. Feb 2020, at 22:20, Jeffrey Yasskin = wrote: >>>=20 >>> On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov = wrote: >=20 >>>> 3) I also don't really understand this point >>>> "Specifying constraints on how clients load the formats without = describing >>>> specific loading algorithm to help achieve the above goals" >>>> Can you further explain? I assume there are no transport = implications here but >>>> as I'm not sure what is meant, I'd like to double-check! >>>=20 >>> No transport implications. By "load" this means from disk/web = browser cache. Does this help? >>>=20 >>> See also the discussion on the IESG list under "WG Review: Web = Packaging (wpack)" and at = https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/. >>=20 >> Looking at that mail, maybe it would more appropriate to talk about=20= >> "security constrains=E2=80=9D instead of only =E2=80=9Cconstrains".=20= >=20 > I am not sure that only security constrains are intended here. >=20 >> For me it would=20 >> also help if the word browser would show up in the sentence e.g. = =E2=80=9Cwith=20 >> specifying algorithm for the brewers on how to load the format=E2=80=9D= .. >=20 > We do have other HTTP clients which are not browsers, so I think = saying browser above would be too restrictive... >=20 >> However, again I find the chosen format of using bullet points only=20= >> instead of text (at least for the main goals) not really=20 >> reader-friendly... >=20 > Best Regards, > Alexey >=20 >=20 From nobody Wed Mar 4 11:53:57 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D988B3A0404; Wed, 4 Mar 2020 11:53:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158335163086.29404.14610238034883018591@ietfa.amsl.com> Date: Wed, 04 Mar 2020 11:53:50 -0800 Archived-At: Subject: [Wpack] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-wpack-00-16=3A_=28with_COMMENT=29?= X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 19:53:51 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-wpack-00-16: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing and clarifying my block points on any transport-related potential touch points! The charter seem fine to me now to move on. I think my old comments below are still valid though (for the record mainly). One editorial comment: I find the chosen form of listing goals rather than writing text that describes the scope of the work not very reader-friendly (at least more the main/key goals). I think text instead of quite short bullet points would be more meaningful and would probably have avoided some of the discussion/confusion we had about this charter. Further I agree with Ben that this part is not very clear and could be better scoped: "Security and privacy properties of using authenticated bundles as close as practical to TLS 1.3 transport of the same resources." From nobody Thu Mar 5 06:45:24 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 548A93A15A8; Thu, 5 Mar 2020 06:45:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: wpack-chairs@ietf.org, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158341951627.14723.14970639377444952556@ietfa.amsl.com> Date: Thu, 05 Mar 2020 06:45:16 -0800 Archived-At: Subject: [Wpack] Roman Danyliw's No Objection on charter-ietf-wpack-00-16: (with COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 14:45:17 -0000 Roman Danyliw has entered the following ballot position for charter-ietf-wpack-00-16: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-wpack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben Kaduk the goal of "Address[ing] the threat model of a website compromised after a user first uses the site." requires clarification. From nobody Thu Mar 5 13:49:34 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99963A0CDC; Thu, 5 Mar 2020 13:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0QzJfkSKJp7H; Thu, 5 Mar 2020 13:49:19 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 07DC43A0CDB; Thu, 5 Mar 2020 13:49:18 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 025LnD9a028945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Mar 2020 16:49:16 -0500 Date: Thu, 5 Mar 2020 13:49:13 -0800 From: Benjamin Kaduk To: Jeffrey Yasskin Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org Message-ID: <20200305214913.GB98042@kduck.mit.edu> References: <158275938793.2785.11639350703479633599.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-12: (with BLOCK and COMMENT) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 21:49:28 -0000 On Fri, Feb 28, 2020 at 02:09:49PM -0800, Jeffrey Yasskin wrote: > On Wed, Feb 26, 2020 at 3:23 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > It's not entirely clear to me whether "low latency to load a subresource" > > fits better > > as a primary or secondary goal. > > > > There's tension between "Efficient (binary) storage" and low latency > loading, since compressing the whole package as a unit will improve storage > but harm random access loading. The WG should be able to discuss that > tradeoff instead of having it already answered by the charter's choice to > describe low latency as a secondary goal. > > If we demote both to secondary goals, the charter might be read to imply > that we have to achieve TLS 1.3's liveness guarantees by, for example, > forcing authentication to happen via an extra online request to the origin > server. I'd again like the WG to discuss the tradeoff between the latency > harm of that request and its security benefit. > > We say we'll try to have security and privacy properties "as close as > > practical to > > TLS 1.3". Do we have a sense for how much distance we are willing to > > accept > > (vs. conceding that we cannot uphold our security and privacy requirements > > and produce something that satisfies the key goals) and still publish? > > > > I think that I'm only pushing to compromise on TLS's liveness guarantee, > but I haven't thought about this in detail in a couple months, so I might > be forgetting something. > > When we say that we will try to "address the threat model of a website > > compromised > > after a user first uses the site", I'm not entirely clear on which > > properties we're trying > > to preserve in the face of such threats. > > > > I described this in more detail at > https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-protecting-users-from-a-com. > In particular, a user with an existing relationship with a website > shouldn't be compromised by an attacker just because they visited the site > once at any point the attacker controlled its frontend. If the attacker > gained control of the site's build system instead, or if the attacker keeps > control for more than a site-determined amount of time, the user may still > be compromised. > > Does that make sense? It does, though I'm not sure I could distill it to a specific "list of properties" as I was asking for :) > I wanted to let the WG help work out exactly what's needed here, but the > trend of comments seems to be that we should write my current design for a > solution into the charter. If that's the case, I think the "Support signed > statements about subresources" goal is actually sufficient for this > purpose, and we could remove this item. > > Regarding the "automatic discovery" non-goal, does this preclude a way for > > a website > > to indicate how to retrieve an offline-usable version of a resource when > > that resource > > is being fetched "on-line"? > > > > I don't think it's important to prohibit this WG from discussing that > particular kind of link, mostly because I think that discussion will be > short: add to > https://www.iana.org/assignments/link-relations/link-relations.xhtml or > https://html.spec.whatwg.org/multipage/links.html#linkTypes. I wanted to > head the WG off from discussing how to find a peer's copy of a resource > that the client can't access directly. Maybe we should change the non-goal > to "A way to automatically discover the URL for an accessible (retrievable) > package that includes specific content that the client can't otherwise > access."? That might be overly specific for the non-goal; it's hard to say. Thanks for the extra explanations; unfortunately, I don't expect to have the cycles to try to craft them into text suitable for inclusion in the charter. -Ben From nobody Tue Mar 10 17:07:58 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF763A0B2A for ; Tue, 10 Mar 2020 17:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 U90TGPLIeBzm for ; Tue, 10 Mar 2020 17:07:52 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354893A0A27 for ; Tue, 10 Mar 2020 17:07:52 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id e20so323252qto.5 for ; Tue, 10 Mar 2020 17:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:reply-to:mime-version:subject:date:references:to:message-id; bh=We3qiqUpyiO4H7il7JgbQwFV28/sh5p7fJQmZvneuqU=; b=W0qRDdTGTB1e8IqlFB7QHn/JbRRawrfUuarxJRTw58r8g7tWPu8xeZ+H/xxmsiyYZN 2FV3ygKtyts29ew4ZZ2lSIcEyEMf/mMpbjlZUK6LwnYMBP9ekxk2RHnjk1iRztFfop3Q +oJ5/3Y/ijkVSJF0yFSgB4/evnrCb3SdfAJ+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:date :references:to:message-id; bh=We3qiqUpyiO4H7il7JgbQwFV28/sh5p7fJQmZvneuqU=; b=nOsjRiIW2MbPvJ6AU871BW58O0rrtq8kvwvfpVZRhrZcEhENn9Nwa5d/BmsZibsHt+ LAWF+3pNK8o0zdt3nt56k9IriqzklQjMK5IuHPwvNuMofSTVgSF33PL9xvM2ToTn84Sn 0pr2tuvYWSYsgBNOWtNbytlu/gJZmx3fOLhwKeKDWHqQrhUSiU6v525/WxrdRBOfGe1w Dy5xnBWfUov8jYvB2DKhlas8x7gZTlq0N3n6txAu1rzcbAhqFSKwxSbw67wnZnuU04MO Sw80nWi8Rxnu+KCwH9Yk0nWtAxLVDdXbObknp3klbTnBfBue2TpG+Hk8IH5TCXZFaj96 990w== X-Gm-Message-State: ANhLgQ2dFqwQLDrYcLCNHdXVyTKnCGjLLaNn4093vbcV/eWQY6Ub5Arw /7sbzONTm5ZIn91wr5J74uols2bOWdc= X-Google-Smtp-Source: ADFU+vvMTInBqfOcsKrPvRgtWGffXBCBC37W8qvSm57Ygnj7E7485QPKAn9nvJnsgO792h1AAsnArw== X-Received: by 2002:ac8:7b2f:: with SMTP id l15mr428681qtu.320.1583885265806; Tue, 10 Mar 2020 17:07:45 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id o16sm24966483qke.35.2020.03.10.17.07.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 17:07:45 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_FC29595F-0D44-429C-B6E3-C02FF4846D92" Reply-To: ietf Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 10 Mar 2020 20:07:43 -0400 References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> To: WPACK List Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Wpack] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 00:07:57 -0000 --Apple-Mail=_FC29595F-0D44-429C-B6E3-C02FF4846D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those of you not on the ietf@ietf.org mailing = list and that planned to attend in-person, this is of interest. I will = also forward the ED follow up message about registration cancellations = and refunds. spt > Begin forwarded message: >=20 > From: The IESG > Subject: IETF 107 Vancouver In-Person Meeting Cancelled > Date: March 10, 2020 at 3:10:27 PM EDT > To: "IETF Announcement List" > Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org > Reply-To: iesg@ietf.org >=20 > The IESG and the IRTF Chair have decided to cancel the in-person IETF = 107 Vancouver meeting. This decision is based on input we gathered from = Working Group (WG) and Research Group (RG) chairs about our ability to = hold productive WG and RG sessions at IETF 107. Our assessment of this = feedback is that a majority of sessions would not be viable if we were = to hold the in-person IETF meeting. On this basis, we believe we cannot = hold an effective in-person meeting.=20 >=20 > As a result of this cancellation, the in-person Hackathon, Code = Sprint, all other in-person events planned for the weekend of March = 21-22, the chairs training scheduled for March 20, and all other = in-person sessions during the week are cancelled. >=20 > The IESG is working on an alternative all-virtual agenda for the week = of March 21-27 with a limited schedule adapted to accommodate the time = zones of as many participants as possible. We are also planning to = support an increased volume of virtual interim meetings during the weeks = that follow. We will send another update to the community soon with more = information about these plans. The Hackathon organizers are also = considering plans for virtual Hackathon support. >=20 > We have re-opened Internet-Draft submissions, which had been closed on = March 9 in anticipation of the in-person meeting. Internet-Drafts may be = submitted at . >=20 > A separate announcement from the IETF Executive Director will follow = with details about registration cancellations and refunds. =20 >=20 > These are unusual times given the circumstances created by the spread = of COVID-19. We hope that everyone remains safe and healthy. >=20 > Regards, > The IESG and the IRTF Chair >=20 --Apple-Mail=_FC29595F-0D44-429C-B6E3-C02FF4846D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii For = those of you not on the ietf@ietf.org mailing list and that planned to = attend in-person, this is of interest.  I will also forward the ED = follow up message about registration cancellations and = refunds.

spt

Begin forwarded message:

From: = The IESG <iesg@ietf.org>
Subject: = IETF 107 = Vancouver In-Person Meeting Cancelled
Date: = March 10, 2020 at 3:10:27 PM = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org
Reply-To: = iesg@ietf.org

The IESG and the IRTF Chair = have decided to cancel the in-person IETF 107 Vancouver meeting. This = decision is based on input we gathered from Working Group (WG) and = Research Group (RG) chairs about our ability to hold productive WG and = RG sessions at IETF 107. Our assessment of this feedback is that a = majority of sessions would not be viable if we were to hold the = in-person IETF meeting. On this basis, we believe we cannot hold an = effective in-person meeting.

As a result = of this cancellation, the in-person Hackathon, Code Sprint, all other = in-person events planned for the weekend of March 21-22, the chairs = training scheduled for March 20, and all other in-person sessions during = the week are cancelled.

The IESG is working = on an alternative all-virtual agenda for the week of March 21-27 with a = limited schedule adapted to accommodate the time zones of as many = participants as possible. We are also planning to support an increased = volume of virtual interim meetings during the weeks that follow. We will = send another update to the community soon with more information about = these plans. The Hackathon organizers are also considering plans for = virtual Hackathon support.

We have = re-opened Internet-Draft submissions, which had been closed on March 9 = in anticipation of the in-person meeting. Internet-Drafts may be = submitted at <https://datatracker.ietf.org/submit/>.
A separate announcement from the IETF Executive Director = will follow with details about registration cancellations and refunds. =  

These are unusual times given the = circumstances created by the spread of COVID-19.  We hope that = everyone remains safe and healthy.

Regards,
The IESG and the IRTF Chair


= --Apple-Mail=_FC29595F-0D44-429C-B6E3-C02FF4846D92-- From nobody Fri Mar 13 13:59:37 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE83A101E; Fri, 13 Mar 2020 13:59:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aamelnikov@fastmail.fm, wpack@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158413314813.3136.10101252111944290139@ietfa.amsl.com> Date: Fri, 13 Mar 2020 13:59:08 -0700 Archived-At: Subject: [Wpack] wpack - Requested session has been scheduled for IETF 107 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 20:59:21 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. wpack Session 1 (1:30 requested) Wednesday, 25 March 2020, Session I 2000-2130 Room Name: Virtual Track 1 size: None --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/wpack.ics Request Information: --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: tls mls quic Technology Overlap: acme saag secdispatch dispatch httpbis People who must be present: Sean Turner Alexey Melnikov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Mar 20 10:23:59 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6B93A0D22; Fri, 20 Mar 2020 10:23:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Agenda To: X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158472503623.13582.1589544381851901495@ietfa.amsl.com> Date: Fri, 20 Mar 2020 10:23:56 -0700 Archived-At: Subject: [Wpack] Virtual IETF 107 Meeting WebEx Invitation: WPACK X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:23:57 -0000 WPACK Session at IETF 107 Wednesday, March 25, 2020 20:00-21:30 UTC Join meeting: Meeting number (access code): 311 414 596 Meeting password: wnKifMHK249 IETF 107 Agenda: From nobody Fri Mar 20 17:18:53 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF473A0FB7 for ; Fri, 20 Mar 2020 17:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 ORsi95pgMSYA for ; Fri, 20 Mar 2020 17:18:49 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4613A0FB5 for ; Fri, 20 Mar 2020 17:18:49 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id z12so6689144qtq.5 for ; Fri, 20 Mar 2020 17:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=mRHjIh6A2WYtKzWwQLccb4OCPRLzOAc/8QBFL6qqLKA=; b=S0wO0C0vEM2OrsLqHanDPPx8w0QO0VGOFiVi/H4g8bPMcmY35ciB5hmQs7TwJls/84 EmZF+Ts9lJHV3OPFOMhMhKg3dV/yh2Z1ko+Sp/fdH55VnTQXFU89er3Y+wNgQ0JlU3jc q/EBQJxBr38S6kfuWedYooz0Sww2d+DoLPRmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=mRHjIh6A2WYtKzWwQLccb4OCPRLzOAc/8QBFL6qqLKA=; b=kjNlI+7uP1XQZZjUXPouX3FpkL8XEMiFf7QVUelz4I9QEmngskd8glWc5NQHwxqRZq zFr/KWcYXH4UNo1++ny7CzkZySBOlaQsjRGNk/zsrPAHo4o9sUgjC/+PpZvLMv/JLYfM Bg21ZYxH0BN8IxDpDdKKIn4n/H/65ALqV/MYBfOsiVlxLYXfEshsulwSgMAIszOhDXZ0 HFJlGh/uE+izGzmRz9V0K0XgoAAXSYHajEEoXhvuGcADnOguGT8S8+7j5lnv6TojeKV0 1FK7hre+BfIxc/a3aIadLbFvPPH8b99sdID8LojUstgmhtDFmc0xq+jWElYJP2VDmxUT onbQ== X-Gm-Message-State: ANhLgQ3G5rC85+iEJwxCEwGSRnbs3S85okl8jgzFWgGUPb4/YpgUL9Pv PYMhWz81bUmsZb6uTskYn6UX7/9LBuI= X-Google-Smtp-Source: ADFU+vteev5yzxRLvjQhVavFgDvr6rT2t/XB92g2OxElWgkrWPWPJvtEEDuYeLVNIvapkhG9itSbXQ== X-Received: by 2002:ac8:1762:: with SMTP id u31mr11419456qtk.359.1584749928491; Fri, 20 Mar 2020 17:18:48 -0700 (PDT) Received: from [172.17.8.33] ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x5sm5942645qti.5.2020.03.20.17.18.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 17:18:47 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_8884DCEC-6874-43F4-97BF-FF33F69C57E8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: <39C5C273-3BA7-413C-9A0F-FE89AF78698B@sn3rd.com> Date: Fri, 20 Mar 2020 20:18:45 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Wpack] WPACK@vIETF107: Agenda X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:18:52 -0000 --Apple-Mail=_8884DCEC-6874-43F4-97BF-FF33F69C57E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi WPACK, Our virtual meeting is scheduled for Wednesday, 25 March 2020 from = 2000-2130 UTC. The webex details can be found on this page: = https://datatracker.ietf.org/meeting/agenda/ = The proposed agenda is as follows (times TBD): - Administrivia - chairs - Use Cases - chairs - Bundle - Jeffrey - Security Option 1: Digital Signature - Jeffrey - Security Option 2: - Martin - Comparison 1 & 2 - Jeffrey/Martin Cheers, Dave and Sean= --Apple-Mail=_8884DCEC-6874-43F4-97BF-FF33F69C57E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
hi = WPACK,

Our virtual meeting is scheduled for = Wednesday, 25 March 2020 from 2000-2130 UTC. The webex details can be = found on this page: https://datatracker.ietf.org/meeting/agenda/

The proposed agenda is as follows (times = TBD):

- Administrivia - chairs
- Use Cases - chairs
- Bundle - Jeffrey
- Security Option 1: Digital Signature - Jeffrey
- Security Option 2:  - Martin
- = Comparison 1 & 2 - Jeffrey/Martin

Cheers,
Dave and Sean
= --Apple-Mail=_8884DCEC-6874-43F4-97BF-FF33F69C57E8-- From nobody Fri Mar 20 17:18:58 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310133A0FB8 for ; Fri, 20 Mar 2020 17:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 G9VdYPh6B-7X for ; Fri, 20 Mar 2020 17:18:52 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C11E3A0FB5 for ; Fri, 20 Mar 2020 17:18:52 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id v15so6705720qto.2 for ; Fri, 20 Mar 2020 17:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=szoVqK2P5bXb/L4XrKC+cLSMMAZQd5s7jrBZ1Wydy1I=; b=Zp14oHNxqcTyxkYtb9IklpC852pa8FXRt7ZpuoJv6oshe35720OZEhos2EyGJREXI4 EsfKg2ozcFdK4Zfd1qT3loIICULZyKs+woBR0KjA/GteOWYwkzRGn06w651HqhZVZ/oS I5rDjgUQSueq6Y9HCQD4ZSe/9XttqJ36SyjPQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=szoVqK2P5bXb/L4XrKC+cLSMMAZQd5s7jrBZ1Wydy1I=; b=pnrFF4DkRAPlwZZu6T+UdijSZbOQvwEWEsW5TnhWJjzK4PC4/A9VeiIkfb13LCOUZc /9SXsc1tohYUU0V3QCw/VhRNz4FniXaoSoMkP6mZx3IE9FyUZd/xhyWNQvlfaoJVh3c6 wFQLGLUloZNEIkE2E3UTiarcdDyVPhdulZaj6gTSzWuYI8nN+39PsgW6JHq2Fi3su9fe ZCFta586JYupG2wODIXCqAD9VWxhTYnIdZRihTG4Mv4c8tJF2BZI0yI+Eo0rVnI3bU9n i7Py3HqNosXByBPOORzKXqcfk9q/qmcXId3Bua7vqzOxmeCKK3ggGYegeA9XIpmsCA94 pIdg== X-Gm-Message-State: ANhLgQ3yUe/sckxAwgFmnXu+ZlvMLV2OJ7VoOtwlyQdH2RpP9E6Ze8nG B+PupeuJTcUJbbtlu1w63Cnq+/6ZUOI= X-Google-Smtp-Source: ADFU+vsNJgsbtgTfz8puU1NBUVB6oowxKoyymwoMWwgcKijZWhRyN1loaT577gSXyYdZqbqO7PfgZQ== X-Received: by 2002:ac8:749a:: with SMTP id v26mr10925095qtq.260.1584749930961; Fri, 20 Mar 2020 17:18:50 -0700 (PDT) Received: from [172.17.8.33] ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x5sm5942645qti.5.2020.03.20.17.18.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 17:18:50 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_7C40B140-4100-4CEC-9041-DD58AB09B5CB" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: <0D645838-D52A-4130-A81D-5FAFFCE313B5@sn3rd.com> Date: Fri, 20 Mar 2020 20:18:47 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Wpack] WPACK@vIETF107: Minute Taker X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:18:54 -0000 --Apple-Mail=_7C40B140-4100-4CEC-9041-DD58AB09B5CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi WPACK, The chairs are looking for minute take for our session next week. Please = let us know at wpack-chairs@ietf.org if = you would be willing to volunteer. Thanks, Dave and Sean= --Apple-Mail=_7C40B140-4100-4CEC-9041-DD58AB09B5CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hi WPACK,

The chairs are looking for minute take for our session next = week. Please let us know at wpack-chairs@ietf.org if you would be = willing to volunteer.

Thanks,
Dave and Sean= --Apple-Mail=_7C40B140-4100-4CEC-9041-DD58AB09B5CB-- From nobody Mon Mar 23 08:54:59 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D823A09AC for ; Mon, 23 Mar 2020 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8bruMqlHv-dJ for ; Mon, 23 Mar 2020 08:54:51 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FDF3A09E3 for ; Mon, 23 Mar 2020 08:54:46 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id l23so3783916otf.3 for ; Mon, 23 Mar 2020 08:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sYTC7hpyy9/755LgOvfYAYxy35yVe/pYi2/rjL+Y1EM=; b=L1nSzT3pR4O1ZIU8/gt6iFiPI2CxAXoTwR+E9asHxyFylFQ/5+ol6PqZA4If4wkn4N qxSUwCz7u3iRE5BGD+D3HYienl20kMF88YPkv8/fFYfkAkp4zDAb+qyg/YKHTMgQCJmT +N4sGkBgHUb6dHGf4GtgEGIIoO/qxRf1T9/LsThchxrdzi3SZ4OxpMTKIeYWCTMJufsN ihPU3QtXBKPxj+bdGajXH4R5NhKDHszbTE6RW6USQUY6luYflu9W1DCC+K4Ptk7fJjv6 CwpJvFfbbXFk8wMxG4I+kOFAfI8JVzi2FaDugcq+Hdojdwm8iKY0RLiyZfqNpxQHr1Uu oCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sYTC7hpyy9/755LgOvfYAYxy35yVe/pYi2/rjL+Y1EM=; b=iJ7tULoU92rlJ/Uh4HNA9tRwyVvLyx/iKzFD6JEjeCwtKnziuaBGSlzLaVH/DU6LCt vEGvwiyUrRzMmigCPKpSISzEu2RzpmuqIyHT/IVY4yyrEbTsrH3pqu+bQhaZBU5OR4+p 66zO67Ysv8+aCLPqD14w7EiG3UjZINuncTvWdSnErwuaVVDLJ7CzsMeGSaZynNsLgqJ6 cRQpC3IlvMngRtoDYt3o91GcleXCOVHY30Se+08hbP/SEUa/eCYTz50K0DCfcJvPodXT hB0WMH40jF3O1v8cU+wPXS+UdKInjzoz6DlwNzm7alcIRIrSacLEnICZ4HcDQaFFcHbh ti2A== X-Gm-Message-State: ANhLgQ3M8PXHGpl8KxW7AmCzYBdBxayBye+n8MYMMa1pIXP0OUezdidV CAOth8k477wv4U8c8N/fzkRAuLqZJEg7pIGjaBxO/ZtC X-Google-Smtp-Source: ADFU+vs5BlkEVpPzrDak/xtpqdIRtJuUIw+C5PT3Vpia4FJLbq711ONgAN5OA5H31+4+pLR/LU4Evtok+i7MCTx9oZM= X-Received: by 2002:a4a:4505:: with SMTP id y5mr579259ooa.29.1584978884535; Mon, 23 Mar 2020 08:54:44 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Mon, 23 Mar 2020 08:54:19 -0700 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000063ae2605a187a7ef" Archived-At: Subject: [Wpack] https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 15:54:58 -0000 --00000000000063ae2605a187a7ef Content-Type: text/plain; charset="UTF-8" Howdy, Reading Sean's note about the agenda, I wondered if Martin's proposal had a draft--turns out it does, https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00. If that got sent to this list, I somehow missed it. I'm doing a quick review now, and there is much to dig into. But I think it's important to start with one point Martin makes early on: The web relies on the concept of origins [ORIGIN ] as the primary means of identification for resources. A strongly authenticated HTTPS origin is the basis for many security decisions. However, establishing this identity relies on having an active TLS [TLS ] connection to a server that is considered authoritative for the origin; see Section 11 of [HTTP ]. As RFC 6454 points out, the Origin concept is focused on scope of authority and privilege, primarily in the context of the same-origin policy. The Web's view of *identification of resources*, rather than privilege, is considerably more complex. If you go back to the Dublin Core work described in RFC 2413 (and its many successors1), you'll see that the idea of resource identifiers associated with web retrieval and indexing goes back a long way. Some of those ideas, like the inclusion of URNs in metadata tags so that you could identify a resource independently from where it was received, were tried out during experiments in content distribution as long ago as 1995. NASA's web indexers (based on the Harvest system) did that, for example.2 I make this point not to dwell on the past but to call out that this working group has to be very careful to distinguish between the ideas of scope of privilege and other aspects of resource identification and attribution. Methods for resource identification outside of association with the channel of retrieval are not new, and some sense of that context, especially the drawbacks of previous systems, is probably useful. regards, Ted 1) Dublin core is now maintained by DCMI ( https://dublincore.org/specifications/dublin-core/) 2) CIP and friends (RFC 2651 and 2655) emerged out of that set of experiments and exchanges. --00000000000063ae2605a187a7ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Reading Sean's note about th= e agenda, I wondered if Martin's proposal had a draft--turns out it doe= s,=C2=A0https://tools.ietf.org/html/draft-thomson-wpack-content-origin-0= 0.=C2=A0 If that got sent to this list, I somehow missed it.=C2=A0=C2= =A0

I'm doing a quick review now, and there is= much to dig into.=C2=A0 But I think it's important to start with one p= oint Martin makes early on:

   The web relies on the concept of origins [=
ORIGIN] as t=
he primary
   means of identification for resources.  A strongly authenticated
   HTTPS origin is the basis for many security decisions.  However,
   establishing this identity relies on having an active TLS [TLS]
   connection to a server that is considered authoritative for the
   origin; see Section 11 of [HTTP].

As RFC 6454 points out, the Origin concept = is focused on scope of authority and privilege, primarily in the context of= the same-origin policy.=C2=A0 The Web's view of identification of r= esources, rather than privilege, is considerably more complex.=C2=A0 If= you go back to the Dublin Core work described in RFC 2413 (and its many su= ccessors1), you'll see that the idea of resource identifiers associated= with web retrieval and indexing goes back a long way.=C2=A0 Some of those = ideas, like the inclusion of URNs in metadata tags so that you could identi= fy a resource independently from where it was received, were tried out duri= ng experiments in content distribution as long ago as 1995. NASA's web = indexers (based on the Harvest system) did that, for example.2=C2=A0=C2=A0<= br>

I make this point not to dwell on the past but= to call out that this working group has to be very careful to distinguish = between the ideas of scope of privilege and other aspects of resource ident= ification and attribution.=C2=A0 Methods for resource identification outsid= e of association with the channel of retrieval are not new, and some sense = of that context, especially the drawbacks of previous systems, is probably = useful.=C2=A0=C2=A0

regards,

<= div>Ted

1) Dublin=C2=A0core is now maintained by D= CMI (https:/= /dublincore.org/specifications/dublin-core/)
2)=C2=A0 CIP and= friends (RFC 2651 and 2655) emerged out of that set of experiments and exc= hanges.
--00000000000063ae2605a187a7ef-- From nobody Mon Mar 23 17:34:51 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA69E3A0EA1 for ; Mon, 23 Mar 2020 17:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=T7n1iZhC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qWpAo2qp 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 Dtc9756HEs1I for ; Mon, 23 Mar 2020 17:34:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED343A0EAE for ; Mon, 23 Mar 2020 17:34:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6AFC05C0102 for ; Mon, 23 Mar 2020 20:34:43 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 23 Mar 2020 20:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=+vuDEX5VMQNmeiqwiWgiXQLD8z/u63LPUCx1z3li9IE=; b=T7n1iZhC YX+7yuJKIuwcnzno7HqEyZol8VaXD9aY8no1+/VVdot0reuLX3MeJS3bgjWhh1J5 jIInAw9JnI1Oa3467DaFKRtckdM5U39QGAdDuf2BF85agAFCjn0vKlNOkcS0chCh 6N+sjlTFLImU+NbGuzjWn1nhkcutaPM/trgi70qXCn3beycykspoU8LITY7Dl22X zh3HKbOv6o8dYIV2i5hzx6Kiy8sP2vxcFZeQWa21Cetwd8Xayhy8RfHPPq6Cj8ZI hbJN8OOJ78uZ9pLKoHAfBN0W5nD4jDdE7sLaOYkmdSJ/EgSZSmjfgZsVtaVqfpBI HXwWfPBGWuyxDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=+vuDEX5VMQNmeiqwiWgiXQLD8z/u6 3LPUCx1z3li9IE=; b=qWpAo2qpL2pGW4xGgmXuNcSz4ZAtM5NH3+O/pTui9pbu9 uGlvmkRwK0w1eBC2v96tsl6/9hxQH8QdpdLFSpfRitUhBCQ9xrbPemCv24Q1wVy+ P/qgD9b7IroEd7ELeSLvXM4BIzl3c2OiaZBwE3s/PSoG1VU7HKZZBKOwz9GeqtIi LmASYPfaIpEOZz2qcCpcWKoi8dnSSNbxomHWLfHgS8dvxNLEDjFiMR5VVMWOmb14 L4BCbJhEwoKTwMSQ8OyVmLZz+r2Ww4GoR3Ja7J+tcQ0SMrCvVpaZPyfelTSpaYwp VQiKiVBWFE8jMOEIGUJXj/ty0yY8gMu7Py8OLEC3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegledgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhi nhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomh grihhnpehivghtfhdrohhrghdpghhithhhuhgsrdhiohenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E7634E00C9; Mon, 23 Mar 2020 20:34:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> Date: Tue, 24 Mar 2020 11:34:19 +1100 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 00:34:49 -0000 Ted's note prompted me to send a much-belated announcement (sorry folks, I forgot). The draft is here: https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 A nicer version here: https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html This approach could a dramatically different approach to addressing the use cases set out in our charter. In short, this aims to address the core question of how offline content might *ultimately* be attributed to a web origin in a fundamentally different way. There are two key concepts: 1. Content is given its own origin, using a new system for identification. 2. A target origin can "accept" content and state from one of these new origins. There are a lot of details here (read the draft), but the major advantage I see is that you don't have to make an offline decision about authority, and that means you can be offline for much longer (lifting the 7 day limit). What it does have in common with signed exchanges approach is the need for a bundling format, but in its current form it is less dependent on the details of the format. That might allow that to be simpler, but I'm sure that the need to mint new identifier types will more than make up for any slack there. The draft is quite rough. I'm sure that it has the remnants of a few bad ideas still hanging around. Ask questions if you think something is unclear. From nobody Tue Mar 24 07:11:08 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8963A07FF; Tue, 24 Mar 2020 07:10:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.122.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , wpack@ietf.org, wpack-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158505905796.11494.12913263878676601420@ietfa.amsl.com> Date: Tue, 24 Mar 2020 07:10:57 -0700 Archived-At: Subject: [Wpack] WG Action: Formed Web Packaging (wpack) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 14:10:59 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. Web Packaging (wpack) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Sean Turner David Lawrence Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: wpack@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wpack Archive: https://mailarchive.ietf.org/arch/browse/wpack/ Group page: https://datatracker.ietf.org/group/wpack/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wpack/ The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP representations. It will also specify a way for the publisher to authenticate these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: * Efficient (binary) storage across a range of resource combinations. Three use cases to be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and a selection of the whole web for peer-to-peer distribution in a country when access to authoritative servers is unavailable. * The ability to create a snapshot of a web page without the cooperation of its publisher. * The ability to receive a web package from an entity other than the origin server and have continuity of experience and state (especially that created by active content such as JavaScript) between the offline and online versions. * When a bundle is streamed, the client must be able to start using a subresource before the entire bundle is downloaded, and for large subresources, before the entire subresource is downloaded. * When a bundle is loaded from random-access storage, the client must be able to use a subresource without necessarily reading the entire prefix of the bundle before that subresource. * When a bundle is authenticated, the client must be able to validate the authentication without extra requests over the network. * Being extensible and crypto agile. * Security and privacy properties of using authenticated bundles as close as practical to TLS 1.3 transport of the same resources. Where properties do change, the group will document exactly what changed and how affected people, including content publishers and users, can compensate. Part of this is analyzing how the shift from transport security to object security changes the security properties of the web's existing features. * Specifying constraints on how clients load the formats without describing specific loading algorithm to help achieve the above goals. The packaging format will also aim to achieve the following secondary goals as long as they don't compromise or delay the above properties. * Optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs. * Address the threat model of a website's frontend compromised after a user first uses the site. * Support books being published in the format: support for bundles that have no expiration date; ability to reference a resource withing a bundle (e.g. chapter) * Optimize storage of large numbers of small same-origin resources (e.g. using compression) * Allow publishers to efficiently combine sub-packages from other publishers. The following goals are out of scope under this charter: * DRM (Digital Rights Management) * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute a messaging application but wouldn't define a way to distribute individual messages without a direct connection to the messaging application's origin server. * A way to automatically discover the URL for an accessible (retrievable) package that includes specific content. Note that consensus is required both for changes to the initially proposed protocol mechanisms and for their retention. In particular, because something is in an initial working group draft does not imply that there is consensus around the feature or around how it is specified. Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing. Milestones: Jun 2020 - Working group adoption of use cases document (will not be published as an RFC) Jun 2020 - Working group adoption of bundling document Jun 2020 - Working group adoption of security analysis document Jun 2020 - Working group adoption of privacy analysis document Jun 2020 - Working group adoption of one or more signing document Sep 2021 - Submit the Bundling document to IESG Mar 2022 - Submit the Privacy analysis document to IESG Mar 2022 - Submit the Security analysis document to IESG Mar 2022 - Submit Signing document (this might just reference HTTPBIS work) to IESG From nobody Tue Mar 24 10:48:11 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D85E3A09AE for ; Tue, 24 Mar 2020 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.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 m9RapdWfQ75t for ; Tue, 24 Mar 2020 10:48:08 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD623A0915 for ; Tue, 24 Mar 2020 10:48:07 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id j16so17912723otl.1 for ; Tue, 24 Mar 2020 10:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yBMAaQOHzVPv8SpeD2e+E4EQ03zWqkJm6fRwExYJ1RA=; b=LkpwqAsoQqtKForsKVhORhIT/l4tTRC0z9zNhjsEwi02VFboNABODN0LlmjCiOhwLy uugt5OiMpo2SE1uma8tChYbOitb39MjTWnie4n6UN0I6QB7A6sskKT2IsbhceQn0rc3W +9HL/aXK6rBEyzBx7++Lc6vVHUv4bt8b92I9B0V+Rj5DFMWmZKBe2VvW2O6G0ipIEHcR 4hHJa0NVOWZcq2xnFxYD4mU1F9bowYR824FhkS3jGqQ3ICmKuPn+M7NTvYAVHeD3nPGb zKHGhjNxnjVsjk5UwB9WkI7gj9XGpVYRui51ISaWLc8JYmUJUZGYuBMCXYKWtfMuVOcK S63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yBMAaQOHzVPv8SpeD2e+E4EQ03zWqkJm6fRwExYJ1RA=; b=BnETH7Sh1v3xplK3YY0V3qVYRqEVhO5N8Hzu7M3/QoEcwMmwr903or0zBiXNKwoZHg wpAYqWFb0Dz+p5nWL5CY1EUKfId8O6c62WdU3Mon14vnc/UJMI4+mkksxGBMQCF2ux7a UYDm+oAUqPLeA0MGIafeEruAoSSye5xV5mNewcS9HXFO9aFzvbYXtC5DClvsGG+szPlm 3vu5Kf7ZKtNufCGtoxfDFc1hVyU0w8dB8wSIMDQqCmpwWsysjVyxt2NLOJ8R1VGDDpBn HCki3V7H6Ag//qO5m8RhJKrjiscLl5IQguN8I0T32asSfZk9e7prIwN3jsTub666Sxq0 26Nw== X-Gm-Message-State: ANhLgQ37RGjbenfEhKV2XXLTnoRDKRhs2DVLi7tIIc+ERfadkNM5Z1Am z4BVdIPHi73vg/R9YtM5GpWuLzg15J/W9FW7IFhedg== X-Google-Smtp-Source: ADFU+vvyExpVMu10aTIH3OoCCgK96dA8RWp5abOLn/qTAEBtcfJw8IFeB5vFWx+bY8FeoBOzY0XIfCNrJTXvtz7GDV0= X-Received: by 2002:a9d:7397:: with SMTP id j23mr12549964otk.269.1585072086912; Tue, 24 Mar 2020 10:48:06 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> From: Ted Hardie Date: Tue, 24 Mar 2020 10:47:34 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000af13de05a19d5aaa" Archived-At: Subject: Re: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 17:48:11 -0000 --000000000000af13de05a19d5aaa Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for your note. A question in-line. On Mon, Mar 23, 2020 at 5:34 PM Martin Thomson wrote: > Ted's note prompted me to send a much-belated announcement (sorry folks, I > forgot). > > The draft is here: > https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 > > A nicer version here: > > https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html > > This approach could a dramatically different approach to addressing the > use cases set out in our charter. > > In short, this aims to address the core question of how offline content > might *ultimately* be attributed to a web origin in a fundamentally > different way. There are two key concepts: > > 1. Content is given its own origin, using a new system for identification. > > 2. A target origin can "accept" content and state from one of these new > origins. > > I note that you did not include "hashing is a key element of identification" in the key concepts here, despite it being pretty prominent in the draft. Is it something you consider fundamental here, or is it an approach to demonstrate a method of achieving the two desiderata above? > There are a lot of details here (read the draft), but the major advantage > I see is that you don't have to make an offline decision about authority, > and that means you can be offline for much longer (lifting the 7 day limit). > > I would personally describe this as a trade-off, rather than an advantage. The inability to make an offline decision about authority has consequences for how different resources available to the client relate to each other (e.g some come from a bundle and some from a cache). To take an unfortunately pressing example, let's assume a local authority has provided a set of resources to local residents. A new item is created and distributed. For those getting it via direct connection to the local authority's server, the new item can be related to the other items. With a signed exchange and a signature verification, those receiving it peer-to-peer can as well. In a content-origin approach, my understanding is that the new item could be received and displayed, but the ability to integrate it with the rest of set is not active until the client can go online and confirm with the local authority's serve that it verifies that "ni:hashmumble" is the target. The problem here for an offline client is pretty serious, as it cannot determine whether the new resource is from the local health authority or not. If it updates information like a set of symptoms or treatments, the consequences are large. Have I missed something here? If I have not, then this approach makes a trade-off that limits its utility in ways that make peer-to-peer usage of the approach problematic for use cases I personally care about it. Others, of course, may make other assessments of that trade-off. regards, Ted > What it does have in common with signed exchanges approach is the need for > a bundling format, but in its current form it is less dependent on the > details of the format. That might allow that to be simpler, but I'm sure > that the need to mint new identifier types will more than make up for any > slack there. > > The draft is quite rough. I'm sure that it has the remnants of a few bad > ideas still hanging around. Ask questions if you think something is > unclear. > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --000000000000af13de05a19d5aaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for = your note.=C2=A0 A question in-line.

On Mon, Mar 23, 2020 at 5:34 PM M= artin Thomson <mt@lowentropy.net> wrote:
Ted= 's note prompted me to send a much-belated announcement (sorry folks, I= forgot).

The draft is here:
https://tools.ietf.org/html/draft-t= homson-wpack-content-origin-00

A nicer version here:
https://martint= homson.github.io/wpack-content/draft-thomson-wpack-content-origin.html<= br>
This approach could a dramatically different approach to addressing the use= cases set out in our charter.

In short, this aims to address the core question of how offline content mig= ht *ultimately* be attributed to a web origin in a fundamentally different = way.=C2=A0 There are two key concepts:

1. Content is given its own origin, using a new system for identification.<= br>
2. A target origin can "accept" content and state from one of the= se new origins.


I note that you did not include "= hashing is a key element of identification" in the key concepts here, = despite it being pretty prominent in the draft.=C2=A0 Is it something you c= onsider fundamental here, or is it an approach to demonstrate a method of a= chieving the two desiderata above?

=C2=A0
There are a lot of details here (read the draft), but the major advantage I= see is that you don't have to make an offline decision about authority= , and that means you can be offline for much longer (lifting the 7 day limi= t).

I would personally describe this as a trade-off, rath= er than an advantage.=C2=A0 The inability to make an offline decision about= authority has consequences for how different resources available to the cl= ient relate to each other (e.g some come from a bundle and some from a cach= e).=C2=A0 To take an unfortunately pressing example, let's assume a loc= al authority has provided a set of resources to local residents.=C2=A0 A ne= w item is created and distributed.=C2=A0 For those getting it via direct co= nnection to the local authority's server, the new item can be related t= o the other items.=C2=A0 With a signed exchange and a signature verificatio= n, those receiving it peer-to-peer can as well.=C2=A0 In a content-origin a= pproach, my understanding is that the new item could be received and displa= yed, but the ability to integrate it with the rest of set is not active unt= il the client can go online and confirm with the local authority's serv= e that it verifies that "ni:hashmumble" is the target.=C2=A0 =C2= =A0The problem here for an offline client is pretty serious, as it cannot d= etermine whether the new resource is from the local health authority or not= .=C2=A0 If it updates information=C2=A0like a set of symptoms or treatments= , the consequences are large.=C2=A0=C2=A0

Have I m= issed something here?=C2=A0 If I have not, then this approach makes a trade= -off that limits its utility in ways that make peer-to-peer usage of the ap= proach problematic for use cases I personally care about it.=C2=A0 Others, = of course, may make other assessments of that trade-off.

regards,

Ted


<= /div>
=C2=A0
What it does have in common with signed exchanges approach is the need for = a bundling format, but in its current form it is less dependent on the deta= ils of the format.=C2=A0 That might allow that to be simpler, but I'm s= ure that the need to mint new identifier types will more than make up for a= ny slack there.

The draft is quite rough.=C2=A0 I'm sure that it has the remnants of a = few bad ideas still hanging around.=C2=A0 Ask questions if you think someth= ing is unclear.

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--000000000000af13de05a19d5aaa-- From nobody Tue Mar 24 13:03:59 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA03A0C61 for ; Tue, 24 Mar 2020 13:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cCIU3QzGSwb3 for ; Tue, 24 Mar 2020 13:03:55 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3AE3A0BAE for ; Tue, 24 Mar 2020 13:03:54 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id s1so46488wrv.5 for ; Tue, 24 Mar 2020 13:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K5W3bfiuxNdQ/5UCICCFuJ1zBDEoUcLJd0YgijwLtiQ=; b=kXEHwZJfK9q1Thtr4gIwRzdUl+v+B1LYtS1tJ0/EmONDB+3p9GIFLxIQVoaFZrmNs4 VDZuVujOj1xeQ0bOdcTfLf5IGaN5VBPO3NhDALxK6qXZoPBRjvTdsctxoyI9yXbkEZ52 j6+kHAxUDRmsu7AedUuKnb3ZAxgHsJZa+rh9Z5b0/j+JB0K4pyUBljhBZm3fk0HHBX5H b2zT9VjQ1tL4h3nhi3d0uZmxjvA2XrMTBfWIUpe1sEb3qRHFBVkt09H4zPtzdDK/uDru O/FJxnQQgSOGqyjBYXOR5sU6WJpmIefGtjMKPbid6hxk2Dxzka4NTxEjTbS9Ed5shORU BUcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K5W3bfiuxNdQ/5UCICCFuJ1zBDEoUcLJd0YgijwLtiQ=; b=FZT68fTutTtWXtY5t6eAEL8ViGw5pllzx53P9MsVOdqeghIiZlEsipqNZReCSG4TlK ZUzbuJdyyWD9JwndrDysj86WUlp56Wj8BAcgoSd1Yp0rYGHKis4ywxhLCUJKmMgFl0pJ 095LZQjBKqOJBMjTV41hHvg4Qxa/dVcRFh7aHDpng+q7hrCUnSZI8XP5rk+/vPP4DbVd VKJmKltAjXx04kBDbRm6Qp04P78WevsMRhTN/HAGJoMD/OrIlmIbt6dbVtHQXOgSvMu8 CRGZTCPf0hQ0cnTGCo/iOFUVBdJrgTHt4d+WhYfB7vSGCsjrcn01kvE1sBmRwx/legLV uKew== X-Gm-Message-State: ANhLgQ1+TiLLUFWHUTrbQ0kBPP5LbgQmOVYbdzJ6fc8dowIvjU/odt1A Hj8bPGe+fJSdjFFw0NAjllKgD6jW1PdSxmSQN1jRwlWO X-Google-Smtp-Source: ADFU+vtfta/WQAJQP9gFgz8gXyu15t8TEsa7lRD8lrVxqrRA9LcwrycSGywHY5RMrI8JvH4IOWgamGqnRs+uUEFKSF8= X-Received: by 2002:adf:804e:: with SMTP id 72mr23707982wrk.258.1585080232585; Tue, 24 Mar 2020 13:03:52 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Ben Schwartz Date: Tue, 24 Mar 2020 16:03:41 -0400 Message-ID: To: Ted Hardie Cc: Martin Thomson , wpack@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003f004205a19f4000" Archived-At: Subject: Re: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 20:03:58 -0000 --0000000000003f004205a19f4000 Content-Type: multipart/alternative; boundary="00000000000034e21805a19f40af" --00000000000034e21805a19f40af Content-Type: text/plain; charset="UTF-8" For a lighter example: if I'm distributing updates to a single-player videogame, does the client have to get online and ping the server before the game can access my local saved state? (I can think of ways to avoid this while preserving the origin separation, by forking the local state and blocking network access, but it seems complicated.) On Tue, Mar 24, 2020 at 1:48 PM Ted Hardie wrote: > Hi Martin, > > Thanks for your note. A question in-line. > > On Mon, Mar 23, 2020 at 5:34 PM Martin Thomson wrote: > >> Ted's note prompted me to send a much-belated announcement (sorry folks, >> I forgot). >> >> The draft is here: >> https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 >> >> A nicer version here: >> >> https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html >> >> This approach could a dramatically different approach to addressing the >> use cases set out in our charter. >> >> In short, this aims to address the core question of how offline content >> might *ultimately* be attributed to a web origin in a fundamentally >> different way. There are two key concepts: >> >> 1. Content is given its own origin, using a new system for identification. >> >> 2. A target origin can "accept" content and state from one of these new >> origins. >> >> > I note that you did not include "hashing is a key element of > identification" in the key concepts here, despite it being pretty prominent > in the draft. Is it something you consider fundamental here, or is it an > approach to demonstrate a method of achieving the two desiderata above? > > > >> There are a lot of details here (read the draft), but the major advantage >> I see is that you don't have to make an offline decision about authority, >> and that means you can be offline for much longer (lifting the 7 day limit). >> >> I would personally describe this as a trade-off, rather than an > advantage. The inability to make an offline decision about authority has > consequences for how different resources available to the client relate to > each other (e.g some come from a bundle and some from a cache). To take an > unfortunately pressing example, let's assume a local authority has provided > a set of resources to local residents. A new item is created and > distributed. For those getting it via direct connection to the local > authority's server, the new item can be related to the other items. With a > signed exchange and a signature verification, those receiving it > peer-to-peer can as well. In a content-origin approach, my understanding > is that the new item could be received and displayed, but the ability to > integrate it with the rest of set is not active until the client can go > online and confirm with the local authority's serve that it verifies that > "ni:hashmumble" is the target. The problem here for an offline client is > pretty serious, as it cannot determine whether the new resource is from the > local health authority or not.. If it updates information like a set of > symptoms or treatments, the consequences are large. > > Have I missed something here? If I have not, then this approach makes a > trade-off that limits its utility in ways that make peer-to-peer usage of > the approach problematic for use cases I personally care about it. Others, > of course, may make other assessments of that trade-off. > > regards, > > Ted > > > > >> What it does have in common with signed exchanges approach is the need >> for a bundling format, but in its current form it is less dependent on the >> details of the format. That might allow that to be simpler, but I'm sure >> that the need to mint new identifier types will more than make up for any >> slack there. >> >> The draft is quite rough. I'm sure that it has the remnants of a few bad >> ideas still hanging around. Ask questions if you think something is >> unclear. >> >> _______________________________________________ >> Wpack mailing list >> Wpack@ietf.org >> https://www.ietf.org/mailman/listinfo/wpack >> > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000034e21805a19f40af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For a lighter example: if I'm distributing updates to = a single-player videogame, does the client have to get online and ping the = server before the game can access my local saved state?

= (I can think of ways to avoid this while preserving the origin separation, = by forking the local state and blocking network access, but it seems compli= cated.)

On Tue, Mar 24, 2020 at 1:48 PM Ted Hardie <ted.ietf@gmail.com> wrote:
= Hi Martin,

Thanks for your note.=C2=A0 A question in-lin= e.

On Mon, Mar 23, 2020 at 5:34 PM Martin Thomson <mt@lowentropy.net> wrote:
=
Ted's note prom= pted me to send a much-belated announcement (sorry folks, I forgot).

The draft is here:
https://tools.ietf.org/html/draft-t= homson-wpack-content-origin-00

A nicer version here:
https://martint= homson.github.io/wpack-content/draft-thomson-wpack-content-origin.html<= br>
This approach could a dramatically different approach to addressing the use= cases set out in our charter.

In short, this aims to address the core question of how offline content mig= ht *ultimately* be attributed to a web origin in a fundamentally different = way.=C2=A0 There are two key concepts:

1. Content is given its own origin, using a new system for identification.<= br>
2. A target origin can "accept" content and state from one of the= se new origins.


I note that you did not include "= hashing is a key element of identification" in the key concepts here, = despite it being pretty prominent in the draft.=C2=A0 Is it something you c= onsider fundamental here, or is it an approach to demonstrate a method of a= chieving the two desiderata above?

=C2=A0
There are a lot of details here (read the draft), but the major advantage I= see is that you don't have to make an offline decision about authority= , and that means you can be offline for much longer (lifting the 7 day limi= t).

I would personally describe this as a trade-off, rath= er than an advantage.=C2=A0 The inability to make an offline decision about= authority has consequences for how different resources available to the cl= ient relate to each other (e.g some come from a bundle and some from a cach= e).=C2=A0 To take an unfortunately pressing example, let's assume a loc= al authority has provided a set of resources to local residents.=C2=A0 A ne= w item is created and distributed.=C2=A0 For those getting it via direct co= nnection to the local authority's server, the new item can be related t= o the other items.=C2=A0 With a signed exchange and a signature verificatio= n, those receiving it peer-to-peer can as well.=C2=A0 In a content-origin a= pproach, my understanding is that the new item could be received and displa= yed, but the ability to integrate it with the rest of set is not active unt= il the client can go online and confirm with the local authority's serv= e that it verifies that "ni:hashmumble" is the target.=C2=A0 =C2= =A0The problem here for an offline client is pretty serious, as it cannot d= etermine whether the new resource is from the local health authority or not= ..=C2=A0 If it updates information=C2=A0like a set of symptoms or treatment= s, the consequences are large.=C2=A0=C2=A0

Have I = missed something here?=C2=A0 If I have not, then this approach makes a trad= e-off that limits its utility in ways that make peer-to-peer usage of the a= pproach problematic for use cases I personally care about it.=C2=A0 Others,= of course, may make other assessments of that trade-off.

regards,

Ted


=
=C2=A0
What it does have in common with signed exchanges approach is the need for = a bundling format, but in its current form it is less dependent on the deta= ils of the format.=C2=A0 That might allow that to be simpler, but I'm s= ure that the need to mint new identifier types will more than make up for a= ny slack there.

The draft is quite rough.=C2=A0 I'm sure that it has the remnants of a = few bad ideas still hanging around.=C2=A0 Ask questions if you think someth= ing is unclear.

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000034e21805a19f40af-- --0000000000003f004205a19f4000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCAl7S/j6Z9a+448Ad60IZ6th5q0MGMMwXYnjiN87sfTXDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjQyMDAzNTNaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAmduKYUqLT4H1AcNE0VBouk3LDqKYAP3/mZLM45Vk+D5CMk3v7s+xGaDnW9gwLpR2dAK+lcJF Q54yxwX0YyxVNRfqrvcA7Wx8fxqMLWypg9WPN3TZmLcR2exW7h2T9iCzgg076dkrHqEhReV02xXk YauEvT5d8alNxaT3ljcdMgOs2JqLlnCoMVZJeABXJIFs+QoUFd4ZnUvX+dK3zkO6BeOeSd2aJ1mi LWuSiVbwdlDTRCZIJS/RMYqmepH3FoN9jye5LiXY3T3D9JJ91sgLfyR+60WFifl7r76hAD5kbFqt xQJ4m+/l8NW7+rkBN1C0Kj3tXFPuaoltGdAq4ipyaA== --0000000000003f004205a19f4000-- From nobody Tue Mar 24 18:58:52 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF053A086F for ; Tue, 24 Mar 2020 18:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 wwgmqEJXAYmx for ; Tue, 24 Mar 2020 18:58:48 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5453A0873 for ; Tue, 24 Mar 2020 18:58:48 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id t9so907974qto.9 for ; Tue, 24 Mar 2020 18:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=vWkBgkm18g6/eZ9KYuq4nlPzR+EZedXh6idyZxpNkaQ=; b=boejrfu2Px5YmqLeJSs2nTRCUTK7U8xO7Yl4Mvzz1Oc0EdT+/B8VK3FkPGDXFKuK2f zbq250tLpw0Yn/LKQ0xCXgI7l3O4Yy0kocYu6MsiiJl2hdM8C8dvkxdcn8b8s5tebmr6 MJcxdz2hKe08GkqjiCpvtIxZlpoO2mraoYiEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=vWkBgkm18g6/eZ9KYuq4nlPzR+EZedXh6idyZxpNkaQ=; b=r2wwb2i/uWpg5+r8JjPo0GH2fOoo1ouWGq14zoqPWKr4aVCfuwX/RvXHVHFvW3gvJb 4H/pEm3R8Ijs+V6TvlDScKO5APQpzE204yC33dgU4qC/pxTI7Jd2Si3/kvkj50Sulk7+ Q/hdEXjHd8zes8rZfwzePGJ6zElA1kl+m8UiAoF7wfZnGls+ym6Qkdb9C1FQPxXNq6Fc +Sbg+pMQ7xTb9xgZIQTN7EbiOyRFhZMOshSNVa47RYkG/G75Bcad8i7DGnF9juoed+lq 4tHPIFTa6GZc8FzjeRrI4Me0BGG6gh7ast3uqyIanfj1I94dx8Ru5br/9Dc6W7MmLJXi fulw== X-Gm-Message-State: ANhLgQ0pGOISWvFMhwExD0J1b+5ESJfa44YTGrLAUcM0aTNQjb3a7laY yCuMIGiD5CJfDe2r6Ux1jyAfPJ2qOHo= X-Google-Smtp-Source: ADFU+vvu2K44b0yCRAKOESaVVrzDtJsFUSpCsQTyvryjeHXgFWDeQE1NxAmbHeK5twHnZOZH0CsAaQ== X-Received: by 2002:aed:200f:: with SMTP id 15mr832805qta.152.1585101526963; Tue, 24 Mar 2020 18:58:46 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id n21sm15755721qtn.17.2020.03.24.18.58.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2020 18:58:44 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_114DCFF0-DBCD-469A-8DFE-4DC2879F3BE4" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 24 Mar 2020 21:58:43 -0400 References: <39C5C273-3BA7-413C-9A0F-FE89AF78698B@sn3rd.com> To: WPACK List In-Reply-To: <39C5C273-3BA7-413C-9A0F-FE89AF78698B@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Wpack] WPACK@vIETF107: Agenda X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 01:58:51 -0000 --Apple-Mail=_114DCFF0-DBCD-469A-8DFE-4DC2879F3BE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Uploading slides as I get them. spt > On Mar 20, 2020, at 8:18 PM, Sean Turner wrote: >=20 > hi WPACK, >=20 > Our virtual meeting is scheduled for Wednesday, 25 March 2020 from = 2000-2130 UTC. The webex details can be found on this page: = https://datatracker.ietf.org/meeting/agenda/ = >=20 > The proposed agenda is as follows (times TBD): >=20 > - Administrivia - chairs > - Use Cases - chairs > - Bundle - Jeffrey > - Security Option 1: Digital Signature - Jeffrey > - Security Option 2: - Martin > - Comparison 1 & 2 - Jeffrey/Martin >=20 > Cheers, > Dave and Sean --Apple-Mail=_114DCFF0-DBCD-469A-8DFE-4DC2879F3BE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Uploading slides as I get them.

spt
On Mar = 20, 2020, at 8:18 PM, Sean Turner <sean@sn3rd.com> wrote:

hi WPACK,

Our virtual meeting is scheduled = for Wednesday, 25 March 2020 from 2000-2130 UTC. The webex details can = be found on this page: https://datatracker.ietf.org/meeting/agenda/

The proposed agenda is = as follows (times TBD):

- Administrivia - chairs
- Use Cases - = chairs
- Bundle - Jeffrey
- Security Option = 1: Digital Signature - Jeffrey
- Security Option 2: =  - Martin
- Comparison 1 & 2 - = Jeffrey/Martin

Cheers,
Dave and Sean

= --Apple-Mail=_114DCFF0-DBCD-469A-8DFE-4DC2879F3BE4-- From nobody Tue Mar 24 19:06:53 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CD93A0924 for ; Tue, 24 Mar 2020 19:06:35 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 omIYVteAS3MX for ; Tue, 24 Mar 2020 19:06:34 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037813A093C for ; Tue, 24 Mar 2020 19:06:33 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id a5so917278qtw.10 for ; Tue, 24 Mar 2020 19:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=HswCb6U9k5XnsQ6LkbYurffWqvOhtVdN09vMcWvQKwk=; b=GXmmN3eGN+WjEfGWubFa/Ns+dupboEw47axCqG4CqPiYARNeWHE3BKM1YyM76abdg6 ca81YM2WOSTAeePSGQk2Gs6L4fJxSgHSs1qKK2i7gIUSnDl+GoK3SFbp6TegBZpREf71 UPbMTBbDbYQI723ipuy6E66f/hTXQ2Ue5EBzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=HswCb6U9k5XnsQ6LkbYurffWqvOhtVdN09vMcWvQKwk=; b=o353ZBRY9qzx8T9GNPoehFnWz0gZ1CgsVKI2flDB2atSunL1bFwHS2uYhJUyIRIBZk X8upNIQiVdQbA5TdOSYQVpGaArKY8Aqe0Jn5+Al3tamq+r2FMvqV9DKU1/d8mzdykH0P o1bXdWdDSv/hHPEVWIW3oAgu28qv5e8G7InN9B6mi2XHG1RwmXHPnt03a4RPaB3mqafx vuKsXOr9bIt3/lKWhaaiMfaCef6uFqIc8PtmY24MIz12AZSoipB3ZAE4sydC/62YQhlI KVnhfm/1w+7FKOAVDZRan5G6/snbjw4Tvyww4tit2AXdH5YTOC0GLrlqgVvHdvlzEpSG ifIA== X-Gm-Message-State: ANhLgQ2HzGBDi2AjLBWdtua1mhlokCdfQ3/pzyARXKbJXuZG10v4Xbo9 w9MULQiLIN4PF3mhQGgK8L2gcY7OKdU= X-Google-Smtp-Source: ADFU+vtDbYEw4/g1bfzkjYxTEhDcKCnMBZ44U+X/bylMohxfm/k7hnxwiRDHiU/DW5XbW5lblHZUQA== X-Received: by 2002:ac8:607:: with SMTP id d7mr817019qth.271.1585101992618; Tue, 24 Mar 2020 19:06:32 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id l18sm14287997qke.132.2020.03.24.19.06.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2020 19:06:32 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Tue, 24 Mar 2020 22:06:30 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Wpack] WPACK@vIETF107: Meeting Tips X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 02:06:52 -0000 I included this in the chair=E2=80=99s slides, but figured it could not = hurt to also share these tips here: - Webex Link: = https://ietf.webex.com/ietf/j.php?MTID=3Dmf340ca56e8214dc9fe2dd3c6f9f3047f= - Make sure your video is off - Mute your mic unless you are speaking - Use headsets to avoid echo - Use Webex chat only to join the mic queue: +q adds you to the queue=20 -q removes you from the queue - Add your name and affiliation to the virtual blue sheet in the Etherpad - Join the Jabber room: xmpp:wpack@jabber.ietf.org?join Cheers, spt= From nobody Tue Mar 24 22:06:37 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB423A08BD for ; Tue, 24 Mar 2020 22:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=lowentropy.net header.b=H7Zq9Hpm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lWoeA/Ku 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 SxX_gV4-t7Pq for ; Tue, 24 Mar 2020 22:06:34 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323B53A0873 for ; Tue, 24 Mar 2020 22:06:34 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1CE5A5A6; Wed, 25 Mar 2020 01:06:33 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 25 Mar 2020 01:06:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=wQxapI87YmJmZxpN8JMaEjbySbeI L8LGHn44EwP8nuQ=; b=H7Zq9HpmV6S1kq8Kn+16HnHN3yxynCsZHVzhEP4xTzAZ sC91pOfzjTKsqm6gwFCjuQD6imzncSTqR4KnFZMKrZVQKMaqYoTNkPu3EkR9C6rL 3XLYG0cPg7oRTy/AGl0rTm67Dta+vVfH2un6KMpPJgfc1X48fm7rFFmt0nyXQWwS MKfMg6lATqgjbw+e6fNXykjxOUuZtAfAypw0YsxtAFrOu5BH5DPsqKIv+GHGlfrV 6ipb8soxFW7kNrlXrATRolVKdY0PAo/wdPSPZvB7az8lS2hxi4n8LI8xgH/vZrJn UyBkcRbjDeWsV12tzs9j8VZd8Co7OiKi7itJG/jz/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wQxapI 87YmJmZxpN8JMaEjbySbeIL8LGHn44EwP8nuQ=; b=lWoeA/Kuy31dY+dviywnlO RordNexlrwrpARCnwvjAg48B+CG5CNj8IaXK9hsJScyCGy0ScljAAg/+MqRckzCu vKiHNFEcJn9gow3a/SOpZnfQHrGvEcal3fn+21c5LirwqKSZ3EAmuwrYynrTSe86 tmd1lfB80AyQOZr3Eec2jznBY21nCptDCcappvyHGjXX2fW8DzHEL3/bH4sazxIw EmW39huBT1t0upiB5CC+FiRwS1HgrW4MS/hjh9Zx51hd5EdxT4r7rkArZvkbyaHf gKtEm3LyQ4akSRYjxJUSs3QVavVKClQ8cyV8cmkJSNb4fBZ/uRlAROSj7jZxgzlA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehvddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepvgigrghmphhlvgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhho figvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56A23E00A6; Wed, 25 Mar 2020 01:06:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> Date: Wed, 25 Mar 2020 16:06:13 +1100 From: "Martin Thomson" To: "Ted Hardie" Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 05:06:36 -0000 On Wed, Mar 25, 2020, at 04:47, Ted Hardie wrote: > I note that you did not include "hashing is a key element of > identification" in the key concepts here, despite it being pretty > prominent in the draft. Is it something you consider fundamental here, > or is it an approach to demonstrate a method of achieving the two > desiderata above? Exemplar only. I think that signatures offer some greater flexibility, but I wanted to show how this might work without them first. > Have I missed something here? If I have not, then this approach makes a > trade-off that limits its utility in ways that make peer-to-peer usage > of the approach problematic for use cases I personally care about it. > Others, of course, may make other assessments of that trade-off. No, that's an accurate assessment. The requirement to defer attribution of information to a particular entity is part of that trade-off. In preparing slides, I think that the question of how to manage attribution is going to be an important one. I think that Jeffrey is proposing that perhaps we can attribution of the sort that people care about, without also having attribution of the sort that the web security model cares about. That might be a cool way to split this. That is, you can tell people that this is example.com, but maintain segregation and give example.com the right of refusal for the associated content and state at the point you come back online. From nobody Tue Mar 24 23:36:18 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1E3A041C for ; Tue, 24 Mar 2020 23:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Y4_hULLIq8LT for ; Tue, 24 Mar 2020 23:36:13 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BB03A0415 for ; Tue, 24 Mar 2020 23:36:13 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id a9so1169730wmj.4 for ; Tue, 24 Mar 2020 23:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=57min23d321BBXVaf1BMjJyL2qVIjjNsd+OG1tV4pJ4=; b=RlTS0XtESFHUYo6966mQSelLjEGZBwZgPjogQ9Yxswpv2uz2qB/3OSdSv95yAICxa6 3BrXB2XoX3XqNV3QwJmFCHK3oNThgtvDI4PlCrs4gqmmft6msg4lN0iwmX7z5RKksaF9 CRtCr5iiBqssohZEd8k9RnDwSrSkES+UeSR6b89t+XbFVzkhuvAweRBxCKovsPc0Axif KiewkzBxNaVSqp8LshRivVWSSbBB362dz2cbI/IvzhatPgod5BDRRnFaaiC30kc2zhj7 5BAiMz8eurMoy1HwdvUp+0vwD4GGM0ww90Ry3kSlyXQ+TUftt98NMGq9ThV9RN73FrgA ZEfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=57min23d321BBXVaf1BMjJyL2qVIjjNsd+OG1tV4pJ4=; b=s6ZYiPm741y9s5Lb/5ocmXwqtqdYKhz73sv4yCp8M+vVmz+1NjjHRlpJRhQEcpUOtN W7+qiV7xo7A5f24U8QreXxFmPm6P6B/RV83S+4ScNNaqh8T2tMbOmF6KGYrzaEyEWfTD la7Peur1yH06m/3AFzcrmYTu3Yp09+jHfjsuvOxwC50AtkgPgn7RjtNsUvUqGi01hp74 ZdFZvGSIrHrfTNERsC/8J1uGWFgmQpJNCNSFtCyfBwy2DrULtX/oPaeP2ijrparlqFv7 Qs14QIkXedLVTXzpuiaGVasZ4WKeQekbZzwrzrcjWF4HSH1488KXMIGUvRYHMkbIP62e vJfA== X-Gm-Message-State: ANhLgQ0OdrQgdCo9b6ay4pRXEXTpllycUD9SyEgsnwawNcs6jcdKHunl +LOxhDeHghFEhObugTKva+0316JflVTAkMFwUA1uYk77LP8= X-Google-Smtp-Source: ADFU+vsxVsRo95h6HXnM3+6niGjzB9Eeyyxj08BJHrFbDPxcfIh1/pAA3mQKXiTucYa5tSec6U4OlUP5x3RwmHMLt8U= X-Received: by 2002:a1c:f409:: with SMTP id z9mr1915771wma.51.1585118171222; Tue, 24 Mar 2020 23:36:11 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> From: Devin Mullins Date: Tue, 24 Mar 2020 23:35:44 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000086343805a1a81544" Archived-At: Subject: Re: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 06:36:16 -0000 --00000000000086343805a1a81544 Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for the engineering work on this. For others, I've already reviewed this, had some chats with others on the AMP team, and had a few back-and-forths with Martin (he's been very gracious in engaging his time, thank you). I'm trying to estimate the feasibility of this, both for the AMP use-case, and for the non-AMP use-case [1], which we hope to see flourish to the extent that publishers and users desire it, and only impeded by implementation costs where necessary for the common good. With the caveat that this is very early feedback, the high-level bit is that, with some modifications, it seems mostly feasible for AMP. However, there are two main downsides: 1. worse UX on sites that run A/B experiments 2. technical constraints make this harder for publishers to adopt on non-AMP, as compared to SXG A lot of details follow. I suggest to rename the subject if you reply to a detail below, in order to reduce cross-talk and make browsing the archive easier. Details: We would need the display URL to be the attested URL even before transfer. I suspect a flash in the URL bar would be frustrating for both users and publishers. Jeffrey had proposed using signatures for this. I'd suppose UAs could choose to render this with a "may be stale" indicator. In terms of publisher implementation feasibility, I think the mostly likely implementation would be for a publisher to produce a Sec-Content-Origin (Sec-CO) response for the current version of the resource iff it matches the Sec-CO request. I suspect that keeping state of past versions of the resource would be infeasible, especially as it couldn't be done purely at the edge; it would require something like a region-wide cache. The value of the above stateless implementation would be inversely proportional to how often the resource changes (e.g. "transient content" [2] such as Related Articles). I think this would be a workable constraint for publishers wishing to publish such bundles, but felt it's worth noting, nonetheless. Re: fallback behavior on failed state transfer, distributors would need a way to monitor failure rates. This serves two purposes: 1. Automatically detecting errors in the distribution pipeline. This is the same purpose served by https://wicg.github.io/webpackage/loading.html#signed-exchange-report. 2. Verifying that, for some fraction of navigations, bundles are meeting AMP's stated UX goals (by using the verified content in the bundle and not potentially arbitrary content after the redirect). This is a dynamic equivalent of what can be done mostly statically with SXG, because the distributor can run the same algorithm as the UA, modulo client/server skew in clocks and root stores. I think this is a trade-off AMP could make. The alternative is that the fallback behavior keeps the content-based origin (CBO). There is a possible vector for user ID transfer from distributor to publisher; filed as https://github.com/martinthomson/wpack-content/issues/1. This limits the ability to run session-sticky experiments (in https://amp.dev/documentation/components/amp-experiment/ and many non-AMP frameworks). The publisher has the following options: 1. Delay rendering content under experiment until after state transfer. This hurts UX for the sake of experimentation, creating a trade-off that otherwise doesn't exist on origin (modulo ease of implementation). 2. Generate a client-side UUID before state transfer, and join it with the pre-existing user ID after transfer. This means the session could not include CBO pageviews anywhere except in the first pageview. 3. Generate variants of the bundle for each experimental state. The distributor chooses which bundle to send to the user (based on what? not sure). For a page with M independent experiments each with N arms, that's N^M variants. For large enough M and N, this is likely both infeasible for publishers and martinthomson/wpack-content#1. (But I need some guidance from experts on typical ranges for M and N.) Perhaps this is a need the UA could address. A straw proposal -- a selectExperimentArm() API that: 1. only exposes as many bits as the UA deems OK, and 2. exposes different bits to different attested origins, so they can't be joined On the one hand, perhaps this is too much scope for wpack. On the other, it addresses a problem that is somewhat particular to CBOs. This impedes content management (e.g. dialogs for GDPR and CCPA), compared to SXG. The publisher has a few choices: 1. Delay rendering the dialog under after transfer. I think this would cause layout shift (https://web.dev/cls/). 2. Render the dialog, and risk discovering that it's already been acknowledged. At that point: a. Hide it, causing layout shift. b. Leave it there. This is way outside my domain expertise, but ISTR there are some rules or at least best practices wrt when it's okay to re-show an opt-out dialog. One of these options may be an okay trade-off; I'm not sure. Analytics providers (via https://amp.dev/documentation/components/amp-analytics/ and many non-AMP libraries) would have to do one of two things: 1. Delay pingback until after transfer. This risks a lower fraction of successful pingbacks, as e.g. the user might close the tab before transfer. 2. Generate a client-side UUID, send pingback before transfer, and send a follow-up after transfer to join with pre-existing user ID. This captures those otherwise lost pingbacks pseudonymously (anonymously?), though it requires server-side work on the pingback endpoint. For the above client-side mitigations, two feature requests seem necessary: 1. Store the transfer metadata (e.g. indexedDB renames by time) somewhere more permanent. For various reasons the event handler may not fire or finish, and it would be good to later scan for stragglers to merge or expunge. 2. DOM API to wait for transfer to complete. Some subresources are ACLs by Origin header (e.g. paid fonts). Likely mitigation is to defer loading until transfer, with a timeout whose duration depends on the publisher's font-display preference. (Martin suggests an optimization where the encrypted subresource is loaded early, and only the decryption key after transfer.) Last but not least, I am concerned that this is a bar that is disproportionately difficult for non-AMP publishers to meet. The above client-side mitigations are possible, but quite a bit of work. 1. For frameworks like AMP that strongly encourage publishers to use a rolling release, it is possible to upgrade many use-cases in the wild with minimal publisher effort. 2. For other frameworks, it may be possible to provide this support, but the requirement to upgrade versions may limit applicability. Because upgrades occur less often, they often require more work. 3. For custom JS that manages state, authors will need to modify it to move or copy state into indexedDB, and handle transfer events and merge conflicts. >From a "minimal publisher effort" perspective, I am especially interested in making it possible to have as close to a turnkey solution as is reasonable, for instance at the level of the CDN or CMS. If such a solution exists, sites would likely contain a hybrid of all three cases above, and thus want to opt into such support incrementally. How should a CDN determine which pages to provide Sec-CO responses for? 1. URL patterns are the simplest answer, but I suspect hard for publishers to create and maintain with minimal false negatives and positives. 2. Would it be helpful to thread an "I support state transfer" annotation for some portion of the build journey, from individual JS function all the way to bundle? Would folks use this? I don't have a good solution to the issue of non-AMP developer cost, and thus fear this is a solution that would feature a disproportionate amount of AMP pages compared to the background distribution of the web. But I'm hopeful that other JS framework developers can chime in with respect to feasibility of support for CBO and state transfer. I'm leaving out some of Martin's replies to the above; no offense intended. It took me long enough just to summarize the above, and I'd better send it early enough so at least a few people have time to read it before the meeting. Thanks, Devin [1] https://blog.amp.dev/2019/05/22/privacy-preserving-instant-loading-for-all-web-content/ [2] http://www.seobythesea.com/2011/12/how-google-might-identify-transient-content-on-webpages/ On Mon, Mar 23, 2020 at 5:35 PM Martin Thomson wrote: > Ted's note prompted me to send a much-belated announcement (sorry folks, I > forgot). > > The draft is here: > https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 > > A nicer version here: > > https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html > > This approach could a dramatically different approach to addressing the > use cases set out in our charter. > > In short, this aims to address the core question of how offline content > might *ultimately* be attributed to a web origin in a fundamentally > different way. There are two key concepts: > > 1. Content is given its own origin, using a new system for identification. > > 2. A target origin can "accept" content and state from one of these new > origins. > > There are a lot of details here (read the draft), but the major advantage > I see is that you don't have to make an offline decision about authority, > and that means you can be offline for much longer (lifting the 7 day limit). > > What it does have in common with signed exchanges approach is the need for > a bundling format, but in its current form it is less dependent on the > details of the format. That might allow that to be simpler, but I'm sure > that the need to mint new identifier types will more than make up for any > slack there. > > The draft is quite rough. I'm sure that it has the remnants of a few bad > ideas still hanging around. Ask questions if you think something is > unclear. > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000086343805a1a81544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for the engineering work on this.= For others, I've already reviewed this, had some chats with others on = the AMP team, and had a few back-and-forths with Martin (he's been very= gracious in engaging his time, thank you). I'm trying to estimate the = feasibility of this, both for the AMP use-case, and for the non-AMP use-cas= e [1], which we hope to see flourish to the extent that publishers and user= s desire it, and only impeded by implementation costs where necessary for t= he common good.

With the caveat that this is very early feedback, th= e high-level bit is that, with some modifications, it seems mostly feasible= for AMP. However, there are two main downsides:
=C2=A0 1. worse UX on s= ites that run A/B experiments
=C2=A0 2. technical constraints make this = harder for publishers to adopt on non-AMP, as compared to SXG

A lot = of details follow. I suggest to rename the subject if you reply to a detail= below, in order to reduce cross-talk and make browsing the archive easier.=

Details:

We would need the display URL to be the attested UR= L even before transfer. I suspect a flash in the URL bar would be frustrati= ng for both users and publishers. Jeffrey had proposed using signatures for= this. I'd suppose UAs could choose to render this with a "may be = stale" indicator.

In terms of publisher implementation feasibil= ity, I think the mostly likely implementation would be for a publisher to p= roduce a Sec-Content-Origin (Sec-CO) response for the current version of th= e resource iff it matches the Sec-CO request. I suspect that keeping state = of past versions of the resource would be infeasible, especially as it coul= dn't be done purely at the edge; it would require something like a regi= on-wide cache. The value of the above stateless implementation would be inv= ersely proportional to how often the resource changes (e.g. "transient= content" [2] such as Related Articles). I think this would be a worka= ble constraint for publishers wishing to publish such bundles, but felt it&= #39;s worth noting, nonetheless.

Re: fallback behavior on failed sta= te transfer, distributors would need a way to monitor failure rates. This s= erves two purposes:
=C2=A0 1. Automatically detecting errors in the dist= ribution pipeline. This is the same purpose served by https://wicg.g= ithub.io/webpackage/loading.html#signed-exchange-report.
=C2=A0 2. V= erifying that, for some fraction of navigations, bundles are meeting AMP= 9;s stated UX goals (by using the verified content in the bundle and not po= tentially arbitrary content after the redirect). This is a dynamic equivale= nt of what can be done mostly statically with SXG, because the distributor = can run the same algorithm as the UA, modulo client/server skew in clocks a= nd root stores. I think this is a trade-off AMP could make. The alternative= is that the fallback behavior keeps the content-based origin (CBO).
There is a possible vector for user ID transfer from distributor to publis= her; filed as https://github.com/martinthomson/wpack-content/issues/1.

= This limits the ability to run session-sticky experiments (in https://amp.dev/doc= umentation/components/amp-experiment/ and many non-AMP frameworks). The= publisher has the following options:
=C2=A0 1. Delay rendering content = under experiment until after state transfer. This hurts UX for the sake of = experimentation, creating a trade-off that otherwise doesn't exist on o= rigin (modulo ease of implementation).
=C2=A0 2. Generate a client-side = UUID before state transfer, and join it with the pre-existing user ID after= transfer. This means the session could not include CBO pageviews anywhere = except in the first pageview.
=C2=A0 3. Generate variants of the bundle = for each experimental state. The distributor chooses which bundle to send t= o the user (based on what? not sure). For a page with M independent experim= ents each with N arms, that's N^M variants. For large enough M and N, t= his is likely both infeasible for publishers and martinthomson/wpack-conten= t#1. (But I need some guidance from experts on typical ranges for M and N.)=

Perhaps this is a need the UA could address. A straw proposal -- a = selectExperimentArm() API that:
=C2=A0 1. only exposes as many bits as t= he UA deems OK, and
=C2=A0 2. exposes different bits to different attest= ed origins, so they can't be joined
On the one hand, perhaps this is= too much scope for wpack. On the other, it addresses a problem that is som= ewhat particular to CBOs.

This impedes content management (e.g. dial= ogs for GDPR and CCPA), compared to SXG. The publisher has a few choices:=C2=A0 1. Delay rendering the dialog under after transfer. I think this w= ould cause layout shift (https://web.dev/c= ls/).
=C2=A0 2. Render the dialog, and risk discovering that it'= s already been acknowledged. At that point:
=C2=A0 =C2=A0 a. Hide it, ca= using layout shift.
=C2=A0 =C2=A0 b. Leave it there. This is way outside= my domain expertise, but ISTR there are some rules or at least best practi= ces wrt when it's okay to re-show an opt-out dialog.
One of these op= tions may be an okay trade-off; I'm not sure.

Analytics provider= s (via = https://amp.dev/documentation/components/amp-analytics/ and many non-AM= P libraries) would have to do one of two things:
=C2=A0 1. Delay pingbac= k until after transfer. This risks a lower fraction of successful pingbacks= , as e.g. the user might close the tab before transfer.
=C2=A0 2. Genera= te a client-side UUID, send pingback before transfer, and send a follow-up = after transfer to join with pre-existing user ID. This captures those other= wise lost pingbacks pseudonymously (anonymously?), though it requires serve= r-side work on the pingback endpoint.

For the above client-side miti= gations, two feature requests seem necessary:
=C2=A0 1. Store the transf= er metadata (e.g. indexedDB renames by time) somewhere more permanent. For = various reasons the event handler may not fire or finish, and it would be g= ood to later scan for stragglers to merge or expunge.
=C2=A0 2. DOM API = to wait for transfer to complete.

Some subresources are ACLs by Orig= in header (e.g. paid fonts). Likely mitigation is to defer loading until tr= ansfer, with a timeout whose duration depends on the publisher's font-d= isplay preference. (Martin suggests an optimization where the encrypted sub= resource is loaded early, and only the decryption key after transfer.)
<= br>Last but not least, I am concerned that this is a bar that is disproport= ionately difficult for non-AMP publishers to meet. The above client-side mi= tigations are possible, but quite a bit of work.
=C2=A0 1. For framework= s like AMP that strongly encourage publishers to use a rolling release, it = is possible to upgrade many use-cases in the wild with minimal publisher ef= fort.
=C2=A0 2. For other frameworks, it may be possible to provide this= support, but the requirement to upgrade versions may limit applicability. = Because upgrades occur less often, they often require more work.
=C2=A0 = 3. For custom JS that manages state, authors will need to modify it to move= or copy state into indexedDB, and handle transfer events and merge conflic= ts.

From a "minimal publisher effort" perspective, I am es= pecially interested in making it possible to have as close to a turnkey sol= ution as is reasonable, for instance at the level of the CDN or CMS. If suc= h a solution exists, sites would likely contain a hybrid of all three cases= above, and thus want to opt into such support incrementally. How should a = CDN determine which pages to provide Sec-CO responses for?
=C2=A0 1. URL= patterns are the simplest answer, but I suspect hard for publishers to cre= ate and maintain with minimal false negatives and positives.
=C2=A0 2. W= ould it be helpful to thread an "I support state transfer" annota= tion for some portion of the build journey, from individual JS function all= the way to bundle? Would folks use this?

I don't have a good so= lution to the issue of non-AMP developer cost, and thus fear this is a solu= tion that would feature a disproportionate amount of AMP pages compared to = the background distribution of the web. But I'm hopeful that other JS f= ramework developers can chime in with respect to feasibility of support for= CBO and state transfer.

I'm leaving out some of Martin's re= plies to the above; no offense intended. It took me long enough just to sum= marize the above, and I'd better send it early enough so at least a few= people have time to read it before the meeting.

Thanks,
Devin
[1] https://blog.amp.dev/2019/05/22/privacy-p= reserving-instant-loading-for-all-web-content/
[2] http://www.seobythesea.com/2011/12/how-google-might-identify-tr= ansient-content-on-webpages/

On Mon, Mar 23, 2020 at 5:35 PM Martin = Thomson <mt@lowentropy.net> = wrote:
Ted's= note prompted me to send a much-belated announcement (sorry folks, I forgo= t).

The draft is here:
https://tools.ietf.org/html/draft-t= homson-wpack-content-origin-00

A nicer version here:
https://martint= homson.github.io/wpack-content/draft-thomson-wpack-content-origin.html<= br>
This approach could a dramatically different approach to addressing the use= cases set out in our charter.

In short, this aims to address the core question of how offline content mig= ht *ultimately* be attributed to a web origin in a fundamentally different = way.=C2=A0 There are two key concepts:

1. Content is given its own origin, using a new system for identification.<= br>
2. A target origin can "accept" content and state from one of the= se new origins.

There are a lot of details here (read the draft), but the major advantage I= see is that you don't have to make an offline decision about authority= , and that means you can be offline for much longer (lifting the 7 day limi= t).

What it does have in common with signed exchanges approach is the need for = a bundling format, but in its current form it is less dependent on the deta= ils of the format.=C2=A0 That might allow that to be simpler, but I'm s= ure that the need to mint new identifier types will more than make up for a= ny slack there.

The draft is quite rough.=C2=A0 I'm sure that it has the remnants of a = few bad ideas still hanging around.=C2=A0 Ask questions if you think someth= ing is unclear.

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000086343805a1a81544-- From nobody Wed Mar 25 10:28:42 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6853A09D9 for ; Wed, 25 Mar 2020 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.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 DSZbp75VKcBg for ; Wed, 25 Mar 2020 10:28:33 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607ED3A0C93 for ; Wed, 25 Mar 2020 10:28:31 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id v134so2806146oie.11 for ; Wed, 25 Mar 2020 10:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iZsvqGDWoDsN3IOLBDZjV/BhhHeiOJWso9nk826d8IM=; b=tR4M90LR3DCaiI5dLFPAA/6Phgo6OWMphfxV7HUTsyig50pBMCdteH6HS6GsZh2I0K 5l2/IQBLM3bj7NQl04YoUk/JrxO3Dd2B7WuMZTQv2cjElh/wk4hSL+VsSS2gUt1cLr2f haqUOjLRXJNvZcHG6Zn7EB4lqIhbs5crJq7CxX+z/s2/M+sG0x5ZG9hl+aT7nag0vh9x I+msRGgn6qMfJNw6z0OHTLe7aze8Jp6XinEvH4dGYUpl1I/lsYNQTO1ghn8m6O3sqYtI rmaOH6fknIoR/72DszgDSvbTk6cu1eQqPR/tLu//K6bjmAGBICuh+M9qgS0mv1qOpHSh 8xog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iZsvqGDWoDsN3IOLBDZjV/BhhHeiOJWso9nk826d8IM=; b=NeTPwfaV/pDDkufrPu/gWecREtSVKBOIv0jZhrcqpIySsVMS0oWlksJw8dZi0XIMWI KmQKrGw4vYvk9K+T/Ifkg/bZHhU+u02Qj8jzPNHpYXu6KaDCYQfex87/pdStZkJktLEN 1Mzlj0Irz3IJy/13U8L0LsYou5FxgjevSZeSOd02yHrRD4dBBhN/Po4eYVgGroMEGXUw wj0FZy1apSMXV3F6DIFtOAwa7NWzcXE9OdjrMlqjXi4jQ95X7qhYn0wtUsCN43FYdORU WL57WTiXRg2spCdR6iIGa4/RyhIDKq4A7yMX0WPF8Jb5lvgwTl7z5wb3lamqzIVTsGPT 6s+Q== X-Gm-Message-State: ANhLgQ3m7WmB5Hv7Y+arUBMd8J4uJTeVuwNCYY0YBmwlouknJzkUdESg ug+tSKlQM4hGNDjyzQ0uIQmDYTa0yYTVb5CNl+M= X-Google-Smtp-Source: ADFU+vsO0r5nom5jNr6JT/Fl/WoudDRhnUOuOiJPGLtdRloUcL0d5i4LY4qnpXoRMoZDQDpGVdZJ+Y8P0EIMjYyrMDI= X-Received: by 2002:aca:db08:: with SMTP id s8mr3408132oig.167.1585157310267; Wed, 25 Mar 2020 10:28:30 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Ted Hardie Date: Wed, 25 Mar 2020 10:28:06 -0700 Message-ID: To: Devin Mullins Cc: Martin Thomson , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000064471205a1b13200" Archived-At: Subject: [Wpack] Sec-Content-Origin clarification question (was Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 17:28:40 -0000 --00000000000064471205a1b13200 Content-Type: text/plain; charset="UTF-8" Hi Devin, Thanks for the write-up. A clarifying question, snipped from the middle of your response: On Tue, Mar 24, 2020 at 11:36 PM Devin Mullins wrote: > > In terms of publisher implementation feasibility, I think the mostly > likely implementation would be for a publisher to produce a > Sec-Content-Origin (Sec-CO) response for the current version of the > resource iff it matches the Sec-CO request. I suspect that keeping state of > past versions of the resource would be infeasible, especially as it > couldn't be done purely at the edge; it would require something like a > region-wide cache. The value of the above stateless implementation would be > inversely proportional to how often the resource changes (e.g. "transient > content" [2] such as Related Articles). I think this would be a workable > constraint for publishers wishing to publish such bundles, but felt it's > worth noting, nonetheless. > If the ecosystem supported something like signed bundles and unsigned bundles which used content identifiers, would you see a site sending a Sec-Content-Origin response resulting in the user agent essentially upgrading the bundle's treatment to the same as a signed bundle's, or would there a third state (unsigned bundled, verified NI, signed bundle)? regards, Ted --00000000000064471205a1b13200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Devin,

Thanks for t= he write-up.=C2=A0 A clarifying question, snipped from the middle of your r= esponse:

On Tue, Mar 24, 2020 at 11:36 PM Devin Mullins <twifkak= =3D40google.com@dmarc.ietf.o= rg> wrote:

In terms of publisher implementation feasibility, I = think the mostly likely implementation would be for a publisher to produce = a Sec-Content-Origin (Sec-CO) response for the current version of the resou= rce iff it matches the Sec-CO request. I suspect that keeping state of past= versions of the resource would be infeasible, especially as it couldn'= t be done purely at the edge; it would require something like a region-wide= cache. The value of the above stateless implementation would be inversely = proportional to how often the resource changes (e.g. "transient conten= t" [2] such as Related Articles). I think this would be a workable con= straint for publishers wishing to publish such bundles, but felt it's w= orth noting, nonetheless.

If the = ecosystem supported something like signed bundles and unsigned bundles whic= h used content identifiers, would you see a site sending a Sec-Content-Orig= in response resulting in the user agent essentially upgrading the bundle= 9;s treatment to the same as a signed bundle's, or would there a third = state (unsigned bundled, verified NI, signed bundle)?

<= div>regards,

Ted=C2=A0
--00000000000064471205a1b13200-- From nobody Wed Mar 25 11:26:05 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CF23A07D3 for ; Wed, 25 Mar 2020 11:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 jkFJCsh3Bjro for ; Wed, 25 Mar 2020 11:25:58 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B46C3A0C54 for ; Wed, 25 Mar 2020 11:25:58 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 26so5584057wmk.1 for ; Wed, 25 Mar 2020 11:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YpBexxzcJ5WfP870V8pj+BdtdwTWq3aRiHvJ4ZMIMAg=; b=XDBaApW9YDk8Ez4IIyX7+5aCaHvc87pvkKfyQeRfWZmZcZB+StARCfRUghijzAypQI peLbYjpTD1b3zDCZksqfCfbhjkVFd+rq09+0Tn9pcNrfeKVU/BFlgN7oQW6wTgG/wmic NObPZNLMO5tpIQy6jMxfXTwn+nz0MqyO/7KE9ao1zFJ/+Gc7O05OGTgABUEhMzmcDJ6D Vt8wfKSwER9gZB4aA11OSBh+YKXbd+X9YknSZvkrRuvli47YigqpIbaInXvjLVcSz903 LekERcVpB+9h2btVKZTOTn4OArgPG4/MUaowgxz6aDl/5DGKYKONGhZ+jr+383TchK8x Gq7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YpBexxzcJ5WfP870V8pj+BdtdwTWq3aRiHvJ4ZMIMAg=; b=lvJbCHpssnbiLJlmqyB6cYOcGuXh2YazpfLfukJ5pp1wvZqdDUuDjUK2ppqmgG7SEP E2oHAAX9Cv4Iv2lKDbs/VE0hxyg/8ZcP7gQdjsIK1zUOYTgiyztC7d/0wyXY5kI08RWo 9HDb0MSgGDQeMXIa77mnnz0nFIwtvIDibMgS2STMXz1prDzvcb4Xhb4uXbZetRVKLq5C zeSgveg3kYs5j6+3n6zF7ZfyHV3/dDBDYeF3IvR4jyzydnIDzKjds5a1LVr2FaHbk3QO lHfCq7g1xItrfddeRNddVeHAfTXTbppEZpSrJfBbIOtfwE38IfoClbB0KtsqNDWw8YhA f2/w== X-Gm-Message-State: ANhLgQ10J2X71JIKFmNzNojmrZTYOXlCow5inWHA/Nt9JsIN6gykC4SG 9Pp4r15vv5QzGs8eVpROwqBPB7OYmn/5ioHnvvZ8ng== X-Google-Smtp-Source: ADFU+vulCzCO9LDmFCQq7NLe8SpX6hwB9EwFE25XdfaA/GUq9CN6Xw376YgC2LiGW8AEYkOcGc7W1LrvZoMe6zqcsEs= X-Received: by 2002:a1c:f409:: with SMTP id z9mr4926682wma.51.1585160756078; Wed, 25 Mar 2020 11:25:56 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Devin Mullins Date: Wed, 25 Mar 2020 11:25:28 -0700 Message-ID: To: Ted Hardie Cc: Martin Thomson , wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000c7a1ef05a1b1ffcd" Archived-At: Subject: Re: [Wpack] Sec-Content-Origin clarification question (was Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 18:26:03 -0000 --000000000000c7a1ef05a1b1ffcd Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 10:28 AM Ted Hardie wrote: > If the ecosystem supported something like signed bundles and unsigned > bundles which used content identifiers, would you see a site sending a > Sec-Content-Origin response resulting in the user agent essentially > upgrading the bundle's treatment to the same as a signed bundle's, or would > there a third state (unsigned bundled, verified NI, signed bundle)? > If you're asking about user-agent behavior, I'll defer to folks who work on user-agents such as Martin and Jeffrey. In terms of how the framework would behave, I'm not the expert, but from the hip, I'd guess, if in all major user agents, signed bundles can access storage on their attested origin, then we'd bundle the same JS in both signed and unsigned cases. We'd have to move the state of any of our render-critical components [1] to indexedDB for unsigned, and after that, I don't see a reason to keep the non-indexedDB version around just for signed; it'd be a maintenance burden. (But I'm betting there's nuances I don't know about.) If transfer event handlers end up being a lot of code, we could optimize them away in signed bundles to save JS binary size, but I'm guessing they won't be a lot of code, therefore not worth the effort to factor the code for that ability. To make the above work, I'd think we'd need the "wait for transfer" DOM API to resolve immediately for signed bundles and non-bundled pages. Of course, with all things, this will take time. Since support for signed exchanges exists today, it would be easiest to migrate support to signed bundles initially, so I would expect a staggered rollout. I hope I answered your question! [1] or portions of the analytics/consent components, possibly > --000000000000c7a1ef05a1b1ffcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 25, 2020 at 10:28 AM Ted Hard= ie <ted.ietf@gma= il.com> wrote:
If the e= cosystem supported something like signed bundles and unsigned bundles which= used content identifiers, would you see a site sending a Sec-Content-Origi= n response resulting in the user agent essentially upgrading the bundle'= ;s treatment to the same as a signed bundle's, or would there a third s= tate (unsigned bundled, verified NI, signed bundle)?

If you're asking about user-agent behavior, I= 'll defer to folks who work on user-agents such as Martin and Jeffrey.<= /div>

In terms of how the framework would behave, I'= m not the expert,=C2=A0but from the hip, I'd guess, if in all major use= r agents, signed bundles can access storage on their attested origin, then = we'd bundle the same JS in both signed and unsigned cases. We'd hav= e to move the state of any of our render-critical components [1] to indexed= DB for unsigned, and after that, I don't see a reason to=C2=A0keep the = non-indexedDB version around just for signed; it'd be a maintenance=C2= =A0burden. (But I'm betting there's nuances I don't know about.= ) If transfer event handlers end up being a lot of code, we could optimize = them away in signed bundles to save JS binary size, but I'm guessing th= ey won't be a lot of code, therefore not worth the effort to factor the= code for that ability.

To make the above work, I&= #39;d think we'd need the "wait for transfer" DOM API to reso= lve immediately for signed bundles and non-bundled pages.

Of course, with all things, this will take time. Since support for = signed exchanges exists today, it would be easiest to migrate support to si= gned bundles initially, so I would expect a staggered rollout.
I hope I answered your question!

[1] = or portions of the analytics/consent components, possibly
--000000000000c7a1ef05a1b1ffcd-- From nobody Wed Mar 25 12:19:00 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB33A09AE for ; Wed, 25 Mar 2020 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 bJCkTvnDcy63 for ; Wed, 25 Mar 2020 12:18:54 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9953A091D for ; Wed, 25 Mar 2020 12:18:54 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id k13so3880229qki.2 for ; Wed, 25 Mar 2020 12:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nf8E5PNS8WMG2YqfC4fwajZ+mGT/luOacIoTPl9q4QY=; b=eC15CePUERtWCfBKAQ8beiwJ8uvOHupXHX+LH0P+QCkhtdyU3dWKAHAHzAyNawswL/ cunjWOcVQuzRSesTWEl9a0hKvUsRdu1Ev/7/CdHwZ/23ivLkGFPR/MA4qtQuSwbmUBpm WlJ21PkbXqYkHHNgae+i8xeObofVoE936IYjA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nf8E5PNS8WMG2YqfC4fwajZ+mGT/luOacIoTPl9q4QY=; b=e4SlgWjggoDkF4sU1wmxfsw9YwA7TCxO3DOx5qz1vaGFNGTnGgbzH6EZAZOIIvB+1D rzpqA3YjPsf7ma482uwCo5+H9luh9T5jC8FrhgL8MbiPMBQgaKe/wJyUHfUOG5dcR3pe hDPI8dBG8Ie/Q6QPbQj6o21X8IOqV9/C47rymi/HRPJnLVJ1uAEL4H1tBcbeIHmGvbEB b8AplMWE2M9NoDYYg1SEE58BW8Ef6WDxuJgfl9HST3Ej9/lyxN7sGsSaUGlDBkA+KjMp DPQzIVNiLEB7sJgQ9KKgFyUHpwpruExy/4FJT+yFZbkyOTfTB5m9PndAc+yG0d4d2UQj jgHg== X-Gm-Message-State: ANhLgQ3z/nEpF37fOiFSwHP5WbVwxBtI9azsk7CIN3dAoO6wPqggpPwo ChwvRs4bDshBOGIFDcns5QqkOIMbig1h2aQ3+/fKaQ== X-Google-Smtp-Source: ADFU+vvHtpnQo8V5oa8Q1NsSyuHORwpvVUzuyEGHsYhwDLoo5hcxJd/VrlIjLjiJpilXOelrDNahsoeAPas/skxXH0Y= X-Received: by 2002:a37:a7cd:: with SMTP id q196mr4126255qke.447.1585163933083; Wed, 25 Mar 2020 12:18:53 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Jeffrey Yasskin Date: Wed, 25 Mar 2020 12:18:41 -0700 Message-ID: To: Ted Hardie Cc: Devin Mullins , wpack@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="00000000000024faef05a1b2bd75" Archived-At: Subject: Re: [Wpack] Sec-Content-Origin clarification question (was Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:18:56 -0000 --00000000000024faef05a1b2bd75 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 10:29 AM Ted Hardie wrote: > Hi Devin, > > Thanks for the write-up. A clarifying question, snipped from the middle > of your response: > > On Tue, Mar 24, 2020 at 11:36 PM Devin Mullins 40google.com@dmarc.ietf.org> wrote: > >> >> In terms of publisher implementation feasibility, I think the mostly >> likely implementation would be for a publisher to produce a >> Sec-Content-Origin (Sec-CO) response for the current version of the >> resource iff it matches the Sec-CO request. I suspect that keeping state of >> past versions of the resource would be infeasible, especially as it >> couldn't be done purely at the edge; it would require something like a >> region-wide cache. The value of the above stateless implementation would be >> inversely proportional to how often the resource changes (e.g. "transient >> content" [2] such as Related Articles). I think this would be a workable >> constraint for publishers wishing to publish such bundles, but felt it's >> worth noting, nonetheless. >> > > If the ecosystem supported something like signed bundles and unsigned > bundles which used content identifiers, would you see a site sending a > Sec-Content-Origin response resulting in the user agent essentially > upgrading the bundle's treatment to the same as a signed bundle's, or would > there a third state (unsigned bundled, verified NI, signed bundle)? > I don't think there should be three states. I've been trying various models and sets of terminology for the possible treatments of bundle content over the last couple months, and I'm not yet sure what model makes most sense. This week, my favorite is to use HTTP's notion of a response being "authoritative", https://tools.ietf.org/html/draft-ietf-httpbis-semantics-07#section-11.1. A response in a bundle can either be authoritative for their claimed URL or not, and they're authoritative if any of several conditions holds: 1. The bundle itself was served by the same origin. 2. The bundle was signed by the origin. 3. A live request to the claimed origin adopts the content. I think that doesn't quite match Martin's notion of aliasing origins, so I still have some thinking to do. Jeffrey --00000000000024faef05a1b2bd75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 25, 2020 at 10:29 AM Ted Hard= ie <ted.ietf@gmail.com> wro= te:
Hi Devin,

Thanks for the write-up.=C2=A0 A clarifying question, snipped from the m= iddle of your response:

On Tue, Mar 24, 2020 at 11:36 PM Devin Mullin= s <twifkak=3D40google.com@dmarc.ietf.org> wrote:

In terms of publisher= implementation feasibility, I think the mostly likely implementation would= be for a publisher to produce a Sec-Content-Origin (Sec-CO) response for t= he current version of the resource iff it matches the Sec-CO request. I sus= pect that keeping state of past versions of the resource would be infeasibl= e, especially as it couldn't be done purely at the edge; it would requi= re something like a region-wide cache. The value of the above stateless imp= lementation would be inversely proportional to how often the resource chang= es (e.g. "transient content" [2] such as Related Articles). I thi= nk this would be a workable constraint for publishers wishing to publish su= ch bundles, but felt it's worth noting, nonetheless.

If the ecosystem supported something like signed bu= ndles and unsigned bundles which used content identifiers, would you see a = site sending a Sec-Content-Origin response resulting in the user agent esse= ntially upgrading the bundle's treatment to the same as a signed bundle= 's, or would there a third state (unsigned bundled, verified NI, signed= bundle)?

I don't thi= nk there should be three states.

I've been try= ing various models and sets of terminology for the possible treatments of b= undle content over the last couple months, and I'm not yet sure what mo= del makes most sense. This week, my favorite is to use HTTP's=C2=A0noti= on of a response being "authoritative",=C2=A0https://to= ols.ietf.org/html/draft-ietf-httpbis-semantics-07#section-11.1. A respo= nse in a bundle can either be authoritative for their claimed URL or not, a= nd they're authoritative if any of several conditions holds:
= 1. The bundle itself was served by the same origin.
2. The bundle= was signed by the origin.
3. A live request to the claimed origi= n adopts the content.

I think that doesn't qui= te match Martin's notion of aliasing origins, so I still have some thin= king to do.

Jeffrey
--00000000000024faef05a1b2bd75-- From nobody Wed Mar 25 12:45:52 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA9D3A0A03 for ; Wed, 25 Mar 2020 12:45:50 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 CmyD0iDxXtqD for ; Wed, 25 Mar 2020 12:45:48 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A651A3A0A47 for ; Wed, 25 Mar 2020 12:45:48 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id d11so3971787qko.3 for ; Wed, 25 Mar 2020 12:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=L2hh3pxQ/hXLeyf2/sw+1yzAlgF4GHzzjMssEU1K0RE=; b=h2RE8ne4PBU7X3TIUYdA2BjekpZLJ6YcwKIhzTKBPWBwkndttkMoMb9hbMcsvQZ8w+ gPWqJy+HIsmtZEIGBMcU73ZdlrURRHjzWt6Cl4R9AxK8s/6if82gYJHBrGlmqQL1Ehoq LR/OT39SPIrntkcX8Dt/ylnaH3TUKHznjHAmg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=L2hh3pxQ/hXLeyf2/sw+1yzAlgF4GHzzjMssEU1K0RE=; b=haWumOT5DZwCNL9qfAvOajWaqJSKOfEGIBQdWa8JJ2PBpQoyl4+fZQQiGQDIKOIDjj BXSbgiCNVxYZspNdyCGVpI642YHfI2lPj5i5lLGnu/2IoMCRwoL5T5gYOauI7pjoKlYM 6R/sX7p3qVgEsjShy0GksRbZx/fUw3YtMfB23/i/PuOG4doDGQ0YoxzmirdRb7sqQVWH 6i2IUWUypm1h5hpZTSY3zbJx2GZcDHgZKFfac7YMELVSIHAg9pRWCjMLRrT4jGFATQ9h +NG3jX5qpjp87zUDjOEXSE8JoqsHtAKvpbuc+x60cGcgPIpaMGlYR847SdxdAdc6e3uo FAOg== X-Gm-Message-State: ANhLgQ3lLINVibmM1gwNTN7MQ71TuvSqY45bPITURJ+ZXwHC3TLsrAVy ncUro4kePil29GBu2beGQJKM6fqQUo8= X-Google-Smtp-Source: ADFU+vsYHfglwi2WBWmW6xTIQzIsdyPSXEC6UnezXBorc8PqwBqbZZadbysYFSigF50JcwIZSxIseg== X-Received: by 2002:a37:6411:: with SMTP id y17mr4776223qkb.437.1585165547109; Wed, 25 Mar 2020 12:45:47 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id v19sm18132582qtb.67.2020.03.25.12.45.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 12:45:46 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> Date: Wed, 25 Mar 2020 15:45:45 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 19:45:51 -0000 hi WPACK, The chairs have had some success with using GitHub repos for WGs, but = whether we set one up is a WG decision. So, if there are objections to = use establishing a WG repo please let us know 2359 UTC 27 March 2020 and = please state why. Thanks, Dave and Sean= From nobody Wed Mar 25 13:48:43 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5663A0D6A for ; Wed, 25 Mar 2020 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RjbktN2eK5ZN for ; Wed, 25 Mar 2020 13:48:15 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36813A0E05 for ; Wed, 25 Mar 2020 13:47:56 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id w9so1545993pjh.1 for ; Wed, 25 Mar 2020 13:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=X5ELF4jnDeXbCpmNO/DpiWz7BG/AoB+0bkQItbZfZtw=; b=PP2cixM5w4/rPfsEXXFXZKhMWh5ypwmgNZYbcA9dJL2xcMJKn9IIB5lvxr5CSj1Flv KZCTCO6I0+aLUYT5mMrKCX/MhFaaakRtUZbsbFOOKm9Us4h5oUrICk1MwIqpsQY8hPgS JqsMtimzH7zfDs5MjydL8vEkHp1VVGV7t3uETRXL56XUqEMVZQ1YKNExgr6Lg9t+6XXY n2RHG/dOLbCmJoy1NeoxUr0x7liHRkA1dOH07UOkBKnGQAxJB7BcpZ/tSVBt3Umu++3y 0zcaL3GyKTrqrBF6lclFdX4Bqzxh5of5EVvLT1KHTeq0F0oGznxaAGjP5NbjqTkZaVS3 mFCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=X5ELF4jnDeXbCpmNO/DpiWz7BG/AoB+0bkQItbZfZtw=; b=HD04bBjwhY0wGnV9rwLjPcS+1R8quQswUH8kJxNgecI7dYEM6tmfmCnuF6/MN7V6u3 gGhVLJAQGZ0oZgovTdh3kVhc6A50U4/4iB3BlwzsTho5G6So9x65bCtSEaIlfHOQiLT7 y6pJ9mhP1lT3qji1vJJf77HavjNMolzlHD4rjUMoxnn6nyMM93DBKr46qZE77gR1sZQz cXUtK097+DpinQnsDmMPv7+fos5hRL4ghgALTaap/RMxE9MaNMIupbyUp+h6yXtprr5E 8Hwxt664wW24zTyn8GEQiH3u1wSxVhcDFDdOqKdG9y+/kFEFcKMAp/nqZ/93T/uPYDgg WJeg== X-Gm-Message-State: ANhLgQ2uTK/Xqo1YvBAuKLPRF1ie0huJdlnGJL9hctxch7P2slxHSw0G r9IW5YdXjUV84JOeVM+eygVYqGbG X-Google-Smtp-Source: ADFU+vtebGb7UYFcDFJvBYjRYVvrjDLUZzcj12sfjp1xn6fj8MF/YYXNtTO4iMNElX8W6mL9QEGzxg== X-Received: by 2002:a17:90a:1a43:: with SMTP id 3mr5695189pjl.35.1585169275150; Wed, 25 Mar 2020 13:47:55 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id f6sm30563pfk.99.2020.03.25.13.47.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 13:47:54 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Sean Turner'" , "'WPACK List'" References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> In-Reply-To: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> Date: Wed, 25 Mar 2020 13:47:54 -0700 Message-ID: <024201d602e6$a8afde80$fa0f9b80$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEM67UzIqgh1ZbNVvz9bahXlI6eO6nr78JQ Content-Language: en-us Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 20:48:20 -0000 I think relying on GitHub Issues and responses might work out fine for a close knit group that is solving a narrow problem. It's appropriate for a design team or a repo shared by a few document editors to coordinate their work. It's difficult to get a sense of working group status and topics of interest and controversy by trying to delve into GitHub activities. The main reason that there's a BOF at an IETF meeting and forming a working group in the IETF (rather than through WHATWG) is to get broader review from people who aren't following the work day to day. Personally, I'd like to see the working group take on as part of its charter the possible replacement of MIME multipart (mutlipart/related for MHTL, multipart/form-data) and also for PDF (a package of content independently assembled by a sender and signable as a package). > -----Original Message----- > From: Wpack On Behalf Of Sean Turner > Sent: Wednesday, March 25, 2020 12:46 PM > To: WPACK List > Subject: [Wpack] WPACK GitHub Repo? > > hi WPACK, > > The chairs have had some success with using GitHub repos for WGs, but > whether we set one up is a WG decision. So, if there are objections to use > establishing a WG repo please let us know 2359 UTC 27 March 2020 and > please state why. > > Thanks, > Dave and Sean > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Wed Mar 25 15:06:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BDF3A0D5A for ; Wed, 25 Mar 2020 15:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 gXyfFZrIzYmB for ; Wed, 25 Mar 2020 15:06:46 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382E93A0CC5 for ; Wed, 25 Mar 2020 15:06:46 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id a81so4930923wmf.5 for ; Wed, 25 Mar 2020 15:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sNOrWCGtOldinx4dcm4ud+e4ZoRfQ78xVrTI/vxNLck=; b=m3QnZGTY9m4RFOOiadlrpMNKUlS+Bl1FUo6XrYU9AjqQH3wtZhPWqsieoCrKYVMLC/ w1aANZ1pbDWzz3ob6BW7/YxbTxMK9ooS3if6QDIEcp24EO1zqPRRot3ngDwD2mLyM1hj 3iLAWxfTrM8ldFuaOnKAPz+OGuTYY/P2gaVr1DyHPRRJeauHPyWV505wofyefx6NG80L Uj03E+4D9hGzWlzkW6qoVBxMes/1KF/tuejo/ooJ7bdAySWRVlKWhIcCPctQw9f9INPK 79QQ3STRNiFd1J6KADtidXXGSmZrTaqn8XYSO5uT74FnA062TcrC3IuCbiwx8A7u/BXi gi2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sNOrWCGtOldinx4dcm4ud+e4ZoRfQ78xVrTI/vxNLck=; b=GFfcKP1ZfH28fWLdl6SWCHYGcnMxoQYMwtWJ8GECB42QrmO0kWlrK1PQiRLIHAaBuj lc+xIS0+DnWX1w51z/3hWEic+g2MXVqt8q4QduEiVOecSBLcItCsdq8F5p/kTh6xSgIt p40takDkvk54tr4ghEsYTo1k84bQ1h0qr36FllLfJSjUUHstnk029XnoL30u4JSIpOP+ opb82wlfOfnQHSxLJx5d4EyIyYKP9r+7QlVmv94tx14Vk4h0T6tt3LrNZlr+SuocWIQy Q/hBt4kx3fpOAMnwUNsX+6lKZaMWWPWO8yAA1aXWcEHY2MLKeAOwoN1c4fr7OYs2qYxG ePOQ== X-Gm-Message-State: ANhLgQ2fJV8PzthvC5TEsRrDND3masp5gt/S1efdMYJ73XRZW61mD9DU LDnlAg2lO8BT/mnhC5hQLbqTtiM7zgk/Z71Bnne553ab X-Google-Smtp-Source: ADFU+vtP3MpecRMwQL1oQQxyl1CDYL7epIZodm/pyjnQTzcbWJHhqDAZLa0fPZLbKz3AedlgDaQoa8oeTbvnQQS5nt8= X-Received: by 2002:a1c:81:: with SMTP id 123mr5262896wma.97.1585174003738; Wed, 25 Mar 2020 15:06:43 -0700 (PDT) MIME-Version: 1.0 From: Ben Schwartz Date: Wed, 25 Mar 2020 18:06:31 -0400 Message-ID: To: wpack@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000071985705a1b51590" Archived-At: Subject: [Wpack] Security, authority, and privacy X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 22:06:48 -0000 --00000000000071985705a1b51590 Content-Type: multipart/alternative; boundary="00000000000066f82005a1b515da" --00000000000066f82005a1b515da Content-Type: text/plain; charset="UTF-8" It seems to me that there are two main kinds of permission that concern us here. 1. Permission to display content as the origin. 2. Permission to perform I/O while acting as the origin. I think we should accept signed exchanges as sufficient for #1 before online verification completes, but require online verification for #2. This tightly limits any stolen key or stale content attack: the attacker can impersonate the origin until online verification completes, but cannot do much damage during that period. (This is not a comment on implementation, which could be similar to Martin Thomson's proposal, or not.) In this model, we would queue all pending I/O until verification completes. (The relevant APIs should all be asynchronous). This isn't compatible with every use case we have, but it covers most of them. "Early actions" and the corresponding state transfer could be added later if needed, but I think tackling that topic now would likely delay the standards process considerably. I also think most use cases would prefer that I/O simply be queued, so the state-transfer system should be clearly opt-in, only for the most sophisticated developers. --Ben Schwartz --00000000000066f82005a1b515da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that there are two main kinds of permission= that concern us here.

1. Permission to display content = as the origin.
2. Permission to perform I/O while acting as the o= rigin.

I think we should accept signed exchanges a= s sufficient for #1 before online verification completes, but require onlin= e verification for #2.=C2=A0 This tightly limits any stolen key or stale co= ntent attack: the attacker can impersonate the origin until online verifica= tion completes, but cannot do much damage during that period.
(This is not a comment on implementation, which could be simila= r to Martin Thomson's proposal, or not.)

In th= is model, we would queue all pending I/O until verification completes.=C2= =A0 (The relevant APIs should all be asynchronous).=C2=A0 This isn't co= mpatible with every use case we have, but it covers most of them.

"Early actions" and the corresponding state trans= fer could be added later if needed,=C2=A0but I think tackling that topic no= w would likely delay the standards process considerably.=C2=A0 I also think= most use cases would prefer that I/O simply be queued, so the state-transf= er system should be clearly opt-in, only for the most sophisticated develop= ers.

--Ben Schwartz
--00000000000066f82005a1b515da-- --00000000000071985705a1b51590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCAPXupNlB9gRw+61MlMPMnFb6/gs/gixWmbWE+duQJ3GjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjUyMjA2NDRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAugpd/PVcehw351cGyJy9y1PZD7zjYtFxRwjPk8TLyCtfawjfk/bgiipR2Jijwr/huGeGC0Ee X4HLJMLf3fZkrA4ZndKHULZK7F4vutZvuU5+hn/K6tzkj42rEJJwRYeV3+rYHDC5e3tWkDyLQhLJ ucpUNTHR+/WwmO7hMeeko4d6UOFxk638DVEaAQnJq4yloDQRBSU/io79L3q/RunIeNEkMB0d8WLs gf4lnhmnAuhLAMczesEvPZcN+M6i3pQtHa+5KXpJ991oqGDDv2dwZlYrXkOIslYl/bWqCp5bmN6O zabYG4HHNLgpsujQg/aZFqQoEmjnu3JzIxTAvLItPw== --00000000000071985705a1b51590-- From nobody Wed Mar 25 16:06:08 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82443A00D5 for ; Wed, 25 Mar 2020 16:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0nYtUdr-4KeB for ; Wed, 25 Mar 2020 16:05:55 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D99E3A0E18 for ; Wed, 25 Mar 2020 16:04:13 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id m3so5113466wmi.0 for ; Wed, 25 Mar 2020 16:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHfB165DRx7m0D44kdyA0qv4oF7MTEIDV5m06soMXHg=; b=pZVUjXd2DI0AHDGv04acU4KJT2yjXPq4sOXEjsKLaKzJaTtUY3v/eugF6L9R5e7kTT AcN6z82eR7oXiScfT++QZAvxUJXj8QISFvFz7q21VooGsszBzs3KsV2FbFXbrZHCOrWk JLuxygrsL24ID6apQ/Oj+KGrx2kJYI5bh/rUr5aVMJuLei0EKpTEB6eL7T/Jxp8mGMKs NpclIaWllrBbU0VlXKmoCLO5Ldm+aPO3clYZMSsXAA/bGEivwxVRhhFuhSPnutMFj4xI uy6g/1jNQjd4OgaY2uCsBoOCs/PnhY0ppgbyA32ukIZzs/OnD6o/ROzyNI8/Ieh8aZ/a RWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHfB165DRx7m0D44kdyA0qv4oF7MTEIDV5m06soMXHg=; b=thie6J3SX8kepZ7NqwwKuvXYsElB8szyU/rfjdbk+iK6x+l34KMRGX/d6pM5DehiL2 Pu7EtcEdrbgcgkhokUPhL3P2qHh7rXgn5lb743zl1tvyE+0gXgXJOhIkZUdQ6SRFSrDN A56Ovkmb3nChiass7HuYbfRwQFR1TppDV0A977VkpR7W6H722pvgnSmgA2AZ9MrLVB9J lzJ2kLeoJfdoxr1PZz5eBZAbn6u7Dm4TvmrCFtqg7HNZBmJFbMabDinwnPQ53ggxXz7b CLLNAlvrRbOhx+VMkkaME2rhstxo0F7/mrwhTH+Io5RG4T0KCKbKRbZfjeiQuzDVOAvX PXrw== X-Gm-Message-State: ANhLgQ1NFR4g/JQzClniq0hia+9vTJlFvLy1mwAuM1FoVEegkYzSFjwH KkSwg7EUZKBz58Vfc7ITbudno5mlHZtBGzXFfoLy5Ggx0aw= X-Google-Smtp-Source: ADFU+vsKkBAKk0I7+SwnUiqgHvdonImzTwwQiCEsTEvGVdWCJ2aUyJT4kJ8nzi4A6+kl6nJ+hqAYP0pmpLY2E21xt1w= X-Received: by 2002:a1c:f409:: with SMTP id z9mr6026493wma.51.1585177449810; Wed, 25 Mar 2020 16:04:09 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Devin Mullins Date: Wed, 25 Mar 2020 16:03:42 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000cdaa3905a1b5e221" Archived-At: Subject: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 23:06:06 -0000 --000000000000cdaa3905a1b5e221 Content-Type: text/plain; charset="UTF-8" In light of my comment about racing the Sec-CO request, a colleague pointed out a potential hole in the double-hash scheme. There may be flaws in below; I haven't thought about it too much. It may be worth more clearly defining the threat model. The publisher could delay responding to the Sec-CO request. In the interim, the page could send its own hash to //publisher.example/this-is-my-hash. Then the publisher would respond with the preimage sent by the bundle. This requires: A way for the bundle to get its own hash. Ideas: 1. document.location -- we could fix the ni scheme to be based on the double-hash 2. a fetch of distributor.example/what-is-the-hash-of-referer 3. compute client-side based on document.body, in which the publisher could also include an encoding of the headers 4. somebody computes the fixmanifold of a hash function -- is that a thing? i can't math [1] A way for the publisher to associate the this-is-my-hash request with the Sec-CO request. Ideas: 1. IP+timestamp 2. a token as a query param to both requests This depends on the publisher server to have an ability that most don't have, but it wouldn't be hard to purpose-build a server that only handled this-is-my-hash and Sec-CO requests. By segregating its workload from the other content requests, it would be easier to scale -- its need for session-stickiness or regional storage wouldn't affect latency of the edge-serving of normal content. Overall, this still requires more effort than responding `Sec-CO: yes`, but possibly less than a distributor/publisher backchannel. Also, possibly immune to IP privacy depending on above. I hope first that my above napkin sketch is wrong, and secondly that the fix for this isn't deferral of all requests until post-transfer. My guess is that would harm performance of the instant navigation use case. One possible mitigation is deferral of all on-origin requests. Then there needs to be a backchannel between the this-is-my-hash origin and the state transfer origin. This is maybe vaguely isomorphic to the distributor/publisher backchannel? Not really, since subdomains. The publisher could easily CNAME sec-co.publisher.example to sec-co.distributor.example. Actually, I wonder if CNAME is an issue regardless of everything above. https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00#section-5.1 states the UA must follow redirects. The publisher could easily encode a redirect from publisher.example/foo to sec-co.publisher.example/foo, and then CNAME to the distributor, and let the distributor respond with its known preimage. [1] "fixmanifold" being vaguely an extension of a fixpoint. A function f(x) s.t. for all x, hash(concat(x, f(x)) == f(x). Then the bundle could encode its own hash. On Tue, Mar 24, 2020 at 11:35 PM Devin Mullins wrote: > Hi Martin, > > Thanks for the engineering work on this. For others, I've already reviewed > this, had some chats with others on the AMP team, and had a few > back-and-forths with Martin (he's been very gracious in engaging his time, > thank you). I'm trying to estimate the feasibility of this, both for the > AMP use-case, and for the non-AMP use-case [1], which we hope to see > flourish to the extent that publishers and users desire it, and only > impeded by implementation costs where necessary for the common good. > > With the caveat that this is very early feedback, the high-level bit is > that, with some modifications, it seems mostly feasible for AMP. However, > there are two main downsides: > 1. worse UX on sites that run A/B experiments > 2. technical constraints make this harder for publishers to adopt on > non-AMP, as compared to SXG > > A lot of details follow. I suggest to rename the subject if you reply to a > detail below, in order to reduce cross-talk and make browsing the archive > easier. > > Details: > > We would need the display URL to be the attested URL even before transfer. > I suspect a flash in the URL bar would be frustrating for both users and > publishers. Jeffrey had proposed using signatures for this. I'd suppose UAs > could choose to render this with a "may be stale" indicator. > > In terms of publisher implementation feasibility, I think the mostly > likely implementation would be for a publisher to produce a > Sec-Content-Origin (Sec-CO) response for the current version of the > resource iff it matches the Sec-CO request. I suspect that keeping state of > past versions of the resource would be infeasible, especially as it > couldn't be done purely at the edge; it would require something like a > region-wide cache. The value of the above stateless implementation would be > inversely proportional to how often the resource changes (e.g. "transient > content" [2] such as Related Articles). I think this would be a workable > constraint for publishers wishing to publish such bundles, but felt it's > worth noting, nonetheless. > > Re: fallback behavior on failed state transfer, distributors would need a > way to monitor failure rates. This serves two purposes: > 1. Automatically detecting errors in the distribution pipeline. This is > the same purpose served by > https://wicg.github.io/webpackage/loading.html#signed-exchange-report. > 2. Verifying that, for some fraction of navigations, bundles are meeting > AMP's stated UX goals (by using the verified content in the bundle and not > potentially arbitrary content after the redirect). This is a dynamic > equivalent of what can be done mostly statically with SXG, because the > distributor can run the same algorithm as the UA, modulo client/server skew > in clocks and root stores. I think this is a trade-off AMP could make. The > alternative is that the fallback behavior keeps the content-based origin > (CBO). > > There is a possible vector for user ID transfer from distributor to > publisher; filed as > https://github.com/martinthomson/wpack-content/issues/1. > > This limits the ability to run session-sticky experiments (in > https://amp.dev/documentation/components/amp-experiment/ and many non-AMP > frameworks). The publisher has the following options: > 1. Delay rendering content under experiment until after state transfer. > This hurts UX for the sake of experimentation, creating a trade-off that > otherwise doesn't exist on origin (modulo ease of implementation). > 2. Generate a client-side UUID before state transfer, and join it with > the pre-existing user ID after transfer. This means the session could not > include CBO pageviews anywhere except in the first pageview. > 3. Generate variants of the bundle for each experimental state. The > distributor chooses which bundle to send to the user (based on what? not > sure). For a page with M independent experiments each with N arms, that's > N^M variants. For large enough M and N, this is likely both infeasible for > publishers and martinthomson/wpack-content#1. (But I need some guidance > from experts on typical ranges for M and N.) > > Perhaps this is a need the UA could address. A straw proposal -- a > selectExperimentArm() API that: > 1. only exposes as many bits as the UA deems OK, and > 2. exposes different bits to different attested origins, so they can't > be joined > On the one hand, perhaps this is too much scope for wpack. On the other, > it addresses a problem that is somewhat particular to CBOs. > > This impedes content management (e.g. dialogs for GDPR and CCPA), compared > to SXG. The publisher has a few choices: > 1. Delay rendering the dialog under after transfer. I think this would > cause layout shift (https://web.dev/cls/). > 2. Render the dialog, and risk discovering that it's already been > acknowledged. At that point: > a. Hide it, causing layout shift. > b. Leave it there. This is way outside my domain expertise, but ISTR > there are some rules or at least best practices wrt when it's okay to > re-show an opt-out dialog. > One of these options may be an okay trade-off; I'm not sure. > > Analytics providers (via > https://amp.dev/documentation/components/amp-analytics/ and many non-AMP > libraries) would have to do one of two things: > 1. Delay pingback until after transfer. This risks a lower fraction of > successful pingbacks, as e.g. the user might close the tab before transfer. > 2. Generate a client-side UUID, send pingback before transfer, and send > a follow-up after transfer to join with pre-existing user ID. This captures > those otherwise lost pingbacks pseudonymously (anonymously?), though it > requires server-side work on the pingback endpoint. > > For the above client-side mitigations, two feature requests seem necessary: > 1. Store the transfer metadata (e.g. indexedDB renames by time) > somewhere more permanent. For various reasons the event handler may not > fire or finish, and it would be good to later scan for stragglers to merge > or expunge. > 2. DOM API to wait for transfer to complete. > > Some subresources are ACLs by Origin header (e.g. paid fonts). Likely > mitigation is to defer loading until transfer, with a timeout whose > duration depends on the publisher's font-display preference. (Martin > suggests an optimization where the encrypted subresource is loaded early, > and only the decryption key after transfer.) > > Last but not least, I am concerned that this is a bar that is > disproportionately difficult for non-AMP publishers to meet. The above > client-side mitigations are possible, but quite a bit of work. > 1. For frameworks like AMP that strongly encourage publishers to use a > rolling release, it is possible to upgrade many use-cases in the wild with > minimal publisher effort. > 2. For other frameworks, it may be possible to provide this support, but > the requirement to upgrade versions may limit applicability. Because > upgrades occur less often, they often require more work. > 3. For custom JS that manages state, authors will need to modify it to > move or copy state into indexedDB, and handle transfer events and merge > conflicts. > > From a "minimal publisher effort" perspective, I am especially interested > in making it possible to have as close to a turnkey solution as is > reasonable, for instance at the level of the CDN or CMS. If such a solution > exists, sites would likely contain a hybrid of all three cases above, and > thus want to opt into such support incrementally. How should a CDN > determine which pages to provide Sec-CO responses for? > 1. URL patterns are the simplest answer, but I suspect hard for > publishers to create and maintain with minimal false negatives and > positives. > 2. Would it be helpful to thread an "I support state transfer" > annotation for some portion of the build journey, from individual JS > function all the way to bundle? Would folks use this? > > I don't have a good solution to the issue of non-AMP developer cost, and > thus fear this is a solution that would feature a disproportionate amount > of AMP pages compared to the background distribution of the web. But I'm > hopeful that other JS framework developers can chime in with respect to > feasibility of support for CBO and state transfer. > > I'm leaving out some of Martin's replies to the above; no offense > intended. It took me long enough just to summarize the above, and I'd > better send it early enough so at least a few people have time to read it > before the meeting. > > Thanks, > Devin > > [1] > https://blog.amp.dev/2019/05/22/privacy-preserving-instant-loading-for-all-web-content/ > [2] > http://www.seobythesea.com/2011/12/how-google-might-identify-transient-content-on-webpages/ > > On Mon, Mar 23, 2020 at 5:35 PM Martin Thomson wrote: > >> Ted's note prompted me to send a much-belated announcement (sorry folks, >> I forgot). >> >> The draft is here: >> https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 >> >> A nicer version here: >> >> https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html >> >> This approach could a dramatically different approach to addressing the >> use cases set out in our charter. >> >> In short, this aims to address the core question of how offline content >> might *ultimately* be attributed to a web origin in a fundamentally >> different way. There are two key concepts: >> >> 1. Content is given its own origin, using a new system for identification. >> >> 2. A target origin can "accept" content and state from one of these new >> origins. >> >> There are a lot of details here (read the draft), but the major advantage >> I see is that you don't have to make an offline decision about authority, >> and that means you can be offline for much longer (lifting the 7 day limit). >> >> What it does have in common with signed exchanges approach is the need >> for a bundling format, but in its current form it is less dependent on the >> details of the format. That might allow that to be simpler, but I'm sure >> that the need to mint new identifier types will more than make up for any >> slack there. >> >> The draft is quite rough. I'm sure that it has the remnants of a few bad >> ideas still hanging around. Ask questions if you think something is >> unclear. >> >> _______________________________________________ >> Wpack mailing list >> Wpack@ietf.org >> https://www.ietf.org/mailman/listinfo/wpack >> > --000000000000cdaa3905a1b5e221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In light of my comment about racing the S= ec-CO request, a colleague pointed out a potential hole in the double-hash = scheme. There may be flaws in below; I haven't thought about it too muc= h. <trite tone=3Dapologetic>It may be worth more clearly defining the= threat model.</trite>

The publisher could delay r= esponding to the Sec-CO request. In the interim, the page could send its ow= n hash to //publisher.example/this-is-my-hash. Then the publisher would res= pond with the preimage sent by the bundle. This=C2=A0requires:
A way for the bundle to get its own hash. Ideas:
  • document.location -- we could fix the ni scheme to be based on the dou= ble-hash
  • a fetch of distributor.example/what-is-the-hash-of-referer=
  • compute client-side based on document.body, in which the publisher= could also include an encoding of the headers
  • somebody computes th= e fixmanifold of a hash function -- is that a thing? i can't math [1]
    • A way for the publisher to associate the this-is-my-hash= request with the Sec-CO request. Ideas:
    1. IP+timestamp
    2. a token as a query param to both requests
    This dep= ends on the publisher server to have an ability that most don't have, b= ut it wouldn't be hard to purpose-build a server that only handled this= -is-my-hash and Sec-CO requests. By segregating its workload from the other= content requests, it would be easier to scale -- its need for session-stic= kiness or regional storage wouldn't affect latency of the edge-serving = of normal content.

    Overall, this still requires mo= re effort than responding `Sec-CO: yes`, but possibly less than a distribut= or/publisher backchannel. Also, possibly immune to IP privacy depending on = above.

    I hope first that my above napkin sketch is= wrong, and secondly that the fix for this isn't deferral of all reques= ts until post-transfer. My guess is that would harm=C2=A0performance of the= instant navigation use case.

    One possible mitigat= ion is deferral of all on-origin requests. Then there needs to be a backcha= nnel between the this-is-my-hash origin and the state transfer origin. This= is maybe vaguely isomorphic to the distributor/publisher backchannel? Not = really, since subdomains. The publisher could easily CNAME sec-co.publisher= .example to sec-co.distributor.example.

    Actually, = I wonder if CNAME is an issue regardless of everything above.=C2=A0https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00#s= ection-5.1 states the UA must follow redirects. The publisher could eas= ily encode a redirect from publisher.example/foo to sec-co.publisher.exampl= e/foo, and then CNAME to the distributor, and let the distributor respond w= ith its known preimage.

    [1] "fixmanifold"= ; being vaguely an extension of a fixpoint. A function f(x) s.t. for all x,= hash(concat(x, f(x)) =3D=3D f(x). Then the bundle could encode its own has= h.

    On Tue, Mar 24, 2020 at 11:35 PM Devin Mullins <twifkak@google.com> wrote:
    Hi Martin,

    = Thanks for the engineering work on this. For others, I've already revie= wed this, had some chats with others on the AMP team, and had a few back-an= d-forths with Martin (he's been very gracious in engaging his time, tha= nk you). I'm trying to estimate the feasibility of this, both for the A= MP use-case, and for the non-AMP use-case [1], which we hope to see flouris= h to the extent that publishers and users desire it, and only impeded by im= plementation costs where necessary for the common good.

    With the cav= eat that this is very early feedback, the high-level bit is that, with some= modifications, it seems mostly feasible for AMP. However, there are two ma= in downsides:
    =C2=A0 1. worse UX on sites that run A/B experiments
    = =C2=A0 2. technical constraints make this harder for publishers to adopt on= non-AMP, as compared to SXG

    A lot of details follow. I suggest to r= ename the subject if you reply to a detail below, in order to reduce cross-= talk and make browsing the archive easier.

    Details:

    We would = need the display URL to be the attested URL even before transfer. I suspect= a flash in the URL bar would be frustrating for both users and publishers.= Jeffrey had proposed using signatures for this. I'd suppose UAs could = choose to render this with a "may be stale" indicator.

    In = terms of publisher implementation feasibility, I think the mostly likely im= plementation would be for a publisher to produce a Sec-Content-Origin (Sec-= CO) response for the current version of the resource iff it matches the Sec= -CO request. I suspect that keeping state of past versions of the resource = would be infeasible, especially as it couldn't be done purely at the ed= ge; it would require something like a region-wide cache. The value of the a= bove stateless implementation would be inversely proportional to how often = the resource changes (e.g. "transient content" [2] such as Relate= d Articles). I think this would be a workable constraint for publishers wis= hing to publish such bundles, but felt it's worth noting, nonetheless.<= br>
    Re: fallback behavior on failed state transfer, distributors would n= eed a way to monitor failure rates. This serves two purposes:
    =C2=A0 1. = Automatically detecting errors in the distribution pipeline. This is the sa= me purpose served by https://wicg.github.io/webpac= kage/loading.html#signed-exchange-report.
    =C2=A0 2. Verifying that, = for some fraction of navigations, bundles are meeting AMP's stated UX g= oals (by using the verified content in the bundle and not potentially arbit= rary content after the redirect). This is a dynamic equivalent of what can = be done mostly statically with SXG, because the distributor can run the sam= e algorithm as the UA, modulo client/server skew in clocks and root stores.= I think this is a trade-off AMP could make. The alternative is that the fa= llback behavior keeps the content-based origin (CBO).

    There is a pos= sible vector for user ID transfer from distributor to publisher; filed as <= a href=3D"https://github.com/martinthomson/wpack-content/issues/1" target= =3D"_blank">https://github.com/martinthomson/wpack-content/issues/1.
    This limits the ability to run session-sticky experiments (in https://amp.dev/documentation/components/amp-experiment/ and many = non-AMP frameworks). The publisher has the following options:
    =C2=A0 1. = Delay rendering content under experiment until after state transfer. This h= urts UX for the sake of experimentation, creating a trade-off that otherwis= e doesn't exist on origin (modulo ease of implementation).
    =C2=A0 2.= Generate a client-side UUID before state transfer, and join it with the pr= e-existing user ID after transfer. This means the session could not include= CBO pageviews anywhere except in the first pageview.
    =C2=A0 3. Generate= variants of the bundle for each experimental state. The distributor choose= s which bundle to send to the user (based on what? not sure). For a page wi= th M independent experiments each with N arms, that's N^M variants. For= large enough M and N, this is likely both infeasible for publishers and ma= rtinthomson/wpack-content#1. (But I need some guidance from experts on typi= cal ranges for M and N.)

    Perhaps this is a need the UA could address= . A straw proposal -- a selectExperimentArm() API that:
    =C2=A0 1. only e= xposes as many bits as the UA deems OK, and
    =C2=A0 2. exposes different = bits to different attested origins, so they can't be joined
    On the o= ne hand, perhaps this is too much scope for wpack. On the other, it address= es a problem that is somewhat particular to CBOs.

    This impedes conte= nt management (e.g. dialogs for GDPR and CCPA), compared to SXG. The publis= her has a few choices:
    =C2=A0 1. Delay rendering the dialog under after = transfer. I think this would cause layout shift (https://web.dev/cls/).
    =C2=A0 2. Render the= dialog, and risk discovering that it's already been acknowledged. At t= hat point:
    =C2=A0 =C2=A0 a. Hide it, causing layout shift.
    =C2=A0 =C2= =A0 b. Leave it there. This is way outside my domain expertise, but ISTR th= ere are some rules or at least best practices wrt when it's okay to re-= show an opt-out dialog.
    One of these options may be an okay trade-off; I= 'm not sure.

    Analytics providers (via https://amp.dev= /documentation/components/amp-analytics/ and many non-AMP libraries) wo= uld have to do one of two things:
    =C2=A0 1. Delay pingback until after t= ransfer. This risks a lower fraction of successful pingbacks, as e.g. the u= ser might close the tab before transfer.
    =C2=A0 2. Generate a client-sid= e UUID, send pingback before transfer, and send a follow-up after transfer = to join with pre-existing user ID. This captures those otherwise lost pingb= acks pseudonymously (anonymously?), though it requires server-side work on = the pingback endpoint.

    For the above client-side mitigations, two fe= ature requests seem necessary:
    =C2=A0 1. Store the transfer metadata (e.= g. indexedDB renames by time) somewhere more permanent. For various reasons= the event handler may not fire or finish, and it would be good to later sc= an for stragglers to merge or expunge.
    =C2=A0 2. DOM API to wait for tra= nsfer to complete.

    Some subresources are ACLs by Origin header (e.g.= paid fonts). Likely mitigation is to defer loading until transfer, with a = timeout whose duration depends on the publisher's font-display preferen= ce. (Martin suggests an optimization where the encrypted subresource is loa= ded early, and only the decryption key after transfer.)

    Last but not= least, I am concerned that this is a bar that is disproportionately diffic= ult for non-AMP publishers to meet. The above client-side mitigations are p= ossible, but quite a bit of work.
    =C2=A0 1. For frameworks like AMP that= strongly encourage publishers to use a rolling release, it is possible to = upgrade many use-cases in the wild with minimal publisher effort.
    =C2=A0= 2. For other frameworks, it may be possible to provide this support, but t= he requirement to upgrade versions may limit applicability. Because upgrade= s occur less often, they often require more work.
    =C2=A0 3. For custom J= S that manages state, authors will need to modify it to move or copy state = into indexedDB, and handle transfer events and merge conflicts.

    From= a "minimal publisher effort" perspective, I am especially intere= sted in making it possible to have as close to a turnkey solution as is rea= sonable, for instance at the level of the CDN or CMS. If such a solution ex= ists, sites would likely contain a hybrid of all three cases above, and thu= s want to opt into such support incrementally. How should a CDN determine w= hich pages to provide Sec-CO responses for?
    =C2=A0 1. URL patterns are t= he simplest answer, but I suspect hard for publishers to create and maintai= n with minimal false negatives and positives.
    =C2=A0 2. Would it be help= ful to thread an "I support state transfer" annotation for some p= ortion of the build journey, from individual JS function all the way to bun= dle? Would folks use this?

    I don't have a good solution to the i= ssue of non-AMP developer cost, and thus fear this is a solution that would= feature a disproportionate amount of AMP pages compared to the background = distribution of the web. But I'm hopeful that other JS framework develo= pers can chime in with respect to feasibility of support for CBO and state = transfer.

    I'm leaving out some of Martin's replies to the ab= ove; no offense intended. It took me long enough just to summarize the abov= e, and I'd better send it early enough so at least a few people have ti= me to read it before the meeting.

    Thanks,
    Devin

    [1] https://blog.amp.dev/2019/05/22/privac= y-preserving-instant-loading-for-all-web-content/
    [2] http://www.seobythesea.com/2011/12/how-goo= gle-might-identify-transient-content-on-webpages/

    On Mon, Mar 23, 20= 20 at 5:35 PM Martin Thomson <mt@lowentropy.net> wrote:
    Ted's note prompted me to send a much-bel= ated announcement (sorry folks, I forgot).

    The draft is here:
    https://tools.ietf.org/html/draft-t= homson-wpack-content-origin-00

    A nicer version here:
    https://martint= homson.github.io/wpack-content/draft-thomson-wpack-content-origin.html<= br>
    This approach could a dramatically different approach to addressing the use= cases set out in our charter.

    In short, this aims to address the core question of how offline content mig= ht *ultimately* be attributed to a web origin in a fundamentally different = way.=C2=A0 There are two key concepts:

    1. Content is given its own origin, using a new system for identification.<= br>
    2. A target origin can "accept" content and state from one of the= se new origins.

    There are a lot of details here (read the draft), but the major advantage I= see is that you don't have to make an offline decision about authority= , and that means you can be offline for much longer (lifting the 7 day limi= t).

    What it does have in common with signed exchanges approach is the need for = a bundling format, but in its current form it is less dependent on the deta= ils of the format.=C2=A0 That might allow that to be simpler, but I'm s= ure that the need to mint new identifier types will more than make up for a= ny slack there.

    The draft is quite rough.=C2=A0 I'm sure that it has the remnants of a = few bad ideas still hanging around.=C2=A0 Ask questions if you think someth= ing is unclear.

    _______________________________________________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --000000000000cdaa3905a1b5e221-- From nobody Wed Mar 25 17:16:37 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E693A00C0 for ; Wed, 25 Mar 2020 17:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 w2sF4Enk-bru for ; Wed, 25 Mar 2020 17:16:31 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C103A07FC for ; Wed, 25 Mar 2020 17:16:30 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id d198so4782510wmd.0 for ; Wed, 25 Mar 2020 17:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aAnTSQqU1VV8/LAdEfVrJEsQa1LfRc0ZTfKJ1dL//1Q=; b=Hjk8Em6oIVHutVae+kL7tSXIChB4g+wbJsveHM3iVG047/9qz91Fyd+wmlM3gODhEL gMInL6J/7fS1BA4ckGAc4wW3Imcz6S5RbAUZVI56shlj5xiyMSPawryVn6z80daY+cgE OEFT48OURp2ayxSy8SxwHYLRPrwedKCe5B+l0iorTockd21SMIm9kCEgfVJsu6z+LPZF CitmnKw9M4EhozjpWjqmGfdX/MKtAH+uXK4NNmPWbw1FY4/9iHFKKTblDyJ4qzrfy6iy 8Q/dLygsL45xfVIugiv328zdQD5E+JBwMCG2g1FQEo3aIx9v2x1uy6hjVtQoKw451xY3 NkRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aAnTSQqU1VV8/LAdEfVrJEsQa1LfRc0ZTfKJ1dL//1Q=; b=klm368bTuQTpaNqfrD4nN2awfpb+I1X/cQtUETnkJucQe6lPY8n3kl2QxEfqVZ7esI AwbPi0m4gh36sItPhXwyHS+gqlX9eqoGzO/MIxuKd65n0Qyr00GxsHdN/cjvnQZWE3+v O+n4RtxMM5769rKWf6Itj18cA/H1aPjgp4Tn+hzAW9pKA0Hqe+KojInJ1XhfCiHx9uT3 ZX8q0nyoVTo5MG+a46Nq4RdQIUzwuBL/QsPVaCO0k4jzwsE1vOAjCIgd5ckZEB/Dompi QmlJKITeJ8ue/bbvhOWyD53hwqw65HdW/712PHg9MojcVheFNM48vqfiTctHF9azDktl ZNuA== X-Gm-Message-State: ANhLgQ3ucgGgUeBm2xlWaPDUGh+5O2kgkeFHXlTnbsMx/qp6AVIC+cO0 cNRBDq2Zlp0g/sY2iKU+n6sxHpi7YzRINyOv9LFdwxTu X-Google-Smtp-Source: ADFU+vtrY/YyteOer61wKkIvzcM1/yIF3flb+GXvob+OI/QUj4Yv2aj4g0HkLcu8Oj8ADm7cltzU6FkF4LDDjsACHfY= X-Received: by 2002:a05:600c:224d:: with SMTP id a13mr164077wmm.53.1585181788203; Wed, 25 Mar 2020 17:16:28 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Devin Mullins Date: Wed, 25 Mar 2020 17:16:02 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000645ffa05a1b6e555" Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 00:16:35 -0000 --000000000000645ffa05a1b6e555 Content-Type: text/plain; charset="UTF-8" Augh, I forgot that 30x responses change the attested URL. Ignore my comments about CNAME, I suppose. On Wed, Mar 25, 2020 at 4:03 PM Devin Mullins wrote: > In light of my comment about racing the Sec-CO request, a colleague > pointed out a potential hole in the double-hash scheme. There may be flaws > in below; I haven't thought about it too much. It > may be worth more clearly defining the threat model. > > The publisher could delay responding to the Sec-CO request. In the > interim, the page could send its own hash to > //publisher.example/this-is-my-hash. Then the publisher would respond with > the preimage sent by the bundle. This requires: > > A way for the bundle to get its own hash. Ideas: > > 1. document.location -- we could fix the ni scheme to be based on the > double-hash > 2. a fetch of distributor.example/what-is-the-hash-of-referer > 3. compute client-side based on document.body, in which the publisher > could also include an encoding of the headers > 4. somebody computes the fixmanifold of a hash function -- is that a > thing? i can't math [1] > > A way for the publisher to associate the this-is-my-hash request with the > Sec-CO request. Ideas: > > 1. IP+timestamp > 2. a token as a query param to both requests > > This depends on the publisher server to have an ability that most don't > have, but it wouldn't be hard to purpose-build a server that only handled > this-is-my-hash and Sec-CO requests. By segregating its workload from the > other content requests, it would be easier to scale -- its need for > session-stickiness or regional storage wouldn't affect latency of the > edge-serving of normal content. > > Overall, this still requires more effort than responding `Sec-CO: yes`, > but possibly less than a distributor/publisher backchannel. Also, possibly > immune to IP privacy depending on above. > > I hope first that my above napkin sketch is wrong, and secondly that the > fix for this isn't deferral of all requests until post-transfer. My guess > is that would harm performance of the instant navigation use case. > > One possible mitigation is deferral of all on-origin requests. Then there > needs to be a backchannel between the this-is-my-hash origin and the state > transfer origin. This is maybe vaguely isomorphic to the > distributor/publisher backchannel? Not really, since subdomains. The > publisher could easily CNAME sec-co.publisher.example to > sec-co.distributor.example. > > Actually, I wonder if CNAME is an issue regardless of everything above. > https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00#section-5.1 > states the UA must follow redirects. The publisher could easily encode a > redirect from publisher.example/foo to sec-co.publisher.example/foo, and > then CNAME to the distributor, and let the distributor respond with its > known preimage. > > [1] "fixmanifold" being vaguely an extension of a fixpoint. A function > f(x) s.t. for all x, hash(concat(x, f(x)) == f(x). Then the bundle could > encode its own hash. > > On Tue, Mar 24, 2020 at 11:35 PM Devin Mullins wrote: > >> Hi Martin, >> >> Thanks for the engineering work on this. For others, I've already >> reviewed this, had some chats with others on the AMP team, and had a few >> back-and-forths with Martin (he's been very gracious in engaging his time, >> thank you). I'm trying to estimate the feasibility of this, both for the >> AMP use-case, and for the non-AMP use-case [1], which we hope to see >> flourish to the extent that publishers and users desire it, and only >> impeded by implementation costs where necessary for the common good. >> >> With the caveat that this is very early feedback, the high-level bit is >> that, with some modifications, it seems mostly feasible for AMP. However, >> there are two main downsides: >> 1. worse UX on sites that run A/B experiments >> 2. technical constraints make this harder for publishers to adopt on >> non-AMP, as compared to SXG >> >> A lot of details follow. I suggest to rename the subject if you reply to >> a detail below, in order to reduce cross-talk and make browsing the archive >> easier. >> >> Details: >> >> We would need the display URL to be the attested URL even before >> transfer. I suspect a flash in the URL bar would be frustrating for both >> users and publishers. Jeffrey had proposed using signatures for this. I'd >> suppose UAs could choose to render this with a "may be stale" indicator. >> >> In terms of publisher implementation feasibility, I think the mostly >> likely implementation would be for a publisher to produce a >> Sec-Content-Origin (Sec-CO) response for the current version of the >> resource iff it matches the Sec-CO request. I suspect that keeping state of >> past versions of the resource would be infeasible, especially as it >> couldn't be done purely at the edge; it would require something like a >> region-wide cache. The value of the above stateless implementation would be >> inversely proportional to how often the resource changes (e.g. "transient >> content" [2] such as Related Articles). I think this would be a workable >> constraint for publishers wishing to publish such bundles, but felt it's >> worth noting, nonetheless. >> >> Re: fallback behavior on failed state transfer, distributors would need a >> way to monitor failure rates. This serves two purposes: >> 1. Automatically detecting errors in the distribution pipeline. This is >> the same purpose served by >> https://wicg.github.io/webpackage/loading.html#signed-exchange-report. >> 2. Verifying that, for some fraction of navigations, bundles are >> meeting AMP's stated UX goals (by using the verified content in the bundle >> and not potentially arbitrary content after the redirect). This is a >> dynamic equivalent of what can be done mostly statically with SXG, because >> the distributor can run the same algorithm as the UA, modulo client/server >> skew in clocks and root stores. I think this is a trade-off AMP could make. >> The alternative is that the fallback behavior keeps the content-based >> origin (CBO). >> >> There is a possible vector for user ID transfer from distributor to >> publisher; filed as >> https://github.com/martinthomson/wpack-content/issues/1. >> >> This limits the ability to run session-sticky experiments (in >> https://amp.dev/documentation/components/amp-experiment/ and many >> non-AMP frameworks). The publisher has the following options: >> 1. Delay rendering content under experiment until after state transfer. >> This hurts UX for the sake of experimentation, creating a trade-off that >> otherwise doesn't exist on origin (modulo ease of implementation). >> 2. Generate a client-side UUID before state transfer, and join it with >> the pre-existing user ID after transfer. This means the session could not >> include CBO pageviews anywhere except in the first pageview. >> 3. Generate variants of the bundle for each experimental state. The >> distributor chooses which bundle to send to the user (based on what? not >> sure). For a page with M independent experiments each with N arms, that's >> N^M variants. For large enough M and N, this is likely both infeasible for >> publishers and martinthomson/wpack-content#1. (But I need some guidance >> from experts on typical ranges for M and N.) >> >> Perhaps this is a need the UA could address. A straw proposal -- a >> selectExperimentArm() API that: >> 1. only exposes as many bits as the UA deems OK, and >> 2. exposes different bits to different attested origins, so they can't >> be joined >> On the one hand, perhaps this is too much scope for wpack. On the other, >> it addresses a problem that is somewhat particular to CBOs. >> >> This impedes content management (e.g. dialogs for GDPR and CCPA), >> compared to SXG. The publisher has a few choices: >> 1. Delay rendering the dialog under after transfer. I think this would >> cause layout shift (https://web.dev/cls/). >> 2. Render the dialog, and risk discovering that it's already been >> acknowledged. At that point: >> a. Hide it, causing layout shift. >> b. Leave it there. This is way outside my domain expertise, but ISTR >> there are some rules or at least best practices wrt when it's okay to >> re-show an opt-out dialog. >> One of these options may be an okay trade-off; I'm not sure. >> >> Analytics providers (via >> https://amp.dev/documentation/components/amp-analytics/ and many non-AMP >> libraries) would have to do one of two things: >> 1. Delay pingback until after transfer. This risks a lower fraction of >> successful pingbacks, as e.g. the user might close the tab before transfer. >> 2. Generate a client-side UUID, send pingback before transfer, and send >> a follow-up after transfer to join with pre-existing user ID. This captures >> those otherwise lost pingbacks pseudonymously (anonymously?), though it >> requires server-side work on the pingback endpoint. >> >> For the above client-side mitigations, two feature requests seem >> necessary: >> 1. Store the transfer metadata (e.g. indexedDB renames by time) >> somewhere more permanent. For various reasons the event handler may not >> fire or finish, and it would be good to later scan for stragglers to merge >> or expunge. >> 2. DOM API to wait for transfer to complete. >> >> Some subresources are ACLs by Origin header (e.g. paid fonts). Likely >> mitigation is to defer loading until transfer, with a timeout whose >> duration depends on the publisher's font-display preference. (Martin >> suggests an optimization where the encrypted subresource is loaded early, >> and only the decryption key after transfer.) >> >> Last but not least, I am concerned that this is a bar that is >> disproportionately difficult for non-AMP publishers to meet. The above >> client-side mitigations are possible, but quite a bit of work. >> 1. For frameworks like AMP that strongly encourage publishers to use a >> rolling release, it is possible to upgrade many use-cases in the wild with >> minimal publisher effort. >> 2. For other frameworks, it may be possible to provide this support, >> but the requirement to upgrade versions may limit applicability. Because >> upgrades occur less often, they often require more work. >> 3. For custom JS that manages state, authors will need to modify it to >> move or copy state into indexedDB, and handle transfer events and merge >> conflicts. >> >> From a "minimal publisher effort" perspective, I am especially interested >> in making it possible to have as close to a turnkey solution as is >> reasonable, for instance at the level of the CDN or CMS. If such a solution >> exists, sites would likely contain a hybrid of all three cases above, and >> thus want to opt into such support incrementally. How should a CDN >> determine which pages to provide Sec-CO responses for? >> 1. URL patterns are the simplest answer, but I suspect hard for >> publishers to create and maintain with minimal false negatives and >> positives. >> 2. Would it be helpful to thread an "I support state transfer" >> annotation for some portion of the build journey, from individual JS >> function all the way to bundle? Would folks use this? >> >> I don't have a good solution to the issue of non-AMP developer cost, and >> thus fear this is a solution that would feature a disproportionate amount >> of AMP pages compared to the background distribution of the web. But I'm >> hopeful that other JS framework developers can chime in with respect to >> feasibility of support for CBO and state transfer. >> >> I'm leaving out some of Martin's replies to the above; no offense >> intended. It took me long enough just to summarize the above, and I'd >> better send it early enough so at least a few people have time to read it >> before the meeting. >> >> Thanks, >> Devin >> >> [1] >> https://blog.amp.dev/2019/05/22/privacy-preserving-instant-loading-for-all-web-content/ >> [2] >> http://www.seobythesea.com/2011/12/how-google-might-identify-transient-content-on-webpages/ >> >> On Mon, Mar 23, 2020 at 5:35 PM Martin Thomson wrote: >> >>> Ted's note prompted me to send a much-belated announcement (sorry folks, >>> I forgot). >>> >>> The draft is here: >>> https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 >>> >>> A nicer version here: >>> >>> https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html >>> >>> This approach could a dramatically different approach to addressing the >>> use cases set out in our charter. >>> >>> In short, this aims to address the core question of how offline content >>> might *ultimately* be attributed to a web origin in a fundamentally >>> different way. There are two key concepts: >>> >>> 1. Content is given its own origin, using a new system for >>> identification. >>> >>> 2. A target origin can "accept" content and state from one of these new >>> origins. >>> >>> There are a lot of details here (read the draft), but the major >>> advantage I see is that you don't have to make an offline decision about >>> authority, and that means you can be offline for much longer (lifting the 7 >>> day limit). >>> >>> What it does have in common with signed exchanges approach is the need >>> for a bundling format, but in its current form it is less dependent on the >>> details of the format. That might allow that to be simpler, but I'm sure >>> that the need to mint new identifier types will more than make up for any >>> slack there. >>> >>> The draft is quite rough. I'm sure that it has the remnants of a few >>> bad ideas still hanging around. Ask questions if you think something is >>> unclear. >>> >>> _______________________________________________ >>> Wpack mailing list >>> Wpack@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpack >>> >> --000000000000645ffa05a1b6e555 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Augh, I forgot that 30x responses change the attested URL.= Ignore my comments about CNAME, I suppose.

    On Wed, Mar 25, 2020 at 4:03 PM = Devin Mullins <twifkak@google.com<= /a>> wrote:
    <= div dir=3D"ltr">
    In light of my comment about racing the Se= c-CO request, a colleague pointed out a potential hole in the double-hash s= cheme. There may be flaws in below; I haven't thought about it too much= . <trite tone=3Dapologetic>It may be worth more clearly defining the = threat model.</trite>

    The publisher could delay re= sponding to the Sec-CO request. In the interim, the page could send its own= hash to //publisher.example/this-is-my-hash. Then the publisher would resp= ond with the preimage sent by the bundle. This=C2=A0requires:
    A way for the bundle to get its own hash. Ideas:
      =
    1. document.location -- we could fix the ni scheme to be based on the doub= le-hash
    2. a fetch of distributor.example/what-is-the-hash-of-referer<= /li>
    3. compute client-side based on document.body, in which the publisher = could also include an encoding of the headers
    4. somebody computes the= fixmanifold of a hash function -- is that a thing? i can't math [1]
    A way for the publisher to associate the this-is-my-hash = request with the Sec-CO request. Ideas:
    1. IP+timestamp
      2. =
    2. a token as a query param to both requests
    This depe= nds on the publisher server to have an ability that most don't have, bu= t it wouldn't be hard to purpose-build a server that only handled this-= is-my-hash and Sec-CO requests. By segregating its workload from the other = content requests, it would be easier to scale -- its need for session-stick= iness or regional storage wouldn't affect latency of the edge-serving o= f normal content.

    Overall, this still requires mor= e effort than responding `Sec-CO: yes`, but possibly less than a distributo= r/publisher backchannel. Also, possibly immune to IP privacy depending on a= bove.

    I hope first that my above napkin sketch is = wrong, and secondly that the fix for this isn't deferral of all request= s until post-transfer. My guess is that would harm=C2=A0performance of the = instant navigation use case.

    One possible mitigati= on is deferral of all on-origin requests. Then there needs to be a backchan= nel between the this-is-my-hash origin and the state transfer origin. This = is maybe vaguely isomorphic to the distributor/publisher backchannel? Not r= eally, since subdomains. The publisher could easily CNAME sec-co.publisher.= example to sec-co.distributor.example.

    Actually, I= wonder if CNAME is an issue regardless of everything above.=C2=A0https://tools.ietf.org/html/draft-thomson-wpack-c= ontent-origin-00#section-5.1 states the UA must follow redirects. The p= ublisher could easily encode a redirect from publisher.example/foo to sec-c= o.publisher.example/foo, and then CNAME to the distributor, and let the dis= tributor respond with its known preimage.

    [1] &quo= t;fixmanifold" being vaguely an extension of a fixpoint. A function f(= x) s.t. for all x, hash(concat(x, f(x)) =3D=3D f(x). Then the bundle could = encode its own hash.

    On Tue, Mar 24, 2020 at 11:35 PM Devin Mullins &l= t;twifkak@google.co= m> wrote:
    Hi Martin,

    Thanks for the engineering work on this= . For others, I've already reviewed this, had some chats with others on= the AMP team, and had a few back-and-forths with Martin (he's been ver= y gracious in engaging his time, thank you). I'm trying to estimate the= feasibility of this, both for the AMP use-case, and for the non-AMP use-ca= se [1], which we hope to see flourish to the extent that publishers and use= rs desire it, and only impeded by implementation costs where necessary for = the common good.

    With the caveat that this is very early feedback, t= he high-level bit is that, with some modifications, it seems mostly feasibl= e for AMP. However, there are two main downsides:
    =C2=A0 1. worse UX on = sites that run A/B experiments
    =C2=A0 2. technical constraints make this= harder for publishers to adopt on non-AMP, as compared to SXG

    A lot= of details follow. I suggest to rename the subject if you reply to a detai= l below, in order to reduce cross-talk and make browsing the archive easier= .

    Details:

    We would need the display URL to be the attested U= RL even before transfer. I suspect a flash in the URL bar would be frustrat= ing for both users and publishers. Jeffrey had proposed using signatures fo= r this. I'd suppose UAs could choose to render this with a "may be= stale" indicator.

    In terms of publisher implementation feasibi= lity, I think the mostly likely implementation would be for a publisher to = produce a Sec-Content-Origin (Sec-CO) response for the current version of t= he resource iff it matches the Sec-CO request. I suspect that keeping state= of past versions of the resource would be infeasible, especially as it cou= ldn't be done purely at the edge; it would require something like a reg= ion-wide cache. The value of the above stateless implementation would be in= versely proportional to how often the resource changes (e.g. "transien= t content" [2] such as Related Articles). I think this would be a work= able constraint for publishers wishing to publish such bundles, but felt it= 's worth noting, nonetheless.

    Re: fallback behavior on failed st= ate transfer, distributors would need a way to monitor failure rates. This = serves two purposes:
    =C2=A0 1. Automatically detecting errors in the dis= tribution pipeline. This is the same purpose served by https://wicg.github.io/webpackage/loading.html#signed-exchange-report<= /a>.
    =C2=A0 2. Verifying that, for some fraction of navigations, bundles= are meeting AMP's stated UX goals (by using the verified content in th= e bundle and not potentially arbitrary content after the redirect). This is= a dynamic equivalent of what can be done mostly statically with SXG, becau= se the distributor can run the same algorithm as the UA, modulo client/serv= er skew in clocks and root stores. I think this is a trade-off AMP could ma= ke. The alternative is that the fallback behavior keeps the content-based o= rigin (CBO).

    There is a possible vector for user ID transfer from di= stributor to publisher; filed as     https://github.com/martinthomso= n/wpack-content/issues/1.

    This limits the ability to run session= -sticky experiments (in https://amp.dev/documentation/component= s/amp-experiment/ and many non-AMP frameworks). The publisher has the f= ollowing options:
    =C2=A0 1. Delay rendering content under experiment unt= il after state transfer. This hurts UX for the sake of experimentation, cre= ating a trade-off that otherwise doesn't exist on origin (modulo ease o= f implementation).
    =C2=A0 2. Generate a client-side UUID before state tr= ansfer, and join it with the pre-existing user ID after transfer. This mean= s the session could not include CBO pageviews anywhere except in the first = pageview.
    =C2=A0 3. Generate variants of the bundle for each experimenta= l state. The distributor chooses which bundle to send to the user (based on= what? not sure). For a page with M independent experiments each with N arm= s, that's N^M variants. For large enough M and N, this is likely both i= nfeasible for publishers and martinthomson/wpack-content#1. (But I need som= e guidance from experts on typical ranges for M and N.)

    Perhaps this= is a need the UA could address. A straw proposal -- a selectExperimentArm(= ) API that:
    =C2=A0 1. only exposes as many bits as the UA deems OK, and<= br>=C2=A0 2. exposes different bits to different attested origins, so they = can't be joined
    On the one hand, perhaps this is too much scope for = wpack. On the other, it addresses a problem that is somewhat particular to = CBOs.

    This impedes content management (e.g. dialogs for GDPR and CCP= A), compared to SXG. The publisher has a few choices:
    =C2=A0 1. Delay re= ndering the dialog under after transfer. I think this would cause layout sh= ift (https://web.dev/cls= /).
    =C2=A0 2. Render the dialog, and risk discovering that it's = already been acknowledged. At that point:
    =C2=A0 =C2=A0 a. Hide it, caus= ing layout shift.
    =C2=A0 =C2=A0 b. Leave it there. This is way outside m= y domain expertise, but ISTR there are some rules or at least best practice= s wrt when it's okay to re-show an opt-out dialog.
    One of these opti= ons may be an okay trade-off; I'm not sure.

    Analytics providers = (via https://amp.dev/documentation/components/amp-analytics/= and many non-AMP libraries) would have to do one of two things:
    =C2=A0 = 1. Delay pingback until after transfer. This risks a lower fraction of succ= essful pingbacks, as e.g. the user might close the tab before transfer.
    = =C2=A0 2. Generate a client-side UUID, send pingback before transfer, and s= end a follow-up after transfer to join with pre-existing user ID. This capt= ures those otherwise lost pingbacks pseudonymously (anonymously?), though i= t requires server-side work on the pingback endpoint.

    For the above = client-side mitigations, two feature requests seem necessary:
    =C2=A0 1. = Store the transfer metadata (e.g. indexedDB renames by time) somewhere more= permanent. For various reasons the event handler may not fire or finish, a= nd it would be good to later scan for stragglers to merge or expunge.
    = =C2=A0 2. DOM API to wait for transfer to complete.

    Some subresource= s are ACLs by Origin header (e.g. paid fonts). Likely mitigation is to defe= r loading until transfer, with a timeout whose duration depends on the publ= isher's font-display preference. (Martin suggests an optimization where= the encrypted subresource is loaded early, and only the decryption key aft= er transfer.)

    Last but not least, I am concerned that this is a bar = that is disproportionately difficult for non-AMP publishers to meet. The ab= ove client-side mitigations are possible, but quite a bit of work.
    =C2= =A0 1. For frameworks like AMP that strongly encourage publishers to use a = rolling release, it is possible to upgrade many use-cases in the wild with = minimal publisher effort.
    =C2=A0 2. For other frameworks, it may be poss= ible to provide this support, but the requirement to upgrade versions may l= imit applicability. Because upgrades occur less often, they often require m= ore work.
    =C2=A0 3. For custom JS that manages state, authors will need = to modify it to move or copy state into indexedDB, and handle transfer even= ts and merge conflicts.

    From a "minimal publisher effort" = perspective, I am especially interested in making it possible to have as cl= ose to a turnkey solution as is reasonable, for instance at the level of th= e CDN or CMS. If such a solution exists, sites would likely contain a hybri= d of all three cases above, and thus want to opt into such support incremen= tally. How should a CDN determine which pages to provide Sec-CO responses f= or?
    =C2=A0 1. URL patterns are the simplest answer, but I suspect hard f= or publishers to create and maintain with minimal false negatives and posit= ives.
    =C2=A0 2. Would it be helpful to thread an "I support state t= ransfer" annotation for some portion of the build journey, from indivi= dual JS function all the way to bundle? Would folks use this?

    I don&= #39;t have a good solution to the issue of non-AMP developer cost, and thus= fear this is a solution that would feature a disproportionate amount of AM= P pages compared to the background distribution of the web. But I'm hop= eful that other JS framework developers can chime in with respect to feasib= ility of support for CBO and state transfer.

    I'm leaving out som= e of Martin's replies to the above; no offense intended. It took me lon= g enough just to summarize the above, and I'd better send it early enou= gh so at least a few people have time to read it before the meeting.
    Thanks,
    Devin

    [1] htt= ps://blog.amp.dev/2019/05/22/privacy-preserving-instant-loading-for-all-web= -content/
    [2] http://= www.seobythesea.com/2011/12/how-google-might-identify-transient-content-on-= webpages/

    On Mon, Mar 23, 2020 at 5:35 PM Martin Thomson <mt@lowentropy.net> w= rote:
    Ted's = note prompted me to send a much-belated announcement (sorry folks, I forgot= ).

    The draft is here:
    https://tools.ietf.org/html/draft-t= homson-wpack-content-origin-00

    A nicer version here:
    https://martint= homson.github.io/wpack-content/draft-thomson-wpack-content-origin.html<= br>
    This approach could a dramatically different approach to addressing the use= cases set out in our charter.

    In short, this aims to address the core question of how offline content mig= ht *ultimately* be attributed to a web origin in a fundamentally different = way.=C2=A0 There are two key concepts:

    1. Content is given its own origin, using a new system for identification.<= br>
    2. A target origin can "accept" content and state from one of the= se new origins.

    There are a lot of details here (read the draft), but the major advantage I= see is that you don't have to make an offline decision about authority= , and that means you can be offline for much longer (lifting the 7 day limi= t).

    What it does have in common with signed exchanges approach is the need for = a bundling format, but in its current form it is less dependent on the deta= ils of the format.=C2=A0 That might allow that to be simpler, but I'm s= ure that the need to mint new identifier types will more than make up for a= ny slack there.

    The draft is quite rough.=C2=A0 I'm sure that it has the remnants of a = few bad ideas still hanging around.=C2=A0 Ask questions if you think someth= ing is unclear.

    _______________________________________________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --000000000000645ffa05a1b6e555-- From nobody Wed Mar 25 17:20:51 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17393A041D for ; Wed, 25 Mar 2020 17:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 jojDCkDhmLtR for ; Wed, 25 Mar 2020 17:20:43 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7563A0400 for ; Wed, 25 Mar 2020 17:20:42 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id l20so5198614wmi.3 for ; Wed, 25 Mar 2020 17:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pgEYiWt7Ak7k87wSFf2myja9+6hKPtzOLmUPiPN69bs=; b=u9rkcoPMBEGV2HkLSJEjek4K8NTgYP9IzED0/twXUSjAUDK5WYTNZw25e9JzpPZ331 /EsPhtyH2ytrlLbsPcBx6i/EYeEdNJ85MQ4MU/7jmGB+V/X25N3whpczuCQ/P2gLF2xD hNx2UrjNhleb5J2bjYaxU60TpEpyR1hD7JFJwjgdkaEIW73phYbZ3uS/Q59goFcT/ScN ogmTlbiclKHrsA/Ynz/khORVUcQVI+bBjc031LFYwRN71aRRmeIGZ3OWS2CekF2bNYWV y7sAa0lZJ59/uRLj3TzeeZIpBCDc3DZ/wxzRXI0cOeABV9I5h2wExS2h8TQcAs1OcLCn 4r+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pgEYiWt7Ak7k87wSFf2myja9+6hKPtzOLmUPiPN69bs=; b=FUsGloc3PQfWN6WFSOfIpuWmpVhQW2MXXO3l2JUZFDhg4OTFTW1pUVeFUxwxjDNpM+ +zBTJvIlYTIaxiJUFQkB1dvQJw8RdzNGaUg9Svv45Z7gBQ2q+G70kkyuiUbBI85Tw2UF Q4jjyn/gYlXTbHwbkZuaLm+7TzEl7ER7uH1zkzsNLK3WgJQhVTWFoQ8507Vm06oIweqT STKZqcuzc3edVOyxf5FGUWBih2pqv0gRrBR5G7RnfP1TyT+akmTJ2a/1UBSP6rwuDb9Y Daf3fuEewRRfUxBR8IaO5B8lEhI7MEIppOZeEr+f8wIo2V01KZ/4fI/81kBAg48AH/mn C4Jg== X-Gm-Message-State: ANhLgQ0sLT4OD4v/CR0rnc5TGFVqwJDLMRvvQuYRgowFmN8FaHyNnWfs T7vW9Xw5qcxpkvxu/9Dma/EHbghC+tRS7jlt9OM247Ff/W4= X-Google-Smtp-Source: ADFU+vvRvj14tMLtye2kK78A7tm9v4KHV2mUOT5dcXWi7YarC+mgyg4XOPKa5qq3XGfEJsAcBinbx1V7/RcwU/6sheI= X-Received: by 2002:a1c:6146:: with SMTP id v67mr219307wmb.78.1585182040680; Wed, 25 Mar 2020 17:20:40 -0700 (PDT) MIME-Version: 1.0 From: Devin Mullins Date: Wed, 25 Mar 2020 17:20:14 -0700 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000070eb9505a1b6f406" Archived-At: Subject: [Wpack] Displaying "(offline)" in URL X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 00:20:50 -0000 --00000000000070eb9505a1b6f406 Content-Type: text/plain; charset="UTF-8" Catching up on https://www.ietf.org/jabber/logs/wpack/2020-03-25.html, I saw some mention of displaying "offline" in the URL/origin bar if the transfer request takes longer than a few seconds. Perhaps I'm picking a nit, but I'd caution against displaying "offline" unless that's really the case. The user may confusedly try to restart their router or something. Then again, I'm not a UX person, so grain of salt. Thanks, Devin --00000000000070eb9505a1b6f406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Catching up on=C2=A0https://www.ietf.org/jabber/logs/wpack/2020-03= -25.html, I saw some mention of displaying "offline" in the U= RL/origin bar if the transfer request takes longer than a few seconds. Perh= aps I'm picking a nit, but I'd caution against displaying=C2=A0&quo= t;offline" unless that's really the case. The user may confusedly = try to restart their router or something. Then again, I'm not a UX pers= on, so grain of salt.

    Thanks,
    Devin
    --00000000000070eb9505a1b6f406-- From nobody Wed Mar 25 19:54:23 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23863A041E for ; Wed, 25 Mar 2020 19:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 IjvrXblpy3RW for ; Wed, 25 Mar 2020 19:54:17 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EAD3A0776 for ; Wed, 25 Mar 2020 19:54:17 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id c5so3569103lfp.5 for ; Wed, 25 Mar 2020 19:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bxHtw8uWNr8d+VJIALNiwM5UGunjyM8FrAz5Mf5MPjs=; b=e0TZPaJ+5iPxTsL+2U4jj6zUsRMB6maqQ+U6T9GxMzfc83C2uzNKAQ5qfk1DrRcsjo 74m3J0F5B5yrlWaJ93NZ5xrBAqVIpLDi+JDydmedL7DtX98PXXDHQrHSTjN8/2mV/qhL uxM7BK4oJY8yYgu5iobqhfR3WUyON7GIgKtQORP4mRk27m88MraHp3B4lqEaV4bMRaaY GggxfoRrEy/C9/ULN+wqRz/CfX9JQX06lz/GchrWXSg5k8+m5x5T+wlyHvoWNadMOEtB m6N3iWiq2uQyh6SXsvZIqa004JXAcMw/Vi027Xqyw6X9ox0rsZyjulCugelz23jeIRkk zpGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bxHtw8uWNr8d+VJIALNiwM5UGunjyM8FrAz5Mf5MPjs=; b=WWsFl53z39LLJJo1s28SllhoxRkY43ETC5pGkxhBwjcnePbMBMOQwWDHqMsKfkFvuV Lo4DJOf5j69z+ntTDTuj7OWmHR/XwiQyusUIjxHGLYpKMKwFGg44IefG0VlNPnLpLl1X sURVZXuW3g77ZD+I5lNtycbXXaG5yhqsPgw1CoNaHDGI9owUjfIqHNh2twav6UYq8GNX D1rNJsqVY9+pFDCoq22S23Box8/ODp5pc1ON/bAHjjTy+bJpRln6MAKCUiTUZc72HgI0 F6WtDvnk8nm6GWhcdEds5UFNgYLs2UsJPobEMM/PclHaZA0rM2wZ1DEvK1r0BGgpnExp SBOQ== X-Gm-Message-State: ANhLgQ3hjkV1+i7721OQHqNj7wQxDo6YtnE2gNToqSY51tFg2WlFLgl2 7I422ey6zHImsDTWH/5Y5LrQhAXhCeChKet3XL8Hmw== X-Google-Smtp-Source: ADFU+vtgadK4F8kzUjZclaAV5JefKyKytAh9UioyP3SEs1OcX+egQr+cTYTMzVa2NL1aOVOTZXpOW5m7RBijT0W0IXc= X-Received: by 2002:a19:ad4c:: with SMTP id s12mr4169030lfd.109.1585191255624; Wed, 25 Mar 2020 19:54:15 -0700 (PDT) MIME-Version: 1.0 References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> In-Reply-To: <024201d602e6$a8afde80$fa0f9b80$@acm.org> From: Eric Rescorla Date: Wed, 25 Mar 2020 19:53:39 -0700 Message-ID: To: Larry Masinter Cc: Sean Turner , WPACK List Content-Type: multipart/alternative; boundary="000000000000b178b105a1b919ec" Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 02:54:20 -0000 --000000000000b178b105a1b919ec Content-Type: text/plain; charset="UTF-8" As this seems to be controversial, i want to voice support for using Github. It's a much better system than what we had before. On Wed, Mar 25, 2020 at 1:48 PM Larry Masinter wrote: > I think relying on GitHub Issues and responses might work out fine for a > close knit group that is solving a narrow problem. > > It's appropriate for a design team or a repo shared by a few document > editors to coordinate their work. > > It's difficult to get a sense of working group status and topics of > interest > and controversy by trying to delve into GitHub activities. > > The main reason that there's a BOF at an IETF meeting and forming a working > group in the IETF (rather than through WHATWG) is to get broader review > from > people who aren't following the work day to day. > > Personally, I'd like to see the working group take on as part of its > charter > the possible replacement of MIME multipart (mutlipart/related for MHTL, > multipart/form-data) and also for PDF (a package of content independently > assembled by a sender and signable as a package). > > > -----Original Message----- > > From: Wpack On Behalf Of Sean Turner > > Sent: Wednesday, March 25, 2020 12:46 PM > > To: WPACK List > > Subject: [Wpack] WPACK GitHub Repo? > > > > hi WPACK, > > > > The chairs have had some success with using GitHub repos for WGs, but > > whether we set one up is a WG decision. So, if there are objections to > use > > establishing a WG repo please let us know 2359 UTC 27 March 2020 and > > please state why. > > > > Thanks, > > Dave and Sean > > _______________________________________________ > > Wpack mailing list > > Wpack@ietf.org > > https://www.ietf.org/mailman/listinfo/wpack > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --000000000000b178b105a1b919ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    As this seems to be controversial, i want to voice support= for using Github. It's a much better system than what we had before.

    On Wed, Mar 25, 2020 at 1:48 PM Larry Masinter <LMM@acm.org> wrote:
    I think relying on GitHub Issues and responses might wo= rk out fine for a
    close knit group that is solving a narrow problem.

    It's appropriate for a design team or a repo shared by a few document editors to coordinate their work.

    It's difficult to get a sense of working group status and topics of int= erest
    and controversy by trying to delve into GitHub activities.

    The main reason that there's a BOF at an IETF meeting and forming a wor= king
    group in the IETF (rather than through WHATWG) is to get broader review fro= m
    people who aren't following the work day to day.

    Personally, I'd like to see the working group take on as part of its ch= arter
    the possible replacement of MIME multipart (mutlipart/related for MHTL,
    multipart/form-data) and also for PDF (a package of content independently assembled by a sender and signable as a package).

    > -----Original Message-----
    > From: Wpack <wpack-bounces@ietf.org> On Behalf Of Sean Turner
    > Sent: Wednesday, March 25, 2020 12:46 PM
    > To: WPACK List <wpack@ietf.org>
    > Subject: [Wpack] WPACK GitHub Repo?
    >
    > hi WPACK,
    >
    > The chairs have had some success with using GitHub repos for WGs, but<= br> > whether we set one up is a WG decision. So, if there are objections to= use
    > establishing a WG repo please let us know 2359 UTC 27 March 2020 and > please state why.
    >
    > Thanks,
    > Dave and Sean
    > _______________________________________________
    > Wpack mailing list
    > Wpack@ietf.org=
    > https://www.ietf.org/mailman/listinfo/wpack

    _______________________________________________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --000000000000b178b105a1b919ec-- From nobody Wed Mar 25 23:51:29 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBC3A080C for ; Wed, 25 Mar 2020 23:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 c50l6k82FS2k for ; Wed, 25 Mar 2020 23:51:26 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AA63A010D for ; Wed, 25 Mar 2020 23:51:26 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id z65so2303752pfz.8 for ; Wed, 25 Mar 2020 23:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=6syHhID2A9jJfEBKX/AKWJTAKcEkIruRtNIyPATIEk4=; b=oQwhG+MWViedvDlA0VqfU+7rhSExVolps+9XA0LN1yQ0gkLik4twLq+pHLM6jPcxEI kp5xpuBydq8s3XlUDUNDuOMfMAVZHwphsm2zgS7yF5OWW7cFr2Q3UGZB2Mlfb/HJIENp 4YllDKp1uDC6W0lxYgtf/gOvnA3Z13KEGQpoPMUqcYBPTKewQwohLsxDnlNZJ5IYHCvF iygD7V8CMrSaMA7CtCtCWRxoSNHqg/dAeiNpv87OW/x6plplvzn9SxWAtaSzUMNNxX9c Lk7+F2BCtvXp/eZDnvAMnFtx7AbQQsf6u3PfiSzBo3mXvm+15uPLG+m4BbubSEGXEbRe xQew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=6syHhID2A9jJfEBKX/AKWJTAKcEkIruRtNIyPATIEk4=; b=oy85rQodLPBGbvjzZl01boMGge2ZVIZ7cHfMEXMXj/kt8zVxfDzzjAKwLLnvs2sSZr zOahM6Wi5hfoSPkqBg3Qu8tyXlLTjvzXB2m75uJHKk3sbYtPWA68uRL47nskINLPtYdT mYzfOyo0JpBvdWFcG+o1kR2f+YIlEKHRr02Bwyb9rNKHbGaFOEVtK2bXTH04jcEBihfn ixOV/E2j8hjvjWktP69/51+QjvQUQpmnLqvlC6SQF7grtRmrGiRqR2gBXgaYtdMMRnVC WMZDEeQ5IPhKyasJLiGhwuCCGpvmRuZEfZW/tkPwUn/OIKpr3+Tri8JKRqY7Z9wGrOWo sQKw== X-Gm-Message-State: ANhLgQ26QxS/bGCvariPHWPaSL5BXOJ03d1fcTTZUSr5YRYlNCI3SJYP rXsb3gq3Fb5bGlFndgtpmv0= X-Google-Smtp-Source: ADFU+vtkcNRTIuCrwtCJo7NylrIbb7kkLsHzUhpA7mB95khqOs5mBkh+F4KEEWdsj3Zo4EvaDbl2iQ== X-Received: by 2002:a63:371b:: with SMTP id e27mr6560485pga.297.1585205484614; Wed, 25 Mar 2020 23:51:24 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id z7sm874793pfz.24.2020.03.25.23.51.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 23:51:23 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Eric Rescorla'" Cc: "'Sean Turner'" , "'WPACK List'" References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> In-Reply-To: Date: Wed, 25 Mar 2020 23:51:23 -0700 Message-ID: <002401d6033a$f70fe990$e52fbcb0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01D60300.4AB186C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEM67UzIqgh1ZbNVvz9bahXlI6eOwGswW5pALwgHvyp2UszgA== Content-Language: en-us Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 06:51:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01D60300.4AB186C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m sorry. I=E2=80=99m fine with using GitHub, I was grousing = about something else -- the difficulty in searching in GitHub comments = and responses to find out what things were the focus of the work of the = working group. I=E2=80=99m on the mailing list, but it=E2=80=99s clearly some other = forum in which the discussion about the different kinds of signing and = trust and identity are being discussed. Or not. I want to learn enough of the language you use in these = discussions so I can explain and be understood. I suspect your = requirements may be at the wrong level (you=E2=80=99re starting with a = very operational view of the =E2=80=9Cweb security model=E2=80=9D (if = there is such a thing) by translating TLS into digital signatures and = asking who signs what and how can you do that with minimal changes to = the browser =E2=80=9Csecurity model=E2=80=9D. Asking what=E2=80=99s the origin of a data: URL is asking the wrong = question. The problem is the notion of =E2=80=9Corigin=E2=80=9D is tied = to the HTTP transaction model. PDF signatures are package signatures, but the signature isn=E2=80=99t = tied to the origin of any of the parts. Isn=E2=80=99t that what you want = when you want to show something is trusted not because it was assembled = from trusted parts but because you trust the assembler? What use case = forces you to assume that interpretations packages have to look the same = in the browser showing URLs? =20 =20 Anyway, this is the kind of question / discussion I=E2=80=99d try to do = in the hallway at a F2F IETF. I don=E2=80=99t see the mailing list, a = github issue, or a group videoconference call. But if you want to chat, = let me know. ------=_NextPart_000_0025_01D60300.4AB186C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    I=E2=80=99m sorry. I=E2=80=99m = fine with using GitHub, I was grousing about something else -- the = difficulty in searching in GitHub comments and responses to find out = what things were the focus of the work of the working = group.

    I=E2=80=99m on the mailing = list, but it=E2=80=99s clearly some other forum in which the discussion = about the different kinds of signing and trust and identity are being = discussed.

    Or not.=C2=A0 I want to = learn enough of the language you use in these discussions so I can = explain and be understood. I suspect your requirements may be at the = wrong level (you=E2=80=99re starting with a very operational view of the = =E2=80=9Cweb security model=E2=80=9D (if there is such a thing) by = translating TLS into digital signatures and asking who signs what and = how can you do that with minimal changes to the browser = =E2=80=9Csecurity model=E2=80=9D.

    Asking what=E2=80=99s the origin of a data: URL is = asking the wrong question. The problem is the notion of = =E2=80=9Corigin=E2=80=9D is tied to the HTTP transaction = model.

    PDF signatures are package = signatures, but the signature isn=E2=80=99t tied to the origin of any of = the parts. Isn=E2=80=99t that what you want when you want to show = something is trusted not because it was assembled from trusted parts but = because you trust the assembler? What use case forces you to assume that = interpretations packages have to look the same in the browser showing = URLs?

     

     

    Anyway, this = is the kind of question / discussion I=E2=80=99d try to do in the = hallway at a F2F IETF. I don=E2=80=99t see the mailing list, a github = issue, or a group videoconference call. But if you want to chat, let me = know.

    ------=_NextPart_000_0025_01D60300.4AB186C0-- From nobody Thu Mar 26 06:27:22 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F53A0944 for ; Thu, 26 Mar 2020 06:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=XdrP0rSw; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=cscFztin 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 WfS-u0RhpXBJ for ; Thu, 26 Mar 2020 06:27:16 -0700 (PDT) Received: from outbound1a.ore.mailhop.org (outbound1a.ore.mailhop.org [54.213.22.21]) (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 2EF183A08E2 for ; Thu, 26 Mar 2020 06:27:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585229236; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=G1Pb1neUHznglB0Pml3ucIzpCWsE2KYkoN7k7dNZdLzk5a+RJCRpJaGJ8JxQGpD4dmyoB+YfNfOYR 9erQzChVrLIVEQNbHuJvkbtut6gxky5ZukaEXvA/FcJWVSCs2H9T6LwxgWrpVHs8NaWGSM0US+s4XG ak+QNUByhnR9sZndOvbuWzTfkPROvahc9mtQjjMcRhshsC+as7RKVwQQ6W11wlGqb51XFuRJ8vd4xc vZi9SBWSb0QvOTZ8GbVFnOIS7JTgTr+XiX5kQ38BXZnxRglnyp79w09zQCTQJcTqn/VGIggz5Dz4nL IFFibO7dbEHv/TdUC+Dab51TAZ3XZ/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=jfpkMUbHP++w7fF73OrzfktTnPTEdDBkSWDPDeR7ZsM=; b=DeNelrn09UiEDJQlFwDIUOgZOaw4iHO/5GXUx6ET2wOEcaLZTwWU5Y6nZQ/pkmEyzPOLAB0KimXe4 c+9R0lntxePVf1x2fZaZgghOuey81clAGSq9doa0tEy+DH72twTLuEUGwDuKqRebmMlHOXJg9ccdPi szNZ5XUTAhTLkyeAURCyR7whEfoZq/FXTPrMNbCwYE4Sgcp6GrsJCqJ8yV/Tm9FwrHoC6q86gFn+5B ON8Nd9t0/aip22VtS2/vbibsLrcsuwzNgn28V3QUQ5nVgT9Z5HNkUAHHxYxjCJV0BzZgCwh2/2HnyR v4T7kJFNL7OJUVwmOe1fv4+8riXxA0w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.49; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=jfpkMUbHP++w7fF73OrzfktTnPTEdDBkSWDPDeR7ZsM=; b=XdrP0rSwK/J17yvvkqvSCwTD43rRkBkCL7QwSjTXL4p9UWtz3r1eNlUa/3GgGCGCUddiE1FRgFpyV +8/K+thq+nCnbtPZXG5GOgjO2zv54zpjwwaKegZhJ9pwOGGhqfj4JXKpxkMtcDklFAdb6JtBs4VhxO 3Zy4VMYSKJtUnLWQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=jfpkMUbHP++w7fF73OrzfktTnPTEdDBkSWDPDeR7ZsM=; b=cscFztinwUkV8aLk4sTUh+t3hQHWpWem9coou3oMi9zMsP6ze8Z4qLyw51apJGqw46VEd1paQ1K5Q jLemtqKbpV7EV2fP+SMmMF1/rC9NoqtzlNuELvDV7gl6eKPDjom58fKg4gk9xa4haojPUIti6iSv5P TXlF4MiXMtLm1r7uWSkpFh5u2Kjd2172ObYl+ajsTGhoVVtZC9avjXEuezvN7/OJxg5HLjTcBGBMON 3H6I8+MAex+94+47UzPO521rsH85aXovOW0qdYLOH+WJnNHWsPdQZihOASrc62x5qaM8nxA13d+2Nv 6pTDJAFRQ/9M1D7lDFlpG5HY90jSwfA== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 8176e3d0-6f65-11ea-b80e-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.49 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8176e3d0-6f65-11ea-b80e-052b4a66b6b2; Thu, 26 Mar 2020 13:27:14 +0000 (UTC) Received: by mail-ot1-f49.google.com with SMTP id f52so5735673otf.8 for ; Thu, 26 Mar 2020 06:27:14 -0700 (PDT) X-Gm-Message-State: ANhLgQ0Ax9LXdsKHIrFzzTORKcSekZlnN/Hx0okZfCDoWvsdp/vH2rOF Ja5sSNbFawcN1Z2aruyjwiVontDMtfjVfXly/UY= X-Google-Smtp-Source: ADFU+vv6HWeXJHNV7cIIo9lcl/J82UqpLypJ/lb6FsEGjed5E6p3CpMX4oR6cDDcFYHWalDP+/NsHu2Is7We6oCjjIQ= X-Received: by 2002:a4a:250b:: with SMTP id g11mr5093444ooa.27.1585229234032; Thu, 26 Mar 2020 06:27:14 -0700 (PDT) MIME-Version: 1.0 References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> <002401d6033a$f70fe990$e52fbcb0$@acm.org> In-Reply-To: <002401d6033a$f70fe990$e52fbcb0$@acm.org> From: Patrick McManus Date: Thu, 26 Mar 2020 09:27:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Larry Masinter Cc: Eric Rescorla , WPACK List , Sean Turner Content-Type: multipart/alternative; boundary="00000000000061d7b705a1c1f171" Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 13:27:20 -0000 --00000000000061d7b705a1c1f171 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi Larry - I find for a wg I am heavily invested in, its often handy to subscribe to all notifications of a github repo (and then mail filter). This creates the sort of serialized back and forth that conveys the tone and areas of emphasis of a very good email discussion. Its even better though because everything is properly threaded :) I recognize that this is mostly helpful looking forward. ymmv -P On Thu, Mar 26, 2020 at 2:51 AM Larry Masinter wrote: > I=E2=80=99m sorry. I=E2=80=99m fine with using GitHub, I was grousing abo= ut something else > -- the difficulty in searching in GitHub comments and responses to find o= ut > what things were the focus of the work of the working group. > > I=E2=80=99m on the mailing list, but it=E2=80=99s clearly some other foru= m in which the > discussion about the different kinds of signing and trust and identity ar= e > being discussed. > > Or not. I want to learn enough of the language you use in these > discussions so I can explain and be understood. I suspect your requiremen= ts > may be at the wrong level (you=E2=80=99re starting with a very operationa= l view of > the =E2=80=9Cweb security model=E2=80=9D (if there is such a thing) by tr= anslating TLS into > digital signatures and asking who signs what and how can you do that with > minimal changes to the browser =E2=80=9Csecurity model=E2=80=9D. > > Asking what=E2=80=99s the origin of a data: URL is asking the wrong quest= ion. The > problem is the notion of =E2=80=9Corigin=E2=80=9D is tied to the HTTP tra= nsaction model. > > PDF signatures are package signatures, but the signature isn=E2=80=99t ti= ed to the > origin of any of the parts. Isn=E2=80=99t that what you want when you wan= t to show > something is trusted not because it was assembled from trusted parts but > because you trust the assembler? What use case forces you to assume that > interpretations packages have to look the same in the browser showing URL= s? > > > > > > Anyway, this is the kind of question / discussion I=E2=80=99d try to do i= n the > hallway at a F2F IETF. I don=E2=80=99t see the mailing list, a github iss= ue, or a > group videoconference call. But if you want to chat, let me know. > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000061d7b705a1c1f171 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    hi Larry -

    I find for a wg I am heavily= invested in, its often handy to subscribe to all notifications of a github= repo (and then mail filter). This creates the sort of serialized back and = forth that conveys the tone and areas of emphasis of a very good email disc= ussion. Its even better though because everything is properly threaded :)

    I recognize that this is mostly helpful looking for= ward. ymmv
    -P


    On Thu, Mar 26, 2020 at 2:51 AM= Larry Masinter <LMM@acm.org> wrot= e:

    I=E2=80=99m sorry. I=E2=80=99m fine with= using GitHub, I was grousing about something else -- the difficulty in sea= rching in GitHub comments and responses to find out what things were the fo= cus of the work of the working group.

    I=E2=80=99m on the mailing list, but it=E2=80=99s clearly some other for= um in which the discussion about the different kinds of signing and trust a= nd identity are being discussed.

    Or= not.=C2=A0 I want to learn enough of the language you use in these discuss= ions so I can explain and be understood. I suspect your requirements may be= at the wrong level (you=E2=80=99re starting with a very operational view o= f the =E2=80=9Cweb security model=E2=80=9D (if there is such a thing) by tr= anslating TLS into digital signatures and asking who signs what and how can= you do that with minimal changes to the browser =E2=80=9Csecurity model=E2= =80=9D.

    Asking what=E2=80=99s the o= rigin of a data: URL is asking the wrong question. The problem is the notio= n of =E2=80=9Corigin=E2=80=9D is tied to the HTTP transaction model.=

    PDF signatures are package signatures, bu= t the signature isn=E2=80=99t tied to the origin of any of the parts. Isn= =E2=80=99t that what you want when you want to show something is trusted no= t because it was assembled from trusted parts but because you trust the ass= embler? What use case forces you to assume that interpretations packages ha= ve to look the same in the browser showing URLs?

    =C2=A0

    =C2=A0=

    Anyway, this is the kind of question / di= scussion I=E2=80=99d try to do in the hallway at a F2F IETF. I don=E2=80=99= t see the mailing list, a github issue, or a group videoconference call. Bu= t if you want to chat, let me know.

    __________= _____________________________________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --00000000000061d7b705a1c1f171-- From nobody Thu Mar 26 06:52:12 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512AF3A0779 for ; Thu, 26 Mar 2020 06:52:11 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=akamai.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 i82R12liNBri for ; Thu, 26 Mar 2020 06:52:09 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8C9103A00C4 for ; Thu, 26 Mar 2020 06:52:09 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02QDjPs5009195; Thu, 26 Mar 2020 13:52:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=p7o57cp1P5S7uGc/91x4Ftf82kyKsjnGGL8y7ul142k=; b=Bcgl50biPVMqnWNUsUTa36Gp6lq0aWWrQZttQ2Zsj9X9LlZp2YKYCyNU9zT/YBJpZsb2 +kQ35RZKG17/RZzQ3+AVuf/VU6IHzc4rU5zqqwZvjKq06lpYhxkOAzjkxHH0AXLHsCEO GhVb+snC0ORHxca9oLRiKLOP4yyy6nBi8aRvW/4e1geWU5AHo2QVz7h1l/3oVEo+owd5 upM4AxVLWMNiUn7gYSiKyneZYjkDh9ZPG4P1BghHnKOP1vWBUyOHb2dWAOZ1/ZWGXrgd bd43Of7xaI5Q3d4v79oTYAZUh99gKqinm7qhhc4YTj1mkNwkEm3jU160KEFheEhBMzfS 1A== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2yyt8q04ky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Mar 2020 13:52:05 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02QDmKU1017387; Thu, 26 Mar 2020 09:52:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint7.akamai.com with ESMTP id 2ywe8uk4cn-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Mar 2020 09:52:04 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Mar 2020 09:52:03 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Thu, 26 Mar 2020 09:52:03 -0400 From: "Salz, Rich" To: Eric Rescorla , Larry Masinter CC: WPACK List , Sean Turner Thread-Topic: [Wpack] WPACK GitHub Repo? Thread-Index: AQHWAt4Bik2efFAH/0iv7a/r+AZNq6haCqIAgABmMICAAHTlAA== Date: Thu, 26 Mar 2020 13:52:02 +0000 Message-ID: <0AA35F51-CD55-4466-AD8E-A0B49D1BAD8F@akamai.com> References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: multipart/alternative; boundary="_000_0AA35F51CD554466AD8EA0B49D1BAD8Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-26_04:2020-03-26, 2020-03-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=726 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003260107 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-26_04:2020-03-26, 2020-03-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=693 impostorscore=0 adultscore=0 clxscore=1011 spamscore=0 suspectscore=0 bulkscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003260106 Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 13:52:12 -0000 --_000_0AA35F51CD554466AD8EA0B49D1BAD8Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgbG9uZyBhcyBpdHMgbmFtZSBpZXRmLXdnLXdwYWNrLCBwbGVhc2UgdXNlIGdpdGh1Yi4NCg0K WWVzLCBpZiB5b3XigJl2ZSBnb3QgYW4gYWN0aXZlIEdIIGdyb3VwLCBjYXRjaGluZyB1cCBjYW4g YmUgaGFyZC4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGNhdGNodXAgYnkgcmVhZGluZyB0aGUg V0cgbWFpbGluZyBsaXN0LCBwZXJoYXBzIGRpdmluZyBpbnRvIG9jY2FzaW9uYWwgaXNzdWUgdGhy ZWFkczsgaWYgbm90LCB0aGF04oCZcyBhIGZhaWx1cmUsIHByb2JhYmx5IG9mIFdHIGxlYWRlcnNo aXAuIFdoYXQgaWYgaXTigJlzIGJlZm9yZSB0aGUgbWFpbGluZyBsaXN0IG9yIFdHIGlzIGZvcm1l ZD8gIFdlbGwsIHRoYXTigJlzIG91dCBvZiBzY29wZSwgYW5kIGF0IGxlYXN0IHlvdSBoYXZlIGFu IGFyY2hpdmFsIHJlY29yZCAodmlhIGlzc3Vlcykgb2YgZGlzY3Vzc2lvbnMuDQo= --_000_0AA35F51CD554466AD8EA0B49D1BAD8Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBsb25nIGFzIGl0cyBuYW1lIGlldGYt d2ctd3BhY2ssIHBsZWFzZSB1c2UgZ2l0aHViLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMs IGlmIHlvdeKAmXZlIGdvdCBhbiBhY3RpdmUgR0ggZ3JvdXAsIGNhdGNoaW5nIHVwIGNhbiBiZSBo YXJkLiBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gY2F0Y2h1cCBieSByZWFkaW5nIHRoZSBXRyBt YWlsaW5nIGxpc3QsIHBlcmhhcHMgZGl2aW5nIGludG8gb2NjYXNpb25hbCBpc3N1ZSB0aHJlYWRz OyBpZiBub3QsIHRoYXTigJlzIGEgZmFpbHVyZSwgcHJvYmFibHkgb2YgV0cgbGVhZGVyc2hpcC4g V2hhdCBpZg0KIGl04oCZcyBiZWZvcmUgdGhlIG1haWxpbmcgbGlzdCBvciBXRyBpcyBmb3JtZWQ/ Jm5ic3A7IFdlbGwsIHRoYXTigJlzIG91dCBvZiBzY29wZSwgYW5kIGF0IGxlYXN0IHlvdSBoYXZl IGFuIGFyY2hpdmFsIHJlY29yZCAodmlhIGlzc3Vlcykgb2YgZGlzY3Vzc2lvbnMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0AA35F51CD554466AD8EA0B49D1BAD8Fakamaicom_-- From nobody Thu Mar 26 06:56:21 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407A63A08F4 for ; Thu, 26 Mar 2020 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 zEDlLTRvxkcF for ; Thu, 26 Mar 2020 06:56:05 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2101.outbound.protection.outlook.com [40.107.93.101]) (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 F27653A0955 for ; Thu, 26 Mar 2020 06:56:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m2SvqD2D/zQXbBBsQqhzkm8W2wv9Ui2YiYfPhq52yN97bHFGfQ0v1rfrx/9kEz6KaiiLVO4+hfGHR8ojp6sTk+5E/BwwyjC1kih8YUDzE8r+iEMKyWnCkvnG519zTT8fTm9gO+8f1IjjpyTpj2jnrt75kLnj2zG9bVPPwmIqqqZGgSzl6LXta80IrEuhwBs0Yf4umu5vsRt+nBXKqboVqzzNPJx/XqKNNEkswyQ5oEqXfS06LMErobG5pl/Z7AoSQNNP9r1yqvTSQ1uSaNMb5/PXunHC8XUkQeqzu7oXRXPXTE6Yk5SCVSrKNlyDLHHDhhMi2scrn90v8P5ForgZyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xj0NpeyVgjrTzYJHN4yabMj0JmR/DAS4Qw2g5fgxtVA=; b=eJbJ+4zzdihCFGMRrtBWiHMyoIT+YE/lj59Y7MGK472psqNwErdNiFKWJ5howaqX9PdBWF560kTWdlw1dnAXt/3R72VGOtxMMqd8wkmSQ7LE3LoD8O8N18Gn2OWIckWU+G55xD0CehjRQCuAVIZelTkulQ82F8wKPLv32oK+WNBCbNma4Xqnu091zXqh1BI4jHiaonvPBjpu+DjOam0P84IVy4HgMU0Y7StBumd1Vzydxems3nBmtIuthf6JCO+gxOMSCJVKlD7IxNIsLUCaEj56yDexcusrfzArpHOiFLBZ/h8pG49bSX0PSrb2LZYTi0/xsxhry1cOSANdFgMDTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xj0NpeyVgjrTzYJHN4yabMj0JmR/DAS4Qw2g5fgxtVA=; b=cD2frMqBemEH4ZuxezCHdxShjfcplubX+fGE4MCKeplZTavtWPMfkDljA2g/2c4kBDJ3OlZ8nFZPYjQBQr4FA99TJCmWKEwWOzI/SF+38BylW7v4cosKkfnXCv7itOMO6qcMRwebQjqEDZL1oHdPBAgIDM/0o/o4cD4fZ/kzpxk= Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB1960.namprd22.prod.outlook.com (2603:10b6:610:5e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Thu, 26 Mar 2020 13:56:02 +0000 Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::49ef:5e83:1dee:ddb2]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::49ef:5e83:1dee:ddb2%6]) with mapi id 15.20.2835.023; Thu, 26 Mar 2020 13:56:02 +0000 From: Mike Bishop To: Sean Turner , WPACK List Thread-Topic: [Wpack] WPACK GitHub Repo? Thread-Index: AQHWAt4DjJ1d/KCf4kikjI8s/nB8h6ha5liw Date: Thu, 26 Mar 2020 13:56:02 +0000 Message-ID: References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> In-Reply-To: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2600:2b00:930c:7701:99cb:a615:ff9d:29f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c71da125-427d-43a6-0665-08d7d18d6bdb x-ms-traffictypediagnostic: CH2PR22MB1960: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(366004)(39830400003)(136003)(966005)(8676002)(81156014)(81166006)(9686003)(5660300002)(8936002)(33656002)(52536014)(71200400001)(508600001)(186003)(55016002)(7696005)(316002)(110136005)(64756008)(2906002)(66446008)(66946007)(76116006)(66556008)(53546011)(6506007)(66476007)(4744005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR22MB1960; H:CH2PR22MB2086.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H/6n9op+Lr0dL1Hw2g9H8X3JV0cwz0lwn61wEVXe3v2G/bUWUQK2Ig2HFzmSbNg/+wkf4IW+SRyGUAWeHYXJujObT1Ko97KUaPYMZgx9XW8aKePh25Cv/1Rmg2eCY07thJgVOdKljcpTtpuanMhYLIAFNydV5hOLC7az4BynJjz/1cpTWGyKM1n6kcHVKVwg+bLAt47pzzv8fWZ4zcqCssmWdHqiFWlKQQ1vTT/my1MmA6/zXAzuaNmE9s+45J6vhsK7Z3n7WujWYKMnlqD/Hj1ZPJrft+J4uVhK5kUUG/CPt11uA25lMOuIlBUGNrgPQ9xFaW4/VL+mQjwYn57ffq0tyj2EVpECRaZMuhm22Td/y70hYxCj2iBRsCAyjqJWJ24HflV5KmzymAq/i/IA0duJxox7PXAWHDfkcVkK+HyrTOWtZH+h3rbFnpQl1aSSDsXY7V8cQbygTNb/uWLmSS095OqnJTLS6BqcAEsl062fiKrjnEhZDrNjMhTG6lYN9l/NsxWmC7BwOnCjRUmTMw== x-ms-exchange-antispam-messagedata: YOVVsosbzk/pw1FTIzaKUOYxZ/830ZicWM5+OZz99gNNrb66TtUWpfKq188NJ/3+wWXoXkJr1cHxIQYKfuALwVdVdY+7X11bgR+wWntYIL8DBrFId1ESXmCnLCmspg+j4hi7UkpSMb3laa71CRYCdZyT4AugwANymeSyZobLhC3+0RMe6os++AyZuywgnnOnj1gxGjJlpiOaUbNZ8nukGw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c71da125-427d-43a6-0665-08d7d18d6bdb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 13:56:02.4537 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yKMY8yc0MzIVlucRasGD1VaJOq0onAv1uNTz60HMJK2LAjup0D0+fAi4kFETwe1Tpr1HdC0/4Kf2jKciIMxIbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB1960 Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 13:56:20 -0000 GitHub has worked out quite well for several other WGs I participate in. A= ll-in on GitHub, please. -----Original Message----- From: Wpack On Behalf Of Sean Turner Sent: Wednesday, March 25, 2020 3:46 PM To: WPACK List Subject: [Wpack] WPACK GitHub Repo? hi WPACK, The chairs have had some success with using GitHub repos for WGs, but wheth= er we set one up is a WG decision. So, if there are objections to use estab= lishing a WG repo please let us know 2359 UTC 27 March 2020 and please stat= e why. Thanks, Dave and Sean _______________________________________________ Wpack mailing list Wpack@ietf.org https://www.ietf.org/mailman/listinfo/wpack From nobody Thu Mar 26 09:55:17 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EFE3A0D41 for ; Thu, 26 Mar 2020 09:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LGHjNKrxzkIU for ; Thu, 26 Mar 2020 09:55:01 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C633A0CD2 for ; Thu, 26 Mar 2020 09:55:01 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id o12so2648821pjs.2 for ; Thu, 26 Mar 2020 09:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=OFYQx39bTyWfa+dbw0waO6Gy9rNNQt6LSd71zxDOfak=; b=nBJbU4sgYIHvIao793gu9PyY20p6hJhUQXzPQdYEVlqEP8qhdWZkShGZ+3AYPMkhwS PEIKDwuk0j9IzfpmpxkCKOKXIjZYj+2+BRGqVTQ9ySX5kyhg50YaWBkboE6A+Huqt8nv nkgtk6kOvmewN++mhM7jf34f2ymFShQtJ42Z/AZpw6Y8Y+crXgCMmxzBiVDuzmKxwggk HI+qIjk+7S8RbwB9dYE/rtqkvmgZcuoJBSAT9ZJIGcVEJbSX3L5K8Jxf+FAWP0dGRYAA SYB82PIxnTgepXC6BVLNW/7Oe1c0g7vTI0BhE283Qu9A0L2JvtrJHYgON2m/Crr0BN20 UmTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:thread-index:content-language; bh=OFYQx39bTyWfa+dbw0waO6Gy9rNNQt6LSd71zxDOfak=; b=kp4Hf3OWXV3ebl4gWU5eNMNrAh3a0nBYG7yoBUbNS83HEULdReyKXal6RLWqL+mkkg HZn6ldlTccDD8f7DmXc6OBTQqKtKcAu85r7F1Bec3Klyg9Owm32KIaPOF505R5MVZ2BG DDpSzUGo8IKwg9iQ6McrQyqgMLWVzRcYqm85RB0fOPfjHPqEma8Kp7g1ZvcBYYDOZBLb jJLBJhrItpXbNN4D2djEjEy439BzTNLH0QExqqYbP+IbzY0VTuQJCeQvRv+9GZ/R9K5E C2juNAnYpPma9SSIk7FmS0yEw/ZwWbgARsXMzRMKJe/m3vyIkLIZi4n0BROAN/20ruFe /QcA== X-Gm-Message-State: ANhLgQ2+AhnuihWuhW/a5jAIB6T6p5WLmmuJV3ZEYzPakbq9F/TRuuN0 KpcNyztPBrRznGc9Dtb6iumNfxPu0/g= X-Google-Smtp-Source: ADFU+vuIYsekGc7/LCxKhZSL2bdVe73Sn8MxWuMQSOo3faKPdFxKEjgQZ7upzAi5thC6tSl+5DffvA== X-Received: by 2002:a17:90a:e287:: with SMTP id d7mr1030772pjz.76.1585241700595; Thu, 26 Mar 2020 09:55:00 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id t188sm1151990pfb.102.2020.03.26.09.54.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2020 09:54:59 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'WPACK List'" Date: Thu, 26 Mar 2020 09:54:58 -0700 Message-ID: <00f301d6038f$49451880$dbcf4980$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01D60354.9CE6B5B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYDjjGN2aC2ANcMS0q87swer2aSzw== Content-Language: en-us Archived-At: Subject: [Wpack] URLs for older timestamped data X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 16:55:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F4_01D60354.9CE6B5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit https://tools.ietf.org/html/draft-masinter-dated-uri This document defines two URI schemes. The first, 'duri' (standing for "dated URI"), identifies a resource as of a particular time. This allows explicit reference to the "time of retrieval", similar to the way in which bibliographic references containing URIs are often written. ------=_NextPart_000_00F4_01D60354.9CE6B5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    https://too= ls.ietf.org/html/draft-masinter-dated-uri 

     

      This = document defines two URI schemes.  The first, 'duri' = (standing

       for = "dated URI"), identifies a resource as of a particular = time.

       This = allows explicit reference to the "time of retrieval", similar = to

       the = way in which bibliographic references containing URIs are = often

       = written.

     

    ------=_NextPart_000_00F4_01D60354.9CE6B5B0-- From nobody Thu Mar 26 10:47:23 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA933A07F6 for ; Thu, 26 Mar 2020 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 loVeHLPLzAWJ for ; Thu, 26 Mar 2020 10:47:18 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CBB3A00D9 for ; Thu, 26 Mar 2020 10:47:17 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id p60so3482316qva.5 for ; Thu, 26 Mar 2020 10:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OloFHqXD0l+5xL1vIbVxK1ZZk0pMA/nvjWViFfgEKtk=; b=cIds4l6WzQLJSj+0gTupuVeSyiqfDzfuUx5eWGIEWBDsJm8779tYAlGN3lZUIwpghc TZ9tPazd3ggar59XCDJU7pf+53cON7JgjDSllP0Iiq6/lgLc4UJkeQxkeiVtRjYZLzPD KeRM/lNKcvuij+E/nTvDNHKO4myUDzBEP7gKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OloFHqXD0l+5xL1vIbVxK1ZZk0pMA/nvjWViFfgEKtk=; b=iPvOa8eT23kStNhDKyD5GTRGhs/LPEbyRDypIQ1MvXR/bHKi31E2daiklUSU2kjcz6 LQ8ipEKIoPwaPsZgSMDSJFOv3mF1bDNc4O4pmreaskR7nijuJJsSFlgPWjoZIXrF9oBu 1ELfaxWn3K37JwprOMXOoVppJ5G9g6oo5no0vUo7FKU/sd7QSYst/RHs5lsTd6CikVhy 6LSN6blInU6RJHPwMOh4bAzX4Z/e0sMcTIqmBWIFwH43E4IxyBikW5aLUwKus5RNRgcq 7/WwQyWPmeLMOb59Wfcz3eBOkx8b7oYAzoDfRV3VAJjuu9CyBLfpVZOGmTephCj1qK8v 7ZEg== X-Gm-Message-State: ANhLgQ1oi11wotsx2id3N+34CJ2L8NQPwJkL9JwT5XXPzOKiTj5VeCbk R5wkEiQ2R0H62cM+qy7qc5peMuDrMUFqF4DsRviyafNKY2k= X-Google-Smtp-Source: ADFU+vv+7JGG60bHbaUYLE9JtffFVt6nv3M045pIvuhM2E+/GFWT7dExVZ4xc6H5maYA7q2ylaoXaq6kyzFZRe+CrQo= X-Received: by 2002:ad4:4802:: with SMTP id g2mr8998942qvy.95.1585244836070; Thu, 26 Mar 2020 10:47:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 26 Mar 2020 10:47:04 -0700 Message-ID: To: Devin Mullins Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000056938705a1c59328" Archived-At: Subject: Re: [Wpack] Displaying "(offline)" in URL X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 17:47:21 -0000 --00000000000056938705a1c59328 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it makes a lot of sense to have the client tell the user that they're looking at possibly-out-of-date information. In addition to Mike Bishop's "Origin as of ", I think the idea of a "Snapshot" indication in the url bar has come up. You can see something similar (using "Offline", actually) on Android Chrome if you use the =E2=A4=93 icon to sav= e a page locally and then open it: https://support.google.com/chrome/answer/7343019?co=3DGENIE.Platform%3DAndr= oid&hl=3Den&oco=3D1 . Individual pages can use Javascript to warn users about stale content in their own UI too. I agree that it's worth letting client UX teams figure out what terminology is best for their users instead of having this group try to guess something, but I think the IETF is pretty good about avoiding this sort of precise UX decision. Jeffrey On Wed, Mar 25, 2020 at 5:20 PM Devin Mullins wrote: > Catching up on https://www.ietf.org/jabber/logs/wpack/2020-03-25.html, I > saw some mention of displaying "offline" in the URL/origin bar if the > transfer request takes longer than a few seconds. Perhaps I'm picking a > nit, but I'd caution against displaying "offline" unless that's really th= e > case. The user may confusedly try to restart their router or something. > Then again, I'm not a UX person, so grain of salt. > > Thanks, > Devin > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --00000000000056938705a1c59328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I think it makes a lot of sense to have the client tell th= e user that they're looking at possibly-out-of-date information. In add= ition to Mike Bishop's "Origin as of <datetime>", I thi= nk the idea of a "Snapshot" indication in the url bar has come up= . You can see something similar (using "Offline", actually) on An= droid Chrome if you use the=C2=A0=E2=A4=93 icon to save a page locally and = then open it:=C2=A0https://support.= google.com/chrome/answer/7343019?co=3DGENIE.Platform%3DAndroid&hl=3Den&= amp;oco=3D1.

    Individual pages can use Javascript to = warn users about stale content in their own UI too.

    I ag= ree that it's worth letting client UX teams figure out what terminology= is best for their users instead of having this group try to guess somethin= g, but I think the IETF is pretty good about avoiding this sort of precise = UX decision.

    Jeffrey

    On Wed, Mar 25, 20= 20 at 5:20 PM Devin Mullins <twifkak=3D40google.com@dmarc.ietf.org> wrote:
    Catching up on=C2= =A0https://www.ietf.org/jabber/logs/wpack/2020-03-25.html, I = saw some mention of displaying "offline" in the URL/origin bar if= the transfer request takes longer than a few seconds. Perhaps I'm pick= ing a nit, but I'd caution against displaying=C2=A0"offline" = unless that's really the case. The user may confusedly try to restart t= heir router or something. Then again, I'm not a UX person, so grain of = salt.

    Thanks,
    Devin
    _______________________________________________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --00000000000056938705a1c59328-- From nobody Thu Mar 26 11:11:23 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E523A085C for ; Thu, 26 Mar 2020 11:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 Cjsc0180aFzQ for ; Thu, 26 Mar 2020 11:11:19 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F257F3A0BFB for ; Thu, 26 Mar 2020 11:11:18 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id cy12so3522618qvb.7 for ; Thu, 26 Mar 2020 11:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sffl0Bi7HD5HiT6zhc6b6vvZl5L37pNnouMu2cwoWqs=; b=k2BklW6onAuAF/blmFrUwcQxuNlAYt6qBOnjD1Cfz6UH+JhFyEsd8Qf5O029AegAca iGyViU35uocaf4FzDqPc1tciJ3Lves0WUzc34yeagiYxCjMkiefhqBoWBpeXgAJfjQ8n 7InLYcpbJqI2I2Mht9TKnmXvicZk2RtmsU8Yg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sffl0Bi7HD5HiT6zhc6b6vvZl5L37pNnouMu2cwoWqs=; b=JuuhiVo9XMOi8dctsH4weU7s6h6877ODeGa3WvB+I0nYQcA4yarP67pS7rrWJkM5hd O4DWoj2cYsQEQQYaQdu4zcWBSyRqsfSpBTst7pkYAKjUzYXxyOfou62mn8mD1yyXJ6kp pQvRXSssRMWXrtC33Dao2iXQ3kTtCTF4GZlTLbvR6C7JfL2LdqwbpM0NpwGgOhNUfqN2 cPcnb3hdJ8ELDLhQ4Vb/+mOnwIKeq2dWLA8cpyOvK9+sSNbMMTA+D01W49xXyWy1iWNZ qjbh3U2Hu41XOYxLeEkSfB+8FycrBqK2RSWviP+pN1TfovmutTcdFStor4iSRTyIc2oh 2HLA== X-Gm-Message-State: ANhLgQ1EZUYqMG3rzwNmn2oa9JZWiKr3LPr9ZM6xYj0QbHTcHy/2XxNt JABPFWiVkPOJPRts125TFxc6qMwsR+TJBcXjsQBPTQ== X-Google-Smtp-Source: ADFU+vszV8ipYM9Kcz1EbmpJF9j46gJ9hqGbyIcp18xcvwc6G24MfNIP+355HZvaSwvScZK5GpmSs25sQJ3Gl3uJ8Ec= X-Received: by 2002:a0c:f207:: with SMTP id h7mr9455842qvk.20.1585246277355; Thu, 26 Mar 2020 11:11:17 -0700 (PDT) MIME-Version: 1.0 References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> <002401d6033a$f70fe990$e52fbcb0$@acm.org> In-Reply-To: <002401d6033a$f70fe990$e52fbcb0$@acm.org> From: Jeffrey Yasskin Date: Thu, 26 Mar 2020 11:11:01 -0700 Message-ID: To: Larry Masinter Cc: WPACK List Content-Type: multipart/alternative; boundary="0000000000003f30d505a1c5e939" Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:11:21 -0000 --0000000000003f30d505a1c5e939 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's my fault that much more discussion has happened on https://github.com/WICG/webpackage/ PRs and issues, and even private discussions, than this mailing list. Sorry about that. I don't think you've missed anything significant since IETF 106, as I was mostly waiting for the WG to finish spinning up. Hopefully having actual chairs will help us do better here in the future. https://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.html = has a lot of good advice on how to manage this. I prefer the work mode it describes as "Issue Discussion Mode ", with the tweak that even in the "Early Design Phase", the editor gets at least another person to review each PR, but I'm happy to use whatever the whole group decides on. I don't think we've discussed the question of what a signature should mean, either on the list or as a github issue. I have opinions there that I think match what you want, which I'll describe in a separate thread. I'm also happy to chat directly, or I believe we can schedule targeted interim meetings if that sounds useful. I *suspect* that we'll come up with something that can replace at least some multipart/* (certainly MHTML is a goal) and PDF use cases, and like the other secondary use cases, I support small tweaks to the format to support that, as long as it doesn't compromise the primary use cases. Jeffrey On Wed, Mar 25, 2020 at 11:51 PM Larry Masinter wrote: > I=E2=80=99m sorry. I=E2=80=99m fine with using GitHub, I was grousing abo= ut something else > -- the difficulty in searching in GitHub comments and responses to find o= ut > what things were the focus of the work of the working group. > > I=E2=80=99m on the mailing list, but it=E2=80=99s clearly some other foru= m in which the > discussion about the different kinds of signing and trust and identity ar= e > being discussed. > > Or not. I want to learn enough of the language you use in these > discussions so I can explain and be understood. I suspect your requiremen= ts > may be at the wrong level (you=E2=80=99re starting with a very operationa= l view of > the =E2=80=9Cweb security model=E2=80=9D (if there is such a thing) by tr= anslating TLS into > digital signatures and asking who signs what and how can you do that with > minimal changes to the browser =E2=80=9Csecurity model=E2=80=9D. > > Asking what=E2=80=99s the origin of a data: URL is asking the wrong quest= ion. The > problem is the notion of =E2=80=9Corigin=E2=80=9D is tied to the HTTP tra= nsaction model. > > PDF signatures are package signatures, but the signature isn=E2=80=99t ti= ed to the > origin of any of the parts. Isn=E2=80=99t that what you want when you wan= t to show > something is trusted not because it was assembled from trusted parts but > because you trust the assembler? What use case forces you to assume that > interpretations packages have to look the same in the browser showing URL= s? > > > > > > Anyway, this is the kind of question / discussion I=E2=80=99d try to do i= n the > hallway at a F2F IETF. I don=E2=80=99t see the mailing list, a github iss= ue, or a > group videoconference call. But if you want to chat, let me know. > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --0000000000003f30d505a1c5e939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It's my fault that much more discussion has happe= ned on=C2=A0https://github.= com/WICG/webpackage/=C2=A0PRs and issues, and even private discussions,= =C2=A0than this mailing list. Sorry about that. I don't think you'v= e missed anything significant since IETF 106, as I was mostly waiting for t= he WG to finish spinning up. Hopefully having actual chairs will help us do= better here in the future.=C2=A0

    http= s://ietf-gitwg.github.io/using-github/draft-ietf-git-using-github.html= =C2=A0has a lot of good advice on how to manage this. I prefer the work mod= e it describes as "Issue Discus= sion Mode", with the tweak that even in the "Early Design Pha= se", the editor gets at least another person to review each PR, but I&= #39;m happy to use whatever the whole group decides on.

    I don't think we've discussed the question of what a signatur= e should mean, either on the list or as a github issue. I have opinions the= re that I think match what you want, which I'll describe in a separate = thread. I'm also happy to chat directly, or I believe we can schedule t= argeted interim meetings if that sounds useful.

    I = *suspect* that we'll come up with something that can replace at least s= ome multipart/* (certainly MHTML is a goal) and PDF use cases, and like the= other secondary use cases, I support small tweaks to the format to support= that, as long as it doesn't compromise the primary use cases.

    Jeffrey

    On Wed, Mar 25, 2020 at 11:51 PM Larry Masinter <= ;LMM@acm.org> wrote:

    I=E2=80=99m sorry. I=E2=80=99m fine with using GitHub, I wa= s grousing about something else -- the difficulty in searching in GitHub co= mments and responses to find out what things were the focus of the work of = the working group.

    I=E2=80=99m on t= he mailing list, but it=E2=80=99s clearly some other forum in which the dis= cussion about the different kinds of signing and trust and identity are bei= ng discussed.

    Or not.=C2=A0 I want = to learn enough of the language you use in these discussions so I can expla= in and be understood. I suspect your requirements may be at the wrong level= (you=E2=80=99re starting with a very operational view of the =E2=80=9Cweb = security model=E2=80=9D (if there is such a thing) by translating TLS into = digital signatures and asking who signs what and how can you do that with m= inimal changes to the browser =E2=80=9Csecurity model=E2=80=9D.

    Asking what=E2=80=99s the origin of a data: UR= L is asking the wrong question. The problem is the notion of =E2=80=9Corigi= n=E2=80=9D is tied to the HTTP transaction model.

    PDF signatures are package signatures, but the signature isn= =E2=80=99t tied to the origin of any of the parts. Isn=E2=80=99t that what = you want when you want to show something is trusted not because it was asse= mbled from trusted parts but because you trust the assembler? What use case= forces you to assume that interpretations packages have to look the same i= n the browser showing URLs?

    = =C2=A0

    =C2=A0

    Anyway, this is the kind of question / discussion I=E2=80=99d t= ry to do in the hallway at a F2F IETF. I don=E2=80=99t see the mailing list= , a github issue, or a group videoconference call. But if you want to chat,= let me know.

    ________________________________= _______________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --0000000000003f30d505a1c5e939-- From nobody Thu Mar 26 11:43:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B073A0959 for ; Thu, 26 Mar 2020 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 fZO3fpYZCpiG for ; Thu, 26 Mar 2020 11:43:21 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5372B3A0E45 for ; Thu, 26 Mar 2020 11:43:21 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id a5so6333700qtw.10 for ; Thu, 26 Mar 2020 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3FLIeN4SpFrYB0ucMilXplEAU8yLpo7N5QgdW8mEUY=; b=MRIPcSzjbvyXRrO8k/+LKf7trZpRU1uMrb1mmf+GlhjBJLqaHTHAhGnkwlHPhB0vgc wWezScMhX9Jn0R63ZJ3MyloTp+uNLmac9X6UYxi55SNkzSz1uPLUXw6j66KyXRD6HGvl 01PFxQTsYpu6IQjcoefBxNDzWuYDLHPt+Yv1s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3FLIeN4SpFrYB0ucMilXplEAU8yLpo7N5QgdW8mEUY=; b=HUS+yQ7EEbtvd9fTR1iiVSv7eCV54aX0Fi8NHrC5xA0TDDQ/x7T45DxyFClAE02LZf 2xaI4LVFPAxCAKAFgpFF0i/vrvOQitM5rTWUgQXdlAD/tg+CkHRsIloFfJMFiLqGRMHR k0Kw0aJxq93JRxZCzawlooYpeAJO55Em4MNaXdFro36XFu810QRQkjgiPYKB1dR9gdgW l21SCWhxyQCEzmcmHIKEsbJqSxoGTt7+HjGh8W2kgLmBIjuW3r1KEH2EbqLqwXCZRjBU rgmcyQJbqPcQMtVqbNLtvmZmsTejX8Hwrt0FbKA5rzdwwOeWgwSgTjWxc/RAyi5QTQqV +q2g== X-Gm-Message-State: ANhLgQ2b0ID3PccFZm1FZjNB+D4RxGNigxptWZK/lr3QgKeSFfXLoB97 /dWq/HKYZX7Csgx7JTiAb4uE2XfOwUVD+ivhm7GQBLBJ X-Google-Smtp-Source: ADFU+vv8iKvFAJ65Wkrfvip6nRp64EcHM1mAv/b4M+soLNRGVD3oKknBrABAKlneA1p9DaPslP0jkrwTddyP8p03YTU= X-Received: by 2002:ac8:fe9:: with SMTP id f38mr9876776qtk.130.1585248199652; Thu, 26 Mar 2020 11:43:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 26 Mar 2020 11:43:07 -0700 Message-ID: To: Ben Schwartz Cc: WPACK List Content-Type: multipart/alternative; boundary="000000000000d2a23005a1c65ba9" Archived-At: Subject: Re: [Wpack] Security, authority, and privacy X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:43:35 -0000 --000000000000d2a23005a1c65ba9 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 3:06 PM Ben Schwartz wrote: > It seems to me that there are two main kinds of permission that concern us > here. > > 1. Permission to display content as the origin. > 2. Permission to perform I/O while acting as the origin. > > I think we should accept signed exchanges as sufficient for #1 before > online verification completes, but require online verification for #2. > This tightly limits any stolen key or stale content attack: the attacker > can impersonate the origin until online verification completes, but cannot > do much damage during that period. > > (This is not a comment on implementation, which could be similar to Martin > Thomson's proposal, or not.) > > In this model, we would queue all pending I/O until verification > completes. (The relevant APIs should all be asynchronous). This isn't > compatible with every use case we have, but it covers most of them. > > "Early actions" and the corresponding state transfer could be added later > if needed, but I think tackling that topic now would likely delay the > standards process considerably. I also think most use cases would prefer > that I/O simply be queued, so the state-transfer system should be clearly > opt-in, only for the most sophisticated developers. > I like the general suggestion to avoid side-effects on the origin's online state until the client has checked with the online origin, if we can make the transfer work, but I'm wary of a couple aspects of this implementation: A) I'm not sure what "I/O" means here. One could make a small camera-effects website that works entirely offline, but that does Input through the camera and Output by, perhaps, being able to let the user save files (aside from the obvious one of drawing to the screen). You seem to mean writing to local storage and fetching remote resources with a particular value in the Origin header. Is that all? B) Having all writes to storage queue instead would break offline use of content-authoring sites, which is something I wouldn't want to lose. I think use cases where a user wants to avoid expensive data transfer but still has a connection, still work, but as Ted Hardie has described, there are lots of cases where people actually can't connect to the global internet for periods of time, and I think we'd lose all of their use cases except for pure content consumption. Jeffrey --000000000000d2a23005a1c65ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Mar 25, 2020 at 3:06 PM Ben Schwa= rtz <bemasc=3D40google.co= m@dmarc.ietf.org> wrote:
    It seems to me = that there are two main kinds of permission that concern us here.

    <= /div>
    1. Permission to display content as the origin.
    2. Perm= ission to perform I/O while acting as the origin.

    = I think we should accept signed exchanges as sufficient for #1 before onlin= e verification completes, but require online verification for #2.=C2=A0 Thi= s tightly limits any stolen key or stale content attack: the attacker can i= mpersonate the origin until online verification completes, but cannot do mu= ch damage during that period.

    (This is not a comme= nt on implementation, which could be similar to Martin Thomson's propos= al, or not.)

    In this model, we would queue all pen= ding I/O until verification completes.=C2=A0 (The relevant APIs should all = be asynchronous).=C2=A0 This isn't compatible with every use case we ha= ve, but it covers most of them.

    "Early action= s" and the corresponding state transfer could be added later if needed= ,=C2=A0but I think tackling that topic now would likely delay the standards= process considerably.=C2=A0 I also think most use cases would prefer that = I/O simply be queued, so the state-transfer system should be clearly opt-in= , only for the most sophisticated developers.
    =
    I like the general suggestion to avoid side-effects on the o= rigin's online state until the client has checked with the online origi= n, if we can make the transfer work, but I'm wary of a couple aspects o= f this implementation:

    A)=C2=A0I'm not sure wh= at "I/O" means here. One could make a small camera-effects websit= e that works entirely offline, but that does Input through the camera and O= utput by, perhaps, being able to let the user save files (aside from the ob= vious one of drawing to the screen). You seem to mean writing to local stor= age and fetching remote resources with a particular value in the Origin hea= der. Is that all?

    B) Having all writes to storage = queue instead would break offline use of content-authoring sites, which is = something I wouldn't want to lose. I think use cases where a user wants= to avoid expensive data transfer but still has a connection, still work, b= ut as Ted Hardie has described, there are lots of cases where people actual= ly can't connect to the global internet for periods of time, and I thin= k we'd lose all of their use cases except for pure content consumption.=

    Jeffrey
    --000000000000d2a23005a1c65ba9-- From nobody Thu Mar 26 11:51:31 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5EE3A0E36 for ; Thu, 26 Mar 2020 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 EYcMVneFAKye for ; Thu, 26 Mar 2020 11:51:17 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7973A0E43 for ; Thu, 26 Mar 2020 11:51:16 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id q188so7950580qke.8 for ; Thu, 26 Mar 2020 11:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clHyGpkZOR3+nROHV268+ZskwH943EuLyMOzwLgRHVI=; b=Y9BXeJOZkqg7ZEcnntr3O1Dp23bheYVXtVRYBZQVPAfcJ4a2fuhi2nzodJEwrbcXyP KZQeLsPyu36OkBaS+cu6H5tyy8nffFNWw8jHgzQJfErTHkj6Z/7j03/rC9mRyx6H4+3I DvHBnEKQaHavXmnRdZBbAhNrgEJS+6XZH22VI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clHyGpkZOR3+nROHV268+ZskwH943EuLyMOzwLgRHVI=; b=rnK1fn/qDW/HdPLhnyNtIERwyEb7EHQVFCAWrq0DG55/h4kUqLGT8EomNMaTaqg+KW OcOW/7u7yme6iXvbtfS0dLPQ2jzYOFA0SAyf3kg7QVBO0z9AzXP2uFP44PFozau9ZjiQ piQU39gQa44bi77bo1JxuEY61JucbZjp86kQttzYTan9+xJrch4HOewX9Az52WAp0s2w tYxamJNr/qeEI7fcEn/LE4o5yHkr4T7dZqvuUHgYIQpwYfox/osy6VV2TMcZqOICQRHB rKuVBPmP9FoF1dMSlQ1/HQT/Gly8j6/qVdqb6zy92V7OOckTur/yL88ASerrPrJ5draN HcUw== X-Gm-Message-State: ANhLgQ21C01Kk9P//tOSxwQIihH3euarJYp+r8IKGaHUcUvR7EnxxCUS pmxQ1teGpl7f2pxrpVtf8Bqw72v2E9odeCAzBebyCmimKiM= X-Google-Smtp-Source: ADFU+vv9l6qEa5UoQUhpLuLQXuoW96goNpXTP+m2aFhAwp+o2wdVbywHDf3tkf06g9aQlGQbz343LyE9pkkKtv8L+zc= X-Received: by 2002:a37:4949:: with SMTP id w70mr10120741qka.38.1585248675425; Thu, 26 Mar 2020 11:51:15 -0700 (PDT) MIME-Version: 1.0 References: <00f301d6038f$49451880$dbcf4980$@acm.org> In-Reply-To: <00f301d6038f$49451880$dbcf4980$@acm.org> From: Jeffrey Yasskin Date: Thu, 26 Mar 2020 11:51:03 -0700 Message-ID: To: Larry Masinter Cc: WPACK List Content-Type: multipart/alternative; boundary="0000000000002e442a05a1c678ab" Archived-At: Subject: Re: [Wpack] URLs for older timestamped data X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:51:29 -0000 --0000000000002e442a05a1c678ab Content-Type: text/plain; charset="UTF-8" This seems related to the Memento framework in https://tools.ietf.org/html/rfc7089 that some of the Web Archiving folks mentioned at the ESCAPE workshop: https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf. Are you suggesting that these would be good URIs to use for signed origins? Or something else? Thanks, Jeffrey On Thu, Mar 26, 2020 at 9:55 AM Larry Masinter wrote: > https://tools.ietf.org/html/draft-masinter-dated-uri > > > > This document defines two URI schemes. The first, 'duri' (standing > > for "dated URI"), identifies a resource as of a particular time. > > This allows explicit reference to the "time of retrieval", similar to > > the way in which bibliographic references containing URIs are often > > written. > > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --0000000000002e442a05a1c678ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    This seems related to the Memento framework in=C2=A0https://tools.ietf.org/html/rfc70= 89=C2=A0that some of the Web Archiving folks mentioned at the ESCAPE wo= rkshop:=C2=A0https://www.iab.org/wp-content/IAB-uploads/2019/06/sawoo= d-alam-2.pdf.

    Are you suggesting that these would be= good URIs to use for signed origins? Or something else?

    Thanks,
    Jeffrey

    =
    On Thu, Mar 26, 2020 at 9:55 AM Larry= Masinter <LMM@acm.org> wrote:
    =

    https://tools.ietf.org/html/draft-masi= nter-dated-uri=C2=A0

    = =C2=A0

    =C2=A0 This document defines two URI scheme= s.=C2=A0 The first, 'duri' (standing

    =C2=A0=C2=A0 for "dated URI"), identifies a resource as = of a particular time.

    =C2=A0=C2=A0 T= his allows explicit reference to the "time of retrieval", similar= to

    =C2=A0=C2=A0 the way in which bi= bliographic references containing URIs are often

    =C2=A0=C2=A0 written.

    =C2=A0

    ________________________________= _______________
    Wpack mailing list
    Wpack@ietf.org
    https://www.ietf.org/mailman/listinfo/wpack
    --0000000000002e442a05a1c678ab-- From nobody Thu Mar 26 12:45:30 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247353A043D for ; Thu, 26 Mar 2020 12:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JKJDD_t4OuzF for ; Thu, 26 Mar 2020 12:45:26 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B1C3A03EA for ; Thu, 26 Mar 2020 12:45:26 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id z18so8074034wmk.2 for ; Thu, 26 Mar 2020 12:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0i+K4lAYp2qYcbfhN5T13xnmCqimL/ouSbQ/yT+7GhA=; b=NqcPy3UaVtt4+JVwLAPrKDHF+ELR7SBqrOsXsRg8K5k5YPr9x5J34jdlXbtn8J+WHi hZHuzMizy6VxYvMKaz6Tp0kIjCskTk0QSf/4miUqOYUoHtSS0g7fgMjeA8Gv/zr3/oDs fxjIfDrsad5Y5NkPNIuLQpc/Wv9BhAubZmaRlA6PJ8fDMsIuibGvGIkl62chOAx2Z9A6 xcMoJbqHmCmBG/JsJtnm8SF9t2FbmMKsQibySpAsgfj8pvbTNEBTfXt2QipoAx5TSBmj swAPjn3I3+9H/kZ3K4K7BHq18MNKYf29KfIIxrRq6NRdJJRL6v/J/uXXqLqVCcHKxpRu A1DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0i+K4lAYp2qYcbfhN5T13xnmCqimL/ouSbQ/yT+7GhA=; b=Lbl07UeMFam+fLXwdQaopyLkgyEqdZxstct4PTSA19MegtNbafuEDrR744W59JnC2Q c8DOgLLe6epWTA85C48zlYYSp8zRpCYmhBhpzMmDuFQnIdG7H+TJjK6E0GM1CoqDv5Or buJc4qtWYqLYzY5iHqZpx0sLabQkcZvJLGOMucaQaJTZUtJyUHlxbcbIN1mgUo3ikuN8 MFZusdtOnGoD0CDPavILzx4tADJuF38L4MrX7ewv40k2cQpJF/y0iY8AgpfZClSO5t/a RdMO58UkEXbFf2Tragrk0USNsFnOnt5dE8bRgV6Jk43u7OcR/ea23iQCslNjsbpAaJwR GCRA== X-Gm-Message-State: ANhLgQ2toQKiKSAQb+38RuYCI5D+12I901K9DZxBRfIamPpYhwwHO64r KDLRTl1SSCbiYnIrkes3nJ6tZoO67M8G2qaB8ffW0uOe X-Google-Smtp-Source: ADFU+vsYDNxwcZgFbaz8bs+Bwv6Ze63h5hfKPdb+IwED/MrKml8WlshRZ8nd70W/OumOymdPQ6bYt2gzNIemnNCbd08= X-Received: by 2002:adf:fd44:: with SMTP id h4mr8688190wrs.177.1585251923898; Thu, 26 Mar 2020 12:45:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Thu, 26 Mar 2020 15:45:10 -0400 Message-ID: To: Jeffrey Yasskin Cc: WPACK List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d85d1605a1c739bf" Archived-At: Subject: Re: [Wpack] Security, authority, and privacy X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 19:45:28 -0000 --000000000000d85d1605a1c739bf Content-Type: multipart/alternative; boundary="000000000000ce2fa505a1c73971" --000000000000ce2fa505a1c73971 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 26, 2020 at 2:43 PM Jeffrey Yasskin wrote: > On Wed, Mar 25, 2020 at 3:06 PM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> It seems to me that there are two main kinds of permission that concern >> us here. >> >> 1. Permission to display content as the origin. >> 2. Permission to perform I/O while acting as the origin. >> >> I think we should accept signed exchanges as sufficient for #1 before >> online verification completes, but require online verification for #2. >> This tightly limits any stolen key or stale content attack: the attacker >> can impersonate the origin until online verification completes, but cannot >> do much damage during that period. >> >> (This is not a comment on implementation, which could be similar to >> Martin Thomson's proposal, or not.) >> >> In this model, we would queue all pending I/O until verification >> completes. (The relevant APIs should all be asynchronous). This isn't >> compatible with every use case we have, but it covers most of them. >> >> "Early actions" and the corresponding state transfer could be added later >> if needed, but I think tackling that topic now would likely delay the >> standards process considerably. I also think most use cases would prefer >> that I/O simply be queued, so the state-transfer system should be clearly >> opt-in, only for the most sophisticated developers. >> > > I like the general suggestion to avoid side-effects on the origin's online > state until the client has checked with the online origin, if we can make > the transfer work, but I'm wary of a couple aspects of this implementation: > > A) I'm not sure what "I/O" means here. One could make a small > camera-effects website that works entirely offline, but that does Input > through the camera and Output by, perhaps, being able to let the user save > files (aside from the obvious one of drawing to the screen). You seem to > mean writing to local storage and fetching remote resources with a > particular value in the Origin header. Is that all? > I think fetching any remote resource would have to be delayed, if stolen key attacks are in-scope. Imagine a package (signed with a stolen key) that presents a login screen, collects user passwords, and sends them as "anonymous" GET requests to the attacker's server. Local filesystem reads should be OK, but filesystem writes would have to wait. Otherwise, a package (signed with a stolen key) could "download" a .exe that is malware. > B) Having all writes to storage queue instead would break offline use of > content-authoring sites, which is something I wouldn't want to lose. I > think use cases where a user wants to avoid expensive data transfer but > still has a connection, still work, but as Ted Hardie has described, there > are lots of cases where people actually can't connect to the global > internet for periods of time, and I think we'd lose all of their use cases > except for pure content consumption. > I agree with this analysis, but I think the potential "offline webapp" users are vastly outnumbered by the potential offline content readers, so we should focus on the larger, easier case first, and add optional complex features for the fancier use cases later. > Jeffrey > --000000000000ce2fa505a1c73971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Thu, Mar 26, 2020 at 2:43 PM Jeffr= ey Yasskin <jyasskin@chromium.o= rg> wrote:
    On Wed, Mar 25, 2020 at 3:06 PM Ben Sch= wartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
    It seems to me that there are two main kinds of permission that concer= n us here.

    1. Permission to display content as the origi= n.
    2. Permission to perform I/O while acting as the origin.
    =

    I think we should accept signed exchanges as sufficient= for #1 before online verification completes, but require online verificati= on for #2.=C2=A0 This tightly limits any stolen key or stale content attack= : the attacker can impersonate the origin until online verification complet= es, but cannot do much damage during that period.

    = (This is not a comment on implementation, which could be similar to Martin = Thomson's proposal, or not.)

    In this model, we= would queue all pending I/O until verification completes.=C2=A0 (The relev= ant APIs should all be asynchronous).=C2=A0 This isn't compatible with = every use case we have, but it covers most of them.

    "Early actions" and the corresponding state transfer could be a= dded later if needed,=C2=A0but I think tackling that topic now would likely= delay the standards process considerably.=C2=A0 I also think most use case= s would prefer that I/O simply be queued, so the state-transfer system shou= ld be clearly opt-in, only for the most sophisticated developers.

    I like the general suggestion to avoid s= ide-effects on the origin's online state until the client has checked w= ith the online origin, if we can make the transfer work, but I'm wary o= f a couple aspects of this implementation:

    A)=C2= =A0I'm not sure what "I/O" means here. One could make a small= camera-effects website that works entirely offline, but that does Input th= rough the camera and Output by, perhaps, being able to let the user save fi= les (aside from the obvious one of drawing to the screen). You seem to mean= writing to local storage and fetching remote resources with a particular v= alue in the Origin header. Is that all?
    =
    I think fetching any remote resource would have to be delaye= d, if stolen key attacks are in-scope.=C2=A0 Imagine a package (signed with= a stolen key) that presents a login screen, collects user passwords, and s= ends them as "anonymous" GET requests to the attacker's serve= r.

    Local filesystem reads should be OK, but filesy= stem writes would have to wait.=C2=A0 Otherwise, a package (signed with a s= tolen key) could "download" a .exe that is malware.
    =C2= =A0
    B) Having all writes to storage queue inst= ead would break offline use of content-authoring sites, which is something = I wouldn't want to lose. I think use cases where a user wants to avoid = expensive data transfer but still has a connection, still work, but as Ted = Hardie has described, there are lots of cases where people actually can'= ;t connect to the global internet for periods of time, and I think we'd= lose all of their use cases except for pure content consumption.

    I agree with this analysis, but I = think the potential "offline webapp" users are vastly outnumbered= by the potential offline content readers, so we should focus on the larger= , easier case first, and add optional complex features for the fancier use = cases later.


    Jef= frey
    --000000000000ce2fa505a1c73971-- --000000000000d85d1605a1c739bf Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCBAq1ia7Y5yrZptRTfHHbZSjscwSDe9ZEm6yGBkgelFdDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjYxOTQ1MjRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAnCVgXIweCbLPGgiw2xdovA8wa0duiJxJgCTFbchWNCT8IrKjNbTUWsyAy585W50YTROYJrlx cKsfgiJ9cA9wkMZ0h3zIq43kBVUyG1QBs5GpHCqDHCAgxrFJDm3mmH8swpGAugqYQw7W8Qh2h+78 31gY+f6r81l/ahUGQ+YEn8qyuo6MR9ydzucSvnE/nIX6ezGGS0MrhfvUBWBnCe3rdzdVxK75oVpf YzPsvsmq432lgde5u7tnU5/hhQK56oLxJFtjBe6rL2WTbMxI0W08+tcmoYFhRl2cC6R+LCYsRkO1 XT1zcXJIZpQmbeNBZPV3zUjwG3bi51zRw1/NQMwFcw== --000000000000d85d1605a1c739bf-- From nobody Thu Mar 26 21:32:47 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752FC3A086B for ; Thu, 26 Mar 2020 21:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=lowentropy.net header.b=AxXtCqx+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JPSF8jQE 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 rIS-HAMkwfZz for ; Thu, 26 Mar 2020 21:32:42 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24563A0860 for ; Thu, 26 Mar 2020 21:32:42 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id D828582F; Fri, 27 Mar 2020 00:32:40 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 27 Mar 2020 00:32:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=bojf6clFI5On8EK76juaXx9IWVEY p4rJCzAf812YdH4=; b=AxXtCqx+9/77luxhriaY0oOKU+rV8Jv8InAkQdqN+iYb FejRXkKdi0crUEbOdVKJjnE0DMy8fJG56iPxyN5h+slL9Dr4HrTlxRYC//ho91Zd R1+v14Si6BEkPc0X/R82kOwvenxDdNJhIC3phRmxeruzJBwPODlZ8EWSV+jhsYUS vf4f0IxWUMMMd+i/+BRxuFlP0c0/OgcH2hTy6USFQx6K/AOclDX7EdSiioDAV6Ro ow6AiGN1CrHhOZYwoVOEyhgDcoe5Ax+NERZD9WssXPs7V/Fd/LF48jMmn8Xytmle X91GOwWByoyTLZzRuuNFpDyYPFauZHff34qvJYmpKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bojf6c lFI5On8EK76juaXx9IWVEYp4rJCzAf812YdH4=; b=JPSF8jQEdlkSxsyyeoZo1B DI0UOQzD14diIUdjtjsgXjhYwCqSHxRiXy9GO3mS6uP/Uupa/JUBJEZ7aaayrSWg 84XNm6mPkUnbPmusQveA4c04e+JeSTJoRaLr8+wqqU4+PHdYT0622+h9Fyf9dHmX UUePWFFR6ye6jyxtBcnyXGUcx6dvi86ZjzQinMJZZiLAAjYb+EyR+tZ6Fe73RFcN uegnn4Ps70LQ3PhJ1b9IuXcOKi41eJryO0zwUbrS33M5L/NHSAXJk0WfWvpVrmL9 mdG3TVQp/beJ+f46AX6eihr57dqze6Rs9u+eCzwhtwy879oyXDWK28ZvGvH4PGcg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehjedgudejudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 07FC9E00FF; Fri, 27 Mar 2020 00:32:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> Date: Fri, 27 Mar 2020 15:32:19 +1100 From: "Martin Thomson" To: "Devin Mullins" Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 04:32:45 -0000 Slowly crawling out from a giant pile of email... I will try to get to your longer email later. On Thu, Mar 26, 2020, at 10:03, Devin Mullins wrote: > In light of my comment about racing the Sec-CO request, a colleague > pointed out a potential hole in the double-hash scheme. There may be > flaws in below; I haven't thought about it too much. tone=apologetic>It may be worth more clearly defining the threat > model. I didn't have time to write this down, but I don't think that we need to worry so much about your attack. My threat model is similar to that of CORS. That is, the origin that is accepting - in this case content and state, in CORS a request - something should not be ignorant of what it is accepting. The reason I ended up at double-hashing was that a hash of the content is all that is really available. Having the server demonstrate that it is willing to accept a bundle without it being susceptible to making mistakes. After all, the bundle gets to write into the origin (and potentially exfiltrate from it after the transfer occurs). For something like a bundle, which encompasses a lot of things, having the server indicate that it knows the exact bundle is likely the best way to achieve some indication that it knows what it is getting into and consents to that. With a hash, you can split it, share part of it, and ask for the remainder. Or double-hash like a one-time password. If a bundle were signed, proof of ownership of the signing key might also work. In the end, if the bundle and origin want to collude I am of the opinion that that is fine. An origin that is willing to cooperate with the bundle is intentionally exposing itself to attacks on the integrity of its own state. Going to the extremes you describe is taking great care to aim your footgun. So it's not really worth stopping in my view. (I don't think that for a secure hash you can do anything like what you describe with fixpoints. Such a thing would seem to lead to trivial collision attacks. What seems more likely to me is that the bundle is constructed using some very precise canonicalization scheme such that it can be reconstructed from within and then hashed. That might be quite restrictive, but I don't see why it wouldn't work.) From nobody Thu Mar 26 21:43:54 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BA3A0776 for ; Thu, 26 Mar 2020 21:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=lowentropy.net header.b=CSpnwwsL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wou2Aqu9 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 UAuipR-q3Lpj for ; Thu, 26 Mar 2020 21:43:48 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A513A0764 for ; Thu, 26 Mar 2020 21:43:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 66CD88BE for ; Fri, 27 Mar 2020 00:43:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 27 Mar 2020 00:43:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=21uHH Qbm94xiHBlDDyX8AlM0X1HgtAFFAntSR5+u6TQ=; b=CSpnwwsLU2aOf7srmenSu PYaZWAdfvsaVkkUf+4CNlqBC89q3eF9RJtbNT2JECO/acLt+tQ+jbVEvxzkkTA+2 G9n1JtVeNUK6OD/sdzuGagi2CJx8VHR9RL4a0bdJOx70ec8b19ZjCbwYcNliD3en jBv71opQFT7fNgtvVZjXHSh4nlNde++cxIsdAnexC+jZmO+S4dPGS9yClhBSbNVQ 34oW5hJs80304dsuFuCkteDYoVmfxqr61y9BW6kzAijO9/suTIccvPdw4njsRCgG LdtsLZHjqF2DexX4HsEmEM128+Ai5qst9p4b5iamYEQrXitaO0X8StkYvPOS/k1/ A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=21uHHQbm94xiHBlDDyX8AlM0X1HgtAFFAntSR5+u6 TQ=; b=wou2Aqu9itaMO/iyE6Uvw2ZzCY6+uE/jI7vlFeP8mUVUQ7tM/1YYf/mbj K6SmLERjXbU0eregZvAf4+4bI6J/2mqZX+AA1O6mjXMl/p3+FQrtRbB7qlhlSXIJ snsa8tzzAkxS2Bjab4YttXw5Lmx7I8w6K98XD9fObbn6HeyR2Rf0uKj0Na5MqvAB KH7M8Mhw3Tl8ZzSj+xZMuy6+H3p2/23VBNMGv9eHJOwwVBYMF/SeuREDgW+giNPg z1g/ZO7kCAX8IVhY1eIhmc6s+U4TurwD5AedLiluMyWT0coQL3DfGq/XLnUQn5Bw 7VqXli5XPIymfu+eY5EOAdYyv389A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehjedgudejfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmthes lhhofigvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepqhhuihgtfihgrdhorhhgpd hivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8DA53E00BB; Fri, 27 Mar 2020 00:43:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <40772bfb-0ef7-4a07-850b-6f1881c06b45@www.fastmail.com> In-Reply-To: References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> <002401d6033a$f70fe990$e52fbcb0$@acm.org> Date: Fri, 27 Mar 2020 15:43:22 +1100 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 04:43:52 -0000 Anyone who is not following QUIC might find the amount of chatter there = daunting. But you might find the search capabilities in this tool helpf= ul: https://quicwg.org/base-drafts/issues.html#user(mcmanus) For instance, the above link lists everything Patrick has touched. (It's a little slow to load, because there is a lot of data, but it is s= till less than a visit to some sites.) On Fri, Mar 27, 2020, at 00:27, Patrick McManus wrote: > hi Larry - >=20 > I find for a wg I am heavily invested in, its often handy to subscribe= =20 > to all notifications of a github repo (and then mail filter). This=20 > creates the sort of serialized back and forth that conveys the tone an= d=20 > areas of emphasis of a very good email discussion. Its even better=20 > though because everything is properly threaded :) >=20 > I recognize that this is mostly helpful looking forward. ymmv > -P >=20 >=20 > On Thu, Mar 26, 2020 at 2:51 AM Larry Masinter wrote: > > I=E2=80=99m sorry. I=E2=80=99m fine with using GitHub, I was grousin= g about something else -- the difficulty in searching in GitHub comments= and responses to find out what things were the focus of the work of the= working group.____ >=20 > > I=E2=80=99m on the mailing list, but it=E2=80=99s clearly some other= forum in which the discussion about the different kinds of signing and = trust and identity are being discussed.____ >=20 > > Or not. I want to learn enough of the language you use in these disc= ussions so I can explain and be understood. I suspect your requirements = may be at the wrong level (you=E2=80=99re starting with a very operation= al view of the =E2=80=9Cweb security model=E2=80=9D (if there is such a = thing) by translating TLS into digital signatures and asking who signs w= hat and how can you do that with minimal changes to the browser =E2=80=9C= security model=E2=80=9D.____ >=20 > > Asking what=E2=80=99s the origin of a data: URL is asking the wrong = question. The problem is the notion of =E2=80=9Corigin=E2=80=9D is tied = to the HTTP transaction model.____ >=20 > > PDF signatures are package signatures, but the signature isn=E2=80=99= t tied to the origin of any of the parts. Isn=E2=80=99t that what you wa= nt when you want to show something is trusted not because it was assembl= ed from trusted parts but because you trust the assembler? What use case= forces you to assume that interpretations packages have to look the sam= e in the browser showing URLs?____ >=20 > > __ __ >=20 > > __ __ >=20 > > Anyway, this is the kind of question / discussion I=E2=80=99d try to= do in the hallway at a F2F IETF. I don=E2=80=99t see the mailing list, = a github issue, or a group videoconference call. But if you want to chat= , let me know.____ >=20 > > _______________________________________________ > > Wpack mailing list > > Wpack@ietf.org > > https://www.ietf.org/mailman/listinfo/wpack > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > From nobody Fri Mar 27 13:07:02 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5378D3A09A4 for ; Fri, 27 Mar 2020 13:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2KhKiUCfxnMr for ; Fri, 27 Mar 2020 13:06:57 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDA23A0BD8 for ; Fri, 27 Mar 2020 13:06:57 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id b12so12787788wmj.3 for ; Fri, 27 Mar 2020 13:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/pYGmjrYfKOTl1G9VmbeIcwWmsnbQRszEJMyL1RQmc=; b=Wql8t3ucAmEW3wNbPn+/JCER7923XV4fm3wXDJgOEmFBOSME3gwFC3bn6Ep3uiq1IU I3KlkXtX2NwLectMblwnmfMPMu4u70zx6lL8VnIajXJko8W5yIyNTJMzbFV39CfkkJOo +lK/mkog4GoZqrP8XD9s+ugj8A856wl9vX/5Sh/UZyb4hfO0qTaebWQiQdrBjdUv+Ght 8Fkqi4FiMWDjMVLgtE6YjVrtlExe4+/OnB57WRCfJEV0ekFKVxqwoOgZAl/55FzZqbuw 0gb6neNWfZGJ9iv2F3XXtLMdOD80o5VyNl9N6cBHiMK+wXUj8w9Wp3E/NugBt9oLK5JA JWZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G/pYGmjrYfKOTl1G9VmbeIcwWmsnbQRszEJMyL1RQmc=; b=pwin1AnNBwmntQ6MiR//oTRNez9tkcNJSHI14/m2Wrsbhh5kgFPWbe42320/kWhU+9 duhnTqSgLOZW1y+3hPo2CBu1sC6wVYb2G2nYPnc8QzC3BC400td2FwnAFiObvuvgg5Md V0E5zyEI0F6e1YQ3uNaIj3OQs+PxxhXfwKkUO2GRfInyotpsVJ+oFHqYMi2JegHx6mgk D2cPysz2Uo17VMOxV5V7qMPYVpgZmjYd9tsFqpXdGgrG5VbxkQ3tIOxmrur5pvdD265K Oo+PJickNDIVvBcQxVAwwF2uIPryuUD0Su5Hgjo+stR/lMrHZ4vJ9VGuustHPpASeWo2 UBFg== X-Gm-Message-State: ANhLgQ0EDI+nZYG9vvt24yYJ8vEZ6NqTuqAEOvMogAGnDgXVGSCiTPxw ZtKv9MpersUMz2XJPoKOXhhCpgYonaSkb90xf82pZCufglw= X-Google-Smtp-Source: ADFU+vtsnNlNkLAf0Q7VdJqEUQq5bDWJbz3/I81/274XaZfH7n34oUZ4O/6Yvw10E4UzJ9ryFvWqf1zQuuQNA1YqkVM= X-Received: by 2002:a1c:8008:: with SMTP id b8mr317791wmd.43.1585339615682; Fri, 27 Mar 2020 13:06:55 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> In-Reply-To: <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> From: Devin Mullins Date: Fri, 27 Mar 2020 13:06:29 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4a1ab05a1dba47a" Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 20:07:00 -0000 --000000000000a4a1ab05a1dba47a Content-Type: text/plain; charset="UTF-8" On Thu, Mar 26, 2020 at 9:32 PM Martin Thomson wrote: > Slowly crawling out from a giant pile of email... > No worries, understood; my life is a giant pile of email. > without it being susceptible to making mistakes ... if the bundle and > origin want to collude I am of the opinion that that is fine Ah, good to know. To clarify: Am I right in assuming my above proposed attack is somewhere on the spectrum of https://github.com/WICG/webpackage/pull/424 ? That is, it requires publisher server-side work, but is a potential end-run around mitigations to backchannel sharing such as per-origin IP obfuscation and fingerprint entropy reduction. If so, then what motivates https://github.com/martinthomson/wpack-content/issues/1 ? --000000000000a4a1ab05a1dba47a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Mar 26, 2020 at 9:32 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
    Slowly crawling out from a giant pile of email...

    No worries, understood; my life is a giant pile = of email.
    =C2=A0
    without it being susceptible to making mistakes ... if the bundle an= d origin want to collude I am of the opinion that that is fine
    =

    Ah, good to know. To clarify: Am I right in assuming my= above proposed attack is somewhere on the spectrum of=C2=A0https://github.com/WICG/webpackage= /pull/424=C2=A0? That is, it requires publisher server-side work, but i= s a potential end-run around mitigations to backchannel sharing such as per= -origin IP obfuscation and fingerprint entropy reduction. If so, then what = motivates=C2=A0https://github.com/martinthomson/wpack-content/issues/1 ?
    =
    --000000000000a4a1ab05a1dba47a-- From nobody Fri Mar 27 22:24:44 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3401C3A0BED for ; Fri, 27 Mar 2020 22:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3SiDYEbdlecB for ; Fri, 27 Mar 2020 22:24:40 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D049F3A0A47 for ; Fri, 27 Mar 2020 22:24:40 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id w9so4824103pjh.1 for ; Fri, 27 Mar 2020 22:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=pQ41dYeplIal7UD9HJ/HM9+stYAZo8WL3cTFZUoyqGg=; b=LlDVbwevJTGGI0cUkTYkbTYDV1PsgGf14Pf6XaSSA+nc+WySCgT/PLMb6J6cBp/wAs XLPZbKX1rVj+iCN0Nl7C+HnqD8qgzMEhWUYU6E9kQYtE0bNoe8kQ9LQDEix95KDzRxu1 T9Hi0kWByLhZAZNz0x6NndVGFIV0g7kNg9PraqsrAlHSON+MTPO7ygP3DrRYL7moVqJN JYf9SxX+RzF0tEpTgTJOGoC18GezCjureIyOQO3PhSDD7r03SIXYYfX12esZ3zlMZMyC ytOaZSE9RW148SZhWfV9oQnUwOThTSax6efuxjFAoHr5p6Q2UdGEjpt2Lvpo/elAn+5H YcZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pQ41dYeplIal7UD9HJ/HM9+stYAZo8WL3cTFZUoyqGg=; b=l9IDQFP7l6cZoL7PYCWnR8n3nTfJoasPtASH1Ypg/oWdQrZKxF3n7E9EYVpkMcxTTm UDjQ+z8J5wCftShB4RuqOzysKKqDAziMytH87uImAsqv2JcjK3jZIRVaC4BlBA64vgTD BTapFz+wj3lGgGKMLZzsB9agMgHxvekKPpceP8EucKPp13YUdYZdBHKPe9XVPK8nJwuQ MFdyurC3wfRtCyNcXP8Ur+SiAWxKbU0IWMFHIDgamAR6P4dPnDflcJO3DYVRlVlVD+F8 /BYmjHvwMfbLdlhsgiHAHs1zdhHZ+kJ7ve5gPyon9uam83Po3QtvETk/Gwf2bBs7nzAb IIOw== X-Gm-Message-State: ANhLgQ2kcVagfuprtqw+x1+vtjFouOa1owAezca71w2wPKskGaGp6tiG kc0OJloUNLvUrLQJ/eOr0+0dhmnzm7M= X-Google-Smtp-Source: ADFU+vsYD74Cmay/nnYN3qy8Q1xqxlYus2zzsU4OWX+XwthTVBcRovPUEKp5/fWvfRYjQfMUUJY8jw== X-Received: by 2002:a17:902:464:: with SMTP id 91mr2509418ple.261.1585373080142; Fri, 27 Mar 2020 22:24:40 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id b25sm5295978pfp.201.2020.03.27.22.24.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2020 22:24:39 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Martin Thomson'" , References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> <002401d6033a$f70fe990$e52fbcb0$@acm.org> <40772bfb-0ef7-4a07-850b-6f1881c06b45@www.fastmail.com> In-Reply-To: <40772bfb-0ef7-4a07-850b-6f1881c06b45@www.fastmail.com> Date: Fri, 27 Mar 2020 22:24:38 -0700 Message-ID: <007801d604c1$2db98320$892c8960$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEM67UzIqgh1ZbNVvz9bahXlI6eOwGswW5pALwgHvwBiQ7vgAJBZ7UxApa+CcepqUYcwA== Content-Language: en-us Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 05:24:42 -0000 https://www.ietf.org/id/draft-ietf-git-using-github-06.html#name-typical-= working-group-polic My request is that you follow those guidelines and pay attention to the = cautions within about using the mailing list to encourage and gauge = consensus. As an example:=20 =20 I think the attempt to use the 'origin' of each component twists the = security into knots unnecessarily. If you think of a package as just a pushed cache of collection of = resources from various sources, they have no decidable relationship. If you model treats it as document -- an object which may or may not = have an origin, then you have to decide what things you'll allow the = document to do, without necessarily knowing the origin of anything. = You could make it a self-updatable document but not a component at a = time; updates must be coordinated. It seems the discussion of double hashing assumes a pushed-cache model. = Why not use the hash as a kind of global etag? (but how is the content-type reflected in the hash? From nobody Sun Mar 29 20:16:09 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31543A08BE for ; Sun, 29 Mar 2020 20:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=VyaYA5Ix; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tvqnNajc 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 FZleD3D-aX3o for ; Sun, 29 Mar 2020 20:16:05 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34ED3A08BD for ; Sun, 29 Mar 2020 20:16:05 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 23B3C79A; Sun, 29 Mar 2020 23:16:05 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 29 Mar 2020 23:16:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=BoOV5IXIhkOYAkQAgMtPymQ07Nb4pSd BAROj7qrZI1w=; b=VyaYA5Ixc9wW238rxd4EhrBAe0kTeXMytt1ktx76bw3Tfn9 PZnBG9scrOImx0JMujkt8seTbmRNhZ+raxI4aJ1VzHYcPxksARxgNRhUlhOCwajW Df69OHb1jPjUdbYvQYzE8x4R8jH9Zi4ySjx+iy8U19LSrD9cc45J7JZjZeJdZ+Xk O3uQl9AE5sN/eZX2J0//oflLr6P+DLl8NXtaRMBb2PayzYBHqOOqwPTpc5N7xJ5X 0UO5ysUs7sP320O478q5lDkcPfKUY+hU3+9ifjWNgZngwrZnO9BlhRX8mu3qfXto abSy8Pp4hPSgg/oIDOcBIFeIrQ/yCQvsTgbhDjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BoOV5I XIhkOYAkQAgMtPymQ07Nb4pSdBAROj7qrZI1w=; b=tvqnNajcBJRo3SC6K4OJDB eJ3QR8ysfhzRTdmYn1Ym4dzBE8ALE7Q67RIe79v1U40kJvuUPY7LqKWEJxDwRvM+ /Y7873L6qrees/YbxW1aiglwReUHAAM4OuaDhajqBybjEFTER4cABZubOlcnfbZe Ge8FWWWNEpF+3c2xl5epP6xvkOCsVxWyRhzw10nB+257d98cNLGmpRqskdcFtbBW 4rjmKa6nHRWm0qffoEKqTnBrvkHDvEZjcm4EAULYcYudHYemUok9trhZlsL73jhz r/pE7VVwoCWgInTv7VyN/73xTMRGM1OqdPE8i+B0Kr/owNqsuyDQ6OixVVj5iR7Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeigedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35A9EE00C2; Sun, 29 Mar 2020 23:16:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <91760b30-5195-4a3b-ada4-3ea6f44000e5@www.fastmail.com> In-Reply-To: <007801d604c1$2db98320$892c8960$@acm.org> References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> <024201d602e6$a8afde80$fa0f9b80$@acm.org> <002401d6033a$f70fe990$e52fbcb0$@acm.org> <40772bfb-0ef7-4a07-850b-6f1881c06b45@www.fastmail.com> <007801d604c1$2db98320$892c8960$@acm.org> Date: Mon, 30 Mar 2020 14:15:42 +1100 From: "Martin Thomson" To: "Larry Masinter" , wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] WPACK GitHub Repo? X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 03:16:08 -0000 Hi Larry, Thanks for your insights. On Sat, Mar 28, 2020, at 16:24, Larry Masinter wrote: > I think the attempt to use the 'origin' of each component twists the > security into knots unnecessarily. > If you think of a package as just a pushed cache of collection of > resources from various sources, they have no decidable relationship. This is the core of the debate here. If we do decide that a bundle is equivalent to a cache, then we have to accept that the process by which bundles are secured is equivalent to the cache. In my opinion, that buries a lot of important differences, or comes with limitations on use that are unacceptable in the general case. > It seems the discussion of double hashing assumes a pushed-cache model. > Why not use the hash as a kind of global etag? This is a fairly good general model (I know that hashes are often used for etags in practice; it's a good general purpose technique). > (but how is the content-type reflected in the hash? It is not. It's an aspect of HTTP that continues to annoy me, frankly, that there is no clear delineation between metadata about the representation, metadata about the request, and just data about the request. In this case, we depend on the bundle being considered adequately self-describing so that content is not accidentally (or maliciously) mis-classified. For what it is worth, techniques from QUIC might translate well here. QUIC packets are self-authenticating because they include a keyed integrity check that would be hard to generate by accident. The current bundling proposal only includes a short fixed header (and a bunch of things that might lead any attempt to misrepresent a different content-type into error handling paths). From nobody Sun Mar 29 21:28:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA473A0C08 for ; Sun, 29 Mar 2020 21:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=gLqAH0Rm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E3Xcf5b8 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 sgLGdcQXx5PD for ; Sun, 29 Mar 2020 21:28:33 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410733A0C07 for ; Sun, 29 Mar 2020 21:28:33 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 482B778B; Mon, 30 Mar 2020 00:28:32 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 30 Mar 2020 00:28:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=iTYBtYqGA+eq2mxkRl2EQ2/QTtZQ ELulk1R7EMdcz4c=; b=gLqAH0Rm8wnsdkRbCJDx49M+2dsTPhStUTLx45qUorhp o+KcH0+T/12qES7BmjQO4ZvW8QBFkUhlVRseba4W3SQXEvGiplov011WdXw+iYKL dtbEicJdGXDtnxcROCjbMGuxwMTa2uC0zjkeq1oHJgVUAQcqD5hSJLI05ereiByB Tf2JvAmVaV713njjO0pYI0c37OFIU3wsDw/FPtZMQ9DSdroE01L4DXoxZJeKpi16 QjuIIpQn7oSFjsGbxm4d3aoFK9Eg5yJ0BcJukUF5qqZXDQjzWHUcyR+0/UrC9T+r Vu1G0XOUfN06egz39o/w2EX1K37RTY7mXpKHxtCqOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=iTYBtY qGA+eq2mxkRl2EQ2/QTtZQELulk1R7EMdcz4c=; b=E3Xcf5b8Bf06UfeSvfFp0M SGrtV2zhu9zD4SRNgS613B5DOjxtOgw/fB+BB5AMG3cJ63arZo6EYs+2MMliVeNu FaCupzALN9OnEemPG4eCARPMg29pW/SwcMLFDpDTqkOpgQ61Bm+MDFKfS/2sCxl9 PxaKrhH3e2uil4g95bO2EODYmkwGxgJRcM1yT42XoxSARJYQUAKyw+nLXqQ53Wgd 1Sem1YU5f/ki1zmoXIIODK52N+h0aIX6hkvcnNfVtQ7F2ppaQ7Otf3sny197LEpN vntW7gzh8dG7QAupAc4078Vbew+p3uBD1CLq8ct3Kz9ZHpo4U2aQxuOcsWzxJuSA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeigedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82146E00C2; Mon, 30 Mar 2020 00:28:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <0ae3f1b1-7133-4d12-bf6c-a1ee2c257218@www.fastmail.com> In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> Date: Mon, 30 Mar 2020 15:28:11 +1100 From: "Martin Thomson" To: "Devin Mullins" Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 04:28:35 -0000 On Sat, Mar 28, 2020, at 07:06, Devin Mullins wrote: > Ah, good to know. To clarify: Am I right in assuming my above proposed > attack is somewhere on the spectrum of > https://github.com/WICG/webpackage/pull/424 ? That is, it requires > publisher server-side work, but is a potential end-run around > mitigations to backchannel sharing such as per-origin IP obfuscation > and fingerprint entropy reduction. If so, then what motivates > https://github.com/martinthomson/wpack-content/issues/1 ? This particular threat model is a really difficult one for me to get my head around properly, I have to admit. I think that the key mechanism that this assumes we need to look at is navigation. This appears to aim to protect is the transfer of information from the linking site to the target of a link. In this case, from a distributor to a publisher. Today, navigation carries information in essentially two obvious places: the URL and the Referer header (I think that's all). Web packaging potentially adds another path whereby information can travel. Namely the content of the bundle. Assuming that a distributor is given license to generate bundles by the target origin, the linking party can pack any state it chooses into a bundle[1]. That information is then available to the target origin via requests to the resources in the bundle, or via requests to state established by the bundle. It seems fairly obvious that the amount of state that is transferred could be considerable. How the target origin receives this information follows similar lines to your email. But in practice, it doesn't need to be that fancy. If we are talking about hashes, the total amount of data involved isn't that much. I don't think that a site would be particularly put off by the cost of transferring hashes to the sites that they link to. 32 bytes per user per target isn't that much data to save or transfer. You can then rely on post-facto linkage. I'm sure that RTB systems transfer orders of magnitudes more than this as part of their normal operation. (As an aside, this isn't exactly equivalent to giving the distributor control over your private key unless you exercise the options in footnote [1], but it comes close. In any case, I don't believe that there is any material difference between this option and having the distributor ask the publisher to sign bundles containing the data on a per-request basis, aside from perhaps having better performance characteristics at bundle creation time.) Let's say that we had a system that was able to detect and maybe block information transfer in URL or Referer[2]. Is the contention that this system would be unable to detect this sort of information transfer when it was general purpose content? Separately, I'm about your stated desire to provide diversification of content for the purposes of experimentation here. It seems to be in direct tension with this privacy requirement. I'm interested in knowing how you might choose to trade the two off; I don't have any reference here as we haven't spent a whole lot of time looking at this specific problem. Cheers, Martin [1] There is a variant of this that requires only a tiny bit more information to travel between distributor and publisher, but allows the publisher to more closely audit what is being shared. [2] I don't know if this is possible in general, but I remain open to being convinced otherwise. The best defense I can think of for this sort of system requires no such detection. Instead, you try to prevent individual targeting by confirming that others have the same content. However, those designs are trivially vulnerable to sybil attacks. ... The webex calls we were on this week had a URL that was ~422 characters, most of it opaque. Maybe that was critical information, I don't know. But I am not sure it would be possible to tell if this contained information that was designed to de-anonymize someone. Similarly, with only a fifth of the characters, the (up to) 244 bits of random gunk in a Google docs URL might all be used finding the document, but I could imagine that far fewer than this would be needed if someone wanted some bits spare. From nobody Mon Mar 30 11:20:50 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5673A0DA3 for ; Mon, 30 Mar 2020 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CRQDZiCfipSy for ; Mon, 30 Mar 2020 11:20:47 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E593A0DA1 for ; Mon, 30 Mar 2020 11:20:47 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id g4so9443348qvo.12 for ; Mon, 30 Mar 2020 11:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XykByFKn4HojksyEPHmNN0dKs6knwyPFeaMXZ9Ieelg=; b=HQ1QMTrJQFh3CsroI5pDPU1R54F79TsGkVyL5i1IDF957mmHh3VOene9eAzFvELh9k 6W8iqK3DIEqjhNznP7CmbsKVWHliwVNwdXpMNuDMWpu2npFWw5MIzA510JVFToDv2N+L kAC4bmxyuIqZDdH9D0NXRfzcnkeUG0g66Y5Dgsh4FHEsT8NI+A6vinY0AFH0CRjcYzWq qDDxwtZF+VuOisA+/cqZoe1esY2SuloZ/mGYo+MWF8zh3Bi2gq9swPCtxhin3ysLOyA/ IzO0mrRvi6I8MR9Ctn9Z0iCX8dx7BfNMeT894g7EdYZLdK/fpYZ9JP0gE8af9mGQZqYc Sn7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XykByFKn4HojksyEPHmNN0dKs6knwyPFeaMXZ9Ieelg=; b=h6PeQBbc0hCwG4JeOE0tQ7Hzgg4vCEPq5JFc2bTcr+BbgdTnNSsWvR7zwnKz0Vn/Hq sKnHqpExxBpW8bMYsye15tAtweUaJADOR/nZzphS3mHtqoi99XCt/y2qHlA1ugYfxU/s NlqpHrDvBWbw1aBC9o2MTNkbrKI2vSQGp7extrhXAsSilUmL90C7DcYdc+jdYtP1QUn6 I5+GLZWyEFiD6wfHEOa1nhA0RQrYBfRcswckav2s1dUqQBezmFCDkcdwUe8Wja0EZSMJ MqrXckp4ZVuPXbG6DoKB+AxaQMf2DhzyXHP7V/KFAgcRyMTV8sf53j3f73vSVYbY5FwD IihA== X-Gm-Message-State: ANhLgQ2oNRTM21F1sA4T64p6BcsVmyf/o2Yt/tiuqtTs048u5hKm0CUY L9P67oh0c322XTQIPaWarcjrdRtV9sqAki30MEHA5d2+Vj8= X-Google-Smtp-Source: ADFU+vvFkcicnVdljXvT6oX1HiBgle+/qqk1v97Ayv0uziyH5td/iSpNm2UgZ3y9DElGUCpq890yC6WgVdibFhuaamo= X-Received: by 2002:ad4:4302:: with SMTP id c2mr12299798qvs.193.1585592445402; Mon, 30 Mar 2020 11:20:45 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Mon, 30 Mar 2020 11:20:34 -0700 Message-ID: To: WPACK List Cc: Larry Masinter Content-Type: multipart/alternative; boundary="00000000000077ed2005a216824b" Archived-At: Subject: [Wpack] Interpreting package signatures X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:20:49 -0000 --00000000000077ed2005a216824b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Larry wrote in https://mailarchive.ietf.org/arch/msg/wpack/dL8feENuL9t-HpKj1PWCYjz0r2A/ that: I suspect your requirements may be at the wrong level (you=E2=80=99re start= ing with > a very operational view of the =E2=80=9Cweb security model=E2=80=9D (if t= here is such a > thing) by translating TLS into digital signatures and asking who signs wh= at > and how can you do that with minimal changes to the browser =E2=80=9Csecu= rity > model=E2=80=9D. > > Asking what=E2=80=99s the origin of a data: URL is asking the wrong quest= ion. The > problem is the notion of =E2=80=9Corigin=E2=80=9D is tied to the HTTP tra= nsaction model. > > PDF signatures are package signatures, but the signature isn=E2=80=99t ti= ed to the > origin of any of the parts. Isn=E2=80=99t that what you want when you wan= t to show > something is trusted not because it was assembled from trusted parts but > because you trust the assembler? What use case forces you to assume that > interpretations packages have to look the same in the browser showing URL= s? In the web packaging drafts, I've tried to consistently distinguish between the "author" of content versus the "publisher" of a package, for example in https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-08.htm= l#terminology. The HTTP "origin" corresponds to a publisher, rather than an author, as you can see when the byline of https://www.propublica.org/article/what-happens-if-workers-cutting-up-the-n= ations-meat-get-sick isn't reflected in the URL. That is, the "origin" isn't the entity that originally wrote the bytes, it's the entity that assembled the parts, which I think matches what you're asking for. And in my signing proposal, indeed, signatures come from publishers, not authors. This means that if a client saves some unsigned content, they have the option of signing it as themself when forwarding it to a friend. There's not much benefit to doing that, since the client likely doesn't have a publicly-recognized key, but it's possible. Jeffrey --00000000000077ed2005a216824b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Larry wrote in https://mailarc= hive.ietf.org/arch/msg/wpack/dL8feENuL9t-HpKj1PWCYjz0r2A/ that:

    =
    I suspect your requiremen= ts may be at the wrong level (you=E2=80=99re starting with a very operation= al view of the =E2=80=9Cweb security model=E2=80=9D (if there is such a thi= ng) by translating TLS into digital signatures and asking who signs what an= d how can you do that with minimal changes to the browser =E2=80=9Csecurity= model=E2=80=9D.

    Asking what=E2=80=99s the origin of a data: URL is = asking the wrong question. The problem is the notion of =E2=80=9Corigin=E2= =80=9D is tied to the HTTP transaction model.

    PDF signatures are pac= kage signatures, but the signature isn=E2=80=99t tied to the origin of any = of the parts. Isn=E2=80=99t that what you want when you want to show someth= ing is trusted not because it was assembled from trusted parts but because = you trust the assembler? What use case forces you to assume that interpreta= tions packages have to look the same in the browser showing URLs?

    In the web packaging drafts, I've tried to consistentl= y distinguish between the "author" of content versus the "pu= blisher" of a package, for example in=C2=A0h= ttps://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-08.html= #terminology. The HTTP "origin" corresponds to a publisher, r= ather than an author, as you can see when the byline of=C2=A0https://www.propublica.org/article/what-happens-if-worke= rs-cutting-up-the-nations-meat-get-sick=C2=A0isn't reflected in the= URL. That is, the "origin" isn't the entity that originally = wrote the bytes, it's the entity that assembled the parts, which I thin= k matches what you're asking for. And in my signing proposal, indeed, s= ignatures come from publishers, not authors.

    This = means that if a client saves some unsigned content, they have the option of= signing it as themself when forwarding it to a friend. There's not muc= h benefit to doing that, since the client likely doesn't have a publicl= y-recognized key, but it's possible.

    Jeffrey
    --00000000000077ed2005a216824b-- From nobody Mon Mar 30 14:46:36 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051613A13AE for ; Mon, 30 Mar 2020 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.349 X-Spam-Level: X-Spam-Status: No, score=-7.349 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 U3C3txVQ6kh8 for ; Mon, 30 Mar 2020 14:46:33 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC553A13AD for ; Mon, 30 Mar 2020 14:46:33 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id 10so16615346qtp.1 for ; Mon, 30 Mar 2020 14:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4rqhhHEvuQnRX7plrE+qQLH7cWB+NmcP1w0QeY03Tqk=; b=PbaoG5CVIh+d56QDIoM9jsL54Ev+vnu38HgR+/SyS+Wxk6KxV2CA4HXw1dbEjyAFOZ Ucs0ut2t9L7mGbDaPUaaGIncx6M50UzwIDYWzR40vLDNtEW6At72UGwud121uHrzH1KU +rAPZRnEab6Es9GNEbCVpaEWirm9VbfQYkPxE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4rqhhHEvuQnRX7plrE+qQLH7cWB+NmcP1w0QeY03Tqk=; b=qxwqRgjshE1KYuNa2EP9HPJZR7/4yB1prsQ5EWKNkxNYRIwOj24f7rg0Mex1Sd3p2u 4sj2NQwp3Ijj+VmtQoIdDf6tRKMICwBkDdQGB8rwG2BcKRjXAl5/mBI3xjUJxtzFaIru 6PnTirot8nAoThoJnvhu68k7FU3b6sy/rBvqwhXGnHExvOR9HapGjKExy5t8wGjKTY4d ocaP5O3SoAElX3rQywEPQoUEPfsDKqcP92kFMw2k2izCc6tmTdYXf8mTQ/HeR+d9xx// pi5JaDKelrqq4jWfrjdIOXG+kYPwWaISPn47+wA5fle7LUlK0yLxCFiJap3Y6JnQ0Ivx mkMQ== X-Gm-Message-State: ANhLgQ2Qob0u688JcwNm9qhaqSvqVs9CZunYXkMX+zFSpRiZg58JMLKE pAtJYiqlB/qZ1ndj4x5Ax0nBUltwdhX08dakPBQV3Q== X-Google-Smtp-Source: ADFU+vuRgzeKro8G7jljd+e8xCaGc+UwjSXvbD/i+SwjUBGcti22b639BM5C+tMoxGbUgjYy320ZpAJswm5GEZILIfA= X-Received: by 2002:ac8:1a2b:: with SMTP id v40mr2206798qtj.364.1585604791832; Mon, 30 Mar 2020 14:46:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Mon, 30 Mar 2020 14:46:17 -0700 Message-ID: To: Ben Schwartz Cc: Jeffrey Yasskin , WPACK List Content-Type: multipart/alternative; boundary="0000000000005f6f8505a21962ba" Archived-At: Subject: Re: [Wpack] Security, authority, and privacy X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 21:46:35 -0000 --0000000000005f6f8505a21962ba Content-Type: text/plain; charset="UTF-8" On Thu, Mar 26, 2020 at 12:45 PM Ben Schwartz wrote: > On Thu, Mar 26, 2020 at 2:43 PM Jeffrey Yasskin > wrote: > >> On Wed, Mar 25, 2020 at 3:06 PM Ben Schwartz > 40google.com@dmarc.ietf.org> wrote: >> >>> It seems to me that there are two main kinds of permission that concern >>> us here. >>> >>> 1. Permission to display content as the origin. >>> 2. Permission to perform I/O while acting as the origin. >>> >>> I think we should accept signed exchanges as sufficient for #1 before >>> online verification completes, but require online verification for #2. >>> This tightly limits any stolen key or stale content attack: the attacker >>> can impersonate the origin until online verification completes, but cannot >>> do much damage during that period. >>> >>> (This is not a comment on implementation, which could be similar to >>> Martin Thomson's proposal, or not.) >>> >>> In this model, we would queue all pending I/O until verification >>> completes. (The relevant APIs should all be asynchronous). This isn't >>> compatible with every use case we have, but it covers most of them. >>> >>> "Early actions" and the corresponding state transfer could be added >>> later if needed, but I think tackling that topic now would likely delay the >>> standards process considerably. I also think most use cases would prefer >>> that I/O simply be queued, so the state-transfer system should be clearly >>> opt-in, only for the most sophisticated developers. >>> >> >> I like the general suggestion to avoid side-effects on the origin's >> online state until the client has checked with the online origin, if we can >> make the transfer work, but I'm wary of a couple aspects of this >> implementation: >> >> A) I'm not sure what "I/O" means here. One could make a small >> camera-effects website that works entirely offline, but that does Input >> through the camera and Output by, perhaps, being able to let the user save >> files (aside from the obvious one of drawing to the screen). You seem to >> mean writing to local storage and fetching remote resources with a >> particular value in the Origin header. Is that all? >> > > I think fetching any remote resource would have to be delayed, if stolen > key attacks are in-scope. Imagine a package (signed with a stolen key) > that presents a login screen, collects user passwords, and sends them as > "anonymous" GET requests to the attacker's server. > > Local filesystem reads should be OK, but filesystem writes would have to > wait. Otherwise, a package (signed with a stolen key) could "download" a > .exe that is malware. > I think you've accurately described the implications of the threat model in which an off-path attacker who steals a key must not be able to harm a user (using the user's trust in that key) in any way except to put incorrect information in their brain. I'm not sure that's the right threat model, but it's possible. We should start writing down a sketch of the plausible threat models here. > B) Having all writes to storage queue instead would break offline use of >> content-authoring sites, which is something I wouldn't want to lose. I >> think use cases where a user wants to avoid expensive data transfer but >> still has a connection, still work, but as Ted Hardie has described, there >> are lots of cases where people actually can't connect to the global >> internet for periods of time, and I think we'd lose all of their use cases >> except for pure content consumption. >> > > I agree with this analysis, but I think the potential "offline webapp" > users are vastly outnumbered by the potential offline content readers, so > we should focus on the larger, easier case first, and add optional complex > features for the fancier use cases later. > I mostly agree with your estimate of the relative popularity of these two use cases, but I'm still uncomfortable focusing on content consumption over content creation. We'd effectively be saying that low-income people and people living under restrictive governments are less worth hearing from. If I only cared about AMP, this would probably be fine (although I defer to Devin on that question), but our goals are broader than that. That said, I'm curious what non-Google people think of this question. :) Jeffrey --0000000000005f6f8505a21962ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Mar 26, 2020 at 12:45 PM Ben Schw= artz <bemasc@google.com> wro= te:
    On Thu, Mar 26, 2020 at 2:43 PM Jeffrey Yasskin <jyasskin@chromium.org= > wrote:
    =
    On Wed, Mar 25, 2020 at 3:06 PM Ben Schwa= rtz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
    It seems to me that there are two main kinds of permission that concern = us here.

    1. Permission to display content as the origin.=
    2. Permission to perform I/O while acting as the origin.

    I think we should accept signed exchanges as sufficient f= or #1 before online verification completes, but require online verification= for #2.=C2=A0 This tightly limits any stolen key or stale content attack: = the attacker can impersonate the origin until online verification completes= , but cannot do much damage during that period.

    (T= his is not a comment on implementation, which could be similar to Martin Th= omson's proposal, or not.)

    In this model, we w= ould queue all pending I/O until verification completes.=C2=A0 (The relevan= t APIs should all be asynchronous).=C2=A0 This isn't compatible with ev= ery use case we have, but it covers most of them.

    = "Early actions" and the corresponding state transfer could be add= ed later if needed,=C2=A0but I think tackling that topic now would likely d= elay the standards process considerably.=C2=A0 I also think most use cases = would prefer that I/O simply be queued, so the state-transfer system should= be clearly opt-in, only for the most sophisticated developers.
    =

    I like the general suggestion to avoid sid= e-effects on the origin's online state until the client has checked wit= h the online origin, if we can make the transfer work, but I'm wary of = a couple aspects of this implementation:

    A)=C2=A0I= 'm not sure what "I/O" means here. One could make a small cam= era-effects website that works entirely offline, but that does Input throug= h the camera and Output by, perhaps, being able to let the user save files = (aside from the obvious one of drawing to the screen). You seem to mean wri= ting to local storage and fetching remote resources with a particular value= in the Origin header. Is that all?

    =
    I think fetching any remote resource would have to be delayed, i= f stolen key attacks are in-scope.=C2=A0 Imagine a package (signed with a s= tolen key) that presents a login screen, collects user passwords, and sends= them as "anonymous" GET requests to the attacker's server.

    Local filesystem reads should be OK, but filesystem= writes would have to wait.=C2=A0 Otherwise, a package (signed with a stole= n key) could "download" a .exe that is malware.
    =

    I think you've accurately described th= e implications of the threat model in which an off-path attacker who steals= a key must not be able to harm a user (using the user's trust in that = key) in any way except to put incorrect information in their brain. I'm= not sure that's the right threat model, but it's possible.

    We should start writing down a sketch of the plausible th= reat models here.
    =C2=A0
    B) Having all writes to storage queue instead would break offline u= se of content-authoring sites, which is something I wouldn't want to lo= se. I think use cases where a user wants to avoid expensive data transfer b= ut still has a connection, still work, but as Ted Hardie has described, the= re are lots of cases where people actually can't connect to the global = internet for periods of time, and I think we'd lose all of their use ca= ses except for pure content consumption.

    I agree with this analysis, but I think the potential "= ;offline webapp" users are vastly outnumbered by the potential offline= content readers, so we should focus on the larger, easier case first, and = add optional complex features for the fancier use cases later.
    <= /div>

    I mostly agree with your estimate of = the relative popularity of these two use cases, but I'm still uncomfort= able focusing on content consumption over content creation. We'd effect= ively be saying that low-income people and people living under restrictive = governments are less worth hearing from. If I only cared about AMP, this wo= uld probably be fine (although I defer to Devin on that question), but our = goals are broader than that.

    That said, I'm cu= rious what non-Google people think of this question. :)

    Jeffrey
    --0000000000005f6f8505a21962ba-- From nobody Mon Mar 30 16:35:13 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4902B3A0EAF for ; Mon, 30 Mar 2020 16:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hXSm91XdWlbY for ; Mon, 30 Mar 2020 16:35:10 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513A33A0EAC for ; Mon, 30 Mar 2020 16:35:10 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id b12so622184wmj.3 for ; Mon, 30 Mar 2020 16:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5byuOVo9yUZKE+LIvVyBmJpcsskRkDzMWqysjEGAj0s=; b=f+QQrwKc9sAkIr3maIuS2nIISA+ygl6r5UL/wFqocSHslxzL6fWYUHvBJ7QhHuhTSp jPJAMJLicxUmXq4iy1IWzJqMkZ4lFn4LwNUBXbQZ+Pq+zJJU92geI6uQf1uQS8vGkzgY aRtKl8MJYe7oKdy0nh7t3C8mmTMKPEVAXuwDe7gx2ZhgMTfxgopN5tGZkoAa3xHa2Iod 9H8zhieQnqDZUUIGxqq1cy7Mdn49sjONA93ZMz7381H+rdCjv5PMuFd+pCjKjH1W1+Ka 68om8Gv6b/aRymrO0BYFreRX/oDoQs5KdAFx6QvZBfSzzsT8XpwxnRZ+dHLECAdiwkb0 AZ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5byuOVo9yUZKE+LIvVyBmJpcsskRkDzMWqysjEGAj0s=; b=iK1aI6HsGEPWdjkTsf0t+kBaGjCLM7SfFVTmj34dOEeGG3aekWj1zaAiTHWbvQ+7w3 6kmXxTbl+TEB6uauBQrG4vRva/EeZXon6TX5A5k02Gv/PRtUbQR46GWPvBarkob0ysOP izZxjA7Qa3uiXp6pvxBbhMDRQshDH3Ypr+ngRWIXj/2qQYDQtGP2UTLN/7Vbcy1U3GbC eCAoItuvDo5AZOeiopVp2xcVkrTRZPEFQIw7CbmUstTjvlJmSaK4hA+aJ7ooYQdNVntK JMh1jUboX9ylHKzn3JAfVyR3OUQilmF4M8IOPisKoTNkbL6OOsA9bFACuYtd33Ux6M/1 tzMQ== X-Gm-Message-State: ANhLgQ0SyUKTtFn2JdjzxlVs50NctrgBCG2A00uBYLQJyTYWKZBi9ebT hGsSpFU5Yo4TlfA1mLBE2yoaR40YaXIh0auB8Y16Ozxy X-Google-Smtp-Source: ADFU+vvx7HZK/DDiln5fnIV9UHFktzNkIxIpaPxWq3BZNdQ1ag5yl+OlrvuGjdtVf+JQ/K0ZTFtS/Ogd76/JEzCHJJM= X-Received: by 2002:a1c:f409:: with SMTP id z9mr497991wma.51.1585611308468; Mon, 30 Mar 2020 16:35:08 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> <0ae3f1b1-7133-4d12-bf6c-a1ee2c257218@www.fastmail.com> In-Reply-To: <0ae3f1b1-7133-4d12-bf6c-a1ee2c257218@www.fastmail.com> From: Devin Mullins Date: Mon, 30 Mar 2020 16:34:41 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb690605a21ae605" Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 23:35:12 -0000 --000000000000cb690605a21ae605 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 29, 2020 at 9:28 PM Martin Thomson wrote: > Separately, I'm about your stated desire to provide diversification of > content for the purposes of experimentation here. It seems to be in direct > tension with this privacy requirement. I'm interested in knowing how you > might choose to trade the two off; I don't have any reference here as we > haven't spent a whole lot of time looking at this specific problem. > If you haven't seen it yet, my longer email has one proposal, but I haven't thought about it too much; it may have holes. This is an area I need to learn a lot more about. > This particular threat model is a really difficult one for me to get my > head around properly, I have to admit. > Only my guess, but it seems to be at least as much about re-balancing the costs/benefits of bad actions as it is about blocking them (i.e. making the costs infinite). I don't mean to imply stake in any particular threat model; I think UA vendors are in a better position to do so. (I will do my best to help inform that decision with feasibility estimates for one use case.) Mostly I'm trying to ensure there is rough consensus on this part. As a consumer of the signed exchanges spec, I'm obviously interested in a successor spec that has properties that most or all are satisfied with. Let's say that we had a system that was able to detect and maybe block > information transfer in URL or Referer[2]. Is the contention that this > system would be unable to detect this sort of information transfer when it > was general purpose content? > I don't know. It seems like there'd be a lot of ways to evade detection and hide things in the URL that don't even require server changes. (For example, many servers don't validate the URL slug, so it could be steganographically altered and then inspected client-side.) I don't think that a site would be particularly put off by the cost of > transferring hashes to the sites that they link to. 32 bytes per user per > target isn't that much data to save or transfer. You can then rely on > post-facto linkage. > Good point. This is mitigated by martinthomson/wpack-content#1, yes? But AFAICT, this + //publisher.example/this-is-my-hash is not mitigated by #1. That said, I guess the solution is that, for anti-fingerprinting, the state transfer request and any previous subresource requests should be considered in different buckets. The state transfer itself doesn't affect the feasibility of the attack. The unverified bundle can make a fetch to //publisher.example/distributor-id?foo, and even if the Sec-CO request fails, the publisher can join foo with a subsequent credentialled fetch, in order to inform future responses. The UA could consider this ~isomorphic to the linking page making that same fetch to /distributor-id?foo. --000000000000cb690605a21ae605 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Sun, Mar 29, 2020 at 9:28 PM Martin Th= omson <mt@lowentr= opy.net> wrote:
    Separately, I'm about your stated de= sire to provide diversification of content for the purposes of experimentat= ion here.=C2=A0 It seems to be in direct tension with this privacy requirem= ent.=C2=A0 I'm interested in knowing how you might choose to trade the = two off; I don't have any reference here as we haven't spent a whol= e lot of time looking at this specific problem.

    =C2=A0If you haven't seen it yet, my longer email has on= e proposal, but I haven't thought about it too much; it may have holes.= This is an area I need to learn a lot more about.
    =C2=A0
    This particular threat mode= l is a really difficult one for me to get my head around properly, I have t= o admit.

    Only my guess, but it seems to= be at least as much about re-balancing the costs/benefits of bad actions a= s it is about blocking them (i.e. making the costs infinite).
    I don't mean to imply stake in any particular threat model;= =C2=A0I think UA vendors are in a better position to do so. (I will do my = best to help inform that decision with feasibility estimates for one use ca= se.) Mostly I'm trying to ensure there is rough consensus on this part.= As a consumer of the signed exchanges spec, I'm obviously interested i= n a successor spec that has properties that most or all are satisfied with.=

    Let's say that we had a system that was able to detect and maybe block= information transfer in URL or Referer[2].=C2=A0 Is the contention that th= is system would be unable to detect this sort of information transfer when = it was general purpose content?

    I don&#= 39;t know. It seems like there'd be a lot of ways to evade detection an= d hide things in the URL that don't even require server changes. (For e= xample, many servers don't validate the URL slug, so it could be stegan= ographically altered and then inspected client-side.)

    <= /div>
    I don't think th= at a site would be particularly put off by the cost of transferring hashes = to the sites that they link to.=C2=A0 32 bytes per user per target isn'= t that much data to save or transfer.=C2=A0 You can then rely on post-facto= linkage.

    Good point. This is mitigated= by martinthomson/wpack-content#1, yes?

    But AFAICT= , this + //publisher.example/this-is-my-hash is not mitigated by #1. That s= aid, I guess the solution is that, for anti-fingerprinting, the state trans= fer request and any previous subresource requests should be considered in d= ifferent buckets. The state transfer itself doesn't affect the feasibil= ity of the attack.=C2=A0The unverified bundle can make a fetch to=C2=A0//pu= blisher.example/distributor-id?foo, and even if the Sec-CO request fails, t= he publisher can join foo with a subsequent credentialled fetch, in order t= o inform future responses. The UA could consider this ~isomorphic to the li= nking page making that same fetch to /distributor-id?foo.

    --000000000000cb690605a21ae605-- From nobody Mon Mar 30 20:44:02 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C22B3A19EE for ; Mon, 30 Mar 2020 20:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=nzr523Yt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S66Wwdem 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 mPrIAmVf9kRy for ; Mon, 30 Mar 2020 20:43:59 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508883A19ED for ; Mon, 30 Mar 2020 20:43:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B767C6B0; Mon, 30 Mar 2020 23:43:57 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 30 Mar 2020 23:43:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=nK4Z3y45U4nNjlUf93F18fnYjkvg IM2bO2FxOhKVaRk=; b=nzr523YtqcXDs1WXjzpHEMYsWSIw16R6jBNvMpkxpGn+ d1ln9YZPWNdJx5U+Q+ZV19alPBGwdmSR9mmYbaKXsji1kQoLDjrQVcL1U45aO6iV f2RfHxtpBX7KMJkFk6aZsx5m9kg0M4if7w+m0gp0h3KNPYP4sLGi1HG5QprXMKMk akX3Swg6xhtnZVcsKiciJ2vl0y9GO2l6vSMINouGwgtLE0s929HpaJxUgxubU67a OLwDb+AyJ0X8vwt/lOW44vYzeCcUVtmufU43if4gMvXIdR+eUq/4Gu5M37lZCHE4 gVfoXgnndMyYozcokKfUG8mVKTQ8O/e0I6hobXt/PA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=nK4Z3y 45U4nNjlUf93F18fnYjkvgIM2bO2FxOhKVaRk=; b=S66WwdemyphY4O5ydSzlpO nFNA5wMNZTS633wRRZBOzn2tZxVLt3cwgq+ViWGdevWJRgeTKmVKzeJfDMevCrlh w4EYGcl5EevVMFCWcfMs+uWlo9XYua8rD2F8UNsfoEHnTymY1hrvC0XasPESALRV Z7GJyym91aHL9+HNLzCiI8FyFS3RqJWVR8fw+yqOtLivvBympr5SUPBVzY+F2H6C r1QAAExECAT4R5rUeyFWu1e+aRow+FXctzG5R0Yc9X4yEhX7A1tQxz9PtS7u0oyg m3NZpa0XvUQQrRLYbRnPHhbc5MwQFSpos9S7EVLNL5xoA5Il0FE8cA6PRubXrqFA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E3D2CE00BA; Mon, 30 Mar 2020 23:43:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> <32395446-c14e-4bca-9c09-4804934c487b@www.fastmail.com> <0ae3f1b1-7133-4d12-bf6c-a1ee2c257218@www.fastmail.com> Date: Tue, 31 Mar 2020 14:43:37 +1100 From: "Martin Thomson" To: "Devin Mullins" Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins) X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 03:44:01 -0000 On Tue, Mar 31, 2020, at 10:34, Devin Mullins wrote: > > I don't think that a site would be particularly put off by the cost of transferring hashes to the sites that they link to. 32 bytes per user per target isn't that much data to save or transfer. You can then rely on post-facto linkage. > > Good point. This is mitigated by martinthomson/wpack-content#1, yes? Not really. The push can include the H(Content) and the site can calculate H(H(C)). So the truncated hash only really limits the information the client has to include, trading it for more from the server. Since opening that issue, I'm not convinced that it is worth pursuing for anything other than that trade-off (which is only a maybe-optimization at best). > But AFAICT, this + //publisher.example/this-is-my-hash is not mitigated by #1. Right. What *might* do that is the fact that a publisher willing to accept *any* bundle ends up being exposed to a broad spectrum of cross site forgery attacks. It allows an attacker to supplant any script that the site might reference on its own origin. You might be able to avoid that with a really strong CSP, but I'm not sure that would be a strong guarantee. But as I mentioned before, there are ways to partition resources such that a site can validate a bundle without taking on that risk. And signing doesn't help significantly, except to add a signature to the 64+ bytes per user per target cost. > That said, I guess the solution is that, for > anti-fingerprinting, the state transfer request and any previous > subresource requests should be considered in different buckets. One thing that we are seeing in some contexts is not just completely different connections for credentialed vs. uncredentialed requests, but proxying of uncredentialed requests, so that the amount of fingerprinting information is limited. > The state transfer itself doesn't affect the feasibility of the attack. The > unverified bundle can make a fetch to > //publisher.example/distributor-id?foo, and even if the Sec-CO request > fails, the publisher can join foo with a subsequent credentialled > fetch, in order to inform future responses. The UA could consider this > ~isomorphic to the linking page making that same fetch to > /distributor-id?foo. Right. That's where this gets really hairy. But this all goes to challenging the feasibility of the goal of preventing information transfer across origins. The fact that this is a content-based origin doesn't change the dynamics at all. If origins are willing to cooperate in the exchange of information, then I don't know how to prevent that. It might be possible to make things sufficiently unlinkable, but even for something with protections as restrictive as Tor Browser I doubt that you can prevent transfer. (That's a challenge, BTW, because I would be very happy to be shown to be wrong.) From nobody Mon Mar 30 21:05:25 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAC23A1A2E for ; Mon, 30 Mar 2020 21:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=XCfbn/EU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d67UEBHb 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 CRzg1VnpICCn for ; Mon, 30 Mar 2020 21:05:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6462C3A1A2D for ; Mon, 30 Mar 2020 21:05:21 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id F0D9E602 for ; Tue, 31 Mar 2020 00:05:18 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 31 Mar 2020 00:05:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=1plvMBrjU0CQ4Was9yllop5q7BynJ71 L/LbljXq+ITk=; b=XCfbn/EUJGM/UhPHbRQnxiTrb2KPgpripTnqIrjEprgUlED AFu4Y6vpHcPz7xQiGhcG0kLjnlFpbKBWyDXIVNkf1uSO3cMmo24T2XeFrP8wKaK+ hWSSVziq4Uho3MOzFtK9pVogVMwkIZZgfexjyyj4irZuzT6W4vFPN8BKKvmHFHnF DhGvSn3ZGOQEaLrIS7Euafeb0l0H9kOBkwQPFGYoMParKCV+q/A6RFjopeLNSGIY jvvxuH8I4EdTmSf00kXrgyifWcnWyzTatTWtjll4pOW4WmNog1+7kjNxTdAn3UkL cKRNzYF7mK3N3uEFHZZDRxFynvfEN8XzIcR5XAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1plvMB rjU0CQ4Was9yllop5q7BynJ71L/LbljXq+ITk=; b=d67UEBHbaPogOHrRLd7y00 as60pr9WmrfgReve6ol4n+3KTk4dmuBLBRgFyL3L9elB0SFkLnJAwx6ScE/GmpLV rnoFBK7QTxiO9miU0upS7lZuJObYavZMbjjLLSavzzNKvgjup38eFiIUFAVQEvae KITsRu/Y3RFKn2jTu6eqYLFpXqCk3HBSeytqZ2GA3ph1ww7wYp7TgVL/M5arFNiv K4PKk6TvyNs720wE1Yg5jCof6qbDt1eSLLrGlxgxA8XhiaENnmCr+D7u/RJQLxvp N0wwHmBoG4GfLzNj4+gYCFIOek1DjJEFKqZNmYSFJtGnFucpk11AIaSRCYMrJHlg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 614FCE00BA; Tue, 31 Mar 2020 00:05:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 31 Mar 2020 15:04:58 +1100 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] Security, authority, and privacy X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 04:05:23 -0000 On Tue, Mar 31, 2020, at 08:46, Jeffrey Yasskin wrote: > I think you've accurately described the implications of the threat > model in which an off-path attacker who steals a key must not be able > to harm a user (using the user's trust in that key) in any way except > to put incorrect information in their brain. I'm not sure that's the > right threat model, but it's possible. If publisher.example have a key compromised, then phishing is a real concern. If we insist on having the ability to say "publisher.example as of time X" in UX, then people will expect that typing their publisher.example password will not result in that information ending up anywhere else. I don't see any way out of this, but there might be a few things that make this less scary: 1. Password managers won't offer to autofill. So people would have to type the string in. But the expectation is that they haven't visited this site before (or else there would be a service worker instead), so why does the user have a password to enter? I don't think that we can stop sites from taking keyboard input and spoofing password fields, but this does imply some possibility that the browser might detect bad behaviour and block further input. 2. As suggested, if the user agent truly is offline, then there might be no harm in blocking access to the network (and postMessage, and ...) until a transfer is successful. And to delete or quarantine information if the transfer fails. (The question of recovering state from quarantine is fraught, but we might work something out eventually.) I don't know what I think about all of this. It seems like this more motivates display of a garbage origin than it does trying to find a way to have the "true" origin displayed. From nobody Mon Mar 30 21:41:27 2020 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76E3A1AB1 for ; Mon, 30 Mar 2020 21:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=XdnfijNs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=x/m9wCtU 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 ZHtr2o4MKM6u for ; Mon, 30 Mar 2020 21:41:24 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D6D3A1AAF for ; Mon, 30 Mar 2020 21:41:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id C0D5D730; Tue, 31 Mar 2020 00:41:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 31 Mar 2020 00:41:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=iLsAy//FTHKlR76MBiXOqKhk87zv eV3uA7HGvCzTOZQ=; b=XdnfijNsy6VNRJ8OOedvGjJ0WDCIMFPeLkO/RX+fJUdK 4fQrk3ohdYgJoX8XUjfQrAd/NqhOr5Db41NnBZq7Ha7RK9lrC3nBWW8BDDkz/E5W 8V24PcYqrtbK6M5FzzQcGbxV2+Xbp6QCrY6/S8GNx1d1g77AQfxulMYwoLSWyzhB J3YYTbi3IlZeANzpIIdpJs4s3mhBPea+3vpQWBdBWtu+iy9tv1m/BVf1OL7f64NQ vGFNugdUAwQkz8Y4bxl4zYsEQV6TcjJ7kqAWXPnqF60D/Hdf+4AfbLU6GkCk4yDx ptP9JvxS6KQdPe8reJqqBaEGmpDgYNqtAVl4zSWQ7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=iLsAy/ /FTHKlR76MBiXOqKhk87zveV3uA7HGvCzTOZQ=; b=x/m9wCtUErMmhLSyLvvG5j eV3d1N/O/W3Afgj21zDlCWQCC+hfSwjJweTFyZBqjJMZIQCQzsIiOIENcyQHF17l BLqHR5a2nd0AVO+nzp8Xu/5MaYBgxpNZvnDLmAhyQf2i9J0iu0IzYySjD/S665tc H5ZXrct5kTtsonr0TWravTvQZdsFKusO46vIqCXDh6V5A5zSgPg+AQDw8lRDdlGF XtkeaFBIumlIuk0OdwSsoXzh01G9TQFf04+td+kibBG4C5cXiOk0f/c/Xi2BFo/2 kyEmEOr2LKdfu5Iom664FJYQEhs7UGMzb8fkc8FspXQaUC+5BprgasttqDy2W26A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpegvgigrmhhplhgvrdgtohhmpdhgihhthhhusgdrihhopdhgihhthhhusgdr tghomhdprghmphdruggvvhdpfigvsgdruggvvhdpshgvohgshihthhgvshgvrgdrtghomh dpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CD1AE00D3; Tue, 31 Mar 2020 00:41:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> Date: Tue, 31 Mar 2020 15:41:00 +1100 From: "Martin Thomson" To: "Devin Mullins" Cc: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] About content-based origins X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 04:41:26 -0000 Wow, that's a long list. I think that a lot of this relates to the inherent difficulty of providing customization under a regime like was described. This includes all the experimentation things, CCPA/GDPR consent notices [1], analytics, loading resources with referring origin-based ACLs [2], personalization of content, etc... This is something that a signature-based system helps with because you can front-load all of this into custom bundles that are all signed with the same key, but you treat all of these as equivalent. I think that Ekr and I both separately mentioned in on the call last week, but it's worth writing this down somewhere (because I failed to do so thus far). There is a variant of this design that uses signature public keys as the primary identifier and considers all content signed with the corresponding private key as the one co-extant origin. That avoids most of this mess. There are a few challenges, but as the liveness test (Sec-Signer-Origin maybe) remains, concerns about revocation are approximately the same as it pertains to protecting the target origin. The reputation issue remains, as the granularity of key use becomes imperative, and I don't think we should accept any signer-based origins as valid if the the same key is used for a different target origin or a certificate. In other words, don't cross the streams: if you want to attest as example.com that this content is yours, then you will need to use a different key for that purpose. (I suggest we continue to discuss that question on the other thread.) The other question you raise is the difficult of implementation for this. I don't know to what extent state is used in frameworks and sites, so I don't have a good handle on this. The suggestion to keep a record of pre-transfer state is a good one that seems immediately useful. However, for the general problem, I posited offline that there are a few cases in which merge strategies could be trivial: 1. Exclusive access means no merges: If a content-based origin has exclusive ownership over a particular store, then merges are trivial. This is true for a single content-based origin that transitions to a target origin: you can likely assume that the target origin has no pre-existing state before the transfer. You only have to worry about multiple different content-based origins that write to the same logical store, or a content-based origin that doesn't transfer to the target origin for some reason. It is quite likely that many transfers will take information for which the target origin has no pre-existing state. Signer-based origins are more likely to enjoy exclusive access, though we do have to admit the possibility of a single target origin having multiple signing keys and so have multiple sets of state to reconcile, but it might also be possible to have good alignment between access to stores and signing keys to avoid the need for merging. 2. Simple merge strategies: If state is trivial, then very simple merge strategies can be effective with very little effort. Say that you had a control that set a preference. That might be a boolean (dark mode on/off), or something more complex. Last change wins is a perfectly workable strategy in case of conflict. A less simple strategy is to record discrete changes with timestamps and then taking changes in time order. Finally, for non-trivial state, my hypothesis is that servers want to record that state server-side, so the question becomes whether any sort of offline modification of that state is desirable anyway. At the point that a site wants that capability, then yes, this is engineering. But that is engineering they have to undertake anyway at that point. [1] The informed consent doctrine is something I think is despicable, but I can't deny the force of law. [2] Not secure in any real sense, but this method seems to be pretty effective in practice. On Wed, Mar 25, 2020, at 17:35, Devin Mullins wrote: > Hi Martin, > > Thanks for the engineering work on this. For others, I've already > reviewed this, had some chats with others on the AMP team, and had a > few back-and-forths with Martin (he's been very gracious in engaging > his time, thank you). I'm trying to estimate the feasibility of this, > both for the AMP use-case, and for the non-AMP use-case [1], which we > hope to see flourish to the extent that publishers and users desire it, > and only impeded by implementation costs where necessary for the common > good. > > With the caveat that this is very early feedback, the high-level bit is > that, with some modifications, it seems mostly feasible for AMP. > However, there are two main downsides: > 1. worse UX on sites that run A/B experiments > 2. technical constraints make this harder for publishers to adopt on > non-AMP, as compared to SXG > > A lot of details follow. I suggest to rename the subject if you reply > to a detail below, in order to reduce cross-talk and make browsing the > archive easier. > > Details: > > We would need the display URL to be the attested URL even before > transfer. I suspect a flash in the URL bar would be frustrating for > both users and publishers. Jeffrey had proposed using signatures for > this. I'd suppose UAs could choose to render this with a "may be stale" > indicator. > > In terms of publisher implementation feasibility, I think the mostly > likely implementation would be for a publisher to produce a > Sec-Content-Origin (Sec-CO) response for the current version of the > resource iff it matches the Sec-CO request. I suspect that keeping > state of past versions of the resource would be infeasible, especially > as it couldn't be done purely at the edge; it would require something > like a region-wide cache. The value of the above stateless > implementation would be inversely proportional to how often the > resource changes (e.g. "transient content" [2] such as Related > Articles). I think this would be a workable constraint for publishers > wishing to publish such bundles, but felt it's worth noting, > nonetheless. > > Re: fallback behavior on failed state transfer, distributors would need > a way to monitor failure rates. This serves two purposes: > 1. Automatically detecting errors in the distribution pipeline. This > is the same purpose served by > https://wicg.github.io/webpackage/loading.html#signed-exchange-report. > 2. Verifying that, for some fraction of navigations, bundles are > meeting AMP's stated UX goals (by using the verified content in the > bundle and not potentially arbitrary content after the redirect). This > is a dynamic equivalent of what can be done mostly statically with SXG, > because the distributor can run the same algorithm as the UA, modulo > client/server skew in clocks and root stores. I think this is a > trade-off AMP could make. The alternative is that the fallback behavior > keeps the content-based origin (CBO). > > There is a possible vector for user ID transfer from distributor to > publisher; filed as > https://github.com/martinthomson/wpack-content/issues/1. > > This limits the ability to run session-sticky experiments (in > https://amp.dev/documentation/components/amp-experiment/ and many > non-AMP frameworks). The publisher has the following options: > 1. Delay rendering content under experiment until after state > transfer. This hurts UX for the sake of experimentation, creating a > trade-off that otherwise doesn't exist on origin (modulo ease of > implementation). > 2. Generate a client-side UUID before state transfer, and join it with > the pre-existing user ID after transfer. This means the session could > not include CBO pageviews anywhere except in the first pageview. > 3. Generate variants of the bundle for each experimental state. The > distributor chooses which bundle to send to the user (based on what? > not sure). For a page with M independent experiments each with N arms, > that's N^M variants. For large enough M and N, this is likely both > infeasible for publishers and martinthomson/wpack-content#1. (But I > need some guidance from experts on typical ranges for M and N.) > > Perhaps this is a need the UA could address. A straw proposal -- a > selectExperimentArm() API that: > 1. only exposes as many bits as the UA deems OK, and > 2. exposes different bits to different attested origins, so they can't > be joined > On the one hand, perhaps this is too much scope for wpack. On the > other, it addresses a problem that is somewhat particular to CBOs. > > This impedes content management (e.g. dialogs for GDPR and CCPA), > compared to SXG. The publisher has a few choices: > 1. Delay rendering the dialog under after transfer. I think this would > cause layout shift (https://web.dev/cls/). > 2. Render the dialog, and risk discovering that it's already been > acknowledged. At that point: > a. Hide it, causing layout shift. > b. Leave it there. This is way outside my domain expertise, but ISTR > there are some rules or at least best practices wrt when it's okay to > re-show an opt-out dialog. > One of these options may be an okay trade-off; I'm not sure. > > Analytics providers (via > https://amp.dev/documentation/components/amp-analytics/ and many > non-AMP libraries) would have to do one of two things: > 1. Delay pingback until after transfer. This risks a lower fraction of > successful pingbacks, as e.g. the user might close the tab before > transfer. > 2. Generate a client-side UUID, send pingback before transfer, and > send a follow-up after transfer to join with pre-existing user ID. This > captures those otherwise lost pingbacks pseudonymously (anonymously?), > though it requires server-side work on the pingback endpoint. > > For the above client-side mitigations, two feature requests seem > necessary: > 1. Store the transfer metadata (e.g. indexedDB renames by time) > somewhere more permanent. For various reasons the event handler may not > fire or finish, and it would be good to later scan for stragglers to > merge or expunge. > 2. DOM API to wait for transfer to complete. > > Some subresources are ACLs by Origin header (e.g. paid fonts). Likely > mitigation is to defer loading until transfer, with a timeout whose > duration depends on the publisher's font-display preference. (Martin > suggests an optimization where the encrypted subresource is loaded > early, and only the decryption key after transfer.) > > Last but not least, I am concerned that this is a bar that is > disproportionately difficult for non-AMP publishers to meet. The above > client-side mitigations are possible, but quite a bit of work. > 1. For frameworks like AMP that strongly encourage publishers to use a > rolling release, it is possible to upgrade many use-cases in the wild > with minimal publisher effort. > 2. For other frameworks, it may be possible to provide this support, > but the requirement to upgrade versions may limit applicability. > Because upgrades occur less often, they often require more work. > 3. For custom JS that manages state, authors will need to modify it to > move or copy state into indexedDB, and handle transfer events and merge > conflicts. > > From a "minimal publisher effort" perspective, I am especially > interested in making it possible to have as close to a turnkey solution > as is reasonable, for instance at the level of the CDN or CMS. If such > a solution exists, sites would likely contain a hybrid of all three > cases above, and thus want to opt into such support incrementally. How > should a CDN determine which pages to provide Sec-CO responses for? > 1. URL patterns are the simplest answer, but I suspect hard for > publishers to create and maintain with minimal false negatives and > positives. > 2. Would it be helpful to thread an "I support state transfer" > annotation for some portion of the build journey, from individual JS > function all the way to bundle? Would folks use this? > > I don't have a good solution to the issue of non-AMP developer cost, > and thus fear this is a solution that would feature a disproportionate > amount of AMP pages compared to the background distribution of the web. > But I'm hopeful that other JS framework developers can chime in with > respect to feasibility of support for CBO and state transfer. > > I'm leaving out some of Martin's replies to the above; no offense > intended. It took me long enough just to summarize the above, and I'd > better send it early enough so at least a few people have time to read > it before the meeting. > > Thanks, > Devin > > [1] > https://blog.amp.dev/2019/05/22/privacy-preserving-instant-loading-for-all-web-content/ > [2] > http://www.seobythesea.com/2011/12/how-google-might-identify-transient-content-on-webpages/ > > On Mon, Mar 23, 2020 at 5:35 PM Martin Thomson wrote: > > Ted's note prompted me to send a much-belated announcement (sorry folks, I forgot). > > > > The draft is here: > > https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00 > > > > A nicer version here: > > https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html > > > > This approach could a dramatically different approach to addressing the use cases set out in our charter. > > > > In short, this aims to address the core question of how offline content might *ultimately* be attributed to a web origin in a fundamentally different way. There are two key concepts: > > > > 1. Content is given its own origin, using a new system for identification. > > > > 2. A target origin can "accept" content and state from one of these new origins. > > > > There are a lot of details here (read the draft), but the major advantage I see is that you don't have to make an offline decision about authority, and that means you can be offline for much longer (lifting the 7 day limit). > > > > What it does have in common with signed exchanges approach is the need for a bundling format, but in its current form it is less dependent on the details of the format. That might allow that to be simpler, but I'm sure that the need to mint new identifier types will more than make up for any slack there. > > > > The draft is quite rough. I'm sure that it has the remnants of a few bad ideas still hanging around. Ask questions if you think something is unclear. > > > > _______________________________________________ > > Wpack mailing list > > Wpack@ietf.org > > https://www.ietf.org/mailman/listinfo/wpack