Ethical Analytics, Please

A couple of weeks ago, The Wall Street Journal ran an article entitled:
���You Give Apps Sensitive Personal Information. Then They Tell Facebook.���.

More accurately, there are some developers who:

Use analytics services offered by firms (e.g., Google, Facebook) that some people believe behave unethically
Send personal data ��� such as whether the user is trying to get pregnant ��� to those analytics services

I hold out some hope that the developers fought these decisions and were overruled
by pointy-haired bosses.
Alas, I fear that too many people focus on what is being sent to their own
Web services and do not think through what is being handed over to analytics
services. And, since many places outsource analytics collection and analysis,
privacy and security concerns can get magnified.

Fortunately, or perhaps unfortunately, I have not had to deal with analytics
much personally. If I were implementing analytics, I would fight tooth and nail
to do so ethically. Here are some of the things that I would be advising.

Own the Analytics Server

The biggest problem that people will have with what the Journal reported
isn���t that apps collect private information. The problem is that they are perceived
to share that private information with the likes of Facebook and Google. Facebook
in particular has been slipshod, at best, over the years in terms of data privacy.

While you as a developer might think that Google and Facebook don���t look at your
app���s analytics data, and while it���s possible that this is true, the perception
is that you���re sharing the analytics data with Google and Facebook. After all,
you���re sending it to their servers.

Ideally, analytics wind up being managed by some server that you control directly.
The most likely option for that is for the analytics to be sent to some server
that you provision by one means or another (Docker, VPS, etc.). This implies that
you license the server and host it yourself, which is more complicated than simply
outsourcing it. However, that complexity should be manageable and would greatly
reduce the privacy concerns that other parties have with your analytics.

A theoretical option ��� one that I suspect may not exist ��� would be
end-to-end encryption (E2E) of the analytics data. The machines that allow you
to examine the analytics, generate reports, and so on do not have to be the
same machines that are collecting the analytics from your apps. In principle,
the ���middleman��� servers that collect the analytics could be collecting encrypted
payloads of analytics records. A separate ���analytics analyzer��� that you operate
yourself would collect those records, decrypt them, and let you see the results.
The ���middleman��� servers could then be an outsourced service, with the encryption
preventing that provider from getting at the actual analytics data itself.

Encrypt Data In Motion

Speaking of encryption, ensure that the app���s communications to the analytics
server is using an adequate level of TLS or other on-the-wire encryption, so that
nefarious people do not sniff on your network packets to steal information in
transit.

Only Log Constants

I suspect that most users would be reasonably comfortable with you recording
information about what ���screens��� (activities, fragments, etc.) the user visits
and including that as part of your analytics data. I suspect that most users
would be far less comfortable with you recording their location (e.g., GPS fix).
Unfortunately, there is no easy way to automatically detect that the app is
logging sensitive data.

However, you could try to enforce that you only log constants. For whatever
client-side API the analytics service offers, create a Lint rule that will complain
if you try logging something that is not a string literal or string constant.

(and hopefully there is a way for Lint rules to detect Kotlin string interpolation���)

Obviously, this would block far more benign things than logging user locations.
However:

It is safe to say that hard-coded constants are not going to contain user-sensitive data

Automatic detection is much better than relying on manual audits that may never happen

Opt-In (Or At Least Opt-Out)

My guess is that current (e.g., GDPR) or future legislation will require apps
to allow users to control whether analytics get collected or not. Ideally, you
���get ahead of the curve��� and offer this now. Ideally, it would be an opt-in
choice, so the default is that analytics are not collected. At worst, make it
an opt-out option in your PreferenceFragment or other settings screen.

Decline Unnecessary Metadata

The analytics client library might provide APIs to automatically collect lots
of data about the environment: device model, OS version, screen resolution, and
so on. We see this a lot with crash logging, but analytics may offer to collect
similar stuff.

Try to minimize this. In particular, try to stop the collection of metadata
that you are not going to need.

While fixed values like device model are not user-sensitive, too much metadata
does start to make it possible to identify users across devices. The same sort
of stuff that Panopticlick uses for Web
browsers could be collected by analytics libraries in a native Android app.

Use an Open Source Client Library (and Vet It)

Try to use services that open source their SDKs. This allows you or
some consultant to examine the library and
see if it is doing something that you or your users might regret.

With luck,
somebody else has already performed that analysis and has published a report
that you can use. Just bear in mind that any such report will be for a specific
version of the SDK, and so periodically you will need to find a newer report
or vet the updated SDK yourself.

I know that there are some open source analytics options, and so most of what
I recommend here should be possible. And, I will admit that this is more work
than a lot of organizations will want to deal with. With luck, an ethical
analytics service will emerge that emphasizes these sorts of features, and perhaps
more, to help you avoid charges of invasions of privacy.

But, in general, treat your analytics data the same way that you treat your
���real��� data. And, treat your users the same, from a privacy and security
standpoint, for both types of data. Do not consider analytics privacy and security to be something
that you can ignore��� unless you elect to skip analytics outright.