Comment by leptons
8 days ago
>> people will figure that out and adapt for themselves
>No they won't. People on HN will. Not the average person.
Yes they will, Apple has made it very easy to see.
To check iOS app power usage, go to Settings > Battery, where you'll see a breakdown of battery consumption by app for the last 24 hours or 10 days, showing usage time and background activity, allowing you to identify power-hungry apps and manage settings like Background App Refresh to improve battery life.
So yeah, it's easy to see which app is taking the most power, and users can do this easily, unless you think Apple's UX is so bad that users won't know how to read it?
>The problem is, arbitrary code execution vastly expands the risks. Your "should" is doing all the work there.
If that's a problem for web browsers, then it's a problem for every single app in the app store. There's nothing really unique about a web browser app that makes it more risky than any other app. Javascript is already very much sandboxed. And there have been plenty of exploits that already target Safari. So saying other browsers are the problem is like blaming the victim (of Apple's anti-competitive practices).
>Huh? Apple follows web standards. Why the heck should it make Safari available on Android and Windows? Safari isn't a standard, web standards are.
If web standards are standards, then let other web browsers on iOS.
The real reason Apple disallows other browser engines on Safari is so they can force developers to create native apps where they can get a cut of any purchase made through the app. The problems with Apple's anti-competitive practices have been spelled out in the DOJ lawsuit against them:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
Apple made it very clear that their security concerns related to third party browsing engines are about difficult-to-contain threats posed by JIT compilation. (JITs require non-text memory pages to be executable.) Apple doesn’t allow other apps to use such technology, so they’re consistent in that respect.
Apple even disables JIT for Safari itself when you put an iPhone in lockdown mode, at no small cost to performance, in an effort to harden the device even more.
Do you have a rebuttal to that?
That's just their excuse. Javascript is used on practically every web browser in existence, across billions of devices, and it does not have the security risks that Apple claims. It just doesn't. There are plenty of other flaws in their own web browser that have allowed remote code execution, but Javascript isn't typically one of them, in any browser, in any platform, in the last decade or more.
And there are plenty of apps in Apple's app store that are malicious. So the JIT excuse is just Applespeak for "we control what our competitors can do on hardware we supplied that someone bought and paid for". It's abuse and they are being sued by the DOJ. Just read the lawsuit so I don't have to reply to any more of your comments:
https://www.justice.gov/archives/opa/media/1344546/dl?inline
First, are you a security expert? If so, please provide your bona fides. Apple employs some of the brightest software and hardware security experts in the business. (Cellebrite can attest to this; they possess far fewer capabilities to crack iPhones than every other phone on the market.) If they perceive handling out JIT capabilities to apps as risky, I believe them. You, on the other hand, come with no evidence to the contrary other than a bare assertion.
Second, I already told you that there is no claim in the complaint that Apple is withholding Safari features in order to pad its apps business. If you believe otherwise, please provide relevant passages from the complaint.
Third, you’ve never had to reply to any of my comments. That’s on you.
4 replies →
>Do you have a rebuttal to that?
People should be allowed to run the software they want on a device they paid a lot of money to own. Period.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
That’s not the law, and never has been. Devices are combinations of hardware and software. The fact that a device maker allows you to install software subject to limitations is a privilege, not a right. Some device makers, like automobile and medical device manufacturers, often give you no such privileges at all.
Nevertheless, you’re entitled to your belief, which is really at the core of all this discussion. Fine, just say that. But to take that desire and gin up some conspiracy about how Apple is intentionally crippling the browser just to pad its apps business is a bridge too far. You don’t need a villain. Your desire is enough.
Yes. Safari is a less secure browser than Chrome, architecturally. Took far longer to ship sandboxing. Still hasn't fixed SLAP and FLOP. Still hasn't shipped proper site isolation. Takes far longer to fix reported vulnerabilities, and consistently "fixes" them superficially and incorrectly, requiring another fix.
Enough with the Apple fanboy paternalism. They don't need absolute control "for users' sake". They're not entitled to it.
> Still hasn't fixed SLAP and FLOP. Still hasn't shipped proper site isolation.
Those are interesting facts, but are ultimately a red herring. How will enabling JIT for other browser engines, absent the detailed vetting Apple is requiring to provide a Web Browser Engine entitlement, yield a more secure outcome?
> Enough with the Apple fanboy paternalism. They don't need absolute control "for users' sake". They're not entitled to it.
You are, of course, welcome to choose an alternative. If you prefer Android, by all means, use it!
6 replies →
> So yeah, it's easy to see which app is taking the most power, and users can do this easily, unless you think Apple's UX is so bad that users won't know how to read it?
It's easy to see, but seeing doesn't mean the user will do anything about it. I guarantee that for the average user, their list goes something like Instagram/TikTok/FaceBook/Twitter, and they haven't uninstalled any of those yet due to battery drain...
So what? Apps use resources, that isn't really an epiphany. Some apps use more than others, and that isn't rocket science. If a stupid user's battery is getting drained faster than they'd like, maybe someone will clue them in. Maybe not. Maybe they'll just buy a battery bank or something to keep their phone powered up longer. I really don't care, but locking out other browser engines from a platform isn't really the excuse you think it is. Apple is anti-competitive, plain and simple, and there's no getting around that.
https://www.justice.gov/archives/opa/media/1344546/dl?inline
> go to Settings > Battery, where you'll see a breakdown of battery consumption by app
And what percentage of users do you think ever check that, or even know it's there to check?
> If that's a problem for web browsers, then it's a problem for every single app in the app store.
No it's not, the app store disallows arbitrary code execution.
> There's nothing really unique about a web browser app that makes it more risky than any other app.
Yes there is -- JavaScript.
> Javascript is already very much sandboxed.
...by Safari. It wouldn't be if you allowed any developer to write their own JavaScript interpreter as part of their own browser.
> If web standards are standards, then let other web browsers on iOS.
That's a non-sequitur.
>And what percentage of users do you think ever check that, or even know it's there to check?
It does not matter. The functionality is there. If a user can't figure it out then they have other problems that having a smartphone won't fix for them.
>No it's not, the app store disallows arbitrary code execution.
You mean Javascript interpreters inside a web browser? lol. You mean like Safari is allowed to do? So only Apple can allow Apple apps to do this? I'm not sure you're thinking this through. Apples rule is a made-up rule designed to keep competition out, and force developers to write native apps so Apple can extort the developers by taking a percentage of purchases made through the native app.
>Yes there is -- JavaScript.
That's the dumbest possible argument you could make. Javascript has been very much sandboxed and secure for a very long time. There have been flaws in Safari that allowed remote code execution had nothing to do with Javascript, so good luck moving that goalpost somewhere else.
>...by Safari. It wouldn't be if you allowed any developer to write their own JavaScript interpreter as part of their own browser.
I'm not recommending my users use H@ck0rbR0Ws3R, I'm recommending they use Google Chrome, specifically because it supports the APIs my company needs to use for our product (on Android at least).
Okay Tim Apple, the DOJ is coming for you. You can explain this all to them when they come knocking, and they will.