The Daily Parker

Politics, Weather, Photography, and the Dog

Congress passes campaign-finance deform; White House can't take the heat

First, the House last night passed a campaign-finance package last night on a strict 218-209 party-line vote:

The House approved campaign finance legislation last night that would benefit Republicans by placing strict caps on contributions to nonprofit committees that spent heavily in the last election while removing limits on political parties' spending coordinated with candidates.
Lifting party spending limits would aid Republican candidates because the GOP has consistently raised far more money than the Democratic Party. Similarly, barring "527" committees from accepting large unregulated contributions known as "soft money" would disadvantage Democrats, whose candidates received a disproportionate share of the $424 million spent by nonprofit committees in 2003-2004.

I have a dream that someday, the House of Representatives will represent me. I have another dream involving Angelina Jolie. Which dream do you suppose is more likely to come true?

In other news, the best administration we have (as Molly Ivins likes to say) is once again muzzling climate scientists who dare say there is a link between human activity and climate change. This seems to be because there is a link between human activity and climate change, a link the administration's policies are reinforcing:

Employees and contractors working for the National Oceanic and Atmospheric Administration, along with a U.S. Geological Survey scientist working at an NOAA lab, said in interviews that over the past year administration officials have chastised them for speaking on policy questions; removed references to global warming from their reports, news releases and conference Web sites; investigated news leaks; and sometimes urged them to stop speaking to the media altogether. Their accounts indicate that the ideological battle over climate-change research, which first came to light at NASA, is being fought in other federal science agencies as well.

Because if no one talks about it, it isn't really happening, even as the Republic of Kiribati disappears beneath the Pacific...

Corporate insecurity

Anne brought to my attention the security practices at a medium-sized company in Chicago that make security nearly impossible: the company's IT department assigns Windows domain passwords to the users. In a recent communication, IT said this practice made the domain more secure.

It actually made me mad to hear about this practice. They're not only wrong, they're wrong in a particularly ignorant and incompetent manner, and someday they're going to have a significant security incident.

Secure log-ins serve two distinct purposes: authentication and authorization. Authentication means that the log-in procedure should guarantee that the person providing the log-in credentials is who she claims to be. Authorization means that the successfully logged-in person has access to the data he needs access to, and no more.

Most people only equate log-in screens with the latter. In many organizations I've worked with, people share passwords all the time, thinking that the password controls what they can do. It's often then impossible to figure out who did what with which data. Within a company that has Sarbanes-Oxley reporting requirements, this kind of sloppiness may actually violate criminal law in some cases.

Your bank knows about authentication. It's why you have a PIN (personal information number) for your cash card. It's also why sites like the IRS Website ask for hard-to-know information, like your previous year's adjusted gross income, before they let you do anything. Some people at your bank and at the IRS are authorized to see your information, too, but when they look at it, there's a record that they are looking.

IT administrators never actually need your password, because their authorization far exceeds yours. Plus, it's usually important for IT departments to know who did what to each computer. When you have the keys to the kingdom, you come under greater scrutiny.

For these reasons, the only person who should know a log-in password is the person who chose it. Any password that the person did not, herself, choose, is no better than a password that a "malicious user" has cracked or stolen.

Now look at what the company Anne mentioned is doing. The IT department has a list of passwords, which can be stolen. Also, the IT department can log in to any employee's workstation as that employee (which is, I think their goal). Once in, they can send email under the employee's identity, rummage through confidential information (for example on a law partner's computer, where the lawyer has a legal obligation to keep the information private, even from other people in her firm), etc.

No doubt the IT department would claim they need this kind of access to ensure employees aren't using computers for personal work, or storing copyrighted materials on work computers. But since the password list exists, even if compromising material were found on the employee's machine—which, by the way, the IT people have the ability to find under their own login credentials—now there is a legitimate claim that the employee had no knowledge of the problem, because there is no way to show conclusively that only the employee could have put it there. (Had IT put it there under their own credentials, this would be easily determined by checking the security information on the computer.)

This isn't the only idiocy perpetrated by this particular IT department, but it's the one most contributing to their lack of security. If there were a professional organization of computer people, these guys would be thrown out.

Framework classes, again

I mentioned Friday that I've completely refactored the section of the Inner Drive Extensible Architecture™—the Idea™—that handles quantitative functions. (I've also decided to make some SDK documentation available.) The actual design of the IMeasurable classes—Length, Speed and the like—bears more discussion.

What I have, essentially, is a collection of .NET structs that implement IMeasurable, one for each kind of thing you want to measure. The old design had a single struct called Numeric that could represent any kind of measurement at all. The change means that the measurement type is now enforced by the compiler rather than the run-time engine, because instead of this:

Numeric meters = new Numeric(10d, new Meter());
Numeric pounds = new Numeric(10d, new Pound());
Numeric compilesFine = meters.Add(pounds);

> IncompatibleUnitException thrown

You get this:

Length meters = new Length(10d, new Meter());
Mass pounds = new Mass(10d, typeof(Pound));

Length wontCompile = pounds.Add(meters);

> Compiler error: no overload of Mass.Add takes Length as a parameter

One thought I had, though, was: why not make each of the units a measureable type to further constrain the design? So you would have this instead:

Pound pounds = new Pound(10);
Gram grams = new Gram(10, MetricExponent.Kilo);

Pound pounds = pounds + grams;

Simply: that would require either dozens of nearly-identical structs, or I would have had to use classes instead. Remember that a struct can't inherit from anything except System.ValueType. So each struct either has to contain all the relevant code (about 1200 lines of it for each of my IMeasurable classes, including documentation), or it has to compose most of its functionality from other, static objects—which is actually quite difficult in this context.

Structs are small very fast, and immutable, which makes them the best choice for small, fast, immutable things like measurements. I'd rather represent measurements with structs than objects, but I'd also like to avoid writing and unit-testing dozens of nearly-identical classes. So I compromised: representing each type of measurement with its own struct (so there are now only 8 of them), and allow the abstract Unit class to define how the individual units interact.

Check out the Quantitative SDK and let me know what you think.

Web hype: or, Party like it's 1997

Usability guru Jakob Nielsen has a new column today reminiscing about the hype of 1997 because it's back in vogue:

The fads and big deals that get the press coverage are not important for running a workhorse website. To serve your customers, it's far better to emphasize simplicity and quality than to chase buzzwords.
There is endless coverage of a few atypical stories in the trade press, mainstream media, and even on specialized Internet-focused websites. Once again, it's worth remembering: your site is different from the ones in big stories. Focus on fixing the basics to get a simple and communicative website. Simple steps don't get hyped, but they drive much more business value for the average site than the issues that everyone writes about.

He includes a sidebar about the fads of 1997 and how they're doing today.

Krugman on immigration debate

Krugman weighs in (sub.req.) on the immigration debate roiling the GOP:

For now, at least, the immigration issue is mainly hurting the Republican Party, which is divided between those who want to expel immigrants and those who want to exploit them. The only thing the two factions seem to have in common is mean-spiritedness.

Nicely put.

New Inner Drive demo, completely refactored

In January, I wrote about framework classes I was working on, and how I wanted to simplify the Inner Drive Extensible Architecture™. I followed up in February with a conundrum concerning how to model the problem. It turned out to be tricky, and time-consuming, and considering I wrote most of it at The Peddler's Daughter in Nashua, N.H., there was a lot of Smithwick's Ale[1] involved.

But today, at last, I've got a new demo.

The demo page has a lengthy explanation of how the new version works, and includes a bunch of source code showing how simple the stuff is to use and to extend. I still have a little polishing to do, but I'll probably be putting the full SDK documentation for the IDEA™ up on the Inner Drive website later this month.

I think this is some of the coolest stuff I've ever written.

[1] I would have linked to the official Diageo site, but it's so annoyingly badly written—it whisks you away to a page requiring your birthdate and it tries to cookie you—that on principle I won't have that as the primary link to this product.