Some agenda bashing because Erica couldn't get online.
Ted Hardie: compromised phones are often used for stalking. This
solution
seems to rely on the phone for detection, but it might itself
be compromised, so is that a reasonable requirement.
Olsen: Stalkerware is a problem but we see that these location trackers
are a bigger issue and we have ways to educate people about stalkerware.
Also people can get different devices that the stalker is not aware of.
We still need a universal design.
Hardie: We need to consider these points during design. Dependency on
a particular set of technologies.
Kathleen Moriarty: We narrowly focus on use cases relevant to this
discussion. Other vendors have proprietary solutions for detecting
stolen items. Too difficult to try to scoope everything together
and you can't force people to implement the standard. Also, children
and elderly. There are devices designed for those use cases.
Francois Nguyen: Important use cases for these involve tracking
children and anti-theft.
Eva Galperin: Want to push back on the idea that tracking children,
elderly, stolen goods without detection. It's fine for children
and elderly to know they are being tracked. Anti-theft technologies
like this are stalking devices. People are more important than property.
Moriarty: Clarifying that I am supportive of the effort.
Brent Ledvina
Misell: What evidence is there that the deterrence stuff does anything.
If someone wants to commit crimes, then telling them they are doing
crimes won't do anything.
Ledvina: We don't have any evidence about the deterrence. The pairing
registry is useful. We also have evidence that being able to identify
the last four digits of the airtag owner's phone number is helpful
Galperin: You didn't mention that there is a way of turning detection
off through an anti-theft mode for your tile. Is that true?
de la Broise: There is a feature to disable detection, but there are
warnings.
Galperin: you can use that mode for stalking
de la Broise: There are a number of ways to misuse these features
and that's one reason we are here.
Alissa Cooper: Third party scanner suggests that there might
be no information other than the BLE data, but there is also this
proprietary blob.
McAllister: Also want to consider tracking on payload stability
Hari Prasad: What are your thoughts on false alerts, e.g., when
people are together?
McAllister: Really focusing on giving platforms the ability to
detect accessories at all. Actual detection logic is out of scope.
Prasad: If you don't speak about that and this is an annoyance
it might deter deployment.
McAllister: implementation is a separate question.
ekr: The last two points about hacked accessories and non-adherent
manufacturers need to be expanded to include devices that work with a
tracking network that allow being tracked but subvert the unwanted
tracking detection.
McAllister: Definitely a real risk that we are trying to capture in
scope once we can detect the normal ones.
ekr: I don't think we can necessarily do that; need to talk about that
later in scope discussion.
Brendan Moran: Serial number registries don't exist now for good reason.
The whole point of this is to prevent people from stalking you while
you're carrying your keys. It's counterproductive if we enable stalking
while trying to prevent stalking.
McAllister: This is why we have these mitigations around the third party
scanner. That's also why you need to take a physical action to get the
SN.
Moran: This is a real example of something that happened with a shoe
manufacturer.
Chen Li: Noncompliant manufacturer is a probably the biggest risk.
Stalker will find some nonconforming manufacturers. Probably will
require legislation to require trackers to conform to standard.
McAllister: We aren't to the world where we can choose the adherent one.
Once we get there, we can talk about the set of possible solutions
Jari Arkko: Follow up on Brendan's point. Are we relying on existing
databases of serial numbers or are creating a new one for this purpose?
The latter would be concerning. The draft also talks about handing this
data over to the authorities. Not sure the IETF spec should say that.
You mentioned the physical action required but doesn't the spec say that
NFC is enough? Maybe that's not good because you can get close enough to
someone's bag
Nalini Elkins: Non-compliant devices. Another whole category is that
there will be a lot of legacy devices. Maybe the place to do all this is
not at the device level but at a different level or have a good
migration path.
Gabriel Andrews: Re notifying people that they are conducting legal
activity. This helps alleviate plausible deniability around not knowing
you were breaking the law.
Yaron Sheffer: These ecosystems are silos. One of the things we will do
is to start breaking down some of the walls. This may result in a
universal tracking network.
Tommy Pauly: Having the payload be in scope. May need to update the
diagrams to make this clear. This has important privacy implications. In
terms of what's out of scope, the case of an interoperable but
noncompliant device. I would like us to find a way so that obvious
subversion is detectable. Should be ways to mitigate this.
Watson Ladd: I think this is good work. Privacy goals are
underspecified. Diagrams were clear, charter was not.
DKG: These networks are dangerous. We should be thinking about how to do
this. Discouraging proprietary networks. Concerned about this scope.
Putting the third party thing out of scope seems like a mistake. This
has privacy implications. I understand the desire to have bite size
problem. Pairing registration has privacy concerns. E.g., if I get a tag
I can identify someone. Need to think about systemic impacts not just BT
Gregory Maxwell: Are mechanisms to disable trackers in or out of scope,
e.g., shelter or at home.
Ledvina: Physical access allows you to disable it. I don't think the
protocol needs to be in charter scope.
Maxwell: Physical access often too late.
Moriarty: Need to ensure we are precise on the use case in order to make
progress. If we don't out of scope dementia and tracking children it's a
different use case.
Cooper: What should be the scope?
Moriarty: Tracking and preventing surveillance. Lost devices that are
yours. Stolen items and elderly/children out of scope.
Nick Doty: Sent comments on the list. I am questioning ruling
attestation out of scope.
Ted Hardie: This works by having a system which has a device which
colludes with nearby devices and uploads data to a database. This system
involves creating a new system where nearby devices look at the data and
we shouldn't rule out of scope looking at the first piece. Historically,
the IETF has insiste on change control and this charter seems to exclude
any changes to important features. This should be rethought. If you
limit the solution space to things that let existing trackers work you
probably haven't fixed the problem.
Sam Weiler: I saw a paper about how to avoid these issues. Easy to make
a fake tracker. I think attestation is dangerous, but how do we fix this
problem.
Ledvina: Not sure
Jonathan Hoyland: Suppose I trust Apple. Can we find some way to make
the tracking networks include some authentication. Otherwise we might
have rogue devices. If we require a signature in the charter we might
get somewhere
Ben Schwartz: Privacy requirements in the charter are incomplete. They
don't talk about protection for the tag owner. Maybe this problem is
insoluble. Charter should include the possibility of failure.
ekr: On one hand, this is a very important and serious problem. On the
other, this approach is not great. As DKG pointed out, the proprietary
blob is a critical part of the privacy surface. That needs to be in
scope. It will be very difficult to have rules to make the privacy
properties sufficient. We also need to deal with non-conformant devices.
It would be a huge improvement if available devices are conformant. But
the next step is that someone will create cheap non-conformant devices.
We need to be a step ahead. Third, the IPR terms are inadequate -- it is
not acceptable to have to pay Apple a fee. The defensive suspension
clause is also bad.
The end goal is to have a system that provides privacy to the user. In
order to have this be an open system, and it needs to be implementable
without hitting patent infringements. The worst thing we can do is to
only solve part of the problem, and say "mission accomplished" and leave
privacy problems on the table unsolved.
Shivan Sahib: Hard to talk about the privacy guarantee of the opaque
blob. The bullet point about detecting devices that don't implement
doesn't really make sense. For sending the email, etc, that's a bad idea
unless we add lots of constraints to make cryptographically protected,
etc.
David Schinazi: I agree with the goals. The scope is a bit too narrow.
We need to widen the scope to include the tracking system.
Stephen Farrell: Agree with David, EKR, Ted, DKG. Through the pandemic,
there was a lot of experience with Bluetooth based stuff. There might
have been an excuse for rushing stuff out the door then, but not here.
We should require evidence of efficacy before this gets out of the WG.
Andrew Campling: Agree we need to focus on specific use cases, but if we
focus too much, we risk breaking other use cases. When I use AirTags to
find my stolen luggage, I am the "attacker". Need to trade off use
cases. (RFC 8890)
Ledvina: People are more important than belongings.
Behcet Sarikaya: What layer will the protocol be developed at?
Ledvina: Charter isn't clear.
Misell: If you take a small drill bit to an airtag you can disable the
speaker. This should also describe some physical security
considerations. People raised that tracking of children and eldery
people should be out of scope. I have had to deal with children being
tracked nonconsensually. Use case of someone who has a phone and someone
who is not technology literate should not be out of scope.
Jonathan Brown: Committing to RAND terms doesn't require Apple to
charge. Implementor can contact Apple to get a license. Technology is
used in other contests. When it comes to Apple dealing with other
companies they have to be careful. Defensive suspension is needed. How
likely is it that Apple will actually be difficult about this.
EKR: What I'm asking for is a more generous set of terms. Compare Opus
and Cisco. Apple could commit to that now.
Brown: we actually did look at Opus. Lots of RAND licensing.
Question 1:
Does the community think that the problem statemtn is clear,
well-scoped, solvable, and useful to solve?
Yes (Raise hand): 31
No (Do not raise hand): 74
Not using the poll tool.
Would you be willing to contribute drafts: > a dozen hands in the room
across multiple spaces
Would you be willing to review drafts: ~50 hands
Would you be interested in implementing: 6 or so (Apple + Tile + Chipolo
in the chat = others)
Question 3: Is there support to form a WG with the proposed charter
(more or less as-is)
Yes: 34
No: 61
Cooper: A lot of discussion about different charter scope. Is there
support to work on a charter that did something bigger.
Q4: Is there support to work on a charter that address the problem(s)
discussed today but has a broader scope than the proposed charter:
Yes: 97
No: 1
Coop: Does the person who did not raise hand want to speak up? [No
Answer]
Q5: Is there anyone who feels that the IETF should not do work in this
area?
Yes: 3
No: 93
Coop: Does anyone who raised their hand want to speak up?
Michael Richardson: This presupposes that the IETF result will be
effective for the participants that need to be involved. We have the
security and networking clue, and the [....] and some experience with
DRIP, not sure we have the right set of people to implement. Not
convinced we have the running code people in the room. Would love to be
wrong.
Joel Jaeggli: Gone back and forth on this. Pervasive monitoring is an
attack. Do not think that these platforms can be safely used without
enabling that functionality. IETF shouldn't participate in that.
Roman Danyliw: Thanks to all new participants for coming. A lot of
perspectives on this. Appreciate the level of professionalism.
We have a pretty strong signal on what to do next. I think what I heard
was there is strong interest to do work on something in this space, but
we shouldn't do what was presented here. Need to step back and refine
approach and scope it appropriately. There are people in this room
interested in working on this problem and interest in implementation
side. Successful BOF. Interest in working on hard problem. Need to step
back, refactor, and get this right. Please join the ML so we can have
this conversation. Next step is charter iteration.
Bob Hinden: It would be great to have another BOF. Interesting topic. A
long way from forming a WG. Not sure if we can make the world better or
just different.