From nobody Thu Oct 10 10:51:00 2019 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178151200C3 for ; Thu, 10 Oct 2019 10:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3b8x93gaUzW for ; Thu, 10 Oct 2019 10:50:55 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973AA1200F6 for ; Thu, 10 Oct 2019 10:50:54 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id c195so5043836lfg.9 for ; Thu, 10 Oct 2019 10:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IiFuEM5XAIbgp/+q+M/Ki1vlQrWuqmPDHp60lq+qsJg=; b=iUSjLOOUqxu9ZU8+7WIdZxcs5Lkksxu0i3fMnYJCPhnfazaRqi77WBf7ONVRlRfFwV WF02hSVSgWfAysfXG3O8/WqhoDLibZQeZE1MT0cMCPEALB+FCntUUP2hb+kYk55Ooz6D tPhS+tJ1cHvJyHmpiU7fvmcOVmIFXw8Lg1kmUOS0NMrxF14y3bwQxE6XQry7ce/wm6wc TmtTsBu9DaDX6CoSr3tGLWgonZtAx2smt469yPmVvi7bChH7oQmxlV/gryR01LCMy6Bf MyrUn7zAx+yqyUBU6dA02aIEQzgN18KbXHOQBEmxt+h6g/2bNEURM5qv/w7/aBiBvXV+ O/7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IiFuEM5XAIbgp/+q+M/Ki1vlQrWuqmPDHp60lq+qsJg=; b=LDtle7lyynT4wXzrZBnB3ZyZmZbyugurD9lyUcU/vLa2dWqwuOVAUbFUwuBZphk/4W TENLtQ1vK1lJOp/swIPHyN2TtvCp/I0nGGXx/wBcNnqpcv4qzPIdpWlwv+MGjo3EqbOG 2spGha9t2rOCFwuVBEOZQUnFTSIyuX1jl/a22VKTzzTJ8CmM3YWMmVn6sKGpP0N77QYa KuGqRjxjp4EmmtV5tbgZQ/zp5Oe73Xekbn1TIMLk06e9J1JhN815yOLrT1N6nrkYyox5 ZOLuhagQrhWxF6K4wrW7tul3iicYiuX1wB8KQVg6m/X2MsHvc0bCSrwueKX5tqIlQP+y k3UQ== X-Gm-Message-State: APjAAAUPBRdk9no0h6N3MCNpqRjcujrjplsMRYNB95NMuq4hd6oJdLWd MxedAvCDES6469ztDX9SUe+3QC5cZzUfAkOL9Waja5sxamX/Rw== X-Google-Smtp-Source: APXvYqwuwyUICwE42aW51W3iPeL4vGxuN4ywbDGo0nuEq/qcwyjCV4f1hk591Fip4eclZkI5tg7VmL1gLEZiWz0xBu0= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr6557336lfp.94.1570729851881; Thu, 10 Oct 2019 10:50:51 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Thu, 10 Oct 2019 10:50:40 -0700 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000dc913c0594920aae" Archived-At: Subject: [Wpack] Draft WG charter X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 17:50:58 -0000 --000000000000dc913c0594920aae Content-Type: text/plain; charset="UTF-8" In support of the proposed BoF at IETF 106, I've drafted a possible charter for a WG at https://github.com/WICG/webpackage/blob/master/IETF-WG-charter.md, and I've pasted the current version below. What do you think I should change to improve the BoF's chances of approving a working group? Thanks, Jeffrey # Background There is a long history of webpages grouping multiple subresources into a single combined resource because this allows cross-resource compression and because HTTP/1 made requests expensive. This encouraged the W3C TAG (Technical Architecture Group) to propose a web packaging format based on multipart/* to give web browsers visibility into the substructure of these combined resources. HTTP/2 was expected to make these bundles unnecessary, but that hasn't panned out. In countries with expensive and/or unreliable mobile data, there is an established practice of sharing content and native applications peer-to-peer using SD cards, WiFi Direct, and similar transmission channels. Untrusted web content could already be shared, albeit awkwardly, using existing formats. However, with the web's move to HTTPS, it became impossible to share web apps over these channels, so a team within Google Chrome began adding an index and origin-trusted signatures to the TAG's packaging format. The AMP project realized that this new format could solve the problem that pages served by the AMP cache got the wrong URLs. This eventually led to Google Chrome shipping an evolution of the format and Google Search using it in search results. # WPACK The WPACK working group will develop a specification for a web packaging format that efficiently bundles multiple HTTP resources. It will also specify a way to optionally sign these resources such that a user agent can trust that they came from their claimed web origins. Key goals for WPACK are: * Efficiently storing a few or many, small or large resources, whose URLs are from one to many origins. Three examples of the sets of resources that should be supported are: a client-generated snapshot of a complete web page, a web page's tree of JavaScript modules, and El Paquete Semanal from Cuba. * Allowing web apps to be safely installed after having been retrieved from a peer. * Minimizing the latency to load a subresource from a package, whether the package is signed or unsigned, and whether the package is streamed or loaded from random-access storage. * Being able to smoothly migrate to support future requirements such as random access within subresources, larger numbers of subresources, or avoidance of obsolete cryptography. * Losing as little security and privacy as practical relative to TLS 1.3 and documenting exactly what is lost and how content authors can compensate. Part of this is analyzing how the shift from transport security to object security changes the security properties of the web's existing features. * Minimizing the likelihood that the new format increases centralization or power imbalances on the web. The packaging format will also achieve the following secondary goals as long as they don't compromise or delay the above properties. * Support more-efficient signing of a single, possibly same-origin HTTP resource. * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs. For example, that they appear on a transparency log, that they have passed a certain kind of static analysis, that a particular real-world entity vouches for them, etc. * Address the threat model of a website whose frontend might be compromised after a user first uses the site. * Support books being published in the format. * Support long-lived archival storage. * Optimize transport of large numbers of small same-origin resources. * Allow the format to be used in self-extracting executables. * Allow publishers to efficiently combine sub-packages from other publishers. The following potential goals are out of scope under this charter: * DRM * A way to distribute the private portions of a website. For example, WPACK might define a way to distribute Gmail's application but wouldn't define a way to distribute individual emails without a direct connection to Gmail's origin server. * Defining the details of how web browsers load the formats and interact with any protocols we define here. Other standards bodies are more appropriate fora for this. * A way to automatically discover the URL for an accessible package that includes content for a blocked or expensive-to-access URL that the user wants to browse. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set (consisting of draft-yasskin-webpackage-use-cases, draft-yasskin-wpack-bundled-exchanges, and draft-yasskin-http-origin-signed-responses) does not imply that there is consensus around the feature or around how it is specified. # Relationship to Other WGs and SDOs WPACK will work with the W3C and WHATWG to identify the existing security and privacy models for the web, and to ensure those SDOs can define how this format is used by web browsers. # Milestones * Chartering + 3 Months: Working group adoption of use cases document * Chartering + 3 Months: Working group adoption of bundling document * Chartering + 3 Months: Working group adoption of security analysis document * Chartering + 3 Months: Working group adoption of privacy analysis document * Chartering + 3 Months: Working group adoption of signing document * Chartering + 18 Months: Use cases document to IESG * Chartering + 18 Months: Bundling document to IESG * Chartering + 24 Months: Security analysis document to IESG * Chartering + 24 Months: Privacy analysis document to IESG * Chartering + 24 Months: Signing document to IESG --000000000000dc913c0594920aae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In support of the proposed BoF at IETF 106, I've draft= ed a possible charter for a WG at=C2=A0https://github.com/WICG/webpackag= e/blob/master/IETF-WG-charter.md, and I've pasted the current versi= on below. What do you think I should change to improve the BoF's chance= s of approving a working group?

Thanks,
Jeffre= y

# Background

There is a long history of w= ebpages grouping multiple subresources into a single
combined resource b= ecause this allows cross-resource compression and because
HTTP/1 made re= quests expensive. This encouraged the W3C TAG (Technical
Architecture Gr= oup) to propose a web packaging format based on multipart/* to
give web = browsers visibility into the substructure of these combined resources.
H= TTP/2 was expected to make these bundles unnecessary, but that hasn't p= anned
out.

In countries with expensive and/or unreliable mobile d= ata, there is an
established practice of sharing content and native appl= ications peer-to-peer
using SD cards, WiFi Direct, and similar transmiss= ion channels. Untrusted web
content could already be shared, albeit awkw= ardly, using existing formats.
However, with the web's move to HTTPS= , it became impossible to share web apps
over these channels, so a team = within Google Chrome began adding an index and
origin-trusted signatures= to the TAG's packaging format.

The AMP project realized that th= is new format could solve the problem that pages
served by the AMP cache= got the wrong URLs. This eventually led to Google Chrome
shipping an ev= olution of the format and Google Search using it in search
results.
<= br># WPACK

The WPACK working group will develop a specification for = a web packaging format
that efficiently bundles multiple HTTP resources.= It will also specify a way to
optionally sign these resources such that= a user agent can trust that they came
from their claimed web origins. K= ey goals for WPACK are:

* Efficiently storing a few or many, small o= r large resources, whose URLs are
=C2=A0 from one to many origins. Three= examples of the sets of resources that should
=C2=A0 be supported are: = a client-generated snapshot of a complete web page, a web
=C2=A0 page= 9;s tree of JavaScript modules, and El Paquete Semanal from Cuba.
* Allo= wing web apps to be safely installed after having been retrieved from a
= =C2=A0 peer.
* Minimizing the latency to load a subresource from a packa= ge, whether the
=C2=A0 package is signed or unsigned, and whether the pa= ckage is streamed or loaded
=C2=A0 from random-access storage.
* Bein= g able to smoothly migrate to support future requirements such as random=C2=A0 access within subresources, larger numbers of subresources, or avoi= dance of
=C2=A0 obsolete cryptography.
* Losing as little security an= d privacy as practical relative to TLS 1.3 and
=C2=A0 documenting exactl= y what is lost and how content authors can compensate. Part
=C2=A0 of th= is is analyzing how the shift from transport security to object security=C2=A0 changes the security properties of the web's existing features.=
* Minimizing the likelihood that the new format increases centralizatio= n or
=C2=A0 power imbalances on the web.

The packaging format wil= l also achieve the following secondary goals as long as
they don't c= ompromise or delay the above properties.

* Support more-efficient si= gning of a single, possibly same-origin HTTP
=C2=A0 resource.
* Suppo= rt signed statements about subresources beyond just assertions that
=C2= =A0 they're accurate representations of particular URLs. For example, t= hat they
=C2=A0 appear on a transparency log, that they have passed a ce= rtain kind of static
=C2=A0 analysis, that a particular real-world entit= y vouches for them, etc.
* Address the threat model of a website whose f= rontend might be compromised
=C2=A0 after a user first uses the site.* Support books being published in the format.
* Support long-lived arc= hival storage.
* Optimize transport of large numbers of small same-origi= n resources.
* Allow the format to be used in self-extracting executable= s.
* Allow publishers to efficiently combine sub-packages from other pub= lishers.

The following potential goals are out of scope under this c= harter:

* DRM
* A way to distribute the private portions of a web= site. For example, WPACK
=C2=A0 might define a way to distribute Gmail&#= 39;s application but wouldn't define a way
=C2=A0 to distribute indi= vidual emails without a direct connection to Gmail's origin
=C2=A0 s= erver.
* Defining the details of how web browsers load the formats and i= nteract with
=C2=A0 any protocols we define here. Other standards bodies= are more appropriate fora
=C2=A0 for this.
* A way to automatically = discover the URL for an accessible package that
=C2=A0 includes content = for a blocked or expensive-to-access URL that the user wants
=C2=A0 to b= rowse.

Note that consensus is required both for changes to the curre= nt protocol
mechanisms and retention of current mechanisms. In particula= r, because something
is in the initial document set (consisting of
dr= aft-yasskin-webpackage-use-cases, draft-yasskin-wpack-bundled-exchanges, an= d
draft-yasskin-http-origin-signed-responses) does not imply that there = is
consensus around the feature or around how it is specified.

# = Relationship to Other WGs and SDOs

WPACK will work with the W3C and = WHATWG to identify the existing security and
privacy models for the web,= and to ensure those SDOs can define how this format
is used by web brow= sers.

# Milestones

* Chartering + 3 Months: Working group ado= ption of use cases document
* Chartering + 3 Months: Working group adopt= ion of bundling document
* Chartering + 3 Months: Working group adoption= of security analysis document
* Chartering + 3 Months: Working group ad= option of privacy analysis document
* Chartering + 3 Months: Working gro= up adoption of signing document
* Chartering + 18 Months: Use cases docu= ment to IESG
* Chartering + 18 Months: Bundling document to IESG
* Ch= artering + 24 Months: Security analysis document to IESG
* Chartering + = 24 Months: Privacy analysis document to IESG
* Chartering + 24 Months: S= igning document to IESG
--000000000000dc913c0594920aae-- From nobody Fri Oct 11 06:53:06 2019 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F422812004D; Fri, 11 Oct 2019 06:53:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, wpack@ietf.org, wpack-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157080198390.29423.8816214867921160602.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2019 06:53:03 -0700 Archived-At: Subject: [Wpack] wpack - New Meeting Session Request for IETF 106 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:53:04 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the wpack working group. --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Technology Overlap: httpbis quic dispatch secdispatch saag tls acme People who must be present: Alexey Melnikov Resources Requested: Special Requests: Please do not schedule on Monday morning. --------------------------------------------------------- From ikreymer@gmail.com Fri Oct 18 17:39:10 2019 Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739712080C for ; Fri, 18 Oct 2019 17:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1dDZ1wrA_io for ; Fri, 18 Oct 2019 17:39:07 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DAB12012E for ; Fri, 18 Oct 2019 17:39:07 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id a1so9504873ioc.6 for ; Fri, 18 Oct 2019 17:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=whgOS6/nceXXLi2KurKGG/srglql60oxYwrPFizBY08=; b=N/4UYiONohF+amEf6M9MDHNLHso8bk3sng6xlizl3vTh+NCA4WsWl/FEFpcvmdrKmz Q+4a1riwBKsIc4WHyQo4sJ2zhOULoW+kt2hQ8HSBV5WkYsJsMKYJJVMOZBz2YYGrdagg 49QGQqk+a7gLw8/8+0VrV2DSGuAI/NG/LHn76Yw0pnzMGMTftx8zaSGPV6H2/WIuuKuI zk+fmWgBRl5xGAB7CE2B/2SZ8FrOHdzxC071azWX5QgVdsEkoAA5orZHqeAMji+UBHIh Mn9Jo68J5/LLVpGJ2MvA7w6X/L7Mg3dBm2bmV53+ot6FNdpFyRNDqmT+nbRqVU5hDfFa x0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=whgOS6/nceXXLi2KurKGG/srglql60oxYwrPFizBY08=; b=KzqC55QyOfPOmJx1A/5O3gp/gEPTXBPFGV1fZy+ReJf4NSSdkdNo2Fi35Dfle1NhYx spIb9Utsc6tzGYr0C2ggc0Y044mZklmHCGS3KGtA5m69qJ+wihMbRVMnt1urpwQtvs8Z mqSaKFPC9UvfqMrqSw+nPH3cfgc41nDSaKYUQfvTderdY1dX2tuuQdGxsZIz/7/jwai9 BsmFb3UctwamUkchxyMZHE9b0JZWCAoQZpw1ZMrdknXN2DEhEeKL3oBHXE/CUJMCnqPA rv5GpbaZukZnBqZQaUjtPkurxJYk6OzDhFXUBqVY3Ri2iYRRg9SCa6iRg0RwfnbDyu6n cqxw== X-Gm-Message-State: APjAAAUqqbBTGvXynVJBBr6G0NOlpR2o1dm3hm4nFl3EwcO1kiUU02mj 069fhLtHDSw4URoIH4/cxPcn3BmWm9wbkiDBu3M= X-Google-Smtp-Source: APXvYqziSaP+DBE4blihDcvooKVUoYVQf7mXjSaXhwXEsttueYQ3nftee0+IfsaNFmLOo/Rl9YN2rkFTUKiVyIgAGMg= X-Received: by 2002:a5d:8d8f:: with SMTP id b15mr9209353ioj.296.1571445546271; Fri, 18 Oct 2019 17:39:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ilya Kreymer Date: Fri, 18 Oct 2019 17:38:55 -0700 Message-ID: To: Jeffrey Yasskin , wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000091c7b0059538ade8" Archived-At: Subject: Re: [Wpack] Signed Exchanges and Web Archiving Use Case X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 02:44:05 -0000 --00000000000091c7b0059538ade8 Content-Type: text/plain; charset="UTF-8" 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 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 wpack@ietf.org list > 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 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 >> >> >> >> --00000000000091c7b0059538ade8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeffrey, all,

(Moving to = this list at Jeffrey's request)

I am very inte= rested in the 'archival' use case of web pack. In particular, I hav= e a prototype, https://wab.ac= / that can
'replay' and HAR or WARC file (standard fo= rmat used by Internet Archive and others).
The tool replays indiv= idual HAR or WARC files, using service workers, providing a rendering of th= e network traffic contained (and a lot of JS emulation).

The prototype demonstrates that such replay may be possible, if at l= east using service workers and custom replay engine, and so verification wo= uld be extremely useful to have.

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

<= /div>
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 b= eing able to show that the responses that a service worker reads are 'v= erified' would be a good first step somehow.

T= he ability to have longer term signatures would also be key for the archiva= l use case. Could the client browser create counter-signatures itself?
For the archiving use case, being able to prove that the exchange hap= pened 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 ha= d its own certificate and keys..

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

Thanks,
Ilya


On Fri, Oct 11, 2019 at = 12:40 PM Jeffrey Yasskin <jyasskin@google.com> wrote:
https://wab.ac/ looks like an awesome tool. I susp= ect it can't provide isolation between the javascript storage used by d= ifferent WARC files. We plan to do something for that in the bundle format = for unsigned/untrusted content.=C2=A0Sawood Alam also suggested being able = to pretend the archive is being run at a particular time, which seems sensi= ble but is currently low priority.

The remaining difficu= lty we've noticed in verifying that the content is accurate is that Sig= ned Exchange signatures expire in a short amount of time, because we don= 9;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&= #39;t expect web server operators to be able to keep a private key secret f= or multiple years. So you need a system of timestamping servers, and a cont= iguous chain of their (counter-)signatures back to the original server sign= ature. Signed Exchanges don't currently support counter-signatures well= , but that's something that could be added. I wouldn't expect brows= ers' UI teams to decide that chain of trust is worth showing in the UI,= although I could always be surprised.

Would you mind ha= ving this conversation on the wpack@ietf.org list=C2=A0so more people ca= n see your interest and can chime in?

I unfo= rtunately won't be at the Chrome Dev Summit. I'll be at the WPACK B= oF the next week in Singapore:=C2=A0https://trac.tools.ietf.org/bof/trac= /wiki#WPACK.

Jeffrey

On Fri, Oct 11, 2019= at 11:12 AM Ilya Kreymer <ikreymer@gmail.com> wrote:
Hi Jeffrey,

I wanted to reach out to you regarding the archival use case for web pac= kaging 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 archive= s,
verification that the content is authentic and was actually se= rved by the web server is imperative, and for this reason I'm very inte= rested in the signed exchange efforts.
Like most other web archiv= ing 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 w= orkers. 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-o= f-concept of browser support for WARC files, as mentioned in=C2=A0https://wicg.github.io/webpackage/d= raft-yasskin-webpackage-use-cases.html#rfc.section.2.2.9

=
Here are some example link which=C2=A0load a WARC from github pa= ges and redirect to rendered page:
https://wab.ac/?coll_example=3Dexamples/netpreser= ve-twitter.warc&url=3D/example/https://twitter.com/netpreserve

This should allow for rendering of any web archive dir= ectly 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 i= n SF, and applied to attend the Chrome Dev Summit in November, in case you&= #39;ll be here then.

Thank you,
Ilya



--00000000000091c7b0059538ade8-- From nobody Fri Oct 25 14:16:28 2019 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D86241209D6; Fri, 25 Oct 2019 14:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: wpack@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793088.2724.10883581930442832.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:10 -0700 Archived-At: Subject: [Wpack] wpack - Requested session has been scheduled for IETF 106 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:22 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. wpack Session 1 (1:30 requested) Wednesday, 20 November 2019, Afternoon Session II 1520-1650 Room Name: Collyer size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/wpack.ics Request Information: --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: Technology Overlap: httpbis quic dispatch secdispatch saag tls acme People who must be present: Alexey Melnikov Resources Requested: Special Requests: Please do not schedule on Monday morning. ---------------------------------------------------------