7 ms·

https://developer.apple.com/support/dma-and-apps-in-the-eu/#browser-alt-eu https://developer.apple.com/support/dma-and-apps-in-the-eu/#... > To help keep users

https://developer.apple.com/support/dma-and-apps-in-the-eu/#browser-alt-eu https://developer.apple.com/support/dma-and-apps-in-the-eu/#... > To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities. This criteria seems arbitrary. Doesn't this allow Apple to arbitrarily prevent competitor engines like Blink and Gecko?

anon25783 3y ago
Absolutely! That's how the "walled garden" business model works.
KolmogorovComp 3y ago
I don’t think it will used against Blink and Gecko for obvious compliance reasons. But this clause will help Apple pressure them to keep security updates timely (which is a good things for the users). On the other hand they will likely use this to deny all ‘niche’ browser engine without a structured organization behind them (think Ladybug, maybe servo etc.)
- deleted 3y ago
  [deleted]
- toyg 3y ago
  Apple patch their browser twice a year at best; Firefox gets updates every month, plus security ones. Apple is hardly a model of virtue in the sector.
  - madeofpalk 3y ago
    > A new version of Safari shipped 17 times in the last 28 months — version 15.0, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 16.0, 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 17.0, 17.1, and now, today’s Safari 17.2. https://webkit.org/blog/14787/webkit-features-in-safari-17-2/#updating-to-safari-17-2 https://webkit.org/blog/14787/webkit-features-in-safari-17-2... Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023. https://webkit.org/blog/13691/webkit-features-in-safari-16-3/ https://webkit.org/blog/13691/webkit-features-in-safari-16-3... https://webkit.org/blog/13966/webkit-features-in-safari-16-4/ https://webkit.org/blog/13966/webkit-features-in-safari-16-4... https://webkit.org/blog/14154/webkit-features-in-safari-16-5/ https://webkit.org/blog/14154/webkit-features-in-safari-16-5... https://webkit.org/blog/14416/webkit-features-in-safari-16-6/ https://webkit.org/blog/14416/webkit-features-in-safari-16-6... https://webkit.org/blog/14445/webkit-features-in-safari-17-0/ https://webkit.org/blog/14445/webkit-features-in-safari-17-0... https://webkit.org/blog/14735/webkit-features-in-safari-17-1/ https://webkit.org/blog/14735/webkit-features-in-safari-17-1... https://webkit.org/blog/14787/webkit-features-in-safari-17-2/ https://webkit.org/blog/14787/webkit-features-in-safari-17-2... Did you notice the new Safari 17.3 Apple shipped 3 days ago?
    - DaiPlusPlus 3y ago
      > A new version of Safari shipped 17 times in the last 28 month > Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023. That's a very recent change: prior to 2022 Apple had far fewer updates to Safari on both macOS and iOS - and still witholds Safari updates from older iOS versions - for example, there was only 1 macOS Safari update per year between 2008 and 2015, and only 2 updates per year from 2015 to 2022; while things were just as sparse on iOS. The data is all here: click on the "Date relative" view on any of the items on https://caniuse.com/?search=webkit https://caniuse.com/?search=webkit
      - madeofpalk 3y ago
        We're litigating Apple's release cadance from 9 years ago? I get it. Apple used to update Safari infrequently. In the past two years they've increased how frequently they update. "Apple patch their browser twice a year at best" is no longer true.
        jsnell 3y ago
        No, it seems like we're litigating the cadence for a period of 15 years, ending only 2 years ago. Here's the options: 1. Apple was wildly irresponsible with the security and privacy of their users for a decade and a half, despite this childish press release about how EU is making their users less secure. 2. The risk profile of browsers only changed in the last couple of years, and until then it was totally safe for iOS browsers not to be patched regularly. 3. Apple doesn't particularly prioritize their users' security, but are setting up one more malicious compliance roadblock for anything that could threaten the tens of billions in pure profit they squeeze out of the Safari monopoly.
        DaiPlusPlus 3y ago
        None of those options apply: Apple did (and still does) ship regular security updates for iOS users which included Safari, but did not include Safari web-platform feature updates (i.e. CSS+JS+etc support) unless it was a significant iOS update (such as the yearly major-number increase or the "half-term" point releases) until 2022. Apple's handling of Safari mirrors Microsoft's stated plans for Internet Explorer back when Windows XP (and IE6) launched in 2001: they said they'd treat the browser as a core OS component that would only receive major web-platform updates with major OS releases (hence why we had to wait five years between IE6 and IE7, during which Firefox saved us from a mediocre web experience). ...could be worse: could have been like Outlook which has been stuck on Word's HTML rendering engine since 2007 right through until today's "New Outlook" rewrite - that's that's got to be an unbeatable record for the "world's most stagnant web-browser".
pompino 3y ago
Its usual BS from Apple. Imagine Microsoft blocking all non-store applications from running on Windows "to help keep users safe". No I'm not cheering for Microsoft to do the same. Its strange, but I want Apple to be more like Microsoft in this regard.
- hnburnsy 3y ago
  Yeah, if they wanted to keep users safe, all device permissions would be user controlled and all permissions would be default off.
  - pompino 3y ago
    Exactly, they're conflating choice with complexity. As you said, you can have any level of control, via various permission levels. I think what would be helpful if there was a concept of a "system admin" profile that you could apply onto any device/computer. Non-technical users may want Apple to be the 'sysadmin' and only use the Apple store, use Apple recommended apps, etc. - Kinda like the an MDM profile. Any other vendor, as a paid/managed service, could supply a more permissive app store, and manage updates, etc. Companies who issue work devices would have their own "profile" to manage the device.
  - kaba0 3y ago
    Every permission is default off, and ios is the safest computing platform for users (next to android), while windows has a much worse track record.
    - hnburnsy 3y ago
      Permissions that do not need a user prompt... 1. Basic Device Information: Device Name: App can access the device's name, like "John's iPhone." Device Model and OS Version: App can identify the device type (e.g., iPhone 14) and iOS version. Carrier Information: App can access network provider details. Wi-Fi Information: App can determine if Wi-Fi is enabled, but not specific network names or passwords. Battery Level: Accessible without explicit permission: Apps can access the current battery level without needing explicit user consent. 2. Contextual Information: Current Language: App can adapt content based on language settings. Time Zone: App can display time-related information accurately. 3. Necessary Functionality: Push Notifications: Apps can receive push notifications without explicit permission, but users can control this in Settings. Local Network Access: Apps can automatically access devices on the same local network (e.g., a printer). Background App Activity: Some apps can function in the background for tasks like downloading updates or syncing data. 4. Permissions Granted During Installation: Keyboard and Siri: Apps can request full access to the keyboard and Siri without additional prompts. 5. Accelerometer: No permission required: Unlike many other sensors, the accelerometer on iOS devices does not require explicit user permission for the app to access its data. However, there are some limitations: Foreground access: Apps can only access the accelerometer while they are actively in the foreground. Background access is restricted. Privacy concerns: While user consent isn't explicitly requested, some users might still find accelerometer access concerning due to its potential to reveal information about device movement and tilt. Transparency in app descriptions and responsible data handling are crucial. 6. Barometer: No permission required: Similar to the accelerometer, the barometer also doesn't require explicit user permission for access. It functions alongside the Core Motion framework, used for motion and environment-related data.
crazygringo 3y ago
I think it seems pretty clearly meant to include major competitors like Firefox and Chrome and Edge if Microsoft wants, but you can't just include a random build of Chromium that you never update. And this seems understandable to prevent a proliferation of 100's of "browsers" trying to steal your data. You actually have to be developing something legit -- not just reskinning a browser engine and leaving it.
- Yujf 3y ago
  That is fine as an app store policy, but they also want to impose those requirements for apps outside the appstore. That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this
  - DaiPlusPlus 3y ago
    > That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it). Remember the vast, vast majority of iOS users are people like (I assume) our parents - or people we knew in the late-1990s/early-2000s with an excessive number of Internet Explorer toolbars and Bonzi Buddy. I support Apple's mission to keep crap like that off their platform, but Apple sleepwalked into prompting this regulation of their app-store because they weren't the good-stewards they said they'd be - so I'm ambivalent about the whole thing.
    - Yujf 3y ago
      Tbh my mom doesn't even understand how to install an app from the app store. And she comes running for everything that she is not used to. I am not concerned that she would download anything from outside. But I do get your point that many people are incapable of evaluating what aoftware is trustworthy (and hell you cant always know there is a risk even with open source software that seems trustworthy unless you actually read all the source code, which I very rarely do and only for small programs or small parts of programs). However I do not think it is Apple's responsibility or right to be the guardian here.
eviks 3y ago
> This criteria seems arbitrary That's the point, but they sound nice
madeofpalk 3y ago
Read through the technical announcement for browser engines https://developer.apple.com/support/alternative-browser-engines/ https://developer.apple.com/support/alternative-browser-engi... These requirements are things like "Use memory-safe programming languages", "Adopt the latest security mitigations", if you ship your own certificate trust you should "provide information on how a root certificate authority (CA) can apply to become part of the program". All seems like pretty basic conditions designed to ensure that only Mozilla and Google can comply. To be honest, the browser engine stuff seems significantly more robust and permissive that I was expecting.
- jeroenhd 3y ago
  Pretty funny to see "use memory-safe programming languages, or features that improve memory safety within other languages" as a requirement when WebKit itself is built on top of C++ code. I wonder if Apple would be allowed to ship WebKit if they enforce this requirement under the spirit of the EU laws that made them change their minds.
  - Wowfunhappy 3y ago
    Note that the full requirement is: > Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content Emphasis added.
- Wowfunhappy 3y ago
  > Pass a minimum percentage of tests available from industry standard test suites: 90% from Web Platform Tests and 80% from Test262 Why is it any of Apple's business how many test suites a third party browser can pass? Why can't iPhone users run Links if they want to? Why can't they run a browser without Javascript support? Why can't they try out Ladybird to see how development is progressing? Like, even from a pure Apple-is-greedy perspective I don't understand the point of this.
- arlcode 3y ago
  On first glance, the browser stuff is mostly fine and seems to be motivated by security and UX concerns. In the end it's not a big impact on apples revenue if some people run chrome or Firefox. The store part on the other hand is really sketchy.
0x0 3y ago
Browsers that bring their own javascript engine will likely also need to support JIT in order to be able to compete with Safari on performace. Doing JIT on iOS requires a special entitlement grant from Apple in order to map memory pages as executable. An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS. Most other regular apps, even if they have a buffer overflow somewhere, will require a lot more fiddling in order to execute arbitrary code, and are thus a lower risk for users to install. In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard. To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.
- alerighi 3y ago
  > An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days. Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container. And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function. So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).
  - 3y ago

anon25783 3y ago

Absolutely! That's how the "walled garden" business model works.

KolmogorovComp 3y ago

I don’t think it will used against Blink and Gecko for obvious compliance reasons. But this clause will help Apple pressure them to keep security updates timely (which is a good things for the users). On the other hand they will likely use this to deny all ‘niche’ browser engine without a structured organization behind them (think Ladybug, maybe servo etc.)

deleted 3y ago
[deleted]
toyg 3y ago
Apple patch their browser twice a year at best; Firefox gets updates every month, plus security ones. Apple is hardly a model of virtue in the sector.
- madeofpalk 3y ago
  > A new version of Safari shipped 17 times in the last 28 months — version 15.0, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 16.0, 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 17.0, 17.1, and now, today’s Safari 17.2. https://webkit.org/blog/14787/webkit-features-in-safari-17-2/#updating-to-safari-17-2 https://webkit.org/blog/14787/webkit-features-in-safari-17-2... Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023. https://webkit.org/blog/13691/webkit-features-in-safari-16-3/ https://webkit.org/blog/13691/webkit-features-in-safari-16-3... https://webkit.org/blog/13966/webkit-features-in-safari-16-4/ https://webkit.org/blog/13966/webkit-features-in-safari-16-4... https://webkit.org/blog/14154/webkit-features-in-safari-16-5/ https://webkit.org/blog/14154/webkit-features-in-safari-16-5... https://webkit.org/blog/14416/webkit-features-in-safari-16-6/ https://webkit.org/blog/14416/webkit-features-in-safari-16-6... https://webkit.org/blog/14445/webkit-features-in-safari-17-0/ https://webkit.org/blog/14445/webkit-features-in-safari-17-0... https://webkit.org/blog/14735/webkit-features-in-safari-17-1/ https://webkit.org/blog/14735/webkit-features-in-safari-17-1... https://webkit.org/blog/14787/webkit-features-in-safari-17-2/ https://webkit.org/blog/14787/webkit-features-in-safari-17-2... Did you notice the new Safari 17.3 Apple shipped 3 days ago?
  - DaiPlusPlus 3y ago
    > A new version of Safari shipped 17 times in the last 28 month > Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023. That's a very recent change: prior to 2022 Apple had far fewer updates to Safari on both macOS and iOS - and still witholds Safari updates from older iOS versions - for example, there was only 1 macOS Safari update per year between 2008 and 2015, and only 2 updates per year from 2015 to 2022; while things were just as sparse on iOS. The data is all here: click on the "Date relative" view on any of the items on https://caniuse.com/?search=webkit https://caniuse.com/?search=webkit
    - madeofpalk 3y ago
      We're litigating Apple's release cadance from 9 years ago? I get it. Apple used to update Safari infrequently. In the past two years they've increased how frequently they update. "Apple patch their browser twice a year at best" is no longer true.
      - jsnell 3y ago
        No, it seems like we're litigating the cadence for a period of 15 years, ending only 2 years ago. Here's the options: 1. Apple was wildly irresponsible with the security and privacy of their users for a decade and a half, despite this childish press release about how EU is making their users less secure. 2. The risk profile of browsers only changed in the last couple of years, and until then it was totally safe for iOS browsers not to be patched regularly. 3. Apple doesn't particularly prioritize their users' security, but are setting up one more malicious compliance roadblock for anything that could threaten the tens of billions in pure profit they squeeze out of the Safari monopoly.
        DaiPlusPlus 3y ago
        None of those options apply: Apple did (and still does) ship regular security updates for iOS users which included Safari, but did not include Safari web-platform feature updates (i.e. CSS+JS+etc support) unless it was a significant iOS update (such as the yearly major-number increase or the "half-term" point releases) until 2022. Apple's handling of Safari mirrors Microsoft's stated plans for Internet Explorer back when Windows XP (and IE6) launched in 2001: they said they'd treat the browser as a core OS component that would only receive major web-platform updates with major OS releases (hence why we had to wait five years between IE6 and IE7, during which Firefox saved us from a mediocre web experience). ...could be worse: could have been like Outlook which has been stuck on Word's HTML rendering engine since 2007 right through until today's "New Outlook" rewrite - that's that's got to be an unbeatable record for the "world's most stagnant web-browser".

pompino 3y ago

Its usual BS from Apple. Imagine Microsoft blocking all non-store applications from running on Windows "to help keep users safe". No I'm not cheering for Microsoft to do the same. Its strange, but I want Apple to be more like Microsoft in this regard.

hnburnsy 3y ago
Yeah, if they wanted to keep users safe, all device permissions would be user controlled and all permissions would be default off.
- pompino 3y ago
  Exactly, they're conflating choice with complexity. As you said, you can have any level of control, via various permission levels. I think what would be helpful if there was a concept of a "system admin" profile that you could apply onto any device/computer. Non-technical users may want Apple to be the 'sysadmin' and only use the Apple store, use Apple recommended apps, etc. - Kinda like the an MDM profile. Any other vendor, as a paid/managed service, could supply a more permissive app store, and manage updates, etc. Companies who issue work devices would have their own "profile" to manage the device.
- kaba0 3y ago
  Every permission is default off, and ios is the safest computing platform for users (next to android), while windows has a much worse track record.
  - hnburnsy 3y ago
    Permissions that do not need a user prompt... 1. Basic Device Information: Device Name: App can access the device's name, like "John's iPhone." Device Model and OS Version: App can identify the device type (e.g., iPhone 14) and iOS version. Carrier Information: App can access network provider details. Wi-Fi Information: App can determine if Wi-Fi is enabled, but not specific network names or passwords. Battery Level: Accessible without explicit permission: Apps can access the current battery level without needing explicit user consent. 2. Contextual Information: Current Language: App can adapt content based on language settings. Time Zone: App can display time-related information accurately. 3. Necessary Functionality: Push Notifications: Apps can receive push notifications without explicit permission, but users can control this in Settings. Local Network Access: Apps can automatically access devices on the same local network (e.g., a printer). Background App Activity: Some apps can function in the background for tasks like downloading updates or syncing data. 4. Permissions Granted During Installation: Keyboard and Siri: Apps can request full access to the keyboard and Siri without additional prompts. 5. Accelerometer: No permission required: Unlike many other sensors, the accelerometer on iOS devices does not require explicit user permission for the app to access its data. However, there are some limitations: Foreground access: Apps can only access the accelerometer while they are actively in the foreground. Background access is restricted. Privacy concerns: While user consent isn't explicitly requested, some users might still find accelerometer access concerning due to its potential to reveal information about device movement and tilt. Transparency in app descriptions and responsible data handling are crucial. 6. Barometer: No permission required: Similar to the accelerometer, the barometer also doesn't require explicit user permission for access. It functions alongside the Core Motion framework, used for motion and environment-related data.

crazygringo 3y ago

I think it seems pretty clearly meant to include major competitors like Firefox and Chrome and Edge if Microsoft wants, but you can't just include a random build of Chromium that you never update. And this seems understandable to prevent a proliferation of 100's of "browsers" trying to steal your data. You actually have to be developing something legit -- not just reskinning a browser engine and leaving it.

Yujf 3y ago
That is fine as an app store policy, but they also want to impose those requirements for apps outside the appstore. That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this
- DaiPlusPlus 3y ago
  > That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it). Remember the vast, vast majority of iOS users are people like (I assume) our parents - or people we knew in the late-1990s/early-2000s with an excessive number of Internet Explorer toolbars and Bonzi Buddy. I support Apple's mission to keep crap like that off their platform, but Apple sleepwalked into prompting this regulation of their app-store because they weren't the good-stewards they said they'd be - so I'm ambivalent about the whole thing.
  - Yujf 3y ago
    Tbh my mom doesn't even understand how to install an app from the app store. And she comes running for everything that she is not used to. I am not concerned that she would download anything from outside. But I do get your point that many people are incapable of evaluating what aoftware is trustworthy (and hell you cant always know there is a risk even with open source software that seems trustworthy unless you actually read all the source code, which I very rarely do and only for small programs or small parts of programs). However I do not think it is Apple's responsibility or right to be the guardian here.

eviks 3y ago

> This criteria seems arbitrary That's the point, but they sound nice

madeofpalk 3y ago

Read through the technical announcement for browser engines https://developer.apple.com/support/alternative-browser-engines/ https://developer.apple.com/support/alternative-browser-engi... These requirements are things like "Use memory-safe programming languages", "Adopt the latest security mitigations", if you ship your own certificate trust you should "provide information on how a root certificate authority (CA) can apply to become part of the program". All seems like pretty basic conditions designed to ensure that only Mozilla and Google can comply. To be honest, the browser engine stuff seems significantly more robust and permissive that I was expecting.

jeroenhd 3y ago
Pretty funny to see "use memory-safe programming languages, or features that improve memory safety within other languages" as a requirement when WebKit itself is built on top of C++ code. I wonder if Apple would be allowed to ship WebKit if they enforce this requirement under the spirit of the EU laws that made them change their minds.
- Wowfunhappy 3y ago
  Note that the full requirement is: > Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content Emphasis added.
Wowfunhappy 3y ago
> Pass a minimum percentage of tests available from industry standard test suites: 90% from Web Platform Tests and 80% from Test262 Why is it any of Apple's business how many test suites a third party browser can pass? Why can't iPhone users run Links if they want to? Why can't they run a browser without Javascript support? Why can't they try out Ladybird to see how development is progressing? Like, even from a pure Apple-is-greedy perspective I don't understand the point of this.
arlcode 3y ago
On first glance, the browser stuff is mostly fine and seems to be motivated by security and UX concerns. In the end it's not a big impact on apples revenue if some people run chrome or Firefox. The store part on the other hand is really sketchy.

0x0 3y ago

Browsers that bring their own javascript engine will likely also need to support JIT in order to be able to compete with Safari on performace. Doing JIT on iOS requires a special entitlement grant from Apple in order to map memory pages as executable. An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS. Most other regular apps, even if they have a buffer overflow somewhere, will require a lot more fiddling in order to execute arbitrary code, and are thus a lower risk for users to install. In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard. To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.

alerighi 3y ago
> An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days. Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container. And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function. So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).
- 3y ago