[I’m delighted to welcome Lilian Radovac back for another excellent piece on the <a href=“https://boingboing.net/2018/08/02/torontos-aural-panic-why-we.html”>digital surveillance shenanigans in Canada</a>, which aren’t always as showy as their stateside counterparts, but are every bit as worrying. In this piece, Radovac reveals the buried plan for a finance-sector managed, all-surveilling National ID card buried in the latest massive wedge of largely unread documents from Google spin-out Sidewalk Labs (<a href=“https://boingboing.net/tag/sidewalk-labs”>previously</a>) that is building a controversial, privatised city-within-a-city in Toronto -Cory]
In Sidewalk Toronto news, Sidewalk Labs has finally released its Master Innovation and Development Plan Digital Innovation Appendix. As with the 1,524 page MIDP before it, there's a lot to read in the DIA but a few excerpts already stand out.
All this just because Google wants to easily plug into someone else’s system to determine if you are worthy of living in their little patch of land without having to staff a few real people.
This suggests that people who are eligible for the small number of below-market-rate units in the development would have to register for a Sidewalk authorized Digital ID to apply for them.
I can understand where the banks are coming from, sorta. They have a legal obligation to identify their customers. For customers who expect everything can be done online, the existing ways to do this typically involve cross-referencing data held by multiple companies and to be done accurately might require use of the customer’s SIN (or SSN for Americans). Having your SIN passed around between multiple companies isn’t what anyone would consider an ideal situation. So while a centralized digital ID system sounds creepy, existing solutions aren’t great either.
That said, there’s a difference between a digital ID system that can be used voluntarily to identify you in specific situations with your consent, and one used to creepily surveil you without your knowledge, or which you are strong-armed in to using even when you’d really rather not identify yourself at all.
Good point. One of the problems is that SWL surveys a wide range of possible (and sometimes conflicting) approaches but doesn’t provide details about what they’re proposing for this development. In the services list, they do state that U-Prove is the existing standard they plan to develop. This paper suggests that, as of the time of writing, it may have vulnerabilities:
“We show that the revocation mechanism designed for U-Prove enables a system provider to efficiently trace the users’ activities. Namely, the Revocation Authority run the system provider may execute the U-Prove protocol in a malicious way so that: (a) the deviations from the protocol remain undetected, (b) the Revocation Authority becomes aware of each single authentication of a user in the whole system and can link them (regardless which attributes are disclosed by the user against the verifiers), c) it can link presentation tokens with the corresponding token issuing procedure (under some conditions).”
Thereby, the system described in the technical drafts of U-Prove does not guarantee privacy protection unless the system provider can be trusted unconditionally. In fact, a malicious provider may convert the Revocation Authority into a “Big Brother” installation."
Would love to know about more recent work on this.
