Great to see the site being positively received. :-)
This instant deposit feature is great, but you might want to wait until the funds clear before letting people withdraw it back out again.
I thought this wouldn't be an issue, but I'm not so sure anymore. I use the "account" feature of bitcoind and every wallet has its own account. My understanding was, that this will mean that the coins being sent are limited to the account as well. In that case it doesn't matter if the funds end up not confirming, because it will also invalidate the withdraw transaction. But maybe bitcoind uses coins from other accounts as well sometimes? Has someone here more insight into this?
Interesting question, I'm not sure. The balance is whatever the method "getbalance
0" (so minconf=0) will return. I have no idea if this is the case for these pool transactions.
Where are the wallet files kept?
who has access to the physical equipment that the wallets are stored on?
What kind of encryption does instawallet use?
can we see the source code?
Sorry if any/all of these are answered somewhere on the site, but I can't find it yet.
One of the next things I will add is some sort of FAQ list that will address these things. For now: the wallet is on a VPS, running Debian Squeeze on an un-encrypted file system. So my VPS host prgmr.com technically has access and of course I do. Besides SSL there is no encryption used, but the regular backups I will make will be encrypted. I haven't decided about the source code, so for now it remains closed.
In any case: This isn't really the place to store your Bitcoin wealth! I will try my best in keeping the service stable and secure, but ultimately I want to see mostly Bitcents on these wallets. A lot needs to happen before I would trust a cloud service with a larger amount of Bitcoin to store over longer time and Instawallet is definitely not the place to do that.
Yeah, this seems rather nifty, but I'd want a lot more details about how the unique URL is generated, what protections there are against people trying to brute-force URLs to stumble upon money, and how the server/wallets are secured before using it for anything serious.
The URL contains 16 bytes of random data. I hope an attacker will do the math before wasting his and my bandwidth. Right now there isn't any sophisticated throttling implemented. Let's see how long until I have to deal with some trouble maker.
My only suggestion would be a "copy to clipboard" icon/link next to the funding address
Thx for the idea, I will consider implementing that!
It's not specifically supported, but yes, it works at the moment and you are free to make up your own wallet URL.
1. Did you address the possibility of cross-site request forgery?
Maybe not to its full extend. You need to provide the wallet identifier when making a payment, but maybe this could be scripted with JavaScript after being redirect to the wallet URL? I will tighten up security in this area, thx for the pointer. Again, I don't recommend people to store large amounts of money there, so that CSRF would be worthwhile, but of course I appreciate the trust in the service if someone ends up doing it anyway.
2. Though the standard is somewhat vague, the traditional interpretation of RFC 2616 is that Referrer: headers are permitted from HTTPS content as long as the target uses SSL as well. I don't know offhand how each different modern browser reacts by default, but I disagree with Theymos that it's not a concern in general.
2a. To address this issue partly, it would be fairly easy to continue to permit pages to be accessed using an address in the URL but to redirect the user immediately to a page that doesn't include it there, either storing it in the session or including it as a hidden form parameter.
It seems you are correct, that referrer is transferred when linking to another SSL site. I will have to think about this, but as I don't have outgoing SSL links, it should be fine at the moment. Redirecting in the way you describe would be an option, but I'm not sure I like it much. I consider seeing your actual wallet link in the address bar a usability feature.
4. Are the addresses generated using a secure PRNG? If it's an ordinary PRNG, it wouldn't be hard to guess addresses.
What is an "ordinary PRNG" for you? I use Python's os.urandom() which I would consider pretty "ordinary", but I have checked the documentation which claims that it returns "random bytes suitable for cryptographic use". 
I worry what your wallet data looks like after I tried a bunch of random urls and they all worked. Sorry about that. 
