Jeffrey Yasskin: Slides: https://docs.google.com/presentation/d/15VxWQuh_7keJfeRYkwHhXawI11pv7rIT8CJ09jEmsPo/edit Agenda bashing. Any other topics to cover? I’ve heard a collection of fears about what we are trying to do with web packages. EKR: This isn’t about people thinking that Google is malicious; this is about natural outcomes. Especially, the potential for Google to become the single source for all informations, instead of the origin themselves. Mark Nottingham: The most interesting use is as a kind of proxying on links, which gives more power to people who have a lot of outbound links. It’s a lot of work to get this working, though. So it will mostly benefit people who have a lot of outbound links and the economic incentive to use them. Google, Facebook, Twitter, and a few others. Do we want to enable more power transfer to a few parties on the web? I’m willing to believe that there are other interesting use cases too. Will it take over CDN traffic? Maybe AMP has already had as much effect as it will. I would appreciate if we had more engagement from web publishers (who aren’t in the IETF) to make sure that this respects their position in the ecosystem. What I don’t want is for it to come out and have people be surprised and blame the standards groups.. Jeffrey Yasskin: What’s the right venue for this (not just Google)? Mark: The traditional approach is workshops, e.g. W3C workshops. We could Alex Russell: Do you want to try to address EKR’s specific framing? It expresses a very clear fear about how bits will be transferred and by whom. If you look at AMP and AMP-like things, which do have this strong behavior of causing content to move off of the publisher’s origin. From the W3C TAG perspective, we can’t run the content as if it came from the origin; we have to run it as if it came from the CDN. We can’t do cookies, or autofill, or a lot of other things that are origin-dependent. People who host that content now have a heavy burden of making sure that none of these sub-origins can interfere with each other. That team has put together a very delicate balance. This (web packaging) would make this much easier operationally, which should lower the bar. EKR: I was trying to give you a social answer, not a technical answer. The truth is, this technology exists primarily to support AMP. Alex Russell: That’s not true Mark: I think there’s a lot of discussion around the origin substitution. The contentious part is the part that replaces AMP, which is mostly in Fetch. So if someone decided to start an IETF working group for defining bundles tomorrow, I’m not going to complain about that. It’s the interaction with loading contexts with Fetch where this is worrying. EKR: I don’t think Fetch can safely specify the origin rules here. That needs to happen in HTTP. Sure, if your perspective is that the world has already moved to AMP and we should figure out how to make that better, then I understand, but if this makes AMP more prevalent and featureful then it seems bad. Jeffrey: If we were only replacing AMP, then I agree that this could be harmful. But the goal is to be able to serve non-AMP content the way that we currently serve AMP content. The goal is to allow non-AMP content to use this, so people can not use AMP and still get this benefit. EKR: The technology is not the problem, the problem is that it makes the place that you got the link into the gateway. Alex: There’s a balance today, and the balance has swung heavily toward putting all the complexity on the person rehosting content. Anyone who wants to rebuild that system is really far up a creek, in order to make creating an AMP document really easy. The operational barrier to creating that content is so low that this will actually be higher. But it will greatly lower the barrier to rehosting. Martin Thompson: You can’t do per-user content in something like this, realistically, while maintaining the benefit. Jeffrey: Personalized content isn’t going to be a search result anyway. Martin: Yes, but signed exchanges mean that the page can’t customize after you following the link Jeffrey: unlike AMP, signed exchanges allow the page to use javascript and cookies, so it actually enables customization. Martin: We have almost all of the missing pieces to allow this to happen, but the one missing piece is that first link, if you haven’t been to the site before. If you have been there before, then you can use Service Workers to achieve the same result without needing Signed Exchanges. Jeffrey: What we think we need for privacy is to delay the Fetch event until “load”, which might be long after “prefetch”. ???: OK, so the Service Worker isn’t notified at prefetch, but only when the user actually navigates. Alex: Facebook Instant Articles has a totally proprietary prefetch system. Google loads an iframe in a special mode, so you can get instant load without revealing your interest until you actually navigate. This replaces “preloading into an iframe” with a system that can extend to javascript and other resources that we currently can’t get a crack at early. EKR: I think Mark’s point earlier, which is that I think we do not have the right participants here to have that conversation. Mark: I think we could have a workshop, and it would be interesting to hear what the people who would be affected think about it. I would feel funny if we didn’t at least try that. We could do it jointly with W3C and WHATWG. Martin: There are other costs that come with this. Implementing something like this is nontrivial, and I’d like to know whether there’s interest from more than one party before we invest that effort. Implementing something like this is tricky; there are heavy demons. It’s tractable but it’s a big investment. Mark: I know some of the use cases are interesting for CDNs, but I’d like to know how that would actually be realized. Can I reuse the AMP stuff for integration. Mike Bishop: From the Akamai side: there are multiple use cases. The one that my group is most interested in is the ability to do a cross-origin push, for content for which we are not authoritative, but we have a signed exchange. Jeffrey: You won’t get any cache benefit from that, but otherwise this should totally work. I think Mark was skeptical about the benefits of cross-origin push. Mark: 3rd party content is a well-known hairy thing for CDNs, so a reasonable solution for that would be interesting. Jeffrey: This definitely gets that for you if you don’t care about caching. EKR: We have to worry about the coherency of that cache. You’re basically giving up your ability to invalidate this data. Mark: If a 3rd party gave us a signed exchange for a popular JS widget, and we could serve it from the edge, that would be great. But we need a rendezvous mechanism to let the client know that we can serve it. EKR: If your theory is that we can solve this for jquery by having the CDN cache 9000 different variants of jquery, that’s not going to work. Caching all the images from NYTimes is definitely different from caching web library. That’s what SRI caching is for. Jeffrey: SRI caching doesn’t exist, and it has serious privacy problems: https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html. Yoav: You have a third party widget (like a twitter badge), so you have 10 different H2 connections, so H2 priorities don’t really work, and you end up with bandwidth contention. EKR: This is not really a fleshed-out use case. Is this about a small number of common objects, or something else? There might be better ways to solve the caching of small number of common objects. Mark: It’s attractive because we’ve known about this for a long time, and this solution might actually gain tractoin. Yoab: It’s not about caching; it’s about serving everything over one connection instead of having 30 different connections. Mark: Hallelujah. EKR: Yes, but it also makes the CDN a cache. Dan York: as a publisher with multiple websites, I don’t want to have to make all our sites work with AMP, Facebook ,etc. I want people to be able to get to my content as fast as possible, in whatever way. Especially in countries with (bad?) latency. I want one way to do this instead of having to make my content available in many different ways. Mark: You could already interoperate with many different CDNs easily. What do you want? Dan: as a user, AMP and FIA are a great user experience, but I’d like to be able to get that without having to publish through Google. Alex: There’s another axis here: cost. Right now you’re publishing in multiple formats. Every time you want to redesign, you have to redo the redesign for every one of these output formats (Google, Facebook, Apple). That’s not friendly to anybody. Dan: Yes, and I don’t want to be doing that for different kinds of proprietary things. Mark: Suppose this happens. Will Google have restrictions on package contents (feature policy)? Alex: You have to a feature policy that’s of a certain strength. Martin: Why would you have a feature policy. Alex: We made a bunch of mistakes in the web platform. We don’t get many changes to take them back. One of the best things AMP has done is to remove a bunch of the footguns. Images lazy load, they have to have an aspect-ratio, etc. So you can’t use the image element, and then the validator makes sure that you’re compliant. Martin: This sounds like an intervention thing. Yoav: But this is opt-in. Jeffrey: debatable, if it’s a condition for some aspect of Google listing. Kenji Baheux (Google): Ideally you don’t have to apply any feature policy, because we can tell from metrics (e.g. how often you reflow), we don’t need a policy. The policy is just a way to make things easier. Alex: The argument will be: you have to be fast enough. Joe: The framing of “you have to be this tall to ride the ride” sounds like “I get to control who makes money on the web because…”. Some people feel like their business model is under attack. Yoav: This is basically “you have to not make your users suffer”. Joe: You’re going to get a bunch of reactions that feel like they are outsize because you are attacking someone’s economic model. Dan: Let’s be real: that’s already been defined. If we want to rank highly, site speed matters, HTTPS matters, etc. Joe: Yes, but every new one increases the bar a little bit further. I don’t know what my cost model will be going forward. Will I be able to get enough metrics? Dan: Google continues to send the most traffic to our sites, so there are certain things that we need to do. Martin: There’s a difference between ranking and something that makes pages disappear from a certain spot. Alex: Search was once explained to me as if I could read the whole web and recommend the right page for you. Results should be contextual, based on (among other things) the user’s downlink bandwidth. A page with half a megabyte of JS is not the right page if you’re on a slow link. We don’t do this well now, but we should. Nick Sullivan: Another use case is authenticated web archiving. This would let them have signed data. Martin: So when the certificate expires and the OCSP staples are gone, what are you going to do? Alex: So we can show this in relationship to a point in time. EKR: Evaluating whether a certificate was valid a year ago is a very hard problem. Nick: Put it in a transparency log. EKR: You can build a bunch of crap but it’s nontrivial. Yoav: Another case is Webpack with Web Packaging. EKR: There are bunch of things that are uncontroversial: largely the things that look like packaging up a tarball of same-origin stuff. Modestly controversial: same-origin signing of the entire operation, because it’s hard to evaluate the security of that situation. David Benjamin pointed out that signing oracles could be a problem. Super controversial: origin substitution. I think working on the parts that aren’t controversial is perfectly appropriate (maybe not IETF work though). Same-origin signing is worth some evaluation, depending on how motivated people are by the use cases it enables (as listed on the use cases slide). Right now FF’s DMG is signed, but not signed in connection to some transaction, so we would need to differentiate use cases that don’t actually need the connection to HTTP. The right strategy depends on whether you think this work is worth doing without the cross-origin piece. If not, then we need to deal with that head-on. jeffrey: Our original use case was offline P2P site sharing. EKR: I’m pretty unmotivated by that. I think the shitty bandwidth in third world countries is a temporary problem. Alex: It’s been temporary for billions of people for ten years, so how temporary is it? An example use case is sharing a youtube.com player page. It could be “un-origin’d”, running as a webpage disconnected from everything. EKR: The only time where you need cross-origin signing is where you have never had any contact with the site. If you ever have had contact with the site before, you can use SRI keys. Alex: We should bring the data back showing how much P2P offline sharing we’re seeing. Mark: Is there any UI differentiation for package vs. online? Jeffrey: We don’t see a need for any differentiation. Alex: You won’t get certain headers so it won’t be the same as if you got it across the network, but apart from that it should be the same, modulo security UX review. Jeffrey: So once we’d developed the offline P2P use case, which you could also do by signing a service worker, AMP showed up, and it looked like we could fix some of their problems, especially privacy-preserving prefetch. The order we’ve been going is to do the hard stuff first, to make sure we don’t preclude it. EKR: There’s two kinds of hard: technical and getting agreement. If your incentive structure is AMP or Bust, then we need to have a workshop ASAP. If your attitude is that these other things are good too then we can do things in parallel. Jeffrey: We can definitely do things in parallel, except that there’s only one of me. EKR: I think there’s already some enthusiasm for some sort of unauthenticated bundle structure, although that may not matter as much with H2 and QUIC. Mark: It depends what properties you want. Aside from performance, there are still a lot of interesting use cases. Martin: I can share Jonas Sicking’s long list of reasons he wanted bundling, none of which are perf-related. The cost of pushing something that someone doesn’t need is so high that you’ll be scared away from doing that. Same applies to bundling. Yoav: On the web today, people bundle. This will enable easy un-bundling, serving only the bits that are needed. It’s a tool that is used everywhere, and this will enable it to be used in a less hacky way. Joe: So this will improve the development experience. Martin: Yes, resource-substitution is something that bundling enables and creates some of the same problem, e.g. mutually distrusting actors who can serve different parts of your URL space. “Don’t do that” is a reasonable response, but it does happen. Joe: We can talk about the technical bits Martin: Like what do you do if it contains .well-known, for instance? Jeffrey: There are interestingthings to do with bundling. It’s my second priority, but if other people want to get started, go ahead. For cross-origin signing, I’m hearing concerns reflected from other people, so we should try a workshop to talk to them directly. Martin: Those of us with IAB hats on should talk to those of us with TAG hats on. Jeffrey: FYI, Chrome is planning a trial of subresource integrity, although the details are not quite right yet. No expiration, for example. It should generate some useful data: what properties does it need to have? Do we need header signing? Joe: Action: talk about some sort of workshop Jeffrey: is there anyone who wants to drive bundling? Does the IETF want to drive bundling or should it happen in the W3C…? Mark: It’s a nice standalone document. Martin: Apart from the part that touches the authority of things it references. Mark: I wouldn’t put that in that document. Martin: We would need to involve TAG. Joe: With IAB hat: we can start a mailing list for that, as a service, even if the real standardization happens elsewhere. Jeffrey: It would be helpful to have a mailing list even if we also have a github repo. Alexey: Who should do this? Joe: You should do this. Any objections? Mark: Who will add names? Joe: I will announce the list on relevant IETF mailing lists.