3 ms·

It depends how you look at it and this twitter post takes only one perspective. Mine is different. The security I'm interested in for my use case is that there

by iasay 4y ago

It depends how you look at it and this twitter post takes only one perspective. Mine is different. The security I'm interested in for my use case is that there is one egress point from the operating system as far as a browser goes. That means I don't have apps shipping their own browser engines to circumvent the system block lists and screen time whitelist controls. Also comparing CVE rates is pointless as that's exploits and vulnerabilities that were identified and patched, not ones that are in active exploit or publicly unknown which is a metric you cannot measure. And of course if every app ships a browser or you change it, how many CVEs do you have from unpatched browsers shipped in apps? This twitter post feels like the old political adverts: "vote for us because the other guy is shit" (not because we have a better solution).

causi 4y ago
That means I don't have apps shipping their own browser engines to circumvent the system block lists and screen time whitelist controls. The mechanism for banning third-party browsers is rejection by the App Store reviewer, correct? Supposing Apple allowed third-party browsers but disallowed embedded browsers in non-browser apps, how would this security model change at all?
- mtomweb 4y ago
  For In-App Browsers we'd advocate for implementing a system similar to CCT which means that it just uses the user's default browser. For WebViews for native apps we'd advocate for simply using the system browser (every other solution seems too complicated).
btilly 4y ago
Comparing CVE rates is NOT pointless. The bad guys have basically the same toolset as the good guys. Therefore the rate at which vulnerabilities are being discovered by the good guys is indicative of how fast they are being discovered and exploited by the bad guys. Second the thread pointed out that many iPhones remain vulnerable and unpatched to openly disclosed security holes WITHOUT an option to update them. One must assume at that point that they are being exploited. The fact that alternate browsers don't have this problem is a significant version. But you do have a good point that it is bad for third party apps to bundle their own browsers to bypass controls, and then leave them vulnerable.
mtomweb 4y ago
OP here. The point of the post was not that Safari's security is bad (browser security in general is pretty excellent), the point is that Apple uses security as an excuse to block competition and has no evidence that it's browser is more secure than Firefox/Chrome/Edge etc. As for system block lists and screentime whitelist controls, that sounds like something any browser could plug-in to via a OS provided API. I'm in somewhat agreement with you that you can't identify the number of security flaws by vulnerability count, but when you combine that with the big delay in patching + patches not being delivered to the current (most popular) version of the OS it brings a lot of doubt to Apple's claims of both being able to patch faster and have better security. We're not advocating that apps should not be allowed to ship a browser unless they receive a browser entitlement which should be subject to some approval process / vetting etc. i.e. Browsers with strong security track records should be allowed to bring their browsers along with the engines with some affordance given to browsers that run from soft-forks of those engines.
- _kbh_ 4y ago
  Should browsers that ship to iOS have to raise their security profile to be the same as safari in your scenarios?.(afaik no browsers have the same exploit mitigations that safari does on M1/iOS because nothing else has the hardware to support these mitigations).
  - mtomweb 4y ago
    IMO, Only browsers with dedicated security teams should receive a browser entitlement (which includes a small team for soft-fork browsers) who are committed to keeping their browser secure. All browsers have vulnerabilities, and it's hard to measure. Although it's easy to spot browsers that aren't patching known vulnerabilities fast enough. Negligent browsers should be warned and then have their entitlements revoked. As for hardware protections like APRR or Pointer Authentication Codes (PAC) Apple should be forced to provide access to the third party browsers. I would steer clear of mandating exactly how the browsers should keep their users secure because that can be a point of debate and can be done both at a software layer or a hardware layer. Firefox has also introduced Site Isolation, Chromium has proven that adequately staffed security teams are able to mitigate hardware level security issues like Spectre & Meltdown with novel, system-level mitigations and these mitigations reached users before OS and hardware updates were able to fully remove the vulnerabilities.

by iasay 4y ago

causi 4y ago

That means I don't have apps shipping their own browser engines to circumvent the system block lists and screen time whitelist controls. The mechanism for banning third-party browsers is rejection by the App Store reviewer, correct? Supposing Apple allowed third-party browsers but disallowed embedded browsers in non-browser apps, how would this security model change at all?

mtomweb 4y ago
For In-App Browsers we'd advocate for implementing a system similar to CCT which means that it just uses the user's default browser. For WebViews for native apps we'd advocate for simply using the system browser (every other solution seems too complicated).

btilly 4y ago

Comparing CVE rates is NOT pointless. The bad guys have basically the same toolset as the good guys. Therefore the rate at which vulnerabilities are being discovered by the good guys is indicative of how fast they are being discovered and exploited by the bad guys. Second the thread pointed out that many iPhones remain vulnerable and unpatched to openly disclosed security holes WITHOUT an option to update them. One must assume at that point that they are being exploited. The fact that alternate browsers don't have this problem is a significant version. But you do have a good point that it is bad for third party apps to bundle their own browsers to bypass controls, and then leave them vulnerable.

mtomweb 4y ago

OP here. The point of the post was not that Safari's security is bad (browser security in general is pretty excellent), the point is that Apple uses security as an excuse to block competition and has no evidence that it's browser is more secure than Firefox/Chrome/Edge etc. As for system block lists and screentime whitelist controls, that sounds like something any browser could plug-in to via a OS provided API. I'm in somewhat agreement with you that you can't identify the number of security flaws by vulnerability count, but when you combine that with the big delay in patching + patches not being delivered to the current (most popular) version of the OS it brings a lot of doubt to Apple's claims of both being able to patch faster and have better security. We're not advocating that apps should not be allowed to ship a browser unless they receive a browser entitlement which should be subject to some approval process / vetting etc. i.e. Browsers with strong security track records should be allowed to bring their browsers along with the engines with some affordance given to browsers that run from soft-forks of those engines.

_kbh_ 4y ago
Should browsers that ship to iOS have to raise their security profile to be the same as safari in your scenarios?.(afaik no browsers have the same exploit mitigations that safari does on M1/iOS because nothing else has the hardware to support these mitigations).
- mtomweb 4y ago
  IMO, Only browsers with dedicated security teams should receive a browser entitlement (which includes a small team for soft-fork browsers) who are committed to keeping their browser secure. All browsers have vulnerabilities, and it's hard to measure. Although it's easy to spot browsers that aren't patching known vulnerabilities fast enough. Negligent browsers should be warned and then have their entitlements revoked. As for hardware protections like APRR or Pointer Authentication Codes (PAC) Apple should be forced to provide access to the third party browsers. I would steer clear of mandating exactly how the browsers should keep their users secure because that can be a point of debate and can be done both at a software layer or a hardware layer. Firefox has also introduced Site Isolation, Chromium has proven that adequately staffed security teams are able to mitigate hardware level security issues like Spectre & Meltdown with novel, system-level mitigations and these mitigations reached users before OS and hardware updates were able to fully remove the vulnerabilities.