Slashdot Mirror


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.

72 comments

  1. WRONG. by Anonymous Coward · · Score: 0

    You're only allowed to do that to Microsoft, because the rendering engine is NOT an integral part of the OS, until all the other operating systems have one.

  2. ha by Anonymous Coward · · Score: 0

    They should sue them to make them allow other software to run on the device, ala android.

  3. Why should they? by Anonymous Coward · · Score: 3, Insightful

    Just because you want another poorly coded standard as a way to track people, and allow exploit code to run?

    No thanks.

    1. Re:Why should they? by Anonymous Coward · · Score: 5, Insightful

      Safari is holding the web back much like IE6 did when Microsoft refused to upgrade it.

    2. Re:Why should they? by Anonymous Coward · · Score: 4, Informative

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

    3. Re:Why should they? by Anonymous Coward · · Score: 0

      So what you're saying is that Safari on iOS is a poorly coded standard, which tracks people, and allows exploited code to run. You're right, who would want 'another' browser like Safari, which is the new IE6 now days; so a shit browser.

    4. Re:Why should they? by Impy+the+Impiuos+Imp · · Score: 4, Insightful

      Then don't buy Apple. Buy Android, like I did.

      Dang, people. Freedom isn't hard to understand.

      --
      (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
    5. Re:Why should they? by leptons · · Score: 1

      This isn't about buying an iOS device vs. buying an Apple device. This is about iOS apps making more money than Android apps, and developers being forced to develop iOS apps if they want to make money, and Apple's anti-competitive practices.

    6. Re:Why should they? by Anonymous Coward · · Score: 0

      What if Google did it too? Would Google's actions on this change the law for Apple?

    7. Re:Why should they? by Anonymous Coward · · Score: 0

      Well isn't that nice? If only they supported all of the other relevant standards as well as the other browsers do. But even Edge is effectively compatible with ES6 (and is starting to support the rest of the web standards better than WebKit). It's downright pathetic how slowly Safari and WebKit are evolving. Sad from the company that pushed HTML5 so hard they left us with a legacy of half working webkit-prefixed crap that has been worse for web standards than what IE6 gave us, considering that IE6 could be hacked around to make it mostly compatible with a lot of stuff it didn't support properly.

  4. What happen when by Anonymous Coward · · Score: 0

    Let's assume Apple had the balls to pull out of France. Would other countries be more or less aggressive with them?

    1. Re:What happen when by Anonymous Coward · · Score: 0

      Neither. The only consequence would be that Apple loses some profits.

  5. Security... by Anonymous Coward · · Score: 3, Insightful

    Apple has said time and time again the issue is security-- making a sandbox isn't fucking easy. Despite whether that's good or bad, it's hard to do right. There's very little chance with the exception of Mozilla or Google proper making a secure (not massive security hole of a) browser for iOS.

    Not gonna happen (for a few years at least). Not in France, not in the us, not anywhere.

    Well I could see Apple doing this but on the proviso if you have a security hole that compromises the phone-- you owe them a billion dollars.

    1. Re: Security... by Anonymous Coward · · Score: 3, Insightful

      Unix has had sandboxing since forever with chroot.

      BSD jails have existed for more than a decade.

      These days, Linux has both lxc and systemd application level sandboxing (which is attained via cgroups, I believe).

      This isn't the middle ages. How hard is it to sandbox a fucking browser, really?

    2. Re: Security... by molarmass192 · · Score: 3, Informative

      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.

      --

      Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
    3. Re: Security... by Anonymous Coward · · Score: 0

      linux also has a sandbox application, separate from chroot.

    4. Re: Security... by ls671 · · Score: 2, Interesting

      Hmm, chroot needs to include its own OS or at least the parts you need to run said chrooted process unless compiled statically and still. This would make it more than sandbox lite according to your definition.

      chroot is viewed as less secure as bsd jails because it wasn't designed for a security purpose in the first place.

      I have a slackware pure 64 bits, no compat 32 what so ever. I chroot to a 32 bits full install and everything runs smoothly for legacy 32 bits apps.

      Granted, only one kernel runs, 1 /sys /proc, etc., which is "less isolated" than a qemu vm but lets you run on bare metal for specific applications.

      Anyway, even VMs can be victims of privilege escalation. BSD jail is less subject to it than chroot I hear. Good old unix chroot still has its usage nevertheless IMHO.

      --
      Everything I write is lies, read between the lines.
    5. Re: Security... by TheSync · · Score: 2

      There are other risks as well, such as Android's default Web browser lets attackers spoof the URL shown in the address bar, allowing for more credible phishing attacks.

    6. Re: Security... by TheRaven64 · · Score: 4, Informative
      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.

      --
      I am TheRaven on Soylent News
    7. Re: Security... by TheRaven64 · · Score: 1

      Granted, only one kernel runs, 1 /sys /proc, etc., which is "less isolated" than a qemu vm but lets you run on bare metal for specific applications.

      If stuff is actually running, then there's probably a /dev in the chroot as well. And if there's anything running as root, then it's trivial to mount /dev and escape from the chroot. It sounds as if you're using chroot for exactly its intended purpose: running applications that don't necessarily work with the host system libraries and tools. There was never intended to be any serious attempt to prevent an attacker from escaping from a chroot.

      --
      I am TheRaven on Soylent News
    8. Re: Security... by Karlt1 · · Score: 1

      How has all that Unix/Linux security worked out for Android?

    9. Re: Security... by Plumpaquatsch · · Score: 1

      linux also has a sandbox application, separate from chroot.

      "A sandbox application"? Do you even know what we are talking about here?

      --
      Of course news about a fake are Fake News.
    10. Re: Security... by DeVilla · · Score: 1

      Android has been exploited by the vendors. User's security was not the goal. Think windows 10.

    11. Re: Security... by ls671 · · Score: 1

      Actually, you can give access to what you want, /dev, /proc, /sys... or not as you wish. Letting anything run as root in a chroot when using it as a mild isolation technique is a big no-no and has always been.

      chroot can still be used as a mild isolation technique if you know what you are doing. That's why I mentioned that privilege escalation can happen even in VMs.

      Damn, I remember back in the days, logging in a system as guest and getting root in 30 seconds with an xterm exploit. Privilege escalation is the name of the game.

      --
      Everything I write is lies, read between the lines.
  6. More power to them by Anonymous Coward · · Score: 0, Informative

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

    1. Re:More power to them by Anonymous Coward · · Score: 0

      What the fuck are you people doing that makes you see Safari as being a problem? If anything, it's always freakin' Firefox which renders shit improperly or chokes on some javascript.

    2. Re:More power to them by SvnLyrBrto · · Score: 1

      In general, that's true. But oddly enough, there are some sites that Firefox can handle just fine but drop out in both Safari and Chrome. My company's web portals to Peoplesoft and SAP are the first two that come to mind. I can login with any browser. But they work correctly only on Firefox. When I mentioned this to the SAP help desk, they told me the site is "optimized for IE 6" (Seriously, WTFH? This was in 2014, not 2002!.) and that if I'd already upgraded, there was a tool on the IT public shared drive that would let me run my browser in "IE6 Mode". Yeah, I'd upgraded already... to a MacBook with VMware Fusion for Ubuntu, CentOS, and Kali, as needed.

      That was the last time I talked to that help desk, or IT team in general. And though it may be sub-par in general, Firefox is to this day the way I access SAP.

      --
      Imagine all the people...
    3. Re:More power to them by Anonymous Coward · · Score: 0

      As a former developer for PeopleSoft, I can tell you that the software is a total shitshow for browser support.

  7. Grab Apple by the pussy by Anonymous Coward · · Score: 0

    It works every time.

  8. Hmmm... by jenningsthecat · · Score: 1

    Interesting. This might turn into a crack in the garden wall. It might even be a harbinger of more cracks. Given its history in such matters, I suspect the French government won't side with Apple.

    Apple might end up having to comply, if only under the "you're voiding your warranty and cutting yourself off from manufacturer support" caveat that comes with rooting an Android device. Then again, they might just say "Sorry France, no more Apples for you"...

    --
    'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
    1. Re:Hmmm... by brantondaveperson · · Score: 2

      But the world is full of devices on which you can't just install whatever software you like. If a lawsuit like this succeeds, then what does that mean for all those devices? Will all manufacturers of computing devices have to provide SDKs for them? And remove whatever cryptographic restrictions have been placed on them? That would certainly make for a pretty interesting world.

    2. Re: Hmmm... by Anonymous Coward · · Score: 0

      What are you on?

      The only thing that needs to be done is that they click on the Approve Button.

      A browser is just like any other app. It requires no special treatment (asides from the API to handle links to it, but thats already implemented)

  9. I'm suing that French company by Anonymous Coward · · Score: 0

    They won't let me rape them, so I'm going to force them to comply even though it's their company.

  10. Because previous legislation against Microsoft.... by Anonymous Coward · · Score: 4, Insightful

    Well they should... or who doesn't remember the "N" SKU for Windows that prevented the instant bundling of Internet Explorer? Microsoft had to develop a separate version of Windows XP, etc. and beyond to meet this standard that stripped out the "preferred" browser that came with Windows in Europe and other regions. This allowed those users to choose and install the browser(/rendering engine) of their preference instead of being defaulted into the browser packaged with their operating system. Why should Apple be given a golden ticket and allowed to skip over such similar legislation? This is not that much different.

    Peace out.

  11. what a stupid lawsuit by Anonymous Coward · · Score: 0

    Hey can I sue Toyota for not making it possible to use a Ford engine?

    1. Re: what a stupid lawsuit by Anonymous Coward · · Score: 0

      You probably can. But you would lose quickly on the basis that you can if fact swap a ford engine into a Toyota if you really want you.

    2. Re: what a stupid lawsuit by Anonymous Coward · · Score: 0

      Based on that reasoning this lawsuit will also be a loser since you can put another web rendering engine on an iOS device if you really want to.

    3. Re: what a stupid lawsuit by Anonymous Coward · · Score: 0

      But you can already. Write an app that is a browser and use enterprise distribution.

    4. Re: what a stupid lawsuit by Plumpaquatsch · · Score: 1

      You probably can. But you would lose quickly on the basis that you can if fact swap a ford engine into a Toyota if you really want you.

      In the same way that you can put another browser engine onto an iOS device if you really want to. Case closed.

      --
      Of course news about a fake are Fake News.
    5. Re: what a stupid lawsuit by Anonymous Coward · · Score: 0

      Why are you agreeing with me while sounding like you're disagreeing?

    6. Re: what a stupid lawsuit by Anonymous Coward · · Score: 0

      the relative levels of difficulty are significantly higher

  12. I'm confused. by Anonymous Coward · · Score: 0

    Are the Developers being forced to make web browsers? Are They being forced to make browsers for iPhones? Are They being forced by Apple?

    1. Re:I'm confused. by TechyImmigrant · · Score: 2

      Are the Developers being forced to make web browsers? Are They being forced to make browsers for iPhones? Are They being forced by Apple?

      You really didn't grasp the gist of the complaint did you?

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    2. Re:I'm confused. by Anonymous Coward · · Score: 0

      Apparently you are confused. iOS only has one browser Safari. All other browser options in the app-store are just Safari, but with a different skin.

    3. Re:I'm confused. by Anonymous Coward · · Score: 0

      No, you didn't read the actual complaint and understand the implications and I apologize because it is Friday and most of us are enjoying some weekend libations. At what point did you decide that every code developer thought it would be a fantastic idea to abandon free and open source browser development for cross-platform development suddenly meant they were "forced" to make their own code source and compiled base available in the Apple store? What country and what planet are you residing on where you splice Apple's IPhone browser from the IMac browser.. the INTERNET masses that purchased the Apple TV. By design they are supposed to be the same.

      I was merely trying to introduce that an OS vendor that restricted any form of access to the INTERNET and its information.. via a "web browser", "rendering engine" or any other API was found complicit in restricting choice. What I introduced as the complaint here was not about the browser.. which I generalized.. but that any browser on the operating system was trapped in a "walled garden" where the rendering engine pre-installed by the manufacturer restricted the purchaser to see what the OS vendor wanted no matter what possible other browser application was chosen. Please step back 20 paces.. put down the "pint" (or pints.. good for you) and see a post for what it was meant to be... a comparison where vendor "X" and/or vendor "Y" provided code that stranglehold-ed the choices and/or end-result interpretation of a user utilizing that device from what was meant to be a free and open source of information... devoid of manufacturer or retailer's slant of opinion/outcome/informational restrictions.

      If you took my post to be an attack on developers you missed my point enough to score poorly in the Summer Olympics.

      Peace out.

  13. This would destroy Apple's walled garden... by Assmasher · · Score: 1, Interesting

    ...because you could deploy apps without the App Store.

    Let's hope this happens! :)

    --
    Loading...
    1. Re:This would destroy Apple's walled garden... by Karlt1 · · Score: 1

      So while we are at, should we also force Sony, Microsoft, and Nintendo to open up their respective consoles?

    2. Re:This would destroy Apple's walled garden... by Assmasher · · Score: 1

      Who is stopping you?

      --
      Loading...
  14. WebKit is Open Source - So why not help improve it by Anonymous Coward · · Score: 1

    So if the compatient's beef is that WebKit doesn't support the "latest" HTML5, WebM, "whatever is hot today" standard. Why not actually help improve the WebKit engine, since you know, its Open Source. They can first begin by first reading the Getting Started page. And for those individuals that want to know the Licensing WebKit page indicates that "WebKit is open source software with portions licensed under the LGPL and BSD licenses."

    Is WebKit the best rendering engine under the sun, not really, but then none of them are. They all encompass a series of compromises that the developers try to balance as they're developing the software. Most of them boil down to simply the number of hours available. Each project can only develop based upon the number of people willing to contribute to the common goal.

    If they don't like the pace at which the software is being developed, then either shut-up, or help. No one is making you develop any software for a specific platform. If you don't like it you can always take your toys elsewhere and hope the grass is greener on the other side. :)

  15. It's javascript engines Apple doesn't allow. by Henriok · · Score: 2, Informative

    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.

    --

    - Henrik

    - when the Shadows descend -
    1. Re:It's javascript engines Apple doesn't allow. by drinkypoo · · Score: 0

      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 still hard for me to believe Apple has really built a cellphone empire on turning a general purpose computer into a limited purpose computer. I guess this is what comes of not teaching programming in schools.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 1

      When iPhones first came out, everyone thought Apple was crazy and that native-code apps (Appke at first tried to assuage security concerns by allowing only HTML5 apps) would be phoning Nigeria and 1-900-KGB-DOOD to charge users fraudulently. AT&T took a lot of convincing to get them to agree to a phone with ObjC apps as opposed to just HTML applets. No phone company wanted that kind of security nightmare. The current restriction against running arbitrary downloaded code (no JS engines, which is what this story is really about) forgets that Apple's relationships with the phone networks depend on security agreements, and its consumer reputation relies on apps not being able to undermine its security model.

    3. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      When iPhones first came out, there was no App Store, there was no native-code apps, and everything was HTML. Touch events were introduced at that time.

    4. Re:It's javascript engines Apple doesn't allow. by Guidii · · Score: 2

      Apple’s App Store policies state: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.” Source: http://www.howtogeek.com/18428...

    5. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      When iPhones first came out, everyone thought Apple was crazy and that native-code apps (Appke at first tried to assuage security concerns by allowing only HTML5 apps) would be phoning Nigeria and 1-900-KGB-DOOD to charge users fraudulently.

      I've never heard this fearfrom anyone but Apple. Moreover, there were multiple smartphone platforms at the time Apple introduced the iPhone and none of those had such issues.

      AT&T took a lot of convincing to get them to agree to a phone with ObjC apps as opposed to just HTML applets. No phone company wanted that kind of security nightmare

      Mobile network companies have no say in what features phones get and do not get and they have no way of refusing phones that they do not approve ofon their network.

      The current restriction against running arbitrary downloaded code (no JS engines, which is what this story is really about) forgets that Apple's relationships with the phone networks depend on security agreements, and its consumer reputation relies on apps not being able to undermine its security model.

      Apple does not need any relationship with the phone networks. Apple sells phones, the mobile network companies offer a service you can use with a phone. In some cases, they also sell the phones made by Apple and others. However, Apple (or any other manufacturer) is in no way dependent on that resale model. Moreover, other smartphones do not have those restrictions and have not been shown to undermine the security model any more than iPhones do.

    6. Re:It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      not rendering web pages or showing WebM movies

      All browsers on an IPhone have to rountrip through Apples outdated WebKit version, it does not support something or has various decade old bugs? Well no rendering for you unless you invest in a full time developer position to work around Apple (TM) issues.

    7. Re:It's javascript engines Apple doesn't allow. by thegarbz · · Score: 1

      That's like saying I don't ban motorcycles, I only ban engines under 1.4L. The technicalities are different but the effect is the same. An alternate rendering engine which can't do javascript is as useless as useless as teats on a bull.

    8. Re: It's javascript engines Apple doesn't allow. by drinkypoo · · Score: 1

      When iPhones first came out, there was no App Store, there was no native-code apps, and everything was HTML. Touch events were introduced at that time.

      Right, the carriers didn't want the masses of asses running arbitrary code on their phones. Yes, cellular phones could already run apps. But they also had extraordinarily limited computing environments. Most phones' ability to run externally developed software was restricted to some Java MIDlets, and typically a given phone would only implement a subset of the available APIs, usually a fairly small one. The phone literally wasn't capable of running any apps that were a threat to the network; even if you got them all running the same thing at once the worst thing they could do would be generate a lot of SMS.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      The iPhone was not significantly (or even at all) more powerful than the smartphones that were popular at the time it was launched. Moreover, several of those did allwo running arbitrary code. I am not aware of any problems this has ever happened.

      Running user applications on the iPhone was limited because Apple felt it contributed to the user friendliness and they wanted to have tight control over the platfrom. The opinions of mobile network companies were not relevant. The only way they were involved was with the weird monopoly scheme Apple was trying to pull of.

    10. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      Every single one of my flip phones, purchased 3rd partty or first has been able to install Java midlets from any source.

      Not sure where you're getting this idea from.

    11. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      And the slashdot community screamed bloody murder (well, more like looked condescendingly down their noses over their guts) about what a piece of crap it was because there were no native apps.

    12. Re: It's javascript engines Apple doesn't allow. by drinkypoo · · Score: 1

      The iPhone was not significantly (or even at all) more powerful than the smartphones that were popular at the time it was launched.

      Uh, what? Yes, yes it was. The dominant devices were ~200MHz single-core flip phones.

      The opinions of mobile network companies were not relevant. The only way they were involved was with the weird monopoly scheme Apple was trying to pull of.

      Ah, the past looks so simple from your perspective, because you weren't paying attention. Apple had to kiss carrier ass to make those deals at first. Later, when the iPhone proved it would shift units, the situation was reversed.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    13. Re: It's javascript engines Apple doesn't allow. by Dog-Cow · · Score: 1

      Today, you're correct that Apple doesn't have to rely on the carriers' good graces to sell usable phones. But that's because we've had 9 years of the iPhone to show carriers that they'll lose out on a lot of data charges if they don't allow iPhones on their network. When Apple was making deals in 2006-2007, they had to find a carrier that would permit them on the network to begin with. Both Apple and AT&T made out like bandits, but one of the things Apple had to give up was selling the phone on other (US) networks for a couple years.

    14. Re: It's javascript engines Apple doesn't allow. by BasilBrush · · Score: 1

      What you are talking about is feature phones, and in America maybe that's about as much as you had. In Europe we had full smartphones years before th iPhone. The Market leader was Nokia phones running Symbian OS, which had full apps written in C++. For 7 years before iPhone.

    15. Re: It's javascript engines Apple doesn't allow. by Anonymous Coward · · Score: 0

      Rightly so. Lacking handbags, we had no use for a shiny piece of hardware, that wouldn't run applications, because of software limitations. We are still looking down to those using an iPhone cause they think it makes em look pretty.

  16. Vale Firefox OS by ChunderDownunder · · Score: 1

    A web browser and universal app platform rolled into a phone OS. Winning was not so much market share but 'keeping the bastards honest'.

    But, to summon the app app luddite apps guy, a platform without software is stillborn and the mobile web stagnates...

    Perhaps if management at Google loosened the strings, they'd release a spin of Chrome OS as a ROM for Nexus/Pixel devices - a web device with Android app support.

  17. Re:Because previous legislation against Microsoft. by tlhIngan · · Score: 2

    Well they should... or who doesn't remember the "N" SKU for Windows that prevented the instant bundling of Internet Explorer? Microsoft had to develop a separate version of Windows XP, etc. and beyond to meet this standard that stripped out the "preferred" browser that came with Windows in Europe and other regions. This allowed those users to choose and install the browser(/rendering engine) of their preference instead of being defaulted into the browser packaged with their operating system. Why should Apple be given a golden ticket and allowed to skip over such similar legislation? This is not that much different.

    Easy. Microsoft was a monopoly that abused their OS monopoly to enter the browser market. The courts forced Microsoft to unbundle the browser because of this.

    iOS? At 20%, hardly a monopoly. Apple can't leverage either WebKit on iOS nor iOS itself to distort any market.

    Anyhow, browsing engines are hard - especially keeping them sandboxed. iOS and Safari run in a very low privilege state (lower than normal apps) so Safari can use a JIT javascript engine, while normal apps have teo use a slower interpreted engine to prevent sandbox exploits. Then there's battery life itself - given all the crap that can idle in the background chewing up CPU cycles, I wouldn't be surprised if WebKit on IOS has many tweaks to conserve battery life.

  18. Re: WebKit is Open Source - So why not help improv by Anonymous Coward · · Score: 0

    You're kidding, right?

    Webkit may be open sourced, but you're deluding yourself thinking patches that don't improve the parent company won't be included in the official binary.

    Stuff like webm will never be included, considering how hard they railed against it despite minimal investment.

  19. Re:WebKit is Open Source - So why not help improve by Anonymous Coward · · Score: 0

    Apple is one of the world's richest tech companies. They partly built their iPhone empire on HTML5. It's high time they gave back something other than a ton of broken webkit-prefixed shit, and restrictions preventing its users from using a browser that wasn't so far behind that even Edge is about to leapfrog it in terms of capabilities and standards support.

    You're completely buying into what Apple wants you to buy into: using proprietary native solutions instead of open ones. If that's your bag, great. But the web was a way out of that rat's nest, and it might actually do so if Apple wasn't part of the problem now.