Misunderstanding Computers

Why do we insist on seeing the computer as a magic box for controlling other people?
人はどうしてコンピュータを、人を制する魔法の箱として考えたいのですか?
Why do we want so much to control others when we won't control ourselves?
どうしてそれほど、自分を制しないのに、人をコントロールしたいのですか?

Computer memory is just fancy paper, CPUs are just fancy pens with fancy erasers, and the network is just a fancy backyard fence.
コンピュータの記憶というものはただ改良した紙ですし、CPU 何て特長ある筆に特殊の消しゴムがついたものにすぎないし、ネットワークそのものは裏庭の塀が少し拡大されたものぐらいです。

(original post/元の投稿 -- defining computers site/コンピュータを定義しようのサイト)

Wednesday, May 1, 2019

Analyzing Mechanized Trust

So people have told you about the GIMP or Krita or one of hundreds of "free" programs you can download on the web, and you think, maybe you ought to try them, but you don't know if you can really trust them. After all, installing free software was the proximate cause, as the tech said, the last time you had to have your PC's OS cleaned of malware and such.

So, can you tell which ones you can trust and which ones you can't?

How can you tell?


It comes down to trust.

You've heard a lot about HTTPS recently, how it is supposed to guard you from all the bad guys. But you're not sure how that works.

And Microsoft and Intel talk about their "Trusted Computing" or whatever that is, and yet they still have to update stuff about twice a month because of vulnerabilities and such. And the downloads take a long time. And you're not sure how that works either, how they guard your computer from fake updates and such.

Well, I tend to recommend free and open source software to people, too, so I should try to explain how some of this works.

First, HTTP vs. HTTPS:

HTTP is a little like somebody sets up a booth on side of the road and sells stuff. You have no proof they are who they claim to be or that the merchandise they sell is legitimate or that they have it legitimately, etc.

If they have a regular building, it helps a little, but only about impressions. Proper buildings can hide bad stuff happening inside.

But if they show their business license from the city, you can assume that either the license is fake or they have identified themselves to the city sufficiently to get the license. And if they have a technical certification, you can assume either the certificate is fake or they have passed some sort of course or test of certification. And so forth.

(Those certificates say something, and it is usually better than saying nothing, but we can't be sure just from the certificate exactly what it means. But we'll get back to that.)

HTTPS uses what are called asymmetric encryption methods to show their digital certificates to your browser, and your browser uses similar technology to check that the certificates have been issued by who they say they have been issued by. There are two keys involved, one for encrypting and one for decrypting. Keep one secret and make the other public, and people can tell that a person who has the secret key has encrypted a document or used it to calculate something called a checksum and to make a digital signature, perhaps with a digital fingerprint.

The checksum can be used to make sure that you get a complete, accurate, correct copy, and the fingerprint, signature, and checksum together can be used to make sure that the person who put it up for you to download is the person he or she claims to be.

HTTPS uses these techniques to make sure that the person or company who manages or admins the website you are visiting is the person or company claimed. Your browser has certificates from a bunch of certificate authorities (some more trustworthy than others), and the website usually refers to one of those certificate authorities, perhaps through a chain of references.

Secret keys can be discovered through carelessness, databases can be deliberated corrupted, etc., and there other ways of defeating the assurances, but they are difficult to pull off for very long without discovery. Rarely do they go undiscovered for more than a few weeks or a month.

The details are important, but not so important here. We need to talk about what the mechanisms of certification or assurance actually allow us to do, before we can turn this "mechanical trust" into a meaningful kind of trust. Let's look at an example:

Say, for instance, I recommend Cygwin for development tools, or the GIMP for working on images, or an operating system like Ubuntu or Devuan, or maybe the Gnupg tools for checking these digital signature and certificate thingies themselve.

Hmm. I recommend all of the above. Not because they can be used without money, by the way. If they help you make a profit, you do have a moral obligation to contribute to the projects, either with money or time, or preferably both. When you fail to contribute, that's one less person helping keep the proects running.

I recommend them for reasons of trust. They trust us enough to let us use what they have, and, more important, to let us look inside the "magic box", the source code for their software. They put their reputations on the line when they publish their stuff. That latter part gives us more reason to trust them.

But you need something like the Gnupg tools to check that the copy you get does not have malware inserted into it by some unrelated third party who doesn't care about your safety or their reputation, or maybe even wants to undermine your safety and/or destroy their reputation.

At this point, we need to distinguish between "random free download sites", on the one hand, and public repositories and their mirror sites, on the other.

A public repository is a site like osdn.jp (Open Source Developers' Network Japan) or sourceforge.net, both of which I have projets on, or github.com (very popular these days). They provide space for people like me who don't have the resources to maintain a server to host their own projects, and they provide various tools to help make sure the stuff we post there makes it through the download intact. They also provide things like project pages and means to provide checksums and signatures.

(Speaking of which, I need to start signing the stuff I put up in my projects. Right now they only have checksums.)

Random free download sites post blobs of dubious provenance. They generally fail to provide the tools to make sure that what they provide is safe, because part of their business model is to get you to download adware, which is one step short of malware.

Incidentally, sourceforge at one time was taken over by a bad management crew who started inserting dubious adware in many of the more prominent MSWindows downloads. The guys that started sourceforge were able to pool enough funds together to buy sourceforge back, and they have worked on cleaning out the adware infested downloads. But inactive projects are harder to clean out than active projects.

Also, any public repository gets part of the revenue that keeps them afloat from ads, and some advertisers deliberately try to look like legitimate downloads, so be careful what you click on. Patience is a virtue for many reasons.

Two more classes of sites I need to mention, mirror sites and stores.

Mirror sites are separate download sites provide by interested parties such as schools, public institutions, businesses, and such, to help support some of the larger projects by reducing the direct bandwidth burden on the project's primary servers or repositories. I've never seen ads there, and they basically mirror the public parts of each project they mirror, including checksums and signatures. They operate outside the question of trust by only hosting what the projects provide, unchanged. You have to check what you get from them, but that's not a problem because you have to check what you get from the project site itself, too.

Stores are kind of like a commercial re-visioning of repositories and mirrors oriented towards a particular device or family of devices (Google's playstore for Android, Apple's appstore for iPhones, etc., etc.). The company that provides the device makes the download procedure a bit more automatic and provides payment methods. (This is possible because they control the software on the device to a large extent.)

So, this has been an overview of the mechanisms of trust currently in use. What next? How do you convert mechanized trust into real trust?

Number one, patience. Diligent patience.

(Give them a little faith, but faith does not mean just instant belief.)

You do not want to download and install the latest, greatest, newest gadget the first day you hear about it. As I am hinting, patience is a major part of legitimate trust.

Looking for an allegory, the quickest ones that come to mind are human relations. Shaking hands is one thing. Going out to a movie is another. Accepting an invitation to a party is yet another. Friends that you trust are people you've known for a while, and you generally want to avoid committing yourself too far beyond your experience with a friend you haven't known very long.

So, say you think you might want to start using the GIMP. The first thing you should do is search for GIMP on your favorite search engine, and look at the stuff that comes up. You'll find a site that claims to be the official project site at gimp.org, and tutorials will point you to gimp.org and I'm pointing you to gimp.org. You have multiple witnesses that gimp.org is the official project site.

If you type
https://www.gimp.org
directly into your browser's URL field, you can eliminate some games sneaky types play with the displayed URLs. You really should keep that URL field out where you can type directly into it, separate from the search field. It's only a little inconvenient, and it keeps people from playing games with the displayed URL. (Browsers have done some things about protecting displayed URLs, but there are still ways to play those games.) That means, unless there is DNS poisoning, you'll go to gimp.org's servers, which is where you want to go.

Look around. Scan the front page. Don't download it yet Check the news, even though there will be things there that you may not understand. Read the About page a bit. Check out the Docs and Tutorials. Take a peek at Participate and Donate. Look around for about a half an hour. Wait a day or two.

A day or two later, come back and look at the front page again. If you scan down to the bottom of the front page, you'll see a link to the mailing lists. Take a look at the archives of the user and developer lists and read some of the messages there to get a feeling for the community. If you happen to pick a message from a person with a lousy attitude or bad mouth, remember, every good project will attract a few of those. Dont judge the whole project by a few hotheads.

(Truth be told, one of my favorite OSses is run by what seems sometimes to be a whole crew of such hotheads. That's kind of the nature of what they do. It took me more than a year to understand what's going on over there, but that's another story. Trust comes in a variety of shapes and forms.)

While you're here this time, or maybe the next time you visit, check out the download page. You'll notice a list of hashes. These are those checksums I've mentioned. When you download it, you'll want to check the hash against what you downloaded, but I'll tell you about that in a different post.

Check it out. Don't download just yet.

Visit the project main page and read and listen to tutorials several times before you decide to download. Read the wikipedia pages on the GIMP. Get background. That way you have a feel for the community and have some basis for making those trust mechanisms meaningful.

Speaking of the trust mechanisms, I mentioned a tool called GnuPG, up there. Do a web search on that in between looking at the GIMP. The project main page is
https://www.gnupg.org
but, again, look for what people say about it, look around their website, read the archives. This group may not feel as comfortable as the GIMP group for several reasons -- They use a specialized jargon, and they have to have a rather strict attitude about what they do.

You'll notice that they put a close focus on the "integrity check" processes. This is not your integrity, nor is it the integrity of the developers. This is one of those mechanical things. It's about whether something might have happened to the file between when the developers put it up for downloading and when it arrives in your computer. They use a lot of technical jargon, but you'll notice that they tell you not to use the program to check its own integrity.

You can understand why, can't you?

You: Do you have integrity?

The Software: Yeah! Sure!

You: Can I trust you?

The Software: Of COURSE!

I'll try to walk you through the integrity check -- through checking the hashes or checksums and the signatures in another post. [JMR202111141814: Finally got this partially done. Look here: https://joels-programming-fun.blogspot.com/2021/11/getting-freelibre-software-gimp-and.html.] For now it's important to realize you have something of a chicken-and-egg problem here, and it's important to understand that problem.

As I mentioned above, HTTPS helps somewhat, here. It gives you a moderate level of confidence that the website you are reading has not been filtered by some man-in-the-middle who will send you malware when you try to download the software. There are some things you can do to reduce the possibility of the man-in-the-middle attack, and one of those things is precisely this patient approach I have been describing.

Another is the many witnesses princple.

One more place I suggest visiting while you are checking things out, if you are working on MSWindows. (If you are working on Linux, one of the BSDs, or Mac OS X, this is not as relevant.)

Microsoft can give you a number of tools, but their tools tend to push you into their universe. That is one of the reasons I don't trust them as much as I trust Apple or the Free-as-in-freedom and open source crowd. (Google has been losing my trust since before they began developing Android, but I'm still more willing to trust them than Microsoft. Microsoft has burned me too many times. Technical stuff you don't need to know about.)

There is a group, and a piece of software, that you can use as a shim to help get somewhat free of Microsoft.
https://www.cygwin.com
Cygwin is a vendor/provider of developer tools from the free-as-in-freedom, open source community which bridge the gap between the Microsoft community and the greater outside world.

Some of these tools are compilers and other programming language tools. Others are versions of software like the GIMP and GnuPG that can run on MSWindows computers.

Without some special settings, the versions of the GIMP and other graphical tools they can provide need an X-11 or other graphical shell to run within, but these tools allow you to build them yourself. There are details here that I'm going to gloss over, but the point is that Cygwin can help with a lot of things that you would otherwise have to do without when using MSWindows. And that is a topic for another blogpost, as well.

Maybe you think this is not for you, but it will give you more opportunities to check out the community. So, while you are checking out GnuPG and the GIMP, or whatever other software you are interested in, check out the Cygwin site as well.

Trust is not just about the mechanisms.

If it isn't about the people and what they do, it isn't about trust.

[I wrote this to restructure some of the ideas in this post on bootstrapping trust: https://joels-programming-fun.blogspot.com/2019/04/bootstrapping-your-freedom-cygwin-gpg.html.]

No comments:

Post a Comment