15:49:40 RRSAgent has joined #pwg 15:49:40 logging to http://www.w3.org/2017/09/11-pwg-irc 15:49:41 rrsagent, set log public 15:49:41 Meeting: Publishing Working Group Telco 15:49:41 Chair: Garth 15:49:41 Date: 2017-09-11 15:49:41 Regrets+ rrkwright, pkra, cristina, makoto 15:49:41 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2017Sep/0017.html 15:49:42 ivan has changed the topic to: Meeting Agenda 2017-09-11: https://lists.w3.org/Archives/Public/public-publ-wg/2017Sep/0017.html 15:53:13 Avneesh has joined #pwg 15:55:47 present+ dauwhe 15:55:52 irccloud 15:56:00 present+ 15:56:16 present+ wolfgang 15:56:32 present+ 15:58:18 jeffp has joined #pwg 15:58:28 BenSchroeter has joined #pwg 15:58:48 NickRuffilo has joined #PWG 15:58:57 scribenick: NickRuffilo 15:59:19 present+ NickRuffilo 15:59:25 jun_gamo has joined #pwg 15:59:32 present+ Avneesh 15:59:34 present+ Chris_Maden 15:59:40 present+ 15:59:53 present+ lsullam 16:00:00 lsullam has joined #pwg 16:00:02 dkaplan3 has joined #pwg 16:00:04 Zakim, who is here? 16:00:04 Present: dauwhe, ivan, wolfgang, tzviya, NickRuffilo, Avneesh, Chris_Maden, jun_gamo, lsullam 16:00:05 present+ jun_gamo 16:00:06 On IRC I see dkaplan3, lsullam, jun_gamo, NickRuffilo, BenSchroeter, jeffp, Avneesh, RRSAgent, Zakim, ivan, rdeltour, wolfgang, cmaden2, mattg, tzviya, dauwhe, Karen, plinss, 16:00:06 ... jyasskin, github-bot, bigbluehat, ShaneM, astearns 16:00:15 present+ 16:00:22 timCole has joined #pwg 16:00:22 present+ 16:00:30 Jeff - dial in or use the gotomeeting? 16:00:34 baldurbjarnason has joined #pwg 16:00:34 present+ 16:00:35 present+ 16:00:36 present+ Tim_Cole 16:00:44 present+ 16:01:07 present+ 16:01:19 rachel has joined #pwg 16:01:42 wseltzer has joined #pwg 16:01:42 present+ wendyreid 16:01:48 present+ vlad 16:01:49 present+ 16:02:05 present+ rdeltour 16:02:36 guest+ Ralph_Swick 16:02:41 Ivan: "We have at least one new member on the call - i think - Wendy. " 16:02:44 clapierre has joined #pwg 16:02:50 Tzviya: "Welcome wendy, please take a minute to introduce yourself." 16:02:55 present+ 16:03:04 laurentlemeur has joined #pwg 16:03:12 present+ 16:03:16 Wendy: "My name is wendy reed, I'm a QA analyst and Kobo. I also have a side-interest in content rendering, so I have an interest in that as well." 16:03:17 present+ Laurent 16:03:32 Ivan: "We have Ralph as a guest." 16:04:06 Ralph has joined #pwg 16:04:12 Bill_Kasdorf has joined #pwg 16:04:19 present+ 16:04:24 George has joined #pwg 16:04:28 topic: minutes approval 16:04:31 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-08-28-minutes 16:04:33 presnet+ RalphSwick(guest) 16:04:42 present+ George 16:04:43 present+ RalphSwick(guest) 16:04:44 Tzviya: Lets move on to approving mintues. Any comments on the minutes from last week? 16:04:46 marisa_demeglio has joined #pwg 16:04:49 s/presnet+ RalphSwick(guest)// 16:04:55 Tzivya: Minutes approved. 16:05:03 resolved: minutes approved 16:05:04 Ivan's mic seems to be feeding back a bit 16:05:10 present+ 16:05:22 present+ 16:05:25 present+ garth 16:05:32 many echoes 16:05:34 Garth Vader: Hopefully you can all hear me... 16:05:40 garth has joined #pwg 16:06:00 guest+ Wendy_Seltzer 16:06:02 present+ Garth 16:06:11 Garth: We have a great... I see people on the IRC. I take it Jeffrey more timely - did he arrive on time? 16:06:14 Jeff: I am here... 16:06:16 Hadrien has joined #pwg 16:06:18 wendyreid has joined #pwg 16:07:44 Web packaging explainer https://github.com/WICG/webpackage/blob/master/explainer.md 16:07:57 Garth: Tzviya is opt to point out, we've spent much time on the first working draft on Web Publications, if you looked at the schedule, we should have the first working draft of the PORTABLE web publication in TPAC time. I've asked a colleague of mine from Google who has been doing work on the web packaging arena - which is a candidate technology - as we look at what packages look like. I'm 16:07:57 introducing Jeffrey Waskin - who's been working on search front end, ..., he's also chaired web-front end group, which lead to working on the chrome platform team... He's just done alot of stuff, so with that, I'd like to have Jeff do an introduction and talk about history and where web packaging is now. 16:08:14 ...: where the constituent pieces are being developed, open up to Q&A then move to next topics. 16:08:15 s/Waskin/Yasskin/ 16:08:36 guest+ Jeffrey_Yassking 16:08:36 s/ing/in/ 16:09:04 ReinaldoFerraz has joined #pwg 16:09:15 https://en.wikipedia.org/wiki/MHTML 16:09:29 Jeff: I've been working on packaging since the beginning of the year. The project came out of our emerging markets - a system might have an expensive or limited data plan - so there is peer-to-peer data sharing. Our team wanted to share web pages in the same way. We're using MHTML as a stop=gap. MHTML is for a single page, not a web-app. Then I came along and took over the standards effort 16:09:29 for that. 16:09:32 https://github.com/WICG/webpackage 16:09:54 duga has joined #pwg 16:09:55 i/many echoes/topic: Web Packaging Work/ 16:10:03 present+ 16:10:38 Vlad has joined #pwg 16:10:41 present+ 16:11:20 ...: I'll be talking over the github repo that I just posted above. This is where incubations for new web APIs happen. A couple people from this group have already made comments. Every change to all of the proposals is happening here. We put together an initial format for the packages and have started trying to shop it around to other implementors to see what people thing. Because it's a 16:11:21 format, and it sits tightly on top of HTTP, i figured i'd involved the IETP as well. I brought it to their meeting in prague and we fleshed out the use cases, and tried to split into two layers... 16:11:42 s/IETP/IETF 16:13:00 q+ 16:13:06 ...: I'll be bringing it back in singapore soon. A way to have a single request/response and how to bundle that. We already have that. For web publications, you will end up with a website that is a publication, so if you stick it in a packaging format, it should just work. We need to figure out the details - such as a set of top-level metadata around the app manifest. Will the metadata fit 16:13:06 into that - if not, we can talk about how to change things. I think thats the overview. Do you want the format itself descripted? it is not final.... 16:13:13 present+ Hadrien 16:13:27 Garth: I would suggest that we go the next level down - handy waving explainer - on the format. 16:13:33 https://github.com/WICG/webpackage/blob/master/explainer.md 16:13:48 harriett has joined #pwg 16:13:51 present+ 16:14:23 http://cbor.io 16:15:29 Jeff: If you're in the github, there is an explainer -and you can look at the proposal or the overall format. The current sketch is that the whole thing will be a CBOR (binary version of JSON with a few extra features) - it has a sequence of features - content and manifest - where the manifest is actually - well we need a different name for that - there's an index of sections pointing to the 16:15:29 offest of the file. There's an index that's pointing at the items. It holds the request headers, and offset, and the length where the response exsists. This all might change based on the IETF discussion. 16:15:44 s/offest/offset/ 16:15:59 q? 16:16:32 https://github.com/WICG/webpackage/blob/master/explainer.md 16:17:30 ...: The request is where the interesting stuff happens. It has a set of signatures and a certificate on how to trust those signatures. Then there is the manifest - which is the app manifest - and a set of hashes of the sub-resources. There can be a set of hashes for each resource. The thing that is hashed is the concatenation of the request headers, the request, and the body. Two of the 16:17:30 three only find the body, the 3rd allows the signer to sign the headers and possibly the URL. I'm expecting the proposal to sign everything. That would allow you to prevent something to be placed at a different URL and you to expect users to trust it. 16:19:04 ...: We also want to consider it similar to a server certificate type, if we cannot do this, we'll try to do a different signing or certificate type. We allow other signers to vouch for the package, so for instance - if your package wants extra permissions beyond general web, you might want someone who has done a static analysis of the contents, then that would let the user trust the contents. 16:19:04 An author might be able to represent themselves, instead of a domain. In addition to whatever domain it's being served from. 16:19:05 q+ 16:20:07 ...: For the security of the signatures, i'm expecting to derive the signature algorithm from the public key - instead of letting the attacker to put in their own key. For people who are pushing systems like Jose where you push the algorithm next to the signautre. I think that's the overview. We do some technical things in order to make it safe to sign with TOS certificates. We use the same 16:20:07 encoding of the bytes that TOS does. 16:21:00 s/TOS/TLS/ 16:21:01 zakim, who is here? 16:21:01 Present: dauwhe, ivan, wolfgang, tzviya, NickRuffilo, Avneesh, Chris_Maden, jun_gamo, lsullam, BenSchroeter, mattg, rdeltour, dkaplan, Tim_Cole, baldurbjarnason, jyasskin, 16:21:05 ... wendyreid, vlad, rachel, bigbluehat, clapierre, Laurent, Bill_Kasdorf, George, RalphSwick(guest), marisa_demeglio, jeffp, garth, duga, Hadrien, harriett 16:21:05 On IRC I see harriett, Vlad, duga, ReinaldoFerraz, wendyreid, Hadrien, garth, marisa_demeglio, George, Bill_Kasdorf, Ralph, laurentlemeur, clapierre, wseltzer, rachel, 16:21:08 ... baldurbjarnason, timCole, dkaplan3, lsullam, jun_gamo, NickRuffilo, BenSchroeter, jeffp, Avneesh, RRSAgent, Zakim, ivan, rdeltour, wolfgang, cmaden2, mattg, tzviya, dauwhe, 16:21:08 ... Karen, plinss, jyasskin, github-bot, bigbluehat, ShaneM, astearns 16:21:22 present+ ReinaldoFerraz 16:21:40 q? 16:21:42 present+ david_stroop 16:21:51 ...: We're going to have some mechanisms for sub-packages. It might also require you load an iFrame from a different origin, so you'd need to embed their certificate. that part of the format is the least nailed down. i expect you'll just stick the resource next to your own resource. There would be a tree of sub-packages living somewhere in the main package. We have to defend against downgrade 16:21:51 attempts on sub-packages. You might need to get the latest sub-packages. You might request that sub-packages have a specific hash or "not before" which might allow others to combine packages with yours. You would then just include a hash. 16:21:59 present+ mattg 16:22:26 ...: We've talked about external sub-packages, where you include a link to the sub-packages. Electron developers are excited as you can include a link to electron itself, so you would not have the user re-download electron if they already have it. 16:22:36 q+ 16:23:18 david_stroup has joined #pwg 16:23:27 Garth: There are a few on the queue, but here are a few questions that I think epople would like more details on. In the classic digital pub, we have epub - which is a static set of content zipped up. What drove to the overall approach of a request/response instead of a zip. What drove to this architecture? 16:24:59 present+ 16:25:01 q+ 16:25:24 Jeff: The two big qs? "Why not zip" -> security vulnerabilities, and each file is identified two different ways. You can have two copies, and the index at the end tells you what to use - one is security, and one is performance. There was an android attach called the master key invulnerability. Once piece was verifying based off different sets of keys. One could require implementations to get 16:25:24 it right, but better not to have it. Having the index at the end of the file means you cannot stream it - so you have to load the entire file first. Some of the usecases would much rather have the browser load resources as they come - or maybe truncate and see what the browser asks for. 16:26:12 ...: We're also indexing by URL and request headers, rather than filename - zip is filenames to file contents - in order to handle the web, you would need to handle all the request headers somewhere in the filename. Or pair the request headers with the body - all of this is doable, but made zip a non-natural fit. 16:26:29 Garth: Maybe 2-3 sentences on where you are now with the IETF, what's likely at the W3c... 16:27:46 q? 16:28:09 q+ to ask about deep linking 16:28:10 Jeff: "The IETF - following their suggestions - there maybe 2-3 pieces of the web packaging proposal. The first is signed request/response pairs. The second is bundles of request/response pairs. That may happen at the IETF. The 3rd piece is a description of how web browsers load the package - which will happen at the W3C. I have the beginning of a sketch on how that would look but it's probably 16:28:10 not worth looking at yet. We will need a specification on how to load the pages. In singapore in november, we will present again. There has not been too much response to the latest email post. 16:28:22 q? 16:28:40 ack Hadrien 16:29:10 q- 16:30:01 Hadrien: "Two questions - as you said, the design is very different from zip, as it has to package resources on the web. We have two use-cases, one for content on the web, and the other is to distribute a package that is not on the web. Are there any thoughts on what can work for the non-web use-case? The package is supposed to work like the web - but i'm wondering on the client side, is this 16:30:01 supposed to work without explicit support from the browsers? Can this work with existing technologies - behaviour should be like a proxy, no? 16:31:02 DPUB IG Use Cases and Reqs https://www.w3.org/TR/pwp-ucr/ (input doc for this group) 16:32:01 JefF: Taking your questions in order, I have not thought about how to use this for publications that do not exist on the web. If you have examples of a publication that you'd want to do package that doesn't exist as a website, I'd be interested in seeing it. It isn't my top priority, but it would be good to have. The second question [repeated question - on client side how do you implement] - 16:32:01 the obvious way is to build a service worker, and then inject it into the service worker cache. That does 95% of the package. What can never be poly-filled is installing the service worker to begin with. If you are offline, there is no way to get a trusted service worker - so that is one way where a signed signle response could replace the standard web packaged format... 16:33:25 q? 16:33:29 ...: You could then also load the package that way and initialize the service worker cache. Some people in the chrome working team want us to represent all packages this way. When you open a package is it part of the network layer - where the browser makes request and so the package layer makes the requests, or do we represent it as a way to bootstrap a service worker - that installs - then it 16:33:29 gets an event saying 'heres your package'. We could polyfill the package loading in a service worker - saying 'do this service worker, then load packages' we'll do that to test the format, but it's not done yet. 16:34:32 ...: As for clients - non-browser clients are not my top priority. It will certainly be possible to unpackage a package. In the github, there is a go program that can package and unpackage things - so it's straightforward to package/unpackage. That way we can fuzz it and everyone who is loading packages has a trustworthy way to do it. That's what non-browsers will have to do. 16:34:36 s/heres/here is/ 16:34:53 q? 16:34:55 Hadrien: In that case you'd need to rewrite the request or how things are loaded - the URIs... 16:35:40 Jeff: It would need to respond to the request using stuff from the package. One thing I need to standardize is that - given a browser request and a package request, how can they be the same. That should be part of the library we build. When you build a package, you pull a set of requests out. When you need to provide a resource, you look at the cache. 16:36:10 Hadrien: In a way, it would work like the cache layer of the browser, but if you're using a webview, it would be very difficult to go between a web-view and the web. Most dedicated reading systems use a web-view. 16:36:49 Jeff: I'm not intimately familiar with the web-view APIs. In android you might be able to use a service worker inside the web-view to be the proxy. In iOS i'm not sure what resources you have. You migth have to re-write everything to use these... 16:37:21 q? 16:37:34 Garth: Jeffrey, an example of a publication that doesn't live on the web - i'm happy to send you an epub - as any of them will fit. 16:37:34 ack NickRuffilo 16:37:38 q? 16:38:28 Nick: signing with URL might cause peer-to-peer issues? 16:39:46 Jeff: Saving a file for offline use - could create a non-signed package - with some notes saying: 'this is not trusted'. The signed one would require that the original site to sign the package, and then allow the user to download and share that newly signed package. In that case, you're getting content that is a message through the original source -> one way hops. 16:39:54 q? 16:40:34 Jeff: Each package has a physical and a logical URL. The physical is where you get it, the logical is where it is signed as. 16:40:47 ack ivan 16:41:05 s/package/resource within a package/ 16:42:00 Ivan: My worries is that the way these things are deployed as that people who are not closed to the system, there is a close reliance on certificates. It is ... the whole user interface of the managment of certificates is poor. We have self-publishers who create a book and put it up on some providers website - I don't see how they would be able to do all the signature stuff because they have no 16:42:00 access to these things. 16:43:34 Jeff: There are two answers - one is that the author could get their own domain, get a cert for that, and hand the signed book to the publisher as a unit. Because of how the package is designed, the publisher can send subsets of a package to a reader. The second option is the author could send the content to the publisher and the publisher signs the content... 16:43:43 Ivan feedback again 16:43:44 q- 16:44:15 Jeff: We will need to help teach people how to prepare files - but there will be straightforward ways to get things done. 16:44:29 +1 to Ivan 16:44:41 Ivan: There is need for a more straightforward way for generating certificates. That may become a major hurdle in deploying these things. 16:44:54 Jeff: I expect that some web servers will build these things in 16:45:05 +q could you have a non-signed package? 16:45:09 I would envision normal people to author documents, e.g. a teacher in a school prepares a document for the students. The complexity would be a big issue. 16:45:32 q? 16:45:38 Ralph: you answered my first question: How "friendly" are this specification and Service Workers? 16:46:04 Ralph: can a single package be served to different URIs? 16:46:12 q? 16:46:16 ack Ralph 16:46:17 An official signature typically has to be paid for which would be a restriction for potential authors and small publishers 16:46:30 Ralph: My second question is a variant of the question Nick asked - if i want to serve a file at vastly differnet URIs, how difficult is that. Or would the logical/physical matter here. 16:46:50 s/differnet/different/ 16:47:35 zakim, who is here? 16:47:35 Present: dauwhe, ivan, wolfgang, tzviya, NickRuffilo, Avneesh, Chris_Maden, jun_gamo, lsullam, BenSchroeter, mattg, rdeltour, dkaplan, Tim_Cole, baldurbjarnason, jyasskin, 16:47:38 ... wendyreid, vlad, rachel, bigbluehat, clapierre, Laurent, Bill_Kasdorf, George, RalphSwick(guest), marisa_demeglio, jeffp, garth, duga, Hadrien, harriett, ReinaldoFerraz, 16:47:38 ... david_stroop 16:47:38 On IRC I see david_stroup, harriett, Vlad, duga, ReinaldoFerraz, wendyreid, Hadrien, garth, marisa_demeglio, George, Bill_Kasdorf, Ralph, laurentlemeur, clapierre, wseltzer, 16:47:39 q+ 16:47:42 ... rachel, baldurbjarnason, timCole, dkaplan3, lsullam, jun_gamo, NickRuffilo, BenSchroeter, jeffp, Avneesh, RRSAgent, Zakim, ivan, rdeltour, wolfgang, cmaden2, mattg, tzviya, 16:47:42 ... dauwhe, plinss, jyasskin, github-bot, bigbluehat, ShaneM, astearns 16:48:09 JefF: For service workers - were considering adding a service worker event about getting the package and adding it to the cache. The package can certainly be served from different URIs, the interesting question is - can a package say that a resource could be service from any of these 5 logical URIs. You could index the same URI different times with different request headers. You would then need 16:48:09 to have different certificates... We haven't thought through the reasons or how to do it for having multiple locations. 16:48:31 q? 16:48:32 Garth: I want the last 5-10 minutes to dish out guilt, so lets take hadrien's question and that be the end of this topic todya. 16:49:01 Hadrien: You mentioned that the chrome team might use service workers. Will chrome or other browsers ship with a default service worker or default network policy? That would make it possible for packages to work.... 16:49:59 Jeff: That's one of the proposals that our loading team has suggested, that we'll provide a default service worker for packages. Then none of the rest of the browser has to change. I don't like that - i prefer service workers be under the control of the origin. We could write something that people could use, but it makes me 'icky' to say that we're going to give a service worker to an origin 16:49:59 that hasn't asked for one. 16:50:16 Hadrien: so to get support for packages, we would need to write a service worker. 16:50:44 having to write a service worker is a hard job for a team used to publishing in epub format! 16:50:55 Jeff: Assuming we build service workers in a browser, you won't need one. But, the loading team is that we might require it. If we do packages in the browser, we should just load the package. If the user has visited the packages, then they have the resources within it. 16:50:55 q? 16:50:59 ack Hadrien 16:51:06 Hadrien: You want native support then in the browsers? 16:51:07 Jeff: Yes 16:51:49 Note https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html#rfc.section.2.2.1 that includes WP specific use cases 16:51:56 Garth: Thank you Jeffrey for spending time with us, we will thing more seriously about our web package related efforts. We will invite you back. I'm going to turn it over to Tzviya. There is an agenda item with Luke and Baldur - do we want to discuss? 16:51:59 https://github.com/w3c/wpub/pull/64 16:51:59 Thanks for having me, and please file issues in https://github.com/WICG/webpackage! 16:52:19 Tzviya: Baldur put in a pull request over the weekend. We can get to work on that over at Github. Lets review that and we can review next week. 16:52:20 If anyone is interested in the idea of offline packaging of the web for developing countries, this is an interesting article about the Cuban sneakernet: https://www.theguardian.com/world/2014/dec/23/cuba-offline-internet-weekly-packet-external-hard-drives 16:52:30 many thanks to jyasskin! 16:52:40 i/Garth:/Topic: Guilts in the group.../ 16:52:54 https://w3c.github.io/wpub/ 16:53:39 q+ 16:53:44 Tzviya: The last item mentioned is to review people who offered to write. Lets talk about re-assignment as there are sections that are completely blank. I don't want to point fingers, but lets go to section 5 - we just have headers. Even the name of the section is up for grabs. We need someone to write that section. We have also yet to see anything about security. 16:53:45 ack d 16:54:13 Dave: I wanted to mention that the lifecycle of a manifest, and a manifest supply - it is quite complicated. If we piggyback on the web manifest, that would save lots of copy-paste. 16:54:15 +1 to Dave 16:54:22 Tzviya: I agree dave. 16:54:29 q+ 16:54:40 ack n 16:56:02 Nick: What due dates? 16:56:06 q+ 16:56:11 Tzviya: Need to have the first draft done in the next month 16:56:13 ack iv 16:56:59 Ivan: Nick was not hear the last few weeks - the goal isn't to have a final perfect text - it's more to give a kind of evenly spread document that samples all the directions we have to go. We ahve 2 years to work out the details, but we have to know where we want to go. 16:58:17 Tzviya: I will work with ivan and garth to put together some assignments. In the past this has worked. 16:58:27 q+ 16:58:33 Tzviya: Next week we will hear more on metadata and a mini smile note. 16:58:46 q? 16:58:47 Karen has joined #pwg 16:58:47 ack t 16:58:49 ack timCole 16:59:12 Tim: There's an issue #44 - about how to address locators. I appreciate what people have said there - can we schedule some time to discuss this issue? 16:59:13 Karen has joined #pwg 16:59:18 s/smile/SMIL 16:59:50 Tzviya: We can add it to the agenda, or we can discuss it between. 16:59:58 Tim: I think it will be interesting - can we add it to the agenda. 17:00:17 Garth: Thank you all - great attendance, we'll chat over github and we'll talk next weekend 17:00:20 cmaden2 has left #pwg 17:00:27 jun_gamo has left #pwg 17:00:34 laurentlemeur has left #pwg 17:00:36 rrsagent, draft minutes 17:00:36 I have made the request to generate http://www.w3.org/2017/09/11-pwg-minutes.html ivan 17:00:57 zakim, bye 17:00:58 leaving. As of this point the attendees have been dauwhe, ivan, wolfgang, tzviya, NickRuffilo, Avneesh, Chris_Maden, jun_gamo, lsullam, BenSchroeter, mattg, rdeltour, dkaplan, 17:00:58 Zakim has left #pwg 17:01:01 ... Tim_Cole, baldurbjarnason, jyasskin, wendyreid, vlad, rachel, bigbluehat, clapierre, Laurent, Bill_Kasdorf, George, RalphSwick(guest), marisa_demeglio, jeffp, garth, duga, 17:01:01 ... Hadrien, harriett, ReinaldoFerraz, david_stroop 17:01:04 rrsagent, bye 17:01:04 I see no action items