Showing posts with label apple. Show all posts
Showing posts with label apple. Show all posts

Monday, March 7, 2016

Apple, Encryption, and the FBI's request

Encryption has been in the news a lot lately with the recent stand Apple has taken against the FBI's request to help them break into an iPhone. Whatever side you're on with this I think there's some interesting things that may be a bit misleading to the general public that I'd like to weigh in on from a technologists perspective.

I don't work at Apple or the FBI so all of my information about what's going on is from what I've read in the news, from Apple's and the FBI's public statements, and from what I know about how software is built and how operating systems work.

1. Apple is being a bit disingenuous when they say that they're being asked to create a new operating system. I think I understand why they're using this language. I can't find the source to cite here but I believe the legal guidance around the All Writs Act that the FBI is using to claim legal jurisdiction is that a company cannot be compelled to create something new in order to comply with the request. In Apple's case, saying that they're creating a new operating system makes then case stronger in their favor.

What Apple is being asked to do is create new code or remove existing code (likely somewhere in between) in their existing operating system that would weaken or bypass the current security of the system. The reason I say this isn't a new operating system is because an operating system at it's core is a system that interacts with hardware, sensors, and peripheral devices by providing tools and services that applications can build upon. Operating systems do things like interact with your hard-drive, memory, graphics card, and etc. While security is part of the operating system, 99% of what Apple would be delivering with a change would be the same as what's in their operating system now.

Regardless of whether what Apple would need to create is a new operating system or not, they're being asked to create a product that does not exist today by writing (or changing) code that would allow for a brute force attack. So I think Apple is being genuine in what they're trying to say, but not in the way they're saying it.

2. Apple's correct that you can't just write something and then throw it away. 

The only way to achieve what the FBI is asking without having any trace of the source code would be to have a machine from which the source could be changed and the operating system build that didn't have a hard disk or memory attached to it. If there is a hard disk or memory there is a "record" of the change at the lowest levels from which the changed code could be re-constructed. This isn't likely as it would require physical or network access to the machine from which the code was written. You could prevent network access by never plugging the machine in to the network. And you could prevent physical access by destroying the machine immediately after creating the modification to the operating system. Neither of those two are really feasible in today's modern software development ecosystem.

Virtually all software written today, likely including Apple's, is written using source control. Meaning, there is a system that contains every line of code and tracks all changes to that code. This is done for many many reasons. For instance, as software engineers we often have to re-create a build at a given point in time in order to find and fix bugs in a particular release. By the time software is released, we're already working on the next thing. Being able to recreate a build exactly as it was allows us to create targeted changes (or updates) as well as gives us the ability to reproduce errors. Additionally source control gives us an audit mechanism for changes introduced into the system. We can see who, when, (and often) why a change was introduced. With a source control system it is possible to go back to a snapshot of any code in the system at any point in time.

Trying to make changes that never get saved up stream to the source control system isn't that tough. But what is likely tough is getting a fully releasable build created using a build system that assumes the build is being created from source control. It's likely that the Apple's code that builds Apple's operating system is done so through a pipeline of tools that gets the source code from source control. Meaning, all of Apple's processes are likely setup around the use of a source control system.  So if engineers at Apple were to create the requested software it's likely that it would have to be added to the source control system in order to create the requested build of the operating system. Once these changes are added to source control, they're forever there and forever accessible (to an extent).

3. This is about more than just 1 phone. As much as the FBI wants us to believe this is just about one phone it's not. One of the ways our legal system works is through the setting of precedent. Once an act has been performed that can serve as an example for future similar cases precedence has been set. If Apple complies with this request there's precedence that can be used to compel other hardware/software manufactures to do the same.

4. Security is about trust and at the end of the day that is what this is all about. Apple, rightly so, does not want to lose the trust of those in it's ecosystem. It doesn't matter whether Apple thinks this is the correct thing to do from a moral, legal, or ethical standpoint. If Apple loses the trust of those in it's ecosystem that would spell imminent doom for the company.  

Monday, January 19, 2015

Don't hate your users or potential users

The other day I had an incredibly frustrating experience with iCloud that was 100% avoidable. I'm not an iCloud user but a buddy of mine is and when he had his first kid he sent out an iCloud link to some pictures. Being out and about at the time I tried to open the link on my phone using the mobile Firefox browser. I was greeted with this not-so-friendly message:



Something I've gotten used to doing on my mobile when web pages act weird is to check the "request desktop version" button and guess what? The page loaded fine but I was left with more animosity towards iCloud and Apple for blatantly breaking an experience that should "just work".

So what can we learn from this?
  • Your customers aren't just the people who bought your products. 
  • Provide "correct" details when things aren't going to work.

Your customers aren't just the people who bought your products

Most businesses view their customers as the who buy their products or use their services. But in a day and age where social media has become a primary mechanism for sharing information your customer base is now extended to those that your customers share their content with.

When you're building a product that allows users to share information via a URL you are essentially making a contract with that user that their content will be accessible by those they share it with on a modern web browser.

In the iCloud case I'm baffled at why Apple would explicitly block Android users. I understand they're trying to get people to use their ecosystem, but they also need to face the reality that people in their ecosystem interact with people on the outside.

How do I know they're explicitly blocking Android users? I took a look at the difference between the request headers that Firefox sends normally on Android and what it sends when you check the "request desktop site". The big difference was in Firefox's user agent string

Mobile OnlyMobile: Mozilla/5.0 (Android; Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
With Request Desktop Site CheckedMozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0

While I don't think this is the case for iCloud, there may be completely valid reasons they're blocking Android mobile user specifically. For instance they may not have the resources, bandwidth, or experience to test their site fully on enough variations of the Android platform to support the experience. Even if that was the case, which I do not think it is, they need to be more explicit with their users and those trying to use the site that there are known and likely use cases where the experience is not going to be available.

This leads me to the next thing we can learn from this experience.

Provide "correct" details when things aren't going to work

The web is often looked at as an "easier" way to provide a unified experience with broader reach than providing a native experience on multiple platforms. But with that broad reach and unified experience comes more responsibility to provide that reach.

The above screenshot says that my browser isn't supported. That's not true, they don't support my operating system. I tried to open that link in Chrome for Android and the normal Android browser and all three of them had the same experience.

The screenshot also says that I may be able to use iCloud with my phones mail, calendar, and contacts. They know that I'm trying to access a photo album. How is what they're suggesting as a possible fix applicable to my situation? 

Providing your customers (or potential customers) a great experience means being helpful when things don't go as they expect. It's not enough to make the experience work as you expect, you need to make the experience work as THEY expect.