5 ms·

They don't need to support, they just have no right to forbid. There's a big difference between those two things. Imagine if windows crippled Netscape by forc

They don't need to support, they just have no right to forbid. There's a big difference between those two things. Imagine if windows crippled Netscape by forcing them to use Internet Explorer engine on Windows? And this is just one thing Apple are doing that is unbelievable they are getting away with it.

chrisseaton 6y ago
But there's a specific consumer safety reason for it. Not letting other browsers use their own JS engine (which is what it means to 'forcing them to use Internet Explorer engine on Windows' in your analogy) is because Apple want to disallow write|execute for people's safety.
- Silhouette 6y ago
  Not letting other browsers use their own JS engine (which is what it means to 'forcing them to use Internet Explorer engine on Windows' in your analogy) is because Apple want to disallow write|execute for people's safety. Perhaps you're right. Maybe it's entirely coincidental that Apple's policy also prevents owners of Apple devices from using a browser with modern features that would allow web apps to effectively compete with the native apps from which Apple gets a huge cut of the revenue because of its monopoly control over the app store.
- oscargrouch 6y ago
  But if its because of safety, why only JavascriptCore VM allow write execute flag? If that was the real reason then, dont you think it should also be disabled in JavascriptCore? Or the real reason, is as it was pointed out in the other comment, is to cripple other browser engines that offer a platform that could actually be competitive with AppleKit's turning their control over the App store (and what people are allowed to access according to their own taste) irrelevant? And if that's the real reason behind it, its clear the end user best interests are not being taken into account, as in not having access to possible better options according to your own tastes, contrary to what a lot of people in the comments here are trying to make we believe its true.
- saagarjha 6y ago
  Granting dynamic-codesigning exclusively to JavaScriptCore shows a lack of confidence in their platform sandbox and the app store review mechanism, and a (occasionally dangerous) overconfidence in the quality of WebKit's security.

chrisseaton 6y ago

But there's a specific consumer safety reason for it. Not letting other browsers use their own JS engine (which is what it means to 'forcing them to use Internet Explorer engine on Windows' in your analogy) is because Apple want to disallow write|execute for people's safety.

Silhouette 6y ago
Not letting other browsers use their own JS engine (which is what it means to 'forcing them to use Internet Explorer engine on Windows' in your analogy) is because Apple want to disallow write|execute for people's safety. Perhaps you're right. Maybe it's entirely coincidental that Apple's policy also prevents owners of Apple devices from using a browser with modern features that would allow web apps to effectively compete with the native apps from which Apple gets a huge cut of the revenue because of its monopoly control over the app store.
oscargrouch 6y ago
But if its because of safety, why only JavascriptCore VM allow write execute flag? If that was the real reason then, dont you think it should also be disabled in JavascriptCore? Or the real reason, is as it was pointed out in the other comment, is to cripple other browser engines that offer a platform that could actually be competitive with AppleKit's turning their control over the App store (and what people are allowed to access according to their own taste) irrelevant? And if that's the real reason behind it, its clear the end user best interests are not being taken into account, as in not having access to possible better options according to your own tastes, contrary to what a lot of people in the comments here are trying to make we believe its true.
saagarjha 6y ago
Granting dynamic-codesigning exclusively to JavaScriptCore shows a lack of confidence in their platform sandbox and the app store review mechanism, and a (occasionally dangerous) overconfidence in the quality of WebKit's security.