3 ms·

> 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

> 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.
        afavour 4y ago
        You asked: > What benefits to their users result from that choice? But now we've gotten to > I expect a better case will need to be made to convince Apple Those aren't nearly the same things. Of course it's difficult to convince Apple, it isn't in their interests.
        altairprime 4y ago
        You make the case that it’s to the benefit of their users to allow multiple browser engines. I am personally not convinced by your case, for the reasons stated above. I do not expect Apple to be convinced by your case either. You may choose here to strengthen your argument, but your declaration that it’s hopeless to do so is of no help in that regard. If you wish to continue, I’m willing to listen.
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.

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.
      - afavour 4y ago
        You asked: > What benefits to their users result from that choice? But now we've gotten to > I expect a better case will need to be made to convince Apple Those aren't nearly the same things. Of course it's difficult to convince Apple, it isn't in their interests.
        altairprime 4y ago
        You make the case that it’s to the benefit of their users to allow multiple browser engines. I am personally not convinced by your case, for the reasons stated above. I do not expect Apple to be convinced by your case either. You may choose here to strengthen your argument, but your declaration that it’s hopeless to do so is of no help in that regard. If you wish to continue, I’m willing to listen.

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.