Subject: Re: [Wpack] Signed Exchanges and Web Archiving Use Case

From: Ilya Kreymer <[email-masked]>
Date: Fri, 18 Oct 2019 17:38:55 -0700

Hi Jeffrey, all,

(Moving to this list at Jeffrey's request)

I am very interested in the 'archival' use case of web pack. In particular,
I have a prototype, https://wab.ac/ that can
'replay' and HAR or WARC file (standard format used by Internet Archive and
others).
The tool replays individual HAR or WARC files, using service workers,
providing a rendering of the network traffic contained (and a lot of JS
emulation).

The prototype demonstrates that such replay may be possible, if at least
using service workers and custom replay engine, and so verification would
be extremely useful to have.

Currently,  the 'emulation' of a particular time is handled by the replay
system already, as is isolation between different WARC/HAR files, as is
isolation of other built-in primitives (like local storage, etc..).

But, the service worker has to rewrite the responses in order to render at
a different domain. This probably poses a limitation on what can be
rendered directly.
Probably just verifying the raw data, and being able to show that the
responses that a service worker reads are 'verified' would be a good first
step somehow.

The ability to have longer term signatures would also be key for the
archival use case. Could the client browser create counter-signatures
itself?
For the archiving use case, being able to prove that the exchange happened
from the client browser's perspective would be quite useful, even more so,
but I don't know if that is within scope at all, eg. if it had its own
certificate and keys..

Happy to discuss further, not sure how much of this is doable within
current spec, but definitely interested in wpack and signed exchanges and
how this may apply to make web archiving more reliable/verifiable for users.

Thanks,
Ilya

On Fri, Oct 11, 2019 at 12:40 PM Jeffrey Yasskin <[email-masked]>
wrote:

> https://wab.ac/ looks like an awesome tool. I suspect it can't provide
> isolation between the javascript storage used by different WARC files. We
> plan to do something for that in the bundle format for unsigned/untrusted
> content. Sawood Alam also suggested being able to pretend the archive is
> being run at a particular time, which seems sensible but is currently low
> priority.
>
> The remaining difficulty we've noticed in verifying that the content is
> accurate is that Signed Exchange signatures expire in a short amount of
> time, because we don't want browsers to trust javascript that might have
> fixed security holes. Even if the archival system trusts the signature for
> longer, we still don't expect web server operators to be able to keep a
> private key secret for multiple years. So you need a system of timestamping
> servers, and a contiguous chain of their (counter-)signatures back to the
> original server signature. Signed Exchanges don't currently support
> counter-signatures well, but that's something that could be added. I
> wouldn't expect browsers' UI teams to decide that chain of trust is worth
> showing in the UI, although I could always be surprised.
>
> Would you mind having this conversation on the [email-masked] list
> <https://www.ietf.org/mailman/listinfo/Wpack> so more people can see your
> interest and can chime in?
>
> I unfortunately won't be at the Chrome Dev Summit. I'll be at the WPACK
> BoF the next week in Singapore:
> https://trac.tools.ietf.org/bof/trac/wiki#WPACK.
>
> Jeffrey
>
> On Fri, Oct 11, 2019 at 11:12 AM Ilya Kreymer <[email-masked]> wrote:
>
>> Hi Jeffrey,
>>
>> I wanted to reach out to you regarding the archival use case for web
>> packaging and signed exchanges. I work on a project called Webrecorder,
>> which includes a hosted service (https://webrecorder.io/) and desktop
>> app to allow users to create and view their own web archives. To support
>> more decentralized web archives,
>> verification that the content is authentic and was actually served by the
>> web server is imperative, and for this reason I'm very interested in the
>> signed exchange efforts.
>> Like most other web archiving efforts, Webrecorder users standard WARC
>> files, but if verification was an option, could certainly support new
>> package format.
>>
>> I also wanted to share a new development, https://wab.ac/ which allows
>> the browser to open and render WARC files directly, without requiring a
>> server, by using service workers. This also works with HAR files, that can
>> be made by Chrome DevTools as well and then loaded in the tool.
>> This demonstrates a proof-of-concept of browser support for WARC files,
>> as mentioned in
>> https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html#rfc.section.2.2.9
>>
>> Here are some example link which load a WARC from github pages and
>> redirect to rendered page:
>>
>> https://wab.ac/?coll_example=examples/netpreserve-twitter.warc&url=/example/https://netpreserveblog.wordpress.com/2019/05/29/warc-10th-anniversary/
>>
>> https://wab.ac/?coll_example=examples/netpreserve-twitter.warc&url=/example/https://twitter.com/netpreserve
>>
>> This should allow for rendering of any web archive directly in the
>> browser, but no way to verify that the content is accurate, so signed
>> exchanged or some form of verification becomes really imperative.
>>
>> For a web archiving perspective, we want to be able to every http
>> exchange from the server, and if that's not possible, at least from the
>> client, so that future users can verify the authenticity of the archive.
>>
>> I'd love to chat further if you have time and would be interested.
>>
>> I'm based in SF, and applied to attend the Chrome Dev Summit in November,
>> in case you'll be here then.
>>
>> Thank you,
>> Ilya
>>
>>
>>
>>