A French Company is Suing Apple To Open the iPhone To Rival Browsing Engines (recode.net)

A French maker of open-source software said Friday it is suing Apple in an effort to get the company to make iOS more supportive of Web standards. Nexedi is suing Apple under French law in hopes it can force Apple to allow rival browsing engines onto the iPhone. From a report on Recode:Although Apple allows rival browser apps, such as Google's Chrome, on to the iPhone, the'y all have to use Apple's Web rendering engine. That means the ability to draw on the latest Web standards is is limited to whatever Apple decides to include. That means some newer technologies, like the WebM video standard and the WebRTC protocol for real-time communications, can't be made to work in an iOS browser even though they work in nearly all other browsers. "We hope [this lawsuit] will help Apple to sooner support the latest Web and HTML5 standards on its iOS platform -- the operating system used by all iPhones," Nexedi said in a blog post, which also explains the more granular details of how technology works and what needs to change, in their estimation.

Comments

More power to them

[Anonymous Coward]

Safari sucks. It's not quite as retarded as Internet Explorer and Edge, but it's a burden on web developers.

Re:Why should they?

[Anonymous Coward]

The latest version of Safari (10) is 100% compliant with ES6.

It's javascript engines Apple doesn't allow.

[Henriok]

Apple are allowing other web rendering engines. They just aren't allowing engines running arbitrary code on their plaform. That includes Java, Flash, JavaScript and emulators. It's the "running arbitrary code" that's the problem, not rendering web pages or showing WebM movies. You are allowed to make such apps.

Re: Security...

[molarmass192]

Ok, but chroot != sandbox, it's not really even sandbox-lite. A sandbox is complete process isolation, almost full virtualization, not just obfuscating the system root. I say almost because the process doesn't have to include it's own OS.

Re: Security...

[TheRaven64]

First, chroot isn't a sandbox. For desktop applications, it isn't even useful isolation because you have a big attack window via the IPC to the display server. That said, iOS uses the TrustedBSD MAC framework (also in FreeBSD - Apple funded the development of both), which allows very fine-grained resource control to processes. The entire sandboxing framework is based on this.

Second, the grandparent doesn't really mean sandboxing, he means compartmentalisation (which depends on some isolation primitive). Process-based isolation is fine when your threat model is different levels of trust for different processes. In a web browser, that isn't the case. Your tab browsing some random site needs to be strongly isolated from the other tab that contains your webmail login. Ensuring that this isolation is really present and not leaky is a very hard problem. Even that isn't really enough: if someone sends you an image as an email attachment and there's a vulnerability in your copy of libpng that allows arbitrary code execution, it doesn't really help you that the attacker can't compromise any other tabs: they already have the high-value target.

Beyond that, mobile Safari also has some quite neat tricks. It makes use of execute-only memory for the JavaScript engine. On startup, it reserves a range of memory for the JIT code emission and generates a special memcpy that copies data into an offset within that address range. It then deletes all copies that the process holds of the base address and marks the special memcpy as execute-only, so there is nowhere in readable memory that contains the address range where JavaScript code will run, making it almost impossible to exploit gadgets placed in JIT'd JavaScript code.

That said, no security is perfect and a monoculture is a good way of turning a vulnerability into a pandemic. If you have 4 different browsers with approximately equal market share, it's a lot harder to exploit all of them. This is why Verisign uses a mixture of FreeBSD and Linux with 3 different DNS server implementations on their root nameservers: If you want to take down their root zone, you need a to have a compromise for at least two DNS servers and for both operating systems.