Thread by @VTeagueAus

1/7: Hang on a minute, I have misunderstood something important. In my blog post I wrote of Tracetogether "Whenever you're within Bluetooth range of a person, you send them your ID, encrypted with the public key of the Singaporean authorities."
Is that what everyone else thought?

2/7: But their whitepaper actually says: "TempIDs are cryp-tographically generated by the backend service."
bluetrace.io/static/bluetra…
Those encrypted IDs you send out all the time are AES encryptions, generated for you by a central server, using a key you don't know.

3/7: The public-key-based system I thought they were using is described as an alternative that isn't implemented because of its computational burden. They add that this allows health authority monitoring by "logging the issuance of daily batches of TempIDs." Daily is a key word.

4/7: It seems to me this protocol difference has two huge implications:

a. You have no idea what is in those encrypted messages your phone sends via bluetooth, even if you inspect the source code for the app running on your phone.

5/7: b. Daily logging allows govt to detect whether you have the app running at least once each day. A slight update to hourly or more frequent downloads of encrypted IDs would allow more fine-grained constant surveillance of whether the app was running on your phone.

6/7: So now more than ever we need some clear explanation from the Australian government of what they're planning for their app that is 'based on' TraceTogether. Will they commit to phone-based generation of encrypted IDs? #auspol #COVID19au

7/7: It's an educational experience for me because, even though the source code is openly available, one of its most privacy-critical features remains obscure.

Was I the only person confused here?