[continued from previous message]

I gather it's even more complicated than that -- they didn't refuse him,
they didn't reply at all in time for his trip. US visa processing has apparently been getting slower in the past couple of years but it seems particularly slow for cryptographers. Bruce Schneier blogged about it in
May:

https://www.schneier.com/blog/archives/2019/05/why_are_cryptog.html

------------------------------

Date: 21 Jun 2019 18:19:57 -0400
From: "John Levine" <johnl@iecc.com>
Subject: Oh, darn, maybe cell phones don't really make you grow horns
(RISKS-31.30)

Not so fast -- it's not a horn, it's at most a bone spur, and there's lots
of reasons to be sceptical about the whole thing, reports Ars Technica.

https://arstechnica.com/science/2019/06/debunked-the-absurd-story-about-smartphones-causing-kids-to-sprout-horns/

[PS: nonetheless, your mother's advice to stand up straight remains valid.]

------------------------------

Date: Sat, 22 Jun 2019 13:45:19 +0300
From: Amos Shapir <amos083@gmail.com>
Subject: Re: Info stealing Android apps can grab one time passwords to
evade 2FA protections (RISKS-31.30)

Please correct me if I'm wrong, but I always thought that the idea behind
2FA is to increase security by conducting a part of the transaction via a *different* device.

If an SMS confirmation message is sent to the same device from which a user
is attempting to login, there's no added security at all, I wonder why it
would take a hacker's application to make anyone notice that!

------------------------------

Date: Sat, 22 Jun 2019 16:04:22 +0100
From: Martin Ward <martin@gkc.org.uk>
Subject: Re: Auto-renting bugs (RISKS-31.30)

We do not know how it had happened, but someone else took the car on
your reservation ...

Its never a good sign when a company which runs software that has direct control over the engine of a car says about any part of their software: ``We
do not know how it happened!''

------------------------------

Date: Mon, 24 Jun 2019 00:10:15 +0100
From: Toebs Douglass <risks@winterflaw.net>
Subject: Re: In Stores, Secret Surveillance Tracks Your Every Move
(RISKS-31.30)

I worked as a senior software engineer for a year for one of these
companies, on the core product.

I was involved in installation of the first Bluetooth-based system.

The article is technically inaccurate, whilst being spiritually correct, but misses the not-quite-so-obvious huge issue in favour of the much smaller presented issue, I suspect the author prolly isn't technical.

So, phone tracking was performed by two means, wifi and Bluetooth.

The article only covers Bluetooth, which was a new product at the time (2015ish). The main product used wifi.

Bluetooth beacons are very simple devices. They emit a signal with a unique ID. That's *it*. *Nothing* else. The devices have no network
connectivity, no storage, nothing. They just sit there and emit a unique
ID, and we used a battery driven unit. (Despite this, we managed to find vendors asking over 100 euro a unit.) We bought ours from alibaba.com.)

The key players making this all work are the apps on the phone.

Phone apps get to `wake up' regularly, and they can examine their
environment, and one of the things they can do is look around for Bluetooth signals. (It's been a few years now -- I remember there was something of a difference between Apple and Android, and so there was I think more unique
ID fidelity with Android.)

So what happens is the company publishes an API in the form of a library,
which app developers ingest into their software.

In particular, rather than trying to reach out to every app developer out there, deals are made with third party companies -- such as advertising companies -- who already publish their own APIs as libraries, which are
already ingested by lots of different apps. These third companies companies ingest this library into their library, and hey presto, as people's phones auto-update you're very quickly installed on goodness knows how many tens or hundreds of millions of phones.

This really is the bigger story, but the article has missed it. Apps really are random bits of software strangers run on your phone. Users have no idea which sketchy friend-of-a-friend-of-a-friend has just managed to get his API running on their phone. Simple solution to this : do not install apps on
your phone. I'm not kidding. People have the expectation they are buying a phone -- paying a lot of money for a phone -- to put apps on it and use
them, and that it must be possible to do this, because they've spent a bunch
of money on it. This is not the case. The time when apps could be used on phones has passed. You cannot now buy a phone to run apps, because it is
not safe to do so. This means phones no longer make sense. It is in fact I would say a tragedy of the commons.

If you *are* going to do this damn silly thing, don't do it in this damn
silly way. Root your phone first and (for the love of God) get a firewall installed -- and *don't* log into Google on your phone, not ever. Never use
a service in an app you can use on a website, again, for the love of God.
And never, NEVER, *EVER* give ANY company your phone number. These days
it's the key fact around which third-party data collation revolves. Email addresses aren't so bad because it's easy to get disposable addresses, but phone numbers cost money, so they don't change so much. Email addresses
need to be used like passwords -- you have a different email address for
every site or app, just as you have a different password. This helps break third-party data collation. Good email hygiene is the same as good password hygiene. Do not reuse passwords. Do not reuse email addresses.

(I run most apps now in VirtualBox, on x86 Android. Being able to reinstall fresh versions of the OS when they come out also handles the upgrade
problem. Only one app I care about has no x64 version (lookin' at you, Revolut). I'll also be buying the Librem 5 when it comes out, which is real Linux, not Android, on ARM on a mobile form factor and it should have enough umph to run a VirtualBox VM, which being on ARM can run the usual ARM based APKs. Learn to sideload, BTW, and use Raccoon to get genuine APKs off the Google App Store (which I refuse to call Google Play -- an astoundingly
silly name invented by the kind of marketing people Douglas Adams had in
mind with the Sirius Cybernetics Division. I'm surprised Google haven't yet described their app store as your plastic pal who's fun to be with.)

The Bluetooth beacons we had, had a pretty good range. We aimed to have one per floor in pretty large stores -- that was the granularity of extra information being aimed for in this first deployment; the progression
through floors of a phone. With an Android app you could get signal
strength info (as we had an app to configure the Bluetooth beacons), but I don't know if that was true for the ``wake up and look around'' time of a phone, rather than an actual app.

Bear in mind also that I think in general Bluetooth is turned off on phones
-- however, I never saw any numbers for this, so I could be completely
wrong.

The wifi based system was rather different. With this, there are wifi
routers located (fairly carefully) around a store. Phones emit wifi signals periodically, which contain an inherent unique ID (can't remember which now
-- prolly MAC address) and the signal strength is measured at each router.
The store is logically divided up into zones, and a machine learning system, based on the signal strengths at the routers, decides which zone the user is in, for any given signal. Zone sizes vary, based on customer preferences
and technical and cost limits; the more routers near an area, the smaller
and more precise the zones can be.

Actual physical signal triangulation is *not* used. It was tested, before I joined, I'm told it just didn't work. Far too much signal strength variability. Received phone signals vary enormously, second by second, in a normal shop environment. There's just a lot of physical (people moving
around all the tie, in and out of the way of the signal) and
electro-magnetic stuff going on.

During my time there a wifi specification design flaw was uncovered,
where-by you could force a phone, even with wifi turned off as I recall, to emit a response -- so now you didn't need to passively sit there and wait
for the phone wifi to emit a signal; you could coerce the phone into doing
so. This could matter somewhat. Some phones kindly emitted a signal every second (iPhones), others only one a minute. A person can walk a long way in one minute.

This however probably crossed the line of local law, which said something
like you're not allowed to actively, overtly act upon other people's computers/phones. In any case, it wasn't used before I left.

IMHO, wifi tracking is borderline viable as a product. I saw test cases
where someone would walk around an empty store with a known device (we had calibration data on a per-device basis, because they vary so much in signal strength), and report back to us where he was and when, and half of his
journey would be missing from the data. If you did it right, and were
careful, I'd say you could get a mediocre but still genuinely useful and
rather unique data set from it. Only problem is, I'd say 99.99% of the time customers don't know it was going on (let alone understand what was
happening), and that's what makes it unethical. The basic rule is that when you do stuff with people, they have to choose to do it and they have to understand what they're choosing to do (except in self-defence, of course).
You can't force people, and you can't deceive them, Most of this
surveillance capitalism we see is unethical because the people being tracked
do not know what's going on, or understand. T&Cs are a legal fig leaf, not
an actual genuine communication to the user of what's going on such that the user is then known to understand -- the ethical obligation of the company to *actually ensure* users understand is *not* met. Users don't know, and
that's why it's wrong.

Topically, this article has just been published in the WaPo;

``It's the middle of the night. Do you know who your iPhone is talking to?''

https://www.msn.com/en-us/news/technology/its-the-middle-of-the-night-do-you-know-who-your-iphone-is-talking-to/ar-AAC1Wvl%23page%3D2

``In a single week, I encountered over 5,400 trackers, mostly in apps, not including the incessant Yelp traffic. According to privacy firm Disconnect, which helped test my iPhone, those unwanted trackers would have spewed out
1.5 gigabytes of data over the span of a month. That's half of an entire
basic wireless service plan from AT&T.''

------------------------------

Date: Mon, 14 Jan 2019 11:11:11 -0800
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)

The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
comp.risks, the feed for which is donated by panix.com as of June 2011.

SUBSCRIPTIONS: The mailman Web interface can be used directly to

subscribe and unsubscribe:
http://mls.csl.sri.com/mailman/listinfo/risks

SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line that

includes the string `notsp'. Otherwise your message may not be read.
*** This attention-string has never changed, but might if spammers use it.

SPAM challenge-responses will not be honored. Instead, use an alternative

address from which you never send mail where the address becomes public!

The complete INFO file (submissions, default disclaimers, archive sites,

copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
*** Contributors are assumed to have read the full info file for guidelines!

OFFICIAL ARCHIVES: http://www.risks.org takes you to Lindsay Marshall's

searchable html archive at newcastle:
http://catless.ncl.ac.uk/Risks/VL.IS --> VoLume, ISsue.
Also, ftp://ftp.sri.com/risks for the current volume
or ftp://ftp.sri.com/VL/risks-VL.IS for previous VoLume
If none of those work for you, the most recent issue is always at
http://www.csl.sri.com/users/risko/risks.txt, and index at /risks-31.00
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
ALTERNATIVE ARCHIVES: http://seclists.org/risks/ (only since mid-2001)
*** NOTE: If a cited URL fails, we do not try to update them. Try
browsing on the keywords in the subject line or cited article leads.
Apologies for what Office365 and SafeLinks may have done to URLs.

Special Offer to Join ACM for readers of the ACM RISKS Forum:

<http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 31.31
************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)