Where does technology take us?

A couple of recent articles in the New York Times really make us think about some of the things we get from technological progress — some things that aren’t terribly obvious at first blush.

In one article, we see the technology in sports, and how it’s enabled this year’s Olympic swimmers to shatter speed records.

BEIJING — He swam so improbably fast, making up so much ground in a foaming, desperate attempt to reach the wall first in the 4x100-meter relay, that Jason Lezak not only won a gold medal for the United States on Monday, but he also helped to shatter the world record by nearly four seconds.

That race alone would have provided an astonishing day of swimming at the Summer Olympics, but it was the third world record of the morning and the seventh in three days of competition. An eighth record was set later Monday, matching the total number broken at the 2004 Athens Games.

[...]

Advances in training techniques, pool design and swimsuit technology have contributed to the increases in speed for swimmers, [...]

Training and physical techniques have, of course, improved performance in all sports over the years, and that’s a credit to the athletes and their coaches. At the same time, we forbid the use of drugs to enhance performance, and rightly so: with them, we’re measuring not the skill and technique of the athlete, but the effect of the drugs. Faster, higher, stronger drugs, more than faster, higher, stronger competitors.

How, then, faster, higher, stronger equipment? We’ve seen it many times before, with changes in baseball bats, tennis racquets, golf clubs, artificial turf... and now with swimming pools and swimsuits.

The pools are designed to reduce the effects of the water currents that the swimmers create as they race. The suits create less friction in the water and add buoyancy, to no negligible effect: it’s said that the new Speedo LZR Racer can shave up to 2% off the race times, and this in races that are often won or lost by hundredths of a second.

“When technology is used in a sport, it is important to be in control of the way it is being developed and where it might lead us,” Claude Fauquet, the technical director of the French swimming federation, said in reference to swimsuit technology.

Fauquet has called for more debate about the use of Speedo’s LZR Racer, the latest advance in the full-body suit craze popularized in the last eight years. The Racer has been worn in the setting of about four dozen world records since its introduction in February. The corsetlike suit is made by ultrasonic welding instead of stitching, can require a half-hour to put on and shoehorns the body into a more streamlined position.

Indeed. Nearly 50 world records broken this year alone, thanks in some significant part, it seems, to a newly designed swimsuit. Is that fair? I suppose that all current contestants can opt for the new suit if they want it (though I’m not sure about cost and availability issues), but it certainly makes the new records completely incomparable to the old ones. These are really new records set in a new sport: the sport of racing in a Speedo LZR Racer.

Shouldn’t they simply race naked? Then it’s the athlete alone, with less technological assistance (there’s still the question of the pool).

The other article points out how significant new communications mechanisms have become, as police now expect to get crime tips by text message, and are actively encouraging that.

For years, mayors, police commissioners, community leaders and others have sought to drill into the heads of New Yorkers a simple toll-free phone number to anonymously help in solving crimes: 1-800-577-TIPS.

Now, they want to enlist a younger generation of crime-busters. On Tuesday, the Police Department publicized directions for citizens on how to send text messages to the authorities, to provide the same sort of anonymous tips for investigators working on unsolved criminal cases.

The directions are simple, according to Paul J. Browne, the Police Department’s chief spokesman. To initiate a conversation with detectives in the Crimestoppers bureau, callers must text the word CRIMES (or 274637 on a cellular phone).

Recognizing that many people, particularly young ones, prefer text messages to voice ones, the police have added that option in the hope of getting tips from citizens who wouldn’t have otherwise helped out. I do wonder how they can actually promise anonymity with this system, but if the public is willing to use it, I’m all for it. They shouldn’t (and they won’t) discontinue the voice option, of course. But adding more ways to help... can’t hurt.

Why you shouldn’t flash

This isn’t new — I’ve watched people doing it wrong for years, from way before digital cameras existed. Only, I’ve just been on vacation, and that’s when one tends to see it more. You’ve seen it too, right? We all have.

I’m talking about watching someone take a picture of some huge thing that’s far away, and seeing the flash on his camera go off. [Foof!] The burst of light and the look of satisfaction at having snapped a good one is evidence that the user doesn’t understand why that’s bad (and why his photo might not turn out as he expected).

So I’ll tell.

First, it doesn’t do any good. We’re not talking about thousand-watt Klieg lights here; a typical camera flash just can’t illuminate anything very large, and the light from it isn’t effective at much distance. You can’t rely on illuminating something more than about 20 metres away (nor closer than about 1 metre), and it’ll work best between around 3 and 10 metres (but read the instruction manual for specific details about your camera). Think about that, and realize how close that really is. Use it too close, and you’ll drown your subject in too much light; too far, and you won’t be lighting the subject enough.

The corollary to that is that if the subject is larger than the image frame at 10 to 20 metres, it’s probably too big for the camera’s flash to be effective on it. I can’t tell you how many times I’ve seen someone photograph a large building, such as a church, from a distance of at least 50 metres, and watched their flash go off. And inside the church, if you’re taking a photo of a detail, the flash will do fine, but trying to photograph the entire nave and altar with the flash is pointless.

Of course, pointless isn’t bad. So, for why it’s actually bad, let’s continue.

Second, using flash from too far away risks having the flash illuminate some close-in objects that you hadn’t meant to highlight. You’ll often find that some nearby foliage, or a litter bin, or the arm of the guy just ahead of you to your right will be as bright as the sun, when you hadn’t even noticed its presence when you took the picture. This is usually not the effect you want.

Third, there’s the question of shutter speed. The camera is designed to synchronize the shutter (or the equivalent function in a digital camera) with the flash, usually by setting the effective shutter speed to 1/60 sec. That means that all the automatic stuff that your camera does is overridden by the decision (yours or the camera’s) to use the flash, and your flash photos will always be taken at 1/60 sec. Sometimes, that will work fine. Sometimes, it won’t. If it’s inappropriate to use the flash anyway, it’s better to have it turned off so the camera isn’t locked into a specific shutter speed.

Fourth, it runs your batteries down faster. Using up battery power on the flash is fine if you need the flash. But it’s silly if you don’t.

And finally, sometimes the use of flash is just rude, or forbidden outright. You shouldn’t usually use flash in churches, museums, theatres, and other such places. Maybe you’ll get bad looks from people. Maybe someone official will ask you to stop. Maybe you’ll be shown the door. Why subject yourself to that treatment (and others to your behaviour)?

Learn how to turn off your camera’s flash, and then do it. With a digital camera, especially, it’s better to set the default to be off, if you can, and to turn it on when you need it. If you wind up taking a shot without the flash by accident, you can just delete it, and re-take it with the flash on. (Most cameras have the default initially set to “auto”, and not all of them allow you to change the default. It’s annoying if you have to remember to turn off the flash every time you turn on the camera.)

My camera makes this particularly convenient: I have a Canon S3 IS, and in order to use the flash I have to flip it up. If the flash is closed, it’s off. If it’s flipped up, it’s on. Easy to choose, and essentially impossible to have it set the wrong way by accident.

IETF 72, Dublin

Well, Dublin-ish. The IETF meeting was actually at Citywest, 30 minutes outside of Dublin. I guess that was great for the golfers, but I missed being in the city, and having the option of walking out and getting lunch and dinner. They provided dinner buses into Dublin, but that’s not the same as just walking down the street a block or three. It seems that Trinity College Dublin would have been a fine place to have the conference, and I’m sure there are other facilities that’d have worked as well.

Still, it was a good meeting. The facility we did have was somewhat expensive, but otherwise fine, and, of course, the meetings were productive and useful, as always. It was another full week (I had about two hours of free time the whole week, an hour or so each on Wednesday and Thursday), and managed to schedule the rest of the time, including meals, for work.

It’s too bad, someone pointed out, that it was the 72nd meeting, and not the 33rd — if it were the latter, we’d have heard the local presentations welcome us to the “torty-tord IETF”. As it was, we heard that there were almost torteen hundred attendees (or, one tousand tree hundred), so that was nice.

I’m going to keep the meeting summary on the short side this time, with just a few highlights, but it’ll still be a long post. If you want to read about the vacation days after the meeting, and see photos, look for my other post, to come tomorrow. If you’re really interested in this, click here to see the meeting summary.

apparea — Applications Area general session

Among the general announcements were that NFSv4 will probably be done in the Applications Area, and that there’d be a discussion of email standards status on Tuesday (of which I have a summary below). There was a presentation of two follow-ups from the Applications Area workshop in February — netappvlan and netappmodel — but with no ensuing discussion.

There was a brief discussion about FTP extensions. The points are that, while FTP seems quite mature, and not terribly ripe for extensions, it’s still big business and there are five documents that are out as Internet drafts, looking for standardization. Should these go through as individual submissions? Should we form a working group?

It looks like we’ll form a working group, and John Klensin and I have agreed to co-chair it. We expect it to be a short-lived and non-contentious group, and John and I agree that standards going through the group will require some real support behind them, and existing implementations as evidence that they’re real and worth moving forward.

dkim — Domain Keys Identified Mail

We had a quiet session at this meeting, and my co-chair, Stephen, wrote this succinct summary, which I’ll use here:

DKIM met Monday afternoon, 62 people attended.

The main goal of the meeting was to get the ADSP and Overview documents to the start of working group last call. Each had a couple of open issues at the start of the meeting that were discussed and resolved (modulo confirmation on the mailing list). The result was that a new revision of ADSP will be published this week. Working group last call on both documents will start at that point.

The deployment guide was briefly presented, and work on that continues.

A couple of proposals were made for new work that might require re-chartering. There was some, but not overwhelming, interest in pursuing these, but the group won’t have that discussion until after the two current documents are in the hands of the IESG.

idnabis — Internationalized Domain Names update

We had the usual minor issues discussion, but the most significant by far, taking most of the time in the two sessions, was in the “BiDi” (bi-directional text) document: how to deal with left-to-right text, such as numbers, dots, slashes, and the like, in otherwise right-to-left text, such as Hebrew and Arabic. We had a demonstration of what happens when such text is entered, and it’s not pretty. As someone typed “abc2.[Arabic-text].3def.com”, we watched the “.3” get turned around and moved, so it incorrectly appeared to be attached to the Arabic text. To be sure, this is a user-agent problem — the correct characters will be sent on the wire in the correct order — but it’s a very hard one to solve. There’s no resolution yet, but we have more information, and, as we say, “Our best people are working on it.”

We also had a discussion, which included at least one native speaker of Korean, about a request that we add another set of Korean characters to the list of characters forbidden in domain names.

eai — Email Address Internationalization

We had some discussion of EAI issues during a working dinner on Sunday, and came up with a recommended answer to the question of what to do about List-* header fields. I presented that answer in Monday’s EAI session: for List-ID, note that it is meant to be a machine-readable string, not a human-readable one, and should not be in UTF-8; for others, internationalize them by including multiple URIs, and downgrade by removing the UTF-8 version, leaving the non-UTF-8 versions for use after downgrade.

POP and IMAP are almost done, but there’s an issue about POP and downgrade — the document currently has uncertain language about how to downgrade a UTF-8 message if the client isn’t using UTF-8. In the event that an old client is being used to download the message, but that a newer client (perhaps after a software update) is later used against the same local message store, we agreed, after discussion, that it would be good to have a standard downgrade mechanism used, so there’s some hope that the new client can recover the original message. There was agreement to require the use of the standard EAI downgrade.

We decided to wave our hands around the issue of handling mailto URIs. It will eventually require its own document (a UTF-8-enabled mailto), and for now we’ll point out that mailto does not handle UTF-8 addresses, and that something to deal with that is forthcoming.

There was a report on some very successful experiments with the current EAI specs (including downgrade experiments). Many thanks to the organizations that participated in those. Notwithstanding that, it’s clear that the aggressive schedule that was suggested at IETF 71 isn’t realistic, and we’re setting up a new schedule for re-chartering to put the EAI specs on the standards track.

httpbis — HTTP update

There was a long issue list to get through here, and some issues have been harder than the chairs and authors thought they would be to get consensus on. I’m just including some brief notes here.

The next version of the drafts will include a new registry for messages, to parallel the one for status codes.

The formal grammar is being converted to ABNF, and that’s a lot of work to get right. There’s a particular trickiness with cleaning up LWSP, removing it from where it doesn’t belong, while being sure to leave it where it’s appropriate.

Internationalization is, as always, a sticky issue. Despite standard headers, HTTP implementations have done their own things with respect to internationalization, and it’s making it difficult to decide how to go here. There are questions about support of RFC 2047 encoding, internationalization of filenames in content-disposition headers, and such. There was quite some discussion on this.

There was a discussion of issues with the use of the message header registry in HTTP. The registry is for other uses and is shared by HTTP, and there’s concern about having information in the right place, making sure that implementors read everything necessary to get the implementation right, etc.

For more on internationalization, we came to the question of what character sets to allow in new header fields. The decision was to say that new header fields MUST only use US-ASCII, but that implementations SHOULD accept ISO-8859-1 (including UTF-8 as well, at this point, did not get acceptance).

We finished with a presentation and discussion about security requirements for HTTP, an item specifically out of scope for this first round through the working group, but something that might be added to a re-charter.

morg — Message Organization standards

The MORG BOF’s goal was to review a series of individual Internet drafts and ideas that all relate to searching, sorting, and organizing email messages using IMAP, and to consider forming a working group to bring these documents through the standards process.

The BOF chairs came in with a chunky set of drafts, most of them fairly immature, some of them with significant IMAP-community support already and some that are new items. We went through the drafts, got explanations of each, and discussed them — some in considerable detail.

As a result of the discussion, it seems clear that there are enough document authors, reviewers, and server implementors to get through this lot, and enough energy to easily support a working group. There was some concern, though, first brought up by John Klensin, that this could be another set of IMAP extensions that bloats IMAP, and that really isn’t in significant demand. The problem is that we don’t have much participation by client implementors.

Chris Newman supports the formation of a working group here, and I agree. Chris would like to see the chairs manage the work by assessing the implementation commitments, including commitments from client developers, and dropping items that don’t have commitments to implementation in clients. I also agree with that idea.

The “bloat” discussion led to a suggestion to consider “IMAP5”, which would start by removing features to create a minimal protocol with necessary function, making something that’s easier to implement and get right. Randy Gellens has already started a mailing list for that, and there’s been some initial discussion.

asrg — AntiSpam Research Group

There are two primary documents coming out of this research group so far, both dealing with DNS block-lists. The first, which describes how they work, has been reworked to go on the standards track (as an individual submission, since the IRTF can’t publish standards), rather than being an informational document. The second, recommending best practices in operating and managing a block list, still needs work, and will probably go out as a BCP.

We had some discussion about whether another document should be adopted by the ASRG — the decision was not to adopt it — and that discussion led into some talk about how to focus the ASRG on new research. I will discuss the ASRG at the CEAS conference in late August, and try to get more participation from the academic community into the ASRG (possibly recruiting an ASRG co-chair from that community).

vcarddav — VCard update and CardDAV

We had the usual document status update, and went over some open issues. One that seems simple, but that merited some discussion was that dates must currently be complete (day, month, year), but there are times when one doesn’t want them to be, or doesn’t know the full date (for birthdays, for example, one might just want day and month, but no year). We decided to use existing date syntax from the comparators RFC and adapt it for VCard.

The other significant discussion was on how to handle synchronization issues, especially with collision-detection in situations with multiple copies of the information (one on a host server, one on a laptop, and one on each of two or three mobile devices, for example). Included here is the discussion of unique IDs — whether to have per-property UIDs, whether to require persistence of UIDs, how to handle the situation where a particular device or data store can’t keep the UIDs persistently, and so on.

We also had a small discussion about internationalization questions, in light of EAI. I have a suspicion that we’ll encounter effects from EAI that we haven’t yet anticipated. In the end, I don’t think they’ll be serious, but we’ll have to deal with them.

sieve — Sieve mail filtering language

This was an uneventful session for a working group that’s wrapping up its old work and preparing to re-charter to add some new work — work that is itself close to being finished, actually. We went over document status, and there’s nothing notable to say about that. The most difficult document, which this working group is picking up from lemonade, was discussed there (see below).

We talked a little about possible issues that Sieve will have with EAI — most obviously, that it will likely make scripts more complex and ugly, as a script will have to handle multiple versions of the same email address. We expect to have a sieve-eai document in the new charter.

lemonade — Mail extensions for diverse service environments

We still had a full session of final discussion, despite having thought that we wouldn’t meet here at IETF 72, but this group is wrapping up. We made some decisions on the remaining issues, and agreed to move the last document (imap-sieve) to the Sieve working group.

We finished with an incomplete discussion of imap-sieve (we ran out of time), and we’ll continue that discussion on the Sieve mailing list. Ned Freed had brought up a series of thoughts about the extension, in an email message in May, and I’ve summarized that into eight main issues.

Email standards discussion

After our experience with getting RFC 2821 and RFC 2822 updated and through the process of progressing to Draft Standard, a few people thought it would be good to consider setting up a working group chartered to progress those documents to [full] Standard, and to move other Proposed Standard documents to Draft Standard. This dovetails with my idea of creating a long-standing working group for email standards maintenance, a topic that the IAB and IESG discussed in our joint meeting on Sunday.

We have consensus, energy from participants, and IESG support to create such a working group, and we now have a mailing list to discuss a proposed charter. I suggest that we do a three-stage approach:

• In the first stage, set out a list of Draft Standards to progress to Standard, and then re-charter for the next stage.
• In the second stage, set out a list of Proposed Standards to progress to Draft Standard, and then re-charter for the next stage.
• In the third stage, set out a list of work that needs to be done that might result in new Proposed Standards for email.
• Iterate on those three stages. When there’s no immediate work to do, go dormant and periodically review the situation, waking up and picking up work when there’s work to pick up.

Technical plenary

The technical topic at the plenary this time was operational experience with IPv6. We had a panel of five speakers, who talked about their experience with implementing and operating IPv6, and answered questions from the moderator and the attendees.

Internet Architecture Board

In addition to setting up and running the technical plenary panel, the IAB reported on its work as follows:

• Informational documents:
  • We published RFC 5218, “What Makes for a Successful Protocol”, to help provide guidance for protocol designers.
  • We have “Design Choices When Expanding DNS” almost ready for final submission, giving architectural guidance use those who would use DNS for new purposes.
  • Work is wrapping up on “Principles of Internet Host Configuration”, advising on architectural issues involved in configuring Internet hosts.
  • We have a new document, “On RFC Streams Headers and Boilerplates”, dealing with an administrative issue.
• At our IAB meeting in May, we began work on several Internet architectural projects, and two of them have made some progress since:
  • Evolution of the IP Model, looking at architectural problems caused by layer violations as assumptions leak into higher-layer protocols and applications about how the IP layer works.
  • Peer-to-Peer Architecture, covering architectural questions involved in peer-to-peer protocols and applications
• We have set up a process for assigning liaison shepherds from the IAB, to better manage the liaison relationships between the IETF and other organizations, such as ITU-T, OMA, and W3C.
• We set up some new liaison relationships and other inter-organizational work.
• We have proposed a new organization of the RFC Editor job, splitting it into four functional roles that give the flexibility of contracting and managing different roles separately.

More scattered bits

Here’s another assortment of things while I’m meeting in Dublin...

Particularly appropriate during IETF week, the recent DNS exposure and patch frenzy made the NY Times. And, of course, Bruce Schneier has comments about the whole thing.

Another IETF-week-related item: China Surpasses U.S. in Number of Internet Users

And then there’s idiot Senator Ted ("the Internet is tubes") Stevens, who has now been “indicted on Tuesday on seven felony counts of failing to disclose gifts that he received from an oil services company.” I have to admit to some serious schadenfreude.

When Official Truth Collides With Cheap Digital Technology:

Around 9:30 on Friday night, a bicyclist pedaling down Seventh Avenue veered to the left, trying to avoid hitting a police officer who was in the middle of the street.

But the officer, Patrick Pogan, took a few quick steps toward the biker, Christopher Long, braced himself and drove his upper body into Mr. Long.

Officer Pogan, an all-star football player in high school, hit Mr. Long as if he were a halfback running along the sidelines, and sent him flying.

As of Tuesday evening, a videotape of the encounter had been viewed about 400,000 times on YouTube. “I can’t explain why it happened,” Police Commissioner Raymond W. Kelly said on Tuesday. “I have no understanding as to why that would happen.”

But this episode was not just a powerful crash between one bicyclist and a police officer. It may turn out to be yet another head-on collision between false stories told by some police officers in criminal court cases and documentary evidence that directly contradicts them. And while in many instances the inaccurate stories have been tolerated by police superiors and prosecutors, Officer Pogan’s account is getting high-level scrutiny.

Later that night, Officer Pogan composed a story of his encounter with Mr. Long. It bore no resemblance to the events seen on the videotape. Based on the sworn complaint, Mr. Long was held for 26 hours on charges of attempted assault and disorderly conduct.

Over the weekend, though, the videotape, made by a tourist in Times Square with his family, fell into the hands of people involved with Critical Mass, the monthly bicycle rally that Mr. Long had been riding in.

The availability of cheap digital technology — video cameras, digital cameras, cellphone cameras — has ended a monopoly on the history of public gatherings that was limited to the official narratives, like the sworn documents created by police officers and prosecutors. The digital age has brought in free-range history.

And with it, the Digital Age has brought in public scrutiny of officials, and greater demand for accountability. Be happy about this; be very happy!

Finally, and without further comment, we have an op-ed column by Nick Pope that suggests that if we took UFO reports more seriously, we’d be safer from terrorism. Mm-hm.

Liability for software failures?

Security maven Bruce Schneier suggests, in a column in The Guardian, that a solution to the problem of shoddy software that needs constant patching to fix bugs and security vulnerabilities is to hold vendors legally liable for software failures:

It doesn’t have to be this way. It is possible to write quality software. It is possible to sell software products that work properly, and don’t need to be constantly patched. The problem is that it’s expensive and time consuming. Software vendors won’t do it, of course, because the marketplace won’t reward it.

The key to fixing this is software liabilities. Computers are also the only mass-market consumer item where the vendors accept no liability for faults. The reason automobiles are so well designed is that manufacturers face liabilities if they screw up. A lack of software liability is effectively a vast government subsidy of the computer industry. It allows them to produce more products faster, with less concern about safety, security, and quality.

Mr Schneier particularly points out the problem with web browsers, the single most important type of application program for most users:

A recent study of Internet browsers worldwide discovered that over half — 52% — of Internet Explorer users weren’t using the current version of the software. For other browsers the numbers were better, but not much: 17% of Firefox users, 35% of Safari users, and 44% of Opera users were using an old version.

This is particularly important because browsers are an increasingly common vector for internet attacks, and old versions of browsers don’t have all their security patches up to date. They’re open to attack through vulnerabilities the vendors have already fixed.

Bruce is very often spot on in his analyses, but not this time.

I, too, have often lamented the poor quality of software. If our toasters turned out like our computer software, I often say, we wouldn’t tolerate the situation. Suppose that when you pushed down the lever on your toaster, the machine popped up perfect toast 95% of the time. And suppose that 3% of the time you got your toast burnt to a cinder, and 2% of the time the toaster never heated and never popped, and you had to unplug it, wait 10 seconds, and plug it back in before it would work. You’d never buy that brand again, of course, and if all brands did that you might never buy a toaster again.

And, worse, what if .003% of the time, the toaster burnt your house down? But, no, unlike software, toasters don’t have those sorts of problems.

So, yes, I agree that the quality of software is generally appalling, and I agree that it should be fixed. But, no, the marketplace won’t reward it. The fact still is that new features, not bug fixes, are what will sell the next version, and delaying the release of software until more bugs are fixed just allows the competitors to get in there first.

But the more basic issue is the business model we’ve settled into for a great deal of the software we use, including, notably, web browsers: it’s free.

Of the four browsers that Bruce mentions, Firefox and Opera are completely free, and Internet Explorer and Safari are arguably so, since they’re bundled with every system and freely downloadable, and they’re competing with free “products”. Where’s the financial incentive to spend a lot more money to build a higher-quality freebie? And mightn’t legal threats just lead to the abandonment of risky products that don’t bring in revenue?

Beyond that, who is it who would be held liable for, say, failures in Firefox? It’s an open-source project, with countless, random people contributing to it. It’s not entirely a willy-nilly thing, but it’s hardly tightly controlled. There’s no big corporation, no Microsoft or Apple equivalent, behind it.

It’s tough, in an environment where product is given out for free, to demand quality — the adage that “you get what you pay for” is in full effect. But demanding quality is the only way we have any hope to get it. There’s no way we can look to the legal system, at least not in general.

Now: Who’s willing to stop using web browsers until there’s one available that’s bug-free and guaranteed to have no security holes? Raise your hand.

[Barry looks around, his own hands in his pockets.]

Right, and how many of you are willing to pay, say, $200 per computer for a high-quality, bug-free web browser?

I didn’t think so.

Another look at DMCA

The other day, some friends and I who had been discussing the Viacom/Google case drifted off again to the issues of the Digital Millennium Copyright Act (DMCA) and the recording industry’s takedown notices. We got to the broader question of what’s wrong with laws such as the DMCA, and court decisions that require extreme measures to prevent copyright infringement.

Now, I first have to point out that everyone involved in the discussion agreed on a key point: we all think that a content creator — someone who produces a piece of writing, a song, a movie, or the like — has a right to choose what can be done with her material. If she wants to make it freely available, that’s fine... but if she doesn’t, that’s fine too, and the law should protect her rights to safeguard what she’s created. Not everyone agrees with this, but all of us having the discussion do.

We’ll also ignore, for this purpose, questions of whether there’s a difference in this regard between the content creator and other parties, such as the RIAA, ASCAP, Sony BMG, and so on. That’s another discussion.

The discussion at hand is to what lengths we should go to protect the content creators. And my answer to it is that laws should criminalize the violation, not the mechanism used to commit the violation. Making the mechanism a crime has two faults:

1. The violators will find another way, anyway.
2. Unless the mechanism has no legitimate use, we will have placed unreasonable limits on reasonable users.

Let’s make a comparison, moving from Internet crime into the real world. Perhaps we’ll notice that bank robbers usually use getaway cars. We could make that harder by banning cars. Now, that’s obviously silly. Bank robbers would still rob banks — they’d just have to make off with the money another way, or else drive getaway cars illegally. And all the people out there who drive to work every day would no longer be able to. We’d shut down too much legitimate use; we’d be throwing the baby out with the bath water.

And that’s what’s happening with laws like the DMCA, and with legal attempts to shut down peer-to-peer data sharing. It’s already illegal to give away copies of copyrighted material, but we can’t make all this technology illegal... it’s the wrong answer to the problem.

Related to this, eBay just got a favourable decision in the lawsuit brought against it in the U.S. by Tiffany:

In a long-awaited decision in a four-year-old trademark lawsuit against eBay brought by the jeweler Tiffany & Company, Judge Richard J. Sullivan of the Federal District Court in Manhattan ruled that the online retailer does not have a legal responsibility to prevent its users from selling counterfeit items on its online marketplace.

The verdict reaffirms that Internet companies do not have to actively filter their sites for trademarked material. Rather, they can rely on intellectual property holders to monitor their sites, as long as they promptly remove material when rights holders complain.

This is very much related to the policing that Viacom wants Google to do on YouTube, and it seems to me, though I am not a lawyer, that Google could use this as a stare decisis argument in its lawsuit.

[Actually, since the two cases are in different federal districts, the New York court’s decision in the eBay case is not binding on the California court in the Google case. Still, it’s a decision of reason, and good news for content hosts and service providers in general.]

Technology and the Keystone Cops

Last year, a man was arrested in the New York City for sending abusive and harrassing email messages. Only, he didn’t, a fact that would have been obvious to anyone with any sophistication in things email. The police, though, have no such sophistication, and the man, William Hallowell, went through a great deal of hassle, embarrassment, and tarnished reputation before the charges were dropped. He is now suing the city and the police for their handling of the case.

But what began as an innocent exchange of e-mail messages, Mr. Hallowell said, quickly spiraled into an Internet nightmare, with the librarian mistakenly sending another message meant for him to someone with a similar name, the recipient replying with a crude, abusive response, and the blame falling on Mr. Hallowell.

He was arrested on a harassment charge, interrogated, held in custody for more than 30 hours, and became the subject of local news articles, causing enormous embarrassment, he said in a lawsuit filed on Wednesday in Federal District Court in Manhattan.

In the suit, which names New York City and several police officers as defendants, Mr. Hallowell, 24, says that the officers “deliberately and maliciously ignored a mountain of evidence” that proved that he did not send the offending message.

In an interview, he added that the officers did not even seem to understand how e-mail addresses work.

This is reminiscent of the case of Julie Amero, the substitute teacher in Connecticut who was convicted, and faced 40 years in prison, because police, prosecutors, judges, and jurors do not understand computer technology and the Internet. Ms Amero’s conviction was vacated after three postponements of her sentencing, but only after a huge outcry from people who knew better, and from months of publicity about it. And only after her career was ruined — do we really think anyone will hire her to teach school again?

And so with Mr Hallowell, though, thankfully, it ended before he was convicted of the charges. Still, people know about it, and some are sure to be suspicious. “Was there really something there?”, they will wonder. “After all, it was dropped for lack of evidence. That’s just one of those technicalities that get too many guilty people off.” Will anyone be willing to employ him in a school again?

But one of Mr. Hallowell’s lawyers, Ilann M. Maazel, said the case showed how easy it was for innocent e-mail users to be victimized.

“This could happen to anybody,” he said, “if the police are going to have absolutely no competence when it comes to understanding e-mail or the Internet.”

[...]

William Hallowell said that he vigorously denied sending the lurid e-mail message, and that he invited the officers to review the e-mail messages in his computer. He said that he also showed them the exchange of messages he had earlier had with the librarian.

It was clear, he said, that his account did not contain any with the address linked to the abusive sender.

OK, first, I have to say that since I don’t have any of the evidence, since I have not talked with anyone involved, since I have no information other than what’s in the Times article, I’m just speculating here. But it’s speculation based on an understanding of how poorly the police and the courts generally handle these sorts of things, and how little they understand technology.

The thing is, there’s nothing you can do to protect yourself, and that’s a major difference between this case and the one of Ms Amero. Ms Amero could have turned off the computer, for example, contrary to the instructions she’d been given. But Mr Hallowell’s situation cropped up entirely independent of Mr Hallowell — he wasn’t even there. His boss simply used the wrong email address, and didn’t know that she had... and it became a snowball rolling downhill after that.

The answer to this, in general, is that police departments and courts must have access to expert technological advice on an ongoing basis. It’s not sufficient for the courtroom to be a battleground between expert witnesses for each side — that’s too late, and there are too many axes to grind at that point. The police need help in considering the evidence while they’re investigating. Just as the police can now show a guy to the victim and say, “See, the man you saw was over six feet tall; he’s only 5 foot 8. This isn’t the man you saw,” they have to be able to do equivalent things with Internet-related evidence.

Of course, police officers can’t be expected to know enough to do that, in general, any more than they can be expected to have medical or psychological knowledge. For those, they know they need to get advice, and they have ways to do it. Similar access to advice is needed here. And if the Times article is at all accurate, that would have been enough to turn the whole thing into nothing more than a brief annoyance to Mr Hallowell.

“Identity theft”

I see and hear a lot about “identity theft”. It’s a nasty business, and it can take a great deal of time and trouble to dig yourself out from under it, if it happens to you.

But I also see the term tossed around a lot incorrectly. It’s often used to describe fraud or plain, old, traditional theft.

If someone gets your credit card or card number and charges things to it, that’s not identity theft. If someone snags your bank account number and transfers all the money out, that’s not identity theft. If someone phones a business and claims to be you, and the staff believes him, that’s not (by itself) identity theft.

Those things are annoying, but they’re easy to deal with, easy to get yourself out of. You cancel the affected account and you open a new one. Even if your wallet is stolen and several accounts are compromised, the solution is the same.

Fraudulent use of a credit card is usually easy to fix. Identity theft is much more insidious than that.

Identity theft happens when someone gets enough information to open new accounts on your behalf. That can get really nasty, because it can be a long time before you even know about the problem (especially if they get the bills sent to a bogus address), it can be hard to convince the creditors that you didn’t authorize the activity, and it can result in stuff in your credit record that’s hard to get out.

And the thing is that obtaining account numbers, as above, can be the first step to enabling identify theft. Identity thieves collect as much personal information about you as they can. When they have enough, including some key bits, they’re ready. The key bits? Name, address, date of birth, Social Security number. A couple of account numbers help too — a bank account and a credit card fill things out nicely. If they also know where you work, that’s good too, though it’s not necessary. Mother’s maiden name, place of birth, and that sort of thing are icing on the cake, giving them more options to get more information from more sources.

Because that’s the real key point here: the more information one has on someone, the more new information one can get. Information, however insignificant it may seem, provides access to more information. The other side of that is that protecting information helps protect other information.

Your first line of defense, then, is to keep a lid on the key bits of information. Note that your driver’s license has three of the four primary ones in one place: name, address, date of birth. Don’t lose your driver’s license! It’s more than just an inconvenience. Never keep anything with your Social Security number on it in your wallet, and don’t give your SSN out freely. You should only have to use your SSN to open bank or credit card accounts, and to get employment — things that have to deal with taxes or credit checks. For anything else (someone recently said that her doctor asked for her SSN), insist that they use something else (and see below for places that use the last four digits of your SSN).

It’s also popular to put your date of birth into social networking sites, purchasing wish lists, and such, for all to see. Avoid that.

Shred any old mail that has your account numbers on it. Someone picking your old account statements out of the trash gets a free ride on some important information.

That should mostly protect you. If you want to go a little extra, remember what I’ve said here before: the “mother’s maiden name” sort of thing is bad news... it’s asking you to give a weak, easily discovered password that then provides access to much more sensitive information. Don’t use your mother’s maiden name, and don’t use the last four digits of your SSN. Make up something on your own, so it’s not something that doesn’t change and can be looked up. If you really want to limit exposure, use different variations at different times. Only, either make sure you’ll never forget it, or make sure you’ll never forget your primary passwords. I’ve been tripped up a few times, when I used random garbage for “mother’s maiden name”, thinking that I’d never have to produce it, and then ran into a situation where I did, and, of course, couldn’t.

And, of course, there’s also the other standard, offline advice: opt out of financial junk mail (so thieves can’t steal your “pre-approved” credit-card solicitations from your mailbox or garbage), and order free copies of your credit reports regularly — you can get one free per year from each of the three major credit-reporting companies, so get one every four months, cycling through the three.

What makes true identity theft so nasty is that much of what makes up your “identity” in this sense is immutable information, and immutable information can’t be changed if it’s compromised. You can cancel accounts and get new ones with new numbers, of course. But your name, date of birth, and SSN are things your mostly stuck with, and it’s more or less inconvenient to change your address.

Don’t make it easy on the thieves: keep your Social Security number and other account numbers close to your chest.

More on YouTube and Viacom

There’s another disturbing aspect to the Viacom’s lawsuit against Google, besides the privacy implications of the information the judge has ordered released.

A major point in the copyright-infringement lawsuit says that Google should have done more to prevent people from storing and sharing copyrighted material. Service providers have, until now, mostly been insulated from liability for the data stored in their networks. Courts have consistently held, for example, that it’s you, not the provider of your Internet service, who is responsible for ensuring that your children don’t have access to web sites that you’d rather they not see.

The most famous exception to that is Napster, which was shut down by a court order. But that was a very different case — the argument then had been that the primary use of Napster was to share copyrighted material in violation of the copyrights. The judge agreed, in that case, that despite Napster’s claim to the contrary, the whole setup was designed to promote copyright infringement.

The Viacom/Google case is not like that at all. It’s quite easy to show that the majority of the material on YouTube is, in fact, not infringing, and, therefore, that YouTube clearly has a legitimate primary purpose. That leaves the court with the question of how much Google must do to discourage or prevent infringement. Until now, the answer has been “Not much.”

If Viacom wins this billion-dollar lawsuit, there could be disastrous consequences to open data sharing, free speech, and fair use on the Internet. The Associated Press is already trying to place ridiculous limits on citations from its news items (five words, according to some reports!), and the state of Oregon recently backed down from an attempt to declare its state laws — the public laws that everyone must know and follow — to be copyrighted material that could not be posted.

Many people post copyrighted photos to their blogs — they shouldn’t, but they do. Many blogs, including this one, sometimes use fairly lengthy quotes from sources — some quote entire articles, and don’t always attribute them. Blogspot, like YouTube, is owned by Google. So is Picasa, a photo-sharing site. An expensive settlement with Viacom in this case will certainly make Google worry about what it allows on its other sites? Other service providers, such as Yahoo! and the various social networking sites will have to worry as well.

The problem, of course, is that the companies’ responses won’t be limited to stopping wholesale copyright infringement. To avoid ruinous settlements, they’ll have to go too far in the other direction, ultimately limiting fair use and assuming infringement where none exists. There’ll be serious restrictions on what can be posted, and there’ll be a chilling effect that goes beyond what’s actually prohibited.

None of us — in the end, not even companies such as Viacom — will benefit from the squelching of open communication, information, sharing, artistic freedom, and free speech that would result from such a decision.

That’s why I hope they do not win this one. Viacom has a right, if they choose to exercise it, to demand that their protected material not be posted wholesale. They do not have a right to demand that Google or any other content host police it for them.

YouTube and Viacom and privacy

Oh, my!

A federal judge has ordered Google to turn over YouTube usage data, as part of Viacom’s copyright-infringement lawsuit:

A federal judge has ordered Google to turn over to Viacom its records of which users watched which videos on YouTube, the Web’s largest video site by far.

The order raised concerns among YouTube users and privacy advocates that the video viewing habits of tens of millions of people could be exposed. But Google and Viacom said they were hoping to come up with a way to protect the anonymity of the site’s visitors.

Viacom also said that the information would be safeguarded by a protective order restricting access to the data to outside lawyers, who will use it solely to press Viacom’s $1 billion copyright suit against Google.

Still, the judge’s order, which was made public late Wednesday, renewed concerns among privacy advocates that Internet companies like Google are collecting unprecedented amounts of private information that could be misused or fall unexpectedly into the hands of third parties.

That last bit is really the significant part. There are many things that could be done in this case to limit the damage — the privacy exposure. Restricting who has access to the information is the most obvious.

They could also agree to have the data anonymized before it leaves Google. Even better, they could limit what information is released. For the specific purpose of the motion in question, the judge’s order is far broader than it needs to be. Viacom is ostensibly looking for information about what videos are being watched, and how often — not, specifically, who is watching them. Yet:

For every video on YouTube, the judge required Google to turn over to Viacom the login name of every user who had watched it, and the address of their computer, known as an I.P. or Internet protocol address.

Such a broad order isn’t surprising from a judge who doesn’t really understand the technological aspects of all this, and I don’t expect a judge to be well versed in that stuff. It would be nice, therefore, if he had expert advice on it — advice other than the depositions of experts called by either side of the tussle.

For this motion, it would be sufficient for Google to provide only a list of videos along with the number of times each has been viewed within some time window (say, the month of June). No information is needed that identifies the users in any way — not user names, not IP addresses[1], not even the dates and times the videos were accessed.

If Google has to give all the detailed information to Viacom, there are two big issues with that. First, it’s an enormous amount of information. According to the article, 4.1 billion YouTube videos were accessed in April. That’s around 1600 every second. Sifting through that, on both sides, will take a while and will cost a lot. Second, and more important from a privacy point of view, Viacom can use the information to pursue the users, possibly trying to use RIAA-style strong-arm tactics to extort money from the highest-volume viewers.

They say they won’t do that, and that Viacom itself won’t have access to the data. But are we sure? What will their next motion be, and how will the judge decide it? This could easily turn into a fishing expedition, and a dangerous one with wide-ranging effects, which could be quelled by a more informed judge who was more selective in what he ordered.

Where this all really takes us, though, is not just to the privacy aspects of this case, but to the understanding that there isn’t really any privacy on the Internet — a refrain I’ve sung here before. Any data that’s kept can be divulged, be it by mistake, through hacker attacks, after a unilateral change in privacy policy, or in response to legal demands from a court or illegal demands from the government. No matter what assurance you have today, you don’t know what will happen to the data tomorrow. The only information that’s safe is information that’s not kept, not backed up, not archived.

And with the exception of services that are expressly designed for anonymity, this sort of information is always kept, and, therefore, is always subject to being divulged.

 

---

[1] The article says, “Both companies have argued that I.P. addresses alone cannot be used to unmask the identities of individuals with certainty. But in many cases, technology experts and others have been able to link I.P. addresses to individuals using other records of their online activities.” Yes, indeed: knowing the IP address and the exact time of use can, in most situations, get someone with a subpoena direct access to the identity of the user, at least for users within the United States (and, therefore, under the jurisdiction of the subpoena). This has been done many times, in many court cases, and is well known.

I also find the NY Times’ style of using periods in all abbreviations to be... quaint. No one writes “I.P. address” except the Times.

My laptop, my home

Last week there was a Senate hearing about laptop searches at airports, specifically, about whether it’s reasonable to search the laptops of Americans who are not suspected of any wrongdoing when those people enter the country:

Advocacy groups and some legal experts told Congress on Wednesday that it was unreasonable for federal officials to search the laptops of United States citizens when they re-enter the country from traveling abroad.

Civil rights groups have said certain ethnic groups have been selectively profiled in the searches by Border Patrol agents and customs officials who have the authority to inspect all luggage and cargo brought into the country without obtaining warrants or having probable cause.

On the “Yes, search,” side is the standard claim:

The federal government says the searches are necessary for national security and for legal action against people who bring illegal material into the country.

And to the argument that this is different from searching your home without a warrant, there’s this:

But Nathan A. Sales, an assistant professor at the George Mason University School of Law, said in a statement: “The reason the home has enjoyed uniquely robust privacy protections in the Anglo-American legal tradition is because it is a sanctuary into which the owner can withdraw from the government’s watchful eye. Crossing an international border is in many ways the opposite of this kind of withdrawal.”

On the other side, apart from the complaint of racial/ethnic/religious profiling, is the claim that your computer is an extension of your home and/or office these days, and the general disagreement with what Dr Sales says:

“In today’s wired, networked and borderless world, one’s office no longer sits within four walls or a cubicle; rather, one’s office consists of a collection of mobile electronic devices such as a laptop, a BlackBerry, PDA, and a cellphone,” Ms. Gurley said in prepared remarks.

She said the searches meant that “you may find yourself effectively locked out of your office indefinitely.”

Ms. Gurley said a concern was the lack of published regulations explaining what happened to data when it was seized and who had access to it.

Tim Sparapani, senior legislative counsel for the American Civil Liberties Union, said in an interview, “You can’t go into my home and search my computer without a warrant, but simply because I’m carrying my computer with me as I travel, you can search it.”

I won’t be a surprise that I’m on the second side, along with the ACLU and other civil rights groups. Here’s why:

There’s a significant difference between looking for weapons in your bags... and looking for information in them. I think few people would agree that the authorities have reason or right to look through whatever papers you’ve brought with you, to sit and read your personal papers while you wait, to confiscate them, or to take them off and copy them for later scrutiny.

Few would tolerate having their vacation film, for those who still use film, seized, processed, and scrutinized, along with some vague assurance that it’d be returned eventually. Few would stand by while their tape recordings were played back or copied before they could be allowed in the country.

We should be no more tolerant of scrutiny of writings, photos, audio, or video that’s carried on electronic storage. Your laptop, your iPod, your digital camera, your mobile phone... are not weapons, nor in any other way imminent threats.

Apart from that, once these things are taken from you, even when they’re returned you have no assurance that they haven’t been tampered with. Data could have been erased or altered. Software could have been installed. Hardware could have been changed. Perhaps your laptop will now record everything you do, down to every keystroke and mouse click, and send it to the Department of Homeland Security. Maybe now, whenever you transfer photos from your camera to your computer, DHS gets a copy.

Unlikely? Maybe it is. But it’s fully possible, and you have no way to know.

Protection from unreasonable search and seizure of electronic equipment is critically important to our freedom, because of what can be done with that equipment when it’s in the hands of the government. Unless they have cause for the search — and a warrant to support that — your belongings in general, and your electronic belongings in particular, should never leave your sight and control.

To drift from that is to drift toward a police state.
 

---

Update, 10 July: The New York Times agrees, weighing in with this editorial.

The Department of Homeland Security is routinely searching laptops at airports when Americans re-enter the United States from abroad. The government then pores over or copies the laptop’s contents — including financial records, medical data and e-mail messages. These out-of-control searches trample the privacy rights of Americans, and Congress should rein them in.

[...]

The government has the right to take reasonable steps to control what comes into the country, but the laptop-search program’s invasions of privacy go far beyond what is reasonable.

RFID tags and medical equipment

There’s been a study in the Journal of the American Medical Association that’s made the news in the last couple of days, showing that RFID tags (those little devices — or sometimes not so little ones — that are used for inventory control and such) interfere with medical equipment [see USA Today, New Scientist, and the summary at the JAMA site].

The researchers set up readers and tags near active equipment, and recorded whether the equipment was adversely affected, and at what range. From New Scientist (where they give more details than USA Today does):

His team tested two RFID systems and dozens of medical devices, none of which were connected to patients. The researchers tested devices within meters of an RFID reader broadcasting a radio signal to nearby tag. The strength of the radio signal, though high, was not unrealistic.

If the signal caused a device to break down, the researchers moved the device away until the interference stopped. If the initial test turned up negative, van Lieshout’s team inched the device closer.

In 123 tests of 41 different pieces of equipment, the devices malfunctioned 34 times — 22 of the glitches were deemed serious enough to affect patients. For instance, eight of nine syringe pumps, which trickle medicine to patients, failed completely when exposed to an RFID field,