Archive for August 16, 2015

Sunday, August 16, 2015

Xcode Build Setting Transformations

Matt Stevens:

Xcode supports the ability to substitute the value of build settings using the $(BUILD_SETTING_NAME) or ${BUILD_SETTING_NAME} syntax in a number of places including Info.plists, other build setting values, and .xcconfig files. In these substitutions it’s also possible to add operators that transform the value in various ways.

[…]

These transformations can be quite useful but don’t appear to be documented, so here’s the list of available operators and what they do[…]

How Your Phone’s Battery Life Can Be Used to Invade Your Privacy

Alex Hern:

The battery status API is currently supported in the Firefox, Opera and Chrome browsers, and was introduced by the World Wide Web Consortium (W3C, the organisation that oversees the development of the web’s standards) in 2012, with the aim of helping websites conserve users’ energy. Ideally, a website or web-app can notice when the visitor has little battery power left, and switch to a low-power mode by disabling extraneous features to eke out the most usage.

[…]

The researchers point out that the information a website receives is surprisingly specific, containing the estimated time in seconds that the battery will take to fully discharge, as well the remaining battery capacity expressed as a percentage. Those two numbers, taken together, can be in any one of around 14 million combinations, meaning that they operate as a potential ID number. What’s more, those values only update around every 30 seconds, however, meaning that for half a minute, the battery status API can be used to identify users across websites.

Update (2016-11-05): Catalin Cimpanu (via Hacker News):

In an unexpected move, Mozilla has announced last week it was removing support for the Battery Status API, a feature that allows websites to detect the status of the user’s battery level, and use this information to save critical website data to disk before the device shuts down.

Unfortunately, web developers haven’t used the API as Mozilla had hoped. In fact, the most ardent users of the API are advertisers, who used it to track users across websites based on their battery levels and unique device identifiers.

Update (2016-11-07): Lukasz Olejnik:

It’s also interesting to note that Apple is considering to remove support for Battery Status API from WebKit’s (the engine powering Safari browser) source code. Although so far Apple has not enabled Battery Status API, it is implemented in Safari’s engine. At this point, I don’t believe Apple will ever ship this feature.

Update (2016-11-08): Bruce Schneier:

W3C is updating the spec. Here's a battery tracker found in the wild.

Apple Pay to the Rescue

Craig Hockenberry:

At that point, I figured I was just in a lull between the main account closing and the changes propagating to the Apple Pay device account. I had only made the transaction about five minutes after the card was cancelled, after all. Either way, the payment hadn’t been declined and I had my beer.

[…]

The next morning, however, while going through my email, I saw an automated message from Citicard AAdvantage that explained what had happened the previous evening.

I don’t need to do anything further! For any consumer who’s experienced card fraud, this is a huge benefit to Apple Pay.

Fearing an Apple TV Service

Tim Schmitz:

A TV service from Apple is likely to work a lot like Hulu. It might have a greater variety of content or a better UI, but the commercials will be there to stay. Why is it filling me with fear if it’s so similar to existing streaming services? Because an Apple TV service is likely to be far more successful and widely used than Hulu. It’ll turn a niche product into a widespread one, and the ad model will come along for the ride. Once everyone is used to un-skippable ads, they’ll be awfully hard to get rid of. We’ll be back where we started 20 years ago: watching the same ads for Chevrolet pickup trucks for 18 minutes out of every hour. (Oh, and those 18 minutes? That’s 30% of an hour, which just happens to be the same percentage that Apple takes as a cut from sales on the App Store. Certainly a coincidence, but an eerie one.)

How Many Old Apple Devices Can’t Get Security Updates?

Glenn Fleishman:

Google’s statistics about Android devices checking into its Google Play Store show that only about 18 percent are running a version of Android 5; the majority run a 4.x release. When the Stagefright exploit was revealed more than two weeks ago, the estimate was that even though the exploit had been disclosed to Google and patched in its internal code base, over 95 percent of phones were vulnerable to a simple MMS-based attack. Carriers have worked at the network level and with MMS settings they can change remotely to reduce the risk. But from 20 to 50 percent of Android phones will never receive a patch.

[…]

Somewhere from 10 to 20 percent of devices are running iOS 7 or an earlier version. (MixPanel pegs it at 10 percent, while David Smith’s tracking of usage related to his Audiobooks app puts it around 20.) Over a billion iOS devices have been sold since the first iPhone, but it’s impossible to know how many remain in use unless Apple were to provide figures.

[…]

So 70 to 140 million users of systems that predate iOS 8 (and most iOS 8 users have upgraded to 8.4) seems like a large audience to exploit, even though a significant portion are using older devices.

[…]

Apple’s choices do leave a significant number of users of older versions of iOS at risk, but simultaneously make them slim pickings compared to other options.