Adding web packaging #53
Conversation
|
I've looked at this and I think there are major architectural concerns (see my recent message to HTTP). I haven't seen any compelling use cases that require this kind of major architectural change. Accordingly. I think we should mark this either "harmful" or "defer" |
|
Please don't call this "webpack". That's https://webpack.js.org/. There's a collection of specifications that were called "web packaging", but they've been split up into at least "signed exchanges" at https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-02 and "bundles" or maybe "WebZip" which are draftily drafted at WICG/webpackage#98. It probably makes sense to add only "signed exchanges" right now, of course with whichever position @ekr and the rest of Mozilla negotiate. |
|
We should keep the discussion about what our position is in #29. That's the thing that will be referenced from the main table. That said, I think it's worth answering @jyasskin's question about whether the item we're listing is the right one. @adamroach - should we still go ahead with the pull request as-is, or does that make you want to list things differently? (Also, maybe change the title of the PR if you can?) |
I'm not entirely certain what else I would point at in this regard. Are you proposing that we point to draft-yasskin-http-origin-signed-responses instead? |
|
draft-yasskin-http-origin-signed-responses is my suggestion. |
|
@adamroach did you want to update this? |
|
@adamroach ok, just (1 minute ago) landed that |
|
I'm assuming we're doing the standard approach of not merging our own patches to the repository. If that's not aligned with everyone else's expectations, let me know. |
activities.json
Outdated
| "description": "This document specifies how a server can send an HTTP request/ response pair, known as an exchange, with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks.", | ||
| "mozBugUrl": null, | ||
| "mozPosition": "harmful", | ||
| "mozPositionDetail": "Mozilla has concerns about the shift in the web security model required for handling web-packaged infformation. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the webpackage has access to plaintext). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed.", |
|
In some cases I'll admit I've merged my own PRs after getting review from others. But today I merged yours promptly, at least. |
|
Thanks! |
… name. I went with the singular simply because it required fewer changes (and also doesn't invalidate any outstanding PRs). This causes the detail added in mozilla#53 to actually show up.
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to mozilla#58, mozilla#27, mozilla#24, and mozilla#19. It also happens to include the first links to caniuse (the "ciuName" field being non-null). Note that activities.py normalized some whitespace in a prior entry added in mozilla#53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to #58, #27, #24, and #19. It also happens to include the first links to caniuse (the "ciuName" field being non-null), and first links to bugzilla. Note that activities.py normalized some whitespace in a prior entry added in #53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
I suspect editors like to strip out this trailing whitespace (e.g., from mozilla#53) which activities.py then readds when manipulating the JSON (in mozilla#66). We'll avoid the churn (and annoyance) by not having the trailing whitespace at all. This sets the separators as described in the documentation at https://docs.python.org/2/library/json.html to avoid trailing whitespace when using indent. It also consolidates the JSON-writing configuration into a single place by creating a single JSONEncoder object.
I suspect editors like to strip out this trailing whitespace (e.g., from mozilla#53) which activities.py then readds when manipulating the JSON (in mozilla#66). We'll avoid the churn (and annoyance) by not having the trailing whitespace at all. This sets the separators as described in the documentation at https://docs.python.org/2/library/json.html to avoid trailing whitespace when using indent. It also consolidates the JSON-writing configuration into a single place by creating a single JSONEncoder object.
No description provided.