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.

Put your money where your principles are

I have some political donation money to spend.

Let’s see:

1. Barack Obama, whom I supported in the primary election, voted for the Presidential Spying Bill, in the end. One might argue that it was going to pass anyway, and he was just avoiding political trouble with a vote that didn’t matter anyway. But it did matter: one stands on one’s principles, or one falls.
2. The American Civil Liberties Union and the Electronic Frontier Foundation have, since the bill was signed into law, filed suit to challenge it.

   The ACLU contends those blanket powers to grab international communications of Americans without specific court orders violate the Fourth Amendment and would stymie journalists who often speak to confidential sources outside the country.

   That’s standing on principles — the principles this country was founded on.

So....

Where do you think my donation money will go now? To Senator Obama? Or to the ACLU and the EFF?

Hmm....

“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.

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.

Cameras in the security theatre

I read the following two items on the same day.

The first item is “More Delays for Cameras in Subways ”, in the New York Times:

Aging fiber-optic cable in Brooklyn and Queens has become the latest obstacle to a planned high-tech system of surveillance cameras meant to safeguard the subway and commuter railroads, according to Metropolitan Transportation Authority officials.

The system, which is expected to cost at least $450 million, is a crucial component of a larger program to thwart terrorist attacks on the region’s transportation network, but it has met repeatedly with technical problems and delays.

[...]

The comptroller’s report also said that the surveillance project had been scaled back because of problems adapting the cameras’ software to conditions in the authority’s facilities.

One of the officials who spoke on Wednesday said those problems involved the cameras’ ability to spot an unattended bag or briefcase left on a train platform or other busy area and then alert law enforcement to the possible hazard. That capability had originally been promoted as a major feature of the system, but the official said it had failed in tests.

“There are too many people, too many things moving around in the system,” the official said.

[...]

The comptroller’s office has issued periodic reports highlighting delays and increasing costs in the authority’s security program, which was conceived after the Sept. 11, 2001, terrorist attack on the World Trade Center. The program includes the surveillance system as well as other projects to improve the security of bridges, tunnels and other facilities.

The second item is “CCTV doesn’t keep us safe, yet the cameras are everywhere”, by Bruce Schneier for The Guardian (UK):

Pervasive security cameras don’t substantially reduce crime. There are exceptions, of course, and that’s what gets the press. Most famously, CCTV cameras helped catch James Bulger’s murderers in 1993. And earlier this year, they helped convict Steve Wright of murdering five women in the Ipswich area. But these are the well-publicised exceptions. Overall, CCTV cameras aren’t very effective.

This fact has been demonstrated again and again: by a comprehensive study for the Home Office in 2005, by several studies in the US, and again with new data announced last month by New Scotland Yard. They actually solve very few crimes, and their deterrent effect is minimal.

[...]

But the question really isn’t whether cameras reduce crime; the question is whether they’re worth it. And given their cost (£500 m in the past 10 years), their limited effectiveness, the potential for abuse (spying on naked women in their own homes, sharing nude images, selling best-of videos, and even spying on national politicians) and their Orwellian effects on privacy and civil liberties, most of the time they’re not. The funds spent on CCTV cameras would be far better spent on hiring experienced police officers.

It seems that the one is evidence for the other, doesn’t it?

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.

The next step in phishing

I’ve recently seen a new angle[1] on phishing — the practice of sending deceptive email messages to try to snag personal information such as account numbers and passwords. Usually, the phishers try to hit your bank account, credit cards, or online payment system, hoping to get direct access to your money. But last week I got a message that tried to get access to an airline frequent-flier account:

Subject: AAdvantage Survey Program

Greetings from AA.com

Welcome to the American Airlines AAdvantage(R) program, the first and largest loyalty program in the world! We are proud to inform you that today June. 26 /2008 AmericanAirlines.com launch a new reward program. Please log in to your American Airlines account and take the 5 questions survey. For your effort you will be rewarded with $50

Your 50 dollars bonus code is AA-001NXX-2008NX22. Please log in to your www.aa.com account and follow the steps.

Thank you very much for your help and your patient and hope you will enjoy the American Airlines reward program in the future

Sincerely,
American Airlines Reward Department
Please do not reply to this auto-answer message

The clues are the errors in grammar and the missing punctuation (and, um, the fact that it’s not “today, June. 26 /2008” yet). The actual link behind the www.aa.com text points to a web server in Russia.

Of course, if they can get at my AAdvantage account, they could cash in my miles. They could also buy tickets with my credit card if I’ve saved my card information in my account (I haven’t). And, of course, if they get any password, they can try using it in other places too. That’s all good reason for me to remind you to use proper passwords on these sorts of accounts, keep them secret, and don’t use the same password for all of them (limit your exposure, so if one is compromised it doesn’t give access to others).

It’s also a good reminder to keep your hand on your wallet. The bad guys will try to break into anything, from your bank account to your email and Facebook accounts. Watch out.
 

---

[1] Get it? Angle, fish, phishing.... Yeah, OK.

Phishing gets more sophisticated

The folks at F-Secure alert us to an interesting phishing technique. Phishing, for the non-techies reading, is the practice of sending email that tries to get you to respond (usually by going to a web site) by giving them personal information, including login credentials, account information, social security numbers, and the like. You’ve seen the email, with dire warnings that your bank account will be frozen unless you click immediately on the link they provide, and log in to clear up some “problem”. What you actually do is give them the information they need to log into your account.

In this variation, the phishers are trying a new ploy to suck you in, and adding a nasty mechanism to install bad software on your computer:

From: Clients support team
Subject: Comerica Bank - Significant information for our clients.

Client authentication using digital certificates in COMERICA BANK®

Dear Customer,

Comerica.com site has requested that you identify yourself with a certificate.
The next step in the transformation of Comerica Online is Digital Certificate (DC) access.
This DC will allow you to access Comerica Bank and other online services through a single sign-on.

All users will be notified and transitioned to the new URL between April 2008 and October 2008.

Please register your DC account and use our servcies safely.

Continue>>

2008 Comerica Bank. All rights reserved.

The link (which is disabled in the text above) takes you to a web page that “explains” what you have to do, and it involves running a “DC Loader Wizard”... which, of course, installs their malware — spyware that records what you do on your computer, including any login credentials that you use later today, or next week, or next month. In other words, it’s a phish that stays around and keeps on stinking.

Now, ignore the awkward phrasing of the message, and raise your hand if you’d give this concept at least a modicum of credibility in your mind — the idea that your bank might switch to certificate-based authentication, in order to improve security. Is your hand up? Mine is.

Now, that doesn’t mean I’d have been caught by this; I wouldn’t, but more on that later. What it does mean is that these phishers have gone away from the scenario that we’ve well learnt not to trust. They aren’t asking for personal information, they’re not asking us to log on.

Instead, they’re asking us to do something that we’ve heard is good for security. Almost. The trick, of course, is getting us to install software — even software that calls itself a “DC Loader Wizard“ — from an untrusted source.

And that’s where they wouldn’t catch me, and shouldn’t catch you. The core bit of advice that’s operative here is that you never, for any reason, visit a “trusted” web site through a link in email. Keep bookmarks in your browser for those things — your banks, your credit cards, your social networking sites, your email accounts — and use your own, trusted and tested links for them, always. Or else type them in by hand. Then you know where you’re going.

And when you get there and you don’t find anything about digital certificates or a DC Loader Wizard, say “Mmm, hmm....”

Judicial review for the terrorism watch list

One bit of security theatre gets scrutiny by a federal judge.

A federal magistrate judge in Chicago has ruled that protecting state secrets is not a valid argument for the government to refuse to tell American citizens whether they are on the terrorism watch list, the Terrorist Screening Database. The ruling, signed on April 16 but made public by the American Civil Liberties Union of Illinois on Wednesday, ordered the Department of Homeland Security and the F.B.I. to give the court the files regarding the 10 Muslim or Arab-American plaintiffs who filed a lawsuit starting in 2005, seeking court protection from what they contend is unwarranted harassment at the border. The magistrate judge, Sidney I. Schenkier of Federal District Court, said the court could review the information to decide whether it should remain classified. The F.B.I. said it had no comment.

This doesn’t mean that the watch list will go away, nor that it will be made public, nor even that we’ll certainly be allowed to know whether or not we’re on it. What it does is provide a crucial bit of oversight: it says that it gets reviewed by the court.

And that is a critically important thing.

Your privacy on the Internet

The New York Times recently published an op-ed piece by Adam Cohen about how the information that Internet Service Providers (ISPs) have about their users can be a significant privacy issue:

Technology companies have long used “cookies,” little bits of tracking software slipped onto your computer, and other means, to record the Web sites you visit, the ads you click on, even the words you enter in search engines — information that some hold onto forever. They’re not telling you they’re doing it, and they’re not asking permission. Internet service providers are now getting into the act. Because they control your connection, they can keep track of everything you do online, and there have been reports that I.S.P.’s may have started to sell the information they collect.

Mr Cohen talks about targeted advertisements — a practice that most people consider benign, or even helpful, without considering the privacy implications — but goes on to talk about how much further things go:

The bigger issue is the digital dossiers that tech companies can compile. Some companies have promised to keep data confidential, or to obscure it so it cannot be traced back to individuals. But it’s hard to know what a particular company’s policy is, and there are too many to keep track of. And privacy policies can be changed at any time.

There is also no guarantee that the information will stay with the company that collected it. It can be sold to employers or insurance companies, which have financial motives for wanting to know if their workers and policyholders are alcoholics or have AIDS.

It could also end up with the government, which needs only to serve a subpoena to get it (and these days that formality might be ignored).

A bit of this sort of thing got press last November, when Facebook’s “Beacon” feature started exposing people’s Internet purchases to their online “friends”. So, yes, as Mr Cohen notes:

The public has been slow to express outrage — not, as tech companies like to claim, because they don’t care about privacy, but simply because few people know all that is going on. That is changing. “A lot of people are creeped-out by this,” says Ari Schwartz, a vice president of the Center for Democracy and Technology. He says the government is under increasing pressure to act.

The message of the op-ed piece is, in the end, that we need to be aware of this and that federal laws that address privacy of telephone communications need to be extended to address the Internet.

I agree. But that will only go so far, because

1. it’ll be hard for laws to address what information companies collect and keep when you visit their web sites and use their services, and
2. while it is true that Internet users are gradually becoming more aware of privacy issues, it’s also true that there’s far too much of which people aren’t aware.

In particular, I want to say something about what Mr Cohen breezed past at the beginning of his essay: browser cookies.

Long ago, early in the days of the worldwide web, “cookies” were devised as a way to add some state to the stateless HTTP protocol. Basically, the issue is that hypertext transfer protocol (HTTP) is (mostly) sessionless, stateless, and identityless. When you retrieve a web page, your browser contacts the web server and says, “give me [x]”. The response is the content of web page [x], after which your connection with the server ends. When you click on page [y] on the same web site, your browser again connects to the (same) web server and says, “give me [y]”. There’s no reliable way for the server to link those two requests, to know that they were done by the same user, the same browser, the same “browsing session”.

The server could look at your computer’s Internet address, which it gets when your browser makes the connection. But that’s not reliable, because the address could have been reassigned to another computer between the two requests. Or, more likely, because you and I are both using the same HTTP proxy, and the address it sees is the address of the proxy server, not of our individual computers.

But if we’re browsing a catalogue and accumulating items in “shopping carts”, the web server has to keep track of what got put into what cart. And you can come up with many other good reasons for a server to know that a new request is a follow-up to an earlier one.

And, so, we have cookies. A cookie is simply a small bit of data that the web server gives to your browser as part of the response to “give me [x]”. It basically says, “here; save this, and give it back to me when I ask for it.” When you ask for page [y], the web server says, “Do you have that cookie I might have given you before?” If you do, and your browser sends it back, it can use that to keep you connected to the shopping-cart database, maintaining your cart as you shop. Or whatever.

And we were always told that cookies are “safe”. For one thing, it’s just a bit of data that the web server gave to your browser, so it contains no information that the server doesn’t already have. And your browser will only give it back to the same server it got it from. All it does it enhance your web-browsing experience; what could be bad?

What can be bad is that it ties together every request you make to the web server, along with all the information you send to the server in browser forms and such. By setting a cookie, the web server can keep a database of every page you visited at that web site, every button you pressed, every box you checked, every text field you filled in, every ad it showed you, every question it asked you, every answer you gave, every... everything you did at that site.

The cookie itself doesn’t say who you are. But, hey, once they get you to fill in a form — say, an order form — with your name and address, they have that information associated with the cookie they gave you. And that connects it to everything else.

And here’s another thing: as the company expands and you use more of their services, there’s more that they keep track of and tie together. Your Google searches are connected to what you do at Google Maps, at Flickr, at YouTube, at Blogger....

Most browsers have a way to “turn off” cookies, but that’s essentially a useless feature these days: so many web sites require cookies — they’ll refuse to give you anything, and will simply give you a page that explains how to turn cookie support back on. So unless you’re willing to have 75% of the web not work for you, you’re stuck with cookies and the data-collection that they enable.

There’s more, too; most people don’t know what other information web sites get from your browser. The browser usually tells the web server such things as what operating system you’re using, what browser (and version) you’re using, what your screen resolution is, what page you clicked on to get here, what search you ran to get here.... If it can tie all that to a cookie, it has that much more information. In particular, it now also knows what web sites you visit before coming here. Hm.

And there’s not really anything you can do about it. Anonymizing services, which act as proxies and hide that sort of information — omit some, lie about some, block cookies — will make too many web sites not work. The average user will not be willing to accept that, and will give up the privacy, usually with a shrug.

Privacy laws that cover this stuff have to be sufficiently robust that they catch all of this, not just the more egregious bits. The U.S. government doesn’t have a good track record in that regard, I’m afraid. The people writing the laws aren’t savvy enough to get it right. And there’s a great deal of lobbying from companies and organizations that will benefit — at the expense of your privacy — from having access to this information.

Conference on Email and AntiSpam (CEAS) call for papers, deadline extended

The 2008 Conference on Email and Anti-Spam submission deadline is approaching, and has been extended by a week, to 10 April. If you have any work to report on in the area of Internet messaging abuse and its prevention — not limited to email spam; see the topic list in the CfP, below — please form it into a paper by next week, and submit it.

---

THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

Thursday August 21 and Friday August 22, 2008
Microsoft Research Silicon Valley
Mountain View, California
<http://www.ceas.cc>

FINAL CALL FOR PAPERS
 

The Conference on Email and Anti-Spam (CEAS) invites the submission of papers for its fifth meeting. Papers are invited on all aspects of electronic communication including email, instant messaging, text messaging, and voice over internet protocol (VoIP). Topics of interest include novel applications of electronic messaging, abatement of abuses of electronic messaging, spam, spit (spam over internet telephony), spim (spam over instant messenger), phishing, identity theft via messaging, viruses, and spyware.

Paper submissions can be either research papers, extended abstracts, industry reports, or law and policy papers. Submissions from practitioners and vendors are encouraged. Papers will be selected by peer review for presentation at CEAS 2008. Papers will be reviewed based on their contribution to the literature.

SUGGESTED TOPICS:

• Message filtering, blocking, authentication
  • Machine learning
  • Natural language processing
  • Adversarial learning
  • Challenge-response
  • Payment schemes
  • Disposable addresses
  • Messaging protocols
  • Digital signatures
• Evaluation
  • Corpus and benchmark creation
  • Measures and methodologies
  • Comparative tests of methods or products
• Analysis
  • Economics of spam, spit, spim, phishing, etc.
  • Abuse tactics and patterns
  • Legitimate use patterns
  • Historical data
• Message organization and search
  • Advanced calendaring and scheduling
  • Automatic foldering
  • Automatic routing
  • Summarization
  • Search
• Systems and network issues
  • Performance & scalability
  • Reliability & security
  • Archival & retrieval
• User issues
  • User interfaces
  • Usability studies
  • Messaging in support of user activities
• Social issues
  • Deducing social networks
  • Costs and benefits of messaging use and abuse
  • Other social impacts
• Industry
  • Cooperation for stopping abuse
  • Messaging and abuse reporting standards
  • Interoperability
• Legal issues
  • Spam, spit, spim and phishing, etc.
  • Identity theft
  • Privacy
  • Freedom of speech
  • Digital rights management

KEY DATES:

• Submission deadline: April 10, 2008 (10:59pm UTC) — EXTENDED DATE
• Notification of acceptance: June 6, 2008.
• Final camera-ready version of papers: June 21, 2008
• Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:

• Extended abstracts (up to 2 pages) may outline work in progress, exceptional papers published for different scientific communities, original research, or industry reports.
• Full papers (up to 10 pages). Work may not have been previously published in, or under consideration for publication in any other conference or journal.

Submissions must use the CEAS electronic system at https://cmt.research.microsoft.com/CEAS2008/. The style for submissions and final papers is a two-column, 8.5 by 11 inch format. See http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and industrial research centers. Accepted papers will be made freely available on the web, and will be published on CD-ROM. Authors will retain copyright of their work.

CONTACT:

• The conference chair and co-chairs can be reached at information@ceas.cc

CEAS PRESIDENT:

• Gordon Cormack
  University of Waterloo
  http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

• Aleksander Kolcz
  Microsoft Live Labs
  http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

• Andrej Bratko
  Jozef Stefan Institute
  http://ai.ijs.si/andrej/
   
• Barry Leiba
  IBM Research
  http://www.research.ibm.com/people/l/leiba/
   
• Tobias Scheffer
  Max Planck Institute for Computer Science
  http://www.mpi-inf.mpg.de/~scheffer/
   

Amtrak phishes its own customers

On 13 Feb I received email from “Amtrak <amtrak@amtrak.bfi0.com>”. See the image below (click for full size). In short, the email tells me that “changes are coming”, and that “Prior to this update, we ask that you log in to verify the accuracy of the information in your account.” There are several web links in the message that point to Amtrak web sites, but the key one, the one that says “Go to Amtrak.com Now and Update Your Profile”, links to “http://amtrak.bfi0.com/W0RH01300F84...redacted...30”.

Now... as best I can tell (no, I did not click on the link), this actually is legitimate. I made an Amtrak reservation last week, about two weeks after having received that message, and they have changed the way I have to log in (using my email address, rather than the user name I’d created before).[1] But the email message used Epsilon’s email service (bfi0.com), which they’ve apparently contracted to do their mailings, and the key link points back to Epsilon, not to Amtrak.

If this was, indeed, a legitimate mailing, I have something to say to Amtrak about it: You made a big mistake by contracting your mailings to that company. This email message looks exactly like a phishing message that’s trying to steal my login and password information. Don’t you know, as most of the rest of the world does by now, not to send out messages like that?

More specifically, here’s what makes it look like phishing:

1. The message claims to be from Amtrak, but does not use an amtrak.com address.
2. The premise of the message is the same as in many phishing messages: we’re changing our system, and we need you to log in and “verify” your information. It couldn’t match better if a phisher had written it.
3. All of the links that don’t matter are the real ones, but the operative link, the one you’re meant to click on, points to something else, something that’s not amtrak.com.
4. Making number 3 worse, the funny URL has a lot of random-looking junk in it.
5. It uses one of those suspiciously folksy signatures, “The Amtrak E-commerce Team”. As I said, it looks like a phisher actually wrote it.

And, the clues that it’s real? There are two. One is that it calls me “Barry”, which a phisher would probably not. They could have made a point of telling me that, but they didn’t, and many people would probably not notice it, nor realize that it lends some credibility to the message. On the other hand, clever phishers could do that also, in cases where they have email addresses associated with full names (which would be easy with my address).

The other is that bfi0.com is registered to a legitimate email marketing company, Epsilon (that should know better than to send out crap like this), and a thorough check of the message confirms that it almost certainly did come from bfi0.com, and isn’t just claiming so. The funny URL will get you to amtrak.com’s web site, but sends you through bfi0.com to get there because they’re counting the click-throughs for marketing purposes (maybe just for tracking, but it’s likely they’re getting paid more for more clicks).

So what should they have done? I’m glad you asked:

1. Set up DKIM, send the message out as amtrak.com (not as amtrak.bfi0.com), and make sure that the DKIM signature is verifiable.
2. Make sure all the links in the message clearly go directly to amtrak.com.
3. Do not encourage users to click a link in the message to log in anyway. Tell them in plain text to “go to amtrak.com” and log in there. Tell them that it’s safer if they do it that way, because it’s less likely to put their account information at risk.
4. Be less vague about what’s happening. Part of what makes the message suspicious is the vagueness: we’re changing something, but we’re not giving you any details.

I know that 2 and 3 are not what Epsilon and other marketers want to hear. Without being able to track click-throughs, they have a real problem in knowing how successful their campaigns are, and they can’t use that as a way to write their contract terms. That’s too bad, but, well, that’s just too bad. We just have to stop asking or expecting users to click on links in their email, especially funny-looking ones.

It’s garbage like this that keeps the phishers in business, by teaching people to be careless. Amtrak — and Epsilon — should be ashamed.
 

---

[1]Side issue: I actually hate the practice of using my email address as my login identity. It means that it’s harder for me to use domain-specific login identities, and strongly pushes me to use the same identity everywhere. It’s easy to see why the web sites like it, of course: it makes it easier for people to create accounts because they already have a unique name to use, and it reduces support questions about forgotten login identities — the web sites just tell you to enter your email address.

One problem with it, even for people who would prefer to use the same identity everywhere, is that there’s a strong tendency, because you’re using your email address, to use your email password too. That exposes your email, of course. It also means that you’re likely to have the same identity and password for multiple web sites, so someone who snatches your Amtrak information, say, can go start trying it on other sites, like airlines, stores, banks, PayPal....