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.

A merge should always be done by rebasing the to-be-merged material onto the target-of-merge branch. This way not only is the history linear (and thus understandable, rather than some indecipherable "git log --graph" ball of yarn) but the individual changes are properly re-worked to fit into the target.

When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.

I believe a fork of git should be made which entirely eliminates the concept of multiple parents from the representation of a commit. In the same breath, it would drop support for git merge and git log --graph.

If you have root access, you can [1]. You can also build your own apps to trust the "user" certificates [2].

[1]: https://blog.jeroenhd.nl/article/android-7-nougat-and-certif...

[2]: https://android-developers.googleblog.com/2016/07/changes-to...

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.

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

There might be, but our experiences running our original product[0] are contrary to that. Happy to chat about it if you’d like.

[0]: https://www.runscope.com/docs/debugging

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.

Email is in the profile if you ever want to chat

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.