This Friday night, from 5:00pm until late, Pumping Station: One is hosting a get-together at Howl at the Moon!

If you live in Chicago (or will just so happen to be passing through this weekend) and want to get to know the hackerspace community in town, this is a great opportunity! This party is open to everyone, and the first 100 people who show up between 5:00pm and 7:00pm get two $1 drinks. There will be other drink specials all night for everyone, so even if you can't come before 7:00, the party will be going on well into the night.

Howl at the Moon is at 30 W. Hubbard St., in downtown Chicago. If you have any questions about it, send me an email, and I'll let you know any more details that you need.

I hope you can come out!

Just because Twitter is ubiquitous doesn't mean that it should be applied to everything.

Case in point? Vantage Credit Union has introduced a new feature called tweetMyMoney. It is exactly what it sounds like: people can now send bank account management commands--and receive bank account information--through Twitter. People can check balances, transfer funds between accounts, check recent transactions, and check recent holds.

The first question on the tweetMyMoney FAQ supposedly touches on why the feature is secure. It reads:

Q. How is mobile banking using Twitter secure?
A. As always, your account security is our utmost priority. When you use tweetMyMoney to access your account information, keep in mind that the information provided DOES NOT include account numbers, passwords, PINs or any other secure information. Also, tweetMyMoney uses the application’s direct message feature so no one else sees the account information you request.

Really?

Sensitive information should simply not be transmitted via Twitter. There's always the risk of a DM fail: if you accidentally tweet @myvcu without using a direct message, you are in effect announcing to the entire internet that you are using tweetMyMoney, and that control of your Twitter account gives them at least some control over your bank account. Furthermore, your Twitter direct messages are not encrypted--so, if someone is watching the network, they can have your username, your login credentials, and the fact that you use this service, even if you sent a direct message. They can also see what the credit union is sending back to you--including your account balances, as well as the code that supposedly authenticates that the message is from Vantage and not from someone else. If they're sending the code to you unencrypted, you get no assurance that the code hasn't been stolen.

I'm sure I'm just scratching the surface here, and that there are even more security flaws in this that I have yet to think of. I hope other banks don't follow suit on this, and I hope Vantage jettisons this feature soon. Otherwise, there could be some serious issues on the horizon.

(hat tip to @nickhacks for telling me about tweetMyMoney.)

Sometimes, coding is serious business.

And, sometimes, coding is not serious business at all.

I've done a little bit of playing around with Twitter in the past. Last year, I wrote a simple twitter client bash script, so I could update my status from the command line. I've gotten some work done on a twitter bot that actually tries to fool people into thinking it is human. I haven't put it online yet, since I need to finish writing the content that implies that this bot is up to interesting things during different parts of different days.

However, this morning, Rob T Firefly gave me the idea to take that silly Kanye West internet meme and turn it into a Twitter bot. Right now it polls the public timeline every thirty seconds, and searches for tweets that say "thanks" or "thank you." If it finds any such tweets, it responds to the writer of the tweet and tells them that it is happy for them and will let them finish, but that whoever tweeted just before them in the public timeline had one of the best tweets of all time. I am also adding functionality that spits back a random Kanye West quote from a list if anyone @ replies to the bot.

The code is still a work in progress, but the latest version of it is up on my projects page. I'm quite pleased that it has been running on Twitter for about ten hours so far, and the account has not yet been deleted for being a spam bot.

This is the second part in a multi-part series about United States of America v. Comprehensive Drug Testing, Inc., __ F.3d __, No. 05-10067, 2009 WL 2605378 (9th Cir. Aug. 26, 2009).

2. Segregation and redaction must be either done by specialized personnel or an independent third party. If the segregation is to be done by government computer personnel, it must agree in the warrant application that the computer personnel will not disclose to the investigators any information other than which is the target of the warrant.

Although Kozinski's first suggestion, that plain view doctrine be waived in digital evidence cases, is the most legally groundbreaking of the suggestions in Comprehensive Drug Testing, this second suggestion he makes has the most practical ability to protect data privacy. In fact, this plank is the suggestion for how to implement the first: if plain view is waived in the case of digital evidence (or, in the case of my suggested overhaul of Kozinski's paradigm, if plain view is held to be generally inapplicable in the case of digital evidence), how is that waiver (or inapplicability) going to be honored in real life? In simpler terms, how will the court stop the case agent from seeing data, files, folders, and devices that are not actually covered by the warrant?

The government case agent only has a right to see the data that is specifically called for by the warrant. The difficult part is how to actually sift out what data is covered by the warrant, and what data is not covered by the warrant. Kozinski is on the right track to suggest that it must be segregated and redacted before it gets to the case agent--if the case agent is allowed to be present during the segregation and redaction, it is the digital equivalent of the case agent getting his hands on evidence that was not outlined in the warrant. This was exactly the problem in the Comprehensive Drug Testing case.

However, the interesting question is--who actually should get to do the segregation and redaction? Someone needs to do it, and this someone needs to be a human being or a group of human beings. It would be nice if a completely automated script could do the segregation and redaction so the data would not have to be seen by any human eyes, but there are so many crafty ways to obscure incriminating data (or, simply, unorthodox or cutting-edge ways to store data, incriminating or not...) that a human mind and human eyes are necessary to segregate the data in any meaningful and accurate manner. Also, even if that were possible, there would always be the question of whether the segregation and redaction code could be trusted. The vast majority of judges would not be able to do that assessment themselves, and would have to call in a computer forensics expert to check the trustworthiness and effectiveness of the code--exactly the situation that scripting the process would be trying to eliminate in the first place. Thus, it is inevitable in any digital evidence case, human computer forensics experts will have to be involved.

Kozinski suggests two possible parties who could do the forensic investigation necessary to segregate and redact the data: independent third-party forensic investigators, or specialized government computer forensics personnel. In the summary of the plank of his paradigm he implies that either is legitimate. However, elsewhere in the opinion, Kozinski's own statement leads one to believe that not even he sees them as equally protective of data privacy:

"In a case such as this one, where the party subject to the warrant is not suspected of any crime, and where the privacy interests of numerous other parties who are not under suspicion of criminal wrongdoing are implicated by the search, the presumption should be that the segregation of the data will be conducted by, or under the close supervision of, an independent third party selected by the court."

This suggestion is necessarily predicated on accepting two precepts:

1. Segregation and redaction by third parties will, on a whole, provide better privacy protection than segregation and redaction by government investigators.
2. Parties not suspected of any criminal wrongdoing are entitled to a higher level of data privacy protection than parties suspected of any criminal wrongdoing, whether or not the data is covered by a warrant.

The first precept, that third parties are more likely to insulate non-warranted data more strongly than government forensic investigators, is evident from his statement that third parties should take the lead when searching digital data owned by parties not suspected of a crime and concerning other parties who are not suspected of crimes. The comment implies that digital data searches on parties suspected of a crime, or even digital data on innocent third parties who (in the judge's estimation) are keeping data on fewer than "numerous other parties who are not under suspicion of criminal wrongdoing", may be led up by a government investigator, as long as the government investigator pledges not to tell the case agent about the non-warranted data he finds. Even though there are probably some (even many) government forensic investigators who will honestly segregate the data, redact the non-warranted portions, and keep all non-warranted data a secret from the government, there is a higher risk that at least some government investigators will reveal information to fellow government agents, either out of a loyalty to the government's goal to prosecute, or as an inadvertent slip during interactions at work with other government investigators. There will always be a conflict of interest, one that will not be there in the case of a third party who has been properly vetted to ensure lack of connections to the government's case agents or to any of the parties in the case. If Kozinski actually trusted the government agents not to reveal information as much as he trusted a disinterested, judicially-screened third party not to reveal information, there would be no need for him to differentiate.

Working from the first precept that third-party investigations provide better insulation of non-warranted data than government-led investigations, the second precept suggests that data residing on a computer owned by a party not under criminal investigation, and containing information about numerous parties who are also not under criminal suspicion, is entitled to a stronger data segregation and redaction procedure than other information. This provides a dangerously vague framework for which data gets enhanced protection from government case agents during an investigation, and which does not. What about the case of data owned by a third party not under investigation, but the case agent claims in an affidavit during the warrant proceedings that the computer he wants to seize only contains data about parties under criminal suspicion, or claims that it only contains small amounts of data about someone who is not being investigated? What about a computer owned by a party under criminal investigation, but containing large amounts of information about parties that are not under investigation, and even large amounts of data about activities by the suspect that have nothing to do with the investigation from which the warrant stems? If you are not under investigation, but information about you just so happens to be on a computer owned by a party under crimina investigation, too bad. If you are not under investigation, and your data is on a computer owned by someone who is not under investigation, but the government convinces a judge that you're one of a tiny minority of people whose data is on the computer who is not under suspicion, too bad as well. Under the conjunctive test suggested in Kozinski's comment, it would still be permissible for the government to take the lead in the segregation and redaction of the data--thus leaving room for a lower threshold of data privacy than if a third party were to segregate and redact the data.

This is a weak framework for making important decisions about the level of protection granted to someone's data during a government investigation. Given the lack of applicability of the plain view doctrine in cases of digital evidence searches, the framework should be tied rigidly to the data covered in the warrant: if the data is covered in the warrant, the government should see it. If the data is not covered in the warrant, the government should not see it. Since it is impossible to determine whose information is going to be on any computer until a computer forensics expert looks at it, whose computer it is and whose data may or may not be on it should play no role in selecting who does the segregation and redaction of data. Just as with the first plank, Kozinski is going in a better direction than before in requiring that the case agent should not be involved in segregating and redacting digital evidence. However, his suggestion does not go far enough, since it allows it to be done by either a government forensics expert or a judicially appointed third party. No matter whose digital evidence has been seized, the segregation and redaction should always be done by a third party who has been thoroughly vetted by the judge to to assure competency as well as a lack of conflict of interest, with respect to either the government or any of the other parties to the case.

This morning, Andrew Hay borrowed a page from the Facebook playbook, posted five facts about himself in his security blog, and tagged a handful of people to play along. One of them, Erin Jacobs, tagged me. Although I am going to adhere to my longstanding policy of not tagging anyone else to do a meme that I have chosen to do, I do think it's a fun way for you to get to know me a little better, especially since my site is so new and since I am so new to the community. As Erin so wisely did, I am going to try and keep the facts at least slightly professional, so it can remain responsive and interesting to this site's intended audience.

Without further ado, here are five things you may not know about me:

1. I can't shake the idea that I would be even geekier than I already am if my family had owned a computer with a command line interface when I was a girl. Instead, my family's first computer was a Macintosh 512 that it got when I was three years old, and its second was a Macintosh Classic it got when I was ten or eleven.
2. When I first got into computer programming, in middle school, the only computers my family had were those Macs. We didn't have any kind of BASIC interpreter for them. So, my programming process involved writing my BASIC code on notebook paper, typing it into the school computers if I had the chance to do so, and translating all of my code to the Texas Instruments graphing calculator language so I could run my code on my calculators away from school.
3. It always made me sad that I did not have a Commodore computer when I was younger. I finally fulfilled that dream earlier this year when a fellow member of Pumping Station: One gave me a Commodore 128 earlier this year. I am especially proud of the musical suite I composed on it for PS:One's Geek Prom in June of this year, and I plan to post the code from that project on this site as soon as I once again have a functioning cassette drive which I can use to access the code.
4. I have an almost obsessive desire to know how things work at the deepest possible level. I started teaching myself Python last year. It's great for rapid prototyping, but many of the calls felt way too much like black boxes to me. As such, I decided that the only logical response would be to teach myself C. I find C more satisfying still, but I still can't shake the idea that there are still things under the hood that I can understand better. I know that the next step in this trajectory will involve learning assembly language, although I know myself too well to call this the "end" of this trajectory.
5. Doing this meme is reminding me of a comment that Tom Eston made in one of his talks (the one at Notacon, if I remember correctly): that the 25 Things meme on Facebook was a clever way for malicious people to suss out the answers to your password questions on social networking sites. As such, I have been extra-vigilant in writing these in order to make sure that these answers do not touch upon my internet security questions.

Hopefully some of this gives you all a better idea of how I tick.

Recently, the Ninth Circuit handed down its decision in United States of America v. Comprehensive Drug Testing, Inc., __ F.3d __, No. 05-10067, 2009 WL 2605378 (9th Cir. Aug. 26, 2009). The decision has come under fire from some angles for being light on precedent and heavy on new rules for investigative agencies to follow when searching computers. However, that should not be regarded as a weakness of the decision, but rather a strength. Outlining a new paradigm was the only logical route that the Court could have taken, since the measures necessary to protect the unreasonable search and seizure of data saved on a computer are so different from the measures necessary to protect evidence saved on paper or physically sitting in a room.

Judge Kozinski's new paradigm consists of five instructions for carrying out digital search warrants, which I will address one by one in separate entries. This is the first of the series.

1. Magistrates should insist that the government waive reliance upon the plain view doctrine in digital evidence cases.

I see what the majority is trying to do here, but they approached this point incorrectly. Plain view refers to the doctrine that allows an investigator to use all of his senses when doing a search for material outlined in a warrant. For example, if police are lawfully searching a house for a murder weapon, and there's a stash of crack sitting on the table next to the gun described in the warrant, it was in plain view. The investigators can seize that crack under the plain view doctrine.

The elements of plain view were laid out by the Supreme Court in Horton v. California, 496 U.S. 128, 136-137 (1990). The three things that must be the case for a find to fall under the plain view doctrine include:

1. that the officer is lawfully present at the place where the evidence can be plainly viewed
2. that the officer must have a lawful right of access to the object
3. the incriminating character of the object must be “immediately apparent.”

As Professor Orin Kerr explained in his article Search Warrants in an Era of Digital Evidence, it makes sense to describe the search and seizure of digital data in two phases: the physical phase, and the electronic phase. Orin S. Kerr, Search Warrants in an Era of Digital Evidence, 75 Mississippi Law Journal 85 (Fall 2005) First the government needs to access the hardware with the warranted information on it, and then it needs to actually find the data described on the warrant where it is saved on that hardware.

TheHorton test was designed for the seizure of physical evidence. It makes sense to describe the physical seizure of hardware in plain view in terms of the test, just as it makes sense to describe the seizure of a paper, a weapon, a box, or a bottle of drugs in terms of the test. It's just another physical object.

But, this test breaks down once the agent is inside the seized computer, and rooting through for the data. The first two prongs talk about lawful presence and lawful right of access to the object. What is "presence" with respect to a file--how close do you have to be? On the same piece of hardware? The same directory? The same spreadsheet file? And, lawfully seizing a computer does not imply that the officer has a lawful right of access to any file about anyone--that would be tantamount to saying that in the paper world, an officer has a lawful right to access anything in a data warehouse because the warehouse contains a couple of papers relevant to a suspect's criminal activities.

The test also prescribes that something must have an incriminating character that is "immediately apparent." What is "immediately apparent" in a computer? Is it immediately apparent if the incriminating nature of the file data is reflected in the file name? The directory name? The fact that it's on the same computer with other incriminating data? Is it immediately apparent if it needs only common as opposed to highly customized computer forensics tools in order to find the data? It is hard to tell.

The test breaks down in the arena of digital seizure. Even though Judge Kozinski did not discuss it in such explicit terms of the Horton test, he did write:

"If the government can't be sure whether data may be concealed, compressed, erased, or booby-trapped without carefully examining the contents of every file--and we have no cavil with this general proposition--then everything the government chooses to seize will, under this theory, automatically come into plain view. Since the government agents ultimately decide how much to actually take, this will create a powerful incentive for them to seize more rather than less."

This excerpt presents the fundamental tension: how easy it is to conceal digital data at first glance versus the searching that needs to happen to verify which data on a computer is or is not covered by the bounds of the warrant. No reasonable digital search and seizure ruleset would stop at forcing investigators to take what they saw on the computer at face value, without allowing detailed forensic analysis to ferret out which data is usable in the case at hand. However, reliably determining which data can be used in the investigation requires a detailed investigation not contemplated by plain view jurisprudence.

The majority has at least started to realise that plain view is a poor paradigm for digital searches, and has tried to patch the issue by suggesting that the government waive the doctrine of plain view in digital evidence cases. Such a suggestion is naive. Plain view is a powerful doctrine for investigators, and the government is not likely to consent to waiving it without a fight, and without a lot of technical argument as to when the plain view doctrine does or does not apply in any given case. It would help neither the government's interest in investigation nor the citizen's interest in protection from unreasonable search and seizure to get mired in bickering over the bounds to which plain view applies in every single case involving computers.

Instead, when and if the Supreme Court reviews this case, the Court should go one step further and frame this case in terms of defining the bounds of the plain view doctrine as a whole. It should remove that extra level of discretion, and hold that the plain view doctrine does not apply to electronic searches for digital evidence, period, end of discussion, since it is basically impossible to apply the Horton test in any meaningful manner to digital evidence. This will avoid any questions about whether it has been waived properly, and such a blanket rule is the only way to prevent government investigators from rooting through data, files, directories, and computers in which they don't have specific warrant authorization to be.

This morning, Farhad Manjoo's column in Slate Magazine argued that corporate computers should be "unchained": that workers should be allowed to run any chat programs they wanted on there, and be allowed to use any kind of software, because it will allow them to choose the suite that will make them most productive.

Manjoo's argument is naive, and it ignores the realities of corporate IT. He gives the average end user far too much credit. He assumes that people are only playing on the internet to clear their heads for a few minutes before getting back to work, and only using websites and tools that increase productivity and are not infected with malware. There are some end users who are diligent, and will follow this ideal. However, there are many who will not. And, there are some end users who think they are being diligent, but are sufficiently unfamiliar with internet threats that they think they are downloading legitimate software for work, but are instead introducing malware onto their computers. In the balance, allowing anything and everything to load or run on a corporate computer will be far more likely to burden the network with malicious software than cause the renaissance of productivity that Manjoo envisions.

However, even though Manjoo's proposed solution is overbroad, he does raise a good point that IT staffs should take to heart. Sometimes, there is more than one legitimate option for getting a job done. It does get frustrating, as an employee, to be unable to use battle-tested, job-relevant software because IT has not installed it on the company's systems. (Having previously worked as an attorney in a large law firm, I know this all too well.) Allowing employees to install whatever they want whenever they want is not the answer. Instead, this should be a call to IT departments everywhere to take the time to assess the software available to employees, stay in touch with employees relative to their software needs, and continue to explore options frequently cited by employees as ones that would improve their productivity at work. It is folly to allow untested software on a corporate network. On the other hand, if members of the IT department consistently tested and evaluated software frequently requested by employees, and implemented the options that proved themselves sufficiently secure, realistic to administer, and productivity-enhancing, then there is hope for enhanced employee productivity and strong network security to coexist.

(Hat tip to Ben Tomhave for turning my attention to this article.)

Welcome to rogueclown.net!

This page is a home for my projects. It will contain any interesting discoveries, finds, or musings I come across as I explore the worlds of computer networking, administration, and security. It will also contain updates on things I'm making and doing at Pumping Station: One, the hackerspace to which I belong.

Thank you for reading. If you have any suggestions for content, or questions for me,I'd love to hear from you!