Facebook drains users' cellphone batteries intentionally says ex-employee

Exactly. I found myself asking "but how would draining batteries help them?".

I think lots of companies already do stuff like this, for example, Microsoft rolls out updates to smaller groups before doing larger deployments. Google Chrome tests some experimental features before a full deployment.

It would be better if there was simply an opt-out of being part of this testing group. If the user goes to the effort of opting out, then they likely have a good reason for this. Also maybe Facebook also doesn't want to run this on devices with already bad battery performance for example.

Yeah, the boss didn't care about user's battery.

From the article:

    I said to the manager, 'This can harm somebody,' and she said by harming a few we can help the greater masses. Any data scientist worth his or her salt will know, Don’t hurt people,

The problem is not one suffered by Facebook users, it's a problem suffered by people working at Facebook at the hands of evil management. Noble Facebook employees, fighting with their superiors, trying to do the right thing, whilst collecting a fat paycheck.

Here's how I imagine it was introduced:

Engineer A: Hey how would we know whether loading this image as a .webp vs a .jpg would perform? Our lab testing is one thing but the different hardware out there vastly differs from phone to phone -- we need some data on the whether the average phone has enough optimizations for one versus the other.

Engineer B: Oh, what if we just run a background task on some of the phones that tries loading an image that we don't show, just to get the metrics?

Engineer A: Hmnn, that could work, we could load just one image across some small % of the user base to get a representative sample and report that data to system X so we can get some statistics and make heuristics based off of that.

Ethics is not a strong suit/required reading for software engineers, so not every engineer will read the above and detect something wrong. Hell, running experiments on wide swaths of users without consent isn't quite above board ethically either, but we've got a whole technological trees and industry dedicated to it.

Most of the time the person with enough ethics knowledge to realize there's a problem here is more incentivized to alert legal (so they can add it to the EULA/ToS that users don't read) rather than stop the behavior.

I suspect many engineers could read the conversation above and not think there was anything wrong there to begin with. And of course, once X teams across Y companies start using this, we've got a problem.

Note that I use engineers for all the roles on purpose -- the idea that it's only non-engineers doing all the sketchy shit is a deflection of responsibility, I for one am pretty proud of George here -- he's turned down what is very likely a lot of money to do the right thing. We can only guess at how many do not take this route.

[EDIT] I want to note that I do not put myself above this conversation -- being able to recognize that this is wrong immediately is not some innate skill that everyone has, it has to be reasoned about, and often where to draw the line comes down to widely-enough-held social mores/morality.

For example, I run ethical ads on my personal blog -- I know that ads incur unnecessary load on user machines that visit, and in-turn burning unnecessary battery on visitors' machines. Am I the same as Facebooks' engineers that work on this system? Probably not, but explaining that completely (and convincing yourself or anyone else) is more complicated -- maybe it's only a matter of degree.

So they didn't explicitly ship a feature to drain users' batteries, they seem to have shipped a feature that does tests (testing how long downloading different image downloads take etc.) that drains a users batteries.

It's not clear to me why they wouldn't run a few tests for a few seconds across many/all of their hundreds of millions of users so the battery drain would be unnoticeable, rather than enough on a single user where it would be noticeable.

From the article, it sounds like this was part of A/B testing. They want to see how people behave when their battery doesn't last as long... so they drain the battery on 0.1% (or less) of user's phones to collect the data.

Of course, if you ruin battery life for hundreds of thousands of users... you're likely to hit at least one user who really would have needed that battery.

> In the end I've also restricted Telegram and now my battery lasts for 17 hours.

Do notifications for messages still work in restricted mode (sorry if silly question) ?

Facebook app installed on GrapheneOS... talk about an intense yin/yang.

Reading ADB logs is useless for any kind of worthwhile analysis. Might as well fortune tell from coffee sediment.

If you want to figure out what's going on with your battery, grab a bug report (adb bugreport command is one way). Then upload the resulting ZIP into battery historian - https://github.com/google/battery-historian (there's a hosted version somehwere on the web is you're willing to trust it with your debug data).

That will give you a usable graph of what's been keeping your phone awake, using radio and what the state of your signal quality was.

To be fair I wouldn't be surprised if the cause of this is precisely the purity of GrapheneOS: given it lacks Google services and Firebase Cloud Messaging to centralize app notifications through Google, the apps need to do frequent polling or keep an active connection to Facebook's infra to receive notifications. Same with Telegram, each has a slightly different polling mechanism when Google-powered push is not available (a common in phones without Google services), which is most likely way less power efficient.

I mean, the nypost’s reputation is bad enough that you have to prove who copied who

Yeah, a better word would be "knowingly" because the intent isn't to drain the battery. The guy's concerns aren't without merit, but it's a weird hill to die on.

Whatever the ethics of this, the intention seems to be to learn what drains batteries less.

Agreed. As much as it's noble to say technology companies (especially the successful ones) should care more about their users/customers, these sorts of conversations can really get off into the trolly-problem weeds of ethicizing generic tools, and generic entertainment tools going by what users spend most of their time on. At some point we, the public, have to take responsibility for our own security (or whatever else as the specific case may be) by coming up with a plan slightly more sophisticated than "Hope my angry birds machine is up to the task of literally saving my life". It feels like back in the bad old days before smartphones, every suburban dad in cargo shorts understood that if he wanted to make sure he could call into work, he had to bring an extra battery along and not waste juice on superfluous calls, and preferred separate pocket computers for time-wasting entertainment or non-critical business applications. Nowadays we've integrated the two together for convenience, but still get this outrage cropping up every so often over not matching the reliability of the older machines that were designed to primarily just be reliable. Something had to give to, erm, give us our angry birds, and customers bought giving up reliability in emergencies for convenience in the 99.9% of time that's not an emergency. Not preparing for the off chance that the computer in your pocket will prioritize something other than utility-level uptime for call-making by carrying a second phone or extra power, regardless of who, what, or how, is a naive failure to plan that needs to be addressed more deeply than whatever nonsense Facebook's up to this month. Which doesn't have to be a problem, so long as we're not pretending things are different. Users are perfectly capable of running their battery down all on their own, or installing software (or as you point out THE OPERATING SYSTEM) that runs the battery down all on its own "naturally" because everyone involved has different wants until after they've actually had a heart attack at 2% battery.

i don't find it too compelling, but this test could potentially help you understand, to some degree, how important battery consumption of an app actually is to users.

so you run a test where you intentionally consume more of some cohort of users' battery power (you could have several cohorts where you consume more and more power, even). and you look to see if the rate at which your app is deleted/force-quit by the cohorts with more power usage goes up. if it does then you can assume that you're overdoing the battery drain. if it doesn't then you can assume users don't really care (or don't care enough; maybe they're unhappy but your app is too important to them to delete).

why this could be useful is when you're deciding what to prioritize - if you've got data saying that users don't care about excessive battery consumption and they'll keep using the app anyway, you can argue against optimizing for battery life in future development, presumably letting your developers do things faster/more lazily. or, it could show that battery life is super important and be a valuable argument to prioritize power optimization work in the name of keeping your users from jumping ship.

personally i'd rather just presume that battery life is important and that optimizing for efficient use of our users' batteries is the right thing to do, regardless of hard data, but i'm sure there are people out there that think differently.

The article says he was fired for not running the test and reporting to his manager that it was wrong

I don't think someone would risk being attached the "faking the reason for firing" label and become harder to employ and fake stuff like that then go public with it. I mean sure it is possible, but lying about stuff like that is on stupid end of spectrum

What is the point this comment is trying to make ?

Easy to discredit a comment which only comes up with explanations which disfavors one of the sides.

I understand you point but the "How to run thoughtful negative tests" document is pretty specific. Now if that document does not exist, you are 100% right but if that document exists, you may be wrong and this would need to be looked at more closely.

>But what were they actually doing?

I'm assuming the opposite of battery optimizations. Some developers prefer functionality over battery life: https://dontkillmyapp.com/

Why? Just like for other telemetry: all they have to do is push a small modification somewhere and they instantly get access to millions of data points which they can then use to analyse what works best for them. Though I agree it is very, very vague if the 'battery draining' is really just that or it's more a result of something like 'for _ in range(10000000): measurePerfOfAvsB()'. But I assume the original source did/could not enclose that.

Why would a music app use a lot of battery? Apple has been optimizing its hardware for over 20 years to play media efficiently.

Just find a good Anki deck and get rid of Duolingo. To me, Duolingo is just a spaced repetition gateway drug to Anki.

The only thing that I could find was from 2017, where phonearena were apparently re-injecting ads using WebRTC to bypass adblocking. So perhaps you are using an old blocklist such as this: https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt.

But that's probably because you're actually using Chrome a lot? That tracker isn't very accurate and its very biased towards apps you're actually using (which makes sense doesn't it?).

Basically, your phone is picked as a test phone, were software tests run in the background. That's how I understand it.

The claim in TFA is they run a/b style tests where a sample group would have their battery deliberately drained to test performance of the app in low-power situations.

Based on the general fixation on tests at Meta and Alphabet et al, it seems pretty plausible to me that they might try such a thing although:

1) the article is just the employee's claims in the context of employment arbitration, rather than evidence. For example they claim to have been shown a document about running such tests, but it's not clear whether that document has been entered into evidence (and certainly not made public). That document would presumably be subject to discovery in a lawsuit, although in arbitration it's unlikely it would be in the public record unless someone with standing made a freedom of information request (which may or may not reveal it).

2) It seems to me such a test would be unnecessary regardless of the ethics of it. You could just look at instances when a user's battery was low organically without draining it on purpose. The installed base is large enough that this would almost certainly work just as well for most practical purposes.

For a random subset of users, when they view one image, the app downloads two images (eg webp and jpeg) and makes a note of which one decodes fastest; the goal being that in the future they can just download the fastest-decoding one, saving CPU load (and thus battery usage) for everybody in the future.

The argument is that downloading two images when you only need one is “deliberately wasting battery”.