How is this not utterly illegal in the EU, per GDPR? (Which was drafted to stop indiscriminate data acquisition on human subjects: I'm assuming that metadata about the core libraries on your phone, in conjunction with FB's user metadata, are trivially de-anonymizable.)
I'm pretty sure you can fingerprint a device by gathering data about the binaries (and versions thereof) installed on it. I'm pretty sure that Facebook also know whose instance of the FB app is running on the device in question. Ergo, the data can be deanonymized and gives them more insights into what their users are doing … including, oh, competing platforms and apps?
The traditional model of computer security assumes that there's one device (the computer) which may have multiple users, so the emphasis is on identifying the user to the device. But today, one user may have one or more computers (smartphones/tablets/laptops), so the emphasis is on linking devices to users and thereby tracking usage patterns across devices. Which lands it straight in GDPR territory.
> I'm pretty sure you can fingerprint a device by gathering data about the binaries
Actually, probably not. These libraries are the base system image, which is read-only, and typically will only identify which model of phone it is. It might identify you if you have a custom android build you've done yourself though.
For starters, I'm not convinced it would be harder to spoof that than the library information (which also seems pretty easy to spoof if not easier).
But even if that were the case, why would they spend this level of engineering effort just to be able to fingerprint people in that extremely rare case of having a spoofed phone model? Do you think that kind of customer would even be receptive to targeted ads in the first place? It just doesn't make sense to me.
My previous phone got an OS patch every few months. You would get most of this by reading the phone model and Android version, but there's probably a smidge more information in the library versions
I would assume system libraries don't count as personally identifiable data (after all, millions of people have those same libraries), so the gdpr doesn't apply.
In general, I don't think this is going to collect any more identifiable data than just logging the phone model and Android build ID would; under almost all circumstances every build should correspond to exactly one set of system libraries, and they could match across upgrades just as easily with just the build metadata. Generally, every phone of the same model sold by the same carrier in the same country will have the exact same Android build with the exact same system libraries.
The main benefit that Facebook likely get out of this is that it helps them debug crashes on devices they don't have themselves.
Under which provision would this be illegal though? It's the operating system image Facebook can get by just buying the exact same model of phone the user owns. I'm having trouble finding under which definition of GDPR managed personal data does this fall over.
The only angle I see is copyright infringement for copying libraries owned by the phone manufacturer... but even that I'm not sure if it's really illegal in this case. Worth filing a complaint anyway I guess.
Both. No point using an operating system that is a malware and privacy nightmare, just so I can fiddle with it more. It's not a computer, it's just a phone.
And no point using Facebook, really. Still with Whatsapp (and passively Instagram) as my friends are massively on those.
If the actual files are uploaded(?), doesn't this constitute reverse software piracy? Under what license are the uploaded files covered by? Can facebook require the end users to supply the source code for GPL-licensed library binaries uploaded through this system? What about proprietary oem blobs that are often covered by a no-redistribution license or EULA? What if I am an AOSP or vendor developer working on unreleased R&D next-version Android?
So are they allowed to make point in time backups / snapshots of their phone or is that also “copyright infringement”? Usually copyright infringement focuses on distribution for piracy and/or fraudulent sales — this is neither.
Backups are a special case exempted from copyright. What is happening here is clearly not a backup for personal use but redistribution to another party for commercial use.
Yes, users can copy this data for backup purposes, that is covered by fair use.
> Usually copyright infringement focuses on distribution for piracy and/or fraudulent sales — this is neither.
I'm not sure what you mean. Copyright infringement is the act of infringing on one's copyright. It's not a question of focus.
Copyright law does focus on certain aspects of it but it's not up to Facebook to decide when it's copyright and when it's not. The law is pretty clear here.
This is clearly distribution and clearly not licensed copying.
The purpose here is largely irrelevant.
Further, this is clearly unauthorised access and removal of user data. This is quite likely a criminal act under US hacking laws.
FWIW the sibling comments are correct under USA's Fair Use but in the UK there is only a very restrictive Fair Dealing which last I looked did not allow backups without permission unless there is no digital protection in place. There is a right under S.50A to make a backup of a computer program but when paired with the rest of the act it's unworkable.
In the UK you can't (you could for a while) rip a CD/DVD, apps like iTunes are contributory infringers.
Very few of the libraries will be owned by an individual though - I would bet >99% are owned by an OEM or software house. That OEM probably isn't interested in suing facebook for a small amount, because if facebook blocked that OEM's phones, it would probably spell the end of the OEM.
If you build a custom AOSP from source and add a new system library or modify an existing system library that adds a proprietary algorithm or maybe even a poem/artwork that you wrote yourself and put a proprietary license/copyright on, maybe you could go after fb for illegally pirating/stealing your own copyrighted work? Probably wouldn't work if you do this just to poke fb knowing about this feature, but if you happened to work on custom AOSP roms for personal use before this feature became widely known, then it sounds like you might possibly have a good cause?
Apps should be statically linked and the kernel should not allow any access to the hdd or fs. Where you have to opt in to what folders the app is able to read or write to. Same for network access and any other hardware, camera, mic, etc.
Frequently those static libraries provide device-specific functionality. For example, the
Jpeg decompressor on my phone uses custom silicon, and is a systemwide shared library.
Sure, everyone is going to talk about fingerprinting, but let's face it, there are way easier and more reliable methods of doing that than system libraries that mostly match between same devices.
Must be for some sort of debugging? Still seems insane...
There are hundreds of thousands of variants of android phones.
Facebook wants their app to work on all of them, but cant track down all of those physical devices.
Instead, I bet they load all the libraries into a big test bench and check all features of the app work with all possible hardware.
It wouldn't be perfect, since I bet many of those libraries rely on custom system services, kernel interfaces, etc, but I bet it helps them track down a bunch of issues before they impact real users.
As someone who’s built my company’s mobile crash reporting solution, I have a guess why they might do this.
It’s is extremely difficult to diagnose Android native code crashes. Unlike iOS where it is both straightforward to unwind on the phone, and where Apple makes the iOS system symbols available for symbolizing system frames in a stack trace, neither of these things are true on Android.
My first approach for my company’s Android crash manager SDK was to use Google Breakpad. This works by capturing a snapshot of stack memory at the time of the crash. Unwinding then occurs on a backend server. But to unwind successfully, absent a frame pointer register, you need unwind info to provide to the unwinder. This simply isn’t available except for Nexus devices for which you can download the system images from Google. And even on devices where the code was compiled with a frame pointer, you still need symbols so you know what each frame’s function was.
Another approach is to unwind on the device. In my experience, using libunwind, this is successful about 50% of the time. It also risks hanging the app, which looks even worse to the user than just crashing.
Years ago, I briefly considered having our crash SDK, optionally and with user consent, extract the symbols and unwind data from the libraries on the device and upload them to our backend. I dismissed it as too expensive to do on a user’s phone.
Instead, we crowd source as much as we can from our employee phones.
Android native code crashes remain a bear to diagnose. Especially annoying since Android itself collects a ton of diagnostic data about your app when it crashes - it just doesn’t make it easily, or in some cases at all, accessible to the app itself.
This is clearly not for crash reporting. They're sucking up libs to figure out what apps their users use.
Could be a few reasons, could be boring metrics, could be anticompetitive identification of acquisition targets, could be oppo research, could be user profiling.
None of these things I'm ok with Facebook getting off my phone.
It sounds like you don't understand what the term "system libraries" means. It's impossible to tell what apps people are using by uploading system libraries. You could probably tell what type of phone they are using by doing it, but that would be dumb since Android already tells you what kind of phone it is.
I'm really interested in an answer for this question, since WhatsApp is the only Facebook app I have installed/keep an account.
Unfortunately, everyone uses WhatsApp in Brazil, and very few people uses Telegram, for example. This makes it kinda impossible to be Facebook-free here.
67 comments
[ 2.9 ms ] story [ 106 ms ] threadThe traditional model of computer security assumes that there's one device (the computer) which may have multiple users, so the emphasis is on identifying the user to the device. But today, one user may have one or more computers (smartphones/tablets/laptops), so the emphasis is on linking devices to users and thereby tracking usage patterns across devices. Which lands it straight in GDPR territory.
Actually, probably not. These libraries are the base system image, which is read-only, and typically will only identify which model of phone it is. It might identify you if you have a custom android build you've done yourself though.
But even if that were the case, why would they spend this level of engineering effort just to be able to fingerprint people in that extremely rare case of having a spoofed phone model? Do you think that kind of customer would even be receptive to targeted ads in the first place? It just doesn't make sense to me.
How much would you pay for Elons verified personal number?
The main benefit that Facebook likely get out of this is that it helps them debug crashes on devices they don't have themselves.
The only angle I see is copyright infringement for copying libraries owned by the phone manufacturer... but even that I'm not sure if it's really illegal in this case. Worth filing a complaint anyway I guess.
https://news.ycombinator.com/item?id=20839689
And no point using Facebook, really. Still with Whatsapp (and passively Instagram) as my friends are massively on those.
You probably won't be in trouble until you start trying to distribute your copies, but the prohibited thing is copying. Hence the term copy-right.
Under fair-use laws (which vary country to country), you can usually copy a small portion of the work for non-profit educational use
https://en.wikipedia.org/wiki/Fair_use
Users aren't given the right to distribute their copies.
> Usually copyright infringement focuses on distribution for piracy and/or fraudulent sales — this is neither.
I'm not sure what you mean. Copyright infringement is the act of infringing on one's copyright. It's not a question of focus.
Copyright law does focus on certain aspects of it but it's not up to Facebook to decide when it's copyright and when it's not. The law is pretty clear here.
This is clearly distribution and clearly not licensed copying.
The purpose here is largely irrelevant.
Further, this is clearly unauthorised access and removal of user data. This is quite likely a criminal act under US hacking laws.
In the UK you can't (you could for a while) rip a CD/DVD, apps like iTunes are contributory infringers.
If you hold the copyright to a library deployed on android, you might want to talk to a lawyer.
This only includes system libraries which a phone OEM shipped. It doesn't include libraries which are bundled with an app.
This has the advantage of getting away with things the legal team would advise against, which I think they do a lot.
Sure, everyone is going to talk about fingerprinting, but let's face it, there are way easier and more reliable methods of doing that than system libraries that mostly match between same devices.
Must be for some sort of debugging? Still seems insane...
Facebook wants their app to work on all of them, but cant track down all of those physical devices.
Instead, I bet they load all the libraries into a big test bench and check all features of the app work with all possible hardware.
It wouldn't be perfect, since I bet many of those libraries rely on custom system services, kernel interfaces, etc, but I bet it helps them track down a bunch of issues before they impact real users.
It’s is extremely difficult to diagnose Android native code crashes. Unlike iOS where it is both straightforward to unwind on the phone, and where Apple makes the iOS system symbols available for symbolizing system frames in a stack trace, neither of these things are true on Android.
My first approach for my company’s Android crash manager SDK was to use Google Breakpad. This works by capturing a snapshot of stack memory at the time of the crash. Unwinding then occurs on a backend server. But to unwind successfully, absent a frame pointer register, you need unwind info to provide to the unwinder. This simply isn’t available except for Nexus devices for which you can download the system images from Google. And even on devices where the code was compiled with a frame pointer, you still need symbols so you know what each frame’s function was.
Another approach is to unwind on the device. In my experience, using libunwind, this is successful about 50% of the time. It also risks hanging the app, which looks even worse to the user than just crashing.
Years ago, I briefly considered having our crash SDK, optionally and with user consent, extract the symbols and unwind data from the libraries on the device and upload them to our backend. I dismissed it as too expensive to do on a user’s phone.
Instead, we crowd source as much as we can from our employee phones.
Android native code crashes remain a bear to diagnose. Especially annoying since Android itself collects a ton of diagnostic data about your app when it crashes - it just doesn’t make it easily, or in some cases at all, accessible to the app itself.
Could be a few reasons, could be boring metrics, could be anticompetitive identification of acquisition targets, could be oppo research, could be user profiling.
None of these things I'm ok with Facebook getting off my phone.
Hypothesis 1, debugging: requires full copies of system libraries
Hypothesis 2, fingerprinting: requires hashes of application libraries
Evidence: full copies of system libraries are being uploaded
How are you using that evidence to be so confident in hypothesis 2 and confidently against hypothesis 1?
Unfortunately, everyone uses WhatsApp in Brazil, and very few people uses Telegram, for example. This makes it kinda impossible to be Facebook-free here.