Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFP: Web Packaging Format #29

Closed
marcoscaceres opened this Issue Sep 27, 2017 · 27 comments

Comments

Projects
None yet
@marcoscaceres
Copy link
Collaborator

marcoscaceres commented Sep 27, 2017

Request for Mozilla Position on an Emerging Web Specification

Other information

It will allow people to bundle together the resources that make up a website, so they can be shared offline, either with or without a proof that they came from the original website.

Repo: https://github.com/WICG/webpackage

@hsivonen

This comment has been minimized.

Copy link
Member

hsivonen commented Oct 5, 2017

Concerns (non-exhaustive):

  • There are three use cases:
    • Non-HTTP distribution of Web content in places with bad/expensive connectivity in a way that verifiably ties to Web origin.
      • This use case isn't of world-wide interest (if you have tolerably fast and affordable networking, you are not going to bother with SD card or P2P transfer of Web apps even if you want to install them for offline use) and depends on comprehensible UI. While it would be good of vendors to address concerns that don't have world-wide appeal, such features have a difficult time getting significant UI real estate. Does this use case have UI buy-in at Google (the spec writer's affiliation) to make this use case realistic on the UI side?
    • Snapshot sharing without need to authenticate.
      • The spec itself mentions prior art here but dismisses it as non-interoperable. There's an xkcd for that. I'd like to see a much better explanation why interop for this use case would be achieved this time.
    • CDN verifiably speaking for a different origin.
      • Considering how far SRI goes on the topic of CDN verifiability and in a backward-compatible way (albeit without the ability to override origin for resources that don't operate with the authority of the origin referring to them), I have doubts that sites would choose to use this backward-incompatible feature. That is, it's not at all clear that the value provided by this feature would outweigh the risk of breakage with non-evergreen browsers that don't have this feature or the complexity of implementing things two ways to accommodate browsers that have this features and browsers that don't.
      • It isn't explained why packaging (as opposed to additional HTTP-level metadata) is the right solution for this.
  • The spec is layered on top of CBOR, whose error handling story is antithetical to what the Web needs. (CBOR says anything goes but experience shows that well-defined error handling is the way to go on the Web.) The spec tries to impose some error handling requirements on CBOR, which means that you have to use a special-purpose CBOR processor limiting the benefit of layering on top of an existing spec.
@overholt

This comment has been minimized.

Copy link

overholt commented Jan 25, 2018

FWIW, today I was asked about this by Yoav and a few Googlers.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

marcoscaceres commented Jan 30, 2018

Just noting the use of web packaging and AMP (blog post). We should evaluate what this means exactly and how web packaging addresses concerns around AMP.

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Jan 30, 2018

This isn't a complete answer to @hsivonen's concerns, but I figured I'd point you to the up-to-date proposals before you re-review anything:

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html is additional HTTP-level metadata to receive exchanges without talking to the origin server. It's the piece that we think is most immediately useful for AMP. It proposes a way for browsers to opt into CDNs pushing cross-CDN content, although @yoavweiss suggested a second way that I haven't analyzed or written up yet.

WICG/webpackage#98 is the start of the MHTML replacement, and the PR lists a couple ways that it improves on MHTML.

https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-00 has a more complete list of use cases, and was published in August.

@adamroach

This comment has been minimized.

Copy link
Collaborator

adamroach commented Jan 30, 2018

See also @ekr's comment at #53 (comment)

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

marcoscaceres commented Jan 30, 2018

Can someone kindly provide a link to the feedback @ekr referenced in #53?

@stpeter

This comment has been minimized.

@ekr

This comment has been minimized.

Copy link
Contributor

ekr commented Jan 30, 2018

I'm finding myself a bit confused about which standards body this document seems to think it's targeted at. The link above is to a WICG repo but it's clearly an IETF draft.

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Jan 30, 2018

There are several pieces: signed exchanges are aimed at the IETF; bundles are either aimed at the IETF or the WICG depending on conversations at IETF101; and the specification about how browsers load both of those, expose them to service workers, etc., will definitely go through the WICG. The whole thing is in a WICG repository because at the beginning it wasn't clear that I should bring signed exchanges through the IETF.

@martinthomson

This comment has been minimized.

Copy link
Member

martinthomson commented Jan 31, 2018

On the question of venue, it is pretty clear to me that addressing the architectural questions this work raises is something that both the IETF and W3C might have input on. I would not be happy unless both bodies agree that this is worthwhile.

I'm happy that this is going to the IETF. The question of what this does to HTTP is one that they need to address. That's necessary, but not sufficient. Even if the IETF agreed that this is a reasonable solution, the W3C might have grounds to object. We know that the TAG has already made a statement about one of the use cases that this enables; I expect them to have more to say.

Personally, I think that this is potentially very harmful, and it's not clear what would be required to address that concern. The way that this is set up suggests a range of use cases, but if just one of those has the potential to do significant damage to the ecosystem, we need to address that harm.

We should mark this harmful until we can be convinced otherwise.

@dbaron

This comment has been minimized.

Copy link
Member

dbaron commented Feb 1, 2018

I found the last paragraph of @ekr's post quite convincing in terms of showing that this is problematic since it changes what our security indicators mean in fundamental ways.

On the flip side, I think it's pretty important for a bunch of things:

  • packaging is important for the effort to merge IDPF work into W3C and have an ePub successor that's based on Web Technology, although it's possible that effort is stumbling in other areas
  • relieving some of the problems with AMP (as documented in the TAG finding on distributed and syndicated content and in the letter about Google AMP) in the ways described in the recent blog post
  • solving various longstanding use cases related to archiving of web content and sharing of those archives

It's not clear to me what the path forward is; does any approach to packaging necessarily have this problem, or are there ways to avoid them? Does avoiding them require a new state for our security UI?

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Feb 1, 2018

If you don't couple packaging with distributing content from a different authority it seems you could have packaging sans signing as a new kind of delivery mechanism; that might be enough for 1 and 3 of your list, but not 2 I suspect.

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Feb 1, 2018

@annevk Yes, and that's the bundling spec that's separated out from the signed exchange spec.

@ekr

This comment has been minimized.

Copy link
Contributor

ekr commented Feb 1, 2018

My problem here is primarily with origin substitution. I'm actually fine with signing and offline I suggested a beefed up version of SRI-caching to @jyasskin as an alternative to this. I think the primary question at hand is whether there is a standalone mechanism where the client gets content displayed as origin X without any direct contact at all with X.

@stpeter

This comment has been minimized.

Copy link

stpeter commented Feb 2, 2018

To @ekr's point the introduction to draft-yasskin-http-origin-signed-responses-02 clearly states that "When signed by a certificate ([RFC5280]) that’s trusted for an origin, an exchange can be treated as authoritative for that origin, even if it was transferred over a connection that isn’t authoritative (Section 9.1 of [RFC7230]) for that origin." Using signed HTTP exchanges to enhance the security of accessing a resource or verifying its authenticity seems like a good thing; but it seems positively harmful to use signed HTTP exchanges as a replacement for the longstanding web security model (e.g., RFC 6454 as Ted Hardie points out at https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0079.html). I suggest that we let the discussion on the HTTP WG list play out further, and see how @jyasskin modifies his I-D in response to ongoing feedback.

@adamroach

This comment has been minimized.

Copy link
Collaborator

adamroach commented Feb 15, 2018

Based on the conversation so far, I plan to enter a "harmful" with a summary of the concerns expressed above in the "position detail" field, along with an explanation that Mozilla would likely support a webpackaging proposal if such concerns could be addressed.

Please respond by the end of this week if you object to this course of action.

@dbaron

This comment has been minimized.

Copy link
Member

dbaron commented Mar 5, 2018

So #53 has been merged. Are there other parts of Web Packaging that we should document positions on, or should this be closed (at least for now)?

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Mar 5, 2018

You could document a position on bundles, but it's probably premature until that's at least published as an IETF or WICG draft.

I expect to come back with answers to the concerns above, based on either https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-03 (published today) or the discussion at IETF101 in 2 weeks, but I'm happy to reopen the issue when I've written that appeal.

@adamroach

This comment has been minimized.

Copy link
Collaborator

adamroach commented Dec 13, 2018

Given that we've surfaced the position for what can be surfaced, I'm closing this issue.

@adamroach adamroach closed this Dec 13, 2018

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Dec 13, 2018

@adamroach it seems we only list Signed HTTP Exchanges. Should we list Web Packaging separately?

@adamroach

This comment has been minimized.

Copy link
Collaborator

adamroach commented Dec 13, 2018

@annevk -- It sounded like the proponents of that work weren't quite ready to make their case. If you think it's ready for evaluation, open an issue, pointing to the relevant document.

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Dec 13, 2018

If you add one, it should probably be "Bundles". Web Packaging groups the two ideas. I probably will put both into the same Fetch integration spec, hopefully in the next couple months.

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Dec 14, 2018

I see, I was missing the context provided by #53. I guess I'll leave it up to @jyasskin to determine priority. Thanks!

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Jan 31, 2019

We, Chrome team, would like to re-open Mozilla's standards position on Signed Exchanges given the updates to the specifications (https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05 and https://wicg.github.io/webpackage/loading.html) that have happened since the position was established.

Mozilla's current documented objections are:

  1. "The ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome."
  2. "As is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text)."

We are struggling with objection (1) because it doesn't describe any concrete harm caused by the change, especially since the authoritative server's content has plenty of opportunity to contact its server after the content loads. We haven’t heard more details on the thread where that concern was originally expressed.

We believe that Objection (2) isn’t a significant change from the status quo when considering more of the stack than just TLS, as described in https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0089.html and https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#privacy-considerations.

EKR also suggested an SRI-based solution, which I tried to write up in https://jyasskin.github.io/sideloaded-exchanges/draft-yasskin-httpbis-sideloaded-exchanges.html. We haven’t heard any feedback on that draft yet.

It’s unclear if our attempts at understanding or resolving the concerns are missing the point or are otherwise inappropriate, or if this is an issue of finding the time or a good person to review.

We acknowledge three important reductions in security relative to TLS, which we've tried to mitigate, and for which we’d love your help, both for evaluating the mitigations and improving them.

  1. It's possible to replay a personalized response from an attacker to a victim, as now described in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#seccons-over-signing. That section gives signing systems some advice to try to prevent those problems, and clients block "stateful" headers to prevent cookie-based attacks.
  2. An attacker can send a signed exchange that includes a recently-fixed mistake. This could be either an exploitable bug, which the attacker then exploits, or incorrect information for the victim to read. WICG/webpackage#376 discusses a way to mitigate the second, and if picking a particular choice improves Mozilla's opinion on the spec as a whole, that's likely to sway the decision.
  3. Mis-issued certificates and stolen private keys are easier for an attacker to use and harder for a victim site to notice, similar to the issues described in draft-bishop-httpbis-origin-fed-up. WICG/webpackage#377 improves the situation for mis-issued certificates, but not all the way back to TLS. I'm looking for a way to improve detection of stolen keys that retains the surveillance-resistance offered by the current design. For browsers that don't care about surveillance, WICG/webpackage#376 could solve this.

We are looking forward to your response.

@martinthomson

This comment has been minimized.

Copy link
Member

martinthomson commented Feb 1, 2019

Hi @jyasskin, just acknowledging your request here. I'm working on getting you an answer. Understand that this is not a very high priority for us, and there is a lot of complexity. It might take us a while to get back to you.

@othermaciej

This comment has been minimized.

Copy link

othermaciej commented Apr 18, 2019

Has @hsivonen's objection been addressed? Specifically the one about layering on top of CBOR, which has undefined anything-goes error handling. Even though I suspect it's not anyone's primary objection, this seems like a serious future interop hazard that could be fixed (if it hasn't been already).

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Apr 18, 2019

@othermaciej I've approached @hsivonen's objection by sending patches to the next version of CBOR, which you can find at https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html. We're much closer to "good" error handling there, in that the web packaging specs can say "if the CBOR is not valid, return a network error", and have that mean the right thing, but I wouldn't yet bet that we're all the way there. CDDL also has some issues along these lines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.