__b__

There's another solution: Avoid closed source applications and closed source OS.

There's other OS besides the ones you mentioned. And there's other small form factor computers besides mobile "phones" sold by telecom companies.

"What android is doing is making MITMing yourself harder."

That's not good for users.

I do not rely on Android, Windows or Linux. Not really much an app user either.

But if I were a user of these systems I would avoid apps where the user is not allowed to see what is being sent. Irrespective of any justifications put forth. By a company that relies on collecting personal information and selling advertising to make money.

"... it won't change a thing."

So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it?

And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so?

Does the user have control of the process of "trust" or not? The entire point of the device, OS and apps is to benefit the user, not some third party trying to hide data being sent from the device... from the user.

Do you believe a user should be able to "MITM" her own traffic or not?

Any device that prevents a user from installing their own CA root cert is not one I would use. I'm not sure if they have started to do this or not.

In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust.

It would be like if SSH did not allow the user any control over known_hosts or to decide that she will accept or not accept a connection.

Imagine if they had tried this with their corporate customers.

My advice to home users would be to disconnect their Windows computers from the internet and use some other OS for tasks that require internet. Use Windows offline for the graphical tasks that Microsoft was founded on.

I remember the days before Windows had a TCP/IP stack. Gates did not see the point in the internet or www immediately. UNIX computers were connected over the phone lines. Windows computers were not. Gates eventually woke up and MS copied the TCP/IP code they needed from BSD. The rest is history. Look at them now.

One should not need an internet connection to run Excel and create spreadsheets. If one needs to send a spreadsheet to some remote computer, there are other operating systems that can do that. Such as the one from which Microsoft copied the TCP/IP stack.

The parent stated "Data generated on my phone belongs to me."

I interpreted this as "Data generated by me on my phone belongs to me."

The user could agree to license her rights to the data, e.g. via terms and conditions. But it's still her data. That's why the agreement is necessary.

None of this has anything to do with "reverse engineering".

The scenario I am thinking of is a user looking at her data being sent from her hardware over an internet connection that she is paying for.

"I should be able to see what data an app is sending..."

And you can. There are many ways. Something as simple as 2 socat instances and netsed works great as a quick and dirty but very robust solution. See also sslsplit which will generate certificates on the fly.

Anyone who is telling you that you can place complete trust in the use of x509 certificates on the open internet is either naive or dishonest.

I think you have the right attitude.

OK, then how do we separate the data that is his versus data that belongs to somene else? Maybe we would have to look at what is being sent from the app?

I have always liked the download.gmane.org option. I rarely use the web interface. I hope download.gmane.org does not disappear. Gmane is a truly great service. IMO, it does not need to be part of "the web". It's better than that. It's part of "the internet". One of the best parts.

Like AOL. Yes, I agree!

Any similar projects aimed at compiling Linux binaries on non-Linux Unix? (Excluding qemu, etc.)

Some non-Linux Unix have Linux emulation and can translate a subset of Linux syscalls. Perhaps it could be in a chroot with all the needed Linux libraries and utils.

But I am curious if there have been existing projects aimed at this goal.