DULT

Summary

The DULT working group convened to continue discussions on the "promote disablement" proposal, aimed at addressing sophisticated stalking scenarios where a victim cannot locate a hidden tracking device. The discussion focused on the conditions under which a tag could be disabled, the mechanisms for enforcing these conditions, and potential attack vectors from malicious actors. A key point of consensus was the reaffirmation that the DULT protocol is not designed for anti-theft use cases, prioritizing the protection of individuals from unwanted tracking over property recovery. New proposed shared definitions were introduced and deferred for offline review before the next meeting.

Key Discussion Points

Meeting Logistics: The chair, Michael, addressed initial confusion regarding meeting links. Interim meetings are scheduled for August, September, October, and December, with November pending. The working group will not hold an in-person session in Madrid due to expected low attendance and timezone challenges.
"Promote Disablement" Proposal: Maggie presented an update on the "promote disablement" proposal, which seeks to provide recourse for victims in "canonical stalking scenarios" (e.g., a hidden tracker in a car).
- Objective: To enable the disabling of a tag's crowdsourced location reporting while mitigating risks of misuse and unintended consequences for benign scenarios (e.g., lost luggage, borrowed items).
- Proposed Conditions for Tag Disablement (Proposal 1):
  - Passive Scanning: A user must have received an unwanted tracking alert, then repeatedly (at least three times) attempted to locate the tag using available finding technologies (e.g., precision finding, playing a sound/haptics), and subsequently indicated they still cannot find the tag.
  - Active Scanning: A user must actively scan and find a tag separated from its owner. Additionally, the tag must be co-located with the user for a defined period (e.g., 10 minutes), the user must travel a certain distance (e.g., 500 meters), and then scan again, confirming the tag is still present.
  - Re-enablement: Disabled tags could be automatically re-enabled if the owner comes back into range. Notifications to the person who disabled the tag upon its re-enablement were deemed important.
- Enforcement Concerns: Echer and Brent raised significant concerns regarding the enforcement of these conditions.
  - If conditions (e.g., "user attempted to locate") are enforced solely by the platform (e.g., a smartphone app), a malicious actor could use an arbitrary radio emitter to simulate these actions and maliciously disable tags at scale (e.g., in public transport).
  - The current tag architecture does not enable a tag to verify that a specific alert has been shown on a user's phone. While a tag could enforce playing a sound a certain number of times, it cannot verify the precursor alert.
  - It was agreed that any disablement mechanism should ideally be enforceable by the tag itself to prevent widespread abuse by non-platform-controlled devices.
- Victim Opt-out of Crowdsource Network (Proposal 2): A secondary proposal suggested allowing a victim's own device to temporarily opt out of crowdsourcing tag locations. This was noted to provide limited privacy protection, as other devices in the vicinity could still report the tag, and would ideally need to be implemented at an account level across all user devices.
- Impact Analysis: The proposal's impact was assessed, showing a high positive effect on preventing unwanted tracking, with a medium negative impact on recovering benign lost items and a low negative impact on items that are not lost but temporarily away from their owner.
Anti-Theft Use Cases: Brent inquired about the protocol's applicability to anti-theft scenarios, such as multiple non-discoverable tags hidden in a car.
- The working group, including Maggie, Echer, and an Apple representative, reiterated that the DULT protocol is not designed for anti-theft.
- Rationale: The immense power of a wide-scale tracking network necessitates strict controls to prevent its use for stalking. Allowing anti-theft functionalities without sufficient safeguards could inadvertently create a perfect tool for unwanted tracking.
- An Apple representative confirmed that Apple's MFI program for Find My Network accessories explicitly prohibits anti-theft type accessories.

Decisions and Action Items

The working group affirmed the long-standing principle that the DULT protocol's primary goal is to combat unwanted location tracking, and it is explicitly not designed for anti-theft use cases. This fundamental decision should be clearly documented in future drafts.
A proposal for shared definitions (Pull Request 102, present in both the accessory protocol and threat model drafts) was introduced. Participants are requested to review this PR offline.

Next Steps

All participants are encouraged to review the shared definitions (Pull Request 102) in the threat model draft. This will be the first agenda item for the next meeting.
The authors of the "promote disablement" proposal (Maggie, Sedica, Brent, and others) will continue to refine the proposal, specifically focusing on:
- Identifying which of the proposed disablement conditions can be robustly enforced by the tag itself.
- Further analyzing potential attacks and abuses of the remote disablement mechanism.
- Developing a clearer understanding of the implementation details required for secure and effective disablement.

Session Date/Time: 26 Jun 2025 16:00

DULT

Summary

Key Discussion Points

Meeting Logistics: The chair, Michael, addressed initial confusion regarding meeting links. Interim meetings are scheduled for August, September, October, and December, with November pending. The working group will not hold an in-person session in Madrid due to expected low attendance and timezone challenges.
"Promote Disablement" Proposal: Maggie presented an update on the "promote disablement" proposal, which seeks to provide recourse for victims in "canonical stalking scenarios" (e.g., a hidden tracker in a car).
- Objective: To enable the disabling of a tag's crowdsourced location reporting while mitigating risks of misuse and unintended consequences for benign scenarios (e.g., lost luggage, borrowed items).
- Proposed Conditions for Tag Disablement (Proposal 1):
  - Passive Scanning: A user must have received an unwanted tracking alert, then repeatedly (at least three times) attempted to locate the tag using available finding technologies (e.g., precision finding, playing a sound/haptics), and subsequently indicated they still cannot find the tag.
  - Active Scanning: A user must actively scan and find a tag separated from its owner. Additionally, the tag must be co-located with the user for a defined period (e.g., 10 minutes), the user must travel a certain distance (e.g., 500 meters), and then scan again, confirming the tag is still present.
  - Re-enablement: Disabled tags could be automatically re-enabled if the owner comes back into range. Notifications to the person who disabled the tag upon its re-enablement were deemed important.
- Enforcement Concerns: Echer and Brent raised significant concerns regarding the enforcement of these conditions.
  - If conditions (e.g., "user attempted to locate") are enforced solely by the platform (e.g., a smartphone app), a malicious actor could use an arbitrary radio emitter to simulate these actions and maliciously disable tags at scale (e.g., in public transport).
  - The current tag architecture does not enable a tag to verify that a specific alert has been shown on a user's phone. While a tag could enforce playing a sound a certain number of times, it cannot verify the precursor alert.
  - It was agreed that any disablement mechanism should ideally be enforceable by the tag itself to prevent widespread abuse by non-platform-controlled devices.
- Victim Opt-out of Crowdsource Network (Proposal 2): A secondary proposal suggested allowing a victim's own device to temporarily opt out of crowdsourcing tag locations. This was noted to provide limited privacy protection, as other devices in the vicinity could still report the tag, and would ideally need to be implemented at an account level across all user devices.
- Impact Analysis: The proposal's impact was assessed, showing a high positive effect on preventing unwanted tracking, with a medium negative impact on recovering benign lost items and a low negative impact on items that are not lost but temporarily away from their owner.
Anti-Theft Use Cases: Brent inquired about the protocol's applicability to anti-theft scenarios, such as multiple non-discoverable tags hidden in a car.
- The working group, including Maggie, Echer, and an Apple representative, reiterated that the DULT protocol is not designed for anti-theft.
- Rationale: The immense power of a wide-scale tracking network necessitates strict controls to prevent its use for stalking. Allowing anti-theft functionalities without sufficient safeguards could inadvertently create a perfect tool for unwanted tracking.
- An Apple representative confirmed that Apple's MFI program for Find My Network accessories explicitly prohibits anti-theft type accessories.

Decisions and Action Items

The working group affirmed the long-standing principle that the DULT protocol's primary goal is to combat unwanted location tracking, and it is explicitly not designed for anti-theft use cases. This fundamental decision should be clearly documented in future drafts.
A proposal for shared definitions (Pull Request 102, present in both the accessory protocol and threat model drafts) was introduced. Participants are requested to review this PR offline.

Next Steps

All participants are encouraged to review the shared definitions (Pull Request 102) in the threat model draft. This will be the first agenda item for the next meeting.
The authors of the "promote disablement" proposal (Maggie, Sedica, Brent, and others) will continue to refine the proposal, specifically focusing on:
- Identifying which of the proposed disablement conditions can be robustly enforced by the tag itself.
- Further analyzing potential attacks and abuses of the remote disablement mechanism.
- Developing a clearer understanding of the implementation details required for secure and effective disablement.