*Via a double spend attack with careful selection of peer connections and precise timing
However, with brick and mortar stores, 0-confirmations transactions are much more problematic for the business. The customer could be long gone with your product by the time you notice the double-spend. OTOH, the 10 minutes delay is also much more problematic for the customer with physical stores (imagine a customer having to wait for 10 minutes to buy a pack of gum).
One interesting solution for making zero-confirmations safer to accept is fidelity bonds [1], where you would "sacrifice" some Bitcoins from your address, a sort of "safe deposit" that you never get back. From that point on, until that address is seen to commit a double-spend, merchants can accept zero-confirmation payments from it knowing that attempting to double-spend would make the customer's initial deposit invalidated. As long as the deposit is larger than the transaction amount, it'll make double-spending unprofitable.
Edit: Another interesting aspect is that fidelity bonds can also be used to make other kinds of fraud unprofitable, not only double-spending. However, while its easy to determine when a user committed a double-spend attack (just show two signed transactions paying the same coins to two different places), its not that straight forward to prove other kinds of fraud.
[1] https://en.bitcoin.it/wiki/Fidelity_bonds#Financial_Services
However, I suspect you understand these issues better than I, so I'd love to hear your input on these alternatives and why you think Fidelity bonds are the most likely solution that will be adopted.
I think that fidelity bonds are in fact a decentralized solution for green addresses.
With traditional green addresses, you would have to use 3rd party services to prove you're honest. Those services would have to charge fees in order to operate.
With fidelity bonds, you would prove you're going to be honest by making it unprofitable to act otherwise. This doesn't require a trusted party, should be much cheaper for users in the long run, and imho a much more elegant solution.
"However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster." - https://bitcointalk.org/index.php?topic=251233.msg2669189#ms...
In English, if you want to reverse a transaction, IE cancel a payment, the most you can steal from the person you paid is the value of the transaction itself. But if we implement a system where you can change a transaction after the fact, sending more of the fees to miners, the merchant can always outbid you, so it's almost impossible to actually get away with the theft and gain anything. You'll still pay for whatever you stole, thus turning what was a profitable attack, into a unprofitable attack that at best is simple vandalism. Namecheap isn't going to care much if a thief lost $10 when their loss was at most a $0.17 registrar fee.
Disclaimer: I'm working on implementing this feature in Bitcoin, although it's John Dillon's idea.
That site isn't great because it's tricky to hit the two submit buttons in succession, but a fairly trivial script can do the same thing without much difficulty.
The reason why you don't hear about it is in reality there pretty much aren't any services out there that are actually vulnerable to that kind of double-spend in a way that results in genuine financial loss. Aside from some rare exceptions everyone accepting zero-conf transactions are either selling something that can be recalled after the fact, (tell the shipping department to stop) or has zero marginal cost. (like mp3s)