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

What if Zuckerberg had received a cease and desist letter when he was accessing computers without authorization at Harvard?

Before any student willingly sent him personal information, he had to exfiltrate such information i.e. photos of other students so other students would be compelled to look at websites he created using said photos.

He did eventually receive a cease and desist letter, and he ignored it. But of course it was not from the people charged with protecting students' personal information nor the students themselves. You know the story.

As with Google, under today's culture it's acceptable for Facebook to aggressively collect personal information in bulk and pay little attention to obtaining permissions, but it is not acceptable for anyone to attempt to collect information in bulk from Google or Facebook. This make no sense to me, but I gues I am just obtuse.

Maybe what Kerr is wondering is when the necessity of sending costly snail mail cease and desist letters will give way to some less expensive digital form of notice. When that happens, the threat of the CFAA can be used on a mass scale. Perhaps then we would see it in every Terms of Service. Maybe we could create a new HTTP response code: HTTP/1.1 606 CFAA Notice.

Good.

"For instance it doesn't have everything you need to validate certificates..."

Yet it has all the CA crap thrown in, via the overloaded openssl binary. As "examples". And according to the documentation, not even "correct" illustrations of how libssl should be used.

Encryption and authentication are two separate problems.

Just because you figured out a way to encrypt a message does not mean you have also figured out how to a way to send it to only the correct recipient... over an insecure network. (Insecure not only in the sense of "plaintext" but in the sense you are not in control of much of anything - routing, PKI infrastructure, etc.)

It seems to me that one would want to solve the authentication problem first, and then move on to encryption.

This comment shows that for proponents of using SSL on the public web, it's been the other way around. Authentication was never sorted out.

When it comes to authentication, all due respect to the OpenSSL authors, SSH has provided a better attempt at a solution than any implementation of PKI using SSL/TLS.

And one more thing, how many ciphers does a user really need? As we've heard time and again, many of them are not even "safe" to use. Some of the alternative SSL libraries have wisely removed them. But I guess OpenSSL is append only?

I guess the way to test your theory would be to look at users who had IRC to use and nothing else -- no choice.

The truth I believe is that users adapt to whatever software they must use.

Before the "UI/UX" hype began, before there was Javascript, a long time ago, not as many people had to use computers. It was optional. Many people were computer illiterate and it had little to no impact on their life.

Now today, we all know that users no longer have to learn about the command line or configuration files. Everything has been made very easy to fall into. Click or touch an area of a screen and something happens. Great.

But... what I see many commenters fail to recognize is that the increase in computer usage since those times has little to do with interfaces and everything to do with the need for everyone in a civilized society to use computers. Because today computers and computer networks are much more powerful, and more useful. They have become a necessary part of everyday life for the civilized world.

No one in these societies can claim computer illiteracy anymore.

So users learn what they have to in order to get by. This was the same in the 1990's as it is today. Today the amount of learning required to use a computer is almost nil.

But if a user, whether in 1992 or in 2016, had to use a computer out of necessity, and the commmand line was the only way to control the computer, you can bet they would learn it. Technical ability nothwithstanding.

I have seen this with my own eyes. A lot of the talk about what users want and don't want, or what they will and will not do is all in the mind of the developer.

The truth is people today are forced to use computers. They'll use what they are given. And no user is ever forced to learn to use the command line in order to use (be used by) a computer.

But if today's users were forced, they could do it. And they would do it because use of a computer has become a necessity.

Also, people born after 1993 have no fear of computers. They'll learn anything that is put in front of them. It just so happens that what is put before them is a boatload of "UI/UX" hype. They take the bait - hook, line and sinker. No surprise.

Computer usage has changed since the birth of IRC but it has nothing to do with "UI/UX". There was a time when people in the civilized world could abstain from using a computer; that time has passed.

Agree. Legacy code.

You missed the point. The comment suggests the opposite of what you think it suggests. I guess I need to work on my communication skills.

The following comment could apply to hundreds of similar submissions to HN in recent years.

Many people -- many of them young people I suspect -- have invested a lot of time learning Javascript. It has become a very popular language.

But it remains to be seen whether Javascript will be as long lasting as the UNIX shell and standard utilties. Historically speaking, computer languages have been known to fall into and out of popular usage.

For people who invested a lot of time learning the shell and ubiquitous utilties such as AWK, it appears the investment has paid off. I'm not too worried about the terminal disappearing any time soon.

How long until the next submission that aims to abtract away the need to learn how to use a UNIX terminal -- directly.

There are probably hundreds more on Github alone. What if we conslidated them all in one place: 1001 attempts to abstract away the need to learn UNIX.

By no means am I suggesting these attempts have not been successful.

What I'm suggesting is that the need for them will not abate. It could be that UNIX terminals, and programs like AWK, are not just a fad.

Was Kildall a better programmer than Gates?^U

Who wrote more elegant software?

Who undercut the price of the other's software? And why?

Microsoft's early success was not due to originality.

Gates has no aesthetic. He has no respectable standard of quality.

Does anyone remember "Microsoft Bob"?

He may be worthy of respect by less capable programmers. He may be worthy of respect by the business community. He may be worthy of respect for his philanthropic efforts.

But for software users who have any insight into and appreciation of software quality, he has yet to earn any respect. For these users, he has only impeded progress. And Microsoft continues this tradition to this day.

It is perfectly OK to critique him on this particular point.

[Original title was something like "Gates wrote this beauty at four in the morning."]

Users should have the option of choosing or not choosing to use a locked bootloader. For some users, the benefits of an unlocked bootloader exceed the costs of not letting Microsoft handle "security" for them.

If a company is selling hardware, why should it matter what the purchaser does with it afterwards?

For the answer to that question, we might ask Apple.

Whatever the answer is, it is certainly not "for the security of the user" if the user explicitly wants to install their own choice of OS.

"a project that doesn't care about your concerns..."

Unless the concerns are always "more features"... forever. Any new features will do, so long as the project keeps growing. The more changes and updates the better.

I could put Microsoft Windows in this category along with hundreds of other projects. Chrome is deceptive because it has some useful features... but ultimately this browser is the tool of advertisers. Because they are the only hand that feeds the Google.

These folks are not aligned with my concerns. They cannot be. It is a conflict if interest. Will Chrome use my DNS server instead of Google's? Why should it? It's not my browser to control.

At one point the Googlers put a resolver into Chromium. I think they removed it but just the idea they considered this was enough to scare me away permanently.

I enjoyed the spongeboat analogy. One can use a patched alternative. One can write extension after extension to modify default behaviour. At some point it becomes a losing battle and a waste of time. The browser is designed and maintained by an advertising company.

Avoiding mothership home-calling is a wonderful way to navigate a world with too many software choices. It makes choosing software much easier. Because not many projects today consider home-calling a legitimate concern.

When you do find a project that fits your values, that you know will not change to suit advertisers, it can be a software you can stick with as things and times change. At least this has been my experience.

Question: To whom do you want to send mail with your "bonded email server"?

Is it commercial email?

Or are you just interested in sending email to friends and family?

In the case it's both, which one is more important to you?

Before UNIX was ported to the PC, I used a DOS program called Crosstalk Communicator.

Today it's so easy to run a small UNIX kernel on a PC.

Why would "industrial control areas" still be using Windows, if what they need is terminal emulation? Tradition? Windows-only software?

Windows on a networked computer sounds like a potential security hazard in such places.

Maybe they can get the domain name through UDRP.

Or allow Googlebot in robots.txt and then crawl Google.

An ISP will block ports -- the goal is top stop spam -- but nothing requires you to use the traditional SMTP ports that are used for spam. Because you're not sending spam.

You are sending email to people you know, on a port you have agreed to, who also have reachable IP addresses and will accept connections from your IP address.

ISP's are not going to do DPI on open ports like 22, 80, or 443 or any high port, in order to filter out SMTP traffic. Why would they bother?

If you must use the existing "email provider" system -- e.g., you need to send commercial email -- then you must use the standardized ports they use, and yes, you must jump through their hoops. And you will experience spam and other nuisances. It's supposed to be open and decnetralized, but the reality is it's quite centralized because everyone relies on "major email providers".

But there's nothing about SMTP protocol that requires anyone to use an "email provider" or any specific port, nor to accept email from all IP addresses.

Two people can communicate directly via SMTP on a non-standard port and can choose to filter by IP address.

Maybe no one does this anymore, but I've done it; it's possible.

It's not that difficult to set up. The showstopper is not the set up, nor the ISP filtering port 25. It's that most people do not have a reachable IP address.

And to serve that private gTLD to others, you'll need a reachable IP address. :)

But if and how frequently such changes occur depends on the third party. And as you say, the terms should require adequate notice.

Businesses of all sizes rent stable IP addresses. Some ISPs in some countries also provide them to non-business subscribers as part of the standard subscription.

It's really not too difficult to have a persistent IP address for an individual who only needs reachability and is not trying to run a high traffic, global enterprise. Avoid the popular large, high-volume providers. Obviously do not use something like AWS.

"Email" as it is run today by third parties.

Email dates back to timesharing, when people shared computers, each user having an "email account" on a single computer.

For people today, each with their own computer, it's still possible to do email without store and forward, with each user running SMTP servers that talk directly to each other instead of connecting to "email providers".

This is grassroots. Not meant to leverage existing "email provider" ecosystem.