Pushing String: XML haiku project:

Lauren has informed me (and the rest of the world) that the XML 2005 conference website had a problem accepting poster and artwork submissions. The deadline for both has been extended. If you had already filled out these forms, I’m afraid you’ll have to redo them (or, if you like, you can drop me a line if you’re just submitting artwork).

I figured I might as well take this opportunity to share a snapshot of my stitching project for this year’s conference. I already mentioned it’s sort of a sampler that has a haiku about XML parsing in it. I haven’t stitched the actual lettering yet, but you can see half of an “O” at the beginning of what I will admit is the third line of the poem. Any guesses? :-)

XML haiku project as of 28 October 2005

So far this has been a very enjoyable project. Here are some thoughts on the feel of this piece, along the lines of the analysis I did here for another project in February (which languishes unfinished, by the way).

• Under pressure. I’ve never cranked on stitching like this! If I get really desperate I may have to keep stitching through the beginning of the conference. Lynne Price did that when she first submitted her XML with Koalas piece; each day she’d return it to its display location with more done. She’s one fast stitcher…
• Small but pleasant selection of floss colors. I was a little bored doing the monochromatic border, with only a few tricky holes and the corners for relief. I can’t believe I completed the border first on the theory that it would be a quick way into the piece. That sucker took me about 20 hours! But it was the right decision since it gave me the interoperable framework (heh) that I could now fill in.
• Back to 14-count fabric. Yay! I was really killing my eyes on the siapo project at 18-ct. Of course, I’ve also since found out that I had incipient presbyopia by that point, so that explains a lot. Now I’ve got modern bifocals (they call them “progressive lenses” but I rather think they’re all about regression, don’t you?) and stitching is back to being a breeze.
• Huge canvas. I mentioned at the beginning of this project that the piece of fabric was so large that it’s hard to work with. I managed to figure out how to stitch on airplanes with it nonetheless, but it looks wrinkled right now because I work free-hand, without hoops or frames. They mar the fabric and they keep me from getting right close up to the location where I’m working. But that means I’m constantly rolling or even lightly crushing the fabric. It’ll all come out with a steam iron later (heck, that’s easier to smooth out than the original fold lines from when I got the fabric in the first place – I much prefer buying it in rolls for that reason).
• A hybrid design formed by adapting the work of a real professional. The main pattern came from Pat Emlet at Cross-Stitch-Art.com, who has some gorgeous designs, including –as noted on her home page – Oriental, Celtic, Art Nouveau, and Mackintosh styles. It was the Oriental angle that got me interested, and the pattern I selected even conveniently came with a “hole” for me to put my own wording in. Pat kindly also supplied me with a very cool Asian-style stitched font for my haiku. The trouble was, the haiku didn’t quite fit in the space, so I had to extend the border vertically by more than an inch; move the boat-against-the-sunset picture; ensure that the fabric that came with the kit I bought was big enough for the result; and transfer enough of the original design to my own online pattern to doublecheck that the whole thing hung together. This process was really really fun. (For some definition of fun.)
• Flying blind. Even though it was all designed by computer, I had no real idea how big this project was because I didn’t have a stitch count. Pat uses Pattern Maker software to design her pieces (which I first described here as the program that amusingly uses the .xsd file extension) and she sent me the files to work with in modifying the piece. But I only got the free viewer for Pattern Maker, which doesn’t allow you see stitch counts, and of course the portion that I designed in PC Stitch would give me an incomplete count. I’m starting to be able to eyeball the size of projects now, though.
• Process optimization. The thing that looks like a dashed line in the middle is a guideline that I’ll pull out soon. I’ve finally gotten smart about how to parcel off the work – the guideline corresponds exactly to the horizontal page boundary of my pattern printout, which runs to four pages, and to the 10x10 grid markings provided by the software (I already pulled out a vertical guide-line that I no longer need). Maybe that’s why I stitch – it gives me new ways to feel efficient!

I’m hoping that exposing my obsession with this pastime will inspire someone out there to say, “Hey, I could make something better-looking and more related to XML than that in far fewer hours, and I’m willing to come to Atlanta to show it off…”

(Via Pushing String.)

Schneier on Security: NIST Hash Workshop Liveblogging (3):

I continue to be impressed by the turnout at this workshop. There are lots of people here whom I haven't seen in a long time. It's like a cryptographers' family reunion.

The afternoon was devoted to cryptanalysis papers. Nothing earth-shattering; a lot of stuff that's real interesting to me and not very exciting to summarize.

The list of papers is here. NIST promises to put the actual papers online, but they make no promises as to when.

Right now there is a panel discussing how secure SHA-256 is. "How likely is SHA-256 to resist attack for the next ten years?" Some think it will be secure for that long, others think it will fall in five years or so. One person pointed out that if SHA-256 lasts ten years, it will be a world record for a hash function. The consensus is that any new hash function needs to last twenty years, though. It really seems unlikely that any hash function will last that long.

But the real issue is whether there will be any practical attacks. No one knows. Certainly there will be new cryptanalytic techniques developed, especially now that hash functions are a newly hot area for research. But will SHA-256 ever have an attack that's faster than 2⁸⁰?

Everyone thinks that SHA-1 with 160 rounds is a safer choice than SHA-256 truncated to 160 bits. The devil you know, I guess.

Niels Ferguson, in a comment from the floor, strongly suggested that NIST publish whatever analysis on SHA-256 it has. Since this is most likely by the NSA and classified, it would be a big deal. But I agree that it's essential for us to fully evaluate the hash function.

Tom Berson, in another comment, suggested that NIST not migrate to a single hash function, but certify multiple alternatives. This has the interesting side effect of forcing the algorithm agility issue. (We had this same debate regarding AES. Negatives are: 1) you're likely to have a system that is as strong as the weakest choice, and 2) industry will hate it.)

If there's a moral out of the first day of this workshop, it's that algorithm agility is an essential feature in any Internet protocol.

(Via Schneier on Security.)

Schneier on Security: NIST Hash Workshop Liveblogging (2):

In the morning we had a series of interesting papers: "Strengthening Digital Signatures via Randomized Hashing," by Halevi and Krawczyk; "Herding Hash Functions and the Nostradamus Attack," by Kelsey and Kohno; and "Collision-Resistant usage of MD5 and SHA-1 via Message Preprocessing," by Szydlo and Yin. The first and third papers are suggestions for modifying SHA-1 to make it more secure. The second paper discusses some fascinating and cool, but still theoretical, attacks on hash functions.

The last session before lunch was a panel discussion: "SHA-1: Practical Security Implications of Continued Use." The panel stressed that these are collision attacks and not pre-image attacks, and that many protocols simply don't care. Collision attacks are important for digital signatures, but less so for other uses of hash functions. On the other hand, this difference is only understood by cryptographers; there are issues if the public believes that SHA-1 is "broken."

Niels Ferguson pointed out that the big problem is MD5, which is still used everywhere. (Hell, DES is still everywhere.) It takes much longer to upgrade algorithms on the Internet than most people believe; Steve Bellovin says it takes about one year to get the change through the IETF, and another five to seven years to get it depoloyed. And that's after we all figure out which algorithm they should use.

Georg Illies gave a perspective from Germany, where there is a digital-signature law in effect. In addition to the technology, there are legal considerations that make it harder to switch.

The panel seemed to agree that it's still safe to use SHA-1 today, but that we need to start migrating to something better. It's way easier to change algorithms when you're not in the middle of a panic.

There was more talk about algorithm agility. This problem is larger than SHA. Our Internet protocols simply don't have a secure methodology for migrating from one cryptographic algorithm to another.

Bottom line: Don't use SHA-1 for anything new, and start moving away from it as soon as possible. To SHA-256, probably.

And now it's lunchtime.

(Via Schneier on Security.)

Schneier on Security: NIST Hash Workshop Liveblogging (1):

I'm in Gaithersburg, MD, at the Cryptographic Hash Workshop hosted by NIST. I'm impressed by the turnout; a lot of the right people are here.

Xiaoyun Wang, the cryptographer who broke SHA-1, spoke about her latest results. They are the same results Adi Shamir presented in her name at Crypto this year: a time complexity of 2⁶⁴.

(I first wrote about Wang's results here, and discussed their implications here. I wrote about results from Crypto here. Here are her two papers from Crypto: "Efficient Collision Search Attacks on SHA-0" and "Finding Collisions in the Full SHA-1 Collision Search Attacks on SHA1.")

Steve Bellovin is now talking about the problems associated with upgrading hash functions. He and his coauthor Eric Rescorla looked at S/MIME, TLS, IPSec (and IKE), and DNSSEC. Basically, these protocols can't change algorithms overnight; it has to happen gradually, over the course of years. So the protocols need some secure way to "switch hit": to use both the new and old hash functions during the transition period. This requires some sort of signaling, which the protocols don't do very well. (Bellovin's and Rescorla's paper is here.)

(Via Schneier on Security.)

Schneier on Security: DMCA Review:

The Copyright Office of the U.S. Library of Congress is conducting its required regular review of the anti-circumvention provisions of the Digital Millenium Copyright Act. Comments can be submitted over the Internet, and are due December 1st.

Good information on the DMCA can be found here, here, and here.

(Via Schneier on Security.)

Lessig Blog: bravo Microsoft:

It is a common (and very good complaint) that there are too many free and open source software licenses. Multiplicity weakens interoperability. Interoperability of innovation is key.

For sometime, Microsoft has been playing in this community. Its “Shared Source Initiative” has given at least some access to important Microsoft code.

Last week, Microsoft made a major announcement that will benefit the ecology of free and open source software licenses significantly. As described here, Microsoft has abandoned a ton of licenses, focusing its efforts on just three core licenses. Two of these three licenses — the MS-Community License (MS-CL), and the MS-Permissive License (MS-PL) are technically “free” licenses under the FSF’s definition of free. The third MS-Reference License (MS-RL) is a view-only license, not quite free, but valuable nonetheless.

This is fantastic news, reinforcing an ecology of free licenses.

(Via Lessig Blog.)

For shame, for shame.....

I was riding my bicycle to work this morning, when I came to the corner of Bedford and East Washington. At this corner, was two police cars and a fire truck. We were waiting at the green light while an ambulance pulled up. It seems that a car had hit a moped, causing damage, but no injury.

While I waited patiently, a bike passed me and pulled out to the corner, potentially interfering with the ambulance pulling in. The light in our direction turned red as we waited for the ambulance, so I contented myself with rubber-necking at the accident site.

Not content to wait, the other biker waited for the traffic to clear, and ran the red light. The intersection was currently filled with: 2 police cars, three cops, a fire truck, and and ambulance, because someone had just been hit by a car.

Does this seem ridiculous to anybody else? Is it just me or should common sense to:

1. Not run red lights
2. Especially when there are police present
3. Especially especially when the police are present because someone else was recently hit by a car?

Besides, I thought the City of Madison and University of Wisconsin-Madison were moving to more strictly enforce Bicycle and Moped road laws?

EFF: Breaking News: Secret Code in Color Printers Lets Government Track You:

Tiny Dots Show Where and When You Made Your Print

San Francisco - A research team led by the Electronic Frontier Foundation (EFF) recently broke the code behind tiny tracking dots that some color laser printers secretly hide in every document.

The U.S. Secret Service admitted that the tracking information is part of a deal struck with selected color laser printer manufacturers, ostensibly to identify counterfeiters. However, the nature of the private information encoded in each document was not previously known.

"We've found that the dots from at least one line of printers encode the date and time your document was printed, as well as the serial number of the printer," said EFF Staff Technologist Seth David Schoen.

You can see the dots on color prints from machines made by Xerox, Canon, and other manufacturers (for a list of the printers we investigated so far, see: http://www.eff.org/Privacy/printers/list.php). The dots are yellow, less than one millimeter in diameter, and are typically repeated over each page of a document. In order to see the pattern, you need a blue light, a magnifying glass, or a microscope (for instructions on how to see the dots, see: http://www.eff.org/Privacy/printers/docucolor/).

EFF and its partners began its project to break the printer code with the Xerox DocuColor line. Researchers Schoen, EFF intern Robert Lee, and volunteers Patrick Murphy and Joel Alwen compared dots from test pages sent in by EFF supporters, noting similarities and differences in their arrangement, and then found a simple way to read the pattern.

"So far, we've only broken the code for Xerox DocuColor printers," said Schoen. "But we believe that other models from other manufacturers include the same personally identifiable information in their tracking dots."

You can decode your own Xerox DocuColor prints using EFF's automated program at http://www.eff.org/Privacy/printers/docucolor/index.php#program.

Xerox previously admitted that it provided these tracking dots to the government, but indicated that only the Secret Service had the ability to read the code. The Secret Service maintains that it only uses the information for criminal counterfeit investigations. However, there are no laws to prevent the government from abusing this information.

"Underground democracy movements that produce political or religious pamphlets and flyers, like the Russian samizdat of the 1980s, will always need the anonymity of simple paper documents, but this technology makes it easier for governments to find dissenters," said EFF Senior Staff Attorney Lee Tien. "Even worse, it shows how the government and private industry make backroom deals to weaken our privacy by compromising everyday equipment like printers. The logical next question is: what other deals have been or are being made to ensure that our technology rats on us?"

EFF is still working on cracking the codes from other printers and we need the public's help. Find out how you can make your own test pages to be included in our research at http://www.eff.org/Privacy/printers/wp.php#testsheets.

Contact:

Seth Schoen
Staff Technologist
Electronic Frontier Foundation
seth@eff.org

(Via EFF: Breaking News.)

EFF: Breaking News: Court Issues Surveillance Smack-Down to Justice Department:

No Cell Phone Location Tracking Without Probable Cause

New York - Agreeing with a brief submitted by EFF, a federal judge forcefully rejected the government's request to track the location of a mobile phone user without a warrant.

Strongly reaffirming an earlier decision, Federal Magistrate James Orenstein in New York comprehensively smacked down every argument made by the government in an extensive, fifty-seven page opinion issued this week. Judge Orenstein decided, as EFF has urged, that tracking cell phone users in real time required a showing of probable cause that a crime was being committed. Judge Orenstein's opinion was decisive, and referred to government arguments variously as "unsupported," "misleading," "contrived," and a "Hail Mary."

"This is a true victory for privacy in the digital age, where nearly any mobile communications device you use might be converted into a tracking device," said EFF Staff Attorney Kevin Bankston. "Combined with a similar decision this month from a federal court in Texas, I think we're seeing a trend—judges are starting to realize that when it comes to surveillance issues, the DOJ has been pulling the wool over their eyes for far too long."

Earlier this month, a magistrate judge in Texas, following the lead of Orenstein's original decision, published his own decision denying a government application for a cell phone tracking order. That ruling, along with Judge Orenstein's two decisions, revealed that the DOJ has routinely been securing court orders for real-time cell phone tracking without probable cause and without any law authorizing the surveillance.

"The Justice Department's abuse of the law here is probably just the tip of the iceberg," said EFF Staff Attorney Kurt Opsahl. "The routine transformation of your mobile phone into a tracking device, without any legal authority, raises an obvious and very troubling question: what other new surveillance powers has the government been creating out of whole cloth and how long have they been getting away with it?"

The government is expected to appeal both decisions and EFF intends to participate as a friend of the court in each case.

You can read the full text of Judge Orenstein's new opinion, and the similar Texas opinion, at http://www.eff.org/legal/cases/USA_v_PenRegister.

Contacts:

Kevin Bankston
Staff Attorney
Electronic Frontier Foundation
bankston@eff.org

Kurt Opsahl
Staff Attorney
Electronic Frontier Foundation
kurt@eff.org

(Via EFF: Breaking News.)

Between the Lines: Identity and presence:

Apple's new iTunes puts the difference between digital identity and presence into sharp relief. Over at Tom on Identity, Tom points out that because he lives in the UK, iTunes won't let him download songs, let alone TV shows. Tom says: It is assumed that because I live in the UK, [...]

(Via Between the Lines.)

use Perl: New CGI::Application Wiki Released:

Mark Stosberg writes "The CGI::Application project is pleased to announce a new wiki for this MVC web application framework. It featured almost fifty pages of content at launch time. This comes on the heels of the 4.0 release, and a flurry of plugin activity. The new site has something from everyone, from those evaluating MVC frameworks, to experienced users looking for a power tip or a new plugin."

(Via use Perl.)

Schneier on Security: Scandinavian Attack Against Two-Factor Authentication:

I've repeatedly said that two-factor authentication won't stop phishing, because the attackers will simply modify their techniques to get around it. Here's an example where that has happened:

Scandinavian bank Nordea was forced to shut down part of its Web banking service for 12 hours last week following a phishing attack that specifically targeted its paper-based one-time password security system.

According to press reports, the scam targeted customers that access the Nordea Sweden Web banking site using a paper-based single-use password security system.

A blog posting by Finnish security firm F-Secure says recipients of the spam e-mail were directed to bogus Web sites but were also asked to enter their account details along with the next password on their list of one-time passwords issued to them by the bank on a "scratch sheet".

From F-Secure's blog:

The fake mails were explaining that Nordea is introducing new security measures, which can be accessed at www.nordea-se.com or www.nordea-bank.net (fake sites hosted in South Korea).

The fake sites looked fairly real. They were asking the user for his personal number, access code and the next available scratch code. Regardless of what you entered, the site would complain about the scratch code and asked you to try the next one. In reality the bad boys were trying to collect several scratch codes for their own use.

The Register also has a story.

Two-factor authentication won't stop identity theft, because identity theft is not an authentication problem. It's a transaction-security problem. I've written about that already. Solutions need to address the transactions directly, and my guess is that they'll be a combination of things. Some transactions will become more cumbersome. It will definitely be more cumbersome to get a new credit card. Back-end systems will be put in place to identify fraudulent transaction patterns. Look at credit card security; that's where you're going to find ideas for solutions to this problem.

Unfortunately, until financial institutions are liable for all the losses associated with identity theft, and not just their direct losses, we're not going to see a lot of these solutions. I've written about this before as well.

We got them for credit cards because Congress mandated that the banks were liable for all but the first $50 of fraudulent transactions.

EDITED TO ADD: Here's a related story. The Bank of New Zealand suspended Internet banking because of phishing concerns. Now there's a company that is taking the threat seriously.

(Via Schneier on Security.)

Schneier on Security: Electronic IDs:

Interesting commentary on digital identification cards.

(Via Schneier on Security.)

Leon Brocard: YAPC::Europe Day 3: Camelbones - Perl and Cocoa:

After a quick lunch (so sunny!), Mark Fowler presented Camelbones - Perl and Cocoa. This is really about using XCode and CamelBones to write native GUI apps on Mac OS X. He went through how to create simple apps (live demos!) and showed how easy it was to click and drag and create little applications. Interface Builder looks a bit fiddly to use (why would I ever control drag?) but the Perl side was neat.

(Via Planet Perl.)

brian d foy: Dear [fname],:

Here's a little program to generate those responses to marketing messages. I'm not really complaining (I am on the press list which kinda means I asked for it), but I think they could try a little harder (yes, I'm looking at you Black Duck. How about some text with those unloaded images?).

#!/usr/bin/perl

sub prompt
{
print "$_[0] >>> ";
chomp( my $response = <STDIN> );
$response;
}

%mad_libs = (
greeting => "What's a word you use to say hello?",
shill => "What do you call a marketing guy in a suit?",
verb => "What does Nat do with a sheep?",
animal => "What's your favorite animal?",
orifice => "Name a hole in your body.",
false => "How do you say goodbye?",
name => "What's your name?",
address => "Where do you live?",
);

foreach my $key ( keys %mad_libs )
{
$input->{$key} = prompt( $mad_libs{$key} );
}

######
use Template;

my $tt = Template->new();

my $template = do { local $/; <DATA> };

$tt->process( \$template, $input ) || die $tt->error;

__DATA__
[% greeting %] [% shill %],

Go [% verb %] a [% animal %] in the [% orifice %].

[% false %],

[% name %]

P.S. Please send review copies to [% address %]

A sample run:

How do you say goodbye? >>> Ta Ta
What do you call a marketing guy in a suit? >>> Flak
What's a word you use to say hello? >>> Ahoy
What's your name? >>> brian d foy
Name a hole in your body. >>> nostril
What does Nat do with a sheep? >>> caress
What's your favorite animal? >>> weasel
Where do you live? >>> Chicago

And the output:

Ahoy Flak,

Go caress a weasel in the nostril.

Ta Ta,

brian d foy

P.S. Please send review copies to Chicago

To any marketeers out there: feel free to use this code all you like. It's in the public domain. The support contract, however, is a different matter.

(Via Planet Perl.)

Concurring Opinions: Making Universities Pay for Government Surveillance:

In 1994, Congress passed a law called the Communications Assistance for Law Enforcement Act (CALEA), which requires telecommunication providers to build wiretapping and surveillance capabilities for law enforcement officials into their new technologies.

A recent rulemaking by the Federal Communications Commission (FCC) significanty expands the reach of CALEA beyond telephone companies and ISPs:

The federal government, vastly extending the reach of an 11-year-old law, is requiring hundreds of universities, online communications companies and cities to overhaul their Internet computer networks to make it easier for law enforcement authorities to monitor e-mail and other online communications.

The action, which the government says is intended to help catch terrorists and other criminals, has unleashed protests and the threat of lawsuits from universities, which argue that it will cost them at least $7 billion while doing little to apprehend lawbreakers. . . .

The order, issued by the Federal Communications Commission in August and first published in the Federal Register last week, extends the provisions of a 1994 wiretap law not only to universities, but also to libraries, airports providing wireless service and commercial Internet access providers.

It also applies to municipalities that provide Internet access to residents, be they rural towns or cities like Philadelphia and San Francisco, which have plans to build their own Net access networks.

Shouldn't the government be paying these costs? Why should the government be imposing this quasi-tax on those providing communications services?

According to the article:

If law enforcement officials obtain a court order to monitor the Internet communications of someone at a university, the current approach is to work quietly with campus officials to single out specific sites and install the equipment needed to carry out the surveillance. This low-tech approach has worked well in the past, officials at several campuses said.

But the federal law would apply a high-tech approach, enabling law enforcement to monitor communications at campuses from remote locations at the turn of a switch.

It would require universities to re-engineer their networks so that every Net access point would send all communications not directly onto the Internet, but first to a network operations center where the data packets could be stitched together into a single package for delivery to law enforcement, university officials said.

It is certainly true that new technology can erode the government's ability to engage in surveillance. It can also enhance the government's surveillance capabilities too. Setting aside the issue of the merits of the government surveillance, the issue of who pays for it is also a very important one. Placing the costs on those developing or supplying the technology can severely hinder the development of technology and its use. And saddling such a large financial burden on educational institutions at a time of rapidly rising education costs strikes me as very unwise and troublesome.

(Via Concurring Opinions.)

Schneier on Security: ATM Fraud and British Banks:

An absolutely great story about phantom ATM withdrawals and British banking from the early 90s. (The story is from the early 90s; it has just become public now.) Read how a very brittle security system, coupled with banks using the legal system to avoid fixing the problem, resulted in lots of innocent people losing money to phantom withdrawals. Read how lucky everyone was that the catastrophic security problem was never discovered by criminals. It's an amazing story.

See also Ross Anderson's page on phantom withdrawals.

Oh, and Alistair Kelman assures me that he did not charge 1,750 pounds per hour, only 450 pounds per hour.

(Via Schneier on Security.)

Leon Brocard: YAPC::Europe Day 3: Pod::WSDL

Leon Brocard: YAPC::Europe Day 3: Pod::WSDL...:

Tarek Ahmed presented Pod::WSDL - Generating WSDLs Using pod Markup. The problem is the difference between Perl's dynamic nature and WSDL's strict typping. The solution offered by Pod::WSDL is putting specific Pod detailing the types next to the methods and using that to generate the WSDL. Seems a neat solution.

(Via Planet Perl.)

use Perl: Annotating CPAN:

itub writes 'AnnoCPAN lets you view the documentation for CPAN modules. What makes AnnoCPAN special? It provides annotations on the margins, which are added by the users (that means you!). Also see the perl.com article.'

(Via use Perl.)

Curtis Poe: Top Ten Gripes for the Day:

Here's my list of 'Top Ten Gripes for the Day'. Some of these apply to me.

1. It's OK to use an object as a glorified struct if all you care about is the data domain.
2. Stop talking about 'strong and weak' typing. Most programmers (including me) don't know what those mean anyway. Talk about 'typing the variable' versus 'typing the data'.
3. If you use words like 'always' and 'never', you're probably wrong.
4. Don't casually dismiss languages and paradigms you haven't programmed in.
5. Don't create a specification 'variant' if you can't correctly explain why the specification doesn't suit your needs.
6. Don't say 'that's not OO'. There are too many conflicting viewpoints of what OO is for you to have the hubris of saying all others are wrong.
7. Java is not as bad as non-Java programmers make it out to be.
8. Same goes for Perl.
9. Don't tell me why you're violating third normal form if you can't explain what third normal form is. (This is a special case of #5 because it really scrapes the frosting off my Pop-Tart).
10. Maybe you think they're stupid, but people have reasons for their opinions.

Add your own!

(Via Planet Perl.)

Planet Perl: Perlmeme.org - a Site for Perl Beginners:

Shlomi Fish writes 'There's a new web-site called perlmeme.org. It aims to answer the question 'Where can I learn about Perl?' and provides FAQs, HOWTOs and Tutorials for beginners. It aims to provide more beginner-friendly documentation than the core Perl or CPAN documentation. The perlmeme.org people are always looking for new material and for help with the site. If you want to help, have material which you believe may be suitable or at least want to give some input head over to the web-site workers' page over at SourceForge, join the mailing list, checkout the source, etc.'

(Via Planet Perl.)

Slashdot: Too Many Passwords:

LK3 writes 'A survey of 1700 technology end users in the United States released today reveals some interesting findings about password management habits. 'The results suggest that having to juggle multiple passwords causes users to compensate with risky security techniques and creates a drain on productivity by taxing the resources of IT support centers.' Further, corporate requirements of frequent password replacement further exacerbates the toll on human memory. Is the solution a master password, with all of the potential problems that represents, or biometrics, or are we stuck with post-it notes and a call to the help desk?'"

(Via Slashdot.)

Perl.com: OSCON 4.5: Extreme Perl Makeover:

Peter Scott explains what to do when you take over maintenance of truly horrid Perl code.

(Via Perl.com.)

Perl.com: Perl Needs Better Tools: "

Perl is a fantastic language for getting your work done. It's flexible, forgiving, malleable, and dynamic. Why shouldn't it have good, powerful tools? Are Perl development tools behind those of other, perhaps less-capable languages? J. Matisse Enzer argues that Perl needs better tools, and explains what those tools should do."

(Via Perl.com.)

Schneier on Security: Secret Forensic Codes in Color Laser Printers:

Many color laser printers embed secret information in every page they print, basically to identify you by. Here, the EFF has cracked the code of the Xerox DocuColor series of printers.

The DocuColor series prints a rectangular grid of 15 by 8 miniscule yellow dots on every color page. The same grid is printed repeatedly over the entire page, but the repetitions of the grid are offset slightly from one another so that each grid is separated from the others. The grid is printed parallel to the edges of the page, and the offset of the grid from the edges of the page seems to vary. These dots encode up to 14 7-bit bytes of tracking information, plus row and column parity for error correction. Typically, about four of these bytes were unused (depending on printer model), giving 10 bytes of useful data. Below, we explain how to extract serial number, date, and time from these dots. Following the explanation, we implement the decoding process in an interactive computer program.

Because of their limited contrast with the background, the forensic dots are not usually visible to the naked eye under white light. They can be made visible by magnification (using a magnifying glass or microscope), or by illuminating the page with blue instead of white light. Pure blue light causes the yellow dots to appear black. It can be helpful to use magnification together with illumination under blue light, although most individuals with good vision will be able to see the dots distinctly using either technique by itself.

EDITED TO ADD: New story here.

EDITED TO ADD: And another.

(Via Schneier on Security.)

Schneier on Security: U.S. Regulators Require Two-Factor Authentication for Banks:

Two-factor authentication is coming to U.S. banks:

Federal regulators will require banks to strengthen security for Internet customers through authentication that goes beyond mere user names and passwords, which have become too easy for criminals to exploit.

Bank Web sites are expected to adopt some form of 'two-factor' authentication by the end of 2006, regulators with the Federal Financial Institutions Examination Council said in a letter to banks last week.

Here's more details.

This won't help. It'll change the tactics of the criminals, but won't make them go away. I've written about that already (the short version is that two-factor authentication won't mitigate identity theft, because it's not an authentication problem -- it's a problem with fraudulent transactions), and also about what will solve the problem.

(Via Schneier on Security.)

Schneier on Security: Liabilities and Software Vulnerabilities:

My fourth column for Wired discusses liability for software vulnerabilities. Howard Schmidt argued that individual programmers should be liable for vulnerabilities in their code. (There's a SlashDot thread on Schmidt's comments.) I say that it should be the software vendors that should be liable, not the individual programmers.

Click on the essay for the whole argument, but here's the critical point:

If end users can sue software manufacturers for product defects, then the cost of those defects to the software manufacturers rises. Manufacturers are now paying the true economic cost for poor software, and not just a piece of it. So when they're balancing the cost of making their software secure versus the cost of leaving their software insecure, there are more costs on the latter side. This will provide an incentive for them to make their software more secure.

To be sure, making software more secure will cost money, and manufacturers will have to pass those costs on to users in the form of higher prices. But users are already paying extra costs for insecure software: costs of third-party security products, costs of consultants and security-services companies, direct and indirect costs of losses. Making software manufacturers liable moves those costs around, and as a byproduct causes the quality of software to improve.

This is why Schmidt's idea won't work. He wants individual software developers to be liable, and not the corporations. This will certainly give pissed-off users someone to sue, but it won't reduce the externality and it won't result in more-secure software.

EDITED TO ADD: Dan Farber has a good commentary on my essay. He says I got Schmidt wrong, that Schmidt wants programmers to be accountable but not liable. Be that as it may, I still think that making software vendors liable is a good idea.

There has been some confusion about this in the comments, that somehow this means that software vendors will be expected to achieve perfection and that they will be 100% liable for anything short of that. Clearly that's rediculous, and that's not the way liabilities work. But equally rediculous is the notion that software vendors should be 0% liable for defects. Somewhere in the middle there is a reasonable amount of liablity, and that's what I want the courts to figure out.

(Via Schneier on Security.)

Schneier on Security: A "Typical" Terrorist:

A simply horrible lead sentence in a Manila Times story:

If you see a man aged 17 to 35, wearing a ball cap, carrying a backpack, clutching a cellular phone and acting uneasily, chances are he is a terrorist.

Let's see: Approximately 4.5 million people use the New York City subway every day. Assume that the above profile fits 1% of them. Does that mean that there are 25,000 terrorists riding the New York City subways every single day? Seems unlikely.

The rest of the article gets better, but still....

At least that is how the National Capital Regional Police Office (NCRPO) has 'profiled' a terrorist.

Sr. Supt. Felipe Rojas Jr., chief of the NCRPO Regional Intelligence and Investigation Division (RIID), said Friday that his group came up with the profile based on the descriptions of witnesses in previous bombings.

Rojas said the US Federal Bureau of Investigation has a similar terrorist profile.

But a source in the intelligence community derided the profile, calling it stereotyped and inaccurate.

The police profile does not apply to the female bombers who the military said were being trained for suicide missions in Metro Manila.

(Via Schneier on Security.)