Liveblogging Sidewalk Labs’ Master Innovation and Development Plan, Entry 33: The MIDP Volume 2, The Innovations, Chapter 5: Digital Innovation, Parts 1 and 2

Our journey of self-discovery and digital innovation continues…

Previous Master Innovation and Development Plan liveblog entries and relevant documents available here

Part 1: Providing More Affordable and Flexible Digital Infrastructure (pp. 384-399)

I’ll leave it to others to discuss the technical merits of Sidewalk Labs’ plan in Part 1. #notmyfield

Goal 1: Expand opportunity with ubiquitous connectivity (pp. 386-393)

I will note, however, that it’s always good to be the company that comes up with dominant standard, which is what its Super-PON (Passive Optical Network) seems to be an attempt at.

And would you look at that: it’s a Google Fiber technology.

This would seem to be an enormous conflict of interest, and one that is not disclosed in the report.

  • Why did Sidewalk Labs choose this technology over other technologies?
  • How does it compare to other potential competitors?
  • What happens if Google’s preferred standard doesn’t become the norm?
  • Can we stop referring to Sidewalk Labs as an independent company now?

Goal 2:  Reduce installation and maintenance costs with an “urban USB port” (pp. 394-397)

Another standard; another technology that Sidewalk Labs wants to deliver. They call it “Koala.”

  • What would be the effect on these neighbourhoods if Koala doesn’t become the industry standard?
  • Would it be a proprietary standard?
  • At what stage is this technology? Sidewalk Labs says it “has designed” it. Is it ready to go? The answer is not clear from this document, and it really should be.

Goal 3: Use distributed credential infrastructure to protect privacy (pp. 397-399)

Again, #notmyfield; would be interested in an independent evaluation. I’m just happy they don’t mention “the blockchain.”

Part 2: Setting Data Standards That Are Open and Secure (pp. 400-413)

I’ll defer to others who know more about the technical aspects of these issues. I’ll only note that this section discusses open data issues only in the context of security concerns (p. 402). Which is fine as far as it goes, but, again, should public surveillance data be open to everyone who wants to see it (assuming it should be collected in the first place)?

Also, as I’ve noted previously, this emphasis on open data standards reflects a philosophy of government that assumes that competition for the provision of public services is always and everywhere a good thing. This is a perspective that, while not indefensible, requires a wider public debate over the role of private service providers and competition in municipal services.

As with every policy issue, there are costs and benefits to such an approach (e.g., the bureaucracy needed to assure a fundamental level of quality control over competing private service providers), but the main point here is that this type of policy setting should not be treated as a technical exercise.

On bureaucracy

That last point, on the need to ensure quality of service providers using this system, highlights an important flaw in Sidewalk Labs’ overall plan. Namely, the hugely underestimate both the cost and size of bureaucracies that would be needed to oversee, regulate and maintain these very complex systems. As we saw with the WTMA proposal, none of them are seriously costed out and no employment figures are presented. With the data standards case, we see yet another example of this tendency.

On Sidewalk Labs’ role in data standards

The paragraph on page 402, which commits Sidewalk Labs to work with others to implement tools “to achieve its goals for standards and security…” doesn’t answer the question. It focuses on the tools, not the standards. How will the standards be set? Hopefully this question will be answered below.

Goal 1: Enable third- party innovation with published standards (pp. 403-407)

  • Data “must be publicly accessible to improve upon, build on top of, or even replace.” (p. 403)
  • New governance/standards alert: Proposal: Sidewalk will choose the standards, either adopting existing ones or working to create them (p. 403)
  • Proposal: publicly accessible data by default.
  • Proposal: software to integrate with these systems would be open source. (p. 403)

Its likely standards (p. 304) #notmyfield:

  • GTFS Realtime, a standard for reporting the location of public transit vehicles within the neighbourhood in real time (see sidebar)
  • General Bikeshare Feed Specification
  • (GBFS), for reporting the availability of bike-share bikes and docks
  • Brick, a standard for describing building infrastructure, including HVAC systems
  • IFC, a standard for building information modelling, along with the Linked Data extensions
  • OpenStreetMap, a representation of roads and other public realm infra- structure
  • CityGML and CityJSON, standards for describing building shapes and sizes
  • OpenTraffic and OpenLR, emerging standards for describing traffic and street segments
  • Public Life Data Protocol, a standard from Gehl Institute on the use of public space

APIs would be public/open.  #notmyfield

Goal 2: Use best-in-class resiliency and security (pp. 408-413)

#notmyfield. Would love to hear independent technical analyses.

I will note that this is going to be a major pain in the neck since ubiquitous surveillance and networking means a target-rich environment for problems. The district’s maintenance department will have to include both people to fix cracks in the pavement and bad code. This is why it was essential to see a plan for a staffing breakdown by proposed agency.

Sidewalk Labs commits to “Responsible AI” (p. 411). Again, #notmyfield, but here are the principles they’re promoting:

Fairness and equity; Accountability; Transparency and explainability; Relevance; Value alignment; Respect for human dignity.

Data localization

or “data residency,” as it says here (the report contains two mentions of “data localization”, and five of “data residency”)

Sidewalk Labs commits to using its best efforts at data localization – for storage, process, and communication – as long as there are Canadian-based providers who offer appropriate levels of security, redundancy, and reliability. To the extent that it is deemed infeasible to store data solely in Canada, Sidewalk Labs would be transparent about such a decision. (p. 412)

Three caveats here: “best efforts”, and “appropriate levels of …” are the most obvious. However, this statement only binds Sidewalk Labs, and not the “countless” other companies that would be using this data.

This omission is in keeping with its October 2018 draft data governance proposal, in which it said “Sidewalk Labs does not believe that it is sensible to impose a data localization requirement for innovators in Quayside.” (Digital Governance Proposals for DSAP Consultation, p. 35)

It helps to read the supporting documents, doesn’t it?

Sidewalk Labs also commits to following the law of the land in this area, so, thanks?

Part 3 tomorrow…

This entry was posted in Quayside and tagged , , , , , , , , , . Bookmark the permalink.