Web Packaging Breakout -- 24 Oct 2018

<scribe> scribe: falken

<Ralph> https://www.w3.org/wiki/TPAC/2018/SessionIdeas#Web_Packaging:_concept.2C_use_cases_and_Fetch_spec

[agenda is being presented]

[proposal to do self-introductions]

<kinuko> Agenda: quick intro, spec overview: https://docs.google.com/presentation/d/1FMzlFX5NEYr0It7P_QqxdOgkRgNL4rY8nIoo53MV9GY/edit#slide=id.p

Agenda

<kinuko> Agenda: Use cases sharing & review

[self-introductions]

kinuko: people from publishing, performance are here
... let's start with spec/use case/intro

<bigbluehat> https://docs.google.com/presentation/d/1FMzlFX5NEYr0It7P_QqxdOgkRgNL4rY8nIoo53MV9GY/edit#slide=id.p

kinuko: use case: sharing a website with your peer/colleague
... you can share a URL/link though it might not work depending on connectivity/server/etc
... what if we can share an actual website
... maybe we can install PWAs offline. enable offline/reliable loading of web content
... or easily share with friends
... think also the other way around. want to publish content on your website
... but your server is not good.
... what if you can share that content with multiple servers so it can be safely redistributed
... this is partially possible with CDNs
... but you need to give TLS private key to CDNs or else your site needs to be part of another site
... WebPackaging is not a single spec. umbrella concept
... one fundamantal component is Signed Exchange
... single http request response that is digitally signed
... on top of SE we have Bundled Exchange
... a bundle of exchanges. signed or not
... a website usually has multiple resources
... if you want to create a package for your website, you're probably going to bundle
... finally Loading
... Loading will be integrated into the Fetch spec. maybe
... let's talk about Signed Exchange
... has a request url and response payload. comes with a signature
... signature has cert information and time range. so it can expire
... has digest header info. browser can also verify the contents have not been modified from the original
... there is an outer URL and an inner URL (original article)
... browser makes internal relay to the inner URL after verifying everything
... after that point loading just looks like regular HTTP loading

<edent> +q to mention "What's the user interface for this? How does a user share a page - or load a page?"

kinuko: let's talk about privacy preserving
... there is a performance vs privacy tradeoff for prefetching resources today
... with web packaging, the resource can be safely cached on servers. can be safely prefetching without talking to the original source
... the resource can still be loaded as if it came from the original source.

TerranceEden: question about the User Interface
... as a user how do I share one of these packaged things, and how do i receive it, use it

kinuko: for creating packaging side, we're not expecting regular users will create one. you need a private cert key, and sign web content. but there's a set of tools on GitHub for doing it

<Zakim> edent, you wanted to mention "What's the user interface for this? How does a user share a page - or load a page?"

kinuko: including a readme
... regarding consuming content. when the browser loads the package...
... we aren't currently planning to add special UI about it vs normal loading

rbyers: lesson we learned... users shouldn't have to care about how the bits got to the them
... tls mixes two bits of information... confusing

dauwhe: question about. i created a package. put it on my usb stick. give it to you and you can double click and runs in browser?

kinuko: yes thinking about it

[+1s]

dauwhe: yes would like that

kinuko: may need modifications to the spec regarding offline
... but yes we want to address the use case

kouhei: explaning certificates...
... [scribe missed it but it allows offline loading]

rbyers: security tradeoffs... accidentally ship XSS vuln in your site... don't want it to be something someone can load forever
... chrome has a two week timeout currently

kinuko: timeout for how long SXE is verified as valid
... one week

??: timestamp means browser can...

kinuko: cache the signature. url to the cert... browser does verification normally. but if nothing changed browser can just load it.

??: certificate request can affect performance?

kinuko: cert can be separately cached. can be tuned
... signature and SXE have a URL to cert chain.
... the cert chain can be fetched really early. and cached
... caching involves tradeoff with security.

LeonardR: not targeting long-life packages?
... no model for using it as an archive

kinuko: think it's possible
... but current spec doesn't allow it explicitly
... some ideas... say the signed exchange can be loaded in a specific time setting.

rbyers: higher level principle... if package can act as if it's the origin... access cookies etc... need to verify the package is still valid within a one week window...

leonardr_: package is valid or signature is valid?
... intl standards for long term validation of signatures
... is there a design decision

rbyers: currently chrome doesn't honor expiry time beyond 7 days
... may be reasonable to have some UI about "you can view this archived package" but it doesn't have the power of proving you are foo.com
... fundamental change to secutriyy of the web so want to be conservative
... 7 days is written in the spec

kinuko: in that sense, it's the current design decision
... we'll keep exploring possibilities of this space

[let's do the last slide]

kinuko: current impl status: chrome implemented a subset of SXE
... there's an implementation snapshot draft
... working closely with Google Search and AMP team
... as well as ??? publishers for privacy preserving prefetch
... publisher page created as AMP shown on publisher's site can have the publisher's URL as first-party content
... so looks like a regular navigation and loads very fast
... we'll run an Origin Trial experiment so anyone can try it

Ralph: very interesting approach. caching at http level
... tension between doing something that's sufficiently secure so one origin can trust another to speak on its behalf.
... in order to do that we need cert revokation and don't want USB stick with XSS bug in it forever etc
... other end that Leonard identified... that we do want to create something that does last for decades, for human generations
... what's your thinking about that other end of the spectrum
... other part of the question
... in some cases the origin still wants to know that the resource was accessed

kinuko: regarding first question
... most of the answer is... yes we're not yet really clear on the long-end of the spectrum
... long lasting sxe can be very interesting for archival purpose...
... probably would need to make a very explicit restriction... and spec it... eg... resource loaded in that mode cannot access the same storage of the origin...

rbyers: turn it back and ask you. in the long lived cases, is it important that that thing still be treated as the same-origin?
... or is it ok to treat it as an opaque origin

Ralph: expect the use cases are that it doesn't really matter who the original origin was

rbyers: can imagine UI in the browser that says "this package claims to be foo.com" but doesn't have a green lock etc

<dmurph> +q

Ralph: but the security scenarios are based on TLS mechanisms... not clear to me how you resolve that connection between TLS style revocation and century long durations

leonardr_: contexts...
... big diff in execution of content

rbyers: meant like anonymous https origin

<dmurph> https*

[as opposed to file:/// origin]

Ralph: [scribe missed this]

kinuko: let me answer...
... when the browser gets a resource that is just fetched from cache...
... ?Qingqian ... main resource case, there can be javascript there...

Ralph: at application level, you expect app to put something in the package to cause a pingback

rbyers: yes the model today. analytics scripts...

<Zakim> Ralph, you wanted to ask about the opposite of privacy-preserving prefetch

florian: as far as I know, apart from this...
... most proposals boil down to files in a zip file
... this is not... this is offlining http
... that sounds awesome...
... haven't looked into the way you're doing it
... i want to use this as an e-book format
... the publishing community has been making e-books...
... trying to make the a first class citizen of the web
... can click on it as if it were a site
... main point: how do you make sure that the publishing community is involved in the work you're doing, to ensure you solve their use case...

kinuko: great comment...
... been discussing this in the github repository
... discussing in IETF, TPAC...
... would be good to form some working group with periodic face-to-face/VC...

florian: some part of the work is in IETF... do you intend to keep it there?

kinuko: formats will remain in IETF... while application part, how we load in browser... we can discuss with this group of people

<Ralph> GitHub repo for Yasskin Web Packaging

florian: can we have a community group where we both do the part that should be done in W3C and organize with IETF...

<bigbluehat> closest current issue to publishing's needs (fwiw): https://github.com/WICG/webpackage/issues/105

florian: and eventually turns to WG?

yoav: just wanted to say.... all of this in incubated in WICG open in github... everyone is more than welcome
... this would be a first step before forming a WG
... afterwords sure we can form something...

florian: large chunk is in IETF
... people at TPAC are not all following IETF. maybe need help with IETF

rbyers: draft of the spec is in WICG
... the commits are going in WICG on GitHub

<dauwhe> s/YCG/WICG/

rbyers: available in an origin trial. trry it out. give us feedback

<wseltzer> https://github.com/WICG/webpackage

rbyers: let's do engineering in public. all open source

yves: WICG would be good to [missed this]

JakeA: publishing use case...
... how much does it matter for you that the resulting package has the same origin that created it
... always an anon origin would break the use case?

florian: it depends... for example a novel would be fine to be an anon origin probably... but for a periodical with multiple publications it may not be fine
... updatable publications

kouhei: follow up on updte checking. we have ?? URL. which allows SXE to check that URL and check if there's a newer version of the SXE or not
... would love feedback on this

florian: experiment would be complicated. have to experiment with business models at the same time. considering service worker which checks the origin.

<Zakim> wseltzer, you wanted to discuss security and usability and to discuss fallbacks

florian: not sure if people will do this as a business model. space to explore

wseltzer from W3C we're tracking this and interested in this

scribe: help people find WICG issues...

<rbyers> https://github.com/WICG/webpackage

scribe: you can reach out for help in doing that...
... question: what's the fallback when signatures expire?
... user gets no access? or anonymous access?

kinuko: fallback URL...
... if verification/parsing fails.. the browser can redirect to the fallback URL which can have content

wseltzer: the scary thing to me as a reader would be expiring stuff causes the content to disappear

kinuko: mechanism called validity URL

rbyers: priority scenario right now is the privacy preserving prefetch case
... making load instant
... in that model, if package is invalid... it's just a perf optimization loss..

&&: what is the plan for content negotiation

<Zakim> jose-cdbtr, you wanted to ask about conneg

scribe: languages...

kinuko: two level content negotiation. when site should return signed exchange... application/signed-exhcnge content type
... the reason we have both request header and response header in SXE is so we can do dynamic content negotiation in the bundle case... to get the apprioriate resource for that client...
... that part isn't really nailed down yet

<Zakim> edent, you wanted to mention "Fake news and revocation."

edent: chat with the UK national archives... very interested in long term preservation of web content
... question about fake news...
... UK gov we publish documents and say this is definitely published by ministry of transport, etc...
... we wouldn't allow a future admininstation to revoke that
... can you do that here... expire but not revoke?
... dont need an answer but it's a use case to think about

kinuko: been discussing this...

rbyers: when you create the package it's crypto proof that it was signed by this entity...
... cant destroy that...
... q is what's the user experience of loading that past it's expiry date
... today in chrome we load fallback url
... that wouldn't meet this use case... can make a change for that use case

<Zakim> Ralph, you wanted to ask DSinger if he can brief the prior work that he mentioned during his intro

kouhei: for long-term... we really agree in its usefulness.. but dont have answers now... love more participation/feedback

dsinger: introduction of new thing...

HEIF image format

dsinger: a while back MPEG worked on an image format
... original motiviation was compressed images
... we designed a solution for storing images of any kind
... could be used for any resources
... concept of an 'item'
... can have multiple items in a file
... save space in the file
... items can have typed refs to other items. can do runtime derivation
... example: 9x9 grid derivation with 81 refs to other images
... got attention of image community
... but they prefered better compat over better compression
... actually getting traction now
... shipping in mac, android, windows...
... MPEG also wanted to represent web packaging with media resource
... situation like i want to download html resource which has two frames
... one is the professor delivering a lecture, one is slides
... proposal is to use this item storage
... put them all in the same file
... can have triggers to display the right slide at the right time
... general abstraction of items associated with properties linked to other items...
... vision at MPEG is if you do packaging of web resources... assume same oriign...
... but combining this with webpackaging raises all sorts of intersting possiblities

<Zakim> dsinger, you wanted to ask if we have time to shift a little and introduce HEIF and mpeg-packaging

JakeA: whats the license

dsinger: encoding in heavily encumbered......

[talk about licenses etc]

s/oriigin/origin

[breakout session end. please raise issues in the GitHub issue]

<wseltzer> David's presentation on HEIF

- DRAFT -

Web Packaging Breakout

24 Oct 2018

Attendees

Contents

Agenda

HEIF image format

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output