Google Bias against Plain Speech?

Google has been telling me and others that my blogs that I haven't set to auto-redirect to HTTPS encryption are "Insecure!" and "Could be dangerous to access!".

WTFoolishness?

HTTPS has nothing to do with safe content. If you want to host a virus, hosting it over https doesn't block it or change the fact that it's a virus. If somebody gets your password or gets into your server and drops malware in your web pages for you, encrypting it won't change the fact that it's malware.

HTTPS can be used to help ensure identity, by making it harder to put a man-in-the-middle and send you, the reader, to http://defining-computers.blogsp0t.com instead of http://defining-computers.blogspot.com. (Did you see that was blogsp0t instead of blogspot?) I won't explain the weaknesses in HTTPS here, but I can tell you that even that is not all that strong.

And encrypting everything actually gives an attacker more surface area to attack the encryption. 

HTTPS is a speed bump, or, at best, a low wall. That's the best it can give you.

Proper use of HTTPS encryption is to limit it to the pages where it is needed, and to identity tokens on otherwise unsecured ordinary information-type pages (like blogs).

I just posted a post in my political blog about the evils of mocking, but -- 

I use nothing but plain text and a few simple images on my blogs. Okay, on some of my blogs, I let Google put their advertisements up, since I can't afford to pay Google for the use.

Plain text, simple images, and Google's own ads. 

No other content. If there's dangerous content, it would have to be Google's ads.

And I am letting Blogspot host the blogs -- again, because I can't afford to host them on my own server. If there's some problem with identity, it's not me handling my on-line identity, it's Blogspot/Google.

Okay, I guess that's why they want me to let them force my blogs to HTTPS. They think it makes things simpler for them.

Anyway, I am turning on automatic HTTPS redirect for all my blogs, not because it's a good idea, but because I don't have money or time to host my blogs myself, the right way. And I don't want Google warning innocent bystanders that I'm dangerous.

(Whether the ideas I expound on my blogs are dangerous or not is another problem.)

Google Drive is Evil

This blogpost is here: https://defining-computers.blogspot.com/2020/07/google-drive-is-evil.html.

Google Drive Is Evil (666)

666

As Unix file permissions, this file mode allows the entire world to read and write a file.

It basically makes the file a graffiti magnet: a place to write things like "Call {phone-number} for a good time.", etc.

It's particularly evil when this is the effective file permissions for your system files, as was the case for a certain early Internet-capable computer operating system of the 1990s and early 2000s.

[JMR202007231800 edit:

(I thought I had posted elsewhere about the real meaning of "666" in Unix and Unix-like operating systems, and I had promised myself to link that post in here, when I dashed this rant off just before hitting the hay several nights back. And I then forgot about it. Now I can't find that post.

I guess this is a good enough place to post it again.)

For a little preface, here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little explanation of why we shouldn't fear conspiracies, in which I point out that the author and leader of all the conspiracies is none other than the father of lies, the devil. And he can't keep his stories straight, and we can draw conclusions from that fact --

Conspiracies will always fail, even if they do serious damage going down.

And here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little discussion of a typical part of one of the reasons I feel a certain ambivalence about Google.

To go into some detail on this, in Unix-like computer operating systems, there is a concept called "file permissions". These are the permissions (or limits) that the system enforces about who can access a file. Traditionally, they were specified as bits in a binary number, representing the on/off states for sets of permissions, 1 being on and 0 being off.

The permissions were these:

Read, Write, and/or Execute allowed

Or,

rwx

Reading or expressing that as a binary number, you get the following

(0)	000	:	no read,	no write,	no execute
(1)	001	:	no read,	no write,	execute
(2)	010	:	no read,	write,	no execute
(3)	011	:	no read,	write,	execute
(4)	100	:	read,	no write,	no execute
(5)	101	:	read,	no write,	execute
(6)	110	:	read,	write,	no execute
(7)	111	:	read,	write,	execute

So "6" was read and write permissions allowed.

There were three sets of these permissions, one each for the owner of the file (the "User"), the primary group that the owner was a member of (the Group), and all others (Other).

So, a "600" permission setting allowed the owner to read and write a file, and gave no one else access.

A "644" setting allowed the owner to read and write the file, and allowed the owner's primary group and others in general to just read it.

A "660" setting allowed both the owner and the owner's primary group to both read and write a file.

A setting of "666" allowed basically anyone to read the file and write to it.

This "666" permission is not in-and-of-itself strictly evil. If you want a graffiti wall, "666" is pretty much what you usually want to set it as.

The scriptures in the Revelation which refer to "666" as the mark of the beast indicate that the mark would be in the palm of the hand and in the forehead, or a person would not be allowed to engage in necessary commerce activities.  (Such marks have appeared in history, I leave that research to the interested reader.)

I'm not going to say that John was or was not also referring to file permissions. But if we interpret these file permissions in such a way, the palm of the hand might be the device drivers for an operating system, and the forehead might be certain files in the kernel (as one possible interpretation, although there is a little bit of detail I'm not discussing here: The evil "666" would be for configuration files rather than actual drivers and kernel executables. The "766" and "777" for drivers and executables, while just as evil, are obviously enough wrong and hard enough -- cough -- Java -- cough -- to implement.)

This would essentially be allowing anyone with the necessary arcane knowledge to control a computer's calculations and functions from a distance.

A certain popular operating system had this kind of setting as a "feature" during the early days of the Internet (ca. 1993-1999). (In other words, the OS allowed anyone who knew how to reach a computer running that operating system full control over the computer. I'll let the interested reader look that up as well.)

What does this have to do with Google?

]

Google offers a file storage and sharing service they call Drive.

Google  Drive

Freebies always come with strings attached. One of the strings on this one is that you have a part of your drive that you don't manage. The effective default permissions are not 666, but are 622.  You can change them to 662 if you want, but they don't let you shut off write permissions for the "everybody else on the web". Anybody who has the e-mail address for the account you use to access Google Drive can share anything they please with you.

This might not be so bad. It's a bit like a physical mailbox. But the physical mailbox comes with postal system laws about abusing the postal system, whereas Google Drive doesn't have any way to dis-incentivize abuse of the system.

So you get advertisement you didn't want to see, and you have to look at it to delete it.

Even if it is some group of men in some third world country pretending to be women who post intimate pictures of themselves and offer sexual phavors.


You can delete your share link to the file, but they can make another file and share it with you again after they figure they've caught all the phish they could the last time around.

The techniques to block this kind of thing are available for e-mail, and work well enough there to keep the offensive mail to somewhat to a minimum:

• black lists of users you don't want anything from,
• white lists of users you will accept things from,
• and grey lists to block users who behave in certain ways (like huge To lists, which would be share lists for Google Drive).

These techniques should have been in Google Drive from the beginning. They weren't, so I didn't use Google Drive for a long time, until certain friends needed to share stuff with me on it and found it easiest to share on Google Drive.

--- Protocols for these techniques should have been part of the e-mail protocols from the beginning, but they were too hard to implement at first. And there were certain hyper-competitive companies that insisted on being king-of-the-hill in the computer industry, which insisted on making e-mail an end-user product and feature that they could use to compete unethically in the marketplace before the protocols were complete.

Now the protocols exist in conflicting ways, which is not a good thing, but a separate rant.

(The solution should have been two or three levels of protocols, and ordinary users should never have had to see the unfiltered protocols.

But, as I say, certain companies were too impatient. They needed to take over the industry, so they needed them before they were ready. History repeats itself.) ---

Now that I use Google Drive, I regularly get graphically explicit offers for sexual phavors all the time, and I have to go to the trouble of phlagging them as ophensive and illegal, and of deleting myself from the huge share lists.

When enough people flag them as offensive and illegal, Google eventually deletes the share list, at least, if not the actual files. But that's after the people who phish with the sexually explicit shared files have caught enough people who couldn't resist looking for more to make it worth their while to do it again.

Google Drive is either an incompetent service or a blatantly malicious service.

It's time to boycott it.

(Maybe not yet time to boycott Google's gmail, maybe not yet time to boycott Google's Android phone OS, maybe not yet time to boycott Google's Chrome web browser, etc. Maybe not. But definitely time to boycott Google Drive file storage and sharing.)

I will be going back to keeping my own files on my own physical file systems, and using either e-mail or self-hosted web servers to share my files. I suggest you do so, as well.

[JMR202203201344 edit:

Braver words than actions. 

I still have not been able to extricate myself from Google's services. Not enough time, money, or other resources to set up my own mail server, get a static IP address and a domain, and then maintain it.

God sometimes requires us to do the very difficult or even attempt the impossible, but He generally does not require us to operate beyond the bounds of our resources and reason.

For now, at least, I must satisfy myself with simply being aware that Google is filtering my mail, tailoring my search results, trying to profit on the services they offer, and not trying to bankrupt themselves meeting ideal expectations about their services, meaning that I have to be willing to delete obvious spam without wasting time or emotional energy looking at it.

Which, really, is in keeping with the understanding I get from reading the Revelation: 

The mark of the Christ is to keep his teachings in our hearts, minds, and acts.

The mark of the beast is to let the adversary of our souls impose his false teachings on our hearts, minds, and acts.

The influence of the devil does tend to work from the outside in.

But our spirits came out of God, and the influence of the light of Christ works from inside us, outwards.

]

CPUs -- 8-bit vs. 16-bit vs. 32-bit and Unreasonable Behavior

Recently, I was participating in a FB group and I noticed extremely unreasonable behavior on the part of one member of the group.

The group is a group dedicated to the M68000 microprocessor, which is generally classed as a mixed 16-bit and 32-bit processor, and this member of the group was obstinately using all sorts of bad argument technique to insist that the 68000 must be classed strictly as a 16-bit CPU, while accusing anyone who opposed his opinion of using the very same false argumentation techniques that he was using.

I looked at his profile on his FB home, and noted two things -- he registered the user to create a certain group, and he seems to claim some virtue in "being mean to FB users". LOL.

I could report that Facebook user and probably get him kicked off, but I won't, for three reasons.

One, I have been similarly unreasonable in flame wars. I try to shut my unreasonableness down as soon as I notice it, even if it means dropping out of the flame war.

Two, putting up with unreasonable behavior is a necessary civility. If we don't allow another person's misbehavior, we have no claim to any right to behave unreasonably, and pretty soon society descends into war.

Three, we often learn useful things from unreasonable behavior.

Unreasonable behavior.

When I think of unreasonable behavior, an example from the Bible comes to mind in the incident of Baal-peor, when a man and a woman were summarily executed for adultery. The record of the Old Testament is not very complete, and it's hard to be completely sure that the killing was done to stop the plague of sexually transmitted disease that people of Moab had started among people of Israel, but careful reading does indicate that was most likely the case.

And it's a classic example of unreasonable behavior, begetting unreasonable behavior, echoing to the present when ordinary citizens who stray outside without reason in Europe have reportedly been  summarily shot. A couple of things closer to home for me (Kantō area) that I get from mainstream news reports:

• pretty much every member of one group of young people who had a "live event" (dance party) last week has tested positive for COVID-19;
• one man who tested positive deliberately went out and got in the face of innocent salesclerks and others, infecting at least two of the people he came into contact with.

In the same vein, yesterday, I was likely in a checkout line with someone with COVID-19. I can smell viruses (a smell that reminds me of spoiled boiling potatoes or of testing potato starch with iodine), and I smelled that smell until this person left the grocery store. Yes, I stayed a meter back from that person, I walked outside in the clean air for fifteen minutes before returning home, and I when I got home I wiped my clothes down with alcohol spray, washed my face, and gargled.

My tendency to diverge from the topic is pretty unreasonable, too. Back to the topic.

CPUs are yet another thing one should never use a one-dimensional yardstick to compare.

I know that there have been real, if not commercial) implementations of strictly 8-bit
CPUs.

But that requires an 8-bit address space, and it's hard to fit much of a program in 256 bytes of program + data. Well, Harvard architecture would allow 256 bytes max of data space and 256 bytes of program space, but it's still really tight, and the programs you could write in that much space are likely to be better implemented with discrete logic or programmable logic devices.

Okay, it would be a fun topic to pursue, and might even be worth a master's thesis or such. But it would also be unreasonable for anyone who is not retired, in the present socio-economic environment.

That is, until someone does it and proves that there is some useful application for it, it would be unreasonable.

RISC processors were once an unreasonable idea, too.

So, all the so-called 8-bit CPUs you have used are mixed size CPUs, because they have address spaces larger than 256 bytes.

And we probably should admit that there is no useful strictly 4-bit CPU to be built.

A CPU with a 4-bit-wide instruction set? Yes, those exist. A CPU with 4-bit-wide registers? Yes, those exist. A CPU with a 4-bit-wide address space? Hmm. Okay, there are parts of larger CPUs that actually consist of such things.

Maybe we should have more open minds, instead.

Back to 8-bit CPUs. Most such are characterized as 8-bit for their data register width and basic instruction width, and have wider addresses. That's three dimensions, data register width, basic instruction width, and address width.

There are other dimensions, such as number and type of registers, orthogonality of instruction architecture, generalization and specialization of instruction set, etc.

But, even if you line up a bunch of these measures, you really don't end up knowing that much about a CPU until you start looking at well-written code for it and comparing it with good code for other processors.

To that end, I've been working on a set of common library functions that could be useful in comparing processors.  I'm borrowing the code for an old Forth interpreter to center the library around, but it will not be limited to the Forth paradigms. If I work it well, it should produce a Forth-like interpreter that will be portable across the CPUs, and it should allow others to produce similar library sets for other CPUs.

I should be posting the beginnings of the code later today, for the 6800, the 6801, the 6809, and the 68000, on my OSDN account. I'll link to that from here.

[JMR202007181941:

Here is the project on OSDN, but it's stuck at a place where the 68K code is not yet up:

https://ja.osdn.net/projects/splitstack-runtimelib/

]

Connecting Screen Controls And Audio on the Panasonic Let's Note CF-NX2 (Defenestration And Deforestation, Part 3)

This thread probably all belonged in this blog, but I put the first two parts in my main blog:

1. Defenestration And Deforestation
   Not conspiracy theories, theories about economic entropy.
2. Ubuntu on Let's Note (Defenestration And Deforestation, Part 2)
   Discussion of partial success swimming against economic entropy

Update on the status of this notebook PC:

I called the recycling company again, and, after initially arranging to return this thing, I asked again, and this time they said they'd send me the AC Adapter and I could send the bad one back. And if it didn't work out I could still send it back later.

I said a quick prayer and weighed the options again, and decided this machine is usable enough for me, and I need a true PC, so I asked them to send the adapter.

Then I did a search on the web for others who might have had screen control and audio control issues with this particular model, and found several posts:

This one gave me the methods to connect the keyboard function controls, so that I can hear audio without plugging in external speakers or a  headset, and so that I can turn the bright back up when the dying/dead AC adapter forces the backlight off.

https://gtrt7.com/blog/linux/ubuntu1710-on-letsnote

These two are earlier posts that essentially confirm the information in the later post:

https://qiita.com/PopularHero/items/5fda32b42f772061eb2c
https://www.linuxquestions.org/questions/slackware-14/sounds-issues-realtek-hda-14-2-a-4175596546/

The nitty-gritty is that Ubuntu has not had the appropriate settings information in the common install code. I should talk with the devs and get them to fix that. In the meantime, here are the settings:

** For the screen controls,

In

/usr/share/X11/xorg.conf.d/20-intel.conf

add

---

Section "Device"
    Identifier "card0"
    Driver "intel"
    Option "Backlight" "intel_backlight"
    BusID "PCI:0:2:0"
EndSection

---

The file probably won't exist, so, if you do this, you will probably make it new, and this will probably be the only thing in it.

And then in

/etc/default/grub

change the line

---

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

---

to

---

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor acpi_osi="

---

(with no line breaks, regardless of how your browser shows the line).

Then run update-grub with the usual root privileges:

sudo update-grub

When you reboot, the screen controls should take effect, and, if you have a bad AC adapter, you will be able to restore the screen brightness, maybe after logging in to a user.

(But, if you have the bad AC adapter, you really do have to fix the adapter or get a new one if you plan to continue using the PC. The wires inside the insulator will eventually break, like they have on this one, and then you will be running on fumes, like I am right now.)

Two points to take note of. One, this does not fix the behavior of the notebook when a failing AC adapter is plugged in. It will force the brightness on the internal display to zero, and keep firing the phantom button pushes until you unplug the thing.

Which means that you will need to unplug the adapter, and then wait until the filled button-push buffer empties and the on-screen indicator goes away. Then you can manually hit the brightness-up button so you can see what's on the internal screen again.

(Just between you and me, I consider this a poorly-thought-out feature in Panasonic's ergonomic design. Yeah, maybe it saves you from burning your notebook PC out, but must people will just think the thing has died. And, instead of taking it to someone who knows to replace the AC adapter, will just throw the poor thing away and add to the landfills and worker poisoning in poor 3rd-world communities.)

** For the audio controls

In the file

/usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf

find the following lines (headphone element):

---

[Element Headphone]
switch = off
volume = off

---

and change the volume line, and add two override lines, as follows:

---

[Element Headphone]
switch = off
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right

---

Then find the following lines (speaker element):

---

[Element Speaker] required-any = any
switch = mute
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right

---

and change only the volume line, as follows:

---

[Element Speaker] required-any = any
switch = mute
volume = off 
override-map.1 = all
override-map.2 = all-left,all-right

---

Having done that, you and I can just restart the pulseaudio daemon by the usual methods, whether we do it by the cool way with service commands or the hard way by rebooting the computer.

And now we can hear the computer beep at us, or listen to youtube in monaural.

[JMR201911160031 Update:

Rather than make another post to confirm that the replacement adapter does fix the brightness problem, I'll add that information here. However, the adapter does not fix the brightness controls disconnect problem, so, until the patches make their way into the Debian and Ubuntu distributions, the information on this page remains relevant.

Let's figure out what kind of pics to take:

Booting up,  AC adapter plugged in, pilot showing green, and no complaints about the adapter. (No internal screen because BIOS has the external screen selected at higher priority than the internal screen for the boot process.)

Made it all the way to the Ubuntu login screen without the phantom screen brightness control button activity, and the screen is appropriately bright.

Brightness control keyboard controls work, and no phantom presses pushing the brightness down, and you can see I was not eating my nightly yogghurt with chopsticks.

Logged in, nicely bright screen, and you can see I had a gforth session going in a virtual terminal window while playing with musescore, showing my typically distracted mental states when I should be sleeping.

One less notebook PC going to the landfills this month, I think.
]

[JMR202203201420 Update:

I added more audio stuff (Jack, etc.) and discovered that the audio settings got reverted. 

]

Re: Move (and Other Information Leakage)

I find myself reconsidering the wisdom of having ignored a certain free-mail provider's advice some fifteen or more years ago, to move from the unadorned address I was using to an address with some meaningful decoration.

(Ergo, from joelrees@freemailprovider.com to something like joelreesinjapan@freemailprovider.com or joelrees57738@freemailprovider.com.)

Here's why:

---

[Various indicative e-mail headers]
From: C**** D**** <C****.D****@somecompany.com>
To: "joelrees@freemailprovider.com" <joelrees@freemailprovider.com>, Joel Rees <Joel.Rees@somecompany.com>
Subject: 6th floor move ...
Date: [recent, elided]
[More indicative headers]


Hi Joel

Next week is our last week in our current positions.  We need to start our =
clearing out and packing.  Will you be back in the office before Friday, or=
 shall I pack for you?

C****

---------------------------------------------------------------------------=
------------

The information in this email is intended only for the named recipient and =
may be privileged or confidential. If you are not the intended recipient pl=
ease notify us immediately and do not copy, distribute or take action based=
 on this email. [More disclaimers, instructions, and assertions of relative
low priority, and questionable wisdom and utility.]

[Body repeated in HTML]

---

After receiving this message in my e-mail box, I consider myself to have a few options:

• (1) I could ignore this message based on the possibility that it might actually be phishbait. (But I have received other mail, and the probability is appearing low.)

• (2) I could be quiet and see what happens next. (But that really is not very nice, considering the other mail I have already received and tried to ignore.)

• (3) I could set the source address of the mail as a bounce address and otherwise remain silent. (Some might say this is my best option. If not for the other mail, I might consider it.)

• (4) I could send a laconic reply something as follows:

Hi, C****,

Thank you for the offer to help with the move.

Unfortunately, I doubt I shall be in the office any time soon.

Moreover, I suspect it would be not be easy or meaningful for you to attempt to pack for me.

By the way, thank you for your previous e-mail giving me certain information about the internal systems. I shall proceed to test the company's information systems security forthwith.

Joel Some Other Rees

This option, of course, is not a reasonable option for several reasons, not the least of which is that they might take my joke about testing their systems seriously.

(Sorry. This is not a novel. The risk involved in such work is great enough to overcome any motivation I might see for it, not to mention the not insignificant labor and sheer drudgery involved. Go find your entertainment elsewhere.)

So, here's a fifth option: remove most of the identifying information and blog about it, add the sender and recipient to my contacts in a certain SNS service, and put it in that service's feed.

That way, they have a chance to take action without my getting further involved. Also, everybody who reads this knows that I have publically declared my intent not to use the information I have, and the public nature of the declaration gives weight to the declaration itself.

But I then have to hope that no one else attempts to test their systems security before they take action.

I have chosen to take yet another option that can be extrapolated from the above.

And I am seriously considering changing the freemail address now. This sort of thing has happened before, although the details have not been quite as problematic.

I am also considering whether I can afford a proper vanity domain, such as joelreesinjapan.com.

In the original definition of the network technology that underlies the Internet, such domain names were not considered vanity. They were considered de rigueur -- required for every computer that would act as a user's interface to the network.

You can see some of the reasons from the above.

[JMR201908100903:

Or maybe it's not as obvious as I think.

Consider the odds of having to change your credit card number under the following accidental leak scenarios. You've sent it in an accidentally mis-addressed message to

1. a random post office box number in New York City;
2. a random post office box number in Wink, Texas;
3. a random mail drop in some big company like Microsoft;
4. a random mail drop in your own company.

Hmm. This is the post-snail-mail age. Maybe I should use a real example instead of an analogy.

Say you've accidentally sent the credit card number to

johnjones@hotmail.com

vs. accidentally sending it to

johnjones@tanakahardware.com

You'll note that this company does have their own internal e-mail addresses. The problem is that they added a freemail address to their contacts lists without first testing it. And it wasn't the address they thought it was.

So they send me information I shouldn't get.

I don't want the information.

]

Somehow, during the "wild west days" of the extreme exploitation of the nascent Internet, such "minor requirements" got swept under the rug in favor of immediate profit.

(In more than one of my fantasy alternate realities, the countries burdened with the load of cleaning up the information systems, economic, social, and political impact of the exploitation of the early Internet combine to levy serious fines and other punishment on those who have profited in the extreme from the exploitation.

If only.)

Meanwhile, check the addresses that receive internal company mail before you use them.

It's safer that way.

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