MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: 
Cc: unwanted-trackers@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <176045721947.980384.14300704440219623950@dt-datatracker-84f8f646b-tg6mn>
Date: Tue, 14 Oct 2025 08:53:39 -0700
Message-ID-Hash: 36G5KYVCRHDAZNWYSBAFJYFTNYNQQM2B
Reply-To: Barry Leiba <barryleiba@computer.org>
Subject: =?utf-8?q?=5BUnwanted-trackers=5D_draft-ietf-dult-threat-model-02_early_Arta?=
	=?utf-8?q?rt_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/unwanted-trackers/QT0-ZM2egg9IRk8jUX-YHdCC2CE>

Document: draft-ietf-dult-threat-model
Title: DULT Threat Model
Reviewer: Barry Leiba
Review result: On the Right Track

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
<reason>.”

   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.