Meeting minutes
Jake: Motivation for multicast
… [Shows chart]
… Normal day compared to peak day, driven by large downloads
… Difference to peak traffic day is quite stark. Significant impact on user experience
… Everyone is trying to get the same data. An unusual download, happens multiple times per year
… Impacts on web traffic. This example is about downloads
… But also video. Peak traffic days are driven by popular content. When something becomes popular, it adds extra traffic
… The part about web video in particular is large sports
Theo_Olsauskas-Warren: Any insight into the sensitivity of the popular content?
Jake: We don't have perfect insight. It's a very relevant question. A mitigation we've suggested is to disable multicast in private browsing mode
… May not be enough, we'd like more feedback
Jake: Apple have a local network access permission. User prompt for exposing information to the local network
Jake: Sustainability, network energy usage is higher than people realise. Rough estimates. BBC report on 2019 estimate
… There's a guess that we can address a fair bit of this using Multicast
Jake: This is bigger by volume than bitcoin mining
… Another reason to do it is cost to users
… Links in the slides to more information and presentations
Jake: The proposal we're discussing now are adding multicast capability to QUIC
… We have an IETF draft
… It has a security model
… We're working on a demo implementation in the Multicast CG
… It's building on aioquic. Early days, but we think it's practical
… We want to make sure it'll be deployable
Jake: The extension as written is for server to client data
… There's still a unicast connection from client to server
… Multiple servers, need to operate in a coordinated manner
… Shared keying information, is a security challenge
… That would be hard to change without breaking the reasons for doing this
… The server tells the client about the available channels
… The client joins the channel and receives packets
… Acks are similar to multipath acks
… Ordinary QUIC frames. Stream frames are part of the same unicast channel, but they're shared across clients
… Any applications working with the data sees the packets transparently
… We think there's a web API needed, to enable/disable
… Some information shouldn't be carried
… Nonethelesss, we see a worthwhile application for data that's intended to be widely distributed
… Possible gap in security models, in what conditions is it acceptable?
… Extensions to the protocol to add frames for communication about multicast channels
… The client chooses whether to join, a single client/server connection
… Data can be shared across clients. Same stream id for example, so needs coordination among servers
… Some suggestions for better ways to do that
… For serving h3 data, it may require a different spec. With no changes, we can use server push, and WebTransport server-intiated streams
… Those have a client-specific stream id
… The stream frame at the beginning of the packet can be client specific, delivered over unicast
… Bulk of the data transfer then happens over a multicast channel
… Possible for other applications, but those are most relevent
… We expect to work with the WebTransport warp demo for server push of video content
… The big open question for viability is about the security consequences of multicast
… Multicast doesn't have the same deployment experience as unicast
… A few things will be fundamental. The decryption keys must be widely distributed, to each receiver
… A cheap traffic analysis attack code determine what's being carried. Trade off, you no longer have a destination IP that's unique to each receiver
… You don't know who specifically requested the data
… The closer you are to the user, the less k-anonimty you have
… It's not just about the content, but what you know about who's receiving
… I feel there's a threat model gap here, don't know what the consensus would be on this question
… IGMP and MLD for joining, to subscribe to a source group pair
… Source specific multicast, provide source and destination address to the network to get it to deliver traffic
… Device exposes what it wants to receive to the network. So the extent to which your network may be compromised is a factor as well as the sensitivity of the data
… Comparing to W3C privacy criteria, there are some differences
… Not sure if this is a non-starter from the beginning, or if there's a reasonable way to serve this under the web security model
… That's where I'd like thoughts from people, what are the objections likely to be and what can we do about them?
… The need for scalability will be there anyway. Today, ISPs can offer multicast TV services, they control the offering and know who's subscribing and receiving
… Anything that has to be delivered at scale has to be handed off to them for the bulk of the delivery
… Or it gets more expensive and you have fewer users
… Similar question about who gets to know about joining?
… What does it mean for browser adoption?
Theo_Olsauskas-Warren: I'm a privacy person. You talk about transparency at application layer. What kind of UX would make sense for a multicast stream?
… Whatever's in the frame is now public in some way. Work on Fenced Frames
Gendler: Hard to break it down into an easily understandable popup
Theo_Olsauskas-Warren: Needs to be a more heavyweight prompt, like "you're in a movie theatre"
… Browsers have worked hard to develop the security model. Hard to get users to pay attention, so now we propose to punch a hole in that
Jake: What are the concerns about the model?
Gendler: It's a general privacy conversation. Users may not have a clue about what happens beyond requesting what they want
… Cost can be invisible to them. Someone knows you're watching NFL. Possible user harm comes up frequently in privacy conversations
… There's a concept of a privacy tax
Theo_Olsauskas-Warren: What's the failure mode, fall back to paying more for the service?
Gendler: How many businesses will want to maintain two modes, when one is hard enough?
Jake: You need that anyway, as a fallback
… That seems further away than getting to initial adoption
<gendler_> Gendler is Gendler_
Will: How is it different to a VOD video, where you have a key and the service knows you're watching
Jake: It compromises all client connections. If you compromise either side of a TLS connection you can see all the data - but compromising one client doesn't compromise others
… Network analysis attacks, TLS has an appendix that talks about it's vulnerability. It can be defeated, make all your traffic look identical, send same size packets
… So your biggest event looks like the smallest
Will: Netflix report
Jake: You can tell what pages people view via traffic analysis
… More expensive for the network, climate disaster
Nigel: Is there threshold where mutlicast is good and safe enough vs there being too few people locally, so would reveal too much information?
Jake: Good suggestion. If there are guidelines for the k-anonymity on the threshold, seems reasonable
… There's also use cases like video conferencing, a 50 to 1 benefit to the server. But not benefit to the network
… Fewer clients that can be compromised. They may know there's someone on it, but now what's being discussed
Gendler: Anonymity guidelines is an interseting question. If we have guidelines for some providers to use and some not to, e.g., if you have to have a certain size, it's harder for smaller providers
… Potential competition effects
Jake: There's tradeoffs for sure
Theo_Olsauskas-Warren: Plausible deniability is another privacy concept. Is there any space for that?
Jake: Depends where you're looking at the traffic, either in the home, or in upstream networks
… If you have a point at the GMPS
… With unicast, one packet sent is sent to everyone on the same fibre connection, and they're filtered out
Theo_Olsauskas-Warren: Who in this system can know?
… Can tell if it somes from a home gateway devices. MAC address is associated with the one who joined
Theo_Olsauskas-Warren: So the join would need to be fuzzed somehow
Jake: Looking for ways to mitigate? Or document in security model
Theo_Olsauskas-Warren: It's the bottom part where it transitions to consumers I worry about. How to manage the request initially?
Jake: Similar problem with MAC addresses joining wifi APs
… Apple have a MAC randomisation scheme
… Might be able to help defeat log analysis
Theo_Olsauskas-Warren: Sounds like a valuable mitigation
Jake: Does that make it more palatable to browsers?
Theo_Olsauskas-Warren: It's an improvement, but if that gets it where it needs to be I'm not sure
… As a privacy reader, looking at the threat model
Jake: Level of browser interest impacts whether we should deploy it, so looking for input
<gendler_> Theo_Olsauskas-Warren is Theo from Google, last name unknown (by me)
Jake: It seems it doesn't sound like a non-starter from a privacy perspective?
Theo_Olsauskas-Warren: Important to distinguish privacy from security. Someone else from Chrome in security may have a different view
… Whether this walks us back from other security UX fronts, I'm not sure. An example is HTTPS, we've trained users to care about recognising secure connections in the address bar
Jake: We had early feedback from the Chromium netdev team
… Does this violate the promise provided by the lock icon, if someone else has the same key?
Nigel: You still know you've received what was sent
… Is there no return path, so no way for client to send data back?
Jake: No, it's only used for server to client data, no peer to peer
Jake: Is there a definition of what the lock icon guarantees?
Nigel: Firefox says secure, and certificate used for the HTTPS connection is validated
Theo_Olsauskas-Warren: In Chrome, it means your information is private
Greg_Kellogg: Any system like this would need to maintain both a private connection and a multicast connection. There would need to be a connection back to the server for lower bandwidth events
… The lock icon indicates I know who i'm talking to
… Indicate you can't reveal anything, others can't tell you're receiving
Jake: Thank you for helpful comments, please send anything else you think of