Chad Perrin: SOB

18 February 2008

YouTube – FOX News Exposes Diebold Electronic Vote Flipping in Florida

Filed under: Geek,Liberty — Tags: , , , , , , , , — apotheon @ 12:21

YouTube – FOX News Exposes Diebold Electronic Vote Flipping in Florida

That’s video of a demonstration on Fox News of how a Diebold voting machine can be compromised. Some important steps were left out, of course. The gist is pretty obvious, though — and unsurprising.

The only way around this kind of thing is to take an open source approach to voting machine development, of course. When you can’t trust the developer (Can you trust Diebold?), you need to make sure the source is available. When you can’t trust the deployer (Can you trust the government under the Bush Administration?), you need to make sure the source is available. It’s that simple.

Nice to see that even Fox acknowledges there’s something wrong with the way voting machines are being “validated”.

If you’re on a Unix-like system, and the audio doesn’t match up with the video when viewing this, you can adjust the video framerate. I had to do this. Here’s one way to do this:

  1. Make sure youtube-dl is installed.

  2. Make sure MPlayer is installed with the necessary codecs for viewing Flash video.

  3. Use youtube-dl to download the video. I used the -o option for youtube-dl to specify the name of the saved file.

  4. Watch the video with MPlayer, using the -fps option to set the framerate for the video so that it roughly matches the audio. For me, a value of 30 worked pretty well.

Here’s the series of commands as I would have executed them if I did it all at once:

  portinstall youtube_dl
  portinstall mplayer win32-codecs
  youtube-dl -o vote_flipping.flv ''
  mplayer -fps 30 vote_flipping.flv

This is the Debian version, assuming the needed codecs are in a win32-codecs package in APT archives:

  apt-get install youtube-dl
  apt-get install mplayer win32-codecs
  youtube-dl -o vote_flipping.flv ''
  mplayer -fps 30 vote_flipping.flv

I don’t happen to recall whether there’s a package in the standard APT archives for those codecs (I haven’t dealt with this on Debian in a while). If they’re in there, you surely need to have the non-free archives specified in your sources.list file.

15 February 2008

tooltips for text on the Web

Over at Lunar Ocean, Antoine Toulme commented on my use of the <acronym> tag. He was apparently not familiar with the <acronym> tag in HTML 4 and XHTML 1.x. For those who are not familiar with it, the <acronym> tag is what I used to create the tooltip effect here: HTML

Basically, it provides a roll-over tooltip effect, where pointing your mouse at the tagged text should cause a little off-colored box to appear with some alternate text in it. It is part of the standard for both HTML 4 and XHTML. Of course, I don’t think there’s any such thing as a browser that implements the entire HTML 4 or XHTML specification, so it’s almost inevitable that there are browsers that don’t support a tag like <acronym>.

Assaf commented at Lunar Ocean, correctly pointing out that at present the proposed HTML 5 standard deprecates <acronym> in favor of <abbr>, which makes perfect sense to me. There isn’t much need for both — <abbr> can serve that purpose for acronyms as well as any other types of abbreviations, and if you really need to distinguish between them, you can do so with a style class in your CSS. In addition to all that, <abbr> is less typing than <acronym>. Assaf recommends using <abbr> instead of <acronym> because of the apparently incipient deprecation of the latter tag. Unfortunately, that’s not the whole story.

Not too long ago, a few of the editors and weblog writers at TechRepublic (I’m one of those writers — check out the TechRepublic IT Security weblog) were involved in a brief discussion of the support for <acronym> and <abbr> tags in IE. This came up because the subject of the <acronym> tag came up briefly in comments to one of my ITSEC articles there. It became quickly evident that there are widespread inaccurate beliefs about these two tags.

For those who aren’t familiar with it, <abbr> is basically exactly the same thing as <acronym>. The difference is that <acronym> is meant to be used for acronyms to provide alternate text that explains the acronym to the reader, and <abbr> is meant to be used for the same purpose with all other types of abbreviated text (other than acronyms).

What most of the people in the behind-the-scenes TR discussion seemed to believe, incorrectly, is that the <abbr> and <acronym> tags are both unsupported by Internet Explorer. Further, one or two of them suggested that we (the writers for TR’s weblogs) should never use either one of them, because of that lack of support. There are some problems with this reasoning, however:

  1. The <abbr> and <acronym> tags are parsed by some search engines, and taken into account when determining search keyword associations and search rankings. Thus, using these tags helps with search engine optimization.
  2. Using either of these tags in no way hurts anything. If the only difference between two versions of text is the presence or absence of these tags, go ahead and use them. Not only will it potentially help with search engine optimization, but it will also help in that — for those users who employ browsers that do support these tags — in at least some cases they lend additional usability for the website.
  3. Internet Explorer does support the <acronym> tag. It just doesn’t support the <abbr> tag.

Point 3 there bears on the comments at the Lunar Ocean post. In choosing between the <abbr> and <acronym> tags, you need to make a choice between:

  1. <acronym>: a tag that is supported by more browsers now, but may become obsolete in the future, judging by a proposed specification that may one day become a standard
  2. <abbr>: a tag that, right now, isn’t supported properly by the browser with the single biggest share of the market — and, thus, the browser used by the most potential visitors or customers at your website

I don’t advocate for using standards-noncompliant code just to cater to Microsoft Internet Explorer, of course. In fact, I use standards compliant code that breaks in IE somewhat frequently. I’m a bad boy, that way. What I do advocate is using standards compliant code that works as close to “everywhere” as you can reasonably get. In the case of <abbr> vs. <acronym>, then, the choice seems obvious to me.

When using <acronym>, however, make sure the CSS code for your website includes some styling for the <acronym> tag. In terms of general principle, this is because the dotted underline styling for the tag in Firefox is not part of the actual HTML and XHTML standards. It’s just the default styling employed by the browser. Since it’s not part of the standard, there’s no guarantee it will always be there — and, as such, you should make sure the styling is explicit in your code.

More specifically, you should explicitly style the <acronym> tag because, while Internet Explorer supports the tag according to the standard specification, it doesn’t provide default styling for <acronym> the way Firefox does. As such, in IE, <acronym> tagged text will look exactly like the rest of the text, undifferentiated from the rest — which means IE users won’t even know there’s a tooltip there to be viewed — unless you use CSS to style the tag yourself.

13 February 2008

WordPress refixes

Filed under: Geek,Metalog — Tags: , , , , — apotheon @ 09:07

I’ve finally gotten around to trying to re-fix the atrocious character replacement and formatting issues that seem endemic to WordPress in general, after making recent changes to save SOB from its recent problems. This should eliminate “smart quotes” replacement and character spacing that made all the characters in certain presentation contexts run together, as well as restoring justified text alignment. Last, but not least, I fixed the problem this thing had with reversing the meanings of “older” and “newer”.

Yes, this means I’ve been hacking some of the ugliest PHP in the world this morning.

Let me know if you encounter any problems that seem new. Let me know about old problems too, of course.

In the meantime, I’m going to turn off the (apparently intermittently visible) CAPTCHA system for a while. If anyone was unable to post comments because of it, now is the time to let me know. I anticipate leaving it turned off for at least a week — longer, if it turns out it prohibited people from posting comments.

Thanks for being my beta test crew.

« Newer PostsOlder Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License