Facebook scans system libraries on Android and uploads them to their server
twitter.com
twitter.com
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?
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
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.
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.
Unfortunately, everyone uses WhatsApp in Brazil, and very few people uses Telegram, for example. This makes it kinda impossible to be Facebook-free here.
This has the advantage of getting away with things the legal team would advise against, which I think they do a lot.
And no point using Facebook, really. Still with Whatsapp (and passively Instagram) as my friends are massively on those.
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.
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.