# RTCWEB Minutes IETF95 - Session I Minutes: Mark Nottingham ## 5 min - Welcome & Note Well Barry was thanked in absentia. No agenda bashing. ## 10 min - WG drafts’ status Chairs: ALPN for WEbRTC is moving along. Alissa: I sent comments, but didn't receive a response. Martin: I missed the deadline. You said "yes those changes look fine, please submit." I haven't had an opportunity to do that; will do it now. Alissa: Great. Alissa: A couple of your docs are in publication requested for more than a year; you might want to go over those too. Chairs: We'll come back to those. Chairs: Audio is only hung up on the DTMF questions. Chairs: Data channel is in the RTC Editor Queue with missing references. Fluffy: Much of our stuff is blocked on interlinking references, and will publish all at the same time. E.g., ICE and JSEP. Christian: Regarding the datachannel draft, it falls down to the NCP enddata. WGLC in a couple of weeks. Chairs: The security drafts need some very busy peoples' time to do updates. They say they're almost there, need some tweaks (not rewriting entire drafts). EKR: I'm a bad person. I should work harder. I'm not going to, at least for several months. I don't have time for it. If someone would like to volunteer, that would be helpful; otherwise it'll be around Berlin. Chairs: Sean? Sean: I will volunteer to look at it. Martin: Fluffy asked me to look at identity sections; I'm too close to that, can't see the problems. I need help. Chairs: Ian? Ian: Maybe... Chairs: Ask Martin. Ian: Sure. Chairs: RTP-Usage is in MISSREF, that's not correct. Went back into LC after editorial changes and more. In IETF LC. Should go smoothly, we hope. Chairs: It depends on multistream and multistream optimisation. Chairs: We're up to 20 published RFCs for WebRTC overall; bunch in Last Call. ## 5 min - FEC _Justin Uberti presenting_ ### issue: AMR inband FEC Magnus: It's not included in signalling is because receiver side support is mandatory. The sender can always choose to use it. Justin: Excellent; that means we don't need it. ### issue: max-red Justin: We will not say anything about max-red. Justin: Magnus appears to be the only person who has reviewed the doc in detail; more appreciated. Magnus: About max-red; that doesn't mean you wouldn't like to see redundancy at all; it's a negotiation factor. Justin: Should the author indicate that you don't want max-red at all, or...? Magnus: You might be right, need to think about it. Justin: The doc says that if no value is supplied, it's the sender's discretion. That feels right. If it's zero, we could say don't send, but that's already redundant in some ways. Magnus: Interop with 3GPP, they might use this parameter. Justin: OK, Magnus will go investigate what to do with max-red. Chairs: More reviews would be good. Tim? Tim: Sure. Chairs: Mo? Mo: Sure. Chairs: Bo? Bo: Sure. Varun volunteers as well. ## 20 min - IP-address handling _Justin Uberti presenting_ ### "IP Gathering Permission" EKR: To be clear, this has exactly the same effect? Justin: Yes, except that when gathering permission, we recommend that IP gathering be mentioned. Fluffy: This may be a W3C issue, or even a non-standards issue, I'd be interested to see how this is phrased. If it's like it is now, and it grants a lot about my location, the argument that your video camera is more sensitive than your location, I don't buy that. If the grant is for video and location, no problem. Justin: The new text addresses that concern, but the exact text isn't specified. Fluffy: I don't want someone who puts a piece of tape over their camera to think that they can hit this safely, but I agree that the text shouldn't be specified here. Martin: I don't know a better solution than what you have, but I'm not sure that we're able to put that information in a prompt. Do you think you can? Justin: We need to do our research. Martin: Right. You can't enumerate all of your devices. Alissa (individual): This is such a slippery slope, to talk about this in the draft. Another way to read this is that the prompt doesn't change at all. Most people will be willing to accept the addition of their IP address. I don't see the words that this will appear in the prompt. The real issue I have is that there are cases where you're totally fine sharing video, but not your location. It's a real case. Justin: The document does consider these cases. It's not trying to be super-prescriptive about UI, because that's outside of scope for this group. The new text is better than the old text. It does try to explain that it's not a simple thing. Chairs: Would you be OK explicitly including this information in the prompt? Would that change opinions? Alissa: I thought that the point was that this is not explicit. I'm proposing wordsmithing to make it clear that this is one case -- that I'm OK with sharing video but not location. Justin: Whether that can be intimated in a prompt is an unresolved question. Alissa: Yeah. Probably not, I guess. Fluffy: This is a tool that fits in to a bigger system; we should evaluate the privacy characteristics of the whole system, not just this in isolation. As we see how the whole solution and the different modes work, we'll see. It's hard to say without knowing how the prompts are going to look like and other parts of the system. Justin: UI is out of scope. Fluffy: Absolutely, but what the prompt looks like does influence this discussion. Harald: The discussion of what advice to give to UI implementers is an area that the W3C has given a lot of thought to; the result being that they don't dictate what the UI should be, and so you have to write advice on what you want the UI to accomplish. We should heed that. One level of detail down should be at the W3C level, not the IETF level. EKR: I'm surprised that we're having this discussion. Six months ago, we were all cool with exfiltrating this data. Now we're talking about how we're not cool with it. When we discussed this last time, there was uneasy agreement that the user was going to respond to more than one prompt, and that we couldn't explain IP address leakage to them. So, maybe people have material objection to one of those statements and think that the system should behave differently. If there's an objection to this yucky but reasonable text, I think we should remove it entirely, rather than talk about it more. I'm fine with it. Whether that consent is informed or not, ratholing on whether the user knows exactly what is going on is silly. Martin: I was going to suggest the same thing. This is perhaps far too much detail. Maybe Cullen wants us to have this level of specificity to perform his analysis, but I don't need to see that. We just need a signal from the user that this isn't a drive-by situation, e.g., camera or mic access, or even geolocation. Justin: I thought about that, but it might be confusing... Martin: The point is that the browser has received some sort of signal from the user that this web site is in some way exceptional. Justin: That was the driving force here. That covers 99% of intent. There's also the 1% case when someone wants video but not location; that may not be pertinent. Adam: The second sentence goes as far as the IETF has in its remit. Saying that we have a combined grant is all we need to say, and the W3C can do the rest. Mo: Why can't another bullet be added to the list, without selection? Just notification? This seems so simple. Adam: For the record we hate that, and will fix it. Justin: The cognitive load of such a dialogue is pretty scary. Ted (individual): I disagree pretty strongly with Martin's characterisation, and agree with EKR's. We're not desparate to give people UI clue. What we're trying to say is that there's a parallelism where the permissions grant for camera and mic are related to the grant for IP addresses used, and that's actually not related. In the left hand side, I think you were right to focus on other things, but I think EKR is right in that you'd be better off without any of that. This relationship between two kinds of information just isn't there. If you're on a chat server, you may very well be willing to show people your face, but not that you're three blocks away. If you try to relate them, you'll always be muddying things. Personally, I'd rip this all out. Justin: At some point, the document tries to say what the default should be. Are you saying we should walk that back? Ted: No. The default is fine. The default for network privacy information should not be derived from media privacy. Justin: I don't know what it means to have a default without using that information. Alissa: I agree with everything that Ted said. Pick a default, don't justify it based upon a relationship that doesn't exist. Ted: You can say that in the common case, we prefer network latency over privacy. Justin: [ proposal about mode 2 as a default ] Alissa: If nobody believes that there's not a reasonable way to obtain informed consent, you shouldn't say anything about consent. Justin: I agree that this isn't a question you can put in front of users and get a reasonable response to. A site that has explicit trust of some sort from the user is in a privileged state. Alissa: That falls back to the notion that these things are somehow related; they're not. Justin: We saw drive-by harvesting go down substantially in Chrome when we did this. We may be over-analysing it. Alissa: The argument is not to change the default; it's to change the false rationale in the document. Fluffy: In mode 1 or 2, what is the default behaviour? For applications like chat or p2p that don't have any audio or video, there is real cost of this permission. People might find it creepy that they're asking for access to camera. If we can explain network location in the prompt, I'd be interested to see someone dig in and see if it's possible. If not, we're punting on the problem that brought us here, and we're making things worse for a bunch of applications. It's not a good tradeoff. If we're solving the problem we thought we were, that'd be fine, but I don't see it. Martin: I think I agree with Alissa; we should rip out justifications. I got up to object to the idea that trust is fungible; that trust in a microphone has no bearing on whether you trust someone to know your location. Justin: That seems hard to support. Something that's been trusted to some degree has a higher reputation. Martin: If I think that I can control this permission to my camera that always points at the wall, it's a surprising thing. Justin: That's a cherry-picked case. Martin: I think we'll disagree on that one. EKR: Let's see if we can close this. There seems to be agreement that the following are OK: browsers should be allowed to go into mode 1 if they get user consent for camera/mic. It may be the case that they should be allowed without consent. My sense is that people in the room would be OK saying nothing here. Do you think we need something stronger than that? What is the normative force of what you're trying to do here? Justin: It's the RFC2119 discussion, which we'll get to later. Let's assume that this is standards track, and has normative force; we have two options. We can say that this algorithm should be used to engage mode 1 or mode 2; or we could leave that decision up to the implementation. I lean on the side of putting in the rationale for posterity. EKR: I'd be happy with either. Much of the benefit of this is not direct consent, but rather that the user is in the loop. It might make people happier to avoid talking about relative levels of risk, but instead encourage browsers to not allow entering mode 1 without direct user interaction. That would mean that any dialog would be OK. Justin: That seems like a re-casting of the text here. I'd be fine with that. But I'm not sure I have a sense of the room. Martin: I'd like to retain some browser discretion here; we may discover better signals in the future. I want to avoid proscription as it stands in the doc, and I want to avoid implications of proscription. EKR's proposal is fine. Maybe some weasel words around it. Justin: That sounds great to me. Do we include rationale? Martin: We should be gating access to mode 1 as much as possible. Justin: Sure. ### RFC2119 Language Chairs: AD, are you OK with this being a standards-track document? Alissa: Yes. Chairs: Anyone in the audience? [ no pushback ] Chairs: Given the previous discussion on consent, I think the right thing to do is to ask the author to take into account the consensus to move this to standards, and update as necessary.