Today an discussion rised up in #debian-devel on the OFTC IRC Network. It started because someone noted the bug report #501318 which is, to summarize it, just a user mistake, because someone obviously read the man page (time(1)) for the /usr/bin/time command, while time is also a shell builtin (which does not accept the same arguments as the time command. Certainly this bug reports appears to be funny at the first sight, but on the other hand, there is a suboptimal situation that leads to this.

1. There are some builtin commands that also have binary equivalents (like time, printf, echo). Its quiet easy to tell weither the one or the other is used, by using the which command, but thats not really a realistic workflow, so its better to know this. The difference between these commands is often causing problems, which we have to cope with. For example bashs builtin echo behaves different as /bin/echo and people who use the bash as their default shell tend to use what bash provides, which in turn causes problems if other people who use a different default shell try to work with these scripts. But this is another problem, because...
   
2. ... every program, utility and function in Debian has to provide a manpage, as said by our policy: "Each program, utility, and function should have an associated manual page included in the same package." I guess that the rationale behind that is that 'man' is a very common tool in the Un*x world, which is wide-spread and which usage is much recommended to find out how specific tools behave. It is always referred to in Documentation, weither it is Debian specific or not, e.g. in books.
   
   The time package, which is of priority Standard and which includes /usr/bin/time, does conform to that policy by providing a manpage for the time command. The various shells don't do that, because they usually don't have a man page for each and every command (usually they have a more generic manpage which includes the builtins or in some seldom cases a special manpage for such and similar things (as for zsh, which has zshmisc(1)) and because its not that easy, because the man command cannot (AFAIK) distinguish between the user joey_average calling 'man time' in a bash, while the user schoenfeld calls the command 'man time' in a zsh, or if joey_foobar calls 'man read' in a shell which does not have a builtin time command and uses /usr/bin/time instead.
   

So whats wrong about this situation? Would you say that users that expect 'man time' (or similar examples) to do the right thing are making wrong assumptions? I disagree. Its what they've always been told to do. And if it does not show anything eventually run info, or look at HTML documentation or what else. But they haven't been prepared for the case where the manpages does show something, something wrong. The good thing is that the manpage for time includes a sentence:

"Users of the bash shell need to use an explicit path in order to run the external time command and not the shell builtin variant."

The bad thing about it is, that it is at approx. 70-80% of the manpage.

Clint, the maintainer of zsh, mentioned run-help which seems to be a part of the zsh, but not of any other shell, and does more or less the right thing (at least for the builtins) but not for external commands and not even for itself (it opens the code of the function instead of something user-readable like a manpage). I guess "one tool for a specific need" is a good maxime, but is it really a good maxime for finding documentation?

But how could the situation be bettered? I could think of a wrapper for man, similar to run-help but as a more generic solution. Any ideas for it? Is it the right way at all to better the users experience? Any other ideas? Other opinions?

While incorporating some of the podlators fixes into the Perl that will be released with lenny, Niko Tyni found more problems with the current implementation. I'd written the test suite to force the output encoding on the file handle used by Pod::Man and Pod::Text, but pod2man and pod2text weren't doing that, and hence the output wasn't properly encoded. I'm finding Perl's Unicode support very tricky, particularly if I want to support the PERL_UNICODE option that adds input and output encodings on all file handles. I can't use encode before output because PERL_UNICODE encoding layers will then double-encode. The approach taken in this release is to force the appropriate output encoding on the output file handle (possibly destroying caller state). This works, but it's ugly. Pod::Text had another problem. Its historic behavior is to copy the input encoding to the output, but doing that with properly-tagged UTF-8 POD input means printing out wide characters in the internal encoding, resulting in Perl warnings. This version now, in the absence of the utf8 option, forces the output encoding to match the input encoding if possible. This seems like the best compromise and matches its historic behavior. pod2text now supports a --utf8 option since it's now useful to force a different output encoding. I wanted to get something out to stop the bleeding, but there are a few problems with the current approach. As mentioned above, I'm forcing file handle encoding layers, which may destroy encoding layers created by the caller that were intentional. This implementation also depends on PerlIO support, which is an optional Perl feature and not always enabled. I think the right long-term approach is to probe for PerlIO support, and if present, use it to check the encoding layer on the output file handle. If PerlIO is not set, or if no encoding layer is present, I can safely use encode before output, which doesn't mess with the file handle state and is much cleaner. If PerlIO is present and an output encoding is set, just trust that output encoding (although if the utf8 option is set and the output encoding is something else, it may be a good idea to throw a warning). I'm not sure when I'll have time to implement this, though, since it will require another reworking of the code and more testing, and I'm behind on a number of other projects. In any event, the current version will work for most people in most cases. You can get it from the podlators distribution page.

I received some feedback on my previous BeID post, where I explained how to log in to a remote system by use of your digital ID card. Philip and Guy both claim it possible or likely that the crypto keys on eID cards are stored on a system of the government somewhere and that you therefore should not be using them. I find this to be jumping the gun a little. Security is always a trade-off; indeed, if you want to hide stuff from the government, then using eID-based authentication might not be a very good idea. However, there are other cases where eID-based authentication really is the correct option; and it is nice to know that this kind of thing is possible. Security always is a trade-off; and if you make an informed choice, there's nothing wrong about giving someone else access to your server. The fun bit is that Philip actually advocates carrying a clear-text printout of a list of still-valid passwords. Now that, I feel, is unacceptable, security-wise. Personally, I'd rather use a smartcard that only some secret government agency might be keeping copies of rather than a list that any random thief might make use of. The question really boils down to this, I think: how likely do you think it is that someone else will be able to get at your password by guessing or stealing it?

• Using a password that's related to your person or someone near you, or is based on a dictionary: rather likely. There are scripts out there that will guess these passwords. Don't use them.
• Using a printout of a list of one-time passwords: somewhat less likely (they can't be guessed by script), but still not very hard (wallets get stolen by the hundreds every day, and it usually takes a while before one notices)
• Using smartcards with keys generated by someone else: somewhat unlikely (there may be a few people who know my private key, but one can't be sure of that; and, color me naive, but I tend to trust the government to abide by its own laws—for the most part—laws that prevent this kind of behavior)
• Using strong password: rather unlikely, provided you take care of them.

What I mean by that last bit is that you should always generate your passwords with a tool that generates fully-random passwords ('pwgen -s', for example), and never write them down in cleartext anywhere. That of course makes it slightly hardish to memorize them; what I do is to store the password encrypted to my GPG key on my laptop, and I memorize the password by changing it on a remote server that I need to access fairly often (Debian's systems will do), but leaving my GPG passphrase and laptop password as is for the time being. Every time I need to log in to the remote server, I first try to remember the passphrase. If I can't remember it, I look it up in the encrypted file (again taking care not to store the file on disk). Once I start being able to log in to the remote server without having to look it up in the file, I change all my other passwords. This process usually takes a few weeks. Then, the only way someone can get my password is either by coercing me or by killing me and disecting my brain. And then still. Unfortunately, in the real world, I realize that many people do not wish to go through all this trouble just to get a secure login, and instead just choose a weak password. I guess that's why I think the next best thing might be slightly better than using strong passwords...

The Omelette Post by Atul Chitnis provoked a lot of discussion and Christian Perrier's response explains the objections clearly. I disagree with them both in different ways. Hence this post. Atul Chitnis is not known for his politeness (unfortunately, like many in the FLOSS community). In such cases, it is best to try to understand the (positive) intent behind the words written rather than concentrate on the words themselves --- the current kabab mein haddi seems to be "low-hanging fruit". I agree with Christian that finding, analysing and fixing bugs ranks up there along with writing programs; especially since many of today's programmers continue to be ''bug-generators'' in the sense of (and in spite of) Dijkstra's article. My reading of the Omelette Post is that hacking should take precendence over talking at FOSS.in 2008 --- a sentiment that I find quite palatable and even tasty! So let's see if we can have a Debian Workout at FOSS.in 2008.

So last week, a relative commented to me that a solicitor sent a letter in reply to an email. I suggested that it might be because the email reply address was on one of the major free web email providers. “What’s wrong with my webmail?” So I explained… First of all, as far as I know, no Big Webmail service supports encrypted email (and there are complications in how you’d provide such a thing on webmail anyway) and it can be fairly easy to trick the webmail service into giving access to other people. My relative was sceptical, but within a day, US vice-presidential candidate Sarah Palin’s Yahoo mail was cracked and splashed across the news. (By the way - gov.palin counted as a personal email address? Huh? Her name isn’t “gov”.) Even without passwords going astray, there’s no telling that the intended recipient is the only person reading the email. Here’s a fun paragraph from the Google Mail Terms:-

“Google maintains and processes your Gmail account and its contents to provide the Gmail service to you and to improve our services. The Gmail service includes relevant advertising and related links based on the IP address, content of messages and other information related to your use of Gmail.” (emphasis added)

The Electronic Privacy Information Center suggests this includes wiretapping. There’s finally a growing awareness that free webmails are not safe, built on artificial anti-competitive encouragements like “you need a Yahoo!ID to subscribe to this yahoogroup” (no - the old “stick -subscribe after the group name, before the @” still works, just like it did before they bought it from egroups). Internet Psychologist Graham Jones writes:-

“It’s time to review your online security and think about whether you actually need Google and its like at all. Probably not.” (source)

I agree with that. Both of my phone companies (The Phone Co-op agency and 3) include webmail - although I have some personal domains (for long-term contactability), those webmails are fine for lists and short-term use. The sort of thing most people seem to use Big Webmail for. The other main point in my argument was that free webmails are unreliable, thanks to tactics like Yahoo’s shoddy anti-spam attacks on other mailservers. There’s no telling whether the email will get through such bad behaviour and delivery-receipts are unreliable. I can quite understand why a solicitor won’t send email to the likes of hotmail, even if I think it’s just as probable that the solicitor doesn’t “get” email. “Oh” said my relative. I think she’s still using Big Webmail though.

A case of a former friend impersonating someone on facebook was decided during the summer: Applause Store Productions Ltd. & Anor v Raphael [2008] EWHC 1781 (QB) (24 July 2008) . The victim was awarded thousands of pounds in damages. As I write this, there’s still no response on facebook’s news page, but I wonder whether Firsht will be to UK social networking what Godfrey was to UK Usenet. A bit of a wake-up - a reminder that the internet isn’t a consequence-free playpen. I know that more than most - my youthful indiscretions are plastered across the web, if you know where to look. Fortunately, cooperative associates seem to understand that people learn over time and don’t hold decade-old mistakes against me. Talking of not holding old mistakes against people, LinkedIn is profitting from an influx of bankers since the banks started going bust. That’s going to change the society behind their network - for better or worse? All of the big name networks seem to be having some growing pains, like the breakdown of the Facebook metaphor and I think the “walled gardens” are ripe for replacement. I’m still listed there at present, but I’m using my account on the cooperativemagazine NoseRub server to monitor it and most of the stuff posted to facebook is taken from my websites. I’d like to make NoseRub import and export more things in more formats, but will anyone pay for that work? Otherwise, it keeps falling down my priorities because it’s in PHP and I don’t find that much fun. Maybe I’ll replace it with something more amusing in Scheme or Perl. Aside: is there a good bot that produces an RSS feed of jabber/XMPP presence messages?

So, while everyone was watching the Bush Bank Bail-out plan get rejected by Congress, they also found time to approve more bad copyright law, an RIAA-backed initiative to attack cooperative download tools like BitTorrent. Thankfully, the attempt to empower the Department of Justice to prosecute on behalf of Big Music was lost (DoJ didn’t want the task anyway) and the Bush administration is minded to veto it. But that’s been the least of my politician annoyances in September. Earlier this year, we were encouraged by Cooperatives-UK to get involved with our Local Strategic Partnership. I went to North Somerset Partnership’s event but I was less than impressed by it. There’s no obvious way that NSP is capable of promoting cooperation. Publishing a thick glossy book about sustainability makes me wonder if it’s capable of doing anything sensible - most people I’ve shown it to have either laughed at it, or got angry about the wasted resources. They’re not the only LSP we have here. Last week, I went to the West of England Partnership’s Transport Forum which

“horrendously perverted the idea of a “forum” - the event would have been better titled “Joint Transport Lectures” because nearly all our time was spent watching council officers and consultants tell us how wonderful transport is here (they’re meeting 18 out of 21 targets, you know!) and what roads and bus roads they will build next. … The whole event seems like a colossal waste of resources for all involved.”

So, I seem to be having a bad time with politicians recently. If the above wasn’t enough, we got a reply to our petition requesting ODF at the National Archives which amazingly doesn’t mention Open Document Format at all. I’ve written to our MP (John Penrose) asking about that. And finally, I asked Climate Change Minister Joan Ruddock MP

“If there’s no windfall tax to fund it, how will the government remove the climate-harming services from the market and encourage new suppliers (particularly Third Sector ones who should show concern for their communities and sustainable energy) into the market?”

and got the non-answer of

“The Government is tackling a very wide range of issues that impact on Climate Change through a variety of mechanisms. The energy efficiency programme recently announced is directed at those most in need and where a small expenditure can produce a significant and lasting saving in energy use. Thus saving households money and reducing CO2 emissions.”

What the heck has that to do with removing harmful services and encouraging new suppliers? If any politicians want to be held in better esteem, try giving some straight answers instead of imitating the above, please. “Yes, Minister” was meant to be a satire!

Yes, it’s me again with this DSA-1571 exploitation issue. The discovery, explanation and exploitation of the bug is now part of my final coursework for my postgraduate degree career. So, yes… sorry. Some weeks ago I started suspecting about the attack to PFS in SSL with EDH. The key point is: the key space is dependent of the PRNG state. The bug affects the initialization of the PRNG, but the random string has not a pattern by it self. If you ask for many random numbers to the PRNG, you gonna get numbers that differ among them, since they are the output of a hash function of them self. So each random number depends on, besides the PID, the state of the PRNG pool in the moment (in other words, amount of bytes that you already pull from the PRNG pool before) The explained attack was based in a fixed list of private exponents (which are selected randomly during the DHE handshake), presupposing that all the application call RAND_bytes() the same number of times before get it. To make the list of exponent I ran the openssl s_client with all the possible PIDs, hoping that all the applications behaves the same way. After more tests I notice that that was an overgeneralization. The proof is in the pudding: wget and cURL, two simple CLI file retrievers, gets different exponent between them, even running with the same PID. I was working on this when I accidentally found a really nice Eric Rescorla’s post which is deeply related with this. The post goes further and analyzes the interaction between how Apache forks off and how it generates SSL handshakes. So, I made lists of secret exponents for wget, curl, openssl s_client and openssl s_server with a modification version of libssl (appling this patch) and running scripts like this:

for i in $(seq $((2**15)));
do
  export MAGICPID=$i;
  LD_LIBRARY_PATH="openssl.broken/" LD_PRELOAD="./getpid.so" \
     wget --no-check-certificate https://localhost/ -q  -O /dev/null ;
  echo $i ;
done

As you can see, I used the HD Moore’s GetPID faker shared library and a normal local Apache with mod_ssl. The broken libssl (which is in .openssl.broken/) store up in /tmp/data.key a csv with command name, PID and all the DH components (g, x, y and p). But this way is farly unconfortable for others SSL deamon servers. Have you got any better idea?

Some people troll free software lists with remarks like:

Linux will never be able to displace MacOS/Windows since the latter are much more pretty/user-friendly. You will lose.

Such people assume that hackers write free software because they "hate Microsoft" or "hate capitalism" or have some other pet hates. However, it should be obvious that such a large creative effort cannot be sustained if it is based on such negative emotions.¹ There are a number of positive reasons why one works on free software. The software that I like to work on is software² that I use or want to use. This has some consequences which are worth underlining:

• Contrary to the views expressed in some articles about free software, the theme of usability (by me!) is uppermost in my mind whenever I approach any task pertaining to software.
• Since the software I work on should be usable long after I have forgotten the ideas behind its implementation, the user interface should be one that confirms to "standard" expections. This means that it should be possible to use the software without reading the code.
• When I look at the code after a long time (for example to extend it in some way) I should be able to read and understand it, which requires clean code with adequate documentation.

Giving others the "four freedoms" results in wider critical examination of these aspects. Bugs must be acknowledged and fixed --- or elevated to features! Moreover, there are parts of the task that are "obvious" to me but I would have to ask others for advice on other parts. So I gain a lot by being part of a larger community. There are other reasons to write free software. For example, someone may pay you to do it. However, this is just deferring the same question to your employer. In most cases, your employer already has a use in mind for the software. The employer has the same concerns as I outlined above except that the job of writing the code is being out-sourced. The usability, portability and long-term maintainability are probably even bigger concerns for your employer. "Last but not the least" (as we always wrote in our school-day essays) free software is fun! You share ideas with people from across the globe and to show them your own clever little tricks. Good code and good themes resonate with people who may not even speak the same language as you do. What could be nicer than that!

Ten Easy Ways to Attract Women to Your Free Software Project? I am a little to sick with a cold now to say anything substantive. I agree in spirit with a lot of what the author says though I still think that part of the problem emerges way before the free software project. I still want to know, in other words, why girls/women are not hacking away at a younger age, which puts them at a disadvantage when and if they decided to join a project. Also, though the author as an important caveat in one of his footnotes:

[10] Throughout this article I make a lot of generalizations about how men and women behave. Obviously men and women are not monolithic groups, and there s a lot of variation, so this is just short hand. There are some important differences that apply in the real world, though, whether because of nature or nurture. Indeed, in writing this article, I have taken the assumption that many of the issues are really just manifestations of lifestyle differences, and it s largely because of lifestyle issues that I feel I can identify with many of the problems that women face when dealing with hacker culture in general and free software in particular.

I am still more than a little bothered by the essentialized portrayal of females/males and the concomicant technlogical determinism as well. Thoughts?

I finally managed to process all my mails and it's not time to push Gammu towards stable release. If everything goes without problems, the just born 1.20.93 will be followed by 1.21.0. Version 1.20.93 fixes several crashes with parsing strange data from phones and changes a bit initialization of FBUS protocols. If you are using this connection type, please test this new code whether it behaves better or worse than older version. Full list of changes:

• Fix crash when decoding EMS pictures (bug #549).
• Motorola phones sometimes reply in UCS2 instead of HEX (bug #712).
• Use native functions sleep/usleep if available.
• Improve FBUS initialization sequence.
• Fixed reading for ringtones from Nokia 5510 (bug #529).
• Do not crash if ringtone name is too long (bug #529).
• Fix possible crash while reading of messages using AT.
• Increase timeout when writing SMS message (bug #596).
• Cleaned up issues with reading from Bluez (bug #670).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.

For the impatient reader: New lintian in experimental, please test and give feedback. You will miss most changes though unless you read the rest of the post (Hint, Hint ;)) During the past week I've uploaded new lintian versions to experimental which we designated to be release candidates for 2.0.0. Code-wise the changes are not that much more intrusive than for many of our past releases, but they change the way lintian classifies tags in a fundamental way, thanks due to the hard work of Jord Polo in his Google Summer of Code project (mentored by Marc Brockschmidt). Lintian Tag Classification, old and new Previously lintian classified tags only in one dimension, in the categories "Info", "Warning", and "Error". While this worked reasonably well, the difference between the categories was not very well defined. The general idea was that everything violating a "must" in Debian Policy or endangering the building or usage of the package should be an "Error", i.e. something very similar to the definition of RC bugs (except that not all "must"s in Policy are deemed worthy of filing RC bugs). Some errors were downgraded to "Warning" or even "Info" though on the basis that their detection was too prone to false positives. Due to this it was a long existing desire to split the classification of tags into two dimensions, one for the impact/importance of the tag, and one for the certainty of its correct detection. This should make it easier for people to interpret and/or filter the output. At various points in the last few years people began to work on this but quickly gave up, usually overwhelmed by the sheer number of tags (728 in 2.0.0~rc2) to classify anew and to make sure that the old and new categorisation could exist side-by-side (because breaking backwards compatibility was not really feasible). Finally this year Jord Polo decided to tackle this task as a Google Summer of Code project, with great success. Tags are now classified in two dimensions "Severity" (with the possible values wishlist, minor, normal, important, serious, which are intentionally very close to the available severities in the Debian bug tracking system), and "Certainty" (possible values: wild-guess, possible, certain). A third classification by "Source" (i.e. Policy, Developers Reference, ...) is planned but not yet fully implemented. For backwards compatibility there is a mapping of these new classification to the old ones (which lead to a few reclassifications of tags). The default output of lintian is unchanged. The new output formats that support the classification are still experimental (see below). How to use it You can specify exactly which levels of Severity and Certainty you want to have displayed with the new --display-level (-L) option. Please see the manual page for the details, but to give you an idea, the default behaviour (i.e. "show warnings and errors" in the "old" vocabulary) is equivalent to specifying

-L ">=important" -L "+>=normal/possible" -L +minor/certain

And to get a report with only severe tags we're very certain of, you could use

-L ">=important/certain"

which will only display tags that have severity "important" or "serious" and a certainty of certain. There is also the (intentionally undocumented) option --exp-output which allows you to play with some experiments we're doing with the output format. --exp-output format=letterqualifier will give you an output very similar to the "classic" one, but with additional information about severity and certainty. --exp-output format=colons gives you a colon-separated format which includes all the possible information lintian currently has available during tag output and which should be easily machine-consumable. Note that these formats are experimental and might be changed at any point without notice. If you're interested in using alternative formats for lintian output, please join the mailing list and talk to us about it. Etc. Other changes include the usual share of bug fixes and of course: New tags

• description-contains-dh-make-perl-template
• doc-base-uses-applications-section (actually a split of doc-base-unknown-section in two tags)
• embedded-pear-module
• embedded-php-library
• improbable-bug-number-in-closes
• maintainer-also-in-uploaders
• maintainer-script-ignores-errors
• manpage-has-errors-from-pod2man
• ored-build-depends-on-obsolete-package (actually a split of build-depends-on-obsolete-package in two tags)
• package-superseded-by-perl
• versioned-dependency-satisfied-by-perl
• windows-devel-file-in-package

Credits This lintian release is brought to you by (sorted by number of changesets):

• Jord Polo
• Frank Lichtenheld
• Adam D. Barratt
• Raphael Geissert
• Russ Allbery
• Niko Tyni
• Marc 'HE' Brockschmidt

Yesterday on NPR's Diane Rehm show, one of the commentators made this point: (paraphrased)

The "bad debt" that all the banks are carrying, and that everyone talks about as the cause for this problem, is mortgage-backed securities. It's bad because there are so many foreclosures, meaning that people aren't paying back their loans. And that's a problem because the banks turn out to have a much less solid investment than they thought.

Instead of spending $100 billion or more bailing out bank after bank, the government ought to spend that money to stabilize the real estate sector. Invest it in programs to help people stay in their homes and avoid foreclosure. This will help both the individuals, and simultaneously fix the problems with the banks, because the mortgage-backed securities will regain their value.

Sounds way too sensible to do, doesn't it?

After all, we wouldn't want to encourage risky behavior on the part of the common folk that don't know better. No, we only want to encourage that with our large multi-national financial institutions that can wreck the entire economy.

Being an American guy married to an Italian woman and living in Austria, I don't really have a problem with "globalization". Actually, I'm something of a fan, which is one reason I'm disappointed in the globalization of Amazon's services. If you order a book from Amazon.com in the US, it will be shipped to you from the nearest shipment center. If you go to a large site like Google, Microsoft, or Yahoo, it's quite likely that they provide services in your language. Amazon, however, appears to be completely split up along country lines. Your amazon.com account is completely seperate from your amazon.co.uk account, and amazon.de isn't even available in English! This completely violates the sensible reasoning behind the two features outlined above. If you're somewhere like Italy or Denmark or Eastern Europe, you should be able to log in to amazon.com, in your language, order a book, and have it shipped from the nearest shipping center. Instead, you have to log in to each site (they don't share account info), which is only available in one language. So, for instance, an English speaking guy in Austria wanting to order books from the nearest country with an Amazon site goes to amazon.de and finds that there is no option to get the site in English. If I want to order from amazon.co.uk I have to enter all my login information from amazon.com again, and don't get the same recommendations and other features that come from Amazon knowing about my purchasing history.

A research conducted by Noel A. Card at the Universities of North Carolina and Kansas, that appears in the September / October issue of journal Child Development, challenges the popular misconception that indirect aggression is a female form of aggression. The meta-analysis is based on 148 studies of aggression in children and adolescents in schools, involving on the whole about 74,000 children and adolescents. Direct aggression is what we might call physical aggression, and indirect aggression includes covert behaviour designed to damage another individual’s social standing in his or her peer group. Based on the analysis, the researchers suggest that children who carry out one form of aggression may be inclined to carry out the other form. This is seen more in boys than in girls. The popular myth that girls are more likely to be socially aggressive has been proven wrong by this analysis, even though it has persisted among teachers, parents, and even among researchers, probably because of social expectations and recent movies and books portraying girls as mean and socially aggressive. They also found ties between both forms of aggression and adjustment problems. Direct aggression is related to problems like delinquency and ADHD-type symptoms, poor relationships with peers, and low prosocial behaviour such as helping and sharing, while indirect aggression is related to problems like depression and low self-esteem, as well as higher prosocial behaviour (perhaps because a child must use prosocial skills to encourage peers to exclude or gossip about others).

As someone who spends a lot, perhaps too much, time thinking, writing, and teaching about the politics of science and technology, I can’t help but feel flat out and down right infuriated when I read about the recent controversies concerning Bisphenol A (BPA), a chemical found in plastics and now suspected as playing a role in causing a small blizzard of health problems from type 2 diabetes to ADHD. Recently there have been a slew of tests and experiments that, while not conclusive, indicate that Bisphenol A may indeed be behind some ill health effects, reports of which pop up in the news at least every few weeks. And, yet the FDA has had the c*j*nes to declare the matter closed, they have ruled that Bisphenol A does not pose a hazard. (In their own words: “”safe and that exposure levels to BPA from food contact materials, including for infants and children, are below those that may cause health effects”) It seems like this not the time to unfurl such public declaration of confidence when clearly, if nothing else, the Jury is Out. No declaration is better than what the FDA has done. What is a least somewhat heartening is that recently the press, I think, has drawn on a panoply of experts, some of whom convey the danger and idiocy of letting the FDA be the ultimate arbiter in these (still) controversial matters:

Another expert, Dr. Rick Stahlhut, from the University of Rochester Medical Center in New York, agreed this study does not provide a causal link between BPA and heart disease and diabetes, but it’s the first step toward discovering such a link. “The findings are intriguing, but they have to be validated,” Stahlhut said. Stahlhut said he expects the controversy to continue. “It’s just like every other environmental exposure problem. We are always two decades behind. Ten to 20 years after the chemical is produced, suspicions start to rise. By then, it’s a multi-billion-dollar industry, and now there are forces whose job it is to keep it going — and that is what is happening now,” he said. Until all the facts are known about BPA, Stahlhut recommends not exposing yourself to things you do not need. Don’t take it for granted that because some “smiling guy on TV” says it’s OK, it is, he said.

Ubuntu is now being forced to show a EULA before letting users run Firefox, on pain of losing the rights to the Firefox trademark. (You know, End User License Agreements: those pop-ups Windows and Mac users have to put up with all the time, with the big “I Accept” button at the bottom.) Mark Shuttleworth, Ubuntu top dog, weighs in on the bug:

Please feel free to make constructive suggestions as to how we can meet Mozilla’s requirements while improving the user experience. It’s not constructive to say “WTF?”, nor is it constructive to rant and rave in allcaps. Your software freedoms are built on legal grounds, as are Mozilla’s rights in the Firefox trademark. To act as though your rights are being infringed misses the point of free software by a mile.

This is a bit surprising, and a bit disappointing. Both the decision itself, and Mark’s take on it, are quite wrong. One of the most important benefits of free software is the legal agreement you work in. You don’t have to agree to some long contract every time you need to do something new on your system, or sometimes even when you get a “critical update” to something you’re already doing. You don’t have to read pages of legalese, or go through some long process with your company’s legal department, or just click the “make it go away” button with this vague unease that you’ve just signed your first-born child away to the Devil. Most importantly, you feel like you actually own your computer when you run free software on it. When you enter a situation where you always have to ask permission to do things, and have to be constantly reminded of the rules, you don’t feel comfortable. Clearly, the thing in front of you is not yours, whatever your credit card bill might say; if it were, there wouldn’t be all this stress over you doing something the real owners don’t like. Free software returns your computer to you, by guaranteeing that you don’t have to enter into all these contracts before you can use it. Well, unless that “free” software is Firefox 3.0.2 or later, it seems. It’s “free” by a technical definition (you can strip the Firefox trademark rather easily, and get rid of the EULA as well). But when users fire up Ubuntu, and decide to do some browsing, and get confronted with pages of legal garbage and ALL CAPS, they will ask: “What’s so different about this open source stuff? I thought I was getting rid of all this legal crap.” And, suddenly, they’re slogging through the same drudgery they had to endure with every Windows service pack, and they wonder what they’ve gained. Perhaps there is a price we should be willing to pay to help Mozilla preserve their trademarks, but this price is too great. Mozilla should never have asked this of us, and Ubuntu should never have decided, on our behalf, that this price was acceptable. Debian has already turned its back on Firefox, and I have yet to have a problem with Iceweasel (the branding Debian chose for its Firefox-alike) that was caused by the branding change. But I’m tempted to bring it back, in Debian’s “non-free” software repository. Perhaps we could provide Firefox, complete with nasty EULA, but launch Iceweasel instead of Firefox if the user clicks “No”. There are probably all kinds of reasons why this is a bad idea, but I’m still drawn to the idea of illustrating how silly and useless click-through EULAs are. But it would be much more productive for Mozilla to back down, and not ask us to sacrifice such a large part of our identity on the altar of their sacred mark. UPDATE: First, I notice I was remiss in not giving a hat tip to Slashdot. Second, Mark has posted another comment on the bug. I encourage people to read the whole comment, but here’s a telling part:

For example, at the moment, we’re in detailed negotiations with a
company that makes a lot of popular hardware to release their drivers as
free software - they are currently proprietary. It would not be possible
to hold those negotiations if every step of the way turned into a public
discussion. And yet, engaging with that company both to make sure Ubuntu
works with its hardware and also to move them towards open source
drivers would seem to be precisely in keeping with our community values. In this case, we have been holding extensive, sensitive and complex
conversations with Mozilla. We strongly want to support their brand
(don’t forget this is one of the few companies that has successfully
taken free software to the dragons lair) and come to a reasonable
agreement. We want to do that in a way which is aligned with Ubuntu’s
values, and we have senior representatives of the project participating
in the dialogue and examining options for the implementation of those
agreements. Me. Matt Zimmerman. Colin Watson. Those people have earned
our trust.

On the one hand, yes, I believe that the Canonical people have earned our trust, and I do appreciate the utility of quiet persuasion with a proprietary software company that doesn’t understand our community. On the other hand, I had been under the impression that Mozilla was not a proprietary software company, and didn’t need persuasion and secret negotiations to see our point of view. Is Mozilla still a free software company, or not? UPDATE 2: Cautious optimism is appropriate, I think. Mitchell Baker, Mozilla chair:

We (meaning Mozilla) have shot ourselves in the foot here given the old, wrong content. So I hope we can have a discussion on this point, but I doubt we ll have a good one until we fix the other problems.

The actual changes aren’t available yet, and I wonder how much of this had been communicated to Canonical beforehand. Still, it’s a good sign.