4 ms·

What's the problem? The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your dev

by tgv 4y ago

What's the problem? The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data.

magicalist 4y ago
> What's the problem? If you're not asking rhetorically, that's one of the primary subjects of this report.
- tgv 4y ago
  I've read the first 25 pages or so, and the question is not answered there. One takeaway that is important, IMO, is this one: > Without browser diversity, a single company’s influence can shape the internet. That would be a problem if iOS accounts for a large majority of all http traffic. That, however, is not the case. If there's one platform that accounts for the large majority of http traffic, it is Chrome. It's estimated market share is 65%. Its derivates take 10% more. Allowing Chrome on iOS will slowly but surely obliterate Safari. Firefox' market share is a joke to begin with (and I say this as a lifelong Firefox user; I even use Firefox on iOS). Browser diversity ends when Chrome arrives on iOS, and it would end the limited privacy we have on iOS, unless Apple would really tighten the rules.
afavour 4y ago
> The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data. Why would allowing more browser engines have even the slightest impact on that? Those are APIs available to all native apps they have literally nothing to do with underlying browser engines.
- altairprime 4y ago
  Native apps go through App Store review, and can be permanently banned for misuse for tracking purposes without express user consent. Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs. This problem is unique to browser engines and no other kind of app, as browser engines are uniquely the only kind of app that needs this sort of permissions-granting per-site passthrough. Apple likely does not consider it interesting or relevant to their users to invest in validating the security models of third-party browser engines for their adherence to App Store standards, nor in providing a public API for third party engines to do so, and so closes off the entire problem space by refusing third-party engines altogether.
  - afavour 4y ago
    > Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs. ...a process which could be reviewed as part of the App Store review process. There isn't really any difference here. If your app reads gyroscope data App Store review will (theoretically!) make sure you're not doing anything nefarious with it. They could just as easily verify whether a browser passes data through correctly.
    - altairprime 4y ago
      Correct: they are not doing something that is possible to do. What benefits to their users result from that choice? (I’m aware of what drawbacks result from it, but that’s been explained to death in a thousand replies in a hundred posts about this already, so no need to derail into them here.)
      - afavour 4y ago
        One benefit that immediately comes to mind is the ability to protect yourself against a major security flaw in Safari: https://safarileaks.com/ https://safarileaks.com/ Apple did issue a fix after a few weeks but with no alternative browser engines the only alternative was “don’t use the web on your iPhone”, which is absurd. Other user benefits might include better performance, more capabilities (it took Apple years to implement WebRTC, for example) and in general more competition that might spur Safari into becoming a better browser.
        altairprime 4y ago
        The other browser engines have other security CVEs. Switching engines on the backend does not materially reduce the total attack surface for vulnerabilities for any given everyday user. Using security vulnerabilities as a primary condition of existence also leads to the introduction of engine oversight, review, and adamant “update or be removed” policy enforcement upon third parties, all of which who will complain endlessly in the press about the draconian App Store policies they would be subject to. I expect a better case will need to be made to convince Apple.
- tgv 4y ago
  May I remark that you're not answering the question? > Those are APIs available to all native apps they have literally nothing to do with underlying browser engines. Except that Safari doesn't expose them while Chrome wants to (or already does), offering Google more fingerprinting capabilities. Native apps don't send data to Google, Chrome does.
  - afavour 4y ago
    Safari absolutely exposes gyroscope data. Not sure where you’re getting the idea that it doesn’t. The problem is that Apple is slow to implement useful web standards. I don’t think the battery API is all that useful either but WebRTC is incredibly useful and it took Apple years to catch up. If they had meaningful competition in the iOS browser space they’d have more incentive to try.
Beached 4y ago
I complain about it as a user, and I take my money to android (reluctantly) as a result. I would love to run apple hardware for my phone, but their over the top control over the whole closed wall ecosystem is why I don't.
- tgv 4y ago
  Good for you, but it doesn't tell me why allowing only a single HTML rendering engine on iOS is a problem.

by tgv 4y ago

What's the problem? The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data.

magicalist 4y ago

> What's the problem? If you're not asking rhetorically, that's one of the primary subjects of this report.

tgv 4y ago
I've read the first 25 pages or so, and the question is not answered there. One takeaway that is important, IMO, is this one: > Without browser diversity, a single company’s influence can shape the internet. That would be a problem if iOS accounts for a large majority of all http traffic. That, however, is not the case. If there's one platform that accounts for the large majority of http traffic, it is Chrome. It's estimated market share is 65%. Its derivates take 10% more. Allowing Chrome on iOS will slowly but surely obliterate Safari. Firefox' market share is a joke to begin with (and I say this as a lifelong Firefox user; I even use Firefox on iOS). Browser diversity ends when Chrome arrives on iOS, and it would end the limited privacy we have on iOS, unless Apple would really tighten the rules.

afavour 4y ago

> The only people that complain about it are some web devs and companies that would love to get their grubby data collecting hands on your device's battery and gyroscope data. Why would allowing more browser engines have even the slightest impact on that? Those are APIs available to all native apps they have literally nothing to do with underlying browser engines.

altairprime 4y ago
Native apps go through App Store review, and can be permanently banned for misuse for tracking purposes without express user consent. Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs. This problem is unique to browser engines and no other kind of app, as browser engines are uniquely the only kind of app that needs this sort of permissions-granting per-site passthrough. Apple likely does not consider it interesting or relevant to their users to invest in validating the security models of third-party browser engines for their adherence to App Store standards, nor in providing a public API for third party engines to do so, and so closes off the entire problem space by refusing third-party engines altogether.
- afavour 4y ago
  > Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs. ...a process which could be reviewed as part of the App Store review process. There isn't really any difference here. If your app reads gyroscope data App Store review will (theoretically!) make sure you're not doing anything nefarious with it. They could just as easily verify whether a browser passes data through correctly.
  - altairprime 4y ago
    Correct: they are not doing something that is possible to do. What benefits to their users result from that choice? (I’m aware of what drawbacks result from it, but that’s been explained to death in a thousand replies in a hundred posts about this already, so no need to derail into them here.)
    - afavour 4y ago
      One benefit that immediately comes to mind is the ability to protect yourself against a major security flaw in Safari: https://safarileaks.com/ https://safarileaks.com/ Apple did issue a fix after a few weeks but with no alternative browser engines the only alternative was “don’t use the web on your iPhone”, which is absurd. Other user benefits might include better performance, more capabilities (it took Apple years to implement WebRTC, for example) and in general more competition that might spur Safari into becoming a better browser.
      - altairprime 4y ago
        The other browser engines have other security CVEs. Switching engines on the backend does not materially reduce the total attack surface for vulnerabilities for any given everyday user. Using security vulnerabilities as a primary condition of existence also leads to the introduction of engine oversight, review, and adamant “update or be removed” policy enforcement upon third parties, all of which who will complain endlessly in the press about the draconian App Store policies they would be subject to. I expect a better case will need to be made to convince Apple.
tgv 4y ago
May I remark that you're not answering the question? > Those are APIs available to all native apps they have literally nothing to do with underlying browser engines. Except that Safari doesn't expose them while Chrome wants to (or already does), offering Google more fingerprinting capabilities. Native apps don't send data to Google, Chrome does.
- afavour 4y ago
  Safari absolutely exposes gyroscope data. Not sure where you’re getting the idea that it doesn’t. The problem is that Apple is slow to implement useful web standards. I don’t think the battery API is all that useful either but WebRTC is incredibly useful and it took Apple years to catch up. If they had meaningful competition in the iOS browser space they’d have more incentive to try.

Beached 4y ago

I complain about it as a user, and I take my money to android (reluctantly) as a result. I would love to run apple hardware for my phone, but their over the top control over the whole closed wall ecosystem is why I don't.

tgv 4y ago
Good for you, but it doesn't tell me why allowing only a single HTML rendering engine on iOS is a problem.