❤ Apple and Google partners up to address unwanted tracking
Table of Contents
On May 02,2023, Apple and Google are partnering to address unwanted tracking through Bluetooth tracker devices and to alert users across platforms like iOS and Android when they are being tracked. The companies have proposed an industry specification to combat unwanted tracking, with support from manufacturers like Samsung, Chipolo, eufy Security, and Pebblebee. This demonstrates their commitment to ensuring user safety and privacy. Ron Huang, Apple’s vice president of Sensing and Connectivity, emphasized the importance of collaboration with Google, stating that it is a critical step forward in combatting unwanted tracking across both iOS and Android platforms.
Feedback from manufacturers and advocacy groups has been incorporated into the development of the specification. Erica Olsen, Senior Director of the Safety Net Project of the National Network to End Domestic Violence, praised the collaboration and resulting standards as a significant step forward in protecting survivors and all people from the misuse of Bluetooth tracking devices.
The specification has been submitted as an Internet-Draft via the Internet Engineering Task Force (IETF), and the partnership is inviting other companies to join the initiative, provide comments or review the draft over the next three months. After this period, Apple and Google will release a production implementation of the specification to address unwanted tracking, which will arrive on both iOS and Android platforms by the end of 2023.
Introduction to the IETF
The Internet Engineering Task Force (IETF), founded in 1986, is the premier standards development organization (SDO) for the Internet.
The IETF makes voluntary standards that are often adopted by Internet users, network operators, and equipment vendors, and it thus helps shape the trajectory of the development of the Internet. But in no way does the IETF control, or even patrol, the Internet.
Quoting from RFC 3935: A Mission Statement for the IETF:
the overall goal of the IETF is to make the Internet work better.
Its mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds.
The Mission Statement further states that the Internet isn’t value-neutral, and neither is the IETF. The IETF wants the Internet to be useful for communities that share our commitment to openness and fairness. The IETF embraces technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that’s possible, and much to do with the technology that the IETF chooses to create.
There is no membership in the IETF. Anyone can participate by signing up to a mailing list, or registering for an IETF meeting. All IETF participants are considered volunteers and expected to participate as individuals, including those paid to participate.
The IETF welcomes all interested individuals and participants come from all over the world and from many different parts of the Internet industry. In any one year, over 6000 people actively participate in the IETF either by authoring a document, engaging in a mailing list discussion, or attending a meeting.
The only fee the IETF charges is for registering for an IETF meeting, with options in place to prevent that fee from becoming a barrier to participation.
IETF participants are regularly shown the Note Well, a reminder of the policies and processes they are expected to comply with.
To ensure an environment in which people of many different backgrounds are treated with dignity, decency, and respect, these policies include a code of conduct, an anti-harassment policy, and the IETF has an Ombudsteam who are the point of escalation for any problems with conduct.
The IETF conducts its work solely in English.
The IETF pursues its mission in adherence to the following cardinal principles:
Open process Any interested person can participate in the work, know what is being decided, and make his or her voice heard on the issue. Part of this principle is our commitment to making our documents, our Working Group mailing lists, our attendance lists, and our meeting minutes publicly available on the Internet.
Technical competence The issues on which the IETF produces its documents are issues where the IETF has the competence needed to speak to them, and that the IETF is willing to listen to technically competent input from any source. Technical competence also means that we expect IETF output to be designed to sound network engineering principles – this is also often referred to as “engineering quality”.
Volunteer Core Our participants and our leadership are people who come to the IETF because they want to do work that furthers the IETF’s mission of “making the Internet work better.”
Rough consensus and running code We make standards based on the combined engineering judgement of our participants and our real-world experience in implementing and deploying our specifications.
Protocol ownership When the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet. Conversely, when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it, even though it may at times touch or affect the Internet.
The IETF publishes its technical documentation as RFCs, an acronym for their historical title *Requests for Comments*. RFCs are sequentially numbered, starting with RFC 1 published in 1969 (the RFC series predates the IETF). Each RFC has a status, generally one of ‘Internet Standard’, ‘Proposed Standard’, ‘Informational’, ‘Experimental’ or ‘Historic’. Some statuses may change over time. RFCs are freely available.
The RFC series has two sub-series, STDs and BCPs, with each numbered STD and BCP comprising one or more RFCs. STDs are ‘Internet Standard’ RFCs and BCPs are RFCs that describe Best Current Practices in the Internet, some of which are administrative processes for the IETF.
Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that “obsoletes” the first. If a technical or editorial error is found in an RFC, an errata may be linked to the RFC and/or held for the next document update.
The authoritative repository of RFCs is the RFC Editor website.
For further information, see RFCs
The work of the IETF is to produce RFCs.
New work in the IETF begins with one or more participants producing a document called an Internet-Draft (I-D) and then working to get that I-D adopted for further work. Anyone can write an Internet-Draft on any topic they believe is relevant to the IETF. There are different routes that an I-D can follow to be adopted, worked on and eventually become an RFC.
The vast majority of the IETF’s work is done in its many Working Groups. A Working Group (WG) has its own mailing list with most of its interaction, and all of it official work, conducted via email. A WG also has a charter that states the scope of discussion for the WG and its goals. The WG’s mailing list and any WG meetings are expected to focus only on what is in the charter. A WG is headed by one or two (occasionally three) **WG chairs**.
Working Groups are organized into one of seven areas, Application and Real Time (art), General (gen), Internet (int), Operations and Management (ops), Routing (rtg), Security (sec), and Transport (tsv), with each area overseen by one to three **Area Directors** (AD).
The day to day work of WGs revolves around Internet-Drafts, those that have been proposed for adoption and those that have been adopted, and over time the WG shapes the latter into RFCs. Decisions within WGs, as with the broader IETF, are taken by ‘rough consensus’ and not by voting. It is the role of the WG chair(s) to determine when rough consensus has been reached. When a Working Group has finished with an I-D and is ready for it to become an RFC, the I-D goes through a process to ensure that it has approval from the appointed technical leadership and the consensus support of the IETF as a whole.
The other routes for an I-D to become an RFC are as the output of some of the leadership bodies, Area Directors can sponsor an I-D, and there is an independent submissions process.
For an RFC to become a Proposed Standard or Internet Standard there must be at least two independent and inter-operable implementations, and the RFC must have full IETF consensus.
The IETF has policies about Intellectual Property Rights (IPR) that are designed to ensure that Working Groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process.
When an I-D has cleared all the hurdles to become an RFC it goes through a professional editorial process and is then assigned a number, published in a range of formats, both human- and machine-readable, and deposited in libraries and archives.
The IETF holds three week-long meetings a year with the primary goal of helping Working Groups get their tasks done, and promoting mixing among the WGs. In-person participation at IETF meetings now averages between 1000 and 1500 participants. These meetings rotate through Asia, North America and Europe each year, though the IETF occasionally meets outside of these regions.
IETF meetings are very different from standard computer industry conferences as there is no exposition hall, no sales staff and the sessions are mostly meetings of existing or proposed working groups who meet to discuss their ongoing work. There are generally eight concurrent tracks of WG sessions which are scheduled so as to reduce the number of scheduling conflicts for related WGs.
WG sessions at IETF meetings are not decision making and any consensus reached during a session must be referred to the WG mailing list to see if it has consensus support across all WG participants, not just those that were at the session.
To assist newcomers there are tutorials and networking sessions, and often there is a social event open to all participants. Additionally there is a plenary session with no other concurrently scheduled sessions, for the IETF to meet as a whole and where the various leadership bodies report on their activities and take questions from the floor.
All sessions have remote participation support and recordings of the sessions are posted on YouTube soon after they are recorded. The full proceedings of all IETF meetings (agenda, sessions materials, recordings, chat logs, etc) are archived and permanently available online after the meeting.
IETF meetings are operated on a cost-recovery basis and participants are charged a fee to participate whether in-person or remote as sponsorship income does not cover the full cost. There is a “no questions asked” remote participation fee waiver available to anyone for whom the fee would be a barrier to participation.
Individual Working Groups can choose to hold interim meetings outside of the regular IETF meeting cycle. These are generally remote only and are always free to participate in.
For further information, see Meetings and events