The @EUCommission wants to combat distracted driving. Starting this month, new #cars ship with an obligatory driver-facing camera that scrutinizes eye movements [1].
The law mandates recordings be only used to minimize harm on the road. Yet time and time again, we've seen tech companies knowingly break laws. It's often just the cost of doing business.
And it's a hell of a slippery slope:
"Once the lens is in and the software is running, the open question stops being whether cars can watch their occupants and turns into what else that watching should cover." [1]
But this is an opportunity. As @pluralistic writes:
"No one gets to keep the math used to calculate the load stresses on the joists holding the roof over our head a secret. We wouldn't tolerate secrecy in the characteristics of the alloys in those joists, or even the wires carrying electricity through the walls. We should not tolerate secrecy in how our digital infrastructure works, either." [2]
The argument to require car manufacturers to #opensource software for sensitive systems like this has never been stronger.
@edri we have a game plan for this?
@tastyraspberry @edri
I don't want to be a party pooper, but I'm not sure the analogous action is to release source code.
The structural engineers are revealing proof that their structure meets requirements based on measured properties of the materials, but I don't think it goes into detail like proprietary manufacturing processes for those materials.
I think source code would be more analogous to a manufacturing process.
That isn't to say that there shouldn't be a requirement to publish software specifications and test results - I think that would be closer to the burden of proof placed on structural engineers.
In fact, automotive applications are among the more highly regulated areas of software engineering, and processes are expected to meet certain guidelines, although I don't know how those guidelines have responded to technologies like those under the AI umbrella.
But I'd certainly welcome greater transparency about the capabilities of embedded software systems. I'm particularly concerned about remote access and data harvesting, and I can't say I'm very keen on the number of previously unknown vehicle brands now available.
@GerardThornley @edri
That's fair, it's not a perfect analogy. But I think it helps get the point across that there should be a reasonable burden of proof in the first place.
And because software is extremely dynamic, external audits to check compliance with guidelines cannot be enough. The more people scrutinize your code, the more secure it gets; anyone can write software secure enough that they themselves can't find an exploit.
It's kind of absurd we haven't mandated this already.
@tastyraspberry @edri yeah, I agree it's a more dynamic situation - updates mean one publication won't remain relevant for the life of a product, and certainly where interfaces are publically accessible (i.e. wireless) there is a much stronger argument for at least requiring external audits.
Edit: when I say external audits, I don't just mean a vendor selected box-ticker.
@tastyraspberry @edri
I'd be cautious about things reaching a point where all vendors end up using the same implementation, as that would increase the consequence when (and I mean when) a security issue is found.
@GerardThornley @edri true, a monoculture has its own problems..