PBG Blog

There's some confusion around Tim Cook's February 16th letter to customers. Here are the salient parts:

We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.

Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.

The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor. And while the government may argue that its use would be limited to this case, there is no way to guarantee such control.

And:

In today’s digital world, the “key” to an encrypted system is a piece of information that unlocks the data, and it is only as secure as the protections around it. Once the information is known, or a way to bypass the code is revealed, the encryption can be defeated by anyone with that knowledge.

The government suggests this tool could only be used once, on one phone. But that’s simply not true. Once created, the technique could be used over and over again, on any number of devices. In the physical world, it would be the equivalent of a master key, capable of opening hundreds of millions of locks — from restaurants and banks to stores and homes. No reasonable person would find that acceptable.

This has caused some amount of controvery and misunderstanding. As soon as the letter was posted, at least one astute developer noticed that Tim's chief complaint, that a backdoor created to access the San Bernardino phone could be reused to access other phones, was factually incorrect.

Even before the letter, Dan Guido explained how it is technically feasible for Apple to comply with the FBI request without jeopardizing the security of all iOS users. The short version is this: Apple can create a version of iOS which can be brute-forced, authorize it for installation on a only single device, and install it just there, giving the FBI exactly what they want.

But, Tim says they can't.

So – Is Tim lying? Can they or can't they create a backdoor to access just a single device? Well, it's more nuanced than that.

I believe that Apple's view of what consititutes a backdoor is different the FBI's. The FBI's request is strictly technical, but when Tim speaks of backdoors, he's speaking of the process of a government requiring Apple to create an insecure OS and authorize it for installation on a single device, and not the technical method in which that OS's security is compromised. When you view things through this lens, the letter is entirely truthful.

If that process were established – one that requires Apple to create and authorize new, insecure versions of iOS, it would set a precedent which compromises the security of all users, which is true to Tim's word.

"But that's not what Tim said!"

It's confusing, especially for technical people who understand iOS well, because Tim's letter uses technical languages and speaks obliquely about modern cryptography, to where a backdoor to one encrypted message would indeed mean a backdoor to all encrypted messages. Specifically, here:

In today’s digital world, the “key” to an encrypted system is a piece of information that unlocks the data, and it is only as secure as the protections around it. Once the information is known, or a way to bypass the code is revealed, the encryption can be defeated by anyone with that knowledge.

The government suggests this tool could only be used once, on one phone. But that’s simply not true. Once created, the technique could be used over and over again, on any number of devices.

"This tool" is not an intentionally insecure version of iOS. It is the process of creating such a tool.

"But Apple has done this for law enforcement agencies before!"

Yes, there are documented cases of Apple bypassing security on pre-iOS 8 devices to assist law enforcement agencies. The difference is that on pre-iOS 8 devices, not all user data was encrypted by default. Apple already had the existing tools to extract it. The creation of a custom, insecure OS to be installed on the device was not necessary.1

"But what about the Secure Enclave / Secure Element, and the fact that this is an iPhone 5c without those features?"

None of that really matters, because while Apple maintains the ability to modify the OS on a locked phone2, it's possible for them to to change it in a way which compromises user data. Apple has chosen to draw a line in the sand here, at "we will not craft a malicious or knowningly insecure OS," because they believe that is what constitutes a backdoor.

For that, they deserve a standing ovation.

For more info, see the EFF comments here, The Daily Dot's coverage here, and Motherboard's coverage here ↩︎

I guess I could say my dad was a geek, but that’s not exactly true. When people think of geeky dads, they think of Gordon Clark from Halt and Catch Fire, or maybe Rick Moranis in Honey I Shrunk the Kids, but my dad was nothing like that.

My dad was a businessman, through and through. A friendly, suit and tie kind of guy, one who would take his clients to dinner and invite them to Blue Jays games.

The geeky part of my dad was that he just loved tech. He credited the Macintosh he bought with transforming the way his office did business, and was always keen on getting the latest versions of whatever OS and software he was using at the time. The guy was an excel wizard. Even today, fully equipped with a CS degree, I still don’t understand some of stuff he was pulling in his .xls files.

I clearly picked up his passion for technology and became his go-to guy for websites and technical advice. After first introducing him to Dropbox, I’d hear a yell from another room: “I put the files in the hotbox, did you get them??” Classic dad.

He took me to New York City when I was only 15 so we could attend MacWorld, where we woke up at 5 AM to line up outside the Javits Center, and later watched Steve Jobs announce the Power Mac G4 Cube. He’d eventually buy me another G4 that I’d learn to program on, starting my career as a software developer. (I’ve since grown up to realize how incredibly privileged I was to have had both the ability and the support to pursue a career in tech.)

He was so excited and so proud when I told him Apple gave me a job offer and I’d be moving to California to work there full time. While I figured he was sad to not have me nearby anymore, I knew he was more excited that his son would be taking part in what he viewed as a technological (and business) revolution, being on the forefront of the latest and greatest tech-y things. He was also probably pretty pumped to get that family discount.

Over the years he bought every iPhone and iPad that launched, even if he didn’t need it. He had more apps installed than anyone I knew. And he got such a kick out of all of it. I remember now when he would visit me in San Francisco, we’d be touring Apple or some other start up, and he’d get kinda quiet. At the time I worried he was mad or bored or something else, but I realize now he was probably just taking it all in. Savoring the moment in a quiet, private way that I’ve come to see other dads do.

My dad died last June at age 64. Kidney cancer, no symptoms until it was already way too late. Really shitty stuff.

In the time between then and now I’ve dealt with it pretty privately. It’s super sad to lose a parent, especially in such a quick and expected way, and I don’t like to bring others down. I think about him a lot, naturally, but the surprising thing, though perhaps it shouldn’t be, is how much I think about him around tech events.

It’s easy to forget just how relentless the tech industry is. Since he passed, Apple announced and shipped a watch, two iterations of the iPhone, and even showed off a big-ass iPad. At each one of these events, the thing I couldn’t get out of my head, and still drives me to tears, is the thought “Ugh. Dad would have loved this.”

This weekend I got to visit and help (a tiny bit) with my wife’s new office expansion and move at Square. It’s without a doubt the most beautiful workspace I’ve ever visited. And it’s also probably the most technologically advanced, not only in tools but in scale. iPads with beautifully designed custom software handling all the meeting room coordination, ubiquitous video conferencing, robots wheeling around with human faces on the eye-level screens – telepresence, man. And again, it hit me: dad would have loved this.

It’s bittersweet to say the least, but this pang has come to serve as helpful reminder.

Tech has a lot of problems: toxic work cultures, lack of diversity, unreliable software, privacy issues, to name a few. It’s easy to become jaded to the fact that we’re living in a future that is greater than most of our ancestors could have imagined. That’s not to say things couldn’t be better, or that we shouldn’t be trying harder on so many fronts. Despite these shortcomings, it’s critical, perhaps necessary, that we take moments to recognize how far we’ve come, and how truly magical our world is, and how important it is to keep working for positive change. Billions of people, my dad included, have lived and died before they were able to see the most magical things, which to us are always around the next corner.

My dad had a lot of skills, and one – that I’m apparently still learning – was to recognize the power and significance of the newness of things, as they keep happening to us, at us, over and over again.

Since Swift’s introduction at last year’s WWDC, iOS and OS X developers have debated over the answer to a common question for platform newcomers: “Which language should I learn, Objective-C or Swift?” Until recently, there was no definitive answer.

The nuanced truth was that both choices offered benefits and drawbacks. Objective-C was and remains fast, stable, has great IDE support and years of community Q&A available online, all of which can make picking up the language relatively easy for newcomers if they already have experience in C and/or other object-oriented languages.

Swift, being new and unworldly, had none of these advantages. It would almost certainly (and did) undergo fairly major changes – Apple even explicitly stated that they wouldn’t maintain syntax compatibility between language revisions, meaning extra work would need to be (and has been) done by early adopters to stay current with the language changes. Most of the high-level iOS and OS X frameworks are written in Objective-C, and using them in Swift through the language bridge was awkward at best. Worse was that Xcode didn’t even support Swift very well: compiler crashes and undecipherable error messages were very common.

On the other hand, Swift was and is clearly the future, so learning it early can put a developer ahead and help them stand out. The language itself truly can eliminate entire classes of common programming errors, and its consistent and modern design provides significantly better developer ergonomics than a 30-plus year old superset of C. (I’ve been writing Objective-C since college and I still need to look up the correct block definition syntax, every time.)

I believe the answer to the “Swift-or-Objective-C” question changes this month, with the release of Swift 2.0. The Swift development team — in fact, all of Apple’s software engineering teams — have moved tremendously fast to give the next iteration of the Swift greatly improved language, framework, and IDE support. Combined with a rapid adoption by the community, Swift has a nearly tangible feeling of momentum. It’s now mature enough to have tackled most of the drawbacks listed above, and so the answer is now a resounding “Swift”.

There’s an important corollary to the above: Because of Swift’s great progress, almost no one coming into the iOS or OS X development world will choose to learn Objective-C – first or perhaps ever. That is to say, we’ve reached Peak Objective-C.

Existing Objective-C usage outside the Apple ecosystem is obscure at best, and with Swift taking it’s place, the only reason to know it is to work on existing Objective-C code bases. With no new developers choosing to learn it except by necessity, the language will begin it’s slow descent into “legacy” status. In fact, there’s good reason to believe this has already started: The TIOBE index shows a fairly precipitous drop after Swift’s introduction in June 2014, from which one might conclude that “Peak Objective-C” may have happened last year. Indeed, Objective-C is scheduled to fall out of the TIOBE’s top 20 index before the end of the year, and other sources show similar trends.1

Of course, Objective-C isn’t going away in the near future. Apple and the Swift team have made this clear in their communication with developers. But Swift offers material benefits over Objective-C and — now — little to no reason to avoid. There’s no telling when Apple will introduce the first Swift-native (and Swift-only) framework, perhaps one that eschews the object-oriented nature of Cocoa in favor of one more protocol-oriented.2 Although this probably won’t happen until at least June 2016, it’s worth thinking about now. To be unable to use such a new framework would be a serious competitive disadvantage.

Luckily, Apple has made it easy for developers to adopt and integrate Swift into existing projects: Objective-C generics and nullability specifiers go a long way in improving compatibility between the languages. Perhaps ironically, Objective-C is being improved by Swift, but developers still need to choose to use it.

Existing OS X and iOS developers and project managers need take note of this major change. The longer they put off adopting Swift, the harder it will be for them find and hire or collaborate with other developers who have learned, are still writing, and still want to write Objective-C projects. While this shift won’t happen overnight, I think we will be surprised with how quickly we find ourselves looking back at Objective-C with (perhaps more than) a tinge of distaste.

I don’t mean to imply that TIOBE be considered the authority on programming language popularity, but it seems fairly accurate. Github and StackOverflow watcher RedMonk puts Objective-C at the 10th most popular language, though Swift is already in 18th place. (Objective-C peaked at #9 last year.) StackOverflow’s own developer survey shows Swift as the “Most Loved” language of 2015, and shows Objective-C dropping from 11.9% popularity in 2014 to 7.8% in 2015 – this loss is mostly attributed to AngularJS and Node.js however, as Swift does not yet rank in the most popular there. ↩︎

I've only had my Apple Watch for about a week, and so much has been written about it already that there isn't too much I have to add, but I can't resist adding my few, late, impressions:

It's the first mainstream Apple product in a long time that has a very specific market. Computers and smartphones are used by pretty much everyone, but the watch appeals only to a select few: wealthy1, health-, and fashion-conscious people. There's nothing wrong with that – it's a great product for those people – but it does signal a pretty radical departure from Apple's former product ethos.2

The health apps are very good. I'm standing more, walking more, trying to meet the goals I've set. This is one of the greatest features of the watch.

The rest of the software is not very good. Some of it is downright bad. My weather app usually doesn't launch, it just spins forever.

It's not yet much of a platform for 3rd party apps. Most of the apps are slow to load and buggy. This will likely change with newer versions and a real SDK, but it's sad that this is the quality of software we've come to expect with any 1.0 release.

The side button seems like a mistake. Aside from using it to summon Apple Pay, accessing a quick list of friends isn't a thing I want to do on my wrist. If I need to contact someone, I will text, email, or tweet at them: all things I'll do from my phone.

Notifications are great. Being able to feel a tap, lift my arm, see the message, and put my arm down feels very freeing and futuristic. My only complaint is that the tapping force seems incosistent and sometimes much too soft. Despite having it set on the strongest setting, I still occasionally miss things.

Watch face customization is fun and makes the device feel so much more personal. I want many more faces, and whole face SDK. I haven't met 2 people with the same face customization options yet.

Yay, button shapes!

The buying/shipping process is bananas. When I bought mine, the quoted delivery time was 3-4 weeks, but it shipped the following day. Many others who bought different models during the inital launch window have only just started to see their orders ship.3 Apple is usually lauded for their logistics and operations accumen, but here they've failed to provide anyone with reasonable delivery estimates.

It's bizarre that some combinations of watches and bands (like a 38mm Watch with Leather Loop strap) don't exist.

There's nothing really that special about the Apple Watch, other than that it's a very good piece of wearable technology. Should you buy one? If you wear a Fitbit or a regular watch, and you don't mind dropping $350-$1000 on a gadget/fashion accessory, then yes – you'll probably really like it. Is it worthy of the insane amount of hype being claimed by Apple? No, not really.

This is relative, but it's worth noting that most Apple Watch models cost more than the (upfront, subsidized) cost of even the newest iPhone. ↩︎

Jim Ray nailed this in his post. ↩︎

Nobody Knows

From Billboard:

If I had been Jay Z, I would have brought out ten artists that were underground or independent and said, 'These are the people who are struggling to make a living in today’s music industry. Whereas this competitor streaming site pays this person 15 cents for X amount of streams, that same amount of streams on my site, on Tidal, will pay that artist this much... I think they totally blew it by bringing out a bunch of millionaires and billionaires and propping them up onstage and then having them all complain about not being paid."

Push notifications are a really big deal. They add tremendous utility to connected devices, especially for mobile ones.

Push notifications are powerful in two different ways: They provide alerts to the user, obviously, but they can also provide alerts to applications. For example, a server can send a push notification to an app, signaling there is new content to be downloaded. The app can then silently pre-load that content and decide when best to alert the user about the new data, if at all. This way the user always sees the freshest data – no "downloading..." required.

Apple’s push technology is closed and proprietary. It relies on native-API-only app tokens, an Apple-controller server, and an OS-level connection to that server to keep battery drain to a minimum.

So far no technology like this exists for the web. It’s a huge weak spot for web apps. If you want to build an app capable of alerting the user to something through an experience you control, you need push notifications, so you need a native app.1

The Apple Watch looks to be all about notifications. It has a touch screen and a dial, but it doesn’t seem designed for lots of input. It has good little screen, but it doesn’t seem like something you’d want to stare at for a long time. Without having used one, it’s difficult to know for sure, but the primary usage pattern seems to be:

Notification: Be notified something happened, through any of the apps you have installed.

Action: Perform some quick action. Reply to a text, get route information, or view a photo.

Dismissal: Dismiss the device and get on with your life.

Web apps can’t even get off the ground with this kind of alert-driven usage pattern. It should be no wonder to anyone why they’re not part of wearable devices. The closest thing the web has right now is a working draft of something called Simple Push which is currently implemented by 0 of the top 5 browsers.

The WWW’s omission from the Apple Watch is hardly a death knell, but I do really hope the web can get it’s act together with regards to push notifications. We've been too long without this feature already, and it would go a long way in securing the web's future relevance.

If you’ve attended our annual meetings, you know Charlie has a wide-ranging brilliance, a prodigious memory, and some firm opinions. I’m not exactly wishy-washy myself, and we sometimes don’t agree. In 56 years, however, we’ve never had an argument. When we differ, Charlie usually ends the conversation by saying: “Warren, think it over and you’ll agree with me because you’re smart and I’m right.”

Stories about people reject wealth, whether it was given to them or they never wanted it in the first place. Also includes great interviews with researchers about how and why people do generous things, and where we draw the lines.

I cried so hard at the first story. The nicest old Canadian man.

In a recent Instagram app update, the blue color of their UI shifted a bit deeper, resembling Facebook Blue a little more.

Facebook has, so far, kept their promise of keeping Instagram at arms length from the rest of the company, and haven’t made any large user facing changes. The app hasn’t stagnated: aside from the continued massive growth which requires mind-numbingly complex back-end changes, they’ve done a good job keeping the UI fresh. They’ve added new filters, greatly improved search and discover, and overhauled notifications. But all of these things are adjustments to the same winning recipe — we haven’t yet seen a change in meals, yet alone an entirely new menu.

As time goes on I wonder about the inevitable first big change they’ll make to the service. My guess is photo size.

The last time Instagram substantially changed their photo size was after the launch of the iPhone 4, the first device with a Retina screen.1 Instagram doubled their image size to fit the new devices screen size. There was no Android version of Instagram at the time, so they had no other sizes to worry about.

Fast forward 4 years, and Instagram now runs on multiple platforms and devices with dozens of different screen sizes. Scaling images was inevitable. But when a 640px image needs to be rendered as wide as 2250px, it's somewhat of a disappointment, and not easily remedied.

Instagram photos kind of look a little blurry on an iPhone 6, and they definitely looks like shit on a 6 Plus. These being the newest, highest quality phones, users would expect a premium experience, not a degraded one. Certainly Facebook/Instagram realize this and want to fix it, but the question is how.

When Instagram decides to up the resolution again, they have to answer:

What new resolution(s) can best serve a flexible set of devices screen sizes?

What do we do, or what technology do we use, to ensure users on slower connections still have a good experience?

Do we reconsider the square-only format?

I'm sure the talented folks at Instagram have the data and skills to solve the first two questions, and frankly I can't wait to see what they come up with. Next-gen Progressive-JPEGs? Some other entirely new image format? A solution to HTML5 adaptive images? I don't know, but I'm sure it will be great.

The last question is easily the most contentious, and not even one that is entirely necessary. But, given how closely related it is to the problem at hand, it's worth considering. That Facebook allows images of any size format, and that it's one of the things venerable competitor Flickr does better, I wouldn't be surprised to see Instagram eventually capitulate on their square-only position. If they do, it will feel much more like Facebook than just the Blue.

If you're at all curious about just how deep the stack technologies powering the internet is, this document will help enlighten you.

This repository is an attempt to answer the age old interview question "What happens when you type google.com into your browser's address box and press enter?"

I love this breakdown of new language evangelism, particularly Eric's take on Swift and the Apple developer ecosystem:

Why will Swift go mainstream before F#?

Yes, F# has a seven year head start, but Swift will cross the chasm first. This has nothing to do with the relative merits of these two languages.

As of January 2015, F# is quite stable and trustworthy for most use cases, while Swift is mostly an unstable mess that isn't ready for prime time. This too is irrelevant.

The simple fact is that C# is kinda great and Objective-C is kinda dreadful. Swift will go mainstream first because you can't swing a 9-iron in the Apple/iOS ecosystem without hitting a pragmatist in pain.