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 -
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.