For context, there are two ways of doing digital contact tracing.
A centralised system which tracks everyone all the time and runs a central algorithm for deciding whether someone is at risk on all that data. This is what China, South Korea, and Taiwan have done. Advantage: it seems to work. Disadvantage: government has a database of literally everyone's movements. In SK they also use CCTV and other data, it's a nightmarish panopticon.
"Minimally disclosive" contact tracing. This keeps as much data as possible on the device and only share some of it with other devices or central servers. Obviously, designing these protocols is a balancing act between privacy and functionality. Different groups have designed protocols that make different choices there.
The two main competing protocols are DP-3T, on which Google/Apple have based their API and PEPP-PT / ROBERT which some countries including the UK have been building their solution. Until very recently, Germany was also using PEPP-PT but they have switched to DP-3T.
Both protocols make trade-offs between the amount of information which leaks and the usefulness of the tool. That's important. Installing an app based on either will strictly reduce your current privacy.
Both frameworks use pseudo-random rotating keys which are exchanged over Bluetooth. In PEPP-PT a central server manages a rotating private key which is used to generate a set of time-gated ephemeral IDs for each device. Devices exchange and log these IDs. When a health authority determines that someone is infected, they issue them a key which allows them to upload all their logged IDs to the central server. (Optionally, they can just allow them to self report which NHSX seems to be doing) The server is able to determine who the infected person's phone has logged a contact with and notify those people. A random sample of additional people also receive notification messages which their phones are able to discard as invalid decoy messages. Because relatively rich data goes to the server, real time data on interaction patterns of the infected is available and notification algorithms can be tested and tweaked. Since we don't know exactly how Bluetooth propagation and covid infection map to each other, this may end up being an important step.
In DP-3T, the keys are generated on the devices and IDs are stored only on the devices. If a central server authorises you to do so (based on a confirmed diagnosed infection), you broadcast the IDs of all the devices you have been in proximity to. All devices regularly download a list of IDs and check the list for one of their own rotating ID numbers. If they match, the user is notified and is able to pre-emptively isolate.
The second approach reduces the consequences of a nefarious central operator but at the cost of sharing more information with more people (since everyone sees the list of possibly-infected IDs). In other words, even in privacy terms, this is not a perfect approach either. That information can be used to carry out re-identification attacks and reveal infected users if certain conditions are met.
From a privacy point of view, I think many people would prefer the latter (possibly allow malicious attacker, if they are able to do certain not-so-easy things to determine that they were infected) since most people in the UK will not consider that deeply private and secret information about themselves. Many of my friends who got it have posted about it on FB, twitter, etc. The former, which gives a state actor more information seems like a greater breach of privacy.
A final point which I think is super important: we don't know if either of these minimally disclosive options work in practice. No-one has used them in the wild yet. If they both worked then we could say - DP-3T has fewer privacy implications, they both work, therefore it is strictly superior.
Since we don't know whether they both work (or even if either one works), we are instead left with a balancing act between privacy and usefulness which is not an easy one.
Of course, if due to API support reasons, only the OEM supported protocol can be made to work then regardless of any theoretical arguments, that is the one that we will need to use. I suspect we will know by the end of the weekend if their implementation works in practice.
I would like to see statutory safeguards put in place for this data. If they really need it then I get that, but it is important that if we do not have the technical safeguard we have legal ones.
(Also, Google/Apple had a difficult choice to make here because they operate everywhere. They had to pick something that they feel comfortable rolling out to their devices in every country.)