Now let's hold Android up next to a piece of Swiss cheese! Looks like someone didn't like the outcome of the second samsung trial! Silly European, he thinks he's superior!
Now let's focus for the moment on Apple and Security. While I think it's fair to say that the Unix foundation of OSX is a great advantage since it incorporates a considerable degree of security by design. it is equally fair to say that Apple has been anything but open and transparent about the details of its implementation. Frankly, you just don't know enough to say it is cutting edge security. The goto fail blunder however speaks volumes about the inadequacy of their code reviews and security testing. Frankly that was a fail of monumental proportions because it was so f*n obvious to anyone who can read code. There was NOTHING subtle about it. There are other examples.
<snip>
It's a bug (like goto fail or the OpenSSL problem). I think it's a bit unfair to assume that Apple does not care about security just because it has a bug. Everybody has bugs.
I also think it's a bit of a stretch to blame this on Apple's OS being proprietary. It's unfair to say that they're not transparent on security: the strategy is here; not revealing a security bug until a fix is ready is standard industry practice (don't give the bad guys a head start, they'll reverse engineer the fix anyway but that's better than a zero-day attack). It's a stretch to say this is down to iOS being proprietary since being open-source is no better guarantee of error-free security code (obvious example being Heartbleed, currently plaguing the web because a piece of open-source code was inadequately reviewed about 2 years ago and many servers have undetectably been leaking data ever since).
I would also echo SolipsismX and asdasd in saying that Apple's profit motive is precisely consistent with providing good security. iOS has a sophisticated security architecture that is a part of the iOS devices being high quality, which underpins Apple's ability to charge a premium price and hence make more profit. The fact that this is often overlooked (by a lot of people, some that should know better) does not affect the fact that the design intent is to secure all data at rest (ie stuff in the Flash memory) just like seriously secure systems do and to do it transparently and efficiently by using hardware AES encryption (in all iOS devices since iPhone 3GS). That currently has a vulnerability for a particular category of files; when it's fixed, the document I referenced will again describe the actual behaviour.
There are downsides to both proprietary OSs and closed ecosystems. I don't think this is an example.
Its not the fact that there was a bug that is the problem. The fact that the bug, which is REALLY EASY to detect by automated code-tracing. made its way into a productive release demonstrates that the pre-release security checking is way below what one can expect from a company with the resources that Apple has. If they were as serious about security as they pretend to be, this would never have slipped through.
OK , now you're really just acting wilfully stupid. Read my comment again. Nowhere did I say that Profit and security are mutually exclusive, but if you want to call it that I would tend to agree simply because Security requires effort, manpower and investment, which means more expenses, which means more profit. So they are not mutually exclusive, but opposing elements.
Secondly, I never said that Apple doesn't do anything, as you claim. I did imply that it doesn't do enough.
But your tactic of erecting straw-man arguments and putting words into my mouth is as transparent as it is infantile.
So, for the intellectually challenged you might like to learn to read carefully, to discuss rationally and to stop being an asshole.
1) Keep trying but personal attacks won't work.
2) Learn what a strawman is.
3) You left zero room for Apple or anyone to be interested in profits and wanting improve security — something already proven — as a manner of achieving that goal. You made the two mutually exclusive with your poorly chosen words.
Its not the fact that there was a bug that is the problem. The fact that the bug, which is REALLY EASY to detect by automated code-tracing. made its way into a productive release demonstrates that the pre-release security checking is way below what one can expect from a company with the resources that Apple has. If they were as serious about security as they pretend to be, this would never have slipped through.
I can't disagree with that. I expect the compiler even warned the programmer about the dead code (not sure I've ever used a goto in C so I'm not sure), never mind testing. The regrettable truth is that much software from everyone is rushed and so ends up with silly bugs (except they become serious in cases like this). However, I expect that Apple will continue to fix security issues and that the ecosystem will remain relatively secure (my Airport Extreme had a Heartbleed-related update the other day that I think was unheralded - that's how it needs to happen).
The LCC compiler doesn't warn on dead code in compilations
I assume they'd be using what Apple calls the Apple LLVM compiler (standard in Xcode) which I think is Clang. However, I've just put a goto and a label around some code and you're quite right that there is no warning. Thanks for pointing it out, I've always thought that dead code usually represents a programming error and is easily detected during optimisation...
Comments
Now let's focus for the moment on Apple
Duh !
<snip>
Now let's focus for the moment on Apple and Security. While I think it's fair to say that the Unix foundation of OSX is a great advantage since it incorporates a considerable degree of security by design. it is equally fair to say that Apple has been anything but open and transparent about the details of its implementation. Frankly, you just don't know enough to say it is cutting edge security. The goto fail blunder however speaks volumes about the inadequacy of their code reviews and security testing. Frankly that was a fail of monumental proportions because it was so f*n obvious to anyone who can read code. There was NOTHING subtle about it. There are other examples.
<snip>
It's a bug (like goto fail or the OpenSSL problem). I think it's a bit unfair to assume that Apple does not care about security just because it has a bug. Everybody has bugs.
I also think it's a bit of a stretch to blame this on Apple's OS being proprietary. It's unfair to say that they're not transparent on security: the strategy is here; not revealing a security bug until a fix is ready is standard industry practice (don't give the bad guys a head start, they'll reverse engineer the fix anyway but that's better than a zero-day attack). It's a stretch to say this is down to iOS being proprietary since being open-source is no better guarantee of error-free security code (obvious example being Heartbleed, currently plaguing the web because a piece of open-source code was inadequately reviewed about 2 years ago and many servers have undetectably been leaking data ever since).
I would also echo SolipsismX and asdasd in saying that Apple's profit motive is precisely consistent with providing good security. iOS has a sophisticated security architecture that is a part of the iOS devices being high quality, which underpins Apple's ability to charge a premium price and hence make more profit. The fact that this is often overlooked (by a lot of people, some that should know better) does not affect the fact that the design intent is to secure all data at rest (ie stuff in the Flash memory) just like seriously secure systems do and to do it transparently and efficiently by using hardware AES encryption (in all iOS devices since iPhone 3GS). That currently has a vulnerability for a particular category of files; when it's fixed, the document I referenced will again describe the actual behaviour.
There are downsides to both proprietary OSs and closed ecosystems. I don't think this is an example.
Its not the fact that there was a bug that is the problem. The fact that the bug, which is REALLY EASY to detect by automated code-tracing. made its way into a productive release demonstrates that the pre-release security checking is way below what one can expect from a company with the resources that Apple has. If they were as serious about security as they pretend to be, this would never have slipped through.
1) Keep trying but personal attacks won't work.
2) Learn what a strawman is.
3) You left zero room for Apple or anyone to be interested in profits and wanting improve security — something already proven — as a manner of achieving that goal. You made the two mutually exclusive with your poorly chosen words.
Its not the fact that there was a bug that is the problem. The fact that the bug, which is REALLY EASY to detect by automated code-tracing. made its way into a productive release demonstrates that the pre-release security checking is way below what one can expect from a company with the resources that Apple has. If they were as serious about security as they pretend to be, this would never have slipped through.
I can't disagree with that. I expect the compiler even warned the programmer about the dead code (not sure I've ever used a goto in C so I'm not sure), never mind testing. The regrettable truth is that much software from everyone is rushed and so ends up with silly bugs (except they become serious in cases like this). However, I expect that Apple will continue to fix security issues and that the ecosystem will remain relatively secure (my Airport Extreme had a Heartbleed-related update the other day that I think was unheralded - that's how it needs to happen).
The LCC compiler doesn't warn on dead code in compilations
I assume they'd be using what Apple calls the Apple LLVM compiler (standard in Xcode) which I think is Clang. However, I've just put a goto and a label around some code and you're quite right that there is no warning. Thanks for pointing it out, I've always thought that dead code usually represents a programming error and is easily detected during optimisation...