7 day SXG expiration? Why?

Hello. One of my core interests in webpackage is to allow offline use cases. For example, I think of the 100 rabbits interactive creative design team. They sail around the world, & sometimes make multiple week crossings. I had hoped WebBundles would make using web systems valid for these sorts of trips, & it felt confirmed when I saw that the use case document contained offline browsing as a primary objective.

To my chagrin, I recent read that there appears to be an arbitrary 7 day limit after which Signed HTTP Exchanges (SXG) will return as "invalid". And that is from the time of signing, not the time of downloading. This short expiration window very much calls into question whether or not webpackage/webbundles signed exchanges support the offline browsing use case.

1. ⌛💣

the offline ticking time bomb

Let's talk further to the sailing model. One day you are sailing the sea, looking at your offline charting webpage, and the next day you wake up and all of a sudden the browser & page you are relying on to get you to land have decided that the signed http exchanges they rely upon are now no longer valid, and your page no longer can access the offline resources you both expected it to read. This is an extreme hazard, introduced by dual problems of lack of awareness to this ticking self-destruct clock, & an extremely fickle & short fuse before offline content reaches this self-destruction. Hikers, travelers, boaters, spacemen, disaster-survivors, & other perhaps connection-starved folk will all be enormously encumbered by this short self-destruction fuse that burns within their browser.

This problem is particularly pernicious for those with inconsistent connectivity. If you live somewhere that experience multi-day internet or power outages a couple times a year, the chance for SXG to be able to help you is highly questionable, & dependent all too much on how recently you happened to visit a site. For example if you read novels in, say for example, a Project Gutenberg offline book reader, but hadn't opened the site in 4 days, and you lose power, you will very quickly lose the ability to access or share the books you thought you were carrying with you. You couldn't predict or guess when you might need to re-download your content (unchanged for hundreds of years but requiring a re-download none-the-less, to freshen the SXG signature date) with new signatures.

In the ideal case, If I refresh my content (say it's a lengthy download), go to sleep (while the download runs), wake up & hop on a 12 hour flight, and the sys-op did everything in their power to give me as much time as possible, I've already potentially used up 15%+ of my offline time granted by SXG's remarkably short self-destruct fuse before I land. This is the ideal scenario, fully planned ahead of time, the best case.

2. ⟳∞

the fear-driven never-ending redownload cycle trap

[+4 hours edit: I was not aware signatures could be updated, which resolves the download-cost. I am relieved to hear this. I do still have reservations about the user-cost of maintaining fresh data, that we will be driving people to a behavior that makes them compulsively connect & update. And I feel like there are anti-user privacy aspects that are highly concerning lurking here.]

The case of losing internet access unexpectedly highlights a problem even bigger & worse than than content unavailability: we are trapping the user in an endless cycle of redownloading content, creating a sense of fear that the content they choose to bring with them is forever only days away from expiring.

Using service-workers, a user might safely read a book at their leisure. But with SXG, a user now has a new expectation for their web experience, that they can share their content too. Alas, to do so, they must continually re-download content. Not just 52 times a year, once a week, when the content expires, but ahead of time, so that if they do want to share the book they are reading, the band website they are enjoying, they can give those they are sharing a gift that will last as long as possible before it self destructs. Rather than freeing users from connectivity, we have now created a new cycle that insists we regularly reconnect & refresh, generating enormous fear that the content we cherish most is ever expiring, that we must re-download, or face negative consequences, find ourselves stripped of this new ability that they have grown to enjoy.

This is so striking, so remarkable an end scenario for the current version of SXG. The very users most in need, with fickle or periodic connectivity & likely also costly connections, who we claimed to be helping, are now instead bound into a vicious cycle of continually re-downloading the same content regularly that, pre-WebBundles, they could rely on to be cached, in order to enjoy the ability to share content.

3. 💢💻

radically increased demands on small operators

[+4 hours edit: i had missed/forgotten that sxg is not required for a SecureContext-approved WebBundle, which makes sxg "voluntary", albeit still a thing i think most users will i believe want. none the less, it is not in the critical stream for operators: i continue to wish small/indie operators had a less demanding time-scale to operate sxg on, but my alarm here is significantly less than the already fairly-mild concern i originally felt.]

My third concern is for operators. Outside of all offline concerns, WebBundles are also a tool for bundling and uh bundling. This fills a desperately needed hole in the JS ecosystem in particular, where EcmaScript 6 / EcmaScript-2015 modules have been the official language specification, but there has been no way to get many modules to a browser (effectively short of rewriting EcmaScript modules into something different & not modules.

To this end, we have created tools like Browserify & Webpackage, which perform long complex operations to convert our sea of EcmaScript modules into concatenated non-module JS, such that they can be shipped effectively & with 'cross-file' compression.

WebBundles use-cases talk about these bundling concerns, describing these needs & desires. And the hope of many is that has been the WebBundle would free us from these complex & obfuscating machines, & give us a path to enjoy transporting bundled JS modules without weighty transpilation that turns these modules we coders & webmasters work with every day into not-modules that when run behave very much alike modules but which are something completely different, supported by their own purpose built execution systems outside of the browser's own module loading & running systems. Which sounds wonderful, like exactly the answer we've been desperately looking for: finally, it sounds like we can actually directly bring EcmaScript modules on to the web.

Except for the operational disadvantages. Historically these bundlers could produce static bundles that could be served easily & readily. Now, with this new 7 day expiration, instead of building a site, & publishing it, operators have to either rebuild their bundles regularly with freshened signatures, or hand over their private keys to webhosts that will rebuild the signatures for them.

At a minimum, this means rebuilding your bundles every 7 days. That alone imposes a great burden on those who enjoy "static" websites, something web operators used to be able to create & publish & forget about. But a weekly cron job to rebundle is not the end of the story for operators. If an operator wants to allow users to share the website, then it's up to the operator to regenerate the cycle more frequently, such that the expiration date remains 7 days in the future even as time passes.

I see no reason why the operators should have to face such sharply increased demands to continue serving content as they switch from WebPack to WebBundles. In many cases, I fear small websites will opt to turn over their most treasured most private keys to external operators, to offload the complexity, at great cost of the privacy & security of their own site, which they now no longer retain cryptographic responsibility for. This seems like a deep regression for the web as a whole, and one that a much longer expiration would radically ease.

---

How and where did this 7 day expiration arrive in the spec? What justifies this?

On three accounts, this fantastically short expiration seems like a dangerous & arbitrary limitation. In the first of scenario, offline users are suddenly being cut off, frozen, after a short window, from the offline content that kept them from being dashed into rocks or left adrift at sea. In the second scenario, far more prevalent, many users, in fact the most vulnerable & needing of robust offline access users, become addicted to a tragic tragic & enormously costly & energy-intensive never-ending ceaseless-redownloading cycle that they can never escape from, a- and I'm serious here- new technocratic limitation introduced to the web that feeds a vicious cycle of addiction & need & want & overall fear of the computing world. In the 3rd case, we see enormous operational complexity introduced to being & remaining on the web, particularly cumbersome to smaller websites that have enjoyed static hosting for decades & who now have to check their cron jobs at a minimum 52 times a year. I've known there was an expiration in webbundles, but you know: I always assumed it was reasonable. All three of these scenarios seem like critically unhealthy & short scenarios that users & sites will face with great pain on a regular & day to day time-frame imposed by the day-to-day time-scale of this 7 day expiration.

I do not feel safe at all describing webbundles or SXG as an offline browsing technology under these conditions. If operators wish to make content available longer, let them. If users wish to not keep content as long as an operator allows, let them. Yes, it would be good for sites to be able to freshen themselves, to not rely on aged content, but a short expiration does not seem like the appropriate way to enable that. I am terrified to know what answers might come, because I am not prepared to accept any counter-reply to issue #2 the redownload trap in particular, but I must ask: why? Why so short? This seems outright cruel to all involved; why would we not want a user to be able to offline browse a site a month latter, or even a year latter, if no other options are available & on hand for the user to turn to & the certificate chain is good & the content sits there on their drives or on a flash drive nearby? Surely we can act in the interest of the user here, help them to continue to benefit from the use of their assets, for as long as the signing certificate chain is good for, versus leaving them with no alternatives & without?

As a small indie systems operator I had hoped for WebBundles to help reduce some of my systems operating complexity by letting me package my JS modules effectively, but the price has become radically higher with these very short-lived expirations. But far more so, discovering this critically short expiration leaves me in a state of critical mourning for the user, the user I thought we were about to be helping. The offline use cases seem not merely weakened, but so unreliable & short as to be an anti pattern, as to be actively dangerous to folks wishing to use offline web systems. But a system that forces ongoing regular multiple-times-a-week re-downloading to enjoy the benefits of knowing that you can keep or share the data you want, that is meaningful to you, actively enslaves & degrades the human spirit in unconscionable ways, and which will radically penalize the less connected folks of this earth who could otherwise best & most truly benefit from this technology.

Technology should have our back. It should permit, allow, enable. This expiration sets a time horizon forever near at hand, forever a trap we must watch ready to spring shut on us.

---

I have been radically hopeful that an offline web where we don't need regular connectivity could come. I have hoped we could simplify the experience of sites by giving them good systems to ship modules without mangling. For these reasons, I have been a longstanding avid fan & supporter of webbundles, deep in my heart, & in countless places online (recently). Webbundles has been an endless source of inspiration that the future is about to get radically better, and I have believed fully in the use cases & webbundles ability to serve them.

This one constraint though, it has me falling apart completely. I am shattered. I have tried to maintain some distance from my opinions above, but in purely my own humble opinion, forgive me, I intend no personal injury nor attack, but my assessment is that with this present 7 day expiration, 🌐📦 is grossly antithetical to the web, to sites, & to, most of all & our shared greatest concern so say we all, the user. I beg, even a month is scant time when the clock is ticking. I would like us to better 🏄 the offline 🌐 together, for longer, much longer.

Start with the linked draft-yasskin-httpbis-origin-signed-exchanges-impl.md passage around line 443, then compare it with the offline-browsing use case in draft-yasskin-wpack-use-cases.html. Trace the discussion and existing rationale for the seven-day SXG validity period. Done means reaching a maintainer decision and documenting or resolving the requested expiration-policy question.