November 23, 2024

EFF Researchers Decode Hidden Codes in Printer Output

Researchers at the EFF have apparently confirmed that certain color printers put hidden marks in the pages they print, and they have decoded the marks for at least one printer model.

The marks from Xerox DocuColor printers are encoded in an array of very small yellow dots that appear all over the page. The dots encode the date and time when the page was printed, along with what appears to be a serial number for the printer. You can spot the dots with blue light and a 10X magnifier, and you can then decode the dots to get the date, time, and serial number.

Many other printers appear to do something similar; the EFF has a list.

The privacy implications are obvious. It’s now possible to tell when a document was printed, and when two documents were printed on the same printer. It’s also possible, given a document and a printer, to tell whether the document was printed on that printer.

Apparently, this was done at direction of the U.S. government.

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

Xerox previously admitted that it provided these tracking dots to the government, but indicated that only the Secret Service had the ability to read the code.

The assertion that only the Secret Service can read the code is false. The code is quite straightforward. For example, there is one byte for (the last two digits of) the year, one byte for the month, one byte for the day, one byte for the hour, and one byte for the minute.

Now that the code is known, it should be possible to forge the marks. For example, I could cook up an array of little yellow dots that encode any date, time, and serial number I like. Then I could add the dots to any image I like, and print out the image-plus-dots on a printer that doesn’t make the marks. The resulting printout would have genuine-looking marks that contain whatever information I chose.

This could have been prevented by using cryptography, to make marks that can only be decoded by the Secret Service, and that don’t allow anyone but the secret service to detect whether two documents came from the same printer. This would have added some complexity to the scheme, but that seems like a good tradeoff in a system that was supposed to stay secret for a while.

Secure Flight: Shifting Goals, Vague Plan

The Transportation Security Administration (TSA) released Friday a previously confidential report by the Secure Flight Working Group (SFWG), an independent expert committee on which I served. The committee’s charter was to study the privacy implications of the Secure Flight program. The final report is critical of TSA’s management of Secure Flight.

(Besides me, the committee members were Martin Abrams, Linda Ackerman, James Dempsey, Daniel Gallington, Lauren Gelman, Steven Lilienthal, Bruce Schneier, and Anna Slomovic. Members received security clearances and had access to non-public information; but everything I write here is based on public information. I should note that although the report was meant to reflect the consensus of the committee members, readers should not assume that every individual member agrees with everything said in the report.)

Secure Flight is a successor to existing programs that do three jobs. First, they vet air passengers against a no-fly list, which contains the names of people who are believed to pose a danger to aviation and so are not allowed to fly. Second, they vet passengers against a watch list, which contains the names of people who are believed to pose a more modest danger and so are subject to a secondary search at the security checkpoint. Third, they vet passengers’ reservations against the CAPPS I criteria, and subject those who meet the criteria to a secondary search. (The precise CAPPS I criteria are not public, but it is widely believed that the criteria include whether the passenger paid cash for the ticket, whether the ticket is one-way, and other factors.)

The key section of the report is on pages 5-6. Here’s the beginning of that section:

The SFWG found that TSA has failed to answer certain key questions about Secure Flight: First and foremost, TSA has not articulated what the specific goals of Secure Flight are. Based on the limited test results presented to us, we cannot assess whether even the general goal of evaluating passengers for the risk they represent to aviation security is a realistic or feasible one or how TSA proposes to achieve it. We do not know how much or what kind of personal information the system will collect or how data from various sources will flow through the system.

The lack of clear goals for the program is a serious problem (p. 5):

The TSA is under a Congressional mandate to match domestic airline passenger lists against the consolidated terrorist watch list. TSA has failed to specify with consistency whether watch list matching is the only goal of Secure Flight at this state. The Secure Flight Capabilities and Testing Overview, dated February 9, 2005 (a non-public document given to the SFWG), states in the Appendix that the program is not looking for unknown terrorists and has no intention of doing so. On June 29, 2005, Justin Oberman (Assistant Administrator, Secure Flight/Registered Traveler [at TSA]) testified to a Congressional committee that “Another goal proposed for Secure Flight is its use to establish “Mechanisms for … violent criminal data vetting.” Finally, TSA has never been forthcoming about whether it has an additional, implicit goal – the tracking of terrorism suspects (whose presence on the terrorist watch list does not necessarily signify intention to commit violence on a flight).

The report also notes that TSA had not answered questions about what the system’s architecture would be, whether Secure Flight would be linked to other TSA systems, whether and how the system would use commercial data sources, and how oversight would work. TSA had not provided enough information to evaluate the security of Secure Flight’s computer systems and databases.

The report ends with these recommendations:

Congress should prohibit live testing of Secure Flight until it receives the following from the [Homeland Security Secretary].

First, a written statement of the goals of Secure Flight signed by the Secretary of DHS that only can be changed on the Secretary’s order. Accompanying documentation should include: (1) a description of the technology, policy and processes in place to ensure that the system is only used to achieve the stated goals; (2) a schematic that describes exactly what data is collected, from what entities, and how it flows though the system; (3) rules that describe who has access to the data and under what circumstances; and (4) specific procedures for destruction of the data. There should also be an assurance that someone has been appointed with sufficient independence and power to ensure that the system development and subsequent use follow the documented procedures.

In conclusion, we believe live testing of Secure Flight should not commence until there has been adequate time to review, comment, and conduct a public debate on the additional documentation outlined above.

Speaking for myself, I joined the committee with an open mind. A system along the general lines of Secure Flight might make sense, and might properly balance security with privacy. I wanted to see whether Secure Flight could be justified. I wanted to hear someone make the case for Secure Flight. TSA had said that it was gathering evidence and doing analysis to do so.

In the end, TSA never did make a case for Secure Flight. I still have the same questions I had at the beginning. But now I have less confidence that TSA can successfully run a program like Secure Flight.

Privacy, Price Discrimination, and Identification

Recently it was reported that Disney World is fingerprinting its customers. This raised obvious privacy concerns. People wondered why Disney would need that information, and what they were going to do with it.

As Eric Rescorla noted, the answer is almost surely price discrimination. Disney sells multi-day tickets at a discount. They don’t want people to buy (say) a ten-day ticket, use it for two days, and then resell the ticket to somebody else. Disney makes about $200 more by selling five separate two-day tickets than by selling a single ten-day ticket. To stop this, they fingerprint the users of such tickets and verify that the fingerprint associated with a ticket doesn’t change from day to day.

Price discrimination often leads to privacy worries, because some price discrimination strategies rely on the ability to identify individual customers so the seller knows what price to charge them. Such privacy worries seem to be intensifying as technology advances, since it is becoming easier to keep records about individual customers, easier to get information about customers from outside sources, and easier to design and manage complex price discrimination strategies.

On the other hand, some forms of price discrimination don’t depend on identifying customers. For example, early-bird discounts at restaurants cause customers to self-select into categories based on willingness to pay (those willing to come at an inconvenient time to get a lower price vs. those not willing) without needing to identify individuals.

Disney’s type of price discrimination falls into a middle ground. They don’t need to know who you are; all they need to know is that you are the same person who used the ticket yesterday. I think it’s possible to build a fingerprint-based system that stores just enough information to verify that a newly-presented fingerprint is the same one seen before, but without storing the fingerprint itself or even information useful in reconstructing or forging it. That would let Disney get what it needs to prevent ticket resale, without compromising customers’ fingerprints.

If this is possible, why isn’t Disney doing it? I can only guess, but I can think of two reasons. First, in designing identity-based systems, people seem to gravitate to designs that try to extract a “true identity”, despite the fact that this is more privacy-compromising and is often unnecessary. Second, if Disney sees customer privacy mainly as a public-relations issue, then they don’t have much incentive to design a more privacy-protective system, when ordinary customers can’t easily tell the difference.

Researchers have been saying for years that identification technologies can be designed cleverly to minimize unneeded information flows; but this suggestion hasn’t had much effect. Perhaps bad publicity over information leaks will cause companies to be more careful.

What is Spyware?

Recently the Anti-Spyware Coalition released a document defining spyware and related terms. This is an impressive-sounding group, convened by CDT and including companies like HP, Microsoft, and Yahoo.

Here is their central definition:

Spyware and Other Potentially Unwanted Technologies

Technologies implemented in ways that impair users’ control over:

  • Material changes that affect their user experience, privacy, or system security
  • User of their system resources, including what programs are installed on their computers
  • Collection, use and distribution of their personal or otherwise sensitive information

These are items that users will want to be informed about, and which the user, with appropriate authority from the owner of the system, should be able to easily remove or disable.

What’s interesting about this definition is that it’s not exactly a definition – it’s a description of things that users won’t like, along with assertions about what users will want, and what users should be able to do. How is it that this impressive group could only manage an indirect, somewhat vague definition for spyware?

The answer is that spyware is a surprisingly slippery concept.

Consider a program that lurks on your computer, watching which websites you browse and showing you ads based on your browsing history. Such a program might be spyware. But if your gave your informed consent to the program’s installation and operation, then public policy shouldn’t interfere. (Note: informed consent means that the consequences of accepting the program are conveyed to you fully and accurately.) So behaviors like monitoring and ad targeting aren’t enough, by themselves, to make a program spyware.

Now consider the same program, which comes bundled with a useful program that you want for some other purpose. The two programs are offered only together, you have to agree to take them both in order to get either one, and there is no way to uninstall one without uninstalling the other too. You give your informed consent to the bundle. (Bundling can raise antitrust problems under certain conditions, but I’ll ignore that issue here.) The company offering you the useful program is selling it for a price that is paid not in dollars but in allowing the adware to run. That in itself is no reason for public policy to object.

What makes spyware objectionable is not the technology, but the fact that it is installed without informed consent. Spyware is not a particular technology. Instead, it is any technology that is delivered via particular business practices. Understanding this is the key to regulating spyware.

Sometimes the software is installed with no consent at all. Installing and running software on a user’s computer, without seeking consent or even telling the user, must be illegal under existing laws such as the Computer Fraud and Abuse Act. There is no need to change the law to deal with this kind of spyware.

Sometimes “consent” is obtained, but only by deceiving the user. What the user gets is not what he thinks he agreed to. For example, the user might be shown a false or strongly misleading description of what the software will do; or important facts, such as the impossibility of uninstalling a program, might be withheld from the user. Here the issue is deception. As I understand it, deceptive business practices are generally illegal. (If spyware practices are not illegal, we may need to expand the legal rules against business deception.) What we need from government is vigilant enforcement against companies that use deceptive business practices in the installation of their software.

That, I think, is about as far as the law should go in fighting spyware. We may get more anti-spyware laws anyway, as Congress tries to show that it is doing something about the problem. But when it comes to laws, more is not always better.

The good news is that we probably don’t need complicated new laws to fight spyware. The laws we have can do enough – or at least they can do as much as the law can hope to do.

(If you’re not running an antispyware tool on your computer, you should be. There are several good options. Spybot Search & Destroy is a good free spyware remover for Windows.)

Michigan Debuts Counterproductive Do-Not-Spam List for Kids

The state of Michigan has a new registry of kids’ email addresses in the state. Parents can put their kids’ addresses on the list. It’s illegal to send to addresses on the list any email solicitations for products that kids aren’t allowed to buy (alcohol, guns, gambling, vehicles, etc.). The site has been accepting registrations since July 1, and emailers must comply starting August 1.

This is a kids’ version of the Do-Not-Email list that the Federal Trade Commission considered last year. The FTC decided, wisely, not to proceed with its list. (Disclosure: I worked with the FTC as a consultant on this issue.) What bothered the FTC (and should have bothered Michigan) about this issue is the possibility that unscrupulous emailers will use the list as a source of addresses to target with spam. In the worst case, signing up for the list could make your spam problem worse, not better.

The Michigan system doesn’t just give the list to emailers – that would be a disaster – but instead provides a service that allows emailers to upload their mailing lists to a state-run server that sends the list back after removing any registered addresses. (Emailers who are sufficiently trusted by the state can apparently get a list of hashed addresses, allowing them to scrub their own lists.)

The problem is that an emailer can compare his initial list against the scrubbed version. Any address that is on the former but not the latter must be the address of a registered kid. By this trick the emailer can build a list of kids’ email addresses. The state may outlaw this, but it seems hard to stop it from happening, especially because the state appears to require emailers everywhere in the world to scrub their lists.

If I lived in Michigan, I wouldn’t register my kid’s address.

UPDATE (July 13): A commenter points out that the Michigan program imposes a charge of $0.007 per address on emailers. I missed this fact originally, and it changes the analysis significantly. See my later post for details.