We now supposedly know who is responsible for the Apple Developer Portal being down for the past four days. Security researcher Ibrahim Baliç has revealed himself as the source behind what Apple is calling an “intrusion” into their systems.
Baliç discovered a vulnerability, among 12 other security issues, that allowed him to access details on over 100,000 Apple developer accounts including their email addresses and names. To see the hack in action, check out his YouTube video.
Why 100,000 Records?
I’m not a security researcher, but my guess is that he accessed that many records to see how deep he could go when reporting the vulnerability. The more data you can access, the bigger an issue it is.
Could he have stopped at 100 records and reported the issue? Probably, but we don’t know if Apple would have been so quick to react to it.
Why the Video?
If you look at Apple’s statement they put out on Sunday it reads as if they are the victim of a malicious hacker that broke into their systems and stole information. Here’s the actual wording:
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.
In reality (assuming that Baliç is indeed the source for this downtime), a security researcher with a proven track record of being a white hat hacker discovered the vulnerability and reported it to Apple through their official channels: RadarWeb.
Indeed, his biggest crime is posting the personal information of five people in a YouTube video to prove the vulnerability. The irony of a security researcher being so personally insecure about how he is labeled that he goes to YouTube isn’t lost on me.
And there are likely better ways he could have proven the hack to the media such as with technical details, but the video is 2 minutes of absolute proof that the issue is there and far easier to understand than technical jargon.
Baliç’s biggest crime is having an ego and not wanting his work misrepresented. I don’t approve of the way he went about it, but I’m not going to vilify him over showing five or so email addresses when the good he’s done in helping Apple secure their stuff far outweighs the bad.
It will be unfortunate if the only thing people focus on is this video rather than the fact that Apple had a serious vulnerability in their system that left all of our personal information at risk.
How Do Other Companies Handle This?
A lot of tech companies have dedicated pages where they highlight the channels for responsibly reporting security issues. They also give public acknowledgement to the folks who have reported the biggest vulnerabilities. Here are just a few:
Baliç is listed on Facebook’s list of white hat reporters so I’m willing to give him the benefit of the doubt as doing this work for good rather than nefarious purposes.
I’m not a security researcher, but I’ve watched Hackers enough to know that one of the big reasons for exploring these sorts of cracks in systems like Apple’s is for the recognition amongst your peers and other companies. To a white hat hacker, being listed on Google or Twitter’s list of people who have reported major vulnerabilities is not only validation for your work, but also likely money in your pocket as others will hire you to break into their systems.
Apple is a culture built around secrecy so I highly doubt they’d set up a public page that championed folks like this, but they have long listed reporters in their Security Update knowledge base articles.
Someone Must Take The Blame!
The vulnerability isn’t Baliç’s. It’s Apple’s. He just discovered it and Apple deemed it severe enough that their response was to take down their entire developer program until they can close the hole.
I’ve been incredibly vocal about the inconvenience that the downtime has caused me, but knowing how big of an issue it is, I’m fine with Apple taking their time to get the fix right.
I am not fine, however, with them trying to paint themselves the victim of malicious intent when in reality it looks as though someone properly reported a vulnerability in their code to them.
No one comes out of this looking clean, but it could have been a lot worse if a more dark hacker discovered the vulnerability before Baliç.
David Smith, creator of personal favorite Check The Weather, wrote a piece about how he wishes Apple would begin culling the “back catalog” of apps that that are no longer actively being developed.
The App Store currently has around 800k active apps listed. I suspect a significant number of these haven’t been updated in more than 12 months. An app that is listed for sale but is no longer under active development creates the possibility for bad user experience. It is like a grocery store that leaves expired produce on its shelves. The best situation for customers is a marketplace where whichever choice they make results in a great experience.
The idea of expiring apps is centered on Apple’s recent announcement that they will no longer accept apps in the App Store that are not retina ready and updated to support the 4″ screen of the iPhone 5 and latest generation iPod touch. I can only think of one app on my phone still not updated for the latest devices1, but I am not as heavy an app shopper as many.
While I don’t believe Apple will likely do this because the app count metric is still worth something, it is something I believe is a positive both for the ecosystem itself, as well as independent developers personally.
Back in August of 2012, I killed both MarkdownMail and the elder statesman of the Second Gear catalog, Today. Both were still bringing in a small amount of sales, but the emotional burden of having apps in the store that I know could use improvements, but have zero interest in working on anymore is heavy. It’s also difficult for me to get over the gross feeling that I would be taking someones $3 – $10 for an app that worked, but really wasn’t actively supported going forward. Financially, it wasn’t my wisest move, but I’ve done way dumber things with money.
This is also why I was more understanding of Google’s decision to axe its Reader project in favor of focusing on other projects. While I sympathize with the people losing a utility they were fond of, tossing rotting software in the dumpster makes room for future innovations from other developers in that space, and allows Google to focus on the things it’s most interested in.
- Born
- Crawled
- Walked
- Nearly died
- Lost my tonsils
- Lost my baby teeth
- Moved to Indiana
- Went to elementary school
- Won the spelling bee three times
- Discovered the Internet
- Went to junior high
- Had my first kiss
- Taught myself Visual Basic
- Met my high school sweetheart
- Grew my hair to my shoulders
- Almost got expelled, multiple times
- Went to high school
- Met the girl I would marry
- Switched to Linux
- Spent far too much time switching between Debian, Slackware and Red Hat
- Learned to drive
- Graduated from high school
- Switched to a Mac
- Went to Purdue
- Experienced my first heartbreak
- Failed out of Computer Science after 1 semester
- Went to the University of Southern Indiana
- Went back to Purdue
- Graduated Purdue (but not for Computer Science!)
- Started Second Gear
- Learned Objective-C
- Released Today for OS X
- Got an iPhone
- Built PocketTweets with Robert Andersen
- Released a native iOS app
- Started FuckingNDA.com
- Quit the App Store
- Did a radio show for a year
- Did a radio segment for two years after that
- Got married
- Moved back to Central Indiana
- Organized Indie+Relief with Garrett Murray and raised $143,872 for charity
- Started public speaking
- Went back to the App Store with Elements
- Dealt with a lot of health stuff
- Got a divorce
- Sold everything and moved to San Francisco
- Shipped HotelTonight’s iPad app
- Went to Hipstamatic
- Became an uncle
- Made some great friends
- Got laid off at Hipstamatic before I could ship anything
- Sold everything that didn’t fit into four boxes and drove to Colorado
- Turned 30
Here’s to another thirty years.
All of the projects I am currently working on are targeting iOS 6, so I have used it as an opportunity to finally dive into the deep end with Auto Layout. Committed was my first foray with the technology on the Mac this summer when I laid out the preferences window using constraints rather than traditional springs and struts.
On a simple window like that with just a few tables views and buttons the experience is pretty straight forward. As I don’t have much experience with anything more complex on the Mac, I’ll refrain from commenting on that experience much more.
My focus the past few months has been on iOS where Apple introduced Auto Layout as part of the iOS 6 launch. Auto Layout is touted as being superior to the old springs and struts based layout styles because it allows building layouts that can scale to a variety of different screen sizes. Working on a platform with 3.5″, 4″, 7.9″ and 9.7″ devices? Sounds like a great technology to adopt!
The Learning Curve
Auto Layout has one of the steepest learning curves of any new technology I’ve worked with. There are at least three different things you need to keep track of on the basic level. Step one is wrapping your head around working with constraints in Interface Builder. Step two involves using the code-based NSLayoutConstraint, which includes the visual formatting language. Step three revolves around debugging and dealing with more advanced things like animation.
Even after a few months of using Auto Layout, I still don’t feel the level off comfort using the technology as I would with any previous ramp up I have had.
Interface Builder Is The New HAL 9000
Apple tends to recommend laying out constraints using Interface Builder whenever possible because it’s a bit easier to visualize what you are doing. Plus, who doesn’t prefer clicking buttons instead of typing more code?
What frustrates me about setting constraints with Interface Builder is its instance on adding more constraints automatically for me, even if I don’t want/need them. I’d love some sort of button or setting I can click to tell Interface Builder to back off and just let me handle everything.
The workaround I tend to have for these constraints I don’t really want or need is to set them with a lower priority (Radar: 12625299).
Debugging Ambiguous
I’ve had better luck trying to read women in my failed relationships than trying to debug why my constraints aren’t working out. When working with a view in Interface Builder, I’d hope that it would be able to tell me that my layout was ambiguous before I went through the process of recompiling and running my application.
In the case of the primary project I’m working on right now, all the constraints are written in code, so the only recourse for debugging really is calling [self.view _autolayoutTrace]1 from LLDB. Calling _autolayoutTrace will give a breakdown of the hierarchy of your views and list any of them that have ambiguous constraints, but that’s it.
Great. I have view that’s ambiguous. Now what? A lot of trial, error, and tears usually. There’s a category on UIView called UIConstraintBasedLayoutDebugging that has three methods for trying to debug constraints, but it’s still far more trial and error debugging than was ever necessary with springs and struts.
OS X has an Instrument tool for working with constraints, but it’s not available for iOS. I’ve never used it, so I can’t speak to its benefits but in general any tool that makes debugging easier would be a win. (Radar: 12625327)
Ideally there would be a way to visualize constraints either on device or in the iOS simulator so see what constraints are affecting a specific view. NSWindow has something similar to its visualizeConstraints: call. I’d love to see that for iOS. (Radar: 12625312)
Documentation?
When something has such a steep learning curve as Auto Layout, you want to provide as much documentation and help as possible, especially if you want developers to adopt the technology.
In the case of Auto Layout, the best documentation isn’t in Apple’s official documentation. It isn’t in a book. It’s in three hours of WWDC 2012 videos. Seriously, if you are going to work with Auto Layout you should watch sessions 202, 228 and 232. And then watch them again.
The problem is that a lot of the information I find in these three hours of videos isn’t really replicated in the documentation. Like a lot of Apple documentation, it highlights the happy path of what you can do with Auto Layout, but leaves you to sink or swim once you get beyond that. The WWDC videos, on the other hand, handle a lot of those hairy edge cases and complexities you may run into when working on a product that is larger than demo size. Sample code on Apple’s side related to Auto Layout is also pretty sparse. Again, I’m a visual learner. (Radar: 12625370)
Animation
Animation is a core component of a modern OS X or iOS application. At a basic level, animation revolves around adjusting the frame of a view or adjusting its transform. With Auto Layout, the recommended way to do any sort of animation is to animate the constraints.
Animating constraints is a bigger pain in the ass than animating frames. You have to keep a strong reference to each constraint that you want to animate and usually either re-set the constraint or adjust its constant value depending on what you’re doing. I recently was trying to figure out how to zoom an Auto Layout-based view to fill the entire parent view that contains it. I uploaded a sample project to iOS with a solution to the problem, but I can’t help but feel like I had to write way more code to accomplish this than I ever would have the old way
I don’t really have a suggestion for a way to improve this. I just think it’s a pain point.
Despite the learning curve and the frustrations I have with Auto Layout in its current incarnation, I plan to continue to use it. Unlike something like bindings on OS X, I think they are a fundamental aspect of development going forward that will be difficult to avoid using.
Four weeks ago this Thursday myself and four other ridiculously talented people were laid off from our jobs at Hipstamatic. In the time since then we have all been trying to figure out what was next.
I personally took several coffees and interviews with companies in the Bay Area as well as other cities around the country. Many of the opportunities would be lucrative. Some would be interesting. Others had a high probability of seeing an excellent payday if I stayed around long enough. None were exciting though. Nothing I heard or saw really got my mind racing with ideas and excitement about what I could accomplish there.
In the end, I kept coming back to what I used to do full-time: Second Gear. I started Second Gear the day after I graduated college and it was my full-time job for six years, up until January when I packed up and moved across the country to the Bay area to try out startup life and see what life was like outside of my Indiana bubble. What I learned is it’s not for me.
So, I’m back full-time at Second Gear. Reviving my company and focusing on products of my own is what gets me excited and what I love doing. It may not be as lucrative or sexy, but it’s far more rewarding in other ways.
I’ll be splitting my time between doing my own products and contracting work 1 for the time being while I replenish the coffers. Updates to Elements are in the works and I’ve already submitted a new app to Apple for review that I’ve been working on over the past few weeks.
While I’m returning to the job I left at the end of 2011, I’ll also be saying goodbye to the city I left it for: San Francisco. In three weeks time, I’ll be loading up a rental car and driving what remains of my belongings to Denver, Colorado to start an all new adventure in an all new city.
I don’t regret my excursion West to get something that has been in the back of my head for so long out of my system. In the end, it was what I needed to realize what I’m best at doing: my own thing.
Back to work.