On 03/22/2017 07:58 AM, Dave Pawson wrote:
> https://yro.slashdot.org/story/17/03/22/0535242/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware
>
> Assuming fair reporting, is this where we're going
> with all hw/sw systems?
>
>
I suspect the John Deere story is real enough; this is the second source
I've seen for it (and the first for some time). In answer to your
question, Dave, I think "Yes, and with the inexorability of a moving
freight train."
The IoT ("Internet of Things") is bound to remove the sovereignty of
individuals over their manufactured possessions, requiring license
agreements to be signed as part of the purchase of vital capital goods.
In media and telecom, we're already in this brave new world. In view of
the new telecom business models, the IoT amounts to a recognition that
there's a vacuum wherever there *can* be centrally-controlled firmware,
and such firmware can serve the interests of manufacturer, whatever the
manufacturer perceives those interests as being.
The farmers' ad-hoc approach to their problems with John Deere is
suboptimal in so many ways that it's more like a horrible example than a
model.
I've gained control over my router firmware, but it has been a costly
exercise. The time and effort required to gain full control over my
routers has convinced me that I have little hope of doing the same thing
for my toaster, much less my car, my cell phone, my smart TV, my alarm
clock, my furnace...
Routers are interesting cases because they are already participants in
the IoT, and because there are already alternative open-source
replacements for their internal firmware, such as DD-WRT and OpenWRT.
Of course, in installing open source firmware, I had to sacrifice my
router warranties, but that's a trivial matter. The manufacturers of my
routers have never put me in a position where I had to waive my
unconditional right to continue to operate my business, as the farmers
are said to claim they must do if they buy John Deere products. Is
that really the brave new world we want, or should we seek a more
mutually respectful power balance between consumers and the big-capital
entities that supply their needs? The recent Samsung, Volkswagen, and
John Deere overreaches are not the bulk of the stories, and some of the
untold ones are likely to be more horrifying. And if we're really
worried about hacker attacks on our infrastructures, how can we not be
at least equally worried about the innumerable software vulnerabilities
of our *personal* infrastructures?
This is fundamentally simple. It's about trust, and we should not trust
any business entity that insists it is the only trustworthy entity. I
think the main thing is to open up the firmware. It should be feasible
for me to outsource my privacy-and-control efforts. If I so choose (and
if I can find customers who trust me), it should be feasible for me to
become a source for such trusted services. If, as a customer for
manufactured goods, I must limit my purchases to products over which my
privacy-and-control contractor is prepared to take control, so be it.
Indeed, it is apparently the case that the routers for which OpenWRT and
DD-WRT are readily available sell better than those for which it isn't,
so I consider the model basically demonstrated.
Alas, the U.S. Congress is moving in the wrong direction on this kind of
thing. It is working to remove the onerous "fiduciary" status of
investment counselors, so that, at least as a legal matter, they are
free to serve their own interests over and above the interests of their
hapless customers. If there will ever be such a thing as an independent
individual privacy-and-control contractor, such a contractor will need
to be a fiduciary, as all practicing lawyers are. Only fiduciary
experts can be expected to figure out how to maintain the security of
private IT infrastructure, too, and probably even public infrastructure,
too. In my view, a large and diverse open market for the services of
such privacy-and-control fiduciaries might actually work.
If you feel this matter is off-topic with respect to XML, I'd be
interested to hear some specific ways in which it is *not* relevant to XML.
Steve Newcomb
