Web Packaging at TPAC 2020

https://www.w3.org/2020/10/TPAC/breakout-schedule.html#web-packaging

Attendees

• Jeffrey Yasskin (Google Chrome)
• Daniel Ehrenberg (Igalia)
• Daniel Appelquist (Samsung / TAG)
• Yoav Weiss (Google Chrome)
• Xueyuan Jia (W3C)
• Ada Rose Cannon
• Alexandra Lacourba
• Alex Christensen
• Ben Kelly
• Dan York (Internet Society)
• Emilio
• Tess O’Connor (Apple)
• Jason B
• Martin Alvarez (Huawei)
• Masakazu Kitahara
• Michal Mocny
• Przemyslaw Iwanczak
• Ralph Swick (W3C)
• Reilly Grant (Google)
• Shivani Sharma (Google Chrome)
• Toshiaki Koike
• Tzviya Siegman
• Xiaoqian Wu
• Yongjing Zhang
• Zhenjie Li
• Zhoudan (Baidu)
• Zitao Wang
• Zoltan Kis
• Thomas Steiner (Google)

Notes

Restricting bundles to the same-origin context

• Dan E: A lot of the use-cases covered by the origin web packaging proposals seem distinct from the ability to bundle multiple resources together
  • I'm more interested in those aspects than the cross-origin cases, e.g., for finding a replacement to webpack/rollup
  • This can reduce the complexity with Web Packaging
  • E.g. the dollar sign (??) package URLs can be removed
  • So interested in people’s thoughts
• Dan A: My suggestion came out of the TAG review for unsigned web bundles. There were a number of issues that came out of the discussion. I would definitely support this. A lot of them boil down to the possibility of user confusion. They have more do with the user experience/trust aspect of how a user interacts with something, that comes to them through a bundle. It sounds right to me, better, to first address the same-origin case. https://github.com/w3ctag/design-reviews/issues/509
• Jeffrey: I think starting with the same-origin use case, building that into the browsers first, and then evaluating later if we want to extend it, makes a bunch of sense, especially if the non-Chromium browsers are more likely to adopt that quickly, let's go there. The use cases that that leaves out are the sharing-webapps case that Ada brought up, since you need signatures of some sort to share apps in a trustworthy way. If we're doing same-origin, then downloading these locally and running them doesn't work either. There's one other niche use case where some folks on the Google Ads team would like to deliver several mutually distrusting ads on one request--and for that, you need suborigins, boundaries within the bundle. And that may be possible to do within this or later. Could folks speak up if you have concerns about only doing same-origin first?
• Yoav: I don't know if we should talk about doing one before the other--from my perspective, they have very distinct use cases. I'd like to hear about concerns that people have with these as separate proposals. Eliminating the cross-origin capabilities eliminates a lot of what people are concerned with, including what Dan opened with. If we are saying we want cross-origin Web Bundles to rely on things, we need to define the same-origin bundles first. I think it's mostly interesting to rule out confusion between the two models, the signing part and the bundling part.
• Dan E: Also wants to rule out the non-authoritative case (from cross-origin but not signed). It runs the risk of leading to user confusion, and not sure things should be served from the web in that way.
  • Find myself convinced more by the offline and distribution cases than by the privacy preserving prefetch case
• Shivani: Agree that there are different use-cases for both signed and unsigned, so want to bring up the Fenced Frame and Ad ???? use cases, we’re proposing not to go to the network for the ad fetch, and that the ad was already fetched
  • Use case for cross-origin bundles
• Dan E: Is that a suborigin use case
• Shivani: Download of a single ad can let the embedding page know which interest group the user belongs to
• Jeffrey: Is this the case where the browser downloads the ad from the advertizer ahead of time? If so, this fits the case that Dan wants to restrict
• Shivani: that’s good to know
• Jeffrey: Sounds like there are several groups that want this, some Chrome folks concerned that this won’t support all the use cases, but seems like a promising direction

Subresources with "incorrect" URLs

See: #422, #544, #551

• Jeffrey: if you have a bundle you can describe a URL in the bundle which is different from the resource you’d get when fetching the URL directly. The browser can fetch the resource directly and notice that it got a different one, but
  • That would slow things down
  • A different resource could be the result of changes to the resource
  • … concerns that this would result in malicious folks obfuscating URLs. When launching anything related to bundles, we need the content blockers to know which URLs were fetched from the bundle
  • Yoav has a proposal to integrate bundles with the browser cache. If the bundle affects the browser cache, then it will interfere with other pages if you're not putting compatible resources in there. So I wanted to make space to talk about this--to see if we have dealt with it adequately, and to see if there are more things that I've missed.
• Dan E: Spent time looking into this topic, I think that subsetting that Yoav has proposed would provide the right incentives for people to give the correct URLs for subresources. Pretty convinced on that so not concerns about this issue
  • We could write the spec in a way that permits the browser to verify the resources
• Jeffrey: fine to allow the fetches but not convinced they help
• Dan E: Yeah, so not concerned about this issue and interested to hear if someone else is
• Alex Christiensen: One of our concerns with this issue was people distribute packages that claim to be universal but actually contain unique IDs and a way to catch this would allow us to catch this tracking content.
• People can distribute package data that claims to be universal, the ability to verify that prevents a new tracking vector.
• Dan E: How is that different from any resource fetch adding tracking data
• Alex: People can already put unique IDs in any resource they want, but no way for one client to send resources to another client, which web packaging adds. That would give the capability to do that.
• Dan E: This related to same origin restrictions. If web bundles are only loaded from same-origin, and disable that sharing case that would prevent that.
• Alex Christiensen: I'm not sure how related they are, but if an origin has only first-party content in two packages that are distinct but claim to be the same, then I don't see how preventing non-same-origin would prevent that
• Reilly: Have any implementations considered implementing some kind of certificate transparency-type monitoring of the uniqueness of bundles/subresources? If the theory is that the same bundle delivered to multiple clients will have the same contents, it seems like implementations could verify this in the background or serverside, so browsers could snitch on sites that are (on a percentage basis) delivering mismatching things? Although it wouldn't allow blocking in real time, it would allow to know of it.
• Jeffrey: Posted a couple of issues that talk about the re-distribution case:
  • https://github.com/WICG/webpackage/issues/422 and (Pete's concern) https://github.com/WICG/webpackage/issues/544
  • It is really just an issue for the signed/cross-origin case. For verification, it's more complicated than it sounds, but we need to look into it.
• Tess: I'm confused by what you just said, about redistribution only being an issue for the cross-origin case. Are you saying that the UI will limit distributing same-origin bundles?
• Jeffrey: When you distribute it, the contents will be of the origin of something else. If you hand it to a friend, the source device is the origin. So, restricting it to the same-origin case blocks redistribution.
• Tess: So it has to be self-contained, cannot load resources from the web
• Jeffrey: Even with that restriction, it's still cross-origin. Dan E's suggestion is to have the browser only load packages whose subresources are named with URLs that are same-origin with where the package was loaded from. It's possible to imagine additionally allowing the browser to load P2P-shared packages with subresources named in a single origin, and then preventing those from accessing the web, but it'd be a separate feature.[a][b]
• Dan E: The same origin restriction doesn’t restrict the URLs the bundle can fetch. It’d just mean that the bundle doesn’t contain resources from other origins.
• Jeffrey: Saw on chat that Pete’s concern wasn’t addressed. Do you still feel that way?
• Tess: I do still feel that way.
• Jeffrey: I will follow up with you later.

The ability to send packaged apps client-to-client over WebRTC

• Ada: This is a fascination of mine, the potential of having a serverless web. If you can have a Web Package which can host websites, then you could bootstrap a web without servers, which has interesting implications for privacy, government tracking, government blocking (anti-censorship)[c], etc, if it's feasible, desirable, etc.
• Reilly: My interest has to do with the ability to archive apps and use them later (so I'm interested in the expiry question). It's very exciting to be able to distribute apps peer-to-peer, but this requires some kind of signature in order to make it practical. If a WebRTC app sends content to a peer, if that content can't be validated, then it can't be used so much.
• Ada: If the initial site is created and signed by an author, can the packages still be distributed but have the content re-authenticate with the authors?
• Jeffrey: Yes, all of the implementation work has been about signatures from online servers. I tried to design the format so that it supports any sort of signature you want. The problem is always key distribution: how do you give people your key, how do they know who you are to have signed it. If you can find a solution to those problems, packages can let you do that. The 7-day expiration only needs to apply to HBS (?) signatures.
• Jeffrey: There is work on P2P distributed web in the W3C. They’ve been watching that work, but weren’t involved. Would be good to get them more involved
• Tzviya: A lot of what Ada talked about is what we have with the ebook distribution model and why web bundles can be interesting for ebooks.
• Jeffrey: Talked to Dave Cramer, and decided that books should be signed by the publisher, not the distributor origin.
• Ada: If you didn’t mind having 1 week expiry on all your content, would it be viable to distribute the original pages via P2P? People could still access them through that location. Or even, have an ephemeral server to server them and shut down
• Jeffrey: That’s the origin use-case we set out to resolve (e.g. example from Cuba), and web packages can do that in an authenticated way. But it gets complicated when you want to enable the browser to trust those origins. But that’s the end goal.
• Jeffrey: thanks everyone!