post #121 of 121
Quote:
Originally Posted by Crowley View Post

It was meant more as a removal of blame from the hacker/researcher.  He didn't take the system down, the discovery of a security vulnerability did.  Apple were responsible for the security vulnerability.  I don't think that equates to blaming Apple for the system being down either, while security vulnerabilities are never welcome they are a fact of life, and it is good that Apple is taking it seriously and beefing up their system.  So Apple can be criticised for there being a security vulnerability in the first place, but can be commended for their response.

 

 

I understand now. Your previous statements did not accurately convey your intent. That being the case, I withdraw my first statement and acknowledge your premise. However, this individual still bears a significant responsibility here.

 

Quote:

Originally Posted by Crowley View Post

What are the ends, a week or so without a developer resource?  Is that really going to affect anyone so terribly?  I don't mean to trivialise it, I'm sure some people are feeling very put out right now, and stress levels may be rising, but in the grand scheme of things, it's not much of an issue.  If he hadn't done this then maybe that security vulnerability would be exploited by someone with malicious intent, someone who might have gone "deeper" and got much more damaging data.  I think the end definitely justify the means, and we're a long way from hell.

 

 

It is, unfortunately, more than a trivial inconvenience. It has already made a significant impact for some. A week of lost productivity is a week of lost income. From my own first-hand experience; the app development companies I work with typically schedule development and business activities in two week "sprints", for project lengths of two to four months. Product scheduling can be planned six months or more in advance. So a delay of one week (and still counting as of this morning) is a significant setback for a sprint, and consequently a significant delay on a development schedule. While creative can often be generated in advance, things like QA are necessarily bound by development activities. Marketing, more often than not, may need to commit resources to release dates far in advance of development even beginning. So, beyond a certain threshold, a delayed project either 1) pushes back all subsequent projects that resource is committed to (and effects the business decisions related to <all> of those products), or 2) delays the affected project until after all the other pre-existing commitments have been satisfied, which easily may be one to two fiscal quarters, or even indefinitely. In many cases, that alone is enough for a business decision to kill a project. I've known contractors to lose their work for delays of this magnitude.

 

Quote:

Originally Posted by Crowley View Post

Apple history in this regard isn't great, they've been criticised for sitting on security vulnerabilities for months without making any moves towards a fix.  I believe I read that this issue was reported using the proper channels to no result.  So the response in your alternative scenario could have been the feared worse-case breach, which would have caused a much greater paralysation of the services.  Conjecture I know, but you're doing the same.

 

 

 

Balic didn't file a bug report outlining a vulnerability that he might have exploited, he (by his own admission) exploited the vulnerability extensively and supposedly reported it after the fact. By his own statements, he tested "how deep he could go" and accessed significant amounts of user data <before> he submitted the alleged report (he claims he supplied some of the misappropriated data as 'proof' of the vulnerability with his reports). As for the criticism that Apple didn't respond to the alleged report - it was (according to Balic) four (4) hours between his bug report (and the intrusion attempt) and the time Apple reacted to an unknown breach. Even if he'd only filed a bug report, without probing the extents of the vulnerability - that was a wholly insufficient time for anyone to have properly verified the issue and responded to it. The time constraint was further aggravated by the fact that Apple had to expend resources contending with the clear and present danger of a breach which had already been executed. At that point, searching the bugbase for a report that may or may not be relevant was likely completely out of the question.
 
In choosing to force the issue <now>, he made a choice to impose an immediate cost (to one degree or another) on everyone associated with the developer program. There was no way to prepare for the situation and mitigate the damage done (for example, a planned outage could've been scheduled and announced - even if on short notice, developers may have been able to preemptively secured the provisioning they needed). He took that ability away from us, and the defense you propose is that someone <might> have found the same vulnerability, and <might> have exploited it, and their intent <might> have been more malicious - and this is all at some unspecified point in the future. Because <he> decided how severe this was, and <he> decided how fast it needed to be addressed, <he> caused a panic. If he'd simply notified Apple of the details, and possibly even made a public statement that he'd found <some> vulnerability of supposedly significant proportions, then Apple disregarded a credible reporting in a <reasonable> amount of time - then absolutely would this sit squarely on Apple's lap. But he didn't, his choices weren't the only course of action available to him, and not even the most prudent of those - so by definition they were unnecessary. That's why he's in the wrong.

 

Quote:

Originally Posted by Crowley View Post

I don't think anyone expects Apple to be able to withstand prolonged military-grade cyber attacks.  A hacker though?  Operating alone?  That suggests they weren't up to scratch.

 

 

At the risk of being blunt, no. In the absence of any other relevant information, it suggests no such thing. This does not appear to have been a brute-force attack that would've materially benefited from extensive time, compute or manpower resources.

 

Quote:

Originally Posted by Crowley View Post

 

I didn't make an analogy, I used a metaphor.  There's a difference.  You extrapolated that into a tortured analogy, that's the lengths.  No "accuracy" was ever intended or implied, it was just a metaphor, like when I say that clouds are like soldiers marching to war - point out the differences between clouds and soldiers as much as you want, but you're wasting your time because I don't actually think clouds are literally like soldiers marching to war.

 

I'd rather drop the painful linguistic exercises and focus on the facts.

 


Very well, semantics it is. I stand corrected, you used a metaphor, which defined an analogy. Your metaphor failed as it did not link the attributes of the vehicle(s) to the tenor(s). What I did was to express a more representative metaphor using the theme from your metaphor and the actual attributes of the vehicle that is the topic of our discussion. And yes, my 'tortured' metaphor was longer than yours. (Ok, I promise I'll stop with that now ;) )