From nobody Wed Aug 5 12:34:24 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 9565C3A0EC7 for ; Wed, 5 Aug 2020 12:34:23 -0700 (PDT) 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 an8E5eE-fpEC for ; Wed, 5 Aug 2020 12:34:21 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC67E3A0EC4 for ; Wed, 5 Aug 2020 12:34:21 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id A9B032B79; Wed, 5 Aug 2020 15:34:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24363.2492.676103.118366@gro.dd.org> Date: Wed, 5 Aug 2020 15:34:20 -0400 From: Dave Lawrence To: wpack@ietf.org Archived-At: Subject: [Wpack] IETF 108 Survey 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, 05 Aug 2020 19:34:24 -0000 One last reminder: From: IETF Executive Director Subject: [108all] Final reminder: IETF 108 meeting survey Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance -- Jay Daley IETF Executive Director exec-director@ietf.org From nobody Tue Aug 18 08:56: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 A142B3A0DD8 for ; Tue, 18 Aug 2020 08:56:49 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 PEij5L4r-Vxi for ; Tue, 18 Aug 2020 08:56: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 5ECE63A0DD7 for ; Tue, 18 Aug 2020 08:56:48 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id e5so15466345qth.5 for ; Tue, 18 Aug 2020 08:56: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=3b8mXa21DiDXCSZGZRSfaY92HzB02/a5Af5/ANgRAbU=; b=dp6u2X1H6dmU8C0WBzsHIt/fvlxWhaXdw7FwEMivduKtF3yKGrVr6IkzLkncdFpWbb Lk7d08HjTexJYruqeAQKUZa/kbJAY5cE4H+SUHAXV1vpc9m2HJ+rqjdv/YalwJG5tGpK WCxzy1dgiYqQYE62C08y6DqqFw3gGGsAx7ImE= 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=3b8mXa21DiDXCSZGZRSfaY92HzB02/a5Af5/ANgRAbU=; b=UiIhAPQ1ehmBNnBEkcRsYZ2KB4RVNBTv4YAYpOE+ip6bqbxtUInMJVrCCbWpwU1Ig7 nOUFn7qPoMB/6RBF7iLnRsVD45g2MG+D9YOWgdVzG5tLX9YDB7q/GldSzypOJjAFS/Nt MgYBu6Df11NugVsjy/IWa1pLvIjI5AWR84bqqzoxDVVle3oq9tXP0DRxgon9oJGHsDiL 2O0ZY3RjPinVsfdo8dQS6MsI+HENRas4FDeWOqGhswA27NFB6HTlwGtOQqE93Q1zPpzX kziBSmbjHwUK/0ZgifQ0LmfNyUu/b9wgA5EiWoHHBubmU9iVqV3ETantyXmt+AJFFd/i AiSg== X-Gm-Message-State: AOAM530EEaqmpfurfTW60rZMLGi/Bzd2GhQ46WYYJAT3Yqi9+9gC2FNF wSFptK+3wFgD504yrfqwwK38MEnnOlSVKA== X-Google-Smtp-Source: ABdhPJxxWhjSSDBTIXO4VD/4ZBPcC5/sA1zFS6CtMblnDSE9Z8IjiJs03cJjx3k6J/uRms7TNAZOwA== X-Received: by 2002:ac8:4d5c:: with SMTP id x28mr19430065qtv.35.1597766207054; Tue, 18 Aug 2020 08:56:47 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id t127sm21536837qkc.100.2020.08.18.08.56.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 08:56:45 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <1518D8BA-C148-4A05-882A-CE8AAFF87596@sn3rd.com> Date: Tue, 18 Aug 2020 11:56:36 -0400 To: WPACK List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Wpack] WPACK@IETF108: minutes uploaded 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, 18 Aug 2020 15:56:50 -0000 Thanks again to Martin and Brian for taking theses. Comments welcome: https://www.ietf.org/proceedings/108/minutes/minutes-108-wpack-00 spt From nobody Wed Aug 26 11:00: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 56B683A1955 for ; Wed, 26 Aug 2020 11:00:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qBE2qXZOs1oJ for ; Wed, 26 Aug 2020 11:00:48 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D3BDA3A1953 for ; Wed, 26 Aug 2020 11:00:47 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id p4so2871254qkf.0 for ; Wed, 26 Aug 2020 11:00: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=rVHMLGeBv1WBtW6TW+iHFjqsdq+MUIClvsTmtV7Ptug=; b=vYBzNO3mIFE3RE0F/Z7VxYINd5pY4R0kHRyh4chM8LCSSvUxfCPmd/GJqjqEzsRgT0 h2YA2RgAojw1OIuceZYMXh1abrbIN80Lj5nwb8etU+4kw6/J8TjkEKEErnWYKq4t0LXZ Po5fpcMNpYhPRKONmTNh3sT3sgGVlBB2gq7fJGeOw55T9ypdnddUM5uH0hB2JBToM5Ld 15GPetxIWUzDnbP7XH3B5RZoXr3mEGJG1E4GpYk1eoKUnIDkiAv+XG8ZYkzAl3ok9WK8 YPKlhG1OT5XHF1fUaKUOJgwcBxdrUREUUNqDac1IdchGWEi8ov9b1MhtDuR516QVxg9A V5iA== 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=rVHMLGeBv1WBtW6TW+iHFjqsdq+MUIClvsTmtV7Ptug=; b=k6FKcXuuyf/UGpA+9enI4yJ5OTXxFARNUyUz6oEdRY04PDW3iwuhAIU+/ASUhxZJXb +HJv+RGbOO9lJuBHKyVi2S0zAG20Mk0BVglu08InTL7mvP9NTO0fEqoT3AH27EO5qPfE 7T/cK3tMdkvbNTLv12ePtD3QvKucCXaoVsYl/aT7PHItWwk1p1ICI49zZMap4v2bpig5 dK3EgVFhtZgmEVOTSDYGI30iGftfRZEY3vFVU7hqdMpeUiHS/D+QQe1zug2QNlOEIJ5W Wc2c+wmxP3//+PzaKRMX13WEhkk0t3CAQV/4f4HWRXf+bWosQ7ImTrk31N+Zwgl8N7GE ebkw== X-Gm-Message-State: AOAM531DymFru4SJ08ypHB6Ge6pbFuhEnJnGiV1JLkAOs8ztGuafbXFR dfDV3AfOyuVUCiUZkjfEzQ5QCgfKeS66Zv4Ii/4fXSnLcTGaEil5 X-Google-Smtp-Source: ABdhPJxkMaoeUhSBh9g0N26UsKQueZnFgH/e7solU+K10OmfJ04W11xFwrREa4XtI75PDvm+lyM73jv5gvNWRIS1xCY= X-Received: by 2002:a37:b502:: with SMTP id e2mr15906445qkf.144.1598464846007; Wed, 26 Aug 2020 11:00:46 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Wed, 26 Aug 2020 11:00:34 -0700 Message-ID: To: WPACK List Cc: Martin Thomson Content-Type: multipart/alternative; boundary="00000000000055a05a05adcb9952" Archived-At: Subject: [Wpack] Counter-proposal where bundles only contain a single origin 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, 26 Aug 2020 18:00:50 -0000 --00000000000055a05a05adcb9952 Content-Type: text/plain; charset="UTF-8" I worked with Martin to flesh out his ideas for simplifying the bundle URL and origin design, and we came up with the following. I still prefer the proposal I presented a couple weeks ago , based on the tradeoffs down at the bottom here, but it's quite possible I've missed things. I'd appreciate this group's input on which way we should go. The basic idea here is that: * Each bundle defines a single origin. * Bundles identify their contents with paths, not full URLs. * Metadata can provide a base URL to resolve those paths against. * We allow a single file to contain multiple origins using nested bundles. Use cases: * Users should be able to share subsets of the web that can link within themselves, in a way that different sites within those subsets don't have their storage collide. * One request for ads should be able to return the contents of multiple iframes in a way that those contents can't modify each other. # URLs for nested bundle resources ``` package://distributor.example/bundle.wbn$app/foo.wbn$bar.html package:///c:/Users/name/Downloads/bundle.wbn$app/foo.wbn$bar.html ``` This fetches the outer bundle by removing everything after the first `$` and: * If the URL has an authority, replacing the `package:` with `https:` * If the URL doesn't have an authority, replacing the `package:` with `file:`. To allow the outer bundle to be fetched using a third scheme, we would need to add a matching new scheme for addressing inside it. Subsequently, each segment separated by `$`s is the path to look up in a nested bundle. Any `$`s inside a segment are percent-encoded. # Origins for nested bundle resources The origin of one of these holds the information from the URL up to the last `$`. So for ``` package://distributor.example/bundle.wbn$app/foo.wbn$bar.html ``` * scheme: package: * host: distributor.example/bundle.wbn$app/foo.wbn * port: null * domain: null We could also hold the part after the first `/` in a new component, similar to Gecko's OriginAttributes , but OriginAttributes are mostly undocumented, and origins define "opaque hosts " to encode this sort of information into the existing field. # Navigating across nested bundles Within something like El Paquete Semanal or the Web Archive, it's straightforward to store each origin in separate nested bundles, but we want links from one origin to another to also work within the same top-level bundle. Addressing something in a sibling or parent bundle is reasonably straightforward, with something similar to the following syntax: ``` ``` The downside is that if a user wants to take one site out of the big bundle and use it on its own, and they want links outside that site to land on the internet, they have to know the mapping from URLs to bundle names and undo it in all the links. If they don't do this, the links are broken instead. Similarly, if someone wants to compose a couple of pre-existing bundles, they have to rewrite links to point to sibling bundles appropriately. # Comparison We need to compare "single-origin bundles", described above, with "multi-origin bundles", described at https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#proposal-a-package-scheme . Both use a package:bundle-location$within-bundle format. Because the single-origin proposal chooses not to encode the whole origin to fit in the authority URL component, and implies rather than states the bundle's scheme, I'll compare it to a variant of the multi-origin proposal that does the same, yielding: ``` package://archive.example/2020-04-01.wbn$https://camera.example/edit.html ``` The difference becomes whether the origin computation includes an authority component in the last $-delimited segment. ## Single-origin bundles are better: * Implementers can use a simpler algorithm to compute the origin, ending at the last $ instead of having to also parse a URL from the last component. * Including just a single origin may avoid the need for signatures to specify a subset of the bundle, which could simplify that section. * Naming subresources with paths instead of URLs is more consistent with other archiving formats. ## Multi-origin bundles are better: * Users can expect simple tools to combine and split pre-existing bundles. * When authors are composing a bundle, cross-origin resources can go directly into the bundle, instead of needing to rewrite them to same-origin or put them in a nested bundle. * Implementations only need to spin up the bundle parser once, which could affect performance. * Implementers need to write and maintain tools to rewrite cross-origin URLs when saving a bundle from a website --00000000000055a05a05adcb9952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I worked with Martin to flesh out his ideas for simplifyin= g the bundle URL and origin design, and we came up with the following. I st= ill prefer the proposal I p= resented a couple weeks ago, based on the tradeoffs down at the bottom = here, but it's quite possible I've missed things. I'd appreciat= e this group's input on which way we should go.

The basic idea here is that:

* Each bundle defines a single origin.=
* Bundles identify their contents with paths, not full URLs.
* Metad= ata can provide a base URL to resolve those paths against.
* We allow a = single file to contain multiple origins using nested bundles. Use cases:=C2=A0 =C2=A0* Users should be able to share subsets of the web that can l= ink within themselves, in a way that different sites within those subsets d= on't have their storage collide.
=C2=A0 =C2=A0* One request for ads = should be able to return the contents of multiple iframes in a way that tho= se contents can't modify each other.


# URLs for nested bundl= e resources

```
package://distributor.example/bundle.wbn$app/foo.= wbn$bar.html
package:///c:/Users/name/Downloads/bundle.wbn$app/foo.wbn$b= ar.html
```

This fetches the outer bundle by removing everything = after the first `$` and:

* If the URL has an authority, replacing th= e `package:` with `https:`
* If the URL doesn't have an authority, r= eplacing the `package:` with `file:`.

To allow the outer bundle to b= e fetched using a third scheme, we would need to add a matching new scheme = for addressing inside it.

Subsequently, each segment separated by `$= `s is the path to look up in a nested bundle. Any `$`s inside a segment are= percent-encoded.


# Origins for nested bundle resources

T= he origin of one of these holds the information from the URL up to the last= `$`. So for

```
package://distributor.example/bundle.wbn$app/foo= .wbn$bar.html
```

* scheme: package:
* host: distributor.examp= le/bundle.wbn$app/foo.wbn
* port: null
* domain: null

We could= also hold the part after the first `/` in a new component, similar to Gecko's OriginAttributes, but OriginAttrib= utes are mostly undocumented, and origins define "opaque hosts" to encode this sort= of information into the existing field.


# Navigating across nes= ted bundles

Within something like El Paquete Semanal or the Web Arch= ive, it's straightforward to store each origin in separate nested bundl= es, but we want links from one origin to another to also work within the sa= me top-level bundle.

Addressing something in a sibling or parent bun= dle is reasonably straightforward, with something similar to the following = syntax:

```
<a href=3D"package:..$/https/other.site.examp= le.wbn$/path.html">
```

The downside is that if a user wa= nts to take one site out of the big bundle and use it on its own, and they = want links outside that site to land on the internet, they have to know the= mapping from URLs to bundle names and undo it in all the links. If they do= n't do this, the links are broken instead.

Similarly, if someone= wants to compose a couple of pre-existing bundles, they have to rewrite li= nks to point to sibling bundles appropriately.


# Comparison
<= br>We need to compare "single-origin bundles", described above, w= ith "multi-origin bundles", described at https://github.com/WICG/webpackage/blob/master/expl= ainers/bundle-urls-and-origins.md#proposal-a-package-scheme.

Bot= h use a package:bundle-location$within-bundle format.

Because the si= ngle-origin proposal chooses not to encode the whole origin to fit in the a= uthority URL component, and implies rather than states the bundle's sch= eme, I'll compare it to a variant of the multi-origin proposal that doe= s the same, yielding:

```
package://archive.example/2020-04-01.wb= n$https://camera.example/edit.= html
```

The difference becomes whether the origin computatio= n includes an authority component in the last $-delimited segment.

<= br>## Single-origin bundles are better:

* Implementers can use a sim= pler algorithm to compute the origin, ending at the last $ instead of havin= g to also parse a URL from the last component.

* Including just a si= ngle origin may avoid the need for signatures to specify a subset of the bu= ndle, which could simplify that section.

* Naming subresources with = paths instead of URLs is more consistent with other archiving formats.
<= br>
## Multi-origin bundles are better:

* Users can expect simple= tools to combine and split pre-existing bundles.

* When authors ar= e composing a bundle, cross-origin resources can go directly into the bundl= e, instead of needing to rewrite them to same-origin or put them in a neste= d bundle.

* Implementations only need to spin up the bundle parser = once, which could affect performance.

* Implementers need to write a= nd maintain tools to rewrite cross-origin URLs when saving a bundle from a = website
--00000000000055a05a05adcb9952-- From nobody Wed Aug 26 22:45: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 546EF3A0D5D for ; Wed, 26 Aug 2020 22:45:01 -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=OqxgaWz9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MJUgBJU6 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 NLhaCZdX53us for ; Wed, 26 Aug 2020 22:44:59 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426CF3A0D43 for ; Wed, 26 Aug 2020 22:44:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 71A025C025E for ; Thu, 27 Aug 2020 01:44:58 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Thu, 27 Aug 2020 01:44: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 :subject:content-type; s=fm3; bh=+4WsiyIHOaGuuBL4CGrhvOqZhxyqv9X e24ZHkNgBwJg=; b=OqxgaWz90QVrVLdIfPk+tk298XjdlAZ6ob0i8a2626f4jqP ss5nBijQ/OM52fWDg+RG+OT/bQW0tQB7Ddv/tSW/65yoYEsLR2TADGL0Th+r0JUB bucEf5F6KzrRzFPgi1NmmRwGULF6pEpK/SZZEddCminKwvk5ZWZOUii+bUfWNZhb NP5U8N25gMkO/YB3GnLddlyDZprmb7WoDaz9FMDOYIoOyJ0rK/P0XhW1Oq8biy8n xmT5acl26Ygv7cz1ijm8rp05pIVirQhz/HTlQthtfZt/oogMFBNL1IFb37QlGEg7 7dybFuy+IP99jFwDB1N1zpwCbYV+t0HxgY0T5lA== 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=fm3; bh=+4Wsiy IHOaGuuBL4CGrhvOqZhxyqv9Xe24ZHkNgBwJg=; b=MJUgBJU6KX9SJlcyp+yjZd 9zmlt6jeX3azhNr9I1a1BmnEiZVqoiiD7uMWjPW1Wrj8j12gta0TMGS4Qf56GjnK zMOjZ2AM5PwzGVLNKOv/PUxk1uPMY183rooq1Uyx/D757vm7BS0kG/M9CdmGyTx4 UAItby/TbehRJ7wRtANYqwrRc53uQ/3LWcXCVCLn8t0k0zYaEKpGb67tZmfL+xmT Nirde0hOB2gmV5sLAugPgN/fmB6LuiXeLFPvRuATCkGKsSqRYWcuwOg/VbqZH5p7 rHj7yajZOBagKHKrFDrfGP1AY14clZvqaCcPATZPGuL+sddC0gRbpjV5e2zCx/hw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeuieekvdetfeeludfhtd ffuedvueefjefgveeivdeviefhteekgfdvfeefieeihfenucffohhmrghinhepvgigrghm phhlvgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A52B200BD; Thu, 27 Aug 2020 01:44:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <614809c3-02d7-4e8e-a63d-1f2bd6307789@www.fastmail.com> In-Reply-To: References: Date: Thu, 27 Aug 2020 15:44:36 +1000 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] =?utf-8?q?Counter-proposal_where_bundles_only_contain_a_?= =?utf-8?q?single_origin?= 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, 27 Aug 2020 05:45:02 -0000 On Thu, Aug 27, 2020, at 04:00, Jeffrey Yasskin wrote: > # Origins for nested bundle resources > > The origin of one of these holds the information from the URL up to the > last `$`. This is one option. I tend to think that adding to the tuple is also reasonable (it doesn't have to be origin attributes). Suborigins proposed a new origin tuple item, for instance. > The difference becomes whether the origin computation includes an > authority component in the last $-delimited segment. This is the bit that I want to draw on a little harder. If the URI for a resource is its identity, and we are basing the fact that x$https://example.com/foo comes from example.com purely on an unsubstantiated assertion, why would we consider example.com to be a necessary part of the identity of the resource? Or the identity of the origin for that matter? > ## Multi-origin bundles are better: > > * Users can expect simple tools to combine and split pre-existing bundles. I think that this is not correct, or at least founded on a poor assumption. I believe that your assumption is that a resource can refer to content by an https:// URL (or otherwise "canonical" URL) without identifying the bundle in which it appears. It's a good assumption when content is properly attributed to an https:// (or otherwise "canonical") source through something like a signature. But also completely unnecessary in that case (we no longer need the new scheme). In that case saying "http://example.com/resource" is enough. It perfectly matches with the treatment of the referenced content. But I don't believe that you can safely identify content without also identifying the bundle in which it appears unless you have that guarantee. The narrow cases in which this is interesting is when you have resources from multiple origins with multiple cross references. If your CSS is in a different origin and it references content from yet another origin, then those links need to be adjusted based on the bundle structure. (Which was your next point; but see below.) > * When authors are composing a bundle, cross-origin resources can go > directly into the bundle, instead of needing to rewrite them to > same-origin or put them in a nested bundle. There is another option, which is to adopt resources. Many subresources are effectively adopted anyway (JS, CSS, CORS images). Bundling removes confidentiality advantages conferred to others (non-CORS images). A simple bundler gains nothing by retaining isolation for either; only a bundler that intends to have the content re-attributed to the "online" origin gains anything by isolating the latter. The main reasons I can think of to maintain any isolation are: reuse (a large bundle like El Paquete Semanal might want to avoid resource duplication), or sandboxing (for re-attribution to online origins, or isoation of mutually distrustful content like iframes). Both of which are things I might argue are sufficiently advanced as to justify the non-trivial extra effort. There are other options of course. If you find that link writing is awkward, then a different authority form for the package: scheme might help. Let's say we choose a non-reg-name form, maybe something that starts with a $ and reserve that. Then we can name packages and reference content in them. Then you might name a shared package of images as eps-images and refer to an image in it using . This is as meaningful as the pseudo-origin that appears after the $ in your examples, it just doesn't pretend to be something it isn't. You could use the same methods for avoiding collisions (i.e., a domain name), but you can also use short mnemonics or UUIDs. The phishing potential of this simple design leads me to wonder if it is the best strategy, but maybe we can just ensure that that string never appears in security-sensitive UX. > * Implementations only need to spin up the bundle parser once, which > could affect performance. Gee, I hope it doesn't cost that much. A better baseline comparison is not zero overhead, but a new TLS connection. And if we can't beat that, we'd have to try not to. > * Implementers need to write and maintain tools to rewrite cross-origin > URLs when saving a bundle from a website See above. It might be enough to avoid that at a granular level.