Some Basic Hardware and OS Security

(I really wanted to do something else today.)

Recent movements in the IP field that I think need to be responded to. (A new huge dump of a random harvest of private data by a pseudo-anonymous group of crackers and gray-hats today, after a bunch of hoopla about a US standards body publishing its lame (pardon me for saying so out loud) list of hardware security requirements last week, among other things.)

#1 No standard DRM (digital rights management) systems in the design.

Let me repeat that. If you think system security is good, standard DRM is evil.

Reason:

A: Every system will be vulnerable. (This is axiomatic, empirically proven in system theory.)

B: In order to meaningful, DRM is sold as universal.

C: If Universal DRM is adopted, every system using it will contain the same vulnerabilities (in addition to whatever vulnerabilities the system has on its own.)

Thus, DRM will tend to induce universal vulnerabilities. When you know how to get into one computer, you can get into them all. Huge, huge reward to the bad guys, and fighting against the diversity which could otherwise protect systems with different (or no) DRM.

Because even nonstandard DRM must function at a low level, it tends to allow entities that do not have system security as a high priority access to the OS at way too low a level, which is another serious social engineering flaw, but that could be worked around somewhat, sort-of, if we really must have DRM. (I'll have to rant about that sometime, I suppose.) To make that work, DRM has to be re-thought, however, particularly the very odd concept that DRM must be enforced.

Yes, I'm pointing out the inherent flaws in the DMCA (Digital Millenium Copyright Act). Which leads to

#2 Repeal the DMCA. If possible, pass an amendment against any further national, state, or community-level attempt at attaching legal culpability to any sort of automated rights protection system. (Which is another subject for a rant sometime.)

The security implications of the DMCA are that, with the DMCA provisions against reverse-engineering, the engineering required of the end-user (or the end-users system integrator or IT specialist) to secure a system has been technically criminalized.

You can provide all sorts of fancy argument about why this should not be so, but both my wife's and my cell (non-smart) phones are vulnerable. I can't get the information from the vendor or manufacturer that I would need to secure them. Under a DMCA-like law (I'm not sure whether the laws in Japan include such.) I would be risking prison time to dig around in the phone, to figure out how to fix the vulnerabilities.

Risk going to prison, just to keep the bad guys out of my phone. Not a win, okay?

Which leads to

#3 Both 3rd party and customer admin and support allowed, and the necessary documentation and source code provide by the vendor.

The options of non-vendor support and system administration are necessary to keep the vendors honest. The option of the customer doing it him/herself is necessary to keep the vendor from trying to use licenses and non-disclosure agreements to keep all the 3rd party companies in their back pocket.

A free-as-in-libre software license, such as the GPL, should be the recommended best practice, but it is not sufficient. The vendor support has to be optional, and not just theoretically so.

#4 Free or open source OS bootstrap code (BIOS, Open Firmware, etc.), supplied with the hardware.

Generally, the manufacturer should supply both the latest tested binary image and the source code over the 'net. But if the manufacturer goes under or drops support, or if you can't get on the internet, you might still be stuck. So a copy of the bootstrap code and object in the system at the time of original sale should be supplied with the hardware.

This should go without saying. If you can't fix the software that controls how your system starts up, you can't fix bugs there, either.

More important, if someone sneaks into your system from the internet and plants low-level malware in your BIOS, you may be left with no option but to junk the motherboard if you don't have some means of re-programming the BIOS to what it should be.

I know that means the customer would end up being able to re-purpose the hardware counter to the vendor's intent, but what is wrong with that? The vendor can (and should) explicitly dis-avow warranties when the user does things like modifying the bootstrap code.

But this brings us to two more points:

#5 Built-in bootstrap code re-programmer, not available during normal operation.

#6 Physical hardware disable for the bootstrap re-programmer which cannot be re-enabled by software, at least not during normal operation.

There is a bit of a conundrum here, because the typical (and often expected) solution here is to have a simple VB program that holds the user's hand while walking through the steps of re-flashing the BIOS. The problem is that, when you need to re-flash the BIOS, you don't want to run the operating system in order to do so. When the malware is in your bootstrap code/BIOS, you have to assume it's also in your OS, even in the so-called safe mode:

Why would the intruder mess with your BIOS/bootstrap code and not mess with the programs that test the integrity of the Operating System?

There are several ways to do this, but the cheapest will be to provide a backup of the bootstrap/BIOS, and a small button or strap on the motherboard, such that, when you push the button, the active bootstrap/BIOS will be automatically overwritten by the backup.

Of course, if you have patched your BIOS/bootstrap code, you lose all your patches when you do that. Which has induced manufacturers to play dodgy games with two flashable BIOSses in many current motherboards, but no real way to tell which one is the safe one.

This is the point at which the DRM advocates said, "Let's just take the whole mess out of the consumers' hands. We have to protect them from themselves."

***
Instead of doing a proper engineering job here, "protect the consumer from himself"!

And this makes the manufacturer a party with the malware installer.

It's not hard to get this right, but it's distracting from the point of this rant, so I'll explain it in the previous rant.

Why should the re-programmer be surrounded by so much fuss? Won't that make keeping the bootstrap/BIOS up to date all the more unlikely?

The bootstrap/BIOS should not be updated that often. But, yes, the manufacturer should provide an opt-in notification method, and instructions which could be printed out, when a bootstrap/BIOS level update is necessary.

This gets us safely booted. What's next?

#7 CPUs. And OS structure. Which should be the subjects of other rants, I guess, even though they're the reason I started ranting today.

Briefly, Intel, in their rush to lock the competition out, have always sacrificed security for features.

Even today, the best CPUs Intel has made fail to properly separate tasks from each other. The 8086 had those stupid segment registers, and they would not have been stupid at all, except they were just ways to extend the length of pointers in an otherwise pure 16-bit chip.

They looked like rudimentary memory management, but they were nothing of the sort. Just a misfeature that was used (fraudulently, if you ask me) to sell underperforming chips.

A: CPUs need to be able to separate flow-of-control information from data. (Yeah, I know, you're raising an eyebrow and saying that sounds like FORTH.)

How this works is that the flow-of-control (return pointer and possibly a frame pointer) are stored on one stack. That stack is cached in a cache that cannot be accessed by any normal instruction, and you have a low wall against the attacker trying to overwrite return pointers. A low wall, yes, but better than none at all.

(A stack-oriented cache with hysteresis could also speed up subroutine call/return significantly, but that's a topic for another day. Yeah, I know Sun has processors that do something like this, but not quite.)

The parameter/locals stack could also have a stack-oriented (ergo, hysteric LILO spill/fill) cache. It would be larger than the cache for the flow-of-control stack, but not too large, because of the delay it would cause for task-switching.

B: CPUs need to be able to separate task-local (thread-local) static data from global data, or, rather, from the data of the calling environment.

Task-local data is accessed without regard to other processes/threads because it is allocated per-process/thread. (This is another way of disentangling the current usage of the unified stack, actually.)

The context of the calling task or thread may be read relatively freely, but writes to it must be filtered through semaphores, critical sections, monitors and the like.

There are four segments here, which must be kept somewhat distinct. This is what segment registers should be used for, but the memory interface itself should have access mode protection, similar to the seven modes supported (but never really used) in the original M68000.

Not quite the same because the conditions for enabling read, write, and execute on those modes could not be tied to access via a specific address register (in absence of segment registers). And there were not limit registers to prevent attempts to access one segment through long offset in another.

These are the kinds of things where Intel has let us down, and actually fought against security.

Not because we knew we needed this back thirty years ago. (I only saw it dimly, until about twenty years ago. I don't know who else sees it.) But because Intel's processor is over-tuned to the structure of the C/Unix run-time defined forty years ago, and Intel has used very questionable means to destroy the market for more flexible processors which could have been used to explore alternative run-times.

Without Intel's hypercompetitivity, it is quite probable that the run-times that could prevent the most commonly exploited vulnerabilities in current OSses would ready for production. As it is, we still need to explore and experiment a lot.

(Microkernels can apparently help for a while.)

There's much more that I need to say about this, but I'm out of time today.


[JMR201704211138: I had some thoughts on the low-level boot process, which might be relevant: http://defining-computers.blogspot.com/2017/04/model-boot-up-process-description-with.html.]

How to update your bootstrap code/BIOS.

No, this is not for existing systems. This is how systems should be designed to provide for updating the code that the hardware runs before anything else.

(If you want to understand why, see the later post on keeping the bootstrap code scure.)

First, your bootsrap OS has to be a bit more complete than BIOSses have tended to be in the past. Closer to Open Firmware, but useable by the average moderately-technical user and the average support-guy at the local shop.

You have to have four images:

1. Working image,
2. Backup of latest working image,
3. Archive image,
4. Fallback, or fail-safe image.

The working image is the one you normally boot. It boots your normal operating system. If the hardware allows the working image to be re-programmed from the normal OS, the normal OS must only provide access to the re-programming features in a special administrator mode that requires being re-booted to.

(Getting or compiling an updated bootstrap image is a separate topic that I will try to rant about later.)

The backup of the latest working image is never booted. It's basically there because a good cryptographic checksum cannot guarantee perfectly that something hasn't been inserted by a very clever mathematically inclined attacker. It's for checking the bootstrap before the bootstrap is allowed to continue.

(Yes, that means a pre-boot boot. Naturally.)

The backup is also checked against the current working image before re-programming is allowed.

Then, after you update the bootstrap code, and run some integrity/security tests, reboot, and run some more integrity tests, before the normal OS is called, a new bootstrap will copy itself to the backup.

The archive is also never booted. It must be physically impossible to write to it from either the normal bootstrap or the normal OS.

The administrator will set a period, a week or two, or a month, after which a grandfather backup will be scheduled, and the pre-boot bootstrap will copy the backup to the archive. (The waiting period is to leave enough time that the bootstrap can be assumed stable.)

The fallback image, which includes the pre-boot bootstrap, must be physically impossible to write to, period. It's there for when all else has failed. It will include some command-line and (simple) menu-driven tools for testing, debugging, hunting for malware, etc.

There must be a physical button, switch, or electrical strap that will force booting to stop and wait at a command-line or menu instead of proceeding to the normal OS. In addition, an administrator tool should be provided for the normal OS, which directs the next boot to stop at the bootstrap level.

Another button, switch, or strap will direct bootup to the fallback.

Among the commands available will be one to get a new bootstrap (working) image from the manufacture, over the network, or from some removable media. Another will provide for updating the kernel and lowest-level utilities of the normal OS without having to start any image of the normal OS.

In a brand-new, fresh-from-the-factory motherboard or system, all four images will be identical.

So, what about the normal OS?


A similar approach might be useful in updating normal OS and application code, as well.

Some code, such as the kernel, would do well to have full multiple copies for backup. Others, mostly end-user applications, might be okay with only good checksums, but I would be inclined to use full copy backup for any mission-critical application.

If four copies of every app is overkill, two copies and a good checksum would be a next best alternative. (And preferably, don't let the application updater directly overwrite the checksums.)


[JMR201704211138: I had some further thoughts on the low-level boot process, which might be interesting: http://defining-computers.blogspot.com/2017/04/model-boot-up-process-description-with.html.]

What are APIs?

Posted a riff on the definition of API on Groklaw last night, and copied (with editing) the riff to my main blog. Here is more of a top-down approach:

An API is an abstract definition of the words and grammar (symbols and the way you arrange them) used to interact with (or operate on) a glob of code. It implicitly includes the (human understanding of) the functions performed.

But, you have to remember, when you mix math into the milieu, it makes for a pretty strange stew.

Anything can be a symbol.

C has headers, ideal was to put the API in the headers. Ideal never fully realized.

Java's API element is supposed to be the interface, but it is still not really separable either.

That's the skeleton of the argument, but the flesh of the argument will have to wait. It's the sabbath morning, and I have over-committed myself to work again.

Fixing my grammar.

Call it a freudian slip?

"We won't control themselves"?

Heh. Blame it on the Japanese I mix in. Or not. Maybe I was jumping from my sarcastic argument (thus, poisoning the well) to my conclusion. Logical fallacies, all.

So I fixed it:

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 何て特長ある筆に特殊の消しゴムがついたものにすぎないし、ネットワークそのものは裏庭の塀が少し拡大されたものぐらいです。

You Thought User Names and Accounts Were Easy?

After re-reading, I remembered I'd left out a discussion of user names.

The initial start-up program that walks you through setting up your first accounts and passwords usually suggests a user name for you. That might be good enough for you, but, then again, ...

There are two ways of choosing suggested user names.

One is to just borrow the first or last name of the owner name you typed in just a page or two back. Another is to borrow the initials. For someone named "Harriet Maxine Smith", user names likely to be suggested would include "harriet", "hms", and "smith".

But you are usually allowed to change the user name, so you might change it to "harrie", or "smitty", or "girlgeek", or "admin".

Hmm. I don't recommend "admin". Let's see why.

The computer (operating system) needs some ways to identify you, so that it can help you keep your stuff separate from the system stuff, and maybe from other users' stuff. Usually, there is a numeric userid (numbers are easier for the computer to work with) and another username that looks like a regular name, with letters and stuff (easier for you).

In most current Linux and Unix systems, numeric ids below 80 are treated special. System processes use them. In many recent systems, from 81 to 500 or 1000 are treated special in a different way. (How is a topic for a later time.)

You might have a reason to choose some number for your numeric user id, but, you should be okay with the one the system suggests for you. In fact, the system may not go to the trouble of even mentioning the numeric id, so as to save you a step in the setup process.

The user name, however, should be one you are comfortable with. And you want it to be easy to type, because you are likely going to need to type it sometimes.

One thing you may want to consider: Logging in to the computer requires ...


OH. I said "log in" again. And you may not know what that means.

Many jobs require the worker to keep a log of what she does on duty. Logging in, in a simple case, would be just making a note in the log book --

Solardate 10.6.3.0.0: Harriet Smith on duty.

Now she can write down notes and stuff, and the assumption is that she is the one wriiting:

Solardate 10.6.5.7: Passed solar east of Ceres.

And when she goes off duty,

Solardate 10.6.3.0.0: Harriet Smith on duty.

And the next entry would be the name of her replacement.

You don't have to write fancy stuff like that in the computer log. (But IT system administrators may.)

Instead, the computer needs to know that you want to start using it, so that it can show you your files and stuff. And you probably don't want strangers using your files, so you want the system to make sure it's you.

Files and stuff. That would be your user account on the computer -- all your files and records and stuff.

So, you tell the computer your user name. And then it asks for your password, just to be sure. That's what loggin in is all about.

Now, if a bad guy doesn't know that Harriet's user name is "harrie", then the bad guy has to waste time guessing a user name before he can even start trying to crack the password.

Which is why I don't recommend "admin" as a password. (Unless you want to use the account as a trap for the bad guys, instead of as a system administrator account.) PIck another name.

Maybe Harrie surfs the web as "geekgirl", works as "harrie", and administers her computer as "carrottop". Three different accounts, three different names, not hard to guess, but not completely obvious, either. Easy enough for Harrie to remember.

Bonus question: Linux and Unix computers pretty much are guaranteed to have a user named "root". This is account number zero, and it is really, really special. It's the super-duper-omnipotent administrator for the computer. If you log in as "root", the entire machine is at your mercy. If you fall asleep at the keyboard at the wrong time, you could erase everything in the computer. Or worse.

You really don't want to log in as "root".

Bad guys know about "root". It's a name they don't have to guess. That's why you don't want to allow anyone to log in as root, ever. That's the real reason you want a separate administrator account.

Most OSses that you may find yourself using these days disable root login by default. If the system setup program asks if you want to leave it that way, say yes. But make sure you set up the administrator account, too -- with a name that isn't obvious.

And, if you're using one of the OSses (like OpenBSD) oriented towards serious technical work, you should check whether root is disabled or not, because the people who build those OSses assume that you know that you should check. (OpenBSD is one that asks, actually.)

Off topic here, but MSWindows, in theory, doesn't even have a root user. Don't misunderstand this. Senior level administrators still know how to get the whole system at their mercy. And if you have to be responsible for a MSWindows computer, or have to own a MWindows phone, make sure you change the default administrator account name. And "admin1" is hardly better than "administrator" or "admin".

"addm1n" would be a terrible password, but maybe not a bad user name for your administrator user. Just don't make it the default administrator user name for the entire company.

Passwords. Now we can move on to passwords.

Good Password -- Bad Password

Well, maybe I or someone has convinced you to set up non-admin users to log in to for your day-to-day work. Now you're faced with the problem of how to choose a password.

(Well, actually, there's also the problem of how to set up a user name, which bears some discussion.)

You've heard all sorts of scary stories (and I'll tell you more) about passwords, and you probably wish you could simply avoid them altogether, but, for the present, they are a necessary evil.

Physical locks can often be picked, so they are not perfect protection.
Passwords, PINs, and passphrases can often be guessed, so they are also not perfect protection.

When you choose a lock, you usually pay a bit extra for a lock to protect things that are more valuable. For your $100 utility bike, a cheap lock is okay, but for your $1,300 dollar mountain bike, you want a better lock.

Likewise, when you choose a password, you may not want to spend much time figuring out a password for the blogging site where you just want to tell the blogger he's all wet. But you should be much more careful about how you pick your e-mail password and your on-line password for your bank.

And you should be really careful about your computer passwords.

One thing you should consider when you pick a password is who the bad guy is. Relative to a password, anybody can be a bad guy. Even good guys can be bad guys sometimes. Maybe your spouse can be privy to the password, maybe not. If you're working at home, probably not. [JMR201612301030: That is, probably not for your work account unless your spouse is also your secretary or something. ] Children? Siblings? Roommates? If you don't want to trust them with free access to your credit card number, you shouldn't trust them with your passwords.

(Well, if you are deliberately sharing a login account, that's different, but you want to be think a bit carefully about shared accounts, too.)

Your administrator password, at any rate, should be kept secret from just about everyone, maybe even your spouse. In fact, if your spouse doesn't want to share the administrator burden, you probably should not share the password. [JMR201612301035: And it's a good idea to ask him or her. ]

And if he or she does share the burden, it may be a good idea to have two administrator accounts, one for each of you. It's not that you don't trust your spouse, it's that arguments about who did it are not conducive to fixing the problem. And, yeah, you'll make your share of mistakes, too.

Bad passwords, PINs, and passphrases are those that are easily guessed, and those that are easily generated automatically by running through some sequence.

Some bad PINs: 1111, 6789, 0202. Also, 0207 would be bad if your birthday is March 2nd or February 7th. If someone steals or finds your wallet, your birthday is probably going to be on your license. 6149 might be good, if it's not part of your phone number or address, or your license plate number, or some other number someone might find in your wallet or might see you checking when you're at the bank. Except, now that I've used it here, you shouldn't use it. Bad guys might see it and think you'd use it.

How about one of these numbers reversed? After all, you need to remember it.

But if your roommate were to figure out how to regularly "borrow" your card without you knowing it, she might try your birthday this week, and your birthday reversed next week, then the last four digits of your phone number, and so forth.

If you are into being devious, you might write some number completely un-related to the actual PIN on a sticky note, and leave it attached to your card. Just be sure you don't try to use it when you're drunk.

[JMR201612301042: Being drunk is a security risk in and of itself, but I'll refrain from preaching at you too much about that in this post. ]

Should you write your PIN down somewhere? Many people say no. I don't know. If you're too tricky with your PIN, you're going to forget. Or you may remember that it's seven days past your birthday and your birth month times 3, but which came first?

If you do write it down, consider writing it in a crowd of other numbers, with some key that only you would notice to remind you where it starts. And write it in a simple code, maybe write two numbers that you have to add together, or use a rotate-by-three or by-five code or something. Be careful not to make it obvious what the number is by what you write around it.

Where PINs are used, they generally get invalidated after the third bad try. (And then you have to go in to the bank or phone company, show them your license, and get them to let you set a new one.)

Passwords can similarly be use limited, but are generally not invalidated. Three bad tries and you have to wait five minutes helps block guessing even simple passwords. But bad guys will sometimes find a way to copy the encrypted password file from the computer, and then take their own sweet time to crack the password by guessing one after another.

One way to cycle through guesses is to start at "0" and go through "9", then "A" to "Z", then start over at "00" through "ZZ", then "000" through "ZZZ". If the password is any combination of just four [JMR201612301051: capital ] letters and numbers, such an approach will find the password in less than a half an hour, even on computers that are not very powerful. If someone can get a thousand computers working at once over at some cloud rental place like Amazon's, such passwords can be [JMR201612301046: find found ] in seconds.

Another trick is to use lists of words. A list of all English words is less than 200,000, and even including ten other languages is still not going to break a million. That's going to be quick.

So joaN and x3r! and electrocution are too weak, and even mYjoaN9! and P0t+3rHa are not all that strong.

For someone who knows you, 8a$EbaLl is going to be somewhat weak, if the bad guy knows you like baseball. Yes, there are computer programs for turning words into 733t$p{aK like that, and they can run pretty fast. Likewise, BeatriceSmith, if that's your mother's name. And famous dates, like 19november1863, are not a good idea, especially if the bad guy knows you are a fan of Abraham Lincoln.

Actually, dates can be sequenced through pretty fast, so don't use any straight date. Do not use your phone number, or any all-number password.

Nonsense passphrases, like "BallWheelSnipe" are supposed to be good. I haven't checked all the math, but it does look pretty good. I'd go with "8aLLvvH33L$nip" instead, I think. But don't use either of these now, of course.

Twelve or more letters, numbers, and punctuation. Use three or more words, mix in a little leet-speak to make things a bit harder to guess, but not hard to memorize.

Write the passwords down?

Probably should.

With PINs, you have the bank or the phone company to go crying to. With your computer, you only have you.

Probably leave the list in a locked drawer in your desk. Even so, don't make the passwords obvious. Do things like burying the real passwords in a list of fake ones. Don't make it obvious which password goes with which user. Maybe encrypt the passwords and user names with something simple, like rotate-by-nine, if you can handle the un-rotation in your head.

And make sure you regularly check that the list has not been borrowed.

Now, you have strong passwords, and you have user accounts to separate the things you and your family do, you need to know about sudo. I'll blog about that next.

[JMR201612301549:

I've posted a little rant that might help remember passwords and passphrases, and might help understand simple encryption, here:
http://defining-computers.blogspot.com/2016/12/how-do-you-remember-passwords-and-pins.html.

]
 

Why users and passwords?

Okay, you just got that brand new computer at the store, you brought it home, turned it on, and it's asking you to set up a user account. And, if the system is worth anything at all, it's suggesting you set up an administration user, too.

You: Huh? What? Why? I just want to use the thing, I don't want to learn how to be a system administrator just to surf the web.

Well, actually, you do. Hmm, ... no, I don't want to tell you that, because I know you'll quit listening. Okay, let's try this, instead:

Strange Web Site: Hey, that's a pretty cool computer you have there.

You: Uh, thanks.

Strange Web Site: Let me show you some cool things to do with it.

You: Wait. I don't know you.

Strange Web Site: Oh, no problem. I wouldn't do anything bad to your computer.

You: STOP! QUIT! NOOOooooooo!

Okay,  that should give you an idea of why you want to set up users. By setting up users, you can make it so people have to log in to your computer with a user name and password before they can do anything evil to your computer.

Okay, so I should set up a user. But why two? I mean, my buddies tell me it's a hassle when you've just downloaded a cool app and you have to log out and log back in as a system administrator just to get it to run.

Hey, I know what you mean. You just found that cool app to find bluegrass tunes for you and, no, not bluegrass? Not grunge rap? Not death plastic metal? Oh, re-mixes of Tchaikovsky. No?

Well, I don't know what it is that turns your crank. In my case it would be a new programming language I'd never tried before, but maybe you're not into that, either. Anyway, there are these things that are often called apps, and you often want them, and friends suggest them, and, yes, if you usually surf the web as a non-administrator user, like they tell you, it's a hassle.

But if you surf the web as an administrator user, all it takes is one crack in the browser's defense, and before the conversation above can be started, somebody you've never even seen or talked to has put in a little program that steals your passwords, credit card numbers, your e-mail address book, and any information in your e-mails that looks interesting, fun, or profitable to them, and left another little program that uses your computer (yes, your computer -- or your phone!) to crank out unsolicited advertisements of dubious nature, or worse.

(v!@GrA anyone?) 

Not interesting, fun, or profitable for you.

So, it's a pain, but go ahead and set up the separate administrator user account, and don't use it to surf or browse.

And, after the initial setup, you might want to find the administration tools and set up another account, to be a bit safer, an account that you only use to log in at the bank.

I actually set up separate accounts for each of the following on the family computer:

• administration (see above)
• bank business
• work (but check with your employer)
• work related surfing
• general family surfing
• one private account for each family member

Why the last item? That's several accounts, of course. For me it's a matter of respecting their right to a certain amount of privacy in their e-mail. (My wife does not yet use her's very often. Oh, well.) It's a bit like each member of the family having his or her own shelves (or room, or desk).

Anyway, you definitely want at least one non-administrator user account and one administrator account on your computer, and you want to use a non-administrator account for most of what you do.

That should go for your cell/portable phone, too, but the guys who make those think you aren't capable of managing it yourself.

But, your friends say it's too hard? Well, that's part of what I made this blog for.

Let's start with how to choose your user names and passwords.

Providing Mailing Lists and Newsgroups

If only service providers really provided what you want for mailing lists.

Google gets close with its groups. But one thing missing, that would seriously limit mailing lists being harvested for unwanted e-mail, is giving registered users their own list addresses.

Sourceforge gives their users a sourceforge address. They also buffer their forum and developer services, so that it's hard for spammers to get user addresses and hard to abuse the addresses that they do find. That means that I can use their services rather freely without too much worry of drowning in a delusion of fake viagra offers and such.

The gmail accounts that Google sets up don't quite match. They are general addresses, and people tend to use them as such. What we want is for Google to provide group-only addresses, along the lines of

molly.m@soc.religion.mormon.ggroups.net

Well, that's a long address. But when molly.m posts to the group, she can tell the group server to show only her group address. 

If someone wants to contact molly.m about needing help to move a million euros out of turkey because the owner died and the rightful heir can't seem to get a visa into the country or some such fantasy, well, they send the unwanted offer to the group address above, and the group server flags it as not being from a registered user, then proceeds to apply strict automatic checks on the content and flags it as probably unwanted mail. 

And, if the server is being really helpful, it could give molly.m web browser access to the posts she gets from the list, so she doesn't have to download the whole message to see the sender and subject, and the flagged messages could be on a separate page, sortable by the reasons they were flagged, similar to Google's spam boxes.

Actually, you can get something similar to this through Google's commercial services. But this is what all ISPs should be providing.

This is what is out-of-balance in the current economy, Google has gotten well down the road to what a real ISP should be, so far that the small providers can't keep up. 

They have done so on the back of open source software, but they aren't feeding their improvements back upstream. That's great for their bottom line on advertising dollars, and doesn't directly hurt the smaller ISPs financially, but it gathers too much power into one organization. And, while it really doesn't do direct damage, it does indirect damage to the economy in general. Ordinary companies can't compete, so they drop out.

Drifting off topic, but losing one small company from the economy means lost jobs, lost wage earners, lost purchasing power, and, ultimately, fewer people buying with fewer dollars. One company doesn't hurt so much, but when too many small companies drop out, it dampens the overall economy.

That's why Google is too big.

That's also why Microsoft, Apple, Oracle, and IBM are too big. And that's why the automakers and banks and artists associations are too big.

Back on topic, part of the reason Google jumped so far ahead also happens to be that ordinary providers had already forgotten that they were selling services. They were already too stingy with e-mail addresses, too slow to add filtering, and too willing to charge extra for the filtering. So it's not all Google's fault.

Another thing they've been too slow about is what I'm talking about here. ISPs should be providing newsgroup services for their subscribers already, and the services should allow group-only addresses as I suggest above. It should be okay to charge for larger list and newsgroup support, but support for small lists and groups should be included in the basic fees, or available for what my provider charges for a dingle simple second address.

mailing lists vs. e-mail -- メールリストとEメールはどう違う

Mailing lists and newsgroups have a lot in common with ordinary e-mail.

I mean, they're called "mailing lists", aren't they?

True, some people are a bit surprised that newsgroups and mailing lists are more or less the same thing. But, if you think about the evolution from mail to mailing list to newsletter to newspaper, it's not so surprising after all. (Not to mention the question of the difference between a blogger and a journalist.)

So, how are they different? How should they be different?

One thing I can think of is the expected volume. Another is potential audience.

With e-mail, you only expect a few messages per topic, maybe two to ten or so.

With mailing lists, the average number of messages per thread is often more than two, and the upper limit may be the size of your server's hard disks. Threads with more than a hundred posts are not uncommon, anyway.

And e-mail is intended to be more-or-less private, where mailing lists are expected to be at least semi-public.

(Of course, we all are aware, sometimes a bit painfully, that even private mail can easily be made all-too-public. And if we have ever (ahem) set up a Google or Yahoo group and waited for people to join, and waited, and ..., well expectations are not always fulfilled.)

So, there are some differences. the protocols and software should reflect those differences.

I'm a little radical. I think that everyone should have their own mail server. Private mail should be stored locally, even if we ask for some (hopefully dependable) company to back our mail up for us, it should be primarily stored locally.

Oh, yeah, if you can get your own mailserver set up, it's not that hard to make it accessible to yourself across the web, the only reason to depend on a provider is if you don't want to bother with doing the setup yourself. Okay, the setup should be easier than it is now, too, but that's part of what we need to work on to get there from here.

Mailing lists, on the other hand, will tend to require enough maintenance that it may make much more sense to ask a provider to handle them for you, especially with the current state of technology.

If only service providers really provided what you want for mailing lists.