**Session Date/Time:** 06 Nov 2024 09:30

# dult

## Summary

The DULT working group meeting focused on progressing the unwanted tracking protocol documents. Discussions covered terminology standardization, applicability of the protocol to different device sizes, the necessity of a sound maker, firmware updates, identifier printing, NFC requirements, and threat model considerations. A key debate centered around the scope and granularity of threat modeling and the balance between privacy and utility. The chair emphasized contribution-driven progress.

## Key Discussion Points

*   **Terminology:**  The group discussed whether to keep a common terminology section within the experience protocol document or move it to a separate document referenced by all others.  Consensus was to keep it in the experience protocol document for now, with potential refactoring later.
*   **Applicability:**  The applicability section currently defines requirements based on device size, specifically concerning trackers easily hidden on a person. The group debated the relevance of size as a primary differentiator. Some argued that the ability to hide a tracking capability matters more than physical size.  Ecker suggested tying applicability to specific features of the finding protocol, not just size.  Document structure came into question and whether four separate documents made sense.
*   **Sound Maker:**  The discussion addressed the mandatory sound maker (speaker) requirement, questioning its practicality for smaller trackers and whether alternative notification methods (haptics, flashing lights) should be considered.  Concerns were raised regarding accessibility for individuals with disabilities. Several participants mentioned that the specification should be broad enough so that accessories can use notifications or some combination of the kind. It was noted technical aspects will need to be considered with different modalities. The concern about muffling sound makers came up for threat consideration.
*   **Firmware Updates:**  The working group revisited the handling of firmware updates. The current text is terse, and the group discussed the need to ensure updates do not violate safety requirements. The manufacturer should maintain the requirements and the specs with any updated firmware that it delivers. The threat model around firmware updates also needs more exploration. Matthew advocated for a requirement that any update mechanism not violate the specification's requirements, rather than mandating a specific mechanism.
*   **Identifier Printing:**  The group debated the requirement to print unique identifiers on accessories, including whether identifiers that rotate over time can be excluded from the printing requirement.  Nick raised the concern of device smashing and how identifiers would be retained in that case. Ecker and DKG pointed out that even rotating identifiers rely on an underlying static identifier. Most favored retaining the printing requirement to aid in identifying found trackers. The privacy implications from printing identifiers were debated.
*   **NFC Requirements:**  Brent proposed adding a section on NFC requirements to ensure proper configuration and privacy-preserving practices. The group generally agreed. The clunkiness of the NFC requirements wording was noted.
*   **Threat Model:** Maggie presented refinements to the unwanted tracking threat model, including attacker/victim profiles and in/out-of-scope considerations. Discussion touched upon issues related to spoofing, reverse engineering and altering devices (e.g. disabling speaker), and the technical capabilities of attackers and also technical skills of victims. DKG challenged the idea of "NOMCOMpliant" devices being in scope, leading to clarifying discussions on the charter. Scenarios and design constraints were also considered and the idea of assessing key parameters to ensure the usefulness of a product.

## Decisions and Action Items

*   **Terminology:** Keep the common terminology section in the experience protocol document for now, with potential refactoring later.
    *   Barry volunteered to review the terminology section. Authors from other documents should be encouraged to also review it.
*   **Applicability:** Encourage PRs with text describing the applicability scope.
*   **Sound Maker:** Broaden sound maker requirement into notifications or something to that effect. The technical requirements of different modalities will need to be considered.
*   **Firmware Updates:** Develop a more robust firmware update policy that protects the user.
*   **NFC Requirements:** Add NFC requirements section, Brent will create a PR. Clean up the text for NFC considerations.
*   **Threat Model:** Maggie will refine the threat model document based on the feedback, including specifications on the parameters with metrics for those issues.

## Next Steps

*   Authors to submit PRs to address open issues and incorporate feedback.
*   Continue discussion on the mailing list.
*   Consider an interim meeting if needed to accelerate progress, pending agenda discussion.