14:06:43 RRSAgent has joined #multicast 14:06:43 logging to https://www.w3.org/2022/09/14-multicast-irc 14:06:45 Zakim has joined #multicast 14:11:30 Meeting: Multicast - TPAC 2022 breakout 14:11:34 Chair: Jake_Holland 14:11:36 Agenda: https://www.w3.org/events/meetings/527d52eb-f8df-4875-844b-09a27a67d772#agenda 14:11:38 RRSAgent, make log public 14:11:40 RRSAgent, this meeting spans midnight 14:17:42 RRSAgent, stay 14:17:46 Zakim, stay 14:17:46 I don't understand 'stay', dom 15:14:58 dom has joined #multicast 15:32:04 anssik has joined #multicast 15:43:55 englishm has joined #multicast 16:12:43 agenda+ breakout 17:17:53 jholland has joined #multicast 18:09:39 gendler has joined #multicast 18:09:53 present+ 18:15:49 dom has joined #multicast 18:16:14 tidoust has joined #multicast 18:17:30 masaki has joined #multicast 18:20:05 cpn has joined #multicast 18:20:18 Meeting: Multicast 18:20:21 scribe+ cpn 18:20:51 Jake: Motivation for multicast 18:21:11 ... [Shows chart] 18:21:36 ... Normal day compared to peak day, driven by large downloads 18:22:29 ... Difference to peak traffic day is quite stark. Significant impact on user experience 18:22:55 ... Everyone is trying to get the same data. An unusual download, happens multiple times per year 18:23:15 ... Impacts on web traffic. This example is about downloads 18:23:51 ... But also video. Peak traffic days are driven by popular content. When something becomes popular, it adds extra traffic 18:24:03 ... The part about web video in particular is large sports 18:24:32 Geun-Hyung_Kim has joined #multicast 18:24:40 present+ 18:24:41 @@@: Any insight into the sensitivity of the popular content? 18:25:21 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 18:25:30 ... May not be enough, we'd like more feedback 18:25:42 gendler has joined #multicast 18:27:23 cpn_ has joined #multicast 18:28:39 gendler_ has joined #multicast 18:28:45 scribe+ cpn 18:28:52 scribe+ cpn_ 18:28:58 Jake: Apple have a local network access permission. User prompt for exposing information to the local network 18:29:02 Jake: Sustainability, network energy usage is higher than people realise. Rough estimates. BBC report on 2019 estimate 18:29:06 ... There's a guess that we can address a fair bit of this using Multicast 18:29:09 Jake: This is bigger by volume than bitcoin mining 18:29:33 ... Another reason to do it is cost to users 18:29:50 ... Links in the slides to more information and presentations 18:30:25 Jake: The proposal we're discussing now are adding multicast capability to QUIC 18:30:30 ... We have an IETF draft 18:30:34 ... It has a security model 18:30:45 ... We're working on a demo implementation in the Multicast CG 18:31:01 ... It's building on aioquic. Early days, but we think it's practical 18:31:13 ... We want to make sure it'll be deployable 18:31:15 q? 18:31:34 https://docs.google.com/presentation/d/11dnGTxKtmSbjo8Wc6eR39v7l_8kcHzu84wt3VMh93Oo/edit#slide=id.g152a8dcf135_0_219 18:31:54 Jake: The extension as written is for server to client data 18:32:02 ... There's still a unicast connection from client to server 18:32:16 nigel has joined #multicast 18:32:16 ... Multiple servers, need to operate in a coordinated manner 18:32:28 ... Shared keying information, is a security challenge 18:32:42 ... That would be hard to change without breaking the reasons for doing this 18:32:51 ... The server tells the client about the available channels 18:33:01 ... The client joins the channel and receives packets 18:33:16 ... Acks are similar to multipath acks 18:33:39 ... Ordinary QUIC frames. Stream frames are part of the same unicast channel, but they're shared across clients 18:33:54 ... Any applications working with the data sees the packets transparently 18:34:04 ... We think there's a web API needed, to enable/disable 18:34:17 ... Some information shouldn't be carried 18:34:38 ... Nonethelesss, we see a worthwhile application for data that's intended to be widely distributed 18:34:52 ... Possible gap in security models, in what conditions is it acceptable? 18:35:17 ... Extensions to the protocol to add frames for communication about multicast channels 18:35:38 ... The client chooses whether to join, a single client/server connection 18:35:57 ... Data can be shared across clients. Same stream id for example, so needs coordination among servers 18:36:08 ... Some suggestions for better ways to do that 18:36:43 ... For serving h3 data, it may require a different spec. With no changes, we can use server push, and WebTransport server-intiated streams 18:36:50 ... Those have a client-specific stream id 18:37:15 ... The stream frame at the beginning of the packet can be client specific, delivered over unicast 18:37:24 ... Bulk of the data transfer then happens over a multicast channel 18:37:36 ... Possible for other applications, but those are most relevent 18:37:54 ... We expect to work with the WebTransport warp demo for server push of video content 18:38:17 ... The big open question for viability is about the security consequences of multicast 18:38:28 ... Multicast doesn't have the same deployment experience as unicast 18:39:07 ... A few things will be fundamental. The decryption keys must be widely distributed, to each receiver 18:39:50 ... 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 18:40:01 ... You don't know who specifically requested the data 18:40:15 ... The closer you are to the user, the less k-anonimty you have 18:40:40 ... It's not just about the content, but what you know about who's receiving 18:40:44 hyojin has joined #multicast 18:40:58 ... I feel there's a threat model gap here, don't know what the consensus would be on this question 18:41:22 ... IGMP and MLD for joining, to subscribe to a source group pair 18:41:48 ... Source specific multicast, provide source and destination address to the network to get it to deliver traffic 18:42:23 ... 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 18:42:44 ... Comparing to W3C privacy criteria, there are some differences 18:43:09 ... 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 18:43:37 ... That's where I'd like thoughts from people, what are the objections likely to be and what can we do about them? 18:44:14 ... 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 18:44:35 ... Anything that has to be delivered at scale has to be handed off to them for the bulk of the delivery 18:44:46 ... Or it gets more expensive and you have fewer users 18:45:06 ... Similar question about who gets to know about joining? 18:45:14 ... What does it mean for browser adoption? 18:45:17 q? 18:45:37 seukyoonkang has joined #multicast 18:46:24 @@@: I'm a privacy person. You talk about transparency at application layer. What kind of UX would make sense for a multicast stream? 18:46:52 ... Whatever's in the frame is now public in some way. Work on Fenced Frames 18:47:43 @@@2: Hard to break it down into an easily understandable popup 18:48:03 @@@: Needs to be a more heavyweight prompt, like "you're in a movie theatre" 18:48:30 ... 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 18:48:43 Jake: What are the concerns about the model? 18:49:16 @@@2: It's a general privacy conversation. Users may not have a clue about what happens beyond requesting what they want 18:49:56 ... Cost can be invisible to them. Someone knows you're watching NFL. Possible user harm comes up frequently in privacy conversations 18:50:20 ... There's a concept of a privacy tax 18:50:37 @@@: What's the failure mode, fall back to paying more for the service? 18:51:20 @@@2: How many businesses will want to maintain two modes, when one is hard enough? 18:51:36 Jake: You need that anyway, as a fallback 18:51:53 ... That seems further away than getting to initial adoption 18:52:21 @@@2 is Gendler_ 18:52:26 Will: How is it different to a VOD video, where you have a key and the service knows you're watching 18:53:14 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 18:54:23 ... 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 18:54:37 ... So your biggest event looks like the smallest 18:54:43 Will: Netflix report 18:55:02 Jake: You can tell what pages people view via traffic analysis 18:55:48 ... More expensive for the network, climate disaster 18:56:14 s/@@@2/Gendler/g 18:56:53 Nigel: Is there threshold where mutlicast is good and safe enough vs there being too few people locally, so would reveal too much information? 18:57:22 Jake: Good suggestion. If there are guidelines for the k-anonymity on the threshold, seems reasonable 18:57:51 ... There's also use cases like video conferencing, a 50 to 1 benefit to the server. But not benefit to the network 18:58:43 ... Fewer clients that can be compromised. They may know there's someone on it, but now what's being discussed 19:00:21 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 19:00:39 Present+ 19:00:44 ... Potential competition effects 19:01:00 Jake: There's tradeoffs for sure 19:01:17 @@@: Plausible deniability is another privacy concept. Is there any space for that? 19:02:00 Jake: Depends where you're looking at the traffic, either in the home, or in upstream networks 19:02:12 ... If you have a point at the GMPS 19:02:57 ... With unicast, one packet sent is sent to everyone on the same fibre connection, and they're filtered out 19:03:15 @@@: Who in this system can know? 19:04:09 ... Can tell if it somes from a home gateway devices. MAC address is associated with the one who joined 19:04:23 @@@: So the join would need to be fuzzed somehow 19:05:34 Jake: Looking for ways to mitigate? Or document in security model 19:06:06 @@@: It's the bottom part where it transitions to consumers I worry about. How to manage the request initially? 19:06:28 Jake: Similar problem with MAC addresses joining wifi APs 19:06:40 ... Apple have a MAC randomisation scheme 19:07:08 ... Might be able to help defeat log analysis 19:07:30 @@@: Sounds like a valuable mitigation 19:07:40 Jake: Does that make it more palatable to browsers? 19:07:59 @@@: It's an improvement, but if that gets it where it needs to be I'm not sure 19:08:50 ... As a privacy reader, looking at the threat model 19:09:35 Jake: Level of browser interest impacts whether we should deploy it, so looking for input 19:09:52 @@@ is Theo from Google, last name unknown (by me) 19:10:10 ... It seems it doesn't sound like a non-starter from a privacy perspective? 19:10:46 @@@: Important to distinguish privacy from security. Someone else from Chrome in security may have a different view 19:11:21 ... 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 19:11:52 Jake: We had early feedback from the Chromium netdev team 19:12:40 ... Does this violate the promise provided by the lock icon, if someone else has the same key? 19:12:56 Louay has joined #multicast 19:12:56 Nigel: You still know you've received what was sent 19:13:04 present+ Louay_Bassbouss 19:13:17 ... Is there no return path, so no way for client to send data back? 19:13:32 Jake: No, it's only used for server to client data, no peer to peer 19:14:13 Jake: Is there a definition of what the lock icon guarantees? 19:14:40 Nigel: Firefox says secure, and certificate used for the HTTPS connection is validated 19:14:54 @@@: In Chrome, it means your information is private 19:15:26 @@@3: 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 19:15:40 ... The lock icon indicates I know who i'm talking to 19:16:04 ... Indicate you can't reveal anything, others can't tell you're receiving 19:17:11 Jake: Thank you for helpful comments, please send anything else you think of 19:17:36 s/@@@3/Greg_Kellogg/g 19:18:07 s/@@@/Theo_Olsauskas-Warren/g 19:18:18 rrsagent, draft minutes 19:18:18 I have made the request to generate https://www.w3.org/2022/09/14-multicast-minutes.html cpn_ 19:18:24 rrsagent, make log public 19:20:06 present+ Cyril_Concolato, Greg_Kellogg, heo_Olsauskas-Warren, Max_Gendler 19:20:10 rrsagent, draft minutes 19:20:10 I have made the request to generate https://www.w3.org/2022/09/14-multicast-minutes.html cpn_ 19:20:21 present+ Chris_Needham 19:20:23 rrsagent, draft minutes 19:20:23 I have made the request to generate https://www.w3.org/2022/09/14-multicast-minutes.html cpn_ 19:20:43 present- nigel 19:20:47 Present_ Nigel_Megitt 19:20:59 rrsagent, make minutes 19:20:59 I have made the request to generate https://www.w3.org/2022/09/14-multicast-minutes.html nigel 19:21:28 Present+ Nigel_Megitt 19:21:34 s/Present_ Nigel_Megitt// 19:21:36 rrsagent, make minutes 19:21:36 I have made the request to generate https://www.w3.org/2022/09/14-multicast-minutes.html nigel 19:21:37 jholland has joined #multicast 19:22:35 nigel has joined #multicast 19:24:27 jholland has joined #multicast 19:25:57 cyril has joined #multicast 19:26:03 netflix traffic analysis attack: https://dl.acm.org/doi/abs/10.1145/3029806.3029821 19:26:45 jholland has joined #multicast 19:29:40 nigel has joined #multicast 19:36:46 jholland has joined #multicast 20:15:05 dom has joined #multicast 20:23:00 nigel has joined #multicast 20:24:53 nigel has joined #multicast 20:25:19 jholland has joined #multicast 20:26:54 jholland_ has joined #multicast 20:30:06 jholland has joined #multicast 20:30:10 dom has joined #multicast 21:07:02 dom__ has joined #multicast 21:30:02 jholland has joined #multicast 21:38:53 nigel has joined #multicast 21:47:49 jholland has joined #multicast 21:52:59 dom has joined #multicast 21:54:56 nigel has joined #multicast 21:56:40 jholland has joined #multicast 21:57:32 jholland has joined #multicast 22:03:07 nigel has joined #multicast 22:03:41 nigel has joined #multicast 23:03:17 jholland has joined #multicast 23:04:18 nigel has joined #multicast 23:18:28 jholland has joined #multicast 23:22:25 dom has joined #multicast 23:25:18 nigel has joined #multicast 23:28:25 jholland has joined #multicast 23:29:42 nigel has joined #multicast 23:39:14 jholland has joined #multicast 00:09:42 jholland has joined #multicast 00:28:42 jholland has joined #multicast 00:36:49 nigel has joined #multicast 00:38:18 jholland has joined #multicast 00:39:24 jholland_ has joined #multicast 00:44:06 nigel has joined #multicast 00:50:22 nigel has joined #multicast 00:52:20 nigel has joined #multicast 01:31:10 nigel has joined #multicast 02:46:42 nigel has joined #multicast 14:58:26 anssik has joined #multicast 14:59:51 nigel has joined #multicast 15:01:37 jholland has joined #multicast 15:02:27 jholland has joined #multicast 15:31:25 nigel has joined #multicast 17:04:58 nigel has joined #multicast 17:09:17 nigel has joined #multicast 17:15:51 nigel_ has joined #multicast 17:20:11 nigel_ has joined #multicast 18:02:34 jholland has joined #multicast 18:21:27 jholland has joined #multicast 18:39:28 jholland has joined #multicast 18:56:39 jholland has joined #multicast 19:49:59 nigel has joined #multicast 19:54:20 nigel has joined #multicast 19:56:08 nigel has joined #multicast 20:00:18 nigel has joined #multicast 20:30:36 nigel has joined #multicast 20:39:43 nigel has joined #multicast 20:42:32 nigel has joined #multicast 20:48:33 nigel_ has joined #multicast 21:14:55 dom has joined #multicast 21:26:12 nigel has joined #multicast 21:29:02 nigel_ has joined #multicast 22:01:58 RRSAgent, bye 22:01:58 I see no action items