My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Thursday, July 31, 2008

tools, OSses, upgrades, and an iBook

Okay, here's the problem --

I have a vintage iBook, tangerine clamshell. I've been using it in my present job for about a year and a half, making teaching materials with AppleWorks. I should be able to automate some of these teaching materials, where I just have a program and feed it a list of words and it formats things and lays things out, etc., but my Java skills aren't really up to it, and I apparently need to learn a bit more patience with CSS.

I also need to be able to access openoffice at work, since I am not a fan of Microsoft's poor excuse for an office software suite. (There's only so much disappointment I can stand from a monopolist, Bill, Steve.) And I want access to the Gimp, as well.

The obvious solution is to buy a new computer, since this vintage iBook is only 300 MHz, 192 MB RAM, 5.6 GB HD, USB only and unable to boot from USB (no Firewire), running MAC OS X 10.2. But that option really is not available to me. (I have serious financial issues here, just like the rest of the world.) Besides, a new MacBook contains an iNTEL CPU. (There's only so much disappointment I can stand from a monopolist, Andy, Craig, Paul.) I understand I could run AppleWorks on an iNTEL MAC via Rosetta whatever, so the primary issues are cost and, well, iNTEL. If I could afford the cost, I might go pragmatic about monopolies.

Ultimately, I need to move off of proprietary software. (The problem with AppleWorks should be enough explanation why?) That's more reason to run Linux. But that's a separate topic.

A second obvious solution would be to purchase a used iBook or PowerBook with a faster processor. Hopefully, I could find one that can still charge its battery, unlike my iBook, where various abuses have rendered the charger and battery dead.

Hopefully, I'll get a chance to buy the battery charging boards before they become impossible to find any more. They're not that expensive, just hard for me to find in Japan. Although, truth be told, even the roughly $100 dollars the two boards tend to be listed at is a tight squeeze for me right now.

So, I was in Softmap the other day getting a new power supply for the iBook. This time I bought one that has the wires all detachable from the brick, Sanwa Supply part #ACA-A11, so that when I dump it in my bag, the wires aren't put under as much stress. And maybe I'll be able to build a replacement for that lousy shielded head next time the wires break right behind it. While there, I picked up a 160G hard drive for about JPY 7000 (about USD 70). They said that the RAM was no longer available, so I left without RAM.

Then, yesterday, I stopped by Pasokon Kobo on my way back from interviewing for a summer job to help pay the August rent, and they had the RAM chips there. The original spec is a 60 MHz part, but Apple says 100 MHz will do, too. Looking around the web, you find people that claim success with the 133 MHz part, and that was what they had, so I dropped another JPY 8000 (about USD 80) on that.

Very interesting to note that lowendmac says that all of this dance was for nothing. You can't even boot Mac OS X in a partition larger than 8G, and that the partition has to be entirely in the bottom 8G. I'm not sure if that's true with this model, one of the last tangerines with the 64M RAM soldered to the motherboard. I ran Mac OS X 10.2 in a 15G partition on it for a year, using it as my personal web server, and I currently have two separate installs of Jaguar on two separate partitions, one partition is 20G, the other, higher up, is 5G, and there is a 4G partition at the very bottom for booting Classic so my kids can play Bugdom, and I can play with openBSD.

Both of the Mac OS X partitions boot, although the Mac OS 9 partition presently does not, apparently because I did a proper partitioning when I installed Fedora and now there are way too many partitions for Classic too remain sane.

[Update: I have checked the readme file that comes with Mac OS 10.2 and it makes no mention of the iBook in the section dealing with the 8G limit. Apple's current information page on the limi does, however, include the iBook. I'm inclined to think this was a case of collecting all the disk drive issues under one roof.]

Anyway, this is my third option, to simply upgrade the iBook and keep using it. I have to figure out what trade-offs I'm going to make, but, other than that, this appears to be the direction I'm taking. Since this post is becoming long, I'll post the pictures of the process in another blog or two.

My fourth option was to get a VIA ultralight and spend the next month moving all my materials to apps that work fully in Linux. But that has the cost factor, as well. At this point, I'm still sitting at under JPY 20,000 (USD 200), to keep this machine running.

Monday, July 21, 2008

trust and certificate authorities

Ever heard of a certificate? No, I don't mean a teaching certificate. (Maybe I need to get one, but that's another story.) I mean the kind of certificate you sometimes see your web browser warning you is not up to date, or is assigned to some other url, or something even more incomprehensible.

Bill Gates, several years ago, finally half-grasped PKI and started selling his "web of trust" and his "trusted computing". Like most of what he sells, he borrowed a bunch of jargon from the industry, twisted a bunch of terms until the thing everyone else was having a hard time building became something his company could (claim to) build, sell, control, and, most importantly, sell control of. And the result is less than optimal, to say the least.

(Awfully close to random, Bill.)

PKI (Public Key Infrastructure) standards describe several structures of trust relationships. The easy to build structure is hierchical. The other structures are not just hard to build, but very hard to build and get right. Unfortunately, the hierarchical structure has a lot in common with the false royalism which the US was born in reaction against. Essentially, you trust the guy at the top of the heap because you think you have no options.

Except you don't really trust him, you just behave as if you do. Sort of. At the minimum level. Grudgingly. And every chance you get, you stick it to him. Because you don't really trust him. Or anyone in between him and you.

Hierarchies are good reporting structures, but are not good for much of anything else. Well, there is one hierarchy that is useful, but it's a really flat hierarchy: you and God.

(Now, if you have that hierarchy properly worked out, artificial trust structures become a bit superfluous.)

The actual relationship structures of trust are fairly simple to describe, but not easy to implement --

First, trust doesn't mean that you know the other guy will never let you down. It doesn't mean you know exactly what the person you trust will do. It only means you have a reasonably good idea. It also means that you accept, to a degree, the results and effects of that person's decisions.

You trust people you know. You don't trust them all equally, of course, but you know them, you know something about what they do, when, and how. So you can base your own choices on your expectations concerning them, to a certain extent.

How far can you trust the other guy? Only as far as you can throw him, according to the wag, and there is a certain meaning to that. It might be more hopeful to invert the action, however: Only as far as you don't have to reach to touch him.

People you know well, you tend to trust more, even if you know you can't trust them exactly the way you thought you wanted to.

A friend of a friend can't be given as much trust as the friend, without making the friend of a friend also a friend. Your friend may choose to act as a guarantor of his or her friend, but you aren't going to trust the guarantee more than the trust the guarantor.

You can extend trust, but until you have actual dealings and see the results, the trust is hypothetical.

Can you trust a friend of a friend of a friend? Is there some sort of formula that tells you how much to scale trust back as the relationship becomes farther away? Of course not. You'd be asking for a guarantor in hypotheses.

So, what does this have to do with computers?

PKI certificates are instruments conveying a substitute kind of trust. Kind of like there are sugar substitutes and food substitutes (My father used to call white bread "bread substitute".), you can substitute certification for trust. What they convey is actually (the witness of) a guarantee.

They are issued by "Certificate Authorities" of various sorts. The CAs don't guarantee much with these certificates. What they guarantee is only that someone identifying himself as so-and-so claimed such-and-such. For example, they might issue a software vendor a certificate that asserts that the software can use to claim they are the software vendor. Then, if you believe the CA, you have a pretty good reason to believe that any software that includes the certificate originated from the vendor.

The technology they work by is a separate subject, and worth exploring, but I'll leave that for another day. Encryption techniques make them at least partially useable in the present world. As long as the encryption isn't broken, as long as the person holding the secret key keeps the secret key secret, etc., they do function in conveying the witness of the guarantee.

If you're thinking this sounds a lot like what they call a CPA in the USA, well, you, that's pretty close to the idea.

I could maybe go to a CPA and show him my birth certificate and passport and get a certificate from he saying I should him those things and claimed certain things in front of him. (Or her. I think I know more women who are CPAs than men, but that is neither here nor there. I think. 8-/)

So, what do you do with these certificates?

Microsoft presently uses these certificates to attempt to prevent rogue software from installing itself in your MSWindows computer. (Not mine. At least at the time of this rant, I only have computers running Linux and Mac OS.)

In theory, the OS could be set to absolutely refuse to let a program that can't present a certificate from Microsoft to even run. In practice, getting those certificates into the right places imposes enough problems that it may not be possible to get the stuff you want certified.

That's always going to be a problem, but lets look at the certificates again. Do you know the CA?

Hmm. Well, you don't know the CPA in many cases, either. All you know is that a rogue CPA is likely to lose his or her license. And the certificate itself doesn't contain any means of ascertaining that issuing the certificate hasn't cost the CPA his or her license. You'd have to find the authority that certified the CPA to be sure.

PKI does contain a method for checking whether a certificate is valid and the issuer still certified to issue certificates, but the implementation is problematic. The flow of time, in fact, makes it impossible to perfectly check the certificates.

But the software you use behaves as if it (or you) can know whether these certificates are valid or not.

I'm not advocating ignoring the certificates. However, the infrastructure needs to be fixed, and that is part of the reason I don't bank on-line.

Okay, so how should these certificates work?

Right now, hardware can't be certified. Microsoft's Trusted Computing stuff notwithstanding, hardware can't be verified. Locked, but not verified.

It could be verifiable. Hardware could contain self-test functions, and it could contain the manufacturer's certificate, which it could be programmed to only present if the self-test passes. But, self-tests being tests self-administered, the only meaningful thing which could be known would be that the hardware either claims to pass the self-test, and claims to be manufactured by the owner of the certificate, or it doesn't.

So, all of the following is purely hypothetical. But here's what could theoretically be done.

The system bootstrap boots the various hardware the first time and collects the certificates. It then self-tests, and adds it's certificate to the bundle, in a certificate that claims to have booted and collected the certificates. It can do this because it "knows" the hardware. Each certificate contains a cryptographic token that (should) uniquely identify the actual piece of hardware in place. (Product number and serial number, encrypted against some reasonably complete operational image of the hardware.)

The bootstrap passes the certificate thus generated to the OS, which boots, self-tests, checks the hardware and bootstrap certificatesand builds its own certificate. It discards the hardware certificates when it bundles the boot-up certificate. Again, it adds cryptographic tokens.

If something fails in the process, the failed hardware should disable or limit itself, or be disabled, and the rest of the system should continue to boot as far as possible. Hopefully, enough of the system can boot far enough to tell the integrator (or, later, the user) what failed to boot and why.

The integrator, who should be a salesman you, the buyer, know, checks the certificate presented by the OS, and bundles the OS cert sans the bootup cert with his own, storing the certificate on the computer. Then he loads the optional software, all of which self-test and present their certificates to the OS and integrator for making more certificates. The OS certifies it all and stores another certificate keeping the result of the initial set of installations, bundled with the integrator's certificate. Later installations will again be certified, and all certificates kept.

Before the integrator turns it over to you, he certifies you as the new admin/integrator.

You, as the owner, can view every certificate. But when the computer goes on-line, the network only sees the overall certificate. Software connected to the computer can query the overall certificate and the certificate of the software it is communicating with. But the queries can be refused, particularly when operating on networks or functions where the identity of the computer or user is not required. (For example, browsing the internet, or window-shopping at some on-line shop, or watching movies at an on-line theatre, or practically any normal on-line activity.)

When you get the computer home (or to the office), if you add or remove either hardware or software, you repeat the certification process, since you are now the admin/integrator.

You can also add users, and you can make certificates for the users.

When you need to update stuff, you probably want to go to the guy who sold it to you, because he knows the guys upstream, and you don't really. (Unless you are running Fedora or Ubuntu, in which case, you are effectively your own integrator, and, hopefully, you at least monitor the announcement lists so that you can keep track of the guys upstream in a meaningful way.)

Ultimately, all this does is give the computer an identity and an associated administrator identity, together with a current user identity. Together, these identities can be used, for example, at a store, to help maintain an account, or at an on-line bank, to augment the banks identification processes. But they can only identify an on-line presence, and this is the way it should be. (Forgery is always possible, and it is building faults into any system to attempt to make it prove identity beyond possibility of forgery. I'll have to rant about the forgery issues at some point, later.)

Since your internet browsing computer terminal can't prove your idendity to the bank, how do you prove your identity to the bank?

You need a hardware token to do that. Think USB key, but think ethernet or Firewire, instead. This is because the token has to be able to be a bus master in order to establish a tunnel, and you need a tunnel because you simply cannot depend on a terminal that you don't have general physical control over. (Yeah, that means you need to keep your token in a safe place, just like you keep your wallet in a safe place.)

The hardware token is a very simple device, because the more complex a device is, the more bad certificates could be lurking in it. Preferably, it only has a cpu, ram, flash or some other kind of persistent store, a time keeping device, a small display and a small keyboard, and (in terms of present tech) an ethernet port. It would be tempting to put a calculator or cellphone on it, but that way lies dragons and dwarves and goblins and worse. Well, no, a simple calculator is likely to be useful enough to have on-board, but you have to think carefully about that.

And maybe phone? No. Turn that around. Wireless modem on the token, the primary phone functions on a handset that connects to the wireless network through the token. Well, maybe you have a separate token physically incorporated your phone, but it must have its own CPU, RAM, and flash. Preferably its own keyboard and screen, so that if your phone gets eaten by malware and installs a keyboard eavesdropper, what you type on the token keyboard won't be seen by the eavesdropper. No, just, keep the token off the phone.

If you do put a wireless modem on the token (in parallel with the ethernet port), you would want direct physical switches and indicators, so you could be sure that you know when it is on or off. You'll think you want to believe your token is safe from attack, but in the end (and I will have to rant about this sometime) it's just a piece of electronic paper with an automatic pen, and the more ways for people to connect with it without you seeing, the more time bad people have to attempt to get that automatic pen without you noticing.

Best way to do this is have the wireless phone provide a place to physically plug the token in, that gives the token a direct physical connection to the modem. Always best to keep the terminal separate from the token.

So, what does the token do?

You take it with you to the bank. The bank has a (secure) machine which jointly generates a one-time pad in the token. Jointly, because every one-time pad has to be completely different, or some mathematically inclined bad guy will reverse engineer the generator from the pad he or she is given.

Since you want the token for several different services, it has to have enough persistent (flash or whatever) store to save quite a few. (Credit cards, savings banks, stock brokers, video store, etc.) You browse on a terminal, you load the shopping cart on the terminal, then you go to checkout. The checkout counter software displays a connection url and a transaction code. You plug your token into a spare ethernet port near your terminal, and key the connection url into the token's keyboard. The token connects with the store over a cryptographic tunnel. The token displays the store's connection prompt and you key the transaction code in, and then the token tells you to key in the token's authorization ("pin") code, and the token and store exchange the credit information.

It seems like a long way around, when you presently just do the one-click stuff on Amazon, but the only reason Amazon is not riddled with fradulent transactions is that most of the bad guys are presently intelligent enough to not draw attention to what they can get away with. (As opposed to the guys who generate spam.)

Why?

It's simple. Your bank sort of knows you. The on-line store does not. Your computer at home sort of knows you, but it knows the web better, especially if it's hooked up to a constant-on broadband connection.

Trust is not transitive.

Religion vs. Religion

In various forums you find arguments about religion, which religion is better, which is less evil, atheism is obviously superior to religion (and the correct way to believe), us vs. them.

It's always at best an approximation to assert binary sets, but there are two kinds of religion: false and true.

That doesn't help the discussion, at all, does it?

Okay, there are two kinds of religion, one which turns a blind eye to truth, and one which seeks truth. And it's always the other guy's religion that turns a blind eye to truth.

Does that help?

Arguing against the other guy's religion is not a good way to communicate. (And I find myself in a dilemma any time I'm talking with someone who claims a religion which includes as a precept the requirement of arguing against all other religions.)

And discussing religion with atheists is a particularly difficult job, because the atheist has often really convinced himself that believing in the non-existence of any God is somehow automatically superior to believing in the existence of any God.

Well, some people resolve the problem by refusing to discuss religion.

I prefer to resolve the problem by looking for points in common. Some people find it threatening to even consider points in common, but it's generally much easier to communicate when there are points you can agree on, and I think communication is generally a good thing.

Well, it's hard to find points in common when you don't know the other guy's assumptions and definitions, so I'll put down some of the definitions and assumptions I operate by, which I think I can sort of hope to find common ground with.

Maybe in another post.