Silly Apple Criticism 2: Apple Has iAds, So Safari’s Reader Function is Hypocritical Ad Blocking

Critique: It’s hypocrtical of Apple to introduce their own ads while putting an ad blocker in Safari 5.

Safari Reader is not an ad blocker. To call it that is to misunderstand “reader” formatters, or ad blockers, or both.

An ad blocker blocks ads. Not trying to be facetious, but that’s what it does. It blocks ads. They’re blocked. You go to a web page, and you do not see ads. Ads are prevented (you might say, “blocked”) from displaying. When you browse with an ad blocker, you go from page to page sans ads. Are we clear?

A reader formatter doesn’t do that. You don’t browse with these. When you go to a page you see the same ads as everyone else. The ad impression is counted (for the content provider) and you’re free to click on any ad to view at will.

What a reader does do is determine if there’s an article on the page, and give you the option to display it more cleanly for easier reading. Yes, the ads (along with other formatiing) do not appear in the reading pane, but they’re still in the background with the rest of the web page, and when you exit the reader in any way—which you have to do to get anywhere else—they’re displayed again.

That’s a big difference. In fact, a reader cannot block ads; the page must load before it can even be invoked in the first place. No one accuses Readability, for example, of being an ad blocker. In fact, someone looking for an ad blocker would be extremely disappointed in the results if they tried to use one of these readers for that purpose.

Google’s Chrome Web Store: “Open” or “Closed”?

Google is reminding us all that “apps” can and should run on the open web, and not just in closed, vertically integrated and controlled environments like the iPhone/Pad/Touch.

Is that what they’re reminding us of? Since Apple’s devices have a compliant web browser in Safari we’ll find out soon enough.

If the Chrome Web Store is truly about supplying apps that “should run on the open web” you’ll be able to use it on an “iPhone/Pad/Touch”. If not, then Google has just created a “closed, vertically integrated and controlled” environment of their own. If the latter, I wonder if the “open” zealots will call them on it.

In-depth analysis of Google’s VP8. One worry is patent infringement.

Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age.  Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. Until we get some hard evidence that VP8 is safe, I would be extremely cautious.  Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem.

Emphasis in the original. The article is a geek read if ever there was one, but an interesting read nonetheless.

Should Opera Mini be approved for the iPhone?

Apple gets dinged for not delivering the full Internet by excluding Flash, and yet I bet the very same Apple anti-fans won’t say a word about Opera not even trying.

Great article detailing why Opera Mini should not be approved for the App Store. It’s a good read, based on numerous technical/privacy/compliance factors, not just one or two philosophical points.

I also suggest you read this great post in the comments section.

Whether you agree with the various points made (I do), or whether those points should be reason for Apple to reject the app (I’m less convinced about that), it’s an important discussion.

The bottom line is that Opera Mini — Opera PR notwithstanding — is not a web browser in the sense we normally use the term. It does not render pages, but rather runs them through a proxy that involves many important “side effects”. A little education about that for a mass market (i.e. not geek-driven) device like the iPhone is a good idea.

iPhone 3GS JavaScript Speed is NOT Faster Than Apple Claimed

Lots of stories making the rounds that the JavaScript speed of the new iPhone 3GS is even faster than Apple had claimed. Most of the stories originate from this one from Medialets, but it’s simply not true the performance is faster than Apple claimed.

JavaScript speed is very impressive. However, if you compare Medialets’ results with those Apple presented during the WWDC keynote, you’ll see they’re essentially the same. Let’s take a look:

sunspider-benchmarking-tests-2009-06-22

Apple_WWDC_JavaScript_Benchmarks

I’d say Medialets’ findings of 133/49/17 for the iPhone 3G-os2/3G-os3/3GS match up very well with Apple’s reported results of 126/43/15. Apple’s numbers are a bit better, but not excessively so. It’s clear that all Medialets has done is confirm Apple’s stated speed claims in this area.

This is a huge speed improvment, and I’m not trying to diminish it, but Apple’s claim of “twice as fast” was a generic one regarding the 3GS in general, whereas their JavaScript claims were very specific. Medialets has shown they were accurate, not underrated.