Apple Developer Center is Fully Restored
developer.apple.com
developer.apple.com
Apple is the only big software company that doesn't develop server-side technologies. If I was the boss of Apple I'd standardize on FreeBSD and Golang today! But, I'm not... obviously :)
> If you've ever poked around with the way that Apple's website works, you can see that the entire place is a huge mess. There's old servers running ancient (pre-2004) perl scripts alongside the brand new iCloud gear. I can't imagine how the authentication for AppleID is working as login details still work on the ancient pages (think pinstripes and glassy buttons). Depending what URL you hit, the webserver is using php3, php4, perl, python or maybe WebObjects (java).
> At one point I wrote a scraper that was targeting one of their product pages, and kept getting random, unexplainable results. It turned out that one of their product areas was behind a round-robin load balancer, with three completely different apache versions on each server. The page was dying on one but not the other two. In the end I just had to repetitively scrape until I hit a good response.
iCloud storage, iTunes Match, iMessage, to name just a few. If you stop to think how these all just work across devices and desktops, and at what volumes, you'll realize they've got some server chops.
They also don't really work. iMessage is unreliable at best, and iTunes match just makes home taping look preferable.
My understanding, from when the references to Azure and Amazon CloudFront (not EC2) were first discovered in iCloud traffic, was that Apple was using Microsoft and Amazon's CDN services, amongst others, to serve static content.
I've seen no indication that the core guts of iMessage et al live anywhere but inside Apple's own data centres.
Many more profanities are being hurled at Apple this morning.
There is nothing to complain about here; you've just got to suck it up.
just saying that apple seems to be getting treated better for no reason
Most firms would have duct-taped the specific section exploited.
Though they were warned before the breach occurred, right? They didn't take it seriously until well after they knew they needed to fix it.
If you can't accept the new T&C you can't get into the profile center.
They fucked up, now they're paying for it.
That's more than enough reporting. If you want a full post-mortem, that's likely not something you'd get from a public company as big as Apple
Another comment mentioned that AWS post-mortems are also detailed and public, they don't really have another choice because their customers have their infrastructure running on AWS - so they want to know what happened and not be left in the dark.
[1] http://labs.spotify.com/2013/06/04/incident-management-at-sp...
https://developer.apple.com/iphone/urlRedirect.action?mode=e...
Anyone else got this issue?
I don't know the extent of the problem but taking down an online service for weeks is very uncommon. I guess (speculating a bit) that Apple could have applied a quick fix to the problem within a day to save their (short term, at least) brand appearance. I think "just getting it secure enough" is the most many people would do if an important service was down. It appears that Apple took the time required to deploy a proper fix, prioritising security over shot term wins.
It would be interesting to see what someone like Microsoft or Amazon would have done in this situation, or what Apple would have done if it was all of iTunes instead of the dev centre.
As usual, a dashboard of green lights does not identify uptime, as can be established by the issues people are still having with the platform.
There's been weekly or slightly shorter than weekly updates and a 24-hour status page. Also, most key portal functionality was available not that long after the breach.
It's a little unfair to say "very little to no communication".
In my books, that is no communication. They haven't told us what the problem was at the end of the day.
We know they didn't push a quick hacky fix live. I think it's quite likely (due to the resources they have) that they deployed a proper fix, not sacrificing security for a faster response. I could be wrong.