#509: Navigation to Unsigned Web Bundles (Web Packaging)

Visit on Github.

Opened Apr 24, 2020

Hello TAG!

I'm requesting a TAG review of Navigation to Unsigned Web Bundles (Web Packaging).

We propose to use the Web Bundle format, without origin-trusted signatures, to give users a format they can create from any website they're visiting, share it using existing peer-to-peer sharing apps, and then have a peer load it in their browser.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): IETF WPACK WG for the format and unknown for the browser side
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/mozilla/standards-positions/issues/264
  • Major unresolved issues with or opposition to this design: It's complex, and it's not clear how to define or render the URLs for non-authoritative subresources.
  • This work is being funded by:

You should also know that...

  • The format spec mentions “signature” section and relation to Signed Exchanges (SXG), while we'd like to scope this TAG review to unsigned WBNs (unique-origin WBN navigation and same-origin WBN navigation). For signed bundle navigation it can act like SXG, and likely don’t need extra review beyond previous SXG discussion and this review.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Apr 1, 2020 (See Github)

Kenneth, Tess, and David volunteer, milestone set for 2 weeks

Discussed May 1, 2020 (See Github)

Tess: [venue] - going to IETF ... have they talked to the IAB?

David: they are proposing a split standardization thing...

Dan: f2f? special guest?

Tess: a good thing to use f2f time... I'm less worried about it then bundling signed exchanges...

Rossen: we should see what parts belong to "us" and see what feedack we can provide...

Dan: should we get a guest joining? I will invite people...

Comment by @hober May 26, 2020 (See Github)

Hi,

@kenchris and I looked at this in a TAG breakout today. This is a really complex feature, so we will need to keep digging, but we wanted to share our initial thoughts with you now.

https://github.com/WICG/webpackage/pull/560 is interesting. With AMP you see these fake address bars in content, which attempt to trick users into believing the URL to the AMP document is actually something else. Sometimes they even auto-scroll the page so that the browsers's address bar gets hidden. It's pretty gross. So it makes a lot of sense that you really want to avoid that same problem here with web packages. But it seems to us that you can't escape it: directly displaying the package URL is meaningless to users, displaying the publisher hostname in the address bar is deceptive the same way the fake AMP address bars are (it puts the deception directly into the browser's trusted UI), and displaying the distributor hostname in the address bar encourages content to do the same icky stuff AMP content does today. This is maybe just the inherent complexity of having publisher != distributor.

Comment by @kenchris May 26, 2020 (See Github)

What are the non-AMP like use-cases for publisher != distributor? Is that mostly for people to manually pass around PWAs like copy from one phone to the other? Wouldn't that need to be signed as well?

Comment by @jyasskin May 27, 2020 (See Github)

@kenchris Three use cases for publisher!=distributor are:

  1. A user has saved a site and wants to share it with their friend while they're offline. For example, https://storage.googleapis.com/web-dev-assets/web-bundles/proxx.wbn, which doesn't need signing because it doesn't need to execute or be trusted as its online origin. That user is acting as a distributor.
  2. A user has bought a book from its publisher and backs it up. When they restore the backup, it's no longer coming from its publisher.
  3. https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf suggests https://web.archive.org/web/20200514010317/https://tag.w3.org/ could serve a bundle.
Comment by @jyasskin May 27, 2020 (See Github)

I'm happy to realize that https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-unsigned-bundles.md#goals lists nearly the same use cases. I finally got an explainer right!

Discussed Jun 1, 2020 (See Github)

Tess: Neither David nor I have looked at this since the f2f, hence no progress.

Peter: We can push this to next week.

Discussed Jul 1, 2020 (See Github)

[bumped to next week, David to take a look at it

Discussed Aug 1, 2020 (See Github)

Tess: Ken and I looked at this at a breakout - and I raised some concerns that they haven't addressed. Things have changed a bit since then. Concern I raised: bundles are attempting to address some of the downsides of AMP - one of those being the default rendinering of AMP is to have a fake address bar. We don't like that. Could be described as deceptive. The question is how do you display the package URL for an unsigned bundle in the browser. If the publisher and package URL are different you could display the package URL directly (opaque), the publisher's origin (promoting the deceptive practice) or the distributor URL (encourages existing package - the fake URL bar). Doesn't look like they replied to that. Also it looks like some things have changed - one issue got closed.

... this is the document that replaces that open issue: https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md

... I will review.

Rossen: So any time you have publisher / distributor difference - you're creating an easy to exploit vector for phishing. That's terrible.

Tess: the key is this is for unsigned.

Dan: what are the use cases?

Tess: suppose you're a professor and you're putting together a bundle of article - you have no authority to make a signed exchange for any of these things...

Dan: what about use of some mechanism e.g. a University server or a letsencrypt / equiv ..

Tess: the publisher signes it - not the distributor.

Tess: you load a web page adn want to share it with your friend over p2p - like bluetooth.

Dan: once again in that case there should be a warning on the receiver's device...

Tess: yes - maybe we should ask the people invlolved about this kind of UI...

Rossen: how does the UA detect this ?

Tess: either for all unsigned bundles - or all bundles of unsigned exchanges where the distbutor origin is not the publisher origin.

Dan: isn't this putting the cart before the horse?

Tess: so far in the web we only use UI like that for insecure things... Might be a hard sell that this should get such a warning.

Rossen: unless the proof is there that this concern is not a concern. At this point I am way more leaning towards requiring - pushing back on that basis - from the PoV... \

Dan: [leaves a comment]

Peter: could we eliminate the idea of unsigned bundles by making it a requirement to sign the bundle - even if it's self-signed? If we just always require that every bundle is signed by whoever made it - might shift the problem.

... also - if I download something over TLS can I store something from the TLS session such that I include the cert fromt he original site such that a 3rd party could verify that this came from the original site - and thereby preserve the provenance of the original data. Maybe a future extension to TLS? Surfacing more of the handshaking to the parts of the browser that would generate a bundle.

Tess: it's weird that this is separate from TLS and existing mechanisms...

[bumped]

Discussed Aug 1, 2020 (See Github)

Discussion of jyasskin's reply, Rossen and Tess posting followups.

Comment by @torgo Aug 3, 2020 (See Github)

Quick question that came out of our discussion today: in other cases where potentially unsafe content might be displayed (e.g. an out of date cert, or a potential phishing site) the browser displays some kind of warning that the user must click through to access the content. Is that kind of UI requirement being considered here? It seems like the potential for use as a phishing vector is very high with this.

Comment by @jyasskin Aug 4, 2020 (See Github)

I think the warnings we'd display on an unsigned bundle would depend on the kind of attack we're worried about. I haven't talked to our security teams yet about this in particular, but I'd guess that the risk you're worried about here is that a bundle at https://attacker.example/attack.wbn contains a resource that claims to be from https://accounts.google.com/ and looks like the Google login screen. I think that's mitigated in the proposed system by:

  1. De-emphasizing the claimed URL in the same way we de-emphasize the path or fragment in other URLs: https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#rendering-the-url-bar
  2. Teaching SafeBrowsing and similar systems to scan inside bundles in the same way they scan normal HTML files. If they notice hostile content, show the same interstitial they'd show for non-bundled hostile HTML pages.

Is there a particular attack you think bundles make easier, which the above mitigations don't help enough with?

Comment by @atanassov Aug 17, 2020 (See Github)

Thank you @jyasskin, the scenario you described is the exact issue we are concerned about. The main problem being that users will be exposed to pretend URLs and exploited for indefinite amount of time while phishing scanners catch up. The mitigation you explained seems quite weak.

Comment by @hober Aug 17, 2020 (See Github)

I wrote:

With AMP you see these fake address bars in content, which attempt to trick users into believing the URL to the AMP document is actually something else[…] it makes a lot of sense that you really want to avoid that same problem here with web packages.

@jyasskin replied:

  1. De-emphasizing the claimed URL in the same way we de-emphasize the path or fragment in other URLs: https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#rendering-the-url-bar

This doesn't seem to address this concern:

Displaying the distributor hostname in the address bar encourages content to do the same icky stuff AMP content does today.

Do you expect web packages won't include AMP-style faux address bars? If so, why?

Discussed Oct 1, 2020 (See Github)

Rossen: We had few rounds of review for this proposal. The main feedback to the authors was that if they were to separate cross vs same origin unsigned bundles the progress will be faster. Furhter, none of the concerns we raised as of Aug 17 were addressed. ... Propose marking as Waiting for Author Feedback and moving on.

All: Agreed.

Discussed Jan 1, 2021 (See Github)

Ken: After talking to Daniel Ehrenberg it appears so that there is a new bundles proposal called "Resource Bundles". From the conversation it seems this will be a superset of the signed/unsigned bundles and will most likely obsolete this proposal. ... Let's add a comment to this in the issue and move on to the next one.

Comment by @kenchris Jan 26, 2021 (See Github)

I heard that there is a new take on bundles (resource bundles in contract to bundles that can package up whole apps):

https://github.com/littledan/resource-bundles

How does that relate to this? @littledan

Discussed May 1, 2021 (See Github)

Rossen: This is pending external feedback, since October 2020. Let's mark it as stalled.

Tess: WFM

Discussed Sep 1, 2021 (See Github)

Stalled - waiting for feedback

Comment by @irori Oct 12, 2021 (See Github)

Let me close this for now, as currently we are prioritizing Subresource loading with Web Bundles use case.