Archive for July 24, 2013

Wednesday, July 24, 2013

Developer Center Downtime


Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed. In the spirit of transparency, we want to inform you of the issue. We took the site down immediately on Thursday and have been working around the clock since then.

Nick Arnott interviews Ibrahim Balic:

With altered web requests, Balic found that by only providing a single piece of user information, first name, last name, etc., he was able to get Apple’s servers to return additional information for a matched user account — specifically full name, username and email address.


So if the bug was in iAd, why does Balic believe he might be responsible for the developer portal outage? Of the 13 bugs that Balic filed with Apple, one of them was a XSS (cross-site scripting) vulnerability in the developer site that could have led to accounts being compromised. In fact, of the 13 total bugs, 12 of them were XSS vulnerabilities in various Apple services that had the potential to expose user details.

Update (2013-07-24): They’ve added a system status page.

Update (2013-07-28): Sites are reporting that the ADC Web site is back up, although the status page shows that Xcode Automatic Configuration (presumably necessary to install the command-line tools), Pre-Release Documentation, Videos, Member Center, App Store Resource Center, Program Enrollment and Renewals, Apple Developer Forums, and Technical Support are all still down.

Update (2013-08-10): All the services are back online.

Update (2013-08-21): Juli Clover (via John Gruber):

Apple has released new details (via @cabel) on the security flaw that caused the Developer Center to be down for more than a week, noting via its Apple Web Server notifications page that a “remote code execution issue” was fixed.


While security researcher Ibrahim Balic speculated that he might have been behind the security breach, it is now clear that the issue he reported was unrelated to the major flaw that caused the downtime.


ParcelKit (via Clark Goble):

ParcelKit integrates Core Data with Dropbox using the Dropbox Datastore API.

Interesting idea, although it seems like for most data models you would need to layer on top your own conflict resolution (as with iCloud).

Beware of Sync Platforms

KS Sreeram:

Any sync-platform that claims to perform automatic conflict resolution is broken. This is because conflict resolution is fundamentally a domain specific problem that cannot be magically solved by a generic platform.


In essence, the notion of a conflict depends on the meaning that we assign to the data. Dropbox knows nothing about the meaning. It only knows the shape of the data. And that’s not enough to resolve conflicts.

JavaScript Object Notation (JSON) Patch

RFC 6902 (via Mattt Thompson):

JSON Patch is a format (identified by the media type “application/json-patch+json”) for expressing a sequence of operations to apply to a target JSON document; it is suitable for use with the HTTP PATCH method.

This format is also potentially useful in other cases in which it is necessary to make partial updates to a JSON document or to a data structure that has similar constraints (i.e., they can be serialized as an object or an array using the JSON grammar).

Patches are atomic; if any operation is not successful or one of the “test” assertions is violated, the patch doesn’t make any changes.

API Smell: NSNumber

Christopher Bowns:

NSNumber’s weakness lies in the ambiguous type of its value. If you receive NSNumber *aNumber as a method parameter and want to know its scalar value, what type should it be evaluated as? Is it correct to treat it as a YES/NO, and send it [aNumber boolValue]? Or perhaps it’s a floating-point value and should be sent [aNumber floatValue]? Without introspecting the Objective-C type encoding of an NSNumber, a glance at its value doesn’t hint at the original value. Consider an NSNumber whose integerValue is 1. Is it a signed or unsigned integer? Is it a boolean? Or is it a float that happens to be 1.0?

He recommends:

An objective evaluation of one’s use of NSNumber makes for clearer and more future-proof code. NSNumber should be used only as a temporary representation of a numeric value. If an instance of NSNumber has numeric meaning, it should be converted to a scalar value; otherwise, it should be converted to an NSString.

Also, if you have an API that uses NSNumber, you should document its type. This is not good:

NSString * const NSURLFileSizeKey; // Total file size in bytes (Read-only, value type NSNumber)

I would have assumed that a file size is an unsigned long long, but this Apple sample code treats it as a 32-bit signed integer.

Improving the Security of Your SSH Private Key Files

Martin Kleppmann (via Mark Jason Dominus):

I don’t know why ssh-keygen still generates keys in SSH’s traditional format, even though a better format has been available for years. Compatibility with servers is not a concern, because the private key never leaves your machine. Fortunately it’s easy enough to convert to PKCS#8:

$ mv test_rsa_key test_rsa_key.old
$ openssl pkcs8 -topk8 -v2 des3 \
    -in test_rsa_key.old -passin 'pass:super secret passphrase' \
    -out test_rsa_key -passout 'pass:super secret passphrase'

If you try using this new PKCS#8 file with a SSH client, you should find that it works exactly the same as the file generated by ssh-keygen.

Victory Lap for Ask Patents

Joel Spolsky:

The America Invents Act changed the law to allow the public to submit examples of prior art while a patent application is being examined. And that’s why the USPTO asked us to set up Ask Patents, a Stack Exchange site where software developers like you can submit examples of prior art to stop crappy software patents even before they’re issued.


Micah showed me a document from the USPTO confirming that they had rejected the patent application, and the rejection relied very heavily on the document I found. This was, in fact, the first “confirmed kill” of Ask Patents, and it was really surprisingly easy. I didn’t have to do the hard work of studying everything in the patent application and carefully proving that it was all prior art: the examiner did that for me.


My dream is that when big companies hear about how friggin’ easy it is to block a patent application, they’ll use Ask Patents to start messing with their competitors. How cool would it be if Apple, Samsung, Oracle and Google got into a Mexican Standoff on Ask Patents? If each of those companies had three or four engineers dedicating a few hours every day to picking off their competitors’ applications, the number of granted patents to those companies would grind to a halt.