From nobody Wed Apr 1 14:21:06 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 2127D3A09D0 for ; Wed, 1 Apr 2020 14:21:05 -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 urBlolugcZyX for ; Wed, 1 Apr 2020 14:21:03 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 344023A08DD for ; Wed, 1 Apr 2020 14:20:49 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id h9so1779960wrc.8 for ; Wed, 01 Apr 2020 14:20:49 -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=JzmA7iUkmZgIZqbHgxRLpJmUZ5PMlbNvPPhmIEtymaw=; b=JindSICF1wa6BK7jzUq5wZORfbOBfqpR7NBKfBaf72asm7EMviV1Eq400ceDt3mdpn 9j4FAg7c5o4mrYKZUTcY9MoUcdfcK9kngc/MrdzavBG6PrNwU5ijzZ46taCK5+R2FJOK RfuXsZ1qxtk75HkBrCjhSbsMRvIN9Zo6uQsOYP/5TF84HfU1Q/ZwgWMXYRhk2JrcUvFD lt9hp/iEHAM1BSxm2Ljo/m+/H2NmSWqdO/pi32BWQ6FeT5ee1wKykIAFgRwGWObV3WYK MbB8NCf805jUWZwuWRdzfSyITsFFaRUlguPh623upUul0Nys+hdQ6J3/JyTaBfGv4zR9 2sEQ== 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=JzmA7iUkmZgIZqbHgxRLpJmUZ5PMlbNvPPhmIEtymaw=; b=EzwtMrNAFkPGknj93zrt5qjjEzCxcRmlAhbBjVF6aqdiF9BuJMHgTRQjt4nJic5d3r JHmYHnyK16GNDE3XMTp/W9tHnTYwp9V6MpJwTTt8fruG6fqNg9K/7Ik61QeasfYqX32U WHUjnO6AK78Yyp0HUOAT9xfBQnAFzUHYEaVDgLKWRl8dkJOXaQqD5IKrxrYDW8vqMqpI /1wvtcB4nN7rk10ekLfNFyG6b8/1K0NwlQcwZzBmvdhS9baop7qMPhTqHJwsRndn9The gtGySZXZWBwtcnkTpmCEr+7vfXzhGcc37XxiYDp53Ve2s1HkwAG9mQeA+09l0J0WKZey HNbA== X-Gm-Message-State: ANhLgQ3BF8aV3qvUamVJKb9qQhl1EzrojLMEYV6y5d0GUpm2hpwjSbz3 xT0BPfvVOrPqkuNTVoCKiyOzVLzq0IHyfnpaML+RCkAT X-Google-Smtp-Source: ADFU+vtTCdubG5lo7AoJAD0s9KXDpiZhuYMQArtkrG3Km51VGAAdFZj0k6t0opAXy2oFg39jZEj4Fg6Pfdq+sMiFeIo= X-Received: by 2002:a5d:68c4:: with SMTP id p4mr28320778wrw.308.1585776047366; Wed, 01 Apr 2020 14:20:47 -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: From: Devin Mullins Date: Wed, 1 Apr 2020 14:20:21 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000ffa37105a241417f" 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: Wed, 01 Apr 2020 21:21:05 -0000 --000000000000ffa37105a241417f Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 8:44 PM Martin Thomson wrote: > 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). > Ah, my assumption was that the UA could limit the number of options the server was allowed to respond with, thus weakly enforcing that others have the same content. The utility of that enforcement would depend on the RPS of the publisher's server, I suppose. --000000000000ffa37105a241417f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2020 at 8:44 PM Martin Th= omson <mt@lowentr= opy.net> wrote:
Not really.=C2=A0 The push can include th= e H(Content) and the site can calculate H(H(C)).=C2=A0 So the truncated has= h only really limits the information the client has to include, trading it = for more from the server.=C2=A0 Since opening that issue, I'm not convi= nced that it is worth pursuing for anything other than that trade-off (whic= h is only a maybe-optimization at best).

Ah, my assumption was that the UA could limit the number of options the s= erver was allowed to respond with, thus weakly enforcing=C2=A0that others h= ave the same content. The utility of that enforcement would depend on the R= PS of the publisher's server, I suppose.
--000000000000ffa37105a241417f-- From nobody Thu Apr 2 08:44:46 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 1F2013A15DD for ; Thu, 2 Apr 2020 08:44:45 -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 KXppLfO3ppQV for ; Thu, 2 Apr 2020 08:44:44 -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 0410F3A15DB for ; Thu, 2 Apr 2020 08:44:43 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id q188so4381998qke.8 for ; Thu, 02 Apr 2020 08:44:43 -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:date:references :to:in-reply-to:message-id; bh=EuEIEqqcdU6WLYtLj57vTFAj0QDhqGWmY5l1I344C5g=; b=TZTPBmT7y+tO4bG+JYDMw+kbEXue6OznngnbdboW+hCns3Omzzenhd8tdwQYOGF0zR gXKcT7B/iIvlmH81dJ+TNPOYXnbtAvW0WapRYq3/egoEx3U9g0vaLao8CL5z+gJY7ShE TF0V8uYr27wza01baRNuhCsfUI2FPPMt7Vn8s= 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:date:references:to:in-reply-to:message-id; bh=EuEIEqqcdU6WLYtLj57vTFAj0QDhqGWmY5l1I344C5g=; b=e5JbuEmC0K5kmrRakm1wtJCFNPzw97N1LYEpkGt6a2viNiPzjQ1RvBRpWYniJNi6n3 igR4Jak8mEXJYfsz1atmg8uWg2NupQs3U7SdpPG1OUEkkpM0oCKi0LUiq3WrnA2XrEsO N62GwoK519mOUHFa1wOGjyEzMAUioPpyDcHxPUAjTvL3UbSwdkz7tbmDMzmZ0liYB8QQ +w1J9E6UFsy4+QsFLW/SA7XReI1NsTxI+qOsgH/twt5SAB2s0ZlLKyy+fbzEsAhg9DV7 6xVe697dQs6n53JHe1I6sQzwpnxR6+BwP0DogYztrEDK75XTQ5c/hOyu455puCNZFWgU mytg== X-Gm-Message-State: AGi0PuZ+Uy5ket309J8Rbt49U3fNt4YY3+Bcu7uBRxjk0SgMIKXrpvkP pLDxUvMgf0369yYNjLyWyh0BS6oGdac= X-Google-Smtp-Source: APiQypLI0SI/ESgL8F7j2f/mAvMU7rx3js8QIxJwkY5oHFlS4L4wKJLrJ/RL6gfq2kfgbSkJAeAPZQ== X-Received: by 2002:a05:620a:91d:: with SMTP id v29mr4003330qkv.424.1585842282797; Thu, 02 Apr 2020 08:44:42 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id h138sm3649387qke.86.2020.04.02.08.44.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 08:44:41 -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\)) Date: Thu, 2 Apr 2020 11:44:40 -0400 References: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> To: WPACK List In-Reply-To: <28C48D9F-4865-4C02-AB35-A366AA280DED@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) 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, 02 Apr 2020 15:44:45 -0000 hi WPACK Thanks for your input. Dave and I will share the repo information once = we have established a repo. spt > On Mar 25, 2020, at 15:45, Sean Turner wrote: >=20 > hi WPACK, >=20 > 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. >=20 > Thanks, > Dave and Sean From nobody Fri Apr 3 15:59:33 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 F0E2C3A0DDA for ; Fri, 3 Apr 2020 15:59:30 -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 i3_5mEW1iaEO for ; Fri, 3 Apr 2020 15:59:29 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 DF6B13A0DD4 for ; Fri, 3 Apr 2020 15:59:28 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id g3so8132681wrx.2 for ; Fri, 03 Apr 2020 15:59:28 -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=DuMj53OkN8ed45jz36VPxQ8kGeO+EMfwsJLRd+HyzTM=; b=Hvx/8h8tlJlc8NYWNtUVuqQXtvJYsATHKD6ZaYAMWK3p6rMOEQZSP6xu4QQ/9OQpHl RpmroS1+8JPkyb8w3M1gKYh/jZkH/k8D4VT5syUvTRjE3zthYhKmNRrx4OPudQl35z2+ 8xjtQiTgaTL1TgD4XKgo7Fr5CgBeiT0NrHr0iX1SORVdH36x20zekPL7/RpBAnD+gXqy NItMOu6PlMNVcdEql4haVnAE33xphKAQFrYu1fxanRZoCPrahDcpz/Kvmkf/1eyCp+sI yHsG9k1mpsQPWa/CqofvjhYLwBHjrp393tzTKHPoKgz+Q2ImI5iwuMgMJL9k1g9RAX8f +pcQ== 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=DuMj53OkN8ed45jz36VPxQ8kGeO+EMfwsJLRd+HyzTM=; b=uAW20obvRUKJ74bMjVEr3YvUVJocfg5F7Qs+OxWR5e6Kn/32meA7cPuiYL8FtFqSCi OHOnHSU6stsp+l5FVWZPwAMuwFq6XtKvuv90QDB76ZkC+/X9+Tn8V6N4OdI2bK9x/Nst 3g4lrZehIg+QUyvK/lFyCioFlR0ebWG1r+ZObTXXZec7QdjnSeddIi6RGU6HbGlE70qx IikhGxdeZJH8S09w81yHFu7z26K7xa+p+Nkqloh5038dD7RboVfnayxREhAFHaHORDVV D9alWCCzkNqh/t4Ot83BFTVrsOUoh0qKM4clBTi6uwUT1JePZQjRFMPJsZvhaIAyfVfj Op5A== X-Gm-Message-State: AGi0PuZ/IrKdhfafPBvWkBGK3DIDvl9uCC116k7JyzDcFAvwGDGBkPhm +M8pKo/voaLcgWjo+/UbpJGHurhDPzfptPyk1rmWq5O76VE= X-Google-Smtp-Source: APiQypJ4lquj+s5dBy390loJi87lgxYhrRbcEZaZiNh4VpztUApvgaSC2O58rF/jRZ+jTYkfQ0dFlgXK+YF8yMf4eSM= X-Received: by 2002:a5d:60ca:: with SMTP id x10mr11875046wrt.372.1585954766737; Fri, 03 Apr 2020 15:59:26 -0700 (PDT) MIME-Version: 1.0 References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> In-Reply-To: From: Devin Mullins Date: Fri, 3 Apr 2020 15:59:00 -0700 Message-ID: To: Martin Thomson Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000080c6b105a26ade5b" 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: Fri, 03 Apr 2020 22:59:31 -0000 --00000000000080c6b105a26ade5b Content-Type: text/plain; charset="UTF-8" > > 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. > Ah, interesting. This could solve a problem I just learned about. https://amp.dev/documentation/components/amp-access/#amp-reader-id is used for access control (e.g. paywalls). It has different user IDs across different (publisher, delivery, browser) tuples, so this would bring that to parity with existing behavior. For experiments, I think the origin would want a way to opt into sharing some subset of its state with this co-extant origin, before Sec-CO response (e.g. for those middle-of-session pageviews). Otherwise, it has to delay rendering or risk generating a session should be excluded from analysis. Similar for consent. For analytics & origin-based ACLs, their libraries/services would need code changes (either to defer requests until origin is correct, or to accept some alternate attestation of origin). My guess is that, even outside of AMP, these are usually rolling releases [1], and thus changes would be largely achievable. Just a guess. This is of course coming from my document-centric view of the web, since that's the use case I'm thinking most about. [1] e.g. https://developers.google.com/analytics/devguides/collection/analyticsjs 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. It occurred to me it may be possible for a bundling service to determine whether a page uses state, with ~0 false negatives. Easy version: disallow any feature that uses state, such as JS. Medium version: hardcode allowances for certain common 3p scripts. Difficult version: analyze trivial scripts (classifying "don't know" as "uses state"). This would allow easier implementation for at least some portion of the long tail of the publisher distribution. For the torso, the publisher could provide an override annotation for any page that the bundler classifies as "uses state". --00000000000080c6b105a26ade5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that Ekr and I both separately mentioned in on t= he call last week, but it's worth writing this down somewhere (because = I failed to do so thus far).=C2=A0 There is a variant of this design that u= ses signature public keys as the primary identifier and considers all conte= nt signed with the corresponding private key as the one co-extant origin.= =C2=A0 That avoids most of this mess.=C2=A0 There are a few challenges, but= as the liveness test (Sec-Signer-Origin maybe) remains, concerns about rev= ocation are approximately the same as it pertains to protecting the target = origin.

Ah, interesting. This could sol= ve a problem I just learned about.=C2=A0https://amp.dev/documentation/c= omponents/amp-access/#amp-reader-id=C2=A0is used for access control (e.= g. paywalls). It has different user IDs across different (publisher, delive= ry, browser) tuples, so this would bring that to parity with existing behav= ior.

For experiments, I think the origin would wan= t a way to opt into sharing some subset of its state with this co-extant or= igin, before Sec-CO response (e.g. for those middle-of-session pageviews). = Otherwise, it has to delay rendering or risk generating a session should be= excluded from analysis.
Similar for consent.

For analytics & origin-based ACLs, their libraries/services would= need code changes (either to defer requests until origin is correct, or to= accept some alternate attestation of origin). My guess is that, even outsi= de of AMP, these are usually rolling releases [1], and thus changes would b= e largely achievable. Just a guess.

This is of cou= rse coming from my document-centric view of the web,=C2=A0since that's = the use case I'm thinking most about.


The other question you raise is the diff= icult of implementation for this.=C2=A0 I don't know to what extent sta= te is used in frameworks and sites, so I don't have a good handle on th= is.

It occurred to me it may be possible fo= r a bundling service to determine whether a page uses state, with ~0 false = negatives. Easy version: disallow any feature that uses state, such as JS. = Medium version: hardcode allowances for certain common 3p scripts. Difficul= t version: analyze trivial scripts (classifying "don't know" = as "uses state").

This would allow easie= r implementation for at least some portion of the long tail of the publishe= r distribution. For the torso, the publisher could provide an override anno= tation for any page that the bundler classifies as "uses state".<= /div>
--00000000000080c6b105a26ade5b-- From nobody Sun Apr 5 23:55:04 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 59D183A07C1 for ; Sun, 5 Apr 2020 23:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=KOa9nNBc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cgKFWoJE 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 Nd878QykuHQr for ; Sun, 5 Apr 2020 23:54:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6F03A0794 for ; Sun, 5 Apr 2020 23:54:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 557B35C00F9; Mon, 6 Apr 2020 02:54:58 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 06 Apr 2020 02:54:58 -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=0axUn7LlQ3x6TrT0hTXwGfQpYXgx RW57OLYL5AcH13M=; b=KOa9nNBcaXkwbpuXei1bf1UVmlA5fIv4ZZNubD+DNSpw ghs5VzWuE055Rpthm/JfBjbWf7C8pEuQxyqKhZ3gSTQ4VgVXjcXP2JYRog/y6tWH UjjbCEK9yp/0/B5y+OY1rAjQ6CGNX9qmz5m4w4PIKJcwrzREK8KEl2vgWMR+CYa7 JziEXMG/goR7e22nwQIZQRe7nlz4mI2RFc8e0wrkWGoKDmw2kZkAMn5d4u/ZnOZR LBBM1CSmxyvCTbiCEZYEZcFqHHRoxiIlVme5g8UIAIRAwY7kzb3qLuxaXCYpqucU zsVeNZZ0dQRCZFykl4u8/FQo0g9tQPMNc8pjQ1Lh4g== 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=0axUn7 LlQ3x6TrT0hTXwGfQpYXgxRW57OLYL5AcH13M=; b=cgKFWoJEQUDhEntOJ9vJ2t Io+3ICaJzLFqULYfTCM9cOVpLmkDf+W4TlGx+u1gN0DXJU9ZZLZ4csEmedQCKB+x wucB7Mibcr+0jBdkZNp8X885PonsYkckgmAKjnEdoryHPDzTKdF+Hfdbp00LEyvE FDKjjXyeK2lGbLfqvKnwwHbO8+hDqe5aBMLU4wv7NhZMZOQADsTrk/LX3NlyKVLU a+55IbK0AYOyiAxrY6PAEmO2bs7e9CRDeOSFR5mFUCq8tHqL+3GtQYXSj+ly4MTD brEXg6ih9NdFt39otcWope9yqMwE+6IPBa+AIiHwyn0wt50SxjrqjP0v3BMH2FeQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D551E00B1; Mon, 6 Apr 2020 02:54:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <260dfc2f-8399-483e-859d-08f92821c823@www.fastmail.com> Date: Mon, 06 Apr 2020 16:54:36 +1000 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: Mon, 06 Apr 2020 06:55:02 -0000 On Sat, Apr 4, 2020, at 09:59, Devin Mullins wrote: > For experiments, I think the origin would want a way to opt into > sharing some subset of its state with this co-extant origin, before > Sec-CO response (e.g. for those middle-of-session pageviews). > Otherwise, it has to delay rendering or risk generating a session > should be excluded from analysis. > Similar for consent. There is nothing that is inherent to the design that prevents content from talking to its target origin (or any other origin for that matter). What might cause that to be limited is policies that a browser might apply to those interactions. For instance, in the AMP case, the entire point is to prevent that sort of communication because that might allow a publisher to exfiltrate information about the linking context prior to a decision to activate a link. Assuming that the transfer of state to a target origin is under programmatic control, then any number of things might occur prior to that. Even if you assume minimal communication, you might allow content to specify query parameters on the request to transfer. > For analytics & origin-based ACLs, their libraries/services would need > code changes (either to defer requests until origin is correct, or to > accept some alternate attestation of origin). My guess is that, even > outside of AMP, these are usually rolling releases [1], and thus > changes would be largely achievable. Just a guess. The deployment question is separate than one you might make about target origin. Content that is served from A might falsely claim a target origin of B, so you would have to allow the server that applies the ACL to decide not to accept the request. Assuming with an assumption that this sort of request would be denied might be OK. For deployment, yeah, I expect that if there is enough demand for this, then the providers of fonts and other such things would be motivated to enable this interaction and could do so relatively easily. > It occurred to me it may be possible for a bundling service to > determine whether a page uses state, with ~0 false negatives. That seems right; you could probably get a long way the way you describe. You could maybe also do this empirically: load pages with an extension that shimmed out those APIs that relate to state and log uses with some false negatives. Browsers could help with this by hooking that analysis into the reporting API, or by supporting CSP rules that constrained use and generated reports on violations. From nobody Sun Apr 19 20:09: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 085143A0D71 for ; Sun, 19 Apr 2020 20:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 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_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 ywojHntDeCXp for ; Sun, 19 Apr 2020 20:09:30 -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 662463A0D70 for ; Sun, 19 Apr 2020 20:09:30 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id t8so2065886qvw.5 for ; Sun, 19 Apr 2020 20:09:30 -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=p017Dm2qDW1vgM8i7mZ9e+NbMj3amgfexVv/b85UAwE=; b=BfIAPfI9pt11/Z9e0xFfIrSb/Yc9adQcgdqJNkg2AmSMVpak8qhXDcDk70h03hT/Ix 1R/roNFC2angAimrojNA/vV++UIzAD35d6ii57CHWcTJKYbUDQ2bgcSkyXRnS7YDPCNC utwrp9SPH1Hr9Q4V15ZcFv/1C9kX7mxInHIiA= 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=p017Dm2qDW1vgM8i7mZ9e+NbMj3amgfexVv/b85UAwE=; b=igZAZILm6jYx2TNs9VEygPxai6HnwG+PWkbA0iu4iJkkXSVIJSTkz/1Cwr3q8ZLbTS 0QC9VGmB98m/6xpq4422WZE2mUNyar7ITJAqXrAYujDAg+rozSzxi1ykoOiRUEZUEVx3 s3zGHW5usc7DYYxGHPec+E3E9iAx7jOOIibI+NPOGOh6Qq7J0zkFCf8mOAtojy7J9ExX Q03QpuCUa8KVGVeeXYk3iAqGGK+iJLldSoy6H4vXE93VynCAdow2WDWnkUCxss8AKbBS AhOiiJW1y8F/RvJM9TIRmEppBF3TqBtIyLO0KZ7uKEIU/ke/zH0nJpk+m1OMMcjFAGA+ obEw== X-Gm-Message-State: AGi0PuZyRCM/1aCbOxD1uqNX1n79HYATrPkfnDgJcMRrrKLLXRyvHy3K y9MYkKQilKh8NKUVoAhhw0tn3R6Akl4= X-Google-Smtp-Source: APiQypK6nSc6GtsrJWjYuvu39BX43soQc85E1844xAwRMJSd4dVxRUYfph3rXW6iG6XSSx6bclBmOw== X-Received: by 2002:a0c:f9c2:: with SMTP id j2mr2390458qvo.90.1587352169211; Sun, 19 Apr 2020 20:09:29 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id o22sm12319746qtm.90.2020.04.19.20.09.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2020 20:09:28 -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.4 \(3608.80.23.2.2\)) Message-Id: <167B09C3-1961-4022-A34B-142C294C0759@sn3rd.com> Date: Sun, 19 Apr 2020 23:09:28 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Wpack] WPACK@vIETF107: Minutes 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, 20 Apr 2020 03:09:33 -0000 hi WPACK, I went ahead and uploaded a very lighted edited version of Peter Wu=E2=80=99= s etherpad notes as minutes. Please review and let us know if there is = anything you would like changed. The draft minutes can be found at: https://datatracker.ietf.org/meeting/107/materials/minutes-107-wpack-00 Cheers, spt=