Archive for July 14, 2015

Tuesday, July 14, 2015

WebKit Hacking From the Bleeding Edge

Daniel Jalkut:

As an open source project, I initially believed I could build and run WebKit wherever I choose. After all, isn’t that what “open source” is supposed to be all about? But ah, there’s a catch. At least when it comes to building and running WebKit on OS X releases, there is a dependency on a small, binary-only static library which provides key system-specific linkages to WebKit. Usually this binary is added to the open source project around the time the system release goes public, but not much sooner.

The long and short of it? If you want to build WebKit and you don’t work at Apple, you need to do so from publicly released versions of OS X.

Python 3.5: async and await

What’s New in Python 3.5 (via Hacker News):

[PEP 492] added dedicated syntax for declaring coroutines, await expressions, new asynchronous async for and async with statements.

Third Hacking Team Flash Zero-Day Found

Brian Krebs:

For the third time in a week, researchers have discovered a zero-day vulnerability in Adobe’s Flash Player browser plugin. Like the previous two discoveries, this one came to light only after hackers dumped online huge troves of documents stolen from Hacking Team — an Italian security firm that sells software exploits to governments around the world.

News of the latest Flash flaw comes from Trend Micro, which said it reported the bug (CVE-2015-5123) to Adobe’s Security Team. Adobe confirmed that it is working on a patch for the two outstanding zero-day vulnerabilities exposed in the Hacking Team breach.

We are likely to continue to see additional Flash zero day bugs surface as a result of this breach. Instead of waiting for Adobe to fix yet another flaw in Flash, please consider removing or at least hobbling this program.

James Vincent (via John Gruber):

Alex Stamos, the recently appointed chief security officer at Facebook, has called on software company Adobe to announce an “end-of-life date for Flash.” In a pair of tweets sent over the weekend, Stamos echoed a number of recent complaints from the security community that the software has become the vector for just too many hacking vulnerabilities.

AppleEventBridge: Native AppleScripting Support for Swift

Hamish Sanderson:

In light of OS X 10.11 addressing some longstanding deficiencies in NSAppleEventDescriptor, I’ve been dusting off a fork of my old objc-appscript project, now renamed AppleEventBridge, modernizing and extending it both to take advantage of improvements to ObjC in the last few years and to add native support for Apple’s new Swift language:

https://bitbucket.org/hhas/appleeventbridge/

Unlike Apple’s flawed Scripting Bridge and JavaScript for Automation, AEB aims to provide application scripting capabilities and compatibility that equal (if not better) AppleScript’s own, along with superior documentation and developer tool support.

92% of Smartphone Profits

John Gruber:

At just 20 percent of unit sales, Apple isn’t even close to a monopoly. At 92 percent profit share, they have a market dominance that rivals any actual monopoly the tech industry has ever seen. We don’t even have a term for this situation, it’s so unusual.

Graham Lee:

That 92% profit on 20% sales is indicative, rather than contraindicative, of a monopoly. And there’s another word we could use, too: monopsony. Let’s say that you’ve made an iOS app, and now you want to sell it. Do you create a storefront on your website to do that? Do you contact Sears and see how many boxes they want? Speak to some third-party distributor? No, you can only sell to Apple, they are the only buyer for iOS apps.

[…]

I would imagine that a legal system that did explore this question would consider analogous environments, like the software market of the 1990s. Back then, Microsoft bundled a web browser and a media player with their operating systems and used their market power (which let them act as a monopoly even though competitors existed) as an operating system vendor to make it hard to sell competing browsers or media players. It might be an interesting thought experiment to compare that situation with today’s.

On Negative App Store Reviews During Betas of iOS and OS X

Federico Viticci:

I don’t know what the solution is, but I’ve been observing this problem for six years now, and I’d like to offer a list of suggestions and ideas that will hopefully act as reminders for the future.

[…]

We all have to keep in mind, though, that developers get the short end of the stick here. When it comes to App Store reviews that point out issues on betas of iOS and OS X, there is nothing they can do. They can’t respond to them, they can’t release compatibility and feature updates for public betas, and yet they’re left dealing with the outcome of negative reviews. These are smart folks, and they know that their apps have issues on beta versions of iOS and OS X. Not only it’s not useful to leave negative reviews for those problems now – it’s not fair to developers.