Doesn't work. (I tried this a while back.) It turns out that the problem is that most SD card readers and/or their drivers don't support the necessary control of the SD card, so it doesn't matter what application you use -- the SD card can't be unlocked by most existing SD card readers.

Actually, there is no problem. It works fine if you replace it with a like chip (though you'll have to reset the phone since the like chip won't have the data from the original chip). The problem comes from two issues: 1) people replace it with non-like chips and whine that it doesn't work, and 2) people replace it and whine that the chip that was originally in there doesn't work in other devices.

As long as you replace it with a good chip, the phone will work fine. Currently, there is only one chip that is known to be good, but I'm sure that will change with time.

No, the lock/unlock protocol for SD cards is public. Nothing particularly special here, just rarely used. That said, a lot of SD card readers don't support the lock/unlock protocol. A locked card completely confuses most SD card readers, which is why the card doesn't even show up in the OS if it has been locked.

Windows Phone locks the SD card. The SD standard includes an ERASE command that would restore a locked SD card to its original unlocked status. However, most SD card readers don't support sending the ERASE command to the card. So while the SD standard allows for fixing the locked cards, in practice it's pretty hard to do so.

No, that won't work. The disk won't even be recognized if it is locked. The disk can't be selected until it has been recognized as a valid disk. You have to tell the SD card to unlock or erase itself before it will be recognized as a disk, and Windows doesn't currently support the necessary low-level unlock and erase commands.

SD card passwords can also be removed via the ERASE command. The card will then be usable in other devices, and you don't need to know the card's password to perform an ERASE. (Unfortunately I don't know of any commonly-available tool that will perform an ERASE on an SD card. Formatting and repartitioning are not the same thing, and the erase has to happen before you can format or partition.)

1. The "modification" mentioned is that Windows Phone uses the "LOCK" command of the SD card, which sets a password on the card. This is not commonly used, but it is part of the SD card standard. The S in "SD" stands for "Secure", and the "LOCK" command is one of the security features. It is possible to unlock the card via an UNLOCK command (requires the password) or via the ERASE command (does not require the password). Unfortunately, tools that support the LOCK, UNLOCK, and ERASE commands are essentially non-existent on Windows and (as far as I know) Linux.

2. The "special" card required is really just "fast" (can sustain a reasonable number of reads/writes per second) and "reliable" (properly implements the SD card spec and doesn't glitch out too often). The SD card's "class" doesn't matter here, as the class essentially measures how quickly an SD card can carry out a single large read/write operation, while phone performance depends more on how quickly the card can carry out a large number of small read/write operations. Microsoft tested a bunch of SD cards from a bunch of different vendors and found exactly one that met the minimum reliability and performance requirements. This is now the "approved" SD card. It is a class 2 card, which means it isn't particularly great at saving big JPGs, but it had much better random I/O scores than anything else that was tested. Microsoft doesn't sell this card and as far as I know has no financial interest in the sale of the card. Any card that meets the reliability and speed requirements will work just fine in the phone -- the phone isn't programmed to look for anything special in the SD card.

3. The confusion here comes from the fact that the SD slot is supported in a Windows Phone as a way for the retailer of the phone to easily upgrade the storage without involving a soldering iron, not as a way to share files between the phone and other systems. Selling a Windows Phone with an SD slot is like selling a computer with an unused SATA RAID port -- the user can add storage without going back to the manufacturer, but most users aren't expected to add or remove their computer's hard drive on a daily basis.

You've over-simplified the problem and created a false dichotomy. There are many solutions that are more secure than plain-text. It's not a binary decision. You are correct in that you can't get perfect security, but that doesn't mean you can't do better than plain-text. Perfect is the enemy of good.

First, while you cannot achieve true security through obfuscation, you can certainly improve your odds. If I steal a computer and scan cookies and documents looking for passwords, I'm more likely to find and use passwords stored in plaintext than I am to find passwords stored with some kind of reversible encryption. Sure, anybody who knows the details of my app will be able to get the passwords, but that doesn't mean I have to make it obvious and advertise the password data -- make it hard for them, and you'll probably stop 99% of the attacks.

Second, there are often operating system features for storing secure data. The data can be encrypted using the user's password, which is stored in kernel memory on the running system, but is not directly stored on the hard disk (the hard disk stores a hash, not the password itself). Your application can ask the OS to store a secret value, and later you can ask for that value back again. The OS will only be able to give you back the original value if the user is logged on with a correct password. (The OS handles re-encrypting the necessary keys each time the user's password changes.) In Windows, you use the CryptProtectData function. I'm not as familiar with other OS APIs, but I'm sure there are similar APIs on other systems. Not available in restricted scenarios (hard to do this from JavaScript running in the browser), but you should take advantage of the facility if you can.

Finally, if you own both ends of the system (client and server), you can provide challenge/response security that can be pretty strong by using hashes and public/private keys. This is harder, but you can get good security this way. Even in JavaScript.

Part of the security for an application can be attributed to the underlying platfom. It is very difficult to write a secure application on a operating system that doesn't require a user to log-on to access all files on the system. On such a system, anybody who can access a terminal can compromise any unencrypted data from any application, and the application developer must work that much harder to secure the data. On the other hand, on an operating system that has log-in and protects files from access by unauthorized users, an application can store per-user sensitive data in a per-user folder and the data is secure from unauthenticated access.

Of course, physical access trumps log-on access controls (if you can steal the hard drive or get the system to boot into an environment that you control, you can bypass the filesystem security). OS features such as whole-disk encryption can help in this scenario, once again making the application developer's job easier by providing a secure-by-default platform.

For Desktop PCs, such encryption is still somewhat optional. If you can provide physical security (lock your house), you don't need data security (encrypt your hard drive) quite as much.

With a mobile device such as a laptop or smartphone, this kind of encryption is very important. If the data on a smartphone can be accessed without logging in, then somebody just needs to steal your phone to access your data. Phones are stolen all the time, so plaintext data on a smartphone is a serious security problem.

Some smartphones have a nifty feature that allows you to treat the phone as a mass storage device. Unfortunately, this feature can be a serious liability if it allows somebody to access data on the phone without going through the OS's filesystem security. Phones that have this feature are more usable, but developers writing apps for this kind of phone need to do more work to ensure that their applications are secure. Applications on phones that don't allow such access are secure by default.

Some phones allow you to store data on an SD card, then remove the card and insert it into another system to read the data. Again, this is a very useful feature, but it can also be a serious security hole if there is any sensitive data on that SD card. Once again, if the phone has this feature, the application developer needs to take additional precautions to ensure that no sensitive information is stored on the SD card.

Some phones encrypt all data stored on the SD card. This renders the SD card useless as removable storage, but it means that sensitive data stored on the SD card is less likely to be revealed if the phone is stolen.

Bottom line is that the design of the smartphone platform (including the platform's limitations) have a lot to do with the security of the applications. I have no trouble believing that the same dumb developer might write the same app for two different platforms and the resulting app might be totally secure on one platform and totally insecure on the other, simply because of differences in the operating system design.

There are several different limitations in effect. Each of them may or may not apply, depending on specific circumstances.

- Number of address pins on the CPU or socket: 8088 had 20, limiting it to 1MB; 80386 had 24, limiting it to 16 MB; Pentium had 32, limiting it to 4 GB; Pentium Pro had 36, limiting it to 64 GB; ...

- Number of address lines on the motherboard: many motherboards (especially laptops) only connect the low 32 address lines, limiting them to 4 GB.

- Chipset memory support: chipsets may limit the size and quantity the memory module, i.e. max 4 memory modules, cannot support modules larger than 512MB.

- Device requirements: Memory-mapped devices (like video cards) usually need to be mapped to an address below some limit. On 8088, the range from 640k-1MB was reserved and couldn't be used for RAM. In PCI, the mapping is more flexible, so address ranges are only reserved if there is actually a device that needs the range. Instead of reserving the range, the device "shadows" the memory at that range (if any). This is usually in the 3GB to 4GB range.

- Chipset remapping support: Memory that is "shadowed" cannot be accessed at its "natural" address. If the motherboard does not support remapping, shadowed memory is inaccessible and wasted. If the motherboard does support remapping, shadowed memory can be remapped to some other address, usually somewhere above 4GB.

- OS PAE support: To access memory above the 4GB limit from a 32-bit CPU, the OS must put the CPU into PAE mode. All modern OSes support this. 32-bit Windows will run in PAE mode if you've enabled "Data Execution Prevention", whether or not you have more than 4GB of memory. (This is not an issue for a 64-bit operating system -- there is no need for PAE if the chip is running in 64-bit mode.)

- Driver support: DMA transfers to PCI devices only work with addresses below 4GB. Drivers must be designed to special-case any requests to transfer data to/from addresses above 4GB (usually done by allocating a temporary buffer below 4GB and copying the data to the temporary buffer). Systems that use drivers that aren't high-address-aware must avoid using physical addresses above 4GB.

- Application support: A 32-bit application can directly access no more than 4GB of address space, some of which will be reserved for use by the operating system. There are workarounds that enable indirect access to more RAM, or the application can be recompiled as a 64-bit application.

- OS edition limitation: Commercial OSes often artificially limit RAM usage for various reasons including edition differentiation and driver compatibility.

The 4GB limitation on consumer editions of Windows is due to driver compatibility issues. (Note that this is a limit on physical address size, not a limit on the amount of memory.) Microsoft originally placed a completely artificial 8GB limit on the amount of memory available to consumer editions of XP (for edition differentiation reasons only). However, driver problems appeared on systems that used addresses above the 4GB limit, so Microsoft changed this to a 4GB address limit (not a 4GB memory limit!) to improve stability on consumer systems (and reduce support calls). This limit is not present on server systems, since Microsoft assumes that server administrators will use higher-quality hardware and/or drivers. Cheaper editions of the server OS do have artificial memory limits (i.e. 16GB). The most expensive edition of the 32-bit server OS has no artificial limit and can access the full 64GB exposed by 36-bit PAE.

64-bit systems also have limits. As far as I know, the 192GB limit is entirely artificial - if you need more memory than that, Microsoft probably figures you should buy one of the server editions of Windows. The 1TB limit on the server edition is probably based on test limits - Microsoft doesn't want to support something it hasn't tested. However, even with a 64-bit edition of Windows, you may still be limited (i.e. my old laptop only had 32 address lines wired, so it couldn't access more than 3.2GB of RAM even on a 64-bit edition of Windows). Depending on the chip, there may also be hardware-based CPU limitations of 64GB (early Intel ia64), 1TB (early AMD amd64), 256TB (current amd64 and ia64), etc.

This is called "fraud". Look it up. It's been around for a long time, a lot longer than HTTP. There are standard business practices for dealing with it. Not all of them are technical. This system's technical defenses are probably sufficient to raise an alarm (delayed by a few weeks as the results are collated), and it will produce a pretty good paper trail leading to the owner of the Bing account. Some of the systems take into account minor details such as the existence of accountants, a police force, a paper trail, and a legal system. Obviously some stronger technical measures might have made it a bit more difficult to pull off this partucular fraud, or maybe it might have even stopped it, but the non-technical measures will also work just fine if they are called into play.

Whether or not the door is obviously guarded, it's still illegal to steal stuff from a store. The fact that the door was not protected with the latest and greatest in RFID theft detection systems doesn't change the fact that what you are doing is illegal. And perhaps the tracking process is slower than what you see in movies, people still get tracked down and arrested, days or weeks after the event. Moving from the streets onto the Internet doesn't really change the rules much (except that your case will probably wind up with Federal jurisdiction).

In this case, the poor "hacker" (I wish him/her luck!) appears to have done the following:
1. Used a specially formatted HTTP request to get a small fabricated purchase to show up as credited to his/her Bing account.
2. Noticed that the cash back did show up with no problem as "available for withdrawal".
3. Tried again with a much larger purchase. Again the purchase shows up in his account.
4. Hacker is hoping that the amount will soon become available for withdrawal.

On the other side of the world, the accounting systems for Microsoft and the associated merchant have likely compared invoices and noticed the discrepancies. The small ones got noted, but they were thrown out as "somebody is playing with the system, but it's not worth dealing with it". But this month, when going over the books, they're going to find a nice big 100,000 item that doesn't match up with any purchase recorded on the store's official records. However, they do have the account number of the buyer that should be getting the cash back. I'm not sure what typically happens at this point, but it probably involves cancelling dinner for the wolf pack so that by the time they're ready to send out the posse, the wolves are hungry.

In this case, Microsoft has apparently (I haven't looked into this) provided an API by which a store can report a sale and attribute the sale to a particular Bing account. The API has varying levels of security, depending on how much effort the store wants to put into preventing fake transactions from entering the system. Low effort might be fine and takes less time to set up, but it's easier to attack and that means more work to do when reconciling the accounts. Just like many other mechanisms for quickly distributing non-critical information between merchants, this isn't meant to be the authoritative information transmission system, just a way for people to keep status on accounts in between the regularly-scheduled account reconciliations. This way Bing can update your account balance within seconds of the purchase. Of course, the payback won't happen until they've gone back and checked Microsoft's records against the merchant's records and pulled out any differences. The differences go to the auditor and possibly to the police or FBI.

Could we maybe just think for a second before acting like jerks? Being a jerk means everybody suffers. I mean, just because I see a way to deface somebody's website doesn't mean I am obligated to do so. I walk by 100 cars a day, and I could easily spray shaving cream all over them and not get caught. But if everybody did that, quality of life would go down for everybody. Same thing on the internet.

I hate this attitude out there that "if it isn't nailed down, I have every right to grab it and take it home, and if it is nailed down, I have every right to destroy it". I don't want a world (or even an Internet) where everything is nailed down and/or destroyed. I like being able to sit down on the occasional park bench. I like seeing the quick web sites put up by some teenagers to show off whatever crazy idea has their attention this week. It would be a pity for the park bench to be vandalized "just because it wasn't properly secured -- to teach those guys a lesson!", because then the park would have to hire security guards (paid for by my taxes) or close down. And simple kiddie web sites about cute kittens shouldn't become defaced just because they were using a version of Drupal that they didn't know how to lock down.

In my sister's neighborhood, people actually know each other and are friendly, but there have been some break-ins the past few weeks. That just plain shouldn't happen -- it causes real harm to people. But when my sister saw that a neighbor had left the garage door open, she called the neighbor and the problem was solved. I'm not sure what the problem was -- perhaps the door was closed immediately, or maybe it was open for a reason (people were in the garage working, or there was nothing in the garage to steal, or the police were baiting the people who had been breaking in). But the problem didn't have to be resolved by stealing stuff out of the garage as a "proof of concept".

Certainly security ought to be part of our thinking as we develop and deploy software. I don't want my mom's computer to get screwed up by the next big virus (though Vista's UAC has been doing its job pretty well so far for her). But honesty and responsability should guide our thinking as we use software. And just as we have to learn that there are non-technical attack vectors (75% success rate for "I'll give you a candy bar if you give me your password"), we shouldn't be so narrow-minded as to think that there are no non-technical mitigations (the inevitable paper trail and the criminal justice system help keep me from trying to scam Bing, just in case my personal code of honor should somehow fail).