DULT BOF, November 6, 13:00-15:00 CET Administrivia Chairs (5 mins) Review of how deployed systems work today and architecture Zach Eddinger (10 mins) https://github.com/rdanyliw/ietf-dult/blob/main/dult-scope.md#notional-dult-architecture Charter discussion (90 mins) Brent Ledvina (90 mins) https://github.com/bdetwiler/draft-detecting-unwanted-location-trackers/blob/main/charter/charter-detecting-unwanted-location-trackers.md BOF questions Chairs (15 mins) * * * Review of how deployed systems work today and architecture - Zach Eddinger (ZE) DKG - It's useful to think about the entire system, but the title of this BoF is the one thing that's not in scope. ZE - The way we've hoped this would work is that the actual detection is dictated by the other pieces, but the detection system itself probably has some platform specific nuances that make it difficult to specify exactly how it works. I don't know how to think about scoping DKG - I don't think we should specify e.g. the colour of the alert in the GUI, but we do need to think clearly about when the warning is going to be shown to the user, and about false positives. I think we do need to scope this in? Alissa Cooper (AC) - Would it be valuable to specify when the tracker is unwanted? Daniel Gillmor (DKG) - There might be a range of options, but if the goal is detecting unwanted tracking then if we don't figure out something I'm not sure we've solved anything. We need to be able to tell people "here's how you defend yourself against unwanted tracking". We need to talk about the range of things that are reasonable to do. SPT - Like implementation guidance? DKG - Sure, but there's a user experience question. Ekr - Two responses to DKG - 1. It's about detecting a tracking network and tracker - and we can call the group something else. 2. We can have something specified here like in QUIC's congestion control, something specific specified but not mandatory to implement. Rohan Mahy - We need to consider the case of thieves stealing things and children being tracked. Tommy Pauly - I agree detecting trackers should be in scope, and we should specify "here is the range of pramaters that can be specified by local policy", but we need a baseline. Marcin Godzina - The two most used cases are tracking things that can be stolen and children that can be kidnapped. I'm wondering if we're not giving attackers a tool they can use. ZE - In effect people are more important than stuff. JGH - Seconding that - stuff is less important than people, and children have a right to privacy. Ekr - We can't get into the equitites of that here, but we don't know of a way to build a system that allows only good people to track. We need to specify a mechanism, or such a mechanism won't exist. Nick Doty - I agree that there needs to be a mechanism. It also doesn't help in the theft case, because theives know when they stole a thing, and can do a single search for the thing, whereas people in general can't search everything all the time. RM - There are two things here - detecting a tracker and having a way to disable someone else's tracker, that might be travelling coincidentally. * * * Charter discussion (90 mins) Ekr - I think the job is designing the entire system. Either we specify everything, including how to find your keys, or we are just detecting the tracker. AC - You think this text is out of sync with the set of interfaces that were presented in the diagram. Ekr - Yes. It's like defining HTTP by only defining cookies. TP - I think we agree on the scope of actual work items, but it is a key point that we need to acknowlege that such systems exist already, and our motivation is that we want to fix the gap that exists already. Would you be ok with expanding the scope within the background to specify this is why, and this is our scope. Gillian Verga (GV) - Remember that the networks are competitors of each other. We're here to solve this problem in a way that protects people, but there are laws that say we should not be sharing every bit of information about our OS with each other. We're not necessarily at liberty to disclose how the finder network is specified. The reason we're trying to create a line between what we need for our product and protecting against unwanted tracking. ND - I don't think the goal should be specifying a network for finding keys. There is importance in having visibility into payloads, etc. but we're less likely to get adoption if we have to deprecate all current devices. Roman Danyliw (RD) - As AD: There is scope later in the text that may or may not jibe here. The meat that binds us is what happens in the subsequent sections. Ekr - Yes let's talk details, but the big picture matters. We have to describe the wire format in full to do security analysis. There might be some proprietary sensing techniques, but we need to define the wire format. Andrew Campling - We have to consider the case of for example people with dementia. We have to be really specific into the problems we're trying to solve. SPT - Do you have any idea when we might first submit a draft to IESG? Brent Ledvina - 2 years? Stephen Farrell - I appreciate you adding security and privacy analysis, we could end up with something that has well known security properties and well known privacy properties but is still useless. We need to include the overall efficacy of the system. We need evidence to back that up. BL - What would that look like? SF - If people have implemented it, and other people have tried to break them. There were serious questions in the pandemic about COVID tracking systems. JGH - Security ND - We need engagement with advocay gorups and service providers for those owrking with victims of intimate partner violence. We won't be effective without have the right expertise on threat models. And there are goring to be some people who aren't going to be willing to show up in person, so maybe we need liason / other mechanisms to talk to them. This also helps address SF's point on measuing impact. SPT - Liason relationships are managed through the IAB, so we're trying to avoid that. We also don't want people whispering in a back room so not sure what we're going to do about that. Chris Patton - How will point 5 work? BL - Ekr and others have ideas. AC - (no hat) On the privacy and security language - can we go a little further, and have affirmative items like "the things specified here cannot be used themselves as additional tracking vectors" as opposed to document and explore the trade-offs. W.r.t. to phones and tablets, I know that other groups have specified devices in terms of capabilities or processing power so that we can have a way of deciding. RD - Stephen can you say more about how to put effectiveness language in the charter? SF - Remember the COVID tracking app. A lot of the claims made about that system were basically not true. We need to have some evidence that it really reduces the harms. RD - In other groups when we publish RFCs we sometimes publish before interop, sometimes before we know if it will work. Do you think this is so security critical that we gate progress on effectiveness? SF - This is us trying to reduce a current harm, not add a new bell or whistle. We should gate this. Maggie Delano - Seconding Nick, I've worked with a number of tech abuse advocacy orgs, and I'm happy to help with that link. DKG - Malorie points out that we need to think about inhibiting other forms of stalking prevention. One common abuse is malware on the phone. If this system requires you to always have your phone on you then you can't leave your potentially malwared phone with you. Can we bring a device to market that is able to detect trackers but has less power than a pocket supercomputer? We should consider these devices explicitly. Ekr - I don't think Stephen's evidence thing should be added to the charter unless he has something specific that he wants. I agree with DKG that we need to consider tracking detectors. Nalini Elkins: RE Stephen's point, how do you know you stopped harm? It's like proving a negative. How would we know what happened? ND: We should talk to experts about this. We're not in a good position to assess these things, and there are clinics and organisations that are very familiar with working with people, and talking about experiencing problems from these devices. TP: I wonder if we can just put in the charter "There is an intent to get some deployment experience before publishing", and let the working group evaluate this. To DKG's point, there are a number of efforts that are orthogonal to this, that we should make any modes compatible with this. AC: Do you think that's something for the IETF to do? TP: ... maybe an RG? Maybe HRPC? It may be useful to enumerate the things that you would want to lock down or disable, like the things the safety team (at Apple) considers. And we should be aware of these things. Mallory Knodel: I just want to affirm I think that's useful at least from a UI perspective. (No hats) I personally think that trackers shouldn't exist. We should take a harm reduction approach, because it'll be basically impossible to get everyone to get these devices off the market, but we should try to make the best solution whilst also trying to prevent it. RD: Should I be able to ubild some custom board with Bluetooth and run Linux on it Stephanie Mikkelson - I work with orgs that help deal with intimate partner violence. This is an issue of concern to them, and they are looking at this issue. We should bring them in. We also need to understand the issue holistically, because having a device with you or not can be bad or not, and is a much more complex issue. We also say Sam Weiler - I don't Dino Farinacci - So the charter should have something much stronger. Macs shouldn't be tracked. Beats (headphones) shoudln't be tracked. Everything shouldn't be tracked without doing this. We should tell vendors that don't follow this that they are non-compliant and don't care about security. CP - I think Ekr and JGH are right. We might argue about the definition, but there's going to be soemthing identifiable about tags. The goal of the charter now is don't make \[...\]. These things may not be in conflict like. TP - Keep it at JGH - DKG Ekr MG - I see a lot of work for manufacturers, but not many benefits for this thing. How do we make them implement this? Legislation? BL - Apple and Google are the proposers of this, and other companies have expressed interest. ND - There already exist devices that are customised or tampered with. These are know threats and we have other mechanisms for addressing this. We own't get a perfect solution. GV - We shouldn't make it too difficult for manufacturers to do this. CP - What about devices build after the fact that don't adhere BL - Covered by 5 / 5a. JGH - Can we change 5 to "crypytographically ensure" Ekr - Ensure is fine. If cryptographically is the best way we'll go that way, but if it's not we shouldn't restrict ourselves to that. David Schinazi - 1 doesn't mean "spill secret sauce", it means provide a baseline. ND - I suggested consultation and engagement - I do think it would help with evidence, but I don't think that's why we should do it, and we should do it throughout the process too. MD - What do people think 'liase' means? It's important that it's many conversations. Prefer "work with". AndCam - We should talk to organisations in places other than the US. AliCoo - IETF is global org, so goes without saying. SF - I like 3 to include collab with intimate partner violance too. Chad Sniffen - I would recommend changing intimate partner violence to gender-based violence. * * * 82 yes 8 no * * * Contribute drafts 18 yes * * * Review drafts 65 yes SPT: Does anyone beyond Apple, Google, Samsung, and Tile want to suggest support. BL: Pebbleby too said they were supportive of the effort. NE: We've (University in India) already started working on an implementation. * * * Create WG? 72 yes 2 no * * * Not create WG? No objections. RD: 171 participants is great for a BoF. We seen really significant motion around refining the charter text. The list of 6 items will be merged and get consensus in mailing list. If consensus is achieved we will take it to the IAB for consideration.