This is the Google model then. Base everything on open source, even allow unofficial builds of your operating system (LineageOS, Graphene), but slowly introduce more and more device attestation and DRM so it becomes de facto impossible to actually use anything but the closed builds because everything from banking apps and electronic identification apps to streaming apps will refuse to run on your "unsafe" operating system.
Currently the only thing which won't run on a non-google blessed android build is google wallet, although a lot of applications rely on google's proprietary services exposed through google play.
I've not ran into any banking applications which won't run on a non-google build of android (as then they would only run on a pixel). That being said, I refuse to seriously bank with any bank which doesn't offer a functioning website. My main bank offers an app but you have to wholesale switch to it.
This is false. List of apps which refuse to run on my old OnePlus 6 which I revived with LineageOS:
- Danish national identity app (MitID). I had to get a hardware token that generates one-time passwords.
- My banking app (still works in the browser though).
- The de facto payment app used for peer-to-peer payments and as a credit card alternative all over Denmark (MobilePay).
- The app for controlling the heating system in my car.
- Revolut.
- The app for showing a digital version of my government issued health insurance card. It's literally just a barcode and a number, so I can get by using a photo of the card instead. This underlines the ridiculousness of requiring Play Integrity attestion.
- The app for showing a digital version of my driver's license. As a bonus this app also doesn't work if you have set your default browser to Firefox instead of Chrome, even on a non-rooted phone.
On top of this, one app for scanning goods in the supermarket stopped working, but without explicitly saying why. I suppose it just silently depends on some Google service, but I have not way of knowing that.
I also cannot get Chromecast to work, but that is perhaps to be expected when replacing the Google services with microg, and not strictly a result of DRM. It is a major inconvenience though.
Denmark is one of the most digitized countries, and in many ways that is good. However, it also means that you are increasingly coerced into the whole Google/Apple ecosystem and that it is very hard to get out. Luckily there are alternatives to all of the above apps, but it is a major inconvenience to have to use them.
I don't know much about LineageOS but GrapheneOS supports attestation (albeit with its own keys) and it works for all the banking apps I have had the displeasure of using here in the UK including revolut.
If LineageOS did support those APIs (which it can support if it wanted to, without any blessing from Google) then presumably most if not all of those should also work.
Try GOS and see if it's broken there. If it works on GOS then you can shout at google for ever exposing the attestation APIs but the apps you're complaining about aren't actually abusing attestation in the way you claim, LineageOS is simply choosing not to implement the features they rely on.
Pretty sure this also requires the banks to then accept those attestation keys. Graphene pushes for them to do this, so you can't simply run whatever open OS you want on your device (like on desktop where you can also do online banking), you need to specifically use some third party service that then tells the banking software it's really okay to run on your device. I do find this to be a bit crappy, but at the same time it's quite amazing that Graphene has enough traction to convince many app vendors they should support an open/secure OS!
They don't have the traction. In my experience almost nothing (except for google pay) uses a whitelist for the keys. They just request attestation. This is presumably because there are too many android phone vendors using too many versions of different keys to reliably check for this.
Do you have the sandboxed Play Services installed? It works fine for me on Graphene (just checked).
That said, the recommendation I always give, and personally follow: keep a spare phone in a drawer somewhere, with official Android installed, a Google account, and use it exclusively for business purposes - banking, government services, and the email account you use for those (separate from the one you use for everything else). Nothing else, no messaging, socials, browsing, or games.
Then you're free to keep your personal phone FOSS and as private as you like, without fear of getting locked out of important stuff due to a crappy Google® SafetyNet® upgrade.
> That said, the recommendation I always give, and personally follow: keep a spare phone in a drawer somewhere, with official Android installed, a Google account, and use it exclusively for business purposes - banking, government services, and the email account you use for those (separate from the one you use for everything else). Nothing else, no messaging, socials, browsing, or games.
Anything which doesn't support an alternative method (not involving a proprietary blessed google phone) of management should be illegal if it's government related and should be boycotted if it's not.
I certainly agree with the sentiment (I would trust-bust tech giants, and severely restrict advertising as a whole for being a negative-sum game).
Nevertheless, for living in this world while preserving your privacy, my advice stands. Separate the devices that you control, which you will use for personal and private purposes, from the devices that global corporations and institutions control, which you will use to access the services those institutions provide - services which, by definition, you would not control anyway.
It is far, far simpler than having to get proprietary, frequently-updated software to play nice inside a secure sandbox. If they do, great, but separate devices ensures it isn't a capital-P Problem for you if they stop.
(FWIW, I lived in three different European countries over the past decade and so far the governments all offered TOTP-based web alternatives to their apps. When it comes to private banking, only one (Lunar) was available only via app, but it was also the only one that ran without Play Services.)
> It is far, far simpler than having to get proprietary, frequently-updated software to play nice inside a secure sandbox. If they do, great, but separate devices ensures it isn't a capital-P Problem for you if they stop.
What I am saying (and what I do) is that it's far simpler still to just not rely on anything where this might be the case.
If my bank turned around tomorrow and said I can't use their website to manage my account, I would not attempt to get their app working on my phone, I would switch bank.
Anything that depends on the SafetyNet API will not run if your android build does not pass the checks, the list is much much bigger than "just google wallet". Whether a rom passes safetynet or not very much depends on what google considers blessed today, and what they will consider blessed in the future.
None of the unofficial Android builds allows me to access to the secure element in my SIM card to use my e-signature, which works with SIM menu prompts triggered OTA by the application I'm currently using, mostly governmental services.
If I'm on a custom ROM, the notification never pops up.
You have to have evidence that this is because of attestation, though - lots of open source software is missing lots of features because they are just missing features.
It's not an attestation problem, but a trusted pipeline problem. Yes, the required files are missing, but carrying them from official builds doesn't work either, because all pipeline from modem to kernel has to be signed, and the chain breaks somewhere, and you can't build it without the private keys Google/OEM has.
It's like Trusted HDCP pipeline. Every part has to be signed properly, and no open distribution of Android can do that, period.
SIM services is an integral part of the GSM stack, and all custom ROMs I used had SIM services menu, and I was able to see and utilize the functions in the menu, sans the ones requiring accessing the secure element.
There was one missing file (which I don't remember its name now, it's long gone), but I always carried over that one from the official ROM (same Android version, mind you), but while everything still worked, this was not enabling me to use the secure element based SIM services (namely e-signature).
The problem was not "not being able to access secure element", it was visible, but making it do (secure/verifiable) things, which require an "operator message" to trigger the right process on the phone. Even if the system which I'm trying to login said that the process should start, the phone just didn't respond/started the e-signature process. In my country, if your SIM is blocked for any reason from using these services (e.g. when you change your SIM and not-activate e-sig again), you SHALL and WILL (in RFC sense) get a message detailing what went wrong.
Again, the moment I flashed the original image, secure element based SIM services started working, I didn't need to do anything on the other side. Different ROM, it's working. Flash the custom one, reboot, it's gone. Add the required files back, no luck. That simple.
BTW, I was not mad that it was not working. It's a legally binding wet signature equivalent. I don't want that pipeline to be peek/poke enabled.
- Battery Management (iPhone 6, 6s, and SE): In 2017, Apple introduced a battery management feature in iOS 10.2.1 to prevent unexpected shutdowns by throttling the performance of iPhones with degraded batteries. This led to slower device performance without informing users, which is a removal of expected performance functionality.
- 32-bit App Support: With the release of iOS 11 in 2017, Apple dropped support for 32-bit apps. This meant users could no longer use older apps that had not been updated to 64-bit, effectively removing access to those apps on updated devices = You want the new OS? -> you have less functionality.
- Pulse oximetry features were recently removed from new Apple Watches due to Masimo's patent infringement claim.
> This led to slower device performance without informing users, which is a removal of expected performance functionality.
As opposed to the device unexpectedly shutting down due to a degraded battery not being able to push enough energy to support the CPU? They didn't remove expected performance, they prevented crashes which are by definition 0 performance. All Li-ion batteries degrade over time. That's not removing a feature...
Well, they DID remove expected performance by slowing CPU performance, disn't they? People who had bought these iPhones (and not the previous ones) did so also because of the promise of a more powerful CPU, a promise broken by Apple. It is removing a feature (a better CPU) and Apple knew it that's why they did it without informing users.
Just to add, they also got fined by the EU for doing so, so it was ruled to be illegal. Bambu's changes would fall into the same category of altering the product and degrading the experience after its been sold.
Just to let you know that InstaCam360 did the same on their cameras with the smartphone app.
Previously you could directly upload the 360 videos do youtube, now you need to download the film locally on the phone, then host a converted version and only after those loops you are permitted to upload.
Or you can now buy a monthly subscription and get back the feature that was already there before. Quite disappointed with this kind of behavior.
the problem is that user got no choice. Some might prefer degraded performance, others might prefer to charge their devices more often.
Also seller should have no business touching anything that they've already sold - they do might offer support, but it should be up to user to accept it or not.
Indeed; while I've not had this specific issue with the phones, I do still have a mid-2013 MacBook Air lying around (it's now too old to realistically sell), and the battery on that was so worn by the time I got an M-something to replace it that would go from "fine" to "emergency shutdown" during boot if I forgot to plug it in. And then report something like 20% if I plugged it in and immediately booted it again.
It's not like the battery is actually empty. The phone is still able to run at 40% if it limits CPU power draw. As long as the throttling curve is accurate to the battery quality, it's all upside. A slow device is better than a turned off device. And if you want to keep your phone above 40% charge so it runs faster, go for it.
The root problem was not the throttling, it was the phone's inability to run at expected speed after a couple years.
No, it was dynamic based on voltage. iPhones with worn batteries had higher performance at full battery and swapping the battery with a fresh replacement restored full performance even at low battery percentage. In fact this is how the slowdown was discovered: someone replaced their iPhone battery with a non-genuine replacement and it got noticeably faster.
Apple (IMO rationally) chose that people would prefer a working phone, one they can use to call emergecy services, for example, to a phone that just suddenly dies.
After the massive hissy fit the Internet threw (along with lawsuits), they added a switch. Now you can choose to have your phone suddenly die.
But the legend lives on that "Appple slowed down phones permanently!!" - even though the fix for that is a 40€ battery swap that takes 30 minutes in any mall phone repair shop.
If you left It hooked up to a charger, their fix would never have affected you. It only slowed down the cpu when the risk of catastrophic shutdown was imminent.
I like a toggle for features like this, but it was a pretty standard user experience / reliability choice imho.
what if you replace battery AFTER the fix was applied? you can't rollback.
again, it's about user's choice. it's not apple's device, but whoever bought it.
they shouldn't be even allowed to DECIDE which option is better. user should be able to pick whichever they want to go with.
With a new battery, the throttling goes away. The cpu throttling only kicks in if your battery condition is poor, and then only at lower charge levels where the risk of unplanned power loss is imminent.
I get it, but if you’re going to accept binary blob updates from a manufacturer at all, this one wasn’t bad.
If there was a toggle, Would you really run your phone in “reckless disregard for battery condition” mode?
Because that is what this fixed, a flaw in the firmware where the power management subsystem made incorrect assumptions about the battery condition. All new phones come with this baked in and working properly, so your phone doesn’t randomly die in the middle of calls when your battery gets old.
People pitchforked over this update without understanding what it was designed to do. If your phone has a good battery, it does not throttle the cpu. It just adjusts the power management profiles to reflect battery aging.
But the way they did it was far from malicious. It only affected users who were actually in danger of an emergency shutdown, during times when the shutdown was imminent. While I don’t want anybody diddling my firmware without giving me a choice, this particular issue was really a nothing burger in the end.
It was discovered when it became apparent that replacing a defective battery made the phone faster. Seems like a standard reliability / user experience fix to me. Not
Many people would choose the “don’t adjust system power consumption to prevent unplanned shutdowns when the battery is about to fail” toggle.
It was not overblown. Apple didn't disclose what they were doing or give the user the option to decide what was best for them. When a company chooses to behave that way, it should hurt them, and it did.
Apple's actions in this case were even worse than Bambu's. At least Bambu documented what the update did and offered the option of declining it.
No, it isn't. If the battery was broken and they knew the battery was broken, they should have informed the user the phone could be fixed with a new battery. They decided to gimp the device and not tell the user so they would be more likely to purchase a new device rather than simply fixing the old one.
Imagine Ford deciding their cars must drive at 50% their speed when the engine oil is older than 2 years and at the same time forbidding users from changing the oil.
Yet there are always people justifying these type of awful practices as better for users. These aren't, the measures are only good for business.
Ford actually does this. They have something called limp mode for when sensors detect degraded conditions. They won't honor the warranty if you clear the code manually and continue operating the vehicle.
Many cars enter limp mode for when the ECU senses a possibly damaging condition. This limits the performance and capabilities until someone with a diagnostic computer can plug it in. Many times these diagnostic computers are entirely proprietary.
I'm not saying it is justified, but to pretend that other businesses don't do this is silly.
Well, that still wouldn't reduce your car speed by 50%.
And even for that case there would be a warning on the console and a mechanic would be able to inform what is happening. On this iphone case, there was no warning at all on the device nor there was any disclosure that they would be doing this to the phones.
You know this. In either case, thank you for the ECU info.
> Well, that still wouldn't reduce your car speed by 50%.
It does actually. It limits your top speed, and your engines rev range to approximately half of redline or less. Typically you end up limited to under 45. Also, accessories and other options, like A/C are disabled. The only indication that you will get is the reduced performance and the check engine/service light (sort of how you might get a 'service battery' warning and reduced performance on a phone).
Again, not defending it, but pointing out that Apple hardly invented artificially limiting performance behind opaque warnings to prevent unwanted outcomes. Cars have had limp mode since before the iPhone was invented.
Forbidding them from changing the oil? I personally changed my battery, I did not feel like it was forbidden.
Not even that hard.
For me, the firmware fix helped me limp through the 2 months before I finally got around to replacing the battery.
It made my phone that was flaky and unreliable below 40percent battery into a phone that worked slightly slower once the battery got low, but didn’t just randomly shut off during calls anymore.
I’d have preferred a toggle, but to be honest I doubt I’d have ever used “reckless disregard for remaining battery capacity” mode.
Yes. I live in Germany, drive German cars and know the tech.
Regular service is indeed a bother. You know what I hate the most? In my oldish Mercedes it isn't even possible to change/update the hour without using a proprietary tool only available at official Mercedes mechanics. Since I refuse to pay premium cost for attending their mechanics, the clock on my car is always with wrong time.
And let's not even get into new business models like charging you a subscription to unlock the car to move faster or to unblock the heated seats. Indeed they also have quite "creative" ways to squeeze money and force to get new models.
The big difference is that none of these changes were part of a defined strategy to lock the user in to their products and ultimately generate more profit, as with the Bambu example:
- Battery management was to handle an issue that was encountered as batteries aged
- 32 bit support: Apple is well known for being one of the more aggressive companies when it comes to forcing users (and especially people coding apps for their platforms) to adopt required tech changes. But again, not directly profit-driven.
- Pulse oximetry: probably the closest to a profit-driven-decision, as this was driven by a patent issue, and presumably they calculated less of a hit from removing the feature than paying feed to the patent owner? Not great, but still not directly part of a user-unfriendly Apple-derived strategy, as with Bambu.
And they have plenty of experience building walls around a garden. Ask anyone using OSX for the past 15 years and you will see how difficult it has become to write or publish software for Apple.
Alternate description of the same information: “newer upgrades made older devices batteries’ last longer”
They did nerf speed. But they did it for a reason. I get being mad about your phone being slowed down, but i don’t get being mad about it once you understand why.
> They did nerf speed. But they did it for a reason.
That reason was to incentivize people to replace their old "slow" phones with faster new phones. If Apple actually cared about the problem of older phones having limited battery life they'd have made the batteries in their phones replaceable.
There are conflicting priorities in every product. Apple tends to optimize look and feel over practicality. So they’ve drawn a hard line at user-serviceable battery. I agree with you that’d a bad call, but I also understand that once you’ve made that call the next best option is what they did.
They are replaceable. I've replaced batteries in older iPhones plenty of times, had Apple replace the battery in a few, and I'm probably going to use the Self Service program to get the parts for my 14 Pro Max soon as it's getting a bit tired out.
I suppose that anything is "replaceable" if you're willing to involve things like soldering irons, heat guns, or specialized tools, but replacing a battery on an iphone is not something that the vast majority of the population would be equipped to do or be comfortable doing.
the keyword being _phone_, not smartphone. Bambulab too will let you print from SD card without logging in their infra, they are just locking the rest of the ecosystem. 1 to 1 analogy.
It's still a smartphone - with web browsing, mail and everything else what's available out-of-the-box. And Bambu will cut out even local network access and, as they stated in "Terms of Use", can lock print jobs until you update firmware. Far from 1:1 analogy...
They are actually adding in LAN modes (standard and developer) with these changes so I'm not sure what you're talking about with them cutting out local network access. Neither will require auth.
As the issue here came through software update, you should look at it under the same lens for Apple.
For instance did an OS update ever prevent you from doing something that you could before ?
Yes. Countless times. OS updates have breaking changes, older apps lose support etc.
And for iOS these updates are irreversible under supported ways, while the very nature of the "there's an app for this" paradigm means losing a third party app equals losing that functionality for your device when you upgrade (you won't get a translation layer or virtualization to help the transition)
You may like Apple more and feel they communicate better, but fundamentally it's the same situation.
Selling a walled garden is one thing, building walls around a garden you already bought is another thing entirely