I understand bitcoin are traded like this but it doesn't address this issue the parent raises. Also if you are trading through an exchange like this you are likely exposed to even greater risks.
If you buy some bitcoin from an exchange and you don't get the bitcoin in an address you control, you are effectively buying an IOU for the bitcoin. The value of the IOU depends not only on the value of bitcoin but also on the exchanges willingness/ability to repay it.
If the exchange doesn't own a similar amount of bitcoins as they have sold IOUs, at the current market value they couldn't possibly repay the IOUs they issued a month ago. If a significant amount of people they have issued IOUs want to redeem them, then they will surely need to sell some bitcoins to repay the IOUs they have issued.
By using a futures market they could limit their exposure price changes when buying or selling coins they don't have, but these markets are quite young and it's certainly not clear how much risk these exchanges are exposing themselves to.
As you apparently understand this better than we do, what do you think will happen on these exchanges if the value of bitcoin starts falling rapidly?
WrapAPI looks neat. Thanks for posting the link, I couldn't find any similar services when we started building debugProxy, although I assumed some must exist.
Thanks! I figured (most) people were pretty fast and loose with their security these days, so that wasn't my concern. I've found the problem is that it still isn't easy to use, you still need to configure a proxy with credentials and install a root certificate to proxy HTTPS traffic. Lots of vistors to debugproxy today, not that many requests through proxy.
This is a good comment and touches a lot of concerns I have with the service.
On debugProxy, username and password "sessions" are disabled after 20 minutes of inactivity. This was implemented, in part, to combat the issue of people forgetting they were still connected to the proxy.
Also, I don't want to, nor do I have a enough disk space to store things for long. So body data over 20 minutes old is periodically permanently removed. Header data lasts a bit longer, but is also periodically permanently removed.
This will not prevent users sending private credentials over the proxy, but it's hard to prevent that as you say, so hopefully this mitigates the problem a bit.
Of course you still have to trust the service, for some people that will be totally unacceptable, which is fine.
Hi John, thanks for the offer. I might take you up on that and email you in coming days.
I learned of Runscope some time after I started building this, it looks very interesting.
I too have doubts a proxy service like debugproxy will be very successful as it is, mostly because using it is still very difficult and in some cases not possible on various devices (buggy proxy implementations on early iPhones, Android 7 not allowing root certificates to be added etc..)
I figured there are some other cool things you can do with a proxy though that might be interesting. For example getting remote debugging working smoothly by injecting a script into HTML pages sent through the proxy. Or going the other way and proxy existing websites through a sub-domain of debugproxy.com, which I used to do to demonstrate changes to clients websites.
I'll see what feedback I get in the coming weeks and decide what to do, if anything, from there.
Thanks for the link. I couldn't find any services offering this when we started building debugProxy. It's good to see there might be a viable business model here :)
This is my thoughts too. I wouldn't think it is very useful to most mitmproxy/fiddler/charles power users.
But not having to install something, find your IP address, open your firewall etc, allows some users who don't want to do all this to start using a debugging proxy without having to. I'm not sure how many of these users exist though, we will see!
This will prevent decryption. In cases where you are debugging your own modern SSL pinned apps, you can add the debugproxy root certificate in development / testing builds.
With mitmproxy you can do almost everything you can do with debugProxy and a lot more.
The main benefit is you don't need to install anything. Also you can proxy requests from clients outside your local network (if you are behind a NAT router, for example).
> So, when I use your proxy you can see and store my http and https traffic (assuming I install the certificate in my device).
Yes. Requests more than 20 minutes old are permanently deleted.
> Furthermore, all the traffic from the my pc to your proxy is also transmitted unencrypted so everyone who sits between my device and your proxy can see my traffic as well.
No, if you make HTTPS requests they are tunneled over TLS.
> While this interface looks really cool and it is probably feature rich,
Thanks. It isn't feature rich though, it's quite minimal.
> If anyone is interested in a local http(a) proxy, check out mitmproxy[0] which is open source, runs locally and is easy to install (I’m not affiliated with them, i use use mitmproxy occasionally when Reverse Engineering am API).
mitmproxy is indeed great, in fact, this service is build on mitmproxy instances :)
This is side project I have been working on with a friend. It's a pretty niche service, so it isn't easy finding people to try it. I'm really interested to hear what you think, for better or worse :) I'm also happy to answer any questions.
With regard to Australia; in 2013 there was a parliamentary inquiry into IT pricing entitled "At what cost? IT pricing and the Australia tax". The report can be found here, on the Parliament of Australia website.
I don't think # or // for comments is a very good idea as it would also make newline characters significant. I find it useful to be able store a JSON object per-line.
> It is very irresponsible to make statements like that.
I don't think so. It is irresponsible to suggest that you can secure a server you don't physically control. Full disk encryption doesn't protect your disk if someone can take a memory dump of the machine. Using sshd in an initramfs to receive the passphrase for an encrypted rootfs doesn't help if someone can modify the initramfs and wait for a the passphrase.
Encrypting your volumes does provide some security, but having to SSH into an initramfs to unlock the root partition has its own problems.
Encrypting data on a VPS, for example using LUKS encrypted volumes, does not provide any meaningful security if the host can take a memory dump of the running machine.