Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender

Posted by timothy on from the you-say-one's-better-I-say-one's-worse dept.

An anonymous reader writes "Apple has hit back over claims that the browser shipped with its iPhone, iPod Touch, and iPad devices is significantly slower than Android's equivalent, calling the independent testing 'flawed.' 'They didn't actually test the Safari browser on the iPhone,' Apple's Kerris argues. 'Instead they only tested their own proprietary app, which uses an embedded Web viewer that doesn't actually take advantage of Safari's Web performance optimisations.' This, claims testing firm Blaze.io, is news to the world. 'Embedded browsers are expected to behave, for the most part, the same as the regular browser,' the company stated, defending its methodology. 'However, Apple is now stating that their embedded browser, called UIWebView, does not share the same optimisations MobileSafari does.'"

155 comments

  1. Chrome by webmistressrachel · · Score: 3, Funny

    1st post, so Chrome must be fastest...

    --
    This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
  2. I love beating this dead horse! by The+End+Of+Days · · Score: 0, Redundant

    I'm not sure how this is worth posting... I mean I guess there are the ad views to consider but really, this has been fully covered already in a multitude of stories.

    Still, that Slashdottian Apple-hate must be worth a lot of money to Taco and friends.

    1. Re:I love beating this dead horse! by MobileTatsu-NJG · · Score: 1

      I'm not sure how this is worth posting... I mean I guess there are the ad views to consider but really, this has been fully covered already in a multitude of stories.

      Still, that Slashdottian Apple-hate must be worth a lot of money to Taco and friends.

      This story's redundant, the post I'm quoting isn't.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  3. Oh hell. by revscat · · Score: 2

    This is turning into a Big Deal, isn't it?

    So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

    You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

    1) Apple is evil and trying to cripple web performance so that people buy apps
    2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

    1. Re:Oh hell. by mr100percent · · Score: 1

      I don't think Apple is trying to cripple web performance.

      • Apple had been pushing for Web apps as early as 2007, showing developers how to do it at WWDC, showcasing third-party ones on their website, and originally saying that it would offer all a user would need instead of a compiled app. The developer SDK and third-party apps only came after a year of popular demand, and appeared in iOS 2.0
      • Their marketing/PR for the new iOS update stated new faster javascript support etc. They're not going to both promote it while trying to kill it
      • Full HTML5 apps (like Google Wave for iPhone or BlackSwan) skip the App Store completely and show up as icons on the Home screen, they run outside of Safari and have application caches, as Apple specified to developers

      While it's mighty peculiar that MobileSafari will run differently than Webkit-using apps, I don't think this is malice by Apple.

    2. Re:Oh hell. by Drakino · · Score: 5, Insightful

      Once iOS gains WebKit 2, this issue should go away. Development activity is pretty rapid right now, so there may be a big push to have this done for iOS 5. A story on Ars indicates bugs about web apps not using the new Nitro engine were closed with "not to be fixed by exec order". Based on that, I'm guessing the following occurred:

      Apple execs wanted web browsing to be faster on iOS, by taking advantage of the same tech that is being used to accelerate browsers on the desktop. They also wanted to maintain the secure environment in iOS, and bring more security to the OS X side. WebKit 2 had been in development internally for a little while, and was opened up to the public for contributions in April 2010. Google, and others have been making major contributions to it, and development is proceeding.

      Apple also had plans to release the iPad 2, along with an eventual iPhone 5 and new iPod Touch featuring dual core processors. iOS 5 is too far out, so iOS 4.3 had a lot of development effort spent on making MobileSafari faster. Because WebKit 2 wasn't ready, security wasn't ready to open it up to the world, and the decision was made to do what they could in the time frame allowed, and make it open to other developers later.

      The "not to be fixed by exec order" is likely in place to prevent engineers from wasting time on trying to bring new improvements to old frameworks, and instead keeping engineers focused on finishing iOS 5, possibly with WebKit 2 in time for the iPhone 5 release this summer.

      Apple is a hardware company (as far as where the majority of their profits come from), and so software development relating to iOS will always be driven by hardware release cycles. They may slip features from software, but key pieces have to be in place to meet the hardware cycle. It's looking like March will be new iPad time, June for iPhones, then September for iPods. iPads will debut new CPUs, iPhones will debut new major iOS releases and some other features (gyroscope, possibly NFC, etc), and iPods will just be a phoneless iPhone. Each release comes with a new iOS, iPad being a final point release of the previous iOS, iPhone being the new one, then iPods gaining the first point release of the new OS.

    3. Re:Oh hell. by MBCook · · Score: 4, Informative

      John Gruber had a good analysis of all this. Basically, the embedded UIWebView didn't change in speed between 4.2 and 4.3, but Safari did. The fact that outside apps didn't speed up has been called "Apple slowing down" other apps.

      The new JS engine (Nitro) uses JIT, which needs writable, executable pages in memory. In iOS 4.2 and before, this didn't exist because of security concerns. In 4.3, it exists, but only for MobileSafari. Because of this, UIWebView in other applications can't use JIT, which is where the performance gains came from.

      So it's a security thing. Apple has decided to error on the side of security here. That's the executive order, that they won't reduce the security (my speculation/interpretation). Android isn't being as pedantic about it. Gruber suggest it could be possible (in a future update) to run the JIT in a separate process, so the main process doesn't need the wrire/execute pages to keep security. It's a good idea, it'd be nice if Apple did it. I'm not sure it matters that much.

      So the problem with this comparison is that instead of MobileSafari, they used something using UIWebView, which doesn't have the permissions to do JIT. Thus it's an unfair comparison, in that users will see faster speeds than they are reporting (since users will use Safari, they have no choice).

      --
      Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    4. Re:Oh hell. by alostpacket · · Score: 5, Funny

      You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

      Yeah but if you were Nostradamus, the predictions would be much more fun.

      Quatrain XI: The searching metal man roze to fell the mighty apple. Chrome, Fire, and Foxes all rejoiced at the silence atop the buffering hills.

      --
      PocketPermissions Android Permission Guide
    5. Re:Oh hell. by Tharsman · · Score: 1

      If you care, and don't just want to pretend Apple is EEEEVILL, you can easily find the reasons.

      Here is a link to make it easier.

      Short version: Security. Nitro uses JIT and that allows javascript to access memory as a native application.

    6. Re:Oh hell. by Hope+Thelps · · Score: 2

      That's the executive order, that they won't reduce the security (my speculation/interpretation).

      That doesn't appear to make any sense.

      Normally you'd expect it to be the exact same code running the embedded web apps as running the browser apps, just no chrome. i.e. you'd expect it to be Apple's code running, with whatever security Apple has written into it.

      How does not displaying the chrome give rise to a security risk? If there's a security vulnerability from running your javascript using Apple's engine then that risk is identical with or without the chrome - isn't it?

      --
      To summarise the summary of the summary: people are a problem. ~ h2g2
    7. Re:Oh hell. by Anonymous Coward · · Score: 0

      This was discussed above. Safari may be running in a more restrictive sandbox, than is not used for apps using UIWebView.

    8. Re:Oh hell. by multipartmixed · · Score: 1

      > If there's a security vulnerability from running your javascript
      > using Apple's engine then that risk is identical with or without the chrome - isn't it?

      Presumably applications embedding the browser have access to Obj-C interfaces that aren't exposed to the web.

      This means that the browser and JS engine have to run in the same process space as your non-safari program.

      Which means that your non-safari program is one buffer overflow away from executing arbitrary machine code stored in data segments, because the JS JIT requires that ability itself.

      Do you understand now? Do you trust that every app in the app store is as well written and tested as Safari?

      --

      Do daemons dream of electric sleep()?
    9. Re:Oh hell. by Anonymous Coward · · Score: 0

      This is turning into a Big Deal, isn't it?

      So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

      You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

      1) Apple is evil and trying to cripple web performance so that people buy apps
      2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

      3) They were holding it wrong.

    10. Re:Oh hell. by Anonymous Coward · · Score: 0

      That doesn't appear to make any sense.

      Normally you'd expect it to be the exact same code running the embedded web apps as running the browser apps, just no chrome. i.e. you'd expect it to be Apple's code running, with whatever security Apple has written into it.

      How does not displaying the chrome give rise to a security risk? If there's a security vulnerability from running your javascript using Apple's engine then that risk is identical with or without the chrome - isn't it?

      This isn't about any security concerns running JavaScript, its about giving an app the right to load and execute anything from the internet. Apple has a policy against that, and they won't just abandon it so some apps can run faster than before - which, just as a reminder, is not the same as running slower than before, like some want to pretend.

    11. Re:Oh hell. by MBCook · · Score: 1

      Right. It's a little odd for web apps saved to springboard (where you just save the link from Mobile Safari, so there is no 3rd party code involved), but it makes sense for a game or other app that may use a UIWebView to display news or such. It probably doesn't need the extra performance, but it would be a big security risk.

      --
      Comment forecast: Bits of genius surrounded by a sea of mediocrity.
  4. No doubt related to the JS brouhaha by Anonymous Coward · · Score: 0

    Ars has a good analysis of why Mobile Safari is different than the embedded browser:
    http://arstechnica.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars

    1. Re:No doubt related to the JS brouhaha by icebraining · · Score: 2

      No, ars is talking about the red herring of security, if it can run things of the net, it can run things from the local drive at least as safely

      The difference isn't the origin, is the app running the code. They trust Safari to JIT and keep unknown code from the net contained, but not the any random app.

      --
      Dilbert RSS feed
  5. Real reason by Anonymous Coward · · Score: 4, Informative

    If they allow apps to use UIWebView with Nitro they would need to allow all those apps to mmap(PROT_EXEC,) on pages, download code and stick on to the pages and execute it - bypassing Apple's control.

    Now will come a multi process WebKit2 (a la Chrome) that will allow them to only give executable page permission to WebKit2 process and apps can just do IPC to it.

    1. Re:Real reason by Anonymous Coward · · Score: 0

      You're not supposed to post facts to Slashdot. You're supposed to either (l)ike or (d)islike the entity the story mentions.

    2. Re:Real reason by bongey · · Score: 3, Interesting

      4.3 has address space randomization , which is why the pwn2own exploit doesn't work any more.

    3. Re:Real reason by Anonymous Coward · · Score: 0

      >4.3 has address space randomization

      That's not the problem. The problem is that some developer might release a program that allows remote code injection if you know the secret code. For example, a game that connects to the developers server and downloads a code library which the program maps in to memory and runs. Apple is afraid of people doing an end-run around their vetting process by getting an injectable program passed then injecting things which wouldn't be approved after it is accepted on to the store.

      This is perfectly reasonable with Apple's "protecting the noobs from themselves since they don't know any better" strategy which seems to be working out well for them, even if I don't like it.

    4. Re:Real reason by bongey · · Score: 1

      Charlie Miller comments who has won the pwn2own contest portion for the iPhone for that last few years. “The first one [in 2007] was really, really easy. They had nothing, no sandboxing. Everything was running as root. It was super easy. The SMS one [in 2009] was harder because of DEP but there were no sandbox issues because the process that controlled SMSes wasn’t in a sandbox.” “As of 4.3, because of the new ASLR, it will be much harder,” Miller added.

  6. Not Reasons Unknown! by VirginMary · · Score: 3, Insightful

    It has been covered that the reason is that Nitro compiles ECMAScript down to ARM machine instructions and then sets the memory region that contains the compiled code to be executable. This is a dangerous ability for arbitrary apps to have and that's why right now only Safari on iOS 4.3 has this capability. No stupid conspiracy theories are needed here. And it's not a bug either.

    --
    When 1person suffers from a delusion,it is called insanity.When many people suffer from a delusion,it is called religion
    1. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 2, Insightful

      So what you're saying is that Mobile Safari does something dangerous and exploitable, and that it's not a bug, it's a feature?

      Just want to make sure we're on the same page here.

    2. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      And how is it not dangerous that safari has this?

    3. Re:Not Reasons Unknown! by MoonBuggy · · Score: 4, Interesting

      Presumably Apple is happy that, being the people who wrote the entire OS in the first place, they can implement this behaviour securely in Safari. They don't have the same faith in giving that ability to any random app developer, who could end up creating a difficult to spot vulnerability via the API either by malice or ignorance.

    4. Re:Not Reasons Unknown! by Nightlight3 · · Score: 2

      Native apps (including those running UIWebView) already use native ARM machine instructions as they wish (you can set compiler to to compile into pure native ARM instructions or write ARM assembly code if you want; Apple only controls which system APIs developers can access, which they can do from JS->machine compiled code equally well). So that "explanation" doesn't make much sense. It is more likely that they merely rushed the iOS upgrade out before their programmers had finished the porting to UIWebView.

    5. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      Wow. That doesn't sound safe. First thought was guess the 5 sec Apple pown to ownage will be even quicker with this?

      Seriously, anybody have any comments on the safety of this / what prevents a small bug in Safari from easily becoming arbitrary code execution?

      Or even the possibility that some special javascript doesn't even need a Safar bug, just this feature to do evil stuff on the device?

    6. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      If the capability is available to Mobile Safari as a user space applications, how is not available to any other other user space application?

    7. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      So surfing the net can open iOS to exploits? It the Web browser that can run any random code from the net, how is that different than some random app developer?

    8. Re:Not Reasons Unknown! by SiMac · · Score: 5, Informative

      The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit to segregate data from code. Because of the way a JIT works, it needs to be able to execute code in the data area of memory. Allowing every app to do this would effectively eliminate the additional security that the NX bit provides.

    9. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 1

      All JITs are exploitable - even if you could reliably ensure only the JIT can write executable pages, you could just use ROP to make the JIT compile code for you.

    10. Re:Not Reasons Unknown! by SiMac · · Score: 2

      Wow. That doesn't sound safe. First thought was guess the 5 sec Apple pown to ownage will be even quicker with this?

      Seriously, anybody have any comments on the safety of this / what prevents a small bug in Safari from easily becoming arbitrary code execution?

      Or even the possibility that some special javascript doesn't even need a Safar bug, just this feature to do evil stuff on the device?

      JavaScript gets compiled to ARM instructions, and those ARM instructions get executed. You can't just put ARM instructions in a webpage and expect it to run. Barring a bug in the Nitro JIT, it's perfectly secure. Any JIT (including V8, JaegerMonkey/TraceMonkey, and the JVM), on any platform, necessarily has the same potential vulnerabilities. If the JIT is written properly and doesn't attempt to execute code in the parts of RAM that contain data from untrusted sources, it's not a problem. Most desktop platforms are much worse because they allow execution of code anywhere in RAM, in any application, regardless of its source. (Ever heard of a buffer overflow?)

    11. Re:Not Reasons Unknown! by SiMac · · Score: 5, Insightful

      No. Google's JIT is just as insecure. The problem is not in the implementation, it's that you need to disable the NX bit on an area of memory to run a JIT at all. There is no workaround to this, unless the JIT isn't actually a just in time compiler.

    12. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      Third party apps aren't allowed to create or modify executable pages, hence no JIT. There's no general way to make JIT compatible with W^X, because even if you check what code is trying to make executable pages you can still just use ROP to call those JIT-approved functions and manufacture the particular code sequence you want.

    13. Re:Not Reasons Unknown! by sgbett · · Score: 1

      Steady on, rationality and reason only 4 posts in. Must be a record!

      --
      Invaders must die
    14. Re:Not Reasons Unknown! by vinehair · · Score: 1

      read the post you replied to you fucking idiot.

      Thanks for the useful reply. But you really don't understand what was just said. What, exactly, is restricting the use of this capability to just Safari? Protections, DRM style authentication? Nobody has ever worked around those ever. Nope.

    15. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 1

      Most desktop platforms are much worse because they allow execution of code anywhere in RAM, in any application, regardless of its source. (Ever heard of a buffer overflow?)

      Really? My desktop platform features DEP so it won't execute code that is marked as data. Yes, that does break the Google Chrome auto-updater (since it is a piece of crap that tries to execute data), but most apps work fine with it. When you say "most desktop platforms" I guess you really mean that most users don't enable DEP. On Windows it has been available since Windows XP SP2 - but it isn't enabled unless the user turns it on. I would imagine most other operating systems are the same?

    16. Re:Not Reasons Unknown! by Random+Destruction · · Score: 4, Informative

      So surfing the net can open iOS to exploits?

      That wouldn't be anything new. I jailbroke my iphone4 by going to a website.

      --
      :x
    17. Re:Not Reasons Unknown! by tlhIngan · · Score: 3, Insightful

      The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit to segregate data from code. Because of the way a JIT works, it needs to be able to execute code in the data area of memory. Allowing every app to do this would effectively eliminate the additional security that the NX bit provides.

      I believe this to be the case. It may also explain why IOS 4.3 is 3GS and later, excluding the iPhone 3G. I believe the ARMv7 architecture introduces the NX bit into the platform, something that the ARM11 used in the original iPhone and iPhone 3G don't have. The 3GS uses a Cortex A8 and the iPhone 4 is a Cortex A8 derivative CPU, which means they have NX support. This would mean that no, IOS 4.3 will not run on the iPhone 3G.

      The other thing is, IOS 4.3 probably also runs Safari in an even more locked down user account - there's root, and mobile (apps run under this user account). Safari may be set to run under an even stricter sandbox that's chroot and has no permissions anywhere else or even alter any files via standard permissions, a la nobody. Apps won't have access to that since there's probably little the account can actually do. This way the attack surface via Safari is minimal as the native code can't really run amok without finding a local root kernel exploit.

    18. Re:Not Reasons Unknown! by node+3 · · Score: 2, Insightful

      It's part of the iOS security model. You're right that this model can be hacked. It's commonly referred to as 'jailbreaking'.

      However, if the user never jailbreaks their iOS device, this security model remains in place. There's also always the potential for remotely exploitable flaws, but that's no different than any other network-capable OS. By confining the new javascript implementation to Safari, Apple is blocking local exploits.

      Also, it's technically feasible that WebKit2 can allow third-party access to the new engine without compromising iOS's security model.

    19. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      It is running the way it is meant to in the reality Distortion Field.
      I, for one, welcome our sociopathic overlord!

    20. Re:Not Reasons Unknown! by omfgnosis · · Score: 1

      If you're asking how it's technically restricted, the next-generation features of the "Nitro" JavaScriptCore engine are not in the UIWebView libraries. That's how it's not available.

      To the great-grandparent-post's broader point about security distinctions, it's hard to imagine that an app implementing UIWebView is more of a security risk than an app specifically geared toward visiting sites which execute arbitrary code with JSC. If JSC is vulnerable to malice or ignorance, then Safari is much more vulnerable than some random App Store application, based on surface area alone.

    21. Re:Not Reasons Unknown! by iserlohn · · Score: 0

      But Safari is exposed to the wider internet, while UIWebView is only exposed to the site that the app dev has coded in. With Apple's leash on the app store, wouldn't it be more safe to enable Nitro on UIWebView compared to Safari on i(phone)OS?

      --
      :. Ultimate Control Dedicated/VM Servers
    22. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      The other thing is, IOS 4.3 probably also runs Safari in an even more locked down user account - there's root, and mobile (apps run under this user account). Safari may be set to run under an even stricter sandbox that's chroot and has no permissions anywhere else or even alter any files via standard permissions, a la nobody. Apps won't have access to that since there's probably little the account can actually do. This way the attack surface via Safari is minimal as the native code can't really run amok without finding a local root kernel exploit.

      ok, I get what you're saying here. I really do. But since apple controls the platform, what's preventing them from running the segment of code for the browser under a different user account than the segment of code running the rest of the app? You could be very well right that Safari is running as Nobody and apps are not, but the browser is already instantiated and further controlled through an API. They can change their implementation below that layer and probably just haven't yet. I imagine they just have yet to devote the engineering time to it since I'm sure it'd take a bit of leg work.

    23. Re:Not Reasons Unknown! by Anonymous Coward · · Score: 0

      Whether it is Safari or a third party application embedding a web browser, the JavaScript being run is untrusted code. If Nitro is not safe for third party applications to use, it is not safe for Safari.

    24. Re:Not Reasons Unknown! by PipsqueakOnAP133 · · Score: 1

      In iOS, apps are sandboxed by the kernel. Look up "seatbelt."
      The kernel is fed a permissions document which dictates what the app is allowed to do.

      Basically, MobileSafari gets special privileges which other apps arn't given.
      Attempts to use the Nitro engine result in success in MobileSafari.
      Attempts to use the Nitro engine in other iOS apps is likely to just fail or get auto-killed by the kernel. (not sure which one)

    25. Re:Not Reasons Unknown! by tlhIngan · · Score: 1

      In iOS, apps are sandboxed by the kernel. Look up "seatbelt."
      The kernel is fed a permissions document which dictates what the app is allowed to do.

      Basically, MobileSafari gets special privileges which other apps arn't given.
      Attempts to use the Nitro engine result in success in MobileSafari.
      Attempts to use the Nitro engine in other iOS apps is likely to just fail or get auto-killed by the kernel. (not sure which one)

      That's one protection, but there are others.

      Like on Linux, you have root, and users run apps as a user group. But websites have the httpd run under "nobody" to ensure that the attack surface is small, despite the relatively large area of attack (random CGI scripts with unknown vulnerabilities).

      No reason iOS can't do the same - the only way to violate the NX bit on iOS is if you agree to run your app with even lower permissions than it would have normally. It's similar to say, Internet Explorer where on Vista/7 IE runs with absolutely no priviledges - it can write to a very specific spot on the filesystem (it's shadowed temporary directory), and then it must call to a helper process in order to move the file somewhere else (that helper process displays the download dialog and everything so websites can't drive-by download).

      Defense in depth - apps run as user apps would under a traditional Unix security model. Apps that are particularly vulnerable run with even less priviledges. A bug in the Nitro JIT or a Webkit vulnerability aided by Nitro is a pretty big attack surface. Run it on a low-priviledge account with little to no access and it's a lot more secure.

      And iOS apps are by no means secure with the default sandboxing - see "jailbreakme.com" - it used TWO exploits to work - first was a PDF reader vulnerability to get it to execute code, the second was a local root exploit so it can break out of the sandbox.

    26. Re:Not Reasons Unknown! by PipsqueakOnAP133 · · Score: 1

      Something I'm curious about is the extent of the difference between the privileges given to MobileSafari compared to the normal iOS 3rd party apps. We know they're different, but by how much?

      I have a feeling that jailbreakme.com might not have worked from a UIWebView in a 3rd party app. But nobody ever bothered to try it since it's easier to use MobileSafari.

  7. Reason is known by Anonymous Coward · · Score: 0

    This is turning into a Big Deal, isn't it?

    So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

    You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

    1) Apple is evil and trying to cripple web performance so that pople buy apps
    2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

    3) 3rd-paty applications are subject to restrictions on dynamically generated code for security. Nitro uses dynamic recompilation, which means that it can't be used int 3rd party applications. Ergo, those apps are stuck with iOS 4.2-level performance.

  8. Universal benchmark by countertrolling · · Score: 2, Funny

    Farmville, right?

    --
    For justice, we must go to Don Corleone
    1. Re:Universal benchmark by Anonymous Coward · · Score: 0

      If only Mobile Safari or UIWebView were able to run it.

    2. Re:Universal benchmark by countertrolling · · Score: 1

      :) Exactly...

      --
      For justice, we must go to Don Corleone
  9. What a wank by Anonymous Coward · · Score: 0

    Is this 1997? It's been ten years since browser speed was an issue, and yes these are mobile devices, but they've been faster than decade-old computers for years themselves. I haven't used a mobile browser since 2007 that gave any issues with *speed* of the browser.

    It's a metric approaching the uselessness of the old "how long does it take to scroll through a word document" speed tests of the 80s and early 1990s.

    1. Re:What a wank by Joe+Tie. · · Score: 1

      I think this has a lot more to do with JIT compilation in webapps than it does for a random page. When considering the limited speed of a phone, using something that's running only as interpreted code is a pretty big limitation.

      --
      Everything will be taken away from you.
    2. Re:What a wank by omfgnosis · · Score: 1

      Browser speed matters because browsers can and will do a lot more than they have done in the past. Browsers have been "fast enough" primarily because developers only push functionality to the limits of browser performance.

  10. Safari is fast, it's UIWebView has no Nitro. by Marble68 · · Score: 1, Interesting

    Apple is accelerating JavaScript in Safari, but not UIWebView.
    In fact, I think there's a bug they're working on that apps on the home screen that use UIWebView are REALLY slow.

    Check out this blog post: http://inzi.com/2011/03/will-phonegap-apps-seemingly-suck-because-of-uiwebview-in-ios-4-3/

    The Safari browser has Nitro JavaScript acceleration while UIWebView doesn't.

    I also read that some think Apple doesn't like the web based apps cause it can bite into their app store revenue. I don't know if that's true or not.

    --
    /me sips his coffee and ponders a new sig...
    1. Re:Safari is fast, it's UIWebView has no Nitro. by larry+bagina · · Score: 5, Insightful

      if "slow" means "the same speed as they were two weeks ago when we weren't complaining about how slow they are", then, yes, they run at the same speed they did two weeks ago when nobody was complaining how slow they were. If you have a 10 terrabyte porn collection, you don't lose porn just because your friend has a 15 terrabyte porn collection.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    2. Re:Safari is fast, it's UIWebView has no Nitro. by RyuuzakiTetsuya · · Score: 2

      UIWebView is still pretty fast. 2 seconds versus 3 seconds is nothing to sneeze at. I'd still take it over say Trident, or whatever they based WP7's JS engine on.

      I doubt that it's about not biting into app store revenue, app revenue just simply doesn't make up a huge portion of Apple's revenue. Getting hardware into people's hands is.

      --
      Non impediti ratione cogitationus.
    3. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 1

      Do you understand that the absolute time has nothing to do with anything? It doesn't mean every webpage will load in 3 seconds; it means that that particular page took 50% longer to render in iOS than Android.

      Furthermore, app store revenue IS a substantial source for Apple. Think about it: while they do make quite a profit off all hardware, apps cost them nothing to produce, but they keep a huge percentage anyway.

    4. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 0

      I've always been complaining about how slow the iPhone's browser is...

    5. Re:Safari is fast, it's UIWebView has no Nitro. by brillow · · Score: 1

      Its not about the speed, but how Apple is putting itself against developers. I remember a few years ago Firefox (or some browser) being slower on OSX than Safari because Safari had access to some undocumented, locked-out resources in the OS. Didn't Microsoft get sued for this?

    6. Re:Safari is fast, it's UIWebView has no Nitro. by UnknowingFool · · Score: 1

      If anything I've seen way more complaints about Safari being slower than anything else. Also it's quite possible that two browsers running on two different engines run at different speeds. Now if Chrome was slower than Safari you might have more of point. Another problem I see with individual installations of Firefox is that users load all sorts of addons which slow it down considerably.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    7. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 0

      That "undocumented feature" was a checkbox in the window's nib file to control redrawing rate while scrolling, IIRC, documented and available to everyone. WebView (not Safari) used an undocumented function to set it since it's embedded in a window and the programmer may have forgotten to set it properly.

    8. Re:Safari is fast, it's UIWebView has no Nitro. by brillow · · Score: 0

      Of course. The point was that Apple seems to have a history of locking developers out of some features so that their products have an advantage. This isn't surprising, but its not exactly above-board either. If you want to make something nice on the iPad, Apple wants you to make an App so they make money. Even iff the app is free, you gotta buy that $100 dev kit. They just want you in their garden.

    9. Re:Safari is fast, it's UIWebView has no Nitro. by agent_vee · · Score: 1

      "Slow" and "Fast" are relative terms. What was "Fast" 2 weeks ago might not be so today. 10 terabytes of porn is still 10 terabytes of porn no matter what day it is.

    10. Re:Safari is fast, it's UIWebView has no Nitro. by aztracker1 · · Score: 1

      Your friend needs to setup a torrent of that... lol

      --
      Michael J. Ryan - tracker1.info
    11. Re:Safari is fast, it's UIWebView has no Nitro. by omfgnosis · · Score: 1

      Safari was faster than Firefox because Firefox was a dog in desperate need of serious updating, and because Safari's release schedule is somewhat more aggressive than Firefox's. There was never any "secret APIs" that Safari could access and Firefox couldn't. The "secret APIs" haven't been opened up, but Firefox is closing the performance gap. How does that fit into this little conspiracy theory?

    12. Re:Safari is fast, it's UIWebView has no Nitro. by SimonTheSoundMan · · Score: 1

      How about accelerated H264 then? It took Apple a couple of years to release that in an SDK.

    13. Re:Safari is fast, it's UIWebView has no Nitro. by tepples · · Score: 1

      if "slow" means "the same speed as they were two weeks ago when we weren't complaining about how slow they are"

      I have a hundred U.S. dollars. I wait 20 years. I now have less real money than before because of inflation. Computing has inflation too: look at how hashcash implementations deal with Moore's law.

    14. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 0

      Actually, it's widely known that the App Store isn't a huge money maker for Apple. Sure, it's not measly but it pales in comparison to what they make off hardware sales. It's no different than their iTunes music store. Both their iTunes music store and App Store are a means to an end, the end being selling hardware.

    15. Re:Safari is fast, it's UIWebView has no Nitro. by UnknowingFool · · Score: 1

      Your specific complaint was Apple was holding back APIs to make Safari faster than Firefox, but anecdotally that doesn't appear to be true. Also my point is you can't compare two different browsers with two different engines and come to that conclusion based on evidence that didn't exist. So the basic jist of your entire post was: Apple sucks.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    16. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 0

      Do you understand that the absolute time has nothing to do with anything? It doesn't mean every webpage will load in 3 seconds; it means that that particular page took 50% longer to render in iOS than Android.

      Despite the flaw in testing and the fact that the Nexus S has a 25% faster CPU (oh wait, isn't that also a flaw in the test), the iPhone embedded browser was still loading 16% of the websites faster. So despite being "slower" it can still be faster, absolute and relative be damned.

    17. Re:Safari is fast, it's UIWebView has no Nitro. by RyuuzakiTetsuya · · Score: 1

      Natural home birthing is twice as likely to kill the mother or the child as birthing at a hospital.

      Here's the rub with that statistic, the number is insanely low to begin with, meaning that the reality is that home birthing with a midwife really isn't all that dangerous(it's still all natural woo woo, but that's not the point).

      Sure, UIWebView is 50% slower than Android in this test, but, the real measurable difference isn't say the difference between IE6 and Chromium's daily build in Sunspider. The difference is largely negligible.

      --
      Non impediti ratione cogitationus.
    18. Re:Safari is fast, it's UIWebView has no Nitro. by brillow · · Score: 1

      Here's the link:
      http://www.expertreviews.co.uk/general/172902/firefox-uncovers-hidden-speed-boost-for-safari
      "Vladimir Vukievi was attempting to find out why the performance of Firefox 3 builds was hitting a plateau, when he noticed that Safari was happily drawing pages at twice the frame rate.

      Digging around in Apple's WebKit engine, which drives Safari, he spotted over 100 undocumented "OS-secrets-only-WebKit-knows"."

      I'm not comparing speed. I am just saying, Apple seems to have a history of building performance hooks into its OS which can only be used by software that it makes. It would be like if everything but iTunes was slower at processing MP3's because iTunes could access a better encoder built into the OS.

    19. Re:Safari is fast, it's UIWebView has no Nitro. by Anonymous Coward · · Score: 0

      Here's the link: http://www.expertreviews.co.uk/general/172902/firefox-uncovers-hidden-speed-boost-for-safari "Vladimir Vukievi was attempting to find out why the performance of Firefox 3 builds was hitting a plateau, when he noticed that Safari was happily drawing pages at twice the frame rate.

      Digging around in Apple's WebKit engine, which drives Safari, he spotted over 100 undocumented "OS-secrets-only-WebKit-knows"."

      I'm not comparing speed. I am just saying, Apple seems to have a history of building performance hooks into its OS which can only be used by software that it makes. It would be like if everything but iTunes was slower at processing MP3's because iTunes could access a better encoder built into the OS.

      Of course what you fail to mention is that probably all these 100 "OS-secrets-only-WebKit-knows" APIs are just like the one he found in his search "why the performance of Firefox 3 builds was hitting a plateau, when he noticed that Safari was happily drawing pages at twice the frame rate." Because that super-duper secret API call allowed Webkit to do something that it couldn't do because it wasn't a program but instead a shared library, something that a program could do without calling that super-duper secret API: set a fucking flag in a fucking XML config file.

      Yes, by setting this fucking flag in a fucking config file, fucking Firefox was able to suddenly update its screen twice as fast - all without needing to call some undocumented "OS-secrets-only-WebKit-knows". Ohh, and he was only able to find these super-duper-extra secret APIs because Apple has OpenSourced the fu-ntastic Webkit that calls them.

  11. What do people want by fermion · · Score: 4, Insightful
    At first Apple wanted apps through safari. This might have been good as the Apps would work on any device, and Apple would have no lockin. But developers and users wanted native apps. So we have the App store, with lockin, and large cuts for Apple.

    So what do we have now. Natives Apps that run in he browser. If lockin and Apple rules are such an issue, then why no run he app in a browser? Probably because most develpers like the lockin and he profit opportunities i provides. They my bitch about Apple, but they are not exacty running away.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    1. Re:What do people want by farnsworth · · Score: 4, Informative

      At first Apple wanted apps through safari. This might have been good as the Apps would work on any device, and Apple would have no lockin. But developers and users wanted native apps. So we have the App store, with lockin, and large cuts for Apple.

      So what do we have now. Natives Apps that run in he browser. If lockin and Apple rules are such an issue, then why no run he app in a browser? Probably because most develpers like the lockin and he profit opportunities i provides. They my bitch about Apple, but they are not exacty running away.

      If you look at the docs and the API that Apple provides for iOS, it's very clear that it was always their intention to provide a mechanism for native apps. Perhaps it was not ready when the first iPhone shipped, or perhaps there is some other reason. But it is not conceivable that the SDK/AppStore/etc was created in under a year due to developer demand.

      We don't have "native apps that run in the browser". We have a Cocoa class called UIWebView which native apps can use to render html. There are all kinds of valid reasons for an app to do this. Sure, there are some apps that are *only* a UIWebView with static URLs, but they are the exception not the rule. And I'm pretty sure those are quick to be uninstalled. What we do have is the ability for a user to add a bookmark to their home screen, which basically creates an iOS app with an embedded UIWebView.

      There are theories that the API, and therefore "URLs on the home screen", don't use the improved Nitro JS engine because it uses JIT, and would be susceptible to script poisoning attacks, since the App author has full access to the processes memory space. There are theories that Apple is putting this JITing out-of-process, which would mitigate or obviate these attacks. This seems to be the reason that apps that use UIWebView get the older, slower JS engine.

      In any case, this has nothing to do with lockin, or profits for Apple. If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple. The only reason they have it is because customers want it, therefore it makes their hardware "more better".

      --

      There aint no pancake so thin it doesn't have two sides.

    2. Re:What do people want by bigNuns · · Score: 2, Interesting

      If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple.

      How does one go about doing this? Everything I have read has been speculation. As far as I can tell, no numbers have actually been released.

      --
      .................... ...mmm farm fresh...
    3. Re:What do people want by farnsworth · · Score: 3, Informative

      If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple.

      How does one go about doing this? Everything I have read has been speculation. As far as I can tell, no numbers have actually been released.

      http://tech.fortune.cnn.com/2010/06/23/app-store-1-of-apples-gross-profit/

      --

      There aint no pancake so thin it doesn't have two sides.

    4. Re:What do people want by bigNuns · · Score: 2

      Those are numbers based on a keynote speech and are full of assumptions. Pretty much each number comes with a "assumed" or "suggests." Anywhere you have seen real numbers and not ones made up based on somethine steve jobs said in a keynote? Not to be rude or anything but Steve Jobs has basically been caught on more than one occasion of, how should we say.... bending the truth.

      --
      .................... ...mmm farm fresh...
    5. Re:What do people want by farnsworth · · Score: 3, Informative

      Fair enough, but you can also read the transcript where Apple CFO Peter Oppenheimer tells shareholders pretty much the same exact thing. I guess he could be lying, but that would be a much more serious thing than telling tall tales at a press event.

      --

      There aint no pancake so thin it doesn't have two sides.

    6. Re:What do people want by UnknowingFool · · Score: 2, Insightful

      Every time I hear someone grouse about how no one really knows about how much Apple makes on the App or Music store, I ask them if they ever read the quarterly earnings or attend the financial conference calls. They never do but they still insist that Apple must be making gads of profit even though they've never looked at the public data that Apple provides and tried to figure it out for them selves.

      For instance for the fiscal year 2010, Apple reported $4.9B in revenue for the iTunes store. At most Apple took $1.5B in revenue for themselves after the artist/holder cut. Between January 2010 and February 2011, Apple sold over 4 billion songs. For arguments sake they only sold 3 billion for the fiscal year. That's 8.3 million songs a day. While not every song is a transaction, that's a lot of transactions. And that's just counting the music. There were probably thousands of movies a day. So for $1.5B a year, Apple had to pay for all the bandwidth, servers, credit card fees, etc and serve up 8 million songs a day and tens of thousands of movies. I would argue that Apple probably makes some profit but it isn't a lot.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    7. Re:What do people want by Anonymous Coward · · Score: 0

      In any case, this has nothing to do with lockin, or profits for Apple. If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple. The only reason they have it is because customers want it, therefore it makes their hardware "more better".

      What do the numbers say about the effectiveness of "there's an app for that" commercials? Anything? Apple may or may not be benefiting from a huge network effect, and I doubt they want to give up any advantage, regardless of how easy it is to measure.

    8. Re:What do people want by LodCrappo · · Score: 1

      "I would argue that Apple probably makes some profit but it isn't a lot."

      man.. i was totally with you right until this part. why would you argue that? its 5 BILLION dollars in revenue. Bandwidth and servers, in quantity, are very inexpensive.

      --
      -Lod
    9. Re:What do people want by UnknowingFool · · Score: 1

      Revenue != profit. Dell made $53 billion in revenue last year but they lost $1.4 billion overall. Would you argue: "But they made $53 billion in revenue! They must be swimming in money!"

      It appears that you didn't really read carefully anything I wrote above that sentence. The iTunes store revenue was $4.9 B. That's gross revenue and before they pay out any costs. Right off the top, $3.4B goes to the copyright holders. That's money they can't figure into any profit calculation. At most Apple keeps $1.5B which has to cover all their costs and profit margin. We don't know exactly how much media Apple serves up, but we know that they served up about 3 billion songs in that time periods and probably hundreds of milions of videos. Also added to that are costs for non revenue generating parts of the store like podcasts and iTunes university. These parts cost money to maintain but generate no revenue for the company.

      In songs alone, Apple had to maintain an infrastructure to sell and serve on average 8 million songs a day. That's more than just bandwidth and servers; that's the entire system including back-end payment processing and data centers. If you feel that you can do so for less than $1.5B a year and generate lots of profit, perhaps you should talk to Apple. They would probably be very interested in your services. Considering the cost of building a data center is in the billions of dollars per center, I doubt you'd make a lot of profit in the end.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    10. Re:What do people want by Anonymous Coward · · Score: 0

      You are aware that most major companies, manage to record a loss, right? This is so they don't have to pay taxes.

      What, you think that kind of widespread fraud stopped after Enron and Arthur Andersen? It's the order of the day.

      And BTW, Yes, I could serve eight million songs a day for less than 1.5 BILLION a year. Your cost figures are off by an order of magnitude.

      (and my captcha is "safari" .. does slashdot pull them from the page or something?)

    11. Re:What do people want by LodCrappo · · Score: 1

      It's easy to imagine things being very expensive when we start using millions and millions of something, hard for the brain to conceptualize it so we just assume it must be alot and don't usually go much further. But just for fun lets do a little guessing and some math...

      8 million songs per day = ~92 songs per second, lets call it 100

      100 songs, lets say 10MB per song (google says average size is much less, but why push it).. 1000 MB per second.. so we need a roughly 8000 Mbps connection (for now, lets assume the load is perfectly averaged over time, we'll deal with reality in just a bit). An OC-192 would do fine, at just under 10Gbps throughput.

      So what does an OC-192 cost? Well, it really depends on where you want to put it. Google doesn't want to tell me much more than somewhere between $10,000 and $100,000 per month. Let's take the worst pricing case.. so with a perfectly distributed load we might need to spend $1.2 million on bandwidth.

      Obviously, Apple is going to need burst capacity, and while this may actually be provided through some arrangement with the ISP, lets take the most expensive route and say that Apple has to actually pay full time for its peak potential capacity (which is silly, no one does this, but what the heck, we've got $1.5 billion coming in). Lets say they actually buy the equivalent of *100* OC-192s (now they can do an entire day's traffic every 15 minutes, sweet) , and somehow manage to pay full OC-192 price and at the worst possible rate.. so we're spending $120 million on bandwidth now.

      I am by no means good at math or knowledgeable about how bandwidth is priced or delivered at these capacities, but using the worst cases I can find with Google and grossly exaggerating every detail I still can't get the bandwidth costs to be even 10% of their 1.5 billion. In reality I doubt Apple is paying for dedicated lines at all, they probably work out deals with local ISPs and whatnot. I suspect you will find similar results with storage, staff, etc... they just don't amount to that much no matter how crazy you get with over estimating. I'm far too lazy to work it out even if we could get the details needed to actually price these things, but there is no way I'm going to believe that it costs 1.5 billion dollars per year to deliver iTunes unless I see a breakdown that proves it somehow.

      --
      -Lod
    12. Re:What do people want by UnknowingFool · · Score: 1

      Do you even read what I type? I said clearly above:

      "That's more than just bandwidth and servers; that's the entire system including backend-end payment processing and data centers."

      And the first thing you start doing is calculating bandwidth costs.

      My question to you which you have not answered is this: What will it cost you to build/maintain a system that is capable of selling and serving up 8 million songs a day? Remember the system probably should compose of multiple data centers for redundancy and performance. It has to handle multiple languages and currencies on the payment end. BTW every credit card transaction is at least 3% of the cost of the transaction. It has to start delivering media pretty much right after the transaction is made. So P2P technology like BitTorrent are not suited to this task. How many servers are required? How much diskspace is required? How much does it cost in electricity alone to run this system?

      Apple didn't build it all in a day, but I'm sure they had to expand their system as they sold more and more songs. Expanding capability isn't free. More servers, more diskspace, more electricity, more bandwidth. These costs add up. Again, if a single data center can cost a billion to build (and Apple has been building them recently just to keep up), how much profit can they really be making?

      PS. It appears I was wrong above: Apple went from 6B to 10B songs January 2009 to February 2010. Apple might be selling at least 3B songs this last year, but it could be higher or lower. I would guess higher by now.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    13. Re:What do people want by UnknowingFool · · Score: 1

      You are aware that most major companies, manage to record a loss, right? This is so they don't have to pay taxes.

      So you're saying that companies break the law and lie about how much they didn't make? And Apple reported a profit. So they lied less? Sure . . .

      And BTW, Yes, I could serve eight million songs a day for less than 1.5 BILLION a year. Your cost figures are off by an order of magnitude.

      Please you don't have the slightest idea of the infrastructure that's required. The only companies that might are Amazon and MS in that they sell music as well. MS, though, probably doesn't sell nearly as much as Amazon or Apple. In Amazon's financials, they don't specifiy how much profit they make on their music store. Nor do we know how much they sell or what the copyright holder cut is on the music.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    14. Re:What do people want by LodCrappo · · Score: 1

      My point is that when we use big numbers like millions and billions, it's difficult to have a sense of what a reasonable range for any calculation will be.
      I calculated bandwidth costs (poorly) merely as an example of this and because it's the only metric where we have any data (the number of songs to be delivered) and I personally have any idea at all of costs involved. When someone says they are selling that huge number of songs, my first reaction is to think "shit, the bandwidth to deliver 8 million songs a day, that must cost a fortune" yet when you do the math, it really isn't that expensive at all when we're talking about that kind of income.

      If you would read what I wrote, maybe you'd notice that I acknowledged there are other costs and explained that I simply cannot estimate them. To assume these costs are anywhere close to the 1.5 billion they are bringing in is foolish, and I provide bandwidth guesstimates only to illustrate this point.

      --
      -Lod
    15. Re:What do people want by UnknowingFool · · Score: 1

      The only metric you provided is bandwidth but my point is that bandwidth is not the majority of the costs. In my opinion, the construction of the data center and its operation is probably the biggest cost. The fact that Apple has been building them recently and they cost in the billions to build is probably a better indicator that Apple doesn't make a lot of profit in the end. Apple probably makes some profit, but they're not swimming in money because of iTunes store sales. Also due to the ever expanding sales, a lot of the profit is probably sunk into building more infrastructure just to keep up.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    16. Re:What do people want by zmollusc · · Score: 1

      Well, you have to store songs, perform transactions and serve songs.
      The bandwidth to do the serving appears less than $1.2 million, let's look at the storage.
              Wiki says iTunes store has: More than 14 million songs worldwide, 1,000,000+ podcasts (USA), 40,000+ music videos (USA), 3,000+ TV shows (USA), 20,000+ audiobooks (USA)2,500+ movies (USA), 300,000+ App Store Apps.

      Say 10Mb for a song, 80Mb for a podcast, 80Mb for a music video, 400Mb for a tv show, 200Mb for an audiobook, 1Gb for a movie and 50Mb for an app.
      I make that about 250 Tb, so a minimum of $12,500 on disks. Let's put those disks in some server hardware, allowing $1000 of ancillary kit per disk. We are now at $270,000 or so, so let's have some redundancy here. 100 mirrors should do, bringing the total to $27,000,000 . I will let someone else work out the electricity costs.

      Anyhoo, it is looking like $1.4 Billion to perform the financial transactions. Anybody know if this is reasonable at this scale?

      --
      They whose government reduces their essential liberties for temporary security, receive neither liberty nor security.
    17. Re:What do people want by UnknowingFool · · Score: 1

      I make that about 250 Tb, so a minimum of $12,500 on disks. Let's put those disks in some server hardware, allowing $1000 of ancillary kit per disk. We are now at $270,000 or so, so let's have some redundancy here. 100 mirrors should do, bringing the total to $27,000,000 . I will let someone else work out the electricity costs.

      I suppose the building to house all that equipment costs nothing? What about the A/C? The thing is building a data center isn't cheap. Google is probably the company with the most experience doing it. However their purpose is massively parallel processing not transaction and downloads. Even then they spend hundreds of millions on each data center. They must be foolishly wasting their money according to you.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
  12. Re:DUH. by YoshiDan · · Score: 0

    your mum's face be trippin

  13. Seems like a legitimate complaint by Anonymous Coward · · Score: 0

    I know we're supposed to be Apple haters but it seems like a legitimate argument. Why not test the iPhone browser on an actual iPhone? Lots of software perform differently in different environments.

  14. This is a joke. by geekmux · · Score: 1

    I find it laughable that companies are actually arguing over the browser performance on a device with a screen less than 4" in size. What's next, are we going to start testing surround-sound on cell phones too? Hell of a 1/4" subwoofer you got there...

    I guess I'm just the only guy who still uses one of those "old-fashioned" desktop monitors or an HDTV to drive my web experience. Apparently double-digit monitors are overrated.

    1. Re:This is a joke. by Midnight+Thunder · · Score: 1

      To some this is just a pissing contest, while others see it as the world changing domination by which their manly hood is challenged. For post people if the user experience meets or beats their expectations, then that is all that matters. I am with you that it really doesn't matter - well unless mine is the winner ;)

      --
      Jumpstart the tartan drive.
    2. Re:This is a joke. by bongey · · Score: 1

      It is old fashion trying to show has a bigger http://www.youtube.com/watch?v=GiWQZhUmmRw

    3. Re:This is a joke. by Anonymous Coward · · Score: 0

      Something tells me you haven't heard of the HTC Surround. Reminds me of when kids had speakers built into their backpacks...

    4. Re:This is a joke. by Anonymous Coward · · Score: 0

      I find it laughable that companies are actually arguing over the browser performance on a device with a screen less than 4" in size. What's next, are we going to start testing surround-sound on cell phones too? Hell of a 1/4" subwoofer you got there...

      I guess I'm just the only guy who still uses one of those "old-fashioned" desktop monitors or an HDTV to drive my web experience. Apparently double-digit monitors are overrated.

      I dunno, if anything, performance in this space is most important to me. If I want to look something up on my phone, I'm generally on the go and probably want to get it done in a hurry. I know I use my iPhone browser a hell of a lot more than I used my blackberry storm browser. It was sluggish. Didn't use it. Now I find it more than acceptable on my new phone (not a knock on BB, I hear the BB OS 6 browser performs well)

    5. Re:This is a joke. by znerk · · Score: 1

      I find it laughable that companies are actually arguing over the browser performance on a device with a screen less than 4" in size. What's next, are we going to start testing surround-sound on cell phones too? Hell of a 1/4" subwoofer you got there...

      I guess I'm just the only guy who still uses one of those "old-fashioned" desktop monitors or an HDTV to drive my web experience. Apparently double-digit monitors are overrated.

      I find it laughable that you don't have enough imagination to figure out why the "tiny screen" on the phone may or may not have anything to do with why people want a faster browser.

      I have a Motorola Atrix. I used to have an EVO. The Atrix has a dual-core 1Ghz processor, 1GB of RAM, 16GB of onboard storage, and the SD slot allows for another 32GB. This "phone" beats the pants off the machine I was using a few years ago to play GTA3 and Neverwinter Nights... and it fits in my pocket.

      Both phones have the ability to output via HDMI, and the Atrix actually does it in 1080p (and unlike the EVO, comes with the required cable). Looks great on my 37" LCD (sorry, not a home theatre buff, yet, so no 60" plasma). Note, this output is complete with audio, so there's a TV, a phone, and a single cable involved in watching 1080p video. No crazy rat's nest of cables, and I'm willing to bet that wireless can catch up to the required speeds fairly quickly.

      The Atrix has that awesome laptop dock that charges your phone while allowing you to use a normal-sized (for laptops) keyboard, and a decent sized screen. As a matter of fact, the only thing separating most modern smartphones from modern laptops is that one of them fits in your pocket, and the carriers' rules about just what the phones can do.

      The saddest part of all of this is that the carriers don't have any imagination, either, and are simply nickel-and-diming the market for every penny they could get, instead of sparking people's imaginations and starting the personal computing war all over again.

      --
      This work is licensed under a Creative Commons Attribution 3.0 Unported License.
  15. How do webapps even get on iphones these days? by Joe+Tie. · · Score: 1

    I haven't used an iphone for a while, so could someone bring me up to speed. If one goes to a webapp in safari that makes use of all the html5 goodies, he can just add it to the homescreen, right? Can it then launch like an application, not having the usual safari behavior of sliding around as a normal page amid other open webpages? Or does a developer essentially have to create a native app, an instance of webkit, and then wrap the html5/javascript within it to get an app written with html5/js onto the phone if he wants it to actually seem like an app instead of a webpage? Because if JIT is disabled in native apps using webkit, I can at least understand that. It's the app store, it's a big brother environment, that's common knowledge from the start. But if they're actually putting effort into slowing down performance of javascript within the context of normal OS functionality, that's something a lot more annoying.

    --
    Everything will be taken away from you.
    1. Re:How do webapps even get on iphones these days? by bongey · · Score: 1

      It can be saved to the home page, as this link shows the "Pie Guy" web app doesn't work anymore in 4.3 and full screen web apps don't get to use the new Nitro Engine.

  16. safari true condenender? by laktech · · Score: 1

    "They didn't actually test the Safari browser on the iPhone," Kerris argues. And, We hope Apple will help us enable those [browser] optimisations and repeat the measurement. Until then, for all we know the missing optimisations may not make a big impact." So, yeah, fix your shit and stop crying.

  17. Who the hell uses web apps? by RyuuzakiTetsuya · · Score: 1

    I'm just not convinced that there's a conspiracy here. I'm pretty sure Apple has the same view I'd have. I don't think that many people are using web apps in the first place and I'm not sure if there are any native apps that could use the performance boost that Nitro in this iteration of iOS, so once Safari was set up to use the new JS engine, they shipped it.

    --
    Non impediti ratione cogitationus.
    1. Re:Who the hell uses web apps? by dave024 · · Score: 1

      I still don't know what a web app is, and I use two iPhones and an iPad daily. I can't even come up with a decent site that explains it. Is it just a link on the home screen to a web page? I never knew so many people used them until these recent articles.

    2. Re:Who the hell uses web apps? by Anonymous Coward · · Score: 0

      Web apps are like AI. Once something qualifies as a web app or AI, it's thereafter called a website or non-AI.

    3. Re:Who the hell uses web apps? by bigNuns · · Score: 1

      I used to use the YouTube one... I no longer have an iPhone... but the YouTube web app was actually better than the built in YouTube app in my opinion. Also, as far as I know, WebApps aren't the only use of the embeded WebUI thingy... you use that in actual apps the get browser functionality. If you haven't noticed HTML in any of your apps you aren't looking very hard.

      --
      .................... ...mmm farm fresh...
    4. Re:Who the hell uses web apps? by RyuuzakiTetsuya · · Score: 1

      I could name a few iOS apps that use the HTML/JS rendering API available to native Apps, for example, ANY twitter client will open links in a browser. My bank's banking app is just a thin wrapper around their mobile page.

      I'm just not sure the previous generation of JS engines were all that slow, and while JS performance boosts are always welcome, I'm not sure if any app right now *needs* it.

      --
      Non impediti ratione cogitationus.
  18. That's not the problem. by pavon · · Score: 5, Informative

    The problem isn't with the intentional ARM code written by the applications. It is with code injected into the application (via an exploitable bug, like a buffer overflow) by malicious software. Setting noexec on data pages and nowrite on code pages is a security feature that prevents a large class of remote exploits, by ensuring that only the original code is executed.

    Compiling code on the fly should only be allowed on applications that have been carefully scrutinized for bugs, not every crappy app with an embedded web-browser. Even enabling it for Safari is risky, but is a lower attack surface than enabling it for any and all apps.

    1. Re:That's not the problem. by Anonymous Coward · · Score: 0

      Yeah, there's a good explanation why Safari can have a JIT for javascript, and your app with an embedded browser can't.

      Because, unlike an embedded browser that usually goes to a specific web page controlled by the app's developer, Safari will happily run javascript from every exploit-ridden page the user can think of.

      Oh, wait, that's the opposite of a good explanation.

    2. Re:That's not the problem. by omfgnosis · · Score: 1

      How on Earth is a web browser—designed to access anything and everything on the web—a lower attack surface than apps with a WebKit view? At the very worst, in the case of apps which are also web browsers, the attack surface is equal.

    3. Re:That's not the problem. by tepples · · Score: 1

      Then why can't UIWebView be set up to run in a separate process under the control of a "crappy app", in much the same way that Chrome runs?

    4. Re:That's not the problem. by pavon · · Score: 1

      It's not; a webbrowser is a pretty damn big attack surface. But Safari + other apps is a larger attack surface than Safari alone.

    5. Re:That's not the problem. by pavon · · Score: 1

      That would be a good architecture, provided the carefully audited the interface between UIWebView and the other applications. Who knows if Apple will ever bother to rearchitect it in that manner.

    6. Re:That's not the problem. by Anonymous Coward · · Score: 0

      Then why can't UIWebView be set up to run in a separate process under the control of a "crappy app", in much the same way that Chrome runs?

      Who says it takes absolutely no time to implement and QA that and won't be included in iOS 4.3.1? You? Google for Webkit2.

      Wanna blame Apple for not doing it that way from the start? Yeah, right, suddenly it isn't KHTML just stolen by Apple right?

  19. What's the issue here? by Anonymous Coward · · Score: 0

    I don't see what the problem is...

    after all when you buy apple kit you demonstrate to the world that you don't have the foggiest idea about computers and what makes them so great - you know, stuff like performance, freedom to tinker etc.

    And for supporting a company that is evil (by just about any definition) you get done right up the pooper. It's a well-deserved but rather thorough and rigorous violation. What's the problem here?

  20. FIRST POST!!!!! by flyingsquid · · Score: 1
    Wait... oh. $#!*. Never mind.

    Stupid iPhone...

  21. Sour grapes from Blaze.io by Bogtha · · Score: 4, Informative

    This, claims testing firm Blaze.io, is news to the world.

    No, it's not news to the world, it's news to Blaze.io. It was already widely reported that UIWebView didn't support the latest Safari speed boost days before their study was published.

    --
    Bogtha Bogtha Bogtha
  22. If you really want to know more, read this... by DavidinAla · · Score: 4, Informative

    John Gruber of Daring Fireball carefully lays out the situation in this post from a couple of days ago. I know that a lot of people like to make up all sorts of conspiracy theories and bizarre motives when it comes to Apple, but the truth is a lot more interesting and a lot less sinister: http://daringfireball.net/2011/03/nitro_ios_43

    1. Re:If you really want to know more, read this... by mSparks43 · · Score: 1

      I don't think anyone ever considered Apple charging a lot of money for a substandard piece of kit a "conspiracy theory". Branding is a well established and apparently acceptable method to con people.
      Personally I use a large advertising budget as a sign no-one would recommend it to a friend. Which I find an infinitely more useful purchasing tool.

    2. Re:If you really want to know more, read this... by Alistair+Hutton · · Score: 2, Insightful
      While Gruber may be right on this he is still the dick who concocted the widely quoted fantasy as to why cross compilers were definitely bad for iOs consumers and Jobs was so right to ban them give that Apple only do things that are good for the consumer blah, blah fucking blah.

      He was suspiciously silent when Apple un-banned cross compiled apps. Which is a shame. I was desperate to know why cross compilers were suddenly good for consumers in a way that didn't reference the EU investigation on the issue that was teed-up to start the following week.

      --
      Puzzle Daze is now my job
  23. Re:DUH. by Anonymous Coward · · Score: 0

    How do you know YoshiDan picked his nickname based on the Nintendo character? He may instead be paying homage to Naofumi Yamamoto.

  24. Wrong by SuperKendall · · Score: 1

    Because, unlike an embedded browser that usually goes to a specific web page controlled by the app's developer,

    The embedded browser will go to any other page too, following links. How many mobile developers are displaying pages with no links?

    Are you seriously saying a Twitter client should ship with the inability to go to any link but ones the twitter app developer has whitelisted. Madness.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Wrong by omfgnosis · · Score: 1

      The usual usage scenario will use a web view to load local html. A Twitter client would open links in a browser. Even putting that all aside though, the worst case scenario is still that the app is equally vulnerable to Safari.

  25. So Sloppy Programming... by Anonymous Coward · · Score: 0

    With Android taking the lead, I'm surprised that this "half-ass"ing by Apple gets any approval from their consumer base... but then again, they're consumer base is (to put it nicely) unique...

    To get to the point quickly (I do not own an iPhone, so...) Web Apps are basic bookmarks that you placed in launcher form on the Home Screen area. They happen to use UIWebView system instead of Mobile Safari. But they are nothing more than glorified web pages that you can "bookmark" to your Home Screen.

    So, if I may ask, Why didn't Apple have those Launchers launch Safari and navigate to said webpage? Maybe have Safari's UI change so users can't see the URL bar or what not. Although it might be comparing Apples to Oranges in speed tests, WHY didn't Apple just go about it the right way instead of that really nasty way that leaves them with egg on their face? I mean seriously, they could of coded it better, and backport it to the rest since I'm sure they've had this feature for a long while.

  26. Is it Chrome on Android? by MichaelSmith · · Score: 1

    This little script says that the user agent on my LG Optimus phone is Safari.

    --
    http://michaelsmith.id.au
    1. Re:Is it Chrome on Android? by Anonymous Coward · · Score: 0

      Not quite - the Android browser reports a Webkit ua string, that many scripts will describe as Safari. For a long time they were right, until Google started using Webkit too, the insensitive clods.

  27. Apple admitting it? by brillow · · Score: 1

    Are they admitting that javascript performance is not "enhanced" universally in iOS? Makes the issue about full-screen webapp performance seem pretty legit doesn't it?

  28. Re:Chrome is Fast Because It's Lightweight! by Anonymous Coward · · Score: 2, Insightful

    http://xkcd.com/322/

  29. Mobile Safari's caching and asynchronous loading by bonch · · Score: 0

    However, Apple is now stating that their embedded browser, called UIWebView, does not share the same optimisations MobileSafari does.

    UIWebView is just a WebKit view that third-party applications can embed; it's not a complete browser on its own. MobileSafari has custom caching mechanisms and asynchronous loading, which is what Apple is referring to. There's more to a browser application than just the engine.

  30. Re:DUH. by Falconhell · · Score: 1

    Pathetic Mike, is copy pasting the same trolls and changing the name.

    2 out of 10, need to do better!

  31. Re:DUH. by MichaelKristopeit407 · · Score: 0
    ur mum's face is copy pasting the same trolls and changing the name.

    why do you cower in my shadow behind a chosen aviary religion based pseudonym? what are you afraid of?

    you're completely pathetic.

  32. ffs by Anonymous Coward · · Score: 0

    can people stop jizzing themselves and spreading apple's shit everytime they release any little crumb of information
    this shit was already covered in the goddam original submission of:

    http://mobile.slashdot.org/story/11/03/17/1810253/Nexus-S-Beats-iPhone-4-In-Real-World-Web-Browsing-Tests

    which linked to the bloomberg article:

    http://www.bloomberg.com/news/2011-03-17/apple-iphone-loses-web-speed-test-to-google-s-android-blaze-software-says.html

    which in the second section of the damn article says:

    Seconds to Load

    Apple regards the tests as flawed because the browser that customers access by tapping on the Safari icon on their iPhones has performance enhancements not available when users access the Web through applications, said Natalie Kerris, a spokeswoman for the Cupertino, California-based company.

  33. Re:Mobile Safari's caching and asynchronous loadin by omfgnosis · · Score: 3, Informative

    No, there's more to it than that. UIWebView cannot compile arbitrary code, but Safari's JavaScriptCore (Nitro nee "Squirrelfish Extreme") does. http://arstechnica.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars

  34. What were those guys thinking? by satuon · · Score: 2

    I don't understand why they decided to compare the embedded browsers. "Ya, we'll go and compare Android and iPhone browser. But we won't compare the real browser, cause that would be too boring. Instead we'll compare the embedded browser, so if our assumption that it's the same turns out to be wrong, we'll become a laughing stock."

    Seriously if I were doing this test, it would have never even occured to me NOT to use the real browsers in the first place.

    1. Re:What were those guys thinking? by Anonymous Coward · · Score: 0

      I don't understand why they decided to compare the embedded browsers. "Ya, we'll go and compare Android and iPhone browser. But we won't compare the real browser, cause that would be too boring. Instead we'll compare the embedded browser, so if our assumption that it's the same turns out to be wrong, we'll become a laughing stock."

      Seriously if I were doing this test, it would have never even occured to me NOT to use the real browsers in the first place.

      What if the purpose is to use the embedded browsers? They are after all an app developer..

  35. Sensationalism and sloppy from the start by YoopDaDum · · Score: 2
    If you look at Blaze blog entry, you'll find this gem:

    On average, Android 2.3 was a 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone’s median load time of 3.254 seconds.

    If it were relevant (which is not the case as it's supposed to compare web browsers), then the iPhone would be 52% slower than Android. Which is equivalent to say that Android would be ~34% faster then the iPhone, not 52% faster (for this, Android would need to complete in less than half the time of the iPhone). I guess that it's not politically correct to use the negative version (iPhone is slower), but then it's hard to resist using the higher number right? ;)
    Interestingly, this has been reused by all news sites without anyone spotting the error. If Paulos makes a refresh of his "Innumeracy" book, I suggest this as an new example of how people lack fluency with basic computations.

    I have neither iPhone nor Android phone (although I offered an iPhone to my wife, and would be more likely to buy an Android phone for me), and I don't care much about such differences. So I would consider myself quite neutral to this discussion. But it feels like the Blaze announcement was sensationalistic and a bit sloppy from the start. Anyway, it certainly worked in getting publicity, and that's probably all they cared for.

  36. Re:Chrome is Fast Because It's Lightweight! by webmistressrachel · · Score: 2

    My last troll put paid to his "fat bitch troll". Look it up, there's pics and everything. But hey, he doesn't need to, I'm pretty damn sure he was there - the comment is almost verbatim!

    --
    This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
  37. If you believe this by kelemvor4 · · Score: 1

    If you believe this, then Steve has a bridge to sell you. Actually, rumor has it that the bridge will come free with your iDevice 5.0.

  38. Re:DUH. by YoshiDan · · Score: 1

    What? Who said this is a pseudonym cower some more feeb you are pathetic

  39. Re:DUH. by MichaelKristopeit407 · · Score: 0
    i am michael kristopeit.

    you are an ignorant hypocrite.

    cower in my shadow behind your chosen tame lizard based pseudonym some more, feeb.

    you're completely pathetic.

  40. Re:DUH. by YoshiDan · · Score: 1

    your mum's face are a tame lizard based pseudonym

  41. Re:DUH. by MichaelKristopeit407 · · Score: 0
    you're an ignorant hypocrite.

    cower in my shadow using last resort mimicry behind your chosen pseudonym some more, feeb.

    you're completely pathetic.

  42. Re:DUH. by YoshiDan · · Score: 1

    Pseudonym? YoshiDan is my actual name.

  43. Re:DUH. by MichaelKristopeit424 · · Score: 0
    you're an ignorant hypocrite.

    cower some more, feeb.

    you're completely pathetic.