As I write this, the volume of spam in my e-mail accounts has dropped drastically. A couple of ISPs have cut certain of their customers' access to the 'net.
Colocation is supposed to be pretty neutral, but when your customers are sending commands to 'botnets from serveres you are colocating for them, you eventually know what's going on, and your contract does allow you to quit co-locating for them, and even turn their servers over to the police. And if you don't take action, that makes you an accessory to the crimes, so the ISPs that supply your connection are within their rights to cut you off.
So, two levels up, but the co-locators were cut off. Without the command centers, the 'bots don't know what to send to whom, and the volume of spam drops. Until the bad guys find another patsy to host their command centers. Only, this time, they'll find legitimate fronts, spread their command centers out, and so forth.
Junk e-mail is kind of like drugs. The only way we'll win the war against drugs is to quit buying them, quit using them. That means the war is won or lost, one person at a time.
The only way to win the war against junk e-mail is to refrain from doing business with them:
(1) Refrain from sending them e-mail (and thus confirmation that you are reading their illicit advertizing channel).
(2) Refrain from clicking the "Don't send me any more!" booby-trap buttons. (Yeah, right, we won't send you any more! hyuck, hyuck.)
(3) Refrain from clicking on the link to the "hot pictures". (Look at the url blank in your browser next time. See that code on the end? They look that code up in their database, and they know what address the mail was sent to. That's your address, you see?)
(4) Don't even look at the mail if the sender and the subject are obviously spam. (Forget sender notification. IFRAME leaks, anyone? Besides, if you don't look, you won't be tempted to buy, or even to look some more.)
(5) Oh. And never, never send them money or your credit card number or bank account information, etc. Don't send them anything. Not if they promise your next night of love-making will be more fulfilling. Not even if they promise that they have lots of money to give you for reason X, Y, or Z. This is organized crime you are dealing with.
You can win the war for yourself, and then you can encourage your friends to win the war for themselves.
I know that what I am proposing may be easier said than done. Maybe you aren't susceptible to letters that start out, "Dear sir or madaam. I am your long lost friend/relative/employer's ex-husband's cat's manicurist/prince-of-some-vaguely-familiar-sounding-country and I have lots of money from our mutual friend/relative/veterinarian/politician/whatever that is legitimately mine, but I can't get at it because of the weather/wars/economy/fleas on my dog and I need your help."
Maybe you are inoculated against that kind of scam. Maybe designer shoes or rip-offs at bargain prices do nothing for you. Maybe you have no fears about your love-life, or at least are well aware that a pill that may or may not make you sexually excited can't solve your social problems. How about expensive wrist-watches? Or the slightly odd, but maybe-not-so-really-terrible mail list that you suddenly found yourself signed up on?
In a sense, you have to get in touch with your conscience, have to develop a good sense of reality, have to get to know your God in order to tell which mail is legitimately worth looking at and which is not. Of course, now I'm making it sound really hard. So let's talk about it a different way.
What we are talking about is setting up filters in your mind:
(1) Check the sender. Do you recognize the sender? Family? Friend? Co-worker? Someone from Church?
On the other hand, do you recognize the sender as a source of stuff you didn't ask for? You know what to do with that.
(2) Don't recognize the sender, so check the subject.
v1A6or@ is not something you want a special price on, okay?
Free nude pictures of that famous hotty? If there are pictures at the site linked, you can be really sure that they've figured out a way to make you pay without you realizing it until you're out a bunch of money. Besides, she/he is not that hot, really. Not hot enough to expose yourself to even more spam.
And, no, you are not interested in letters that promise to tell you how totally awful the current president or president-elect or the last candidate of the opposition party really is.
Nor are you interested in good deals on designer this or that, credit cards or just credit or loans, or basically anything when you don't know the sender.
(3) Vaguely familiar name and a "Long time no see!" or something similar? That one may require looking at. There is a risk of IFRAMEs or similar ways to leak the information that you looked at it, but once you've seen the mail itself, well, a fuzzy GIF with stock prices or something is also not going to give you useful information. You do understand pump-and-dump, don't you? Nor is a cry of "I'm lonely!" from a girl or guy you don't know going to be legitimate, romantic movies notwithstanding. Most likely the picture is used without permission and the real sender is an ugly man or woman who wants, at minimum, to see if your e-mail address is valid. More likely, he or she wants your bank account information.
I should mention again, by the way, that giving money to criminals often makes you an accessory to their crimes. You do not want to do that.
(4) Sometimes, the sender name is one you really think you recognize. But if you look at the raw source code, you can usually see that the real sender is something else.
Now, if you can do that kind of filtering in your head, why can't we just set e-mail software up do that for us?
Well, we can, sort of. The problem is that the spammers know that, so they use little variations to get past the software filters. (Thus the v1A6or@, instead of viagra.) The automatic filters tend to catch more than you wanted them to. (This is what they mean by "false positives".) And then the automatic filters tend to dump all the probable spam in a single folder, so scanning through the positives for the rare false positive is only mitigated by the fact that you now know that almost all of it is stuff you don't want to see.
The automatic filters would be more effective if you could directly train them. For instance, if you could select a word, phrase or url in the sender, subject, or content fields, and click a "This is spam." button, the software could even make a folder for stuff that has that word, phrase, etc. in it. Scanning through a folder that contains mostly similar spam is going to be much more effective than scanning them all together. It also should reduce the false positives, because the guesses the software makes are more restricted in context.
There are other tricks, trap addresses, door-knocking mail addresses, and more. I wish I had time to program such a mail filter, but I don't seem to have that much time. And I have too many other interests, too.
Saturday, November 29, 2008
Friday, August 8, 2008
Looking Back to Go FORTH
A long, long time ago, back when dinasour mainframes roamed the earth, I was fresh back from my mission to Japan, trying to figure out what all LDS young men just back from their missions are trying to figure out: What do I do now?
But this little rant is less about that and more about one of the things I did. My brother, out of the kindness of his heart, gave me a 6800 prototyping board, I think it was the micro-chroma 68. Basically, it was the Radio Shack Color Computer, but with a 6800 instead of a 6809, or even a 6801. Okay, it was a 6802, but that was just a 6800 with some built-in RAM and ROM.
It's about 4000 miles away, so I can't post a picture, but that's okay. This rant is not so much about that piece of kit, either.
My brother dug up a ROM BASIC somewhere, but I wanted a better language. One of the teachers at the community college suggested FORTH, so I wrote off for the fig-FORTH model implementation for the 6800. The printout did not contain the object dump, so I had to go through the entire assembly listing and add the op-codes that had been abbreviated in the listing. I really did not think much of hand-assembling code at the time, writing it down seemed like more work than looking up the op-codes.
[I once had the insane urge to actually transcribe the source for that 6800 fig-FORTH. For a while, it was linked at forth.org, but they seem to have removed the link now. You can find it in the appropriate sub-directory of my 6800 assembler. Joel -- 2015-03-28]
I was silly enough to not build a floppy disk controller, but I did build a fast cassette tape controller, which was a little bit more reliable than the built-in 300 baud cassete tape controller. So I had some place to store the results after I typed the the entire model in in hexadecimal code. How long did it take? Don't remember, but it did seem like a long time, when I had friends and teachers playing around with the original IBM PCs, Apple ][s, and the like. Not to mention the time I wasted at Radio Shack playing around with the Color Computer demo models.
I don't think I can explain why I didn't just save up the money and get one of those Color Computers, with disk drive, etc. It sure would have saved me some time.
I think.
I played around with the FORTH, worked out the examples in Brodie's Starting Forth, as far as I could without disk drives. The dRAM was actually 64K, and I used a bit on the parallel port to toggle between banks, but I didn't really have the experience to figure out how I could usefully emulate a (very small, very volatile) floppy disk with it. So I was a little stuck on the disk examples. Also, the model provided hooks for implementing multi-tasking, but no actual implementation, so I wasn't able to play with that.
But I did learn enough FORTH to make me very impatient with other languages.
Fast forward to to when I got my associates and transferred to BYU. Found myself at the end of the BS-CS coursework with three class left, the one where you write a simple compiler, the one where you write a simple OS, and an elective. I was still spoiled by FORTH. (Maybe I still am.) Could not resign myself to stupidly hashing through simple closed algebrae and playing stupid register allocation games when I "knew" there was a better way. Kept trying to synthesize something useful from the two diametrically opposed approaches to computer languages, without the experience to know where the boundaries of object orientation were, to see where the difference between closed mathematical objects and infinite tape were always depositing me during my design attempts at random places in my own undefined memory.
Hey, I'm stronger for it. Right?
Anyway, those were my first flunked classes. I had, actually, a low A average to that point. Fortunately, BYU allows you to repeat classes. I took on the OS class first. Finally got up the courage and the wisdom to invest enough money to buy a Color Computer on sale, with Radio Shack's recommended cassette deck. (Yeah, I know about store recommendations, but it was also on sale. I could have saved another five dollars, but I'd have wasted a day running around.) Wrote screen routines and keyboard routines and time routines, and whatever else I could to pass the class.
The elective I chose was software tools. I went ahead and bought a disk drive and Radio Shack's disk-based assembler package, and implemented FORTH on the Color computer's 6809.
Actually, I got OS-9/6809 before I got the more basic assembler, and tried to do the FORTH in the OS-9 assembler, but found myself fighting with trying to make a relocatable FORTH, without fully understanding that I was effectively trying to define an i-code without actually pinning the codes down to specific values.
No, actually, I really did figure that out fairly quickly, but I just couldn't reconcile myself to the solution, you know, the one that put a 64K code limit on classes in early versions of Java -- Make the i-codes an index into an array, put the actual pointers in that array. Cry when you run out of array. Or not, if you never compile that many words.
One other option might have been possible, using self-relative i-codes. Needless to say, Microware's assembler would not assemble such a beast. For some reason, I declined writing an assembler that would. OS-9/6809's pre-ANSI C compiler might have been one of those reasons, or maybe I was just too lazy.
You have a similar problem when you try to use raw C language function pointers as i-codes. Most modern OSses relocate by keeping a list of addresses that need to be fixed up when the code is loaded. You can't help filling borked when you have to implement your own fix-up on an OS designed not to be fixed-up, and the fix-up table is as big as your object.
So I dropped my attempts to do it in OS-9, and went out and got the more primitive assembler software and worked with that. That way, I didn't have to think about relocation issues.
Once I had a simple enough implementation environment, the port was fairly straightforward. Or it should have been. First, assign the virtual registers of the FORTH model to real 6809 registers:
The return stack pointer, RP, was the 6809's call stack pointer, S.
The parameter stack pointer, SP, was the 6809's user stack pointer, U.
The i-code instruction pointer, IP, was the 6809's Y index, but I would sometimes save it off temporarily when I needed two index registers.
I put W on the top of the return stack, if I remember right. A little weird, but it was out-of-the-way, and still accessible.
You might think I'd use DP for the user variable pointer. But that sure was an awkward idea, DP being only the top eight bits. I ended up putting most (all) of the headerless primitive words in the DP and using DP relative jumps to get there, which was not a good idea, either. Oh. I also put the user variable pointer in the DP, too.
I designed the symbol table structure as a nested binary tree instead of using the more typical hashing techniques. That facilitated a certain amount of information hiding, for modularity and other object-ish behaviors.
Then I wrote the primitives, the inner interpreter, the basic parser, the symbol table lookup, the basic math. At a certain point, I had enough primitives that I could have finished off by just typing in the rest of the fig-forth high level model's compiled form. But the teacher wanted to be sure I was not just copying, so I re-wrote some of the stuff where it looked like 6809 object would actually be smaller than the high-level object. Used a kind of stupid-code-trick approach to shifting between high-level object and 6809 object on the fly (mostly stupid because shifting gears is not really a good idea, other than showing the teacher that you understand what it's doing at some level.
Once I had the 6800 model converted to 6809, with my modifications, I copied the fig editor source into a screens disk and had a running system. Source code was about a hundred 60-line pages, the object a bit fatter than I had expected, just over 8K if I remember right.
Then the teacher asked me to document every word in the model, so I did that. By hand. On paper. Don't know why I did it by hand, on paper. I later typed it into a text file, and that is also a part of the download on my site, linked again here, in case you missed it above. (Just what you always wanted, wasn't it?) All of that took me about six months, working pretty much full-time on the project. (Thanks go to my parents for letting me live in their attic for a while.)
[My personal website is now off-line until such time as I can afford $20 a year or so to pay dyn.com or someone else to resolve the url for me on an on-going basis, I guess. See the bif-c link below, and look in the appropriate subdirectory for the source code. -- Joel 2015-03-28]
I ended up passing my compiler class with a compiler written on that FORTH. So my education was all FORTH colored. Maybe that's why I just gave up on the industry about two and a half years ago. Maybe I can do something about it [link added 2 May 2011] while I'm taking a break.
But this little rant is less about that and more about one of the things I did. My brother, out of the kindness of his heart, gave me a 6800 prototyping board, I think it was the micro-chroma 68. Basically, it was the Radio Shack Color Computer, but with a 6800 instead of a 6809, or even a 6801. Okay, it was a 6802, but that was just a 6800 with some built-in RAM and ROM.
It's about 4000 miles away, so I can't post a picture, but that's okay. This rant is not so much about that piece of kit, either.
My brother dug up a ROM BASIC somewhere, but I wanted a better language. One of the teachers at the community college suggested FORTH, so I wrote off for the fig-FORTH model implementation for the 6800. The printout did not contain the object dump, so I had to go through the entire assembly listing and add the op-codes that had been abbreviated in the listing. I really did not think much of hand-assembling code at the time, writing it down seemed like more work than looking up the op-codes.
[I once had the insane urge to actually transcribe the source for that 6800 fig-FORTH. For a while, it was linked at forth.org, but they seem to have removed the link now. You can find it in the appropriate sub-directory of my 6800 assembler. Joel -- 2015-03-28]
I was silly enough to not build a floppy disk controller, but I did build a fast cassette tape controller, which was a little bit more reliable than the built-in 300 baud cassete tape controller. So I had some place to store the results after I typed the the entire model in in hexadecimal code. How long did it take? Don't remember, but it did seem like a long time, when I had friends and teachers playing around with the original IBM PCs, Apple ][s, and the like. Not to mention the time I wasted at Radio Shack playing around with the Color Computer demo models.
I don't think I can explain why I didn't just save up the money and get one of those Color Computers, with disk drive, etc. It sure would have saved me some time.
I think.
I played around with the FORTH, worked out the examples in Brodie's Starting Forth, as far as I could without disk drives. The dRAM was actually 64K, and I used a bit on the parallel port to toggle between banks, but I didn't really have the experience to figure out how I could usefully emulate a (very small, very volatile) floppy disk with it. So I was a little stuck on the disk examples. Also, the model provided hooks for implementing multi-tasking, but no actual implementation, so I wasn't able to play with that.
But I did learn enough FORTH to make me very impatient with other languages.
Fast forward to to when I got my associates and transferred to BYU. Found myself at the end of the BS-CS coursework with three class left, the one where you write a simple compiler, the one where you write a simple OS, and an elective. I was still spoiled by FORTH. (Maybe I still am.) Could not resign myself to stupidly hashing through simple closed algebrae and playing stupid register allocation games when I "knew" there was a better way. Kept trying to synthesize something useful from the two diametrically opposed approaches to computer languages, without the experience to know where the boundaries of object orientation were, to see where the difference between closed mathematical objects and infinite tape were always depositing me during my design attempts at random places in my own undefined memory.
Hey, I'm stronger for it. Right?
Anyway, those were my first flunked classes. I had, actually, a low A average to that point. Fortunately, BYU allows you to repeat classes. I took on the OS class first. Finally got up the courage and the wisdom to invest enough money to buy a Color Computer on sale, with Radio Shack's recommended cassette deck. (Yeah, I know about store recommendations, but it was also on sale. I could have saved another five dollars, but I'd have wasted a day running around.) Wrote screen routines and keyboard routines and time routines, and whatever else I could to pass the class.
The elective I chose was software tools. I went ahead and bought a disk drive and Radio Shack's disk-based assembler package, and implemented FORTH on the Color computer's 6809.
Actually, I got OS-9/6809 before I got the more basic assembler, and tried to do the FORTH in the OS-9 assembler, but found myself fighting with trying to make a relocatable FORTH, without fully understanding that I was effectively trying to define an i-code without actually pinning the codes down to specific values.
No, actually, I really did figure that out fairly quickly, but I just couldn't reconcile myself to the solution, you know, the one that put a 64K code limit on classes in early versions of Java -- Make the i-codes an index into an array, put the actual pointers in that array. Cry when you run out of array. Or not, if you never compile that many words.
One other option might have been possible, using self-relative i-codes. Needless to say, Microware's assembler would not assemble such a beast. For some reason, I declined writing an assembler that would. OS-9/6809's pre-ANSI C compiler might have been one of those reasons, or maybe I was just too lazy.
You have a similar problem when you try to use raw C language function pointers as i-codes. Most modern OSses relocate by keeping a list of addresses that need to be fixed up when the code is loaded. You can't help filling borked when you have to implement your own fix-up on an OS designed not to be fixed-up, and the fix-up table is as big as your object.
So I dropped my attempts to do it in OS-9, and went out and got the more primitive assembler software and worked with that. That way, I didn't have to think about relocation issues.
Once I had a simple enough implementation environment, the port was fairly straightforward. Or it should have been. First, assign the virtual registers of the FORTH model to real 6809 registers:
The return stack pointer, RP, was the 6809's call stack pointer, S.
The parameter stack pointer, SP, was the 6809's user stack pointer, U.
The i-code instruction pointer, IP, was the 6809's Y index, but I would sometimes save it off temporarily when I needed two index registers.
I put W on the top of the return stack, if I remember right. A little weird, but it was out-of-the-way, and still accessible.
You might think I'd use DP for the user variable pointer. But that sure was an awkward idea, DP being only the top eight bits. I ended up putting most (all) of the headerless primitive words in the DP and using DP relative jumps to get there, which was not a good idea, either. Oh. I also put the user variable pointer in the DP, too.
I designed the symbol table structure as a nested binary tree instead of using the more typical hashing techniques. That facilitated a certain amount of information hiding, for modularity and other object-ish behaviors.
Then I wrote the primitives, the inner interpreter, the basic parser, the symbol table lookup, the basic math. At a certain point, I had enough primitives that I could have finished off by just typing in the rest of the fig-forth high level model's compiled form. But the teacher wanted to be sure I was not just copying, so I re-wrote some of the stuff where it looked like 6809 object would actually be smaller than the high-level object. Used a kind of stupid-code-trick approach to shifting between high-level object and 6809 object on the fly (mostly stupid because shifting gears is not really a good idea, other than showing the teacher that you understand what it's doing at some level.
Once I had the 6800 model converted to 6809, with my modifications, I copied the fig editor source into a screens disk and had a running system. Source code was about a hundred 60-line pages, the object a bit fatter than I had expected, just over 8K if I remember right.
Then the teacher asked me to document every word in the model, so I did that. By hand. On paper. Don't know why I did it by hand, on paper. I later typed it into a text file, and that is also a part of the download on my site, linked again here, in case you missed it above. (Just what you always wanted, wasn't it?) All of that took me about six months, working pretty much full-time on the project. (Thanks go to my parents for letting me live in their attic for a while.)
[My personal website is now off-line until such time as I can afford $20 a year or so to pay dyn.com or someone else to resolve the url for me on an on-going basis, I guess. See the bif-c link below, and look in the appropriate subdirectory for the source code. -- Joel 2015-03-28]
I ended up passing my compiler class with a compiler written on that FORTH. So my education was all FORTH colored. Maybe that's why I just gave up on the industry about two and a half years ago. Maybe I can do something about it [link added 2 May 2011] while I'm taking a break.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
