The drone configuration presented in my post on autonomous computational law vehicles (ACLVs) described the use of a transportation centric ontology (TCO) to govern flight behavior. A select number of concepts from that post were also reviewed in my “Robots, Drones and AI” panel at last month’s SLS E-commerce Best Practices Conference. Here I revisit some of the key points from that post and introduce a concept that I first talked about in the Conference: Security-by-design (SBD).

In my introductory comments to our (standing room only) audience, I explained that effective security was critical to everything we were going to talk about. Without security, without the operational confidence that it breeds, nothing else would matter. The robots, drones and AI (RDAi) would never achieve meaningful adoption if they could not be trusted. Their operational prowess is at least as large, if not eclipsed by the spectrum of liability associated with their malfunction.

Therefore, a significant portion of the security task is dependent on protecting RDAi from intrusion and integrity compromise (based, in part, on principles gleaned from FIPS 199). While we are already familiar with the concept of privacy-by-design, at the Conference I introduced the concept of security-by-design (SBD). A subset of SBD is end-to-end encryption (e.g., Signal Protocol), blockchains and lightweight block cyphers (e.g., SIMON and SPECK). Baking-in all of these principles into RDAi design ensures the operational risk profile is thoughtfully managed.

SBD is equally applicable to data-banks such as the TCO; securing them from intrusion and integrity compromise is critical. This means that SBD, to be effective, must be an end-to-end principle; it’s an ecosystem. It’s also a closed ecosystem, accepting only RDAi that are SBD compatible.

SBD is also a machine learning design paradigm. SBD-compatible RDAi learn and adopt behavior that syncs with what constitutes as “secure.” All of this learning is then uploaded to relevant ontologies that operate within the SBD ecosystem. The more the RDAi learn, the more secure the ecosystem becomes.

Finally, SBD is also a legal paradigm. It is a benchmark by which to measure whether a particular RDAi design was legally reasonable. Designers who fail to comply with its principles willfully take the risk of being hit with massive liability, both criminal and civil.

The SBD standard has intriguing possibilities. The early adopters, the RDAi designers who opt for using it from the very start, will be able to build their brands around trust, specifically operational confidence. This will not only be the critical vendor-differentiator down the road, but it will also be the platform for sustaining long-term RDAi market success as a whole.

***

Updates

May 11, 2017: Blog update: NVIDIA Isaac purports to offer a “high-fidelity simulation and advanced real-time rendering” virtual environment for training robots. At a glance, this technique appears to be compatible with the SBD principle I discussed in the post. Now, if that’s true, we might find that taking RDAi and running it through the Isaac simulator (and others like it) will serve as a useful step in designing SBD-compliant entities. So long as the manufacturing cost savings and time-to-market variables prove sufficiently compelling, deploying SBD-compliant RDAi stands to become an industry standard, which in turn (quite likely) would morph into a legal one. Stated differently, companies like NVIDIA are poised not only lead the charge in mainstreaming RDAi, they will find themselves setting an important part of the normative tone in RDAi, and may very well fuel an important aspect of the relevant emerging legal framework.

January 20, 2017: Bloomberg BNA reports that DARPA will use blockchain to strengthen network security. Widespread adoption of blockchain is a welcome, beneficial development since it can facilitate robust applications. For example, consider the following proposition: Not only can TCOs be secured by the blockchain, but let’s expand its use to RDAi identity management. This means that the same identity authentication principles used for humans could also be used with RDAi. From there we can see blockchain security for the TCO and RDAi equating with an efficient SBD profile, one that can be consistently measured and improved over time. And that’s not all. Syncing this effort with relevant identification best practices (e.g., NIST SP 1800-2b ES IdAM) will further strengthen SBD implementation in RDAi.

January 17, 2017: The FAA’s emerging drone-flying rules are prime candidates for computational law. (Most recently, the FAA has been updating flying rules over people.) The rule’s complexity and the frequency in which they are issued, coupled with their 3 dimensional quality (coordinates, altitude, objects) can and should be hard-coded to ensure operational compliance. The FAA should encourage manufacturers to adopt a “compliance-by-design” approach, which will help ensure operational safety. The same principle applies to DOT efforts towards autonomous auto makers. The DMCA’s TPM circumvention exemptions must never be allowed to apply.