You could always just go to Settings > General > Passcode > Simple Passcode, check "No," and then "use whatever they enter, no matter how long." Of course then you wouldn't have the had then fun of writing the last four paragraphs...

Would you have preferred if I had written "Apple does not actually need a backdoor per se in order toto perform the actions mentioned in the article?" My point was that what law enforcement is asking does not require a backdoor, since a lot of posters seem to think it implies there must be one. Furthermore, security researchers can and do look and see how all the signing keys etc are structured on running systems even without source code access. Is there a chance there is still something hidden, sure, but there is also a chance someone snuck a root exploit into an innocuous looking commit in an important open source project. Source code access generally does lead to more trustworthy code, but it isn't so black and white as you claim. In the end we depend on people to validate what we use, and just having the source available is not in and of itself validation.

As for the rest of the your comments, you simply don't know what you are talking about, but you would if you had actually read the PDF I linked. First off, rewriting the bootloader via JTAG is not an option on a lot of SoC's and embedded devices once they have had some of their internal fuses blown. From the PDF:

"When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load."

So the stuff in flash might be rewritable, but it won't be executed unless it is signed. Reading the raw flash is also completely useless, because all data written to it is AES encrypted via a DMA engine in the SoC that uses various different keys, but all of them are tied to or derived from values fused into the processor and not readable via software or JTAG (they are routed directly to the DMA block and never exposed). That means the brute force needs to be attempted on the SoC in that particular iPhone, or you need to drastically increase the search space. A suitably advanced attacker code probably also obtain the SoC keys by decapping the chip, dying it, and looking at the fuses with a scanning electron microscope, but I generally don't worry about an attacker with sorts of resources; they would probably just beat my PIN out of me...

Apple does not have a backdoor per se. But Apple does have the device signing key and can thus completely compromise the chain of trust. The only thing stopping you from compromising a phone with a 4 digit passcode in seconds by brute forcing it is the fact that software rate limits attempts, and the option to have it delete its intermediary keys after 10 bad attempts. If you have the ability to load an arbitrary kernel it is trivial to bypass both of these, but only Apple has that capability, at least on devices without jailbreaks that can be executed them while locked.

If you want to make sure your data is secure then use a full password and not a PIN, which will make Apple's ability to run code moot since brute forcing it will not be practical any more. You can look at https://acg6415.wikispaces.com/file/view/iOS_Security_May12.pdf/343490814/iOS_Security_May12.pdf for more info on the actual architecture.

Not that it really changes your point much, but they were given a 250K cash bonus AND a stock grant.

It is entirely accurate to say flu deaths are a minority of all deaths. According to the CDC in 2006 there were 56,326 deaths from Influenza and Pneumonia, out of a total of 2,426,264 deaths. If we assume all of those 56,326 deaths were from the flu, that is a grand total of 2.3% of all deaths from the flu. If the number is actually 36,000 (which sounds reasonable once you factor out Pneumonia) then it is only ~1.5%.

Of course that has nothing to do with the accuracy of the story, but lets not jump on the parts where we actually have reasonable data.

Erlang is very cool, but it is not designed to replace C. In fact, it is designed to handle some bits of the higher level concurrency stuff and call out to C "drivers" for level work. Apparently Ericsson's switch code has almost as much C/C++ code as Erlang code. GCD addresses concurrency in problem spaces Erlang is completely inappropriate for, just like Erlang plays in spaces that GCD is not appropriate for. They are different tools for different jobs.

No, what the actual situation is is that a block consists of some number of pages (currently on the flash used in SSDs it tends to be 128). The pages can be written individually, but only sequentially (so, write page 1, then page 2, then page 3), and the pages cannot be erased individually, you need to erase the whole block.

The consequence of this is that when the FS says "Write this data to LBA 1000" the SSD cannot overwrite the existing page it is stored without erasing its block, so instead it find somewhere else to store it, and in its internal tables it marks the old page as invalid. Later when the GC is sweeping blocks for consolidation the number of valid pages is one of the criteria it uses to figure out what to do. If a block has very few valid pages and has been completely filled then those pages will probably be copied to another block that is mostly valid and the block the data was originally in will be erased.

There is an extensions that was recently added to ATA, the TRIM command. The TRIM command allows an OS to specify a blocks data is no longer useful and the drive should dispose of it. No productions support it, but several beta firmwares do. There are also patches for the Linux kernel that adds support to the black layer along with appropriate support to most filesystems. Windows 7 also has support for it.

There is a lot of confusion about this on the OCZ boards, with people thinking GC somehow magically obviates the needs for TRIM. As you pointed out the GC doesn't know what is data and what is not with respect to deleted files in the FS. I wrote a blog post (with pictures and everything) explaining this just a few days ago