tarnacious_

Significantly decreasing intergenerational mobility is very concerning. Especially for those who aren't wealthy already.

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?

I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch.

I find this simpler and cleaner than introducing a series of merge commits in my local branch.

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.

It's not "better". It's a hosted alternative.

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.

> Interface looks cool

Thanks, glad you think so :)

> what benefits are there over using mitmproxy?

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).