This page knows your battery charge level (unless you're using Firefox)
deepesh-01.github.io
deepesh-01.github.io
The API was implemented in Firefox, Safari, Chrome but it returned too precise data, so by reading battery status on two different pages and seeing the same very precise value, it was like having a tracking cookie.
Firefox and Safari decided to pull the API altogether.
An obvious fix while keeping the API would be to make the data less precise, i.e. round to nearest 10% or so. Still there's potential to abuse, and around the time there were news from Uber study that people with low battery could pay more for taxi, which was the nail to the coffin.
Since then, there was quite a change in how new web APIs are shipped, they all come through privacy design review.
Which went a bit ridiculous into the other extreme, like detecting if user uses dark mode reveals a whole one bit of information (darkmode = true | false) so it's not sent automatically, you need to ask for this info via a specific header, which means you can't know that on the first visit of the user on the website (and not on the first visit in incognito mode), only on subsequent visits. Duh.
Chromium still supports the Battery API, with some rounding implemented.
Note: Google's goal is to basically have all kinds of native APIs available on the web, to make the web rival with native apps, so they are very unlikely to remove things from the web in Chromium.
Yet people still claim "I have nothing to hide" when it comes to concerns about privacy. When your battery level can be weaponised against you by multi-billion dollar companies, everything can be.
Such bullshit. If I have to go somewhere and my battery is about to die, I don't really have much of a choice.
> "Hiding information for financial gain, getting a better deal, is fraud."
Doesn't this goes both ways? "Hiding information" is precisely what Uber is doing, when they don't transparently disclose 100% of the information used to determine price with a customer.
And no, not disclosing whether I have good battery percentage or not is not "hiding information", except in the most uncharitable interpretation possible. Uber doesn't have the right to know everything about me just because they're potentially providing a service.
You can walk, bike, find somewhere to charge your phone, call a friend, use another ride sharing app, use a car you own, etc.
>Doesn't this goes both ways?
I do not believe hiding the algolithm to arrive at a price is fraud. Most business are not transparent why the things they sell cost what they do. It is up to buyers to evaluate whether they value the good or service more than the money they have.
>Uber doesn't have the right to know everything about me just because they're potentially providing a service.
I agree, but when submitting information to them shouldn't be tampered with to get a better deal. There is a difference between just using a privacy feature that always reports your battery to be 100%, and using that feature to deliberately get a better deal from Uber. Not providing information is fine, but the intent behind not giving away the information should not be to get a better deal.
"Another ride sharing app" without battery? If you're without battery this is the exact point where you won't be doing price comparison. This is malicious as fuck.
The rest of those are not available during emergencies where people are far away, without transportation and with low battery. If Uber is really doing it, it clearly is doing that to force people to pay more during those kinds of emergencies, and if they're doing it is because they have data on it.
> "I do not believe hiding the algolithm to arrive at a price is fraud."
I never said anything about an algorithm, I said about collecting data. If Uber is not being transparent about the data it collects during the process of calling a ride, it is spying on me. Period.
"I agree, but when submitting information to them shouldn't be tampered with to get a better deal."
Who is "submitting information"? Uber spying on a customer is not "submitting information.
How long until computer people understand that the existence of an API is not a permission for billion-dollar companies to spy on users and use that to fuck customers?
If someone is in an emergency and have no other option then they will likely value getting an Uber more and would be willing to pay for one.
>Who is "submitting information"?
The app.
You just repeated what I said.
"The app."
If an app is the one submitting information without knowledge and consent of the user, then there's no fraud from the user part. But there might be illegal behavior from the app maker's part in some jurisdictions.
In what world? While your take is wrong, I just wonder where could you get this idea from?
This to me would be a case of fraud. Whether commiting fraud like this is illegal is a legal question.
Hiding information about why or how much you want a good/service is absolutely not fraud, morally or legally (IANAL).
On the other hand, giving misleading info about something you're selling probably is.
Also a better offer for who? Uber obviously.
This is a level of corporate apologism I can’t understand. If Uber is the only one to gain by using this information (and they are), this is purely a negative for consumers. Not sure why anyone would defend this practice and hand waving that people still have to accept the price is absurd.
If Uber put up a line item on your transaction that said “Low battery fee” then fine. They’re not. They didn’t want people to know.
I would support them disclosing it, but the circumstances are not the same as one party is submitting information for a quote and another party is providing the quote. In this exchange, fraud on uber's side would be lying about what the quote is.
>this is purely a negative for consumers
That doesn't mean it is right. Shoplifting being illegal is pure a negative for consumers too.
- Warn the user to save their data when the battery level is too low (or automatically save) etc.
(Of course, there's is 0.1% of webapps/websites who'd need this).
> The benign uses of the API were primarily from two third parties: YouTube, where the API was used in performance metrics for embedded videos, and Boomerang, a performance measurement library
For a performance measurement library, the use is obvious.
You fine with YT downloading all of an hours-long video on mobile and draining your data plan, even if you're paused after a few seconds? Or not being able to jump forward until whole MPEG is downloaded? That's what "standard" HTML video player does.
Also tap to move 10 sec forward is nice, isn't it?
Google of all companies has simulators (probably down to the cycle level on their own phones) and will know exactly how much processing power they're using. There's no reason for them to know the battery level for performance metrics. I fail to see it as benign, even if the stated reason is notionally benign.
> I fail to see it as benign
Maybe not entirely benign (which is why it was removed in Webkit and Firefox, and nerfed in Chrome itself).
Worst case, api should return 3 states: Draining, Charging, Charging & Full
Better to just have optimized applications.
I do agree that battery levels should not be available to fingerprint. And brave browser blocks the posted site from reading my battery level. So I'm not really sure how the research, which is also from brave, could co-exist with their browser implementation.
Don't install an App, just visit the website. The website would act like a App. even offline.
navigator.getBattery().then(battery => console.log(`Battery level: ${battery.level \* 100}%`))
C.f.: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...Eventually these get placed behind permissions if they become too much widely abused.
As explained in the standards:
"This can be used to adjust your app's resource usage to reduce battery drain when the battery is low, or to save changes before the battery runs out in order to prevent data loss".
https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
It was once implemented in Firefox too and then disabled outside internal pages. It's from an era of trying to standardize all the APIs needed for Firefox OS apps: https://caniuse.com/battery-status
Both iOS and Android apps have this capability, ex. https://developer.apple.com/documentation/uikit/uidevice/162...
Since the entropy is coarse over the entire population you could debate the privacy implications (ex. Time zone is more specific and stable). Restricting it to only saved PWAs to match the privacy model of native apps seems reasonable though. Someone should propose the change to Chrome.
Time zone is also much less useful for fingerprinting because it's tightly correlated with other signals like IP location and language preference. If you already know that a user's IP is somewhere in California, the additional information that they're using the Pacific time zone adds little value.
(If a user's time zone doesn't agree with their geolocation, that's certainly a signal -- but it's going to be an uncommon one.)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
Removed from Webkit (Safari) soon after:
https://webkit.org/tracking-prevention/
Chrome took a middle ground, removing it for insecure origins and reducing the precision:
Worth pointing out though that iOS native apps appear to have this information with no permission prompt:
Software I use to make HTTP requests does not support Javascript.
That's fine maybe? Imo it's totally reasonable to expect end-users to have some sort of js support
I do use uBlock Origin too with NoScript, but that's only for handling the JS of domains NoScript temp whitelists.
If you're still disabling by default in 2023, you are a fraction of a percent of a fraction of a percent of people dedicated enough to go through that pain.
I wish I had your dedication.