From: Dave Taht <dave.taht@gmail.com>
To: dpreed@deepplum.com,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Car tire tracking
Date: Wed, 21 Nov 2018 13:01:15 -0800 [thread overview]
Message-ID: <CAA93jw7fR4ZA8=xTfw0jJc0gC785tMzfdO-O3vJFg5o2CiQZXw@mail.gmail.com> (raw)
In-Reply-To: <1542820640.672319900@apps.rackspace.com>
On Wed, Nov 21, 2018 at 9:17 AM David P. Reed <dpreed@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
next parent reply other threads:[~2018-11-21 21:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1542820640.672319900@apps.rackspace.com>
2018-11-21 21:01 ` Dave Taht [this message]
2018-11-21 21:26 ` Jonathan Morton
2018-11-22 21:22 ` Dave Taht
2018-11-22 22:42 ` Jonathan Morton
[not found] <1542820669.4117191@apps.rackspace.com>
2018-11-21 21:06 ` Dave Taht
2018-11-21 23:13 ` David P. Reed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw7fR4ZA8=xTfw0jJc0gC785tMzfdO-O3vJFg5o2CiQZXw@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=dpreed@deepplum.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox