Android wallpaper images can threaten privacy | Hacker News Reader

Android wallpaper images can threaten privacy

fingerprintjs.com

197 pointsDaniel_sk76 comments

Although this is an interesting, novel method, there are so many fingerprinting capable APIs in native code that I don't think this matters much.

Many apps I use daily require internal storage permissions and a bunch of them drop random dotfiles with magical IDs in there. Xiaomi even dumps a world readable unique device ID on the emulated SD card. Not all apps require external storage permissions, but even then there's tons of APIs that can be used to fingerprint the device.

Google is trying their absolute hardest to reduce the fingerprinting surface but as long as system APIs that work with user content like these exist, there will always be something to fingerprint users by. If everything else fails, you could just embed a webview that uses all the javascript stalking we've grown so accustomed to.

It's sad but I don't think you can prevent native code from fingerprinting your device. The sandbox just isn't tight enough and users are too willing to give out permissions.

I can see Google using a predefined set of colours in some update instead of the raw colour values to combat this, but that's only one of many ways apps abuse their users' devices. Unless app stores kick out apps that fingerprint devices, I don't think we'll see any non-fingerprinted devices any time soon.

>Many apps I use daily require internal storage permissions and a bunch of them drop random dotfiles with magical IDs in there. Xiaomi even dumps a world readable unique device ID on the emulated SD card.

They're fixing this with soon with scoped storage api.

A decade later and they're implementing folder permissions...?

Better late than never! But.. yikes!

At this point, I am starting to feel permission fatigue.

Could fuchsia be the solution to this? It's a fresh start and no company is depending on any of its api. But I guess fuchsia is a flaw for its own because of google...

I would assume the opposite. Why a company which makes money from tracking users for many reasons develops an OS which prevents tracking?

My guess is that it'd be an OS which would perform tasks Google needs to stay as Google better than Android, and Google may sell these capabilities to devs to further enhance their bottom line.

Google cannot change the Linux kernel like they control Chromium or the most of the Android, so with Fuchia (or its kernel) they are more in control once again.

Again What has google done to make Chrome more privacy friendly when they have every control? I guess the answer is 0. So even with Fuchia I think it will be worse than Linux.

That was my whole point.

Google is trying their absolute hardest to reduce the fingerprinting surface

Really? If true, it's so they will be the only source of such tracking info.

Google is like the one eye, it never stops seeking, looking, tracking you.

> If true, it's so they will be the only source of such tracking info.

So... they're reducing their competition? Sounds anti-competitive. They wouldn't know anything about that though.

"trying their absolute hardest to reduce the fingerprinting surface"... for anyone else :)

Yes, they indeed are. Though, it could be argued that Google doesn't want anyone else fingerprinting 3B+ Android users other than themselves. Most of their apps ("gapps") are pre-installed with backdoor privileges that can bypass sandbox restrictions in-place for every other (non-OEM) app.

> Most of their apps ("gapps") are pre-installed with backdoor privileges that can bypass sandbox restrictions in-place for every other (non-OEM) app

Hadn't heard about this. Like what?

See: https://grapheneos.org/usage#sandboxed-play-services

Ah, I see, thanks. I thought you meant like gmail, not play services.

i would be kind of surprised if the gmail-app didn't have more access than other email clients

> Unless app stores kick out apps that fingerprint devices, I don't think we'll see any non-fingerprinted devices any time soon.

Talk about throwing out the baby with the bath water on making Apple and Google the equivalent of government with the ability to define the rules on all software that anyone can exist without even considering using actual government :(.

Not saying this would be easy but another approach would be to use references to the colors instead of the actual colors. Other color related APIs would have to be updated to accept the references or, if you wanted to add more flexibility, compound color manipulation operations. It would be the responsibility of the renderer, which I am assuming is protected as I am not familiar at all with android, to compute the final color and not reveal it to the app.

It wouldn’t be a perfect replacement for actual color values but it would give more flexibility while not revealing the value.

Reason #481 virtualization-capable phones would be a huge privacy win.

Or just use much lower precision for the color

Android's theming system does not have the ability to dynamically re-set <color> IDs. And, assuming they managed to do so and keep the reference unaccessible to users (because then you could just do context.getColor(android.R.color.material_you_color_primary) to resolve it), you can still access it through reflection.

Chasing this dragon is exhausting, and seems to be requiring more user-hostile measures that prevent end users from using their device fully.

Can there be a legal frame work where Google and Apple just take your source code and builds it on their farm, and app review is a source-code level review? And Developers that refuse to do these things are just blocked from developing on these platforms?

I don't believe there is any company willing to leak their closed source production source code to anyone. And even they do, it is highly likely there are some dependency they use did not come with source at first place. That wouldn't work in any means.

Handing over your signing keys, your IP, to a company that cannot even be arsed to review apps properly? What could go wrong?

> Many apps I use daily require internal storage permissions and a bunch of them drop random dotfiles with magical IDs in there.

Why can't these apps be restricted to certain folders you need them to access?

I also feel like apps which abuse file system permissions to modify the user file system (e.g. create files useless to the user), let alone the system file system should be reported and banned.

Any app should have full rights to write anything to a special directory dedicated for it however. But you can set up a script to purge it or delete specific files from it on a schedule.

Isn't this policy how Termux was neutered?

Google is working on that with scoped storage, but a lot of old code doesn't work with that yet and dropping the API would break tons of apps. They've been trying to kill general external storage for this reason since Android 4.4, but every time there's huge blowback from users and developers because "they're trying to take our file explorers" or whatever.

In KDE Connect you already need to use the modern API to pick a location for file browsing and it works fine. I picked the entire virtual storage area and that's what's available through remote browsing, but I could've picked a single directory. If all apps supported this, we'd be a lot better off.

Of course, there's a perverse incentive to put off the transition as long as possible so that stalking libraries can make more money. I think Google is moving very closely to forcing the new API with the release of Android 12, which would mean that most app developers can't really put off updating much longer.

They could have made the transition much more straightforward by just making the permissions system more granular (i.e. let the user pick a directory instead of simply asking storage access yes/no) and leaving the existing file APIs intact otherwise, just throw a permission error if you're accessing anything outside of the granted scope.

Instead they tried to force through a completely new API that isn't compatible with anything that came beforehand, isn't compatible with code that must have a classic file handle and cannot easily be changed (native libraries, parts of the Android API itself), introduces exciting new bugs and has worse performance.

Plus at the same time they seem hellbent on hiding the true, original location of files on the file system, so a) if an app needs to ensure continuing access to a file, it needs to copy it to its own storage (Yay, dozens of copies of the same file) b) this breaks any usages and file formats that don't consist of a single, atomic, fully standalone file (HTML files, playlists, subtitles, multi-part archives, ...).

The "new API" has been available since Android 4.4 and was encouraged as default approach because it also worked with cloud storages, Chromebooks and other environment.

Please don't write this misleading stuff, nothing about SAF is new. It's just that it was easier for developers to hardcode paths and crap all over the storage than to open the file dialog.

Using the SAF is quite a bit more complex than simply prompting the user to pick a folder and then using that as your base path, though.

Plus once apps developers were more seriously forced to use the SAF by recent Android versions, I've seen enough bug reports about actual shortcomings and performance problems of the SAF API on the Android bug tracker even for more recent Android versions.

And Google's simultaneous insistence on only allowing inter-app file sharing via content://-URIs has definitively broken all multi-file file formats, with no official replacement available.

I don't think other concerns are less important to "privacy" concerns.

Each restriction just makes certain ideas/project impossible or less ideal [1].

Honestly as an Android dev, I will prefer devices come with these restrictions by default. Then there should be a "I don't give a f*ck" button in the device developer options settings.

The option can be hidden behind 10 screens. Audit rails can be added. Anything but completely eliminating power-use in the name of privacy.

1 - I couldn't implement some telemetry in this project because google yanked the ability to read process stats: https://elvischidera.com/2020-11-23-building-distributed-and...

They could have required a permission instead. Or inform the user about the process I'm observing.

The data I was looking to gather has nothing to do with the user, but the task itself.

Another example is the restrictions introduced in the Bluetooth API.

Not all use of these APIs are intended for stalking. It doesn't make sense to keep "dumbing" down devices.

PS: I'm not arguing about the validity of your concerns. I just wanted to add an alternate take which I felt was missing in this thread.

> but every time there's huge blowback from users and developers because "they're trying to take our file explorers" or whatever.

This is a justified blowback. The file explorers and system utilities (apps users actually want to access the whole file system) should be given full rights. Access rights should be managed, not denied for all the apps altogether. I would introduce separate permissions for full file system (incl. OS and other apps files) access, access to user files space only, access to specific directories.

PS: Can anybody recommend a really good file system explorer for Android? I would pay any reasonable single-time price but no ads and no subscriptions please.

Interesting article but its rich as fuck coming from a company whose sole product is weaponizing the ever increasing scope of browsers against users

I take the article as an advert to say 'use us to fingerprint people, we are always thinking of different ways to reliably finger people'

Yeah I don't know how to interpret this article. Is it a warning to users about a new threat to privacy, or is it an announcement to customers about improved tracking capabilities in Android 12/a potential product update?

Even if it's just some inbound marketing blog spam bullshit, why would a company whose business it is to violate and exploit privacy want to post an article that will attract people who are concerned about privacy?

Hey there, I work at FingerprintJS.

We don't believe in third party tracking and only focus on first party anti-fraud use cases. We publicly reveal any methods that we detect as being pure third party tracking privacy violations so that they get patched.

I suspect first party anti-fraud tracking methods and third party tracking methods have a lot of overlap. What are meaningful differences?

It is certainly a discussion we are having internally often. Overall we focus on identifiers that are not uniquely identifiable to a person on their own without taking them in aggregate, which makes them harder to share across unrelated domains. We also generally avoid anything personally identifiable (name, email, etc) that could be tied back to anyone in particular - we aim only to accurately identify a browser or app instance itself.

that's what i thought, fingerprintjs is kind of symbolic for hard to prevent tracking

> This color extraction algorithm is basically a map from the set of all possible images to the RGB color space. The set is infinite and the RGB color space is limited by 2^24 combinations. Theoretically, this means every RGB combination is possible.

I know this is missing the point of the article, but this is not how the pigeonhole principle works.

I'd guess at least half of the colors are extremely unlikely. Anything near the edge of the RGB cube would require some very uninspired artwork to show up in the set.

Most apps will skip all that and just ask you to login before working. Much easier and they get your email ;)

Do you have anything to back up your claim?

I think the opposite is true: Nearly every app bundles an ad-serving or analytics library which uses fingerprinting techniques like this. Apps require login in addition to fingerprinting, not instead of it.

Analytics libraries are extremely easy to include. Some even get included without the knowledge of the developer. For example, when a Flutter app includes the Firebase library, it starts automatically sending user behavior data to Google. Specifically, it sends the title of every screen the user opens and how long they spend on it. This happens even on Flutter apps for iOS.

Would the way to counter this be using a default / well-known wallpaper? You'd have the same the wallpaper "ID" as several others who stick to the default wallpaper.

That, and/or change your wallpaper relatively frequently.

There seem to be apps that can automate changing your wallpaper, including an official Google one.

Changing your wallpaper frequently doesn't reduce fingerprinting. Each new wallpaper is a new data point for fingerprinting. The timestamps of wallpaper changes are also data points.

The only way to thwart fingerprinting is to make the data points the same on most devices. If you're changing the wallpaper, then it must change in sync with the other devices. Leaving the wallpaper at the default is simpler.

how am I being tracked from this? It takes pages to get to the point where supposedly the wallpaper color reduction could be unique enough ....but when is that going to be used to track me? Or rather, who is going to depend on that to track me across the device? Stretch no?

It generates a unique fingerprint for your phone that can be used across apps without permissions. So if you have multiple apps using the same ad network SDK, each of them will get the same unique fingerprint for you and can tie your activity together. If you're logged into one of the apps, then your activity across all the apps can be tied to your login even when you change your wallpaper.

Color theme is generated from Wallpaper.

Color theme consists of at least 3 colors taken from the wallpaper.

At least 3 unique colors is enough to make the user potentially uniquely identifiable, depending on how rare the color combos are.

2²⁴ (R⁸G⁸B⁸) combinations for every color times 3 colors means 2⁷² combinations.

And there are color samples taken from potentially two different wallpapers.

Other apps have access to the colors picked for the theme generated from the wallpaper so they can theme themselves accordingly.

This means an app can use your color theme (of 3 or 6 colors) as a nearly unique fingerprint. The odds of collision for smaller apps (sub 1 million downloads) are pretty damn low.

I mean apps already have access to your device ID, no?

They don't - without special permissions on newer Android versions (10+). There is an ANDROID_ID but it's scoped to your application on Android 8.0+, reinstalling the same app signed with same key will give you the same key but it returns a different value in other apps. This way you can't use for cross-app tracking.

https://developer.android.com/training/articles/user-data-id...

https://developer.android.com/reference/android/provider/Set...

How does Google share logins between different apps then? Is there some shared keybag/storage location that only works for the developer's own apps (and is it scoped to the actual developer account, not one that different developers can collude to use together)?

I am not sure what mechanism is Google using. But Android apps can talk to each other on the same device and you can restrict this to only applications that are signed with the same certificate (and this is guarded at the OS level).

>How does Google share logins between different apps then?

google play services

It seems that you don't use Android. There's an account system apps can use in the os.

Just checked mine, I can see Google, Facebook, Reddit and quite a lot others there

Apps that have the same signing keys can share code and data: https://developer.android.com/studio/publish/app-signing#con...

However, the restriction only apply to asop/pixel devices. For other devices, often there is a way to extract unique id/ imei with hidden api without any premissions.

Modern high-end phones use OLED displays. Save your battery and set your background to black.

Picture of the family thanks. Gotta remember why I carry around this beeping shit box.

Made me actually laugh. Touché!

It's not constant. I expect that people change wallpaper frequently.

I don't think an average person changes wallpapers frequently.

It's been more than a year since I last changed my wallpaper.

I've used the same wallpaper on every computing device I've owned, for the last 26 years.

With the downside of fingerprinting yourself it seems, would you be willing to share the wallpaper?

It isn't special, merely a blue/green colour with mild dithering.

It is a little like looking at the morning sky.

It's on all phones, desktops, etc. And if I were to give it to you? Well. Maybe you're the NSA, maybe I'll be pulled off the street, thrown into a chair, and in a NDA-drugged, mildly confused state, be told "look, it is your desktop, see your familiar backgroud? You should enter your password."

No sir, I will not disclose my background image!! Sneaky! Good try though.

Unfortunately, constancy is irrelevant. If a malicious app is using this API to locate you, it can detect when your wallpaper changes and use its app_id (unchanged) plus wallpaper fingerprint (changed) to phone home with "Yo, this user's wallpaper thumprint is now Y."

Android dev here. Still have the same default wallpaper as my Pixel 3 came with 3 years ago.

That wallpaper would have the same 3 colors as many, many, other people. The problem here arises when your wallpaper is unique, no?

You can still use as input along with other parts that are accessible without any permissions - for example the android version, device name, IP address...

Do they? I've had the same "live wave animation"(that looks like the PS3's XBM menu) for at least 5 years now and I don't see any reason to change it.

I mean, I go and set up ASCIIQuarium on every phone I have. Hunting down the APK gets harder and harder though.

I'm beginning to feel as if after I'd put my Android phone though a metal shredder that the individual remaining atoms will somehow still have my ID on them à la QM's conservation of information.

It's been clear to me for quite some while that the whole notion of trying to achieve privacy on the internet is broken - the paradigm we're now using (and have always been using) to achieve privacy is wrong. As no matter what steps we take - such as making browsers more private and less fingerprint prone to, say, sandboxing apps etc., etc. - someone sooner or later will always find ways around our best defenses. As it stands, it's an ongoing incremental battle over privacy that we citizens can never have any long-term certainty about.

Somehow our ID and personal data have to be separated from the hardware, software, means of transmission and IP addresses, etc. in ways that any chance of ever linking them are not just difficult but are also logically impossible. It's only then that we'd be in a situation where no matter the amount of hacking the 'system' would ever reveal or encroach upon users' privacy.

This wallpaper example may still be somewhat of a stretch to implement in practice but chances are it won't be so in the future; its existence only goes to illustrate my point.

If anyone ever manages to solve the problem in an easy implementable way then he/she will either be deemed a hero genius or a pariah. Which of these views one has will depend on which side of the political fence one's sitting.

It's simple information theory (or basic OPSEC). Every kind of customization, every differing behavior reduces entropy. That's why Tor recommends using the browser with a fixed size window and with default settings. (Of course neither simple nor basic means easy.)

Reply on news.ycombinator.com