Does this verify and/or rewrite the SRI integrity hashes when it inlines resources?
Would W3C Web Bundles and HTTP SXG Signed Exchanges solve for this use case?
WICG/webpackage:
https://github.com/WICG/webpackage#packaging-tools
"Use Cases and Requirements for Web Packages"
https://datatracker.ietf.org/doc/html/draft-yasskin-wpack-us...
In Gwtar: A static efficient single-file HTML formatWICG
webpackage
Go2017–2026
WICG / webpackage
webpackage
Web packaging format
32Distinct people
53Mentions
0Explicit recommenders
1.3KGitHub stars
What to know before exploring
What it is
Web packaging format
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- wicg/turtledove · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year53 dated mentions
Observed mentions: 2017-07-13 03:26:41 UTC to 2026-02-15 19:43:26 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 20 | 4 | 16 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Packaging Websites
Not to be confused with webpack, this repository
holds a collection of specifications aimed at packaging websites. These
specifications replace the W3C TAG's Web Packaging
Draft and 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. A full list of use cases and resulting requirements is available in
draft-yasskin-wpack-use-cases
(IETF
draft).
Explainers
Use cases
Maintaining security and privacy constraints
Specifications
Building this repository
Building the Draft
Packaging tools
Signed HTTP Exchanges
Web Bundles
Isolated Web Apps (signing with integrity block)
Explainers
The explainers walk through how to use these specs to
achieve the use cases.
Use cases
Packaging whole pages or sites: can be
signed or unsigned.
Serving signed subresources of a signed top-level HTML
page
Navigating to top-level unsigned pages
Packaging subresources. This can include groups of
JS modules, stylesheets, images, or fonts. This is also getting fleshed out at
https://github.com/littledan/resource-bundles/
Maintaining security and privacy constraints
How to avoid third-party tracking
What origin does an unsigned bundle have?
Specifications
The specifications come in several layers:
Signed HTTP exchanges (a.k.a. SXG)
(IETF draft):
These allow a browser to trust that a single HTTP request/response pair was
generated by the origin it claims.
As we implement and test signed exchanges, we're publishing periodic
snapshots so that browsers, publishers, and intermediates can synchronize
on the same format. The current implementation snapshot
is an Internet Draft, and a draft of the next
snapshot
is in this repository.
Web Bundles (previously called Bundled HTTP exchanges):
A collection of HTTP resources, each of which could be signed or unsigned, with
some metadata describing how to interpret the bundle as a whole. This
specification has an initial draft in a PR, but isn't finished yet. This work
may proceed through either the IETF or the W3C/WHATWG.
Update: This work was moved to the wpack-wg/bundled-responses
repository (Web Bundles (IETF draft)) .
Loading: A description of
how browsers load signed exchanges. This is initially specified
here, and will eventually merge into the appropriate specs, e.g.
Fetch, that live in either the W3C or
WHATWG. Currently this only covers signed exchanges.
Subresource Loading
(Explainer):
A description of how browsers load a large number of resources efficiently with
Web Bundles.
This is initially specified here, and will eventually merge into
the appropriate specs.
A previous draft of the format combined layers 1 and 2 into a single format for
signed packages:
draft-yasskin-dispatch-web-packaging
(IETF draft).
The DISPATCH WG at IETF99
recommended the current
split.
Building this repository
Building the Draft
Formatted text and HTML versions of the draft can be built using make.
$ make
This requires that you have software installed as described in
https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md.
Packaging tools
Signed HTTP Exchanges
Install this with go install github.com/WICG/webpackage/go/signedexchange/cmd/... (Golang 1.18+).
See go/signedexchange for the usage of the tool.
Web Bundles
There are several tools.
Go (Reference Implementation)
Install this with go install github.com/WICG/webpackage/go/bundle/cmd/....
See go/bundle for the usage of the tool.
Node
There is a npm package, wbn.
Plugin for bundlers (Experimental)
Rollup plugin
Webpack plugin
Rust (Experimental)
google/webbundle
Isolated Web Apps (signing with integrity block)
Go (Reference Implementation)
See go/bundle#using-integrity-block-sub-command for more.
Node
There is a npm package, wbn-sign.
Also same plugins as for Web Bundles can sign the bundles.
Read the full README on GitHubWhat Hacker News says
53 sourcesThis may eventually come to life via Isolated Web Apps https://github.com/WICG/isolated-web-apps/issues/1 or for example via webpackage https://github.com/WICG/webpackage/issues/576
The first step along the way though is making actually secure web apps possible.
Aren't secure web apps already possible? Well, Signal among others thinks otherwise. See the Isolated Web Apps explainer for a full explanation https://github.com/WICG/isolated-web-apps
In Show HN: I made a privacy-friendly and free image, audio and video converterGood stuff. Still, drives me a bit nuts that we package/HTTP Signed Exchanges, Message Signatures, and web archiving all have very similar but different versions of the same thing.
Webpackage has a lot of stuff that seems super cool to me. Alas it seemed mainly to be a small handful of engineers & most seemed to have moved on from the effort. https://github.com/WICG/webpackage/issues/713
Given the frosty response in the comments they got I guess I'm not shocked, but in general it feels like web standards could use better long term care, that they often don't get, alas.
In HTTP Message SignaturesSome of the navigating into a bundle stuff is indeed not presently happening.
But there's a bunch of specs for signed exchanges & subresources that underpin & allow resource exchange, and which do have recent drafts. Webpackage seems to be doing OK ish. But yeah we bundles specifically do seem to be all expired.
https://github.com/WICG/webpackage#specifications
In Show HN: An alternative web-like system designHTTP SXG and Web Bundles (and SRI) - components of W3C Web Packaging - may be useful for a signed WASM package format:
https://github.com/WICG/webpackage#packaging-tools
How is WASM distinct from an unsigned binary blob?
In New Docker Desktop: Run WASM Applications Alongside Linux Containers in DockerThere's signed & bundled http requests that, I think, will do much of this job better in the long run. It also helps accelerate the everyday web browsing experience/page load speed. Webpackage.
I really like the idea of being able to take a webpage I've downloaded & hand it to my friend. Retransmissable webapps. If the app is offline capable, theycll have the full experience, then & there.
Memento's earlier & very interesting, great effort. I still think webpackage/web bundles is more likely to gain traction & to manifest into what we want.
https://github.com/WICG/webpackage
In About the Memento ProjectWith certificate transparency, I dont think SXG's expiration is a real barrier to broader use. The hardnosed shitty browser attitude around right now: it will collapse in the face of obvious utility, other people will implememt more aspirational & liberal systems. This stance is untennable in the face of the obvious huge value of being able to look at old signed content, particularly when coupled with certificate transparency systems. This conservative standard will is just a minimal & obvious agreeable starting place, something to appease the rejectionist low-caliber safari-alike attitudes, but adoption will give way to expansion, given the immense user value of signed content. I say this as a core core protester against these pathetic loserly expiration timeouts[1].
I get maybe not putting all your chips in SXG basket. I disagree with a
Read the rest
bunch of the protest: this seems like a sensible, basic, obvious layered enhancement to the existing web. Safari & Mozia are (as is the mood today) being terrible shits as usual, the regressives.
Contrasting ADX versus SXG just feels so wild, because SXG is a small refinememt to a vast world spanning & complete ecosystem of technology that has already taken over the planet. It directly targets the one complaint you make: http-server centricity, & sets dynamite to that one old bad no-good base. And ADX is an standalone completely isolated alternate world, it's own reality. This tension, whether we need a baseline which is 100% new & novel & redefines the entire problem space on it's own terms, completely from scratch, or whether we can hack & improve & enhance what we have: I dont feel like there's any camp at all left to defend improvememt.
Ideally SXG would be used woth additional user-encryption. User subdomains, eith their own keys would be swell. Turning sites into sites of sites is what SXG really starts to permit. Layering in some .well-known to be more cryptographically portable with identities ks just another small enhancement, just more layering, albeit yet-more-idealism.
Tear it all down, start over... it's the mode. I agree, this debate needs more than HM comments. But this tension & conflict, this view of the world & how it evolves or revolts: it's been trying to make revutions & insist no bounds, nothing today can possibly be good enough for tomorrow. And two plus decades latter, it's made such tiny impact, is so niche.
I accept your snub, getting told im exasperated, but it's for a real reason, it's because these decades have failed to deliver & so few have willingly tried improving what is (Safari & Mozia being a quite vocal modern anchor keeling things in place, a modern astrpturfing shouting class against trying anything, especially). This effort does have the social capital to perhaps emerge & birth something new, but we could also just improve & greatly fix everything that ready is. With minor, layered, small, principled enhancements.
[1] https://github.com/WICG/webpackage/issues/597
Is this still on track to become a standard? https://github.com/WICG/webpackage
In SingleFile: Save a complete web page into a single HTML file> the idea that we have a choice between no ads or the most pernicious ads imaginable is certainly a false one
I agree with you. I spent a large part of 2018-2019 trying to make ads declarative, and am now working on (among other things) increasing the isolation of conventional ads [1] and implementing cross-site advertising without cross-site identity leakage [2].
But it sounds like you and my parent have very different views: there's a lot of space between "ads should be a lot better" and "ads should not exist".
[1] https://github.com/WICG/webpackage/issues/624
[2] https://github.com/WICG/turtledove/blob/main/FLEDGE.md
In An iframe from googlesyndication.com tries to access the camera and microphoneNot sure if this is entirely what you're after, but check out https://github.com/WICG/webpackage
In ArchiveTeam Warrior backing up Redditsigned web bundles [1] let you package up a page as a fixed resource, distributed with a signature to verify that the content of that page is what the author intended it to be, so a site like twitter that is embedding it can be sure that what they're embedding is always the original resource.
however, this is part of AMP, and so web developers who prefer the "do whatever the fuck you want" aspect of the internet push back against it. the ability to ensure that a web link contains the same content at a future date as it did when it was initially crawled was one of the things we destroyed along with AMP.
[1] https://github.com/WICG/webpackage
In Faking Twitter unfurling to phish youThe Web Packaging specifications[1] are surprisingly close to turning URLs into a content-addressed system. Content-addressed networking is all about names for content, after all, which philosophically is a close match for what a URL is, it just so happens that HTTP uses urls to resolve servers that serve the content. But with Web Package, content is signed by the origin, and can be distributed via other means.
One of the primary uses cases for Web Package is to let two users exchange content while offline, perhaps via a usb stick or what not. This isn't part of the specification, but we could begin to imagine sites that have a list of the web packages they have available for download. And we could imagine aggregating those content indexes, and preferring to download from these mirrors over downloads from the origin's servers.
I'm hoping
Read the rest
eventually we get a fairly content-addressed network, via urls.
[1] https://github.com/WICG/webpackage
A phyrric victory for a Web that is basically ChromeOS.
Ever heard of Web Bundles?
https://web.dev/web-bundles/
https://github.com/WICG/webpackage
In The End of AMPI think advertising is positive [1] and the role of ads in funding freely-available sites is very important. My current work is primarily on how browsers can allow more private and secure advertising [2][3][4] which I think most people will agree is valuable even if they are less in favor of advertising in general.
At a lower level, I do this job because I'm paid, which allows me to donate. [5] But I wouldn't do this work if I thought it was harmful; there are lots of different kinds of jobs I could take.
[1] https://www.jefftk.com/p/effect-of-advertising
[2] https://github.com/google/fledge-shim
[3] https://github.com/WICG/turtledove/issues/161
[4] https://github.com/WICG/webpackage/issues/624
[5] https://www.jefftk.com/donations
In GitHub blocks FLoC across all of GitHub Pagesdata urls encode things in base64 format so bloat up the file. Also the user agent can't just seek over them, requiring it to parse the entire included base64 content. There are better ways, but sadly nothing cross platform:
* https://github.com/WICG/webpackage
* https://en.wikipedia.org/wiki/Webarchive
In HTML5 still doesn't replicate what mattered about FlashShowing the 15 most recent of 53 sources. Enable JavaScript to search and browse every indexed mention.