-
where should terminology section live?
- ekr: i don't want a copy in each document. at the end of the
production process we could copy/paste to make sure they're
aligned, but not now. I'm inclined to leave it in this document.
It needs to be part of the normative spec. Other docs can cite
this one.
- Barry Leiba: i agree with ekr that it can live here. But that
means the other documents are MISREF until this is released.
- Andrew Campling: standalone terminology document makes it easier
to maintain.
Agree with what ekr said earlier: let's have it here, in the
thing that is the most technical. If there are more generic
terms, we could put the high-level terms in the architectural
document. As publishing, this is going to be a cluster of docs
that will depend on each other, similar to what the privacypass
work did.
- dkg: if we publish as a cluster, this doesn't matter. if we want
to put something forward first, we could try to move it to that
one, but then that locks it in.
- Sean: doesn't make sense to publish separately.
-
Brent: who will review?
- Barry Leiba
- Daniel Kahn Gillmor
- Eric Rescorla
- other doc authors?
-
(slide 6) Applicability statement: do we want it?
- ekr: i'd write it into the rest of the spec, define "small",
then say "if small, MUST do X"
- Andrew Campling: size is a red herring. you can't hide a
bicycle, but you can embed a tracker in a bicycle that someone
is already using.
- Maggie Delano: the tracker component might be detachable. if you
make a tracker for a bicycle or luggage, so it thinks it's big,
it could be detached and not know it, and it would still behave
as though it were big.
-
ekr: we should reconsider the breakdown of the documents, because
they seem to be tightly intercoupled, and even though they match the
larger pools of work, they might be better off integrated.
-
deb: get the text down and then redo the organization afterwards.
-
(slide 7) Sound maker requirement:
- Nick Doty:
https://cdt.org/insights/centering-disability-in-mitigating-harms-of-bluetooth-tracking-technology/
speakers are important for people with vision disabilities.
maybe we should require haptics or flashing lights or things
like that.
- dkg: i don't understand the argument for removal. just because
manufacturers want to make something smaller/cheaper/whatever
doesn't mean that we should say that's OK. This is about how to
make a responsible device.
- Andrew Campling: i predict a market for things like accessories
that will muffle sound and block visual detection (waves his
keychain)
- Siddika Polatkan: if we're going to demand other things (e.g.,
haptics), we need to supply technical requirements. ("bright
lights" isn't sufficient, there needs to be a measurable
requirement)
-
(slide 8) Firmware update threat vectors
- ekr: firmware update mechanisms should not allow third parties
to violate these protection mechanisms
-
(slide 9) Printing non-SN unique identifiers
- Nick Doty: if someone finds a device like this and smashes it
with their boot, how could they then identify it? I'm concerned
about having it be only electronic.
- ekr: the devices all have a unique identifier, even if it drives
the published rotating identifiers. You want the radio
identifier to avoid being identified over time by networks of
radio receivers.
- dkg: rotate the radio beacon; leave the static printed
identifier (maybe write it on the internals of the device as
well)
- Andrew Campling: agree that we can have the static ID on the
device.
-
(slide 10) Add NFC requirements section
- dkg: wording is confusing for those of us who don't understand
NFC