Archived / immutable content

[craigfrancis]

While some packages need to be kept up to date, and expired when they become too old; there are also things that should never expire/change.

For example the content of a webpage a user wants to keep, a report or invoice created by a website, etc (this is instead of using a PDF or MS Word document).

So would it be possible to skip the Expires header, and have some way of marking the package as immutable?

That immutable flag could also instruct the browser to never download any resources, and for the JS Date object to return a date/time based on the Date header from the package (not the current date/time)... may be related to issue #104?

[jyasskin]

"Archival" makes me think of formats like WARC, which we're not trying to compete with: they focus on recording the state of the web, while we're trying to distribute content to browsers.

However, the rest of your comment looks like your use case is actually around saving a webpage for later personal use. Most of the need for expiration centers around preventing attackers from forging signatures or exploiting bugs, which isn't a risk for sites you've saved personally and don't distribute. We will support un-signed packages for this sort of thing, and there won't be anything forcing them to expire. Does that work for you?

[bmeck]

The cache-control: immutable header also seems to follow that line of thought where it does have an expiration associated with it, even if it is immutable. I think saving from signed->unsigned seems a reasonable utility to have for most tools.

[TzviyaSiegman]

@prototypo Please see overlap with Archiving section (to come) in https://www.w3.org/TR/pwpub/

[ibnesayeed]

The web archiving community is taking notice of it. While WARC works well for its purpose, it would be good to give some more thoughts on the archiving aspect, be it in the form of some possibility of transformation between webpackage and WARC or some other way to interoperate. WARC might want to store the whole package as an object or unpack it to store individual resources.

[craigfrancis]

@jyasskin, @TzviyaSiegman, I think there are similarities to Web Archive (WARC) and Packaged Web Publications (PWPUB); but I think the WebPackage format is slightly more appropriate for these document types:

• Invoices.
• Terms and conditions.
• Contracts.
• Reports, assessments, statistics.
• Bank statements.
• CVs.

Where these document (as packages) could then be easily downloaded, emailed, viewed any time, and kept/stored/archived - where PDF files cause problems.

And I agree, these documents do not need to be signed by an origin, so un-signed packages would be a simple solution.

---

But, just to think about it further... if it was possible for the WebPackage format to work with "cache-control: immutable", as per the suggestion by @bmeck, that could be a flag to show that a package can be kept indefinitely.

And later (version 2?), that flag could be used to sign the content in a slightly different way - e.g. the Code Signing approach, where the Date recorded within the package is used instead of the current date, both when checking the certificate, but also when executing JavaScript (you don't want some JS hiding content based on the date/time).

[rektide]

@craigfrancis according to https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html#rfc.section.4.1 ,

Packages are designed to hold public information and to be shared to people with whom the original author never has an interactive connection. In that situation, there’s no way to keep the contents confidential: even if they were encrypted, to make the data public, anyone would have to be able to get the decryption key.

That said, if the only data inside the bundle is encrypted data, your use cases of holding secure personal information in a webpackage could be possible. Just keep in mind that you're somewhat in the explicit "non-goals" area of webpackage.

That all said, as a developer I would definitely expect some means available to me to keep resources available from the page for a long long time. "Immutable" content sounds like something I'd want. I'd hope that existing HTTP headers would be sufficient to make this happen. Is there any behavior of cache-control: immutable that needs improvement?

[craigfrancis]

@rektide, thanks for the comment, but (fortunately) I’ve no interest in the package being encrypted from a sensitive data / privacy point of view. I don’t think that will be possible for this spec, as secret key management is tricky, and isn’t covered at all in this case... you might be able to argue for password protected packages, but that would need to be considered another day, when the basic principle of archivable/immutable packages exist.

For now I think it should be up to the user to protect their sensitive documents, and if they decide to share their personal data (or whatever is in these archive-able packages), that will be their choice :-)

As to the immutable header, I hope it’s possible in some way... where the browser might then be able to show that the package is unchanging (which is slightly different to how other non-immutable packages will work).

[jyasskin]

Closed by #137.

[craigfrancis]

Issue 576 continues the discussion regarding disallowing network access for unsigned bundles.