I reviewed an earlier version of this and found it unclear, with terminology that didn’t seem well defined. Sean asked me to re-review this version. It’s much better and is definitely in the right direction, so thanks very much for the continued work on this. Throughout (nit): The phrase “location-tracking tags”, needs the hyphen as here, because “location-tracking” is a compound modifier. “Tags used for location tracking” has no hyphen, but “location-tracking tags” does. — Section 1 — * If accessories simply have a fixed identifier that is reported back to the tracking network, then the central server is able to track any accessory without the user's assistance, which is clearly undesirable. I suggest avoiding characterisations such as “is clearly undesirable”, as there are a lot of varying opinions in this space. Better to either eliminate the phrase (best here, as it’s not necessary to make the point that’s being made, and why is this any more clearly undesirable than, say, the following bullet or the one after?) or to say something like, “which is undesirable because .” While location tracking tags have existed for over a decade, they became especially widely-used in the Global North […] location tracker use in the Global South is typically limited to affluent communities. Why is any of this paragraph relevant? I suggest deleting it. — Section 2.2 — * *easily discoverable*: a device that is larger than 30 cm in at least one dimension, larger than 18 cm x 13 xm in two of its dimensions, and/or larger than 250 cm^3 in three-dimensional space I’m quite sure this has been batted around and lot, and I haven’t been following the discussion. So let me babble a little here, and take this as you will in the context of what’s already been discussed to death. 250 cubic cm is on the order of a tennis ball. General intuition says that’s a reasonable dividing point between “easily discoverable” and not: I might be able to drop a marble or even a ping-pong ball into your coat pocket without your knowing, but probably not so with a tennis ball. But I could easily stuff a tennis ball into, say, a teddy bear and give it to your child. Or something easy to discover in your pocket might be hard to discover if it’s concealed somewhere on your car. I guess I’m wondering if size alone is the right way to gauge discoverability. Still mulling this over. Oh, and there’s a typo up there: “xm” should be “cm”. — Section 3 — Existing attempts to prevent unwanted tracking by the owner(s) of a tag have been criticized as potentially making it easier to engage in unwanted tracking of the owner(s) of a tag. I got confused by this. If I’m reading it right, maybe adding the word “paradoxically” or “ironically” before “easier” would make it clear that you’re saying that the attempts aren’t working and are criticised as actually having the opposite effect. Or maybe I’m reading it wrong? — Section 3.2 — * Proximity to victim - High: Lives with victim or has easy physical access to victim and/or victim’s possessions. This has probably come up already, but maybe “target” is better than “victim” (throughout the doc)? — Section 3.3.2 — Nit: in the first line of the threat matrix table the mitigation column says “full”, while the description above defines “yes” as the value. As I read the details in the various subsections here, it strikes me that reasonable analysis depends greatly on the actual scenarios — factors such as the relationship between attacker and target, and so on. For example, section 3.3.8 talks about using the victim’s own tag and says the likelihood is medium. But it seems to me that the likelihood is low in a scenario that involves a potential burglar tracking a target back to their house, but high in one that involves a cohabitating partner who has full access to the target’s devices and environment over an extended period. Maybe there should be some discussion of the variability and limitations of these analyses at the beginning of the threat matrix section? — Section 3.3.12.1 — or otherwise limit how accessories respond to commands from devices. For example, accessories that receive a "play sound" command should only execute the command if the accessory is away from its owner. The first part of the “for example” part makes sense, but I’m not sure the second does. Suppose it’s my keys and I want to play the sound to find them under papers on my desk. Maybe we shouldn’t be getting into those kinds of design details here. — Section 3.4.2 — This includes attempts to track a victim using a tracking tag and applications readily available for end-users (e.g. native tracking application) is in scope. The “is in scope” is out of place in this sentence, and the “e.g.” phrase is awkward. I would reword this as, “This includes attempts to track a target using a tracking tag and applications, such as native tracking applications, that are readily available to end users.” — Section 3.5.1 — The following are out of scope for this document: * App-based technologies such as parental monitoring apps. * Other Internet of Things (IoT) devices. * Connected cars. * User accounts for cloud services or social media. I don’t know what “other IoT devices” and “user accounts” mean in this context. Also, in 3.4.2 you say that native tracking applications are in scope, so how does that make “app-based technologies” out of scope? I suggest fleshing the bullets out a little to make what you’re trying to say clearer. — Section 4 — * Avoid privacy compromises for the tag owner(s) when protecting against unwanted location tracking using tracking tags It would probably be good to frame this more clearly, setting out suggested priorities or balance between protecting targets vs protecting the attacker’s privacy. I imagine this to likely be a challenging and perhaps controversial area, so giving some more specific guidance now will help.