[Make-wifi-fast] Car tire tracking

[Dave Taht]

On Wed, Nov 21, 2018 at 9:17 AM David P. Reed <dpreed at deepplum.com> wrote:
>
> I think everyone who works in "wireless", especially mobile wireless, should become well aware of privacy concerns.
>
>
>
> Privacy isn't just about secrecy, but about how information gathered by sensors is used by others. Now that it's trivial to gather terabytes of personally sensitive information and analyze it, we have to live in a Surveillance Society whether we like it or not. My own thinking (admittedly anarchist-libertarian) is that Norms need to grow, because Laws can't. Engineers (the ones who design and maintain systems) have professional responsibilities for the societal impacts of their systems. THey are not allowed to subcontract that to the people who specify or regulate their output.
>
>
>
> So if we know how to, or can invent a way to, maintain privacy better for all (users and bystanders), we really must.
>
> The shareholders/owners of profit-maximizing companies won't, and the government (even the elected one) won't.
>
>
>
> Which is why I am following up on tire pressure gauge unique addressability. Anonymous car presence detection is a whole 'nother thing.
>
>
>
> By the way, Dave, I'm sure you know that the WiFi MAC is the technology standard of choice for inter-vehicle communications in the Transportation departments and ministries of the world. One thing to argue for is to require MAC address randomization and periodic (every 10 minutes?) changes.

Well, on this front it's worse than that. Any even semi-persistent
connection can do you in; cell phone towers are the most common
tracking means today. Google always knows where you are, and what
speed you are traveling at. I would certainly like to have a gps that
didn't phone home but those have been nearly wiped off the market.


>
>
>
> Convoying in the Smart Car and Autonomous Car industries is an important design goal. That requires some kind of "addressing" but it really should be non-unique, anonymizing. That follows the standard Principle of Least Privilege in systems architecture, which every engineer of information and control systems should have at front of mind for new designs.

It boils down to trust in google. It wouldn't surprise me - years from
now - to discover that law enforcement already could access this data.
That said, our country is not a place where I currently worry about it
overmuch, were it some places I've lived, and a target, I would.

Given "autonomous" cars phone home... anyone here ever read "safe at
any speed" by Larry Niven? Lessons there, too.

I'm going through a terribly retro phase. I got a boat. It doesn't
have any tech later than 1976 in it, powered up, most of the time. I'm
looking to replace the bluetooth enabled radio entirely... once I get
the diesel repaired and the autopilot working again (can't find one of
those that isn't also cross connected, either)

>
>
>
> Fortunately, nearly all users of the 802.11 protocol assume that the MAC address can dynamically change, and the hardware in the 802 standard devices all seem to support it.
>
> IPv6 actually supports (and IETF best practices encourage) randomization of the lower 64 bit half of the 128-bit address, with the upper 64 bits being the coarse grained routing mechanism, including subnetting. So one can indeed randomize at the IPv6 level for privacy, given the design that allows multiple v6 addresses per interface. You can have different "personae" in IPv6.

Meh, that 64 bit prefix is pretty self identifying, and it takes
technologies like mosh to survive changes going on underneath. Better
would be to work towards more apps running locally, off of local
resources.

But that's not the way the world is going. A whole generation has
grown up with "streaming" and downloading your own music, even, is
becoming a thing of the past. We are tied to the feed....

>
>
>
> This good-privacy-in-the-design can get broken by thoughtless engineering.
>
>
>
> That's why I spread the word.

It helps to keep trying.

>
>
>
>



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740