7 ms·

> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in

by pilif 4y ago

> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding. Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use. Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation. If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise. We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.

paol 4y ago
> That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. Yes, because Chrome and Firefox have such a terrible track record with security /sarcasm Lets face it, that's a conveniently plausible excuse, not an actual reason.
- Klonoar 4y ago
  You’re completely cutting off the other half of their post which makes sense with the context you’re quoting.
pmoriarty 4y ago
"Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?
- bfgoodrich 4y ago
- threeseed 4y ago
  > Why don't they do this? Because the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous. Especially with a web browser which are highly complex pieces of software.
  - pmoriarty 4y ago
    "the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous" Taking Apple's word for their browser being secure and other browsers not is just as if not even more ridiculous. What fair, independent way of determining browser security would you suggest be used instead of an audit?
    - CHY872 4y ago
      This isn't a competition for 'most secure' necessarily. Rather, simply reducing the surface area for attack is positive from a security perspective. If there's some vulnerability in iOS that come from being able to make pages executable, if you only have Safari JIT-ing you have to find a bug in Safari, or the app store review process (and get the user to download your app). If iOS runs Chrome as well, you can find a bug in _either_ Safari _or_ Chrome. While that's just Safari and Chrome, that's probably ok. But what happens when it's Safari, Chrome, Firefox, Opera, Brave, etc, etc? For the security test, there are various ways that an org builds software with integrity, and it's the sort of thing that requires a huge amount of effort to get right. Standards like FedRAMP, SOC2, ISO9001, etc etc are the sorts of standardized things that exist (containing things like 'all code must be reviewed'). I think for a browser, if you were Apple and were looking to accept other browser partners, you'd likely do something like this; regular audits of quality, requirements that must be met to maintain access, pentests, basically a continuous process that's to be met by the supplier (similar to how hardware suppliers must meet many requirements).
asddubs 4y ago
battery life is another stated reason I believe.
- noduerme 4y ago
  I can slip one line of code into a modern website that'll target a particular iphone model and run its battery to nothing in half an hour, and probably crash safari as well. Any language is susceptible to badly written or malicious code. At least with Flash it was in a box, in a virtual machine, and you had to approve it and could kill it at any time.
- kitsunesoba 4y ago
  It’s a big one. Google and Mozilla don’t prioritize efficiency, and it shows in the difference in battery life between using Safari and Chrome or Firefox on macOS. While users can choose their primary browser, they have no control over what embedded browsers third party apps use, and so if embedding Chromium becomes popular in third party apps it will unavoidably cut the battery life of many if not most users. When/if Apple starts allowing third party engines on iOS, I think they should require engines to meet minimum efficiency levels to prevent this issue. As a bonus, it’ll allow savvy laptop users to use community builds of desktop Chromium/Firefox with iOS efficiency compliance flags switched on if they want to extend the battery lives of their laptops by an hour or two.
Eric_WVGG 4y ago
Having a smartphone battery that lasts more than an hour is also a pretty good reason. It’s like the skepticism over the Steve Jobs “Flash” memo… why do nerds have such a hard time accepting that Apple might actually be sincere about wanting to make a decent product?
- native_samples 4y ago
  It's because there's nothing magical about HTML that makes it more battery efficient than Flash was. Quite the opposite really - Flash is a compact binary format designed specifically for high graphics performance in an era when HTML4 thought floating menus was cutting edge. The Jobs Flash memo was crystal clear about why Flash was being booted off his platform. It was to avoid "a third party layer of software coming between the platform and the developer".
  - jacobolus 4y ago
    There’s nothing “magical”, but Safari uses a lot less battery than Chrome. Safari developers optimize for battery life whereas Chrome developers seem not to care about client-side resource use.
    - native_samples 4y ago
      Right, yet, Chrome has an enormous number of Mac users. Apple argue that battery life is a topic so important it's worth banning competitors for but clearly when given the choice users disagree. There are other things more important to them.
      - jacobolus 4y ago
        My impression is that most computer users have a limited sense of which software applications are churning through battery, and instead just blame the computer vendor. That is, if Chrome churns through battery on a Mac laptop, the typical user is going to just think “Apple laptops have poor battery life”, never realizing that switching to Safari would make a significant difference.

by pilif 4y ago

paol 4y ago

> That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. Yes, because Chrome and Firefox have such a terrible track record with security /sarcasm Lets face it, that's a conveniently plausible excuse, not an actual reason.

Klonoar 4y ago
You’re completely cutting off the other half of their post which makes sense with the context you’re quoting.

pmoriarty 4y ago

"Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?

bfgoodrich 4y ago
threeseed 4y ago
> Why don't they do this? Because the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous. Especially with a web browser which are highly complex pieces of software.
- pmoriarty 4y ago
  "the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous" Taking Apple's word for their browser being secure and other browsers not is just as if not even more ridiculous. What fair, independent way of determining browser security would you suggest be used instead of an audit?
  - CHY872 4y ago
    This isn't a competition for 'most secure' necessarily. Rather, simply reducing the surface area for attack is positive from a security perspective. If there's some vulnerability in iOS that come from being able to make pages executable, if you only have Safari JIT-ing you have to find a bug in Safari, or the app store review process (and get the user to download your app). If iOS runs Chrome as well, you can find a bug in _either_ Safari _or_ Chrome. While that's just Safari and Chrome, that's probably ok. But what happens when it's Safari, Chrome, Firefox, Opera, Brave, etc, etc? For the security test, there are various ways that an org builds software with integrity, and it's the sort of thing that requires a huge amount of effort to get right. Standards like FedRAMP, SOC2, ISO9001, etc etc are the sorts of standardized things that exist (containing things like 'all code must be reviewed'). I think for a browser, if you were Apple and were looking to accept other browser partners, you'd likely do something like this; regular audits of quality, requirements that must be met to maintain access, pentests, basically a continuous process that's to be met by the supplier (similar to how hardware suppliers must meet many requirements).

asddubs 4y ago

battery life is another stated reason I believe.

noduerme 4y ago
I can slip one line of code into a modern website that'll target a particular iphone model and run its battery to nothing in half an hour, and probably crash safari as well. Any language is susceptible to badly written or malicious code. At least with Flash it was in a box, in a virtual machine, and you had to approve it and could kill it at any time.
kitsunesoba 4y ago
It’s a big one. Google and Mozilla don’t prioritize efficiency, and it shows in the difference in battery life between using Safari and Chrome or Firefox on macOS. While users can choose their primary browser, they have no control over what embedded browsers third party apps use, and so if embedding Chromium becomes popular in third party apps it will unavoidably cut the battery life of many if not most users. When/if Apple starts allowing third party engines on iOS, I think they should require engines to meet minimum efficiency levels to prevent this issue. As a bonus, it’ll allow savvy laptop users to use community builds of desktop Chromium/Firefox with iOS efficiency compliance flags switched on if they want to extend the battery lives of their laptops by an hour or two.

Eric_WVGG 4y ago

Having a smartphone battery that lasts more than an hour is also a pretty good reason. It’s like the skepticism over the Steve Jobs “Flash” memo… why do nerds have such a hard time accepting that Apple might actually be sincere about wanting to make a decent product?

native_samples 4y ago
It's because there's nothing magical about HTML that makes it more battery efficient than Flash was. Quite the opposite really - Flash is a compact binary format designed specifically for high graphics performance in an era when HTML4 thought floating menus was cutting edge. The Jobs Flash memo was crystal clear about why Flash was being booted off his platform. It was to avoid "a third party layer of software coming between the platform and the developer".
- jacobolus 4y ago
  There’s nothing “magical”, but Safari uses a lot less battery than Chrome. Safari developers optimize for battery life whereas Chrome developers seem not to care about client-side resource use.
  - native_samples 4y ago
    Right, yet, Chrome has an enormous number of Mac users. Apple argue that battery life is a topic so important it's worth banning competitors for but clearly when given the choice users disagree. There are other things more important to them.
    - jacobolus 4y ago
      My impression is that most computer users have a limited sense of which software applications are churning through battery, and instead just blame the computer vendor. That is, if Chrome churns through battery on a Mac laptop, the typical user is going to just think “Apple laptops have poor battery life”, never realizing that switching to Safari would make a significant difference.