 Hello everyone. Hi. My name is Karim McSherry and I'm an attorney with the Electronic Frontier Foundation. The original plan for this panel was we were going to start out by, we're going to do an ASCII FF panel, and we were going to start out actually by talking a little bit about what we've been doing over the past year, you know, what our major concerns are. But it turns out that we're going to need to change things up a little bit. And actually what we're going to do is talk a little bit about what we've been doing for the past 24 hours, which has been part of what we do all the time, but in a very short time frame. So for those of you who aren't aware, what we're going to do for the next, well however long it takes, but for the first part of our talk is actually have a press conference to talk to you about an event that's happened over the past 24 hours here at DEF CON that we've been involved in and these fine young men have been involved in. So I announce that now because if anyone doesn't want to hear about it, if you're not in the press or you have other things you'd rather be doing with your time, take a few minutes to leave because we're actually going to need a few minutes more from you because we're having a little bit of technical difficulty over here. So we'll be right with you in a second and I think it will be worth waiting for. Thanks. Oh, nice to meet you. So for the second hour of our panel, I have a PDF file. Can I have a working projector? Yeah. So for the second hour of our... So in an hour this time, I'm going to have a PDF file for a talk on a public website. Okay, so I think we worked out our technical difficulties. I'm going to hand over the mic in a second to my colleague Kurt Offsall. I just want to say one more thing about what we're planning to do today. We actually do have a few things that we really did want to, you know, talk to you about today and make sure that we had a good full chance to do a good back and forth other than the issue that we're about to discuss right now. So after this press conference, a couple of my colleagues here are going to come up and talk about some important other recent work that EFF's been doing and we will still do the Ask the EFF discussion in the breakout room after this two-hour session. So just to kind of have a general idea of what we have in mind, we'll see how it goes. And now I'm going to shut up and hand over the podium to Kurt Offsall. Thank you. Thank you very much. So yeah, you have three hours of us coming forward. Two in here, one in the Q&A room. So hopefully that will be enough to answer all your questions. But we wanted to start the session today with something that has happened over the last 24 hours. And I'm going to start out by reading our press release that we just gave out. So here it goes. MIT students gagged by federal court judge. EFF backs researchers forced to cancel presentation on transit fare payment system. Three students at the Massachusetts Institute of Technology were ordered this morning by a federal court judge to cancel their scheduled presentation about vulnerabilities in Boston's transit fare payment system violating their First Amendment rights to discuss their important research. EFF represents Zach Anderson, RJ Ryan and Alessandro Caiza who were sent to present their findings Sunday at DEF CON here. However, the Massachusetts Bay Transit Authority sued the students in MIT in the United States District Court in Massachusetts on Friday claiming the students violated the Computer Fraud and Abuse Act by delivering the information to conference attendees that could be used to defraud the MBTA of transit fares. This morning district judge Douglas P. Woodlock, meeting a special Saturday session, ordered the trio not to disclose for 10 days any information that could be used by others to get free subway rides. Quote, we wanted to share our academic work with the security community and had planned to withhold a key detail of our results so that a malicious attacker could not use our research for fraudulent purposes, said Anderson. Quote, we're disappointed that the court is preventing us from presenting our findings even with a safeguard. End quote. Phone abilities and magnetic stripe and RFID card payment systems implemented by many urban transit systems are generally known. The student research applied this information to the specific case of Boston's Charlie Card and Charlie Ticket and the project earned in A from renowned computer scientist and MIT professor, Dr. Ron Rivest. The court relied on a federal law aimed at computer intrusions by initiating its order, holding that even discussing the flaw at a public conference constituted a transmission of information that could harm the fare collection system. Quote, this court's order is an illegal prior restraint on legitimate academic research in violation of the First Amendment, said EFF civil liberties director Jennifer Granick. The court adopted an interpretation of the statute that is blatantly unconstitutional, equating discussion in a public forum with computer intrusion. Security and the public interest benefit immensely from the free flow of information of ideas and information on vulgar melodies. More importantly, squelching research and scientific discussions won't stop the attackers. It will just stop the public from knowing that these systems are vulnerable and from pressuring the companies that develop and implement them to fix security holes. End quote. This case is part of the EFF's Coder Rights Project, which was launched this week to protect programmers and developers from legal threats hampering their cutting-edge research. EFF will seek relief for the researchers in the courts. So that's our press release. And now I'm going to read from the court's temporary restraining order. Skip some of the introductory materials. They define some terms, but I think you'll get the idea, is the MIT undergrads are hereby enjoined and restrained in accordance with federal rule of civil procedure 65B2 from providing program information, software code, or command that would assist another in any material way to circumvent or otherwise attack the security of the fair media system. And that order was entered at 1.30 p.m. in Massachusetts. So that's some of the brief summary. And let me give more of a longer form sense of the story that happened here. The first notice that the MBTA provided that they were going to the court was after they had gone to the court and had gone yesterday afternoon, late Friday, East Coast time, and did not provide notice until they had already sent their lawyers with papers to the court to file their complaint, to file their motion for a temporary restraining order. Nevertheless, the court did not grant the temporary restraining order that day, but instead ordered a hearing first thing this morning. 11 a.m. East Coast time, 7 a.m. local time. So we got involved. We agreed to represent the MIT students as part of our Code of Rights project and part of our dedication to defending free speech and the ability to be able to talk freely about security vulnerabilities and enhance the security of computer systems and being able to talk about the issues that are raised. We worked all night trying to prepare for the hearing. It is a very, very short notice, but we prepared we could. A big thanks to DEF CON, who was extraordinarily helpful in making that possible by giving us secure connections to work in use of some printers. There were people who were helpful to us all night long sacrificing some of their evenings when there were plenty of parties to go to and things to do on a Friday night at DEF CON. And so we really appreciate that. And it's been great working with these guys. They were also with us every step of the way, working hard to help us understand what was going on, explain their stories, and it was really great working with you guys. Nevertheless, the hearing was held this morning at approximately 11. Actually, at 11 the Court said that it wanted to take a few moments to read the papers, so it didn't get started a little bit later. Then we had the hearing. We made our arguments. The other side made their arguments. And the Court ultimately came to a very, very wrong conclusion. I just want to sort of emphasize one aspect of the wrongness of the conclusion. This was about the Computer Fraud and Abuse Act, which those of you who are here at the EFF panel, you may be following this issue and know that that is a computer intrusion statute. And what the relevant portion of the statute speaks of is causing the transmission of a program information code or command to a protected computer. So the statute on its face appears to be discussing sending code, programs, or similar types of information to a computer and does not appear to contemplate somebody who is giving a talk to humans. Nevertheless, the Court disagreed with that interpretation and believed that the act of giving a presentation to a group of humans was covered by the Computer Fraud, Computer Intrusion statute. We believe this is wrong. There were some other issues in the case, but I think some people might find interesting. If you read the complaint, it suggests that a magnetic stripe card is a computer for purposes of the Computer Fraud and Abuse Act. There are many problems with such an interpretation. So we are very disappointed in this temporary restraining order. For those of you who are a little unfamiliar with how that aspect of the legal system works, when you go to a court to obtain an order telling somebody not to do something and you need it in short order, the vehicle is a temporary restraining order. And those are very short-term orders and are usually replaced or not replaced if they were improvidently granted by a preliminary injunction and then a long time later after trial you might consider an injunction. So this temporary restraining order and it reflects the Court's view that they believe that the Massachusetts Bay Transportation Authority was likely to succeed on the merits. We've just discussed, we think that's actually not the case. Unfortunately, however, this order, which I just read to you, creates a very, very difficult situation when the Court is considering such a broad definition of information as prohibiting the providing information that could assist another in any material way to circumvent or otherwise attack. That is a very, very difficult definition to deal with and it makes it impossible to go on with the talk. So unfortunately, as a result of this order, the talk scheduled for, otherwise scheduled for one o'clock tomorrow will not be able to go on. We are anticipating appealing this decision and look forward to having the rights vindicated but in the meantime, we're very disappointed. Alright, thank you. So we can take some questions. We ask that if people want to ask questions, they go to the microphone. What bearing affinity does this TRO have on the presentation materials that have been distributed with the DEF CON CD? As a result of this TRO, we will not be able to discuss the substance of those materials. Hi. I'm with MIT Student Newspaper of the Tech. Just a quick question. Was the talk that was going to be given going to contain any new material, orally, that was not already available in writing? Much of the material that was planned to be presented is material that's known, there are known flaws to the Massachusetts Transportation Authority's security system. And some of that has been covered in the Boston Globe, in the Boston Herald, and much work has been done on this in other forums. So it was never the intention of the students to provide sufficient information so someone could break into the system and defraud the Transportation Authority. That's our answer for now. I'm just curious because of the timing of this situation that the TRO is as effective as almost a permanent injunction until next DEF CON. So if we go back in court, or you go back in court and thank you for your work, and you win, maybe you could convince them that the remedy would be for the Massachusetts Bay Transportation to pay for next year's DEF CON for all attendees since this year we got ripped off. Thank you for an excellent suggestion. I'm wondering if the Transportation Authority gave any legitimate excuses for why they waited until now to file. Obviously seems very slimy to do that when you have very little chance to defend yourself. Your presentation was up there two months ago, so it's not like this should be new to them. Thank you for making that point. Is there anything to stop someone familiar with these techniques from, say, coming up with a last-minute presentation using materials on the CD? Well, we cannot discuss the substance in the CD. It certainly could not give any information, program, code, or what have you that could enable somebody to do anything to the transit fare system. I'm wondering if you can just answer some questions that I have about the claim that there is never any intention to enable other people to hack the T-card system. Specifically, some of the slides suggest, you know, showing how to hack into the system, and, of course, an earlier presentation or, you know, kind of teaser for this thing specifically said, you know, want free subway rides for life. You're saying that you never had any intention, but that doesn't seem to square with some of the written materials that have been released about this. Can you kind of address that a little bit, please? Yeah, at the end of the day, there was not an intention to provide sufficient details in order to enable somebody to walk out of that presentation and be able to do the tack. Some key details will be held back so that it was not a sort of a stand-alone material. I can't discuss the substance of the slides, but just please understand that, you know, rhetoric aside that the attention was to provide an interesting and useful talk but not one that would enable people to defraud the Massachusetts Bay Transitor Survey. You said that you had no indication until Friday afternoon that the T was planning to file this injunction, right? The first notice received about the complaint and motion for restraining order was provided Friday afternoon. Okay, so my understanding is that the students and Dr. Rivest and the MBTA and MIT lawyers all met on August 5th and discussed something at which meeting the students assured the MBTA that they didn't mean to cause them any harm, but what did happen at that meeting? Did they show them the vulnerability? Did they show them the code? Oh, I'm sorry. I'll speak into the microphone. So there was a meeting held on Monday and the students came out of that meeting understanding that a situation had been resolved and an understanding had come to and a situation had been resolved and that appears to have turned out not to be the case. So on Monday the T said we're not going to sue you and on Friday an injunction appeared? Well, it was certainly the understanding coming out of the Monday meeting that the situation had been resolved. That it wasn't that they made an affirmative promise not to sue, but rather that they seemed to have their concerns satisfied and that it seemed like a friendly meeting and that when you leave meetings with people you don't ordinarily say, oh, by the way, I'm not going to sue you. But you still often will leave a meeting with the understanding that the other people aren't going to sue you. I'm looking for a silver lining here, the RFID devices. Should this come to trial? Would that definitely decide whether a RFID actually constitutes a computer or not? Well, so in addition to asserting that the mag stripe was a computer for purposes of the Computer Fraud Abuse Act, they also asserted that the RFID-based fair system was also a computer and then that the fair system as a whole was a computer. So that is an issue. I don't know if it went forward whether that would end up being a critical issue that would get decided by a court. When were the open source tools taken offline? The open source tools, I think you're referring to the website? Yes. The website never had the tools. No tools were put up pending the resolution of the situation with the transit authority. That situation ultimately did not get resolved until a court order and so no tools were ever up on that location. Without going into the details, were those tools also applicable to the Dutch transportation system? I don't know about that. Do they know? I don't think we can really discuss the tools by, you know... Let me rephrase it. Could you do a similar talk about a similar subject on the Dutch transportation system? All I'll say is that the TRO is specific to the Massachusetts Fair Transit System. Thank you. Yeah, Dean Takashi at Venture Beat. A couple of questions. So is First Amendment event part of your defense here? Absolutely. There's a First Amendment right in code. There's a First Amendment right in instructional speech. Courts have found that the First Amendment covers these things outside of traditional speech like political speech. And so we believe that this is a protected speech activity. This is telling... When you discuss security issues, if you are telling the truth, that should be something which is protected at the core of First Amendment. If you are truthfully telling the world about a dangerous situation, and a situation which is dangerous, not because the security researcher exposes the vulnerability, it's dangerous because the person who made the product, the company that made the product, made the vulnerability. And so this should be core speech. And then the second question is, I understand that there are people who have the CDs, who are in the process of posting the paper on the Internet. And does the order cover these people who are doing this? And what's the consequence for those people? Let me just read from the order. It says that the MIT undergrads are hereby enjoined. And I'm going to read the definition. The term MIT undergrads means the defendants, and it names these three gentlemen, and all persons in active concert or participation with any of them. Thanks. So my question is, we've seen obviously some problems in Holland and also in the U.K. regarding transit systems. These are all based on the same flawed technology. Do you expect to see similar responses from other U.S.-based, MiFair technology that's used here in the U.S.? So the MiFair technology has been implemented in cities all over the place. And some excellent work from security researchers have exposed issues with the MiFair technology. This has come to a head in the Netherlands where there was a lawsuit to try and squelch some security vulnerability exposure on a version of MiFair. The Dutch court ultimately did not squelch that speech, and the Dutch court agreed that the responsibility for the security vulnerability lay with the company and not the people announcing the exploit. There have been problems identified with other transit systems all over, and hopefully this is a time for that industry, instead of spending as much time trying to stop people from talking about the security of their system to spend a little bit more time improving the security of their system. I was wondering if you can't talk about the stuff that's in your paper or whatever. Are you allowed to talk about the court filings filed by the MBTA that described specific attacks against their own system? I think that the docket speaks for itself, and I am not going to comment on that. I'm Victor with Data Security Podcast. Are there other cases cited by the judge or the plaintiffs where the Computer Fraud and Abuse Act was used in a way similar to this case? No. Not one. The order itself has no citation. There wasn't much discussion of court cases during the argument. The argument was recorded on audio. I hope the court makes that audio available, and certainly we would have no objection if somebody tried to get a copy of that audio if the court was willing to release it. And a follow-up, do you know approximately how many other cities are using this similar technology in the United States? I don't know that number offhand, but one of the students maybe know, and would they be allowed to comment on that question? I would say look at the slides. Okay. I'm trying to understand why the judge issued this temporary restraining order. If you read the argument, or sorry, if you read the injunction he actually filed, he says two things. First of all, he says, for the sake of the security of the computer system, I hereby provide this injunction. And second of all, he says, I've given most of my explanations for this orally. Could you explain exactly what he said at that hearing because we don't have it in paper? So this is one of the reasons why I think that it is important to be able to see or hear the recorded hearing, especially the part in which the judge gave his order. One of the core values of our judicial system is the openness of the judicial system. Hearings are presumed to be open, and the reason for it is so people can understand what a judge is doing. It's a check against error to allow or require that these hearings be held in the open. People can evaluate what the judge said. So hopefully that recording can be made available. We had to participate telephonically. It was a long way to Boston, and we didn't have a jet handy. So that was a limiting factor in being able to participate. But nevertheless, we were able to participate, and that was great. And it seemed that the court had some interesting interpretations of the Computer Fraud and Abuse Act. It felt that the transit authority was likely to succeed on the merits, that the harm to the authority would be high, while the harm to putting a prior restraint on the speech of security researchers was not that high, that the balance of interest favored giving the injunction. So those were some of the reasons that were discussed. Kim said over the fire of the news. In the meeting that the three students had a week ago with the transit authorities, there was an FBI agent present. I'm wondering if you can tell me if you're aware of whether or not there's an ongoing FBI investigation? It's my understanding that they are not the subjects of an FBI investigation. If this is a temporary restraining order and it expires, say, next Tuesday, is there anything preventing the students from publishing their materials on next Wednesday? Well, the next step with a temporary restraining order is to determine whether or not it turns into a preliminary injunction. And so it's not... that will require another hearing, another argument, another chance to raise the arguments that are, you know, we believe to be meritorious, but it will not just expire without an opportunity for the transit authority to reassert its arguments. Thank you. Hi. Hi. You stated that the audio recording of the court hearing would be very beneficial to be posted publicly. Will you, the EFF, be attempting to obtain it and publish it yourselves? We may. We have not looked into that, but certainly we have no objection to the members of the public and the press trying to get all that in furtherance of their rights to understand how the court system works. Okay. Is there anything keeping... so you would support someone else and you'll look into doing it yourself? Yeah. Sure. Okay. To understand how to get around... or not get around, but to avoid this in future DEF CONs, if some of us are security researchers and we have something that might be controversial, were the students served at the last second? Or, I mean, I noticed their lawyers went in at the last, you know, minute and made it so that there really isn't any chance for any appeals or anything. If, I mean, can you hide right before DEF CON before you do this or what? Well, as a general rule, trying to get around the legal system by hiding from service is not the best way forward. You know, I think that the system didn't work here, but generally the system is useful, that courts actually are a place where more often than not, a lot more often than not, you can go and present your legal arguments, you can talk reasonably to a judge and you can get a good result. And so we try and work within the court system and try and shape the law, make the law a better place so that in the future, people don't have to hide from it. So if it's a system where the law is bad and you're hiding from it, that is a much worse system than where the law is good and you don't have to hide from it. Another specific question on that would be, okay, so if you didn't, if you discovered a vulnerability in XYZ in company ABC, if you leave out the company, so I understand that when you want to present things here for credibility, you have to give enough evidence that, yeah, this is real, but nobody wants to give everything away to the CD and everybody can go do it. So there's that nice line, but if you leave out specifics, would that make it safer in the future for researchers trying to present here? One thing I would recommend to people in the future if you are facing a situation, we have announced the Coders Rights Project a couple of days ago. This is something that we are dedicated to. EFF has long been a friend of the security research community, but this project is designed to enhance that, and so contact us, contact us as early as possible so that we can help either walk you through these issues ourselves or help you find some counsel that will so that the situation that you individually are facing can be addressed in the best possible way. So will subsequent hearings be before the same judge? No, this was assigned to a different judge, but because it was a weekend and it was assigned to this judge, Douglas Woogalock. Was the transit authority aware of the vulnerabilities in their system prior to the August 5th meeting? And if so, could you give a timeline of the disclosure of the vulnerability to them? I think I have no comment on that. I have a second question and kind of a follow-up. Is there any evidence that the transit authority is taking any action against the manufacture of the product to actually get the vulnerability fixed as opposed to just suppressing the research? Well, one thing along those lines that is interesting is in the complaint it says that it was a vendor who brought it to the attention of the transit authority. It does not name the vendor, but I think that the vendor should definitely spend their time trying to fix security vulnerabilities and focus on that and focus less on trying to convince security researchers not to look at their products and talk about flaws. Thank you. First, thank you to the EFF for your efforts in this. You're quite welcome. In the future, would it be possible to preempt a temporary restraining order by filing with the court to establish the author's right? There is a feature in law called the declaratory judgment. So when you have a dispute with somebody where it is a concrete enough dispute that it is possible to then go to a court before you do something according to declare the thing that you are about to do is legal or you could find out that it was illegal, but you don't have to wait until you've done it, you're potentially liable. But the situation has to be concrete enough to have it. So it's going to depend really on the situation. If it's an idle question, probably not, but if you are in a dispute with a company about whether something is really civil and you may have the ability to get a declaratory judgment under certain circumstances. Hi, I was wondering to what extent you're also working with co-defendants MIT President Susan Hockfield and MIT Chancellor Phil Clay. It's my understanding that even though several of those people were named on the motion papers they were not actually named in the complaint. So I'm not sure why their names are on the motion papers, but in terms of who the defendants listed in the complaint it is in addition to the undergraduate students, MIT the institute was named they had a separate council who represented them at the hearing. We certainly were in conversations with MIT's council throughout this process and I think they were adequately represented. Since you won't allow your defendants to talk what's the EFS view on disclosure? I know that the MBTA thought they weren't given appropriate disclosure on this. From the EFS point of view what sort of disclosure do you think is necessary? Well it's going to depend on the circumstances of a particular situation but certainly as a general rule it is advisable to contact the people whose security is at issue who have the vulnerability and do that prior to the disclosure and ideally it would be something where that disclosure or the vulnerability, something they could work on fixing and I can say that efforts were made here to be in communication prior to this lawsuit. Hi, you mentioned in your press statement that the Charlie ticket, which is essentially a magnetic storage medium the court found was actually a computer. To be clear that was not in the court's order the court didn't find that that is something that the transit authority has contended in its complaint. The court's order was about their fare system as a whole. I can read the defined term was the the fare media system means the plaintiff system that meets the following two criteria the system one is employed by the MBTA to manage track charge for and collect fares and two relies on the Charlie ticket passes and or Charlie card passes. I was wondering though if this were to become a permanent court precedent what implications that would have for security researchers in the future? Well, I think that this case is a long way away from a ruling that RFIDs are computers under the computer fraud and abuse act but certainly whether something is a protected computer pursuant to that act is something that is very important to the security research community because you certainly do not want to be on the wrong side of the computer fraud of abuse act if you can help it. Thank you. At the end of MIT's spring semester about half of this attack was presented as a final project in a class taught by Professor Ron Rivest who invented RSA encryption along with S&A. Half of this attack discussed the Charlie ticket attack and explained how you could actually put arbitrary amounts of money on to a Charlie ticket. But this was presented at the end of MIT's spring semester months ago and the MBTA's complaint says they only found out about the attack on July 30th when a vendor told them are they lying or did they really not figure this out for months and months? That would be an excellent question to ask the MBTA. So for instance these folks didn't tell them? So I think that if you want to know what the MBTA was thinking it's a good question to ask them as to anything which hits upon the information program codes or computer things that might somehow be able to lead to somebody messing with the transit fare system we can't touch that. Thank you. Any words? All right. Thank you very much. That concludes this portion of tonight's program. One thing that very nice DEFCON folks asked me to add is that they are working right now on a fun way to fill that now empty slot. So they'll keep you posted. I think there's one thing we'd like to say. We'd like to thank the EFF for all of their efforts really for helping us. I don't know what we would have done in these last 24 hours. We had a team of people helping us out working all night long for us and it's really been great. So thank you. Our pleasure. And thank you all out here for your support of EFF which enables us to do this and we love being here in this community. So thanks a lot to all of you as well. What I meant to say is if you approve of the work that we're doing we only exist because we have a large membership that donates each year and pays our salaries so that we can stay up all night at DEFCON helping people out. So there's a booth over in the exhibition hall. If you haven't already joined the EFF we encourage everyone to consider doing so. There's also a table at EFF. Yes. There's also a table at Hackers with Guns where you can shoot at things and donate money to the EFF. Okay, so now we're just going to pause for just a couple minutes and switch gears a little bit and start on some of the stuff we were originally planning to talk about. All right, let's get started again. Thanks for sticking around. We do have some other stuff to talk about with you guys about and tell you about and take your questions on. We'll also, of course, afterwards do the ASCII EFF kind of Q&A at, I think, 3 o'clock but we'll be in another room for that. So for right now I want to introduce my colleague Peter Eckersley. He's our staff technologist and he's going to talk to you a little bit about one of the other things we were doing in the last year which is keeping an eye on Comcast and lots of people have been keeping an eye on Comcast I'm sure many people in this audience have been keeping an eye on them because they were caught out engaging in some unfortunate activity throttling BitTorrent streams and they were caught out doing it and just recently the FCC issued an order calling them and we have a few concerns about that order with not so much what the FCC is trying to accomplish but whether the FCC has regulatory authority to accomplish it and we can talk about that a little bit more in the ASCII EFF panel, the nature of our concerns but one of the things that we think either way is the best way to hold ISPs accountable if they're interfering with network traffic is to vote with your feet meaning you got to hold them accountable and if you don't like what your ISP is doing you go somewhere else but of course how are you going to do that you need the tools you need to know what they're doing and as we learned from the Comcast situation which Peter will talk about a little bit more they don't always give you full disclosure so we come up with some tools to work around that and Peter is going to talk about them, thanks alright thanks Karin can everyone hear me clearly if I'm talking here put up your hands if you can't hear me okay I guess I'll just lean over and talk like this so EFF is primarily a legal organisation we have a large team of attorneys and we do policy work but there are also a couple of us computer scientists on staff at EFF and sometimes we end up doing pure tech projects like the one that I'm about to talk about so we see our role as combining all of these different skill sets and activities so Switzerland is the piece of software I'm going to talk about today it's a sort of peer to peer system based on a client and a whole bunch of clients talking to a single server and it's designed to test ISPs networks and firewalls to detect modifications or interference that they might introduce into communications between clients on the internet and so this talk is going to cover why we got into writing this piece of software what kind of testing facilities it offers and some technical details about how it works the background is that during 2007 some rumours started circulating that weird things were occurring on the network operated by Comcast which is the United States second largest consumer broadband ISP and EFF ran some tests with a guy named Rob Topolski who was one of the first people who conjectured specifically that Comcast was injecting forged reset packets into certain kinds of traffic we ran some tests with Rob Topolski that gave controlled evidence the first controlled evidence that indeed Comcast was definitely responsible for the forged reset packets that we were seeing on their network I'm going to take this out so we ran those tests with BitTorrent and Nutella and we ran them by hand using Wireshark to get a capture of some packets being sent over here some packets being received over there well hey there are some reset packets being received that were never sent by the person you were talking to hey that's a sign of interference but running those kinds of tests manually just using packet sniffers and talking over a phone to coordinate them turns out to be incredibly labor intensive and you need to make sure that you're both turning on your packet sniffers at the right time capturing the same period of traffic and then ensuring that there is some BitTorrent or some Nutella or some other protocol that you're trying to test being exchanged between the two clients while the sniffers are running and so this whole process this whole methodology takes a long time to run and we thought well hey we would really love to have better tools to run these kinds of tests and they didn't exist so we set out to write some but first what we were saying as I was mentioning you get Alice and Bob talking to each other they're using BitTorrent or Nutella and also briefly there were reports that Lotus Notes and Windows Remote Desktop were being interfered with on Comcast's network and the particular forged packets that we were seeing were TCP reset packets which are just ordinary TCP packets with a single bit in the header the reset flag turned on and they cause the client to die the client may or may not recover if a particular TCP connection dies it may retry it at some point later maybe straight away maybe in 10 minutes maybe in half an hour maybe never so the consequences for an application of having these reset packets injected into its communications are quite complicated and unpredictable and what we saw in particular on Comcast's network was interference that looked like it had been designed for BitTorrent with the intention of preventing BitTorrent seeding on Comcast's network but the consequences of that interference looked very different for Nutella for example and it seemed to us that perhaps Comcast or whoever they had purchased this system from were just applying the reasoning that Nutella must be like BitTorrent and not really understanding what the results of their forged packets would be anyway so we wrote code to make these tests easier to run there was a simple little program designed by a colleague of mine that was shown that was released in 2007 called pcapdiff and as the name suggests it's a simple tool for taking two pcap packet capture files and reporting the differences between them so if you have a log captured over here with Alice and a log captured over there with Bob it'll say wait there is a drop packet here and a modified packet here but that doesn't answer the question of how you get those pcap files in the first place you still need to talk on the phone to someone test make sure you're running your packet sniffers at the same time and make sure there aren't any firewalls or other things in the way that are confusing your results so Switzerland is a fancier design it automates more of those steps of setting up a test environment getting the packet sniffers running at the same time dealing with firewalls and I'll show you how it works in the next few slides but it's worth noting that both of these pieces of software take a particular approach which is to detect any kind of modification or forgery of packets anything that's received by Bob that was not sent by Alice will trigger an alarm and that's different to some of the other tools that are out there which for instance look at heuristics relating specifically say to TCP reset packets because there are things you can look at about a TCP reset packet for instance part of a wave of packets that have looked like they're guessing sequence numbers to try and fall Bob into believing this is a real packet or is the time to live in the TCP reset packet radically different from the other times to live that you see on other packets in this connection or in this flow and so those kinds of heuristics they work up to a point and other people have used them successfully but we're talking about a sort of more general tool that will work for other kinds of modification if other kinds of modification are being deployed either by networks or by hackers and perhaps other things that might get deployed in the future so a general taxonomy of the kinds of software that can exist in this space to solve this problem and I'll show you some a table of other tools that are out there that fit in in different places in this taxonomy you can have active tools which generate traffic and then test to see whether it's interfered with or passive tools that just look at existing traffic and check for modifications and there are advantages to doing each of these things Switzerland just happens to be passive so it doesn't generate packets it just looks at the packets that you're exchanging already you can have testing software that is unilateral so it's just something that you run on your computer that tries to figure out whether something weird is happening in a particular TCP connection for instance and that software is convenient because you don't need to coordinate with any other computer but it's less powerful because you are always guessing whether a particular thing that you're receiving is illegitimate and an example of this kind of unilateral stuff is a plugin that views the BitTorrent client added for their software which just counted the number of reset packets that BitTorrent peers were collecting and that produced some really misleading results about particular ISPs where you are seeing lots of TCP reset packets but it turns out there are a whole lot of reasons why you can get them and if they were actually sent by the other party then they're not in any sense interference by an ISP you can have 1.5 sided tests probably it's better to say you can have two sided tests bilateral tests where you're running software on both Alice's computer and Bob's computer and there's some way that these two pieces of software coordinate or you can have a 1.5 sided test where you have a real algorithm running on one side and then some predictable behavior that you expect the other side to engage in so maybe there's a server running somewhere and it's a fake BitTorrent client that will try to download a BitTorrent file from you and you know how it's going to behave but you don't know you don't actually have code running there inspecting its end of the flow and lastly you can have multilateral clients which is what we've got with Switzerland basically bilateral but with lots of people participating next you can obviously focus down on one protocol you can talk about BitTorrent for example and there is a great tool I'll talk about on the next slide that works pretty well for just BitTorrent interference but it doesn't help you if you're wondering whether your new tele-client is being messed with or if you're a developer and you're writing where it's not working it's not going to tell you whether the network that you're on is hostile to your new code or whatever you can have different modes of deployment JavaScript some people have done JavaScript testing there was in fact a talk on Friday using JavaScript testing of web page modification that's fine but it's quite narrow in scope you can have Java applets a lot of people are putting these tests in browsers and you can have standalone apps for what we've got here and of course you can do crazy things as well so Dan Kaminski has a tool that he's talked about previously it's not actually publicly available at the moment called Inspector Packet that plays games in fooling an ISP into thinking that you are talking to Google when in fact you are talking to a test server that's nice but it's not what we're doing in Switzerland so here are the tools that are out there that we know about that you can just go and download today probably rather than getting into this in a great deal of detail if you want to look at this there's a URL here and you can go and look at that table to find a tool that's useful to you if you want to run a test but our tool is here out of Switzerland on the end of that URL and you'll get our particular software sorry my slides are running on a Mac that I've never used before so they're jumping around our tool is GPL'd it's being developed at Sourceforge so you can get involved in development if you're interested these slides ah the pause button yes it's currently a command line application maybe in the future we'll put a GUI on it or a local host web server kind of interface but at the moment it's just a command line tool it's about as polished as Netstat so if you can deal with Netstat a network tool then you probably can deal with Switzerland on the other hand if Netstat is perplexing to you like it was to me at some point then maybe you should wait until we release a few more versions and it'll make more sense currently all it does is spot modified and forged packets and give PCAP logs of those packets to the user so if both the packets from your side and the packets from your client side so if you receive them a forged packet it will give you a PCAP showing what your PS sent to you or tried to send to you so you can compare the two versions and figure out what was changed in between it also counts drop packets and gives you some general metadata about what flows are going through your system but the important piece of future work that we don't have yet is traffic shaping so there are a bunch of ISPs that are not specifically forging or spoofing packets with BitTorrents but which are deliberately throttling or slowing down how much traffic BitTorrent can send over a network in a fashion that you could call discriminatory in the sense that maybe web traffic doesn't receive the same kinds of limitations and so this is really interesting to test for but we haven't done it yet we're probably in a fairly good place in design terms to do that and I'll talk more about that in a couple of slides but how do we spot modified packets once again my slides are running away imagine you have a bunch of clients call them Alice and Bob and Charlie and Diane and they're all like out there on the net and they're all connected to the same Switzerland server in the middle and we'll call this bunch of users a circle now each of the members of the circle is told about the IP addresses of all the other clients in the circle and so they run a little packet sniffer that's just tuned to collect packets from those other machines and whenever they see a flow, a flow is a combination of IP addresses ports and protocol whenever they see a new flow of traffic between themselves and another member of their circle they start sending summary information about that flow to the server and the summaries are sufficient for the server to detect the injection of a spoof packet or the modification of a genuinely sent packet and raise a flag and when that happens then the server goes back to the clients and says hey wait a minute this packet you sent or you received was modified can you give me a copy of the actual packet in future we'll probably add some privacy settings to enable users to only give the packet to the other party and not to the server but at the moment a copy goes to the server the question that's interesting from a design point is how do you efficiently do this summarization how do you capture enough information about each packet that the server can tell if the packet was not legitimately sent at the same time you don't want to clog the link up by sending huge amounts of data so how do you efficiently summarize your traffic now the obvious ways to do this the most obvious way is also the least practical which is to send an entire copy of all your packets to the server and then of course the server can tell if any of them were modified in flight but you're adding a 200% overhead to your traffic and of course the privacy implications of doing that are not wonderful so the obvious next thing that you turn to as a designer is a secure hash what if I feed each packet through MD5 sum or char1 sum you still have a 27% traffic overhead there so that's not very good and you can do better if you try to do better say imagine you take the char1 sum of a packet and you just take the last couple of bytes that turns out to be insecure of course because someone who wants to who sees you sending a particular packet and who wants to forge a packet or modify that packet can just brute force the char1 sum find an evil packet that has the same fragment of a char1 sum and send that in the place of the packet that you sent but it turns out you can fix this problem and the way you do that is to have your Alice and Bob and Charlie and Diane all your clients talking to the server over an encrypted link using OpenSL which of course we haven't actually implemented yet so if you use the alpha version that's currently available theoretically an ISP could find some sneaky way of modifying a packet and you're not spotting it but we're figuring that we'll have this fixed before any ISP bother doing that then the server sends to Alice and Bob and every pair of clients that are talking to each other a key, a random key that is used to switch instead of using a char1 sum you just use a key to hash or an HMAC and then that prevents the ISP from or some other intermediary from brute forcing your weak hash because they can't see the key because it's inside this TLS connection and they can't see any of the targets for their brute forcing because all of the summary information that you're sending is also encrypted in flight so the only way that an adversary can do this is to try a whole lot of packets and eventually if they try 2 to the n where n is the number of bits in your hash fragment then they will successfully send something that fools you but of course they sent a whole lot of forged packets before they found that one magic forgery and you detected all of those forged packets that they sent first so there isn't really a feasible way to attack this design I don't think at least not through the crypto come on I actually have no more slides so I'm going to keep talking I have a few more points to make it's important when you send these hash fragments to mask out parts of the packets there are things that change all the time for example the time to live field inside an IP packet changes on every single hop the header check sums change and if you have a NAT firewall then the sender IP changes to something that you should know about so before you calculate these hashes you need to make some changes you rewrite the IP addresses in the ports according to what you know about the firewalls between these two machines you zero out any fields that can reasonably change one of the hardest problems that we had to deal with while building this system was realizing how bad consumer NATs are what they'll have in our home is doing wireless routing routing duty those things by and large modify your packets in lots of strange ways that you might not have expected or at least I didn't expect in my naive new experience in this field and the things that we saw being changed inside those packets were so extensive that you can't ignore them all we saw do not fragment bits being changed we saw MSS maximum segment size fields being changed we saw ACT packets being retransmitted by routers when the client had never retransmitted them themselves we saw the fields inside ACT packets the actually acknowledgement number inside an ACT packet being increased by a NAT router so your NAT router is acknowledging packets that you have not received yet so you have this very large set of weird things that some firewalls do and there isn't really any general purpose way of ignoring them because if you for instance ignore that last thing I described if you ignore forged ACT packets going out then an adversary can drop a packet and then forge an ACT for that packet and then your TCP connection is going to sit around waiting for this thing with Alice the sender thinking that it's been received and Bob the receiver never having received it and if an adversary does this to your connections they're going to flail horrifically so at the moment a way of dealing with these NAT firewalls is basically just to report the modifications to the user you'll get a notice saying hey someone's modifying your packets if there's a firewall in the path it'll say hey it's probably your firewall or the other peers firewall that's doing the modification don't blame your ISP for this until you've removed the firewalls and run the test again but of course that means that you have to manually go back and figure out that it was your firewall that's doing this so perhaps at some point someone might build a big database of firewalls that you can fingerprint and though I have this model links this and it's known to do this kind of modification or other kinds of modification perhaps at some point as a big project you can transparently ignore this kind of behavior the other thing that we're planning to implement but have not yet implemented in the current version is an algorithm that goes back once it's seen modification in a particular flow say it's seen the MSS field being changed and says right we reported to the user that MSS is being changed by someone in this particular flow now let's start changing our hashing algorithm so that we mask out the MSS for future packets and then if at some point down the line you get a forged reset packet which modifies different fields inside the packet you're going to still be able to spot that but we haven't implemented that yet the last thing that's worth noting is the way that you can run this software to run tests as I said it's a passive system so if you want to run tests you can send any kind of traffic between Alice and Bob and Charlie and Diane and it will be tested but of course you need to find someone else to run a test with so we have an IRC channel that's reasonably active that's just sprung up in the last week with people there posting links to torrent files and web servers and stuff that you can run tests with so we have kind of a list of public services that are also Switzerland clients and so if you're say a VoIP developer and you want to know if your VoIP client is running okay go and post a link to a public server there in the future we may end up actually having some EFF server somewhere that runs a whole lot of test services and something in the client that actually does active tests against those but again it's further work rather than something we've got today so I think those are the main points about design of the last thing we want to do traffic shaping detection we want to see whether your ISPs messing with your VoIP connections not by dropping or forging anything but just by occasionally like one packet in 10 takes a second longer or 10 milliseconds longer or some small amount of time longer to arrive at the destination and therefore your VoIP call gets all jittery and you hear static all the way through or it falls apart because the reliability and the quality of service you're getting isn't good enough so because we have Alice and Bob in place we have software on both of these machines we have we kind of insist on NTP running on the client or at least NTP dates so that we can get an estimate of how accurate the clock is on each of these machines we can actually get up to the accuracy of your clock we can get measures of latency for every single packet and then do statistics on that so we're kind of excited to add that in the future but we don't have the code to do that stats yet if anyone wants to work on it we're an open source project and we'd love to have people hacking on this stuff too so I will just leave with the by reminding you all about the URL for this project it's here and you'll find links to the source forage project the ISC channel mailing list everything on that page so I'll probably take questions about this project here then I don't know how we're going for time but we're planning to do general EFF questions about all of EFF's work in the breakout room after this session I don't know what time it is at the moment why don't you go ahead and take questions and we may yeah it looks like we actually probably have time to take questions here as well about general EFF stuff so I'll take Switzerland questions first and then we can do all of EFF issues I had a question you're actually recommending that people turn off their home net routers for the purpose of using Switzerland so we're not recommending that anyone in particular does anything on a particular network but we're pointing out that if you want to run tests and at the moment this is really a testing tool for network engineers and protocol developers more than random home users but if you want to run reliable tests and you want to be testing not your NAT firewall but your ISP then you have to get the NAT firewall out of the way okay so you're not actually recommending that for home users because unfortunately in a popular press Switzerland is being recommended for home users to test their ISPs right at some point in the future we'd love to have Switzerland be reliable enough especially in terms of its response to NAT firewalls and the weird things that they do that we could get meaningful data from home users behind NAT firewalls but at the moment we don't think that's possible there are other people who've talked about, there was a researcher who asked me about putting Switzerland on a NAT firewall itself and that would obviously be a great design if you can actually figure out a way of cramming our Python application onto a DDWRT router or porting it to C so it's lean enough that it fits there you're in a good position there for a number of reasons both you get you don't have to worry about this modification stuff as a result of the firewall you also get better data about quality of service because you don't have to worry about other flows from other clients behind the same NAT essentially creating noise in your data on how much traffic your IP address is running so I'm going to leave you with a general question for EFF and then stop hogging the mic last year there was a lot of discussion about what the response was to the adjustments in FISA that a lot of people in the federal administration wanted and I would have loved to have heard a little follow up on that fairly important topic so I didn't click the adjustments in what, sorry oh, I should hand this to Kurt I got one here the foreign intelligence surveillance act we really call it FISA so what the question is about is there have been a number of changes to FISA that were passed into law just this past July one of the issues that was very disappointing to us was that it included a package of telecom immunity legislation that was designed to ensure the telecommunications companies wouldn't have to face the music with respect to our lawsuit we are continuing to fight that we believe that was an unconstitutional law and we'll be fighting that in the courts at the same time the FISA amendments act also revamped surveillance laws in a way designed to make it much easier for the government to spy on you and it is very disappointing that this law passed any more questions yeah a couple of questions first thanks to you guys you guys mean business you guys are doing very technical things this is cool thank you outstanding one thing the Switzerland servers used it very quickly before coming to DEF CON and was like wow neat the remote servers that you guys are running data retention are you guys keeping the bugs and then how does that get into this is obviously a developer tool right now so we haven't written our policy on our data retention but the plan is probably to do something like about two weeks of data retention on our server which gives us a reasonable window if someone says hey we saw some interference here can you go and have a look at what the server recorded during that session it gives us time to follow up on it but it means that we're not a huge target for subpoenas and most of the logs that you get on the server I should go into some more detail about this with the current design most of the logs that you get on the server are just about flow so they're flow metadata logs just there was a connection between port A and port B between these two machines there were you know 3000 packets sent between them so that kind of flow metadata is revealing but it's not as bad as communications contents we also keep contents of some packets in very special cases and the special cases are when Switzerland reported interference in a particular flow the current code grabs nine packets three random like often the interference will be a whole wave of packets being modified at once so we select three of those occurrences of modified packets and we grab up the modified packet and a packet on either side effectively give or take and so we have this tiny little record of actual content of communications during interference and I guess the important point that we're trying to hammer home with the client is if those contents of communications are confidential then you shouldn't be running the client on that machine that is exchanging confidential information it's a very small amount of traffic but there is a slim danger that something sensitive could be in there and we want users to consent to that when they're running the client on their machine cool second question the Switzerland model and the tools saw that this was written in Python great, palpable is there any thought given to making this a more generalized framework for network testing beyond just the how can I put it, instead of just checking for the packets doing more sophisticated things with capturing packets on both ends? obviously the statistics that I was mentioning before is a general network testing of general network testing interest in the sense that if you want to know how good the link that you just built between two buildings or between two cities or something is then you can run these clients and probably there's a bit of engineering to do but you'll get some nice latency and jitter statistics if we build that statistics engine I believe you could get support from people working on TCP stacks as well yes that's true, so there's a whole separate issue about whether you can get a particular instrumentation data out TCP stacks internally know a whole lot of stuff about the state of your connections for instance all the back off algorithms that are the mechanism by which ISPs normally shape traffic, the way they shape traffic is by dropping a few packets they trigger a response in the TCP code on your machine saying hey wait we're not getting all of our packets we're losing some packets here let's slow down a bit and figure out what speed we can reliably transmit data at and so inside the kernel of your operating system this data is available but there isn't generally a way to get it out and my understanding is I'm fairly new to network testing in the sense that until this Comcast stuff started being on an EFF radar I hadn't gotten my hands dirty with network testing like this but my understanding from people who've been working in this field for longer is you can do that but you need to replace the TCP stack inside your kernel and some people do that there's a project called net1000 I think it's in this table that actually NDT so there are these speed test tools that actually use instrumented TCP stacks to get more information about what your kernel knows about your network state and it'll be an interesting future project to try and get some of that data into Switzerland cool and the last question quickly traffic shaping considerations so when you guys are talking about wanting to get towards measuring traffic shaping how are you guys going about it that maybe should be dealt with out of the room so we don't have a design yet but the general idea would be add the first thing I'd say is we need to probably add to the summary information we send to the server a little bit of extra information about the time stamp for that packet the moment what we're doing is we send a whole batch of packets at once and we just send a general time stamp saying this is the newest packet in this whole batch and that's obviously less dated so what we would need is an efficient compression of the time stamp which you can get so you do something like you say this batch contains packets with time stamps between this time here t0 and this time here t1 and then you do some Huffman encoding or some other encoding of the time stamps for every single packet so that you don't need to send a high precision floating point number as the time stamp for every last packet in the batch and so once you have that compression algorithm maybe you can get away with I actually haven't done the numbers on this properly but I think probably a couple of bytes will give you a time stamp that is accurate as your system clock and then once you've done that the server can do some calculations saying okay for every packet that is cancelled out like it's sent by Alice, received by Bob, you calculate how long it was in flight you add that to an average latency for the link and then you do some statistics on the outlying things to get jitter yeah Johnny ask the follow up, grab the mic or afterwards have you thought about control channel detection from the ISPs perspective for example Comcast could see hey this guy's talking to a Switzerland server let's turn off the evil bit so whitelisting is definitely an issue here the first solution that we had to this conceptually was what about maybe grab another wireless network from another ISP send your connection to your Switzerland server over that link and your real test data over the first link alternatively you can perhaps use Tor to connect to a Switzerland server for the control channel and your regular non overlay connection to test the data we have a message in the Switzerland protocol that allows a client to announce that it's public IP address is something other than the IP address it's connecting from and that message is disabled because it has security implications that we haven't quite thought through probably I'm not convinced that there is a way of adding that feature without creating a risk that someone else will find a way to use it to learn something about your traffic when you're not a Switzerland client or when you're a Switzerland client and they're another Switzerland client maybe they can run some tests to check certain things about your connection there's some subtle stuff there so probably the way this will happen at first would be someone runs a special Switzerland server that has that feature enabled where clients can log in through Tor and just say hey I'm at this IP address on Cox's network just trust me that I'm there and that server makes sure that it won't leak private information about people who are totally unconnected to Switzerland but that's a research project still for us actually one thing that I was thinking of just as food for thought you're going to be introducing SSL for the control channel in the near future correct maybe something like XMLRPC over HTTPS to make it look as much like normal HTTPS traffic as possible right actually that's a good point so the other way you can defend against this is obviously the control channel problem is harder when it's a thing, Switzerland.eff.org it's a publicly known server with a publicly known port it's very easy to whitelist if we use SSL we have to make the actual traffic fingerprint proof you know it looks like any other HTTPS connection and that's a good strategy I have a general EFF question made for the attorneys sure over the past year since last fcon we saw a couple instances where lawsuits targeted DNS providers so there was WikiLeaks and then there was a Dutch MP that had a controversial movie and what happened was servers would be overseas so they're outside the jurisdictional reach of whoever wanted to take down the servers so what they did was they went after the domain name fill that one in for me what do you mean? so if you can't get a legal authority or a court to order a server to be shut down but you can't order their domain name registrar the registrar then that's an easy way to take down a site if the law actually allows that process in court I think we'll comment further on so is there a jurisdiction that would be better to have your registrar in as opposed to another jurisdiction as a way of avoiding those takedowns that's my general question so we were involved in the WikiLeaks situation and that was a situation in which initially court gave a very erroneous court order then we got involved a lot of other people got involved and I would say that one of the things it's not so much that the U.S. law was the problem the court misapplied the law and then when the court misapplication of the law was brought to its attention the injunction was lifted the order was taken down such that the order was removed such that the DNS did not have to stop directing traffic to WikiLeaks but this is something that can happen when courts are having a rushed judgment and presented with a perhaps not a full understanding so really having a DNS provider with backbone is a really a good way it was unfortunate that the DNS provider in that instance did not raise some of what ultimately turned out to be some meritorious issues preferring instead to just resolve the matter and look for backbone yep so that's Switzerland mine's a question about when you fly overseas back and you have thumb drives, laptops hearing impaired devices that store data information and they're allowed to investigate them and there's no timetable for them to return them how they keep track of that they're not ending up with somebody because there's fraud saying they can keep them and hold them forever so border search is something that we have been very much interested in looking at this issue from a number of levels trying to use the freedom of information act to find out more about what's going on looking closely at court cases so it's the TSA's position and what it is Petrol's position that when you come from overseas that they can search your laptop just as they could search anything else they haven't or they have affirmatively not taken the position that a U.S. citizen can be prevented from coming into the country if they don't allow the search I should say an issue that at this point appears to be not very commonplace but I can imagine so is what if your material is encrypted and you're not interested in handing over the password and so as I understand their position on that is then they will take the device and try and break your crypto and take as long as they feel as necessary to do so so if you want to travel with information across the borders either you have a lot of faith in your crypto's ability to withstand an unlimited amount of time of government attack or not have it on your computer and perhaps transmit it in a secure method when you're not at the border follow up on the laptop and border discussion so I appreciate your EFF's testimony for Senator Feingold and surprisingly minority party was fairly tepid and it seemed relatively flat in terms of saying that they wanted a fair standard applied I'm curious are you aware of any legislation then to follow up on the breaking the encryption would that constitute a DMCA violation? Yeah, I don't think you'd be able to prevent them from looking at your encrypted material by trying to assert the DMCA but and as far as the legislation I this is not my issue I've been looking to some aspects of this but the Fourth Amendment privacy issues but have not been looking into the legislative things Earlier you mentioned having a provider with backbone is a good defense do you guys have a list of good versus bad providers and would you make one? One thing we've actually really tried not to do is do EFF endorses some of you may know that EFF was involved in the creation of the trustee system where you could get the trustee seal if you had a privacy policy and it turned out that the trustee system was not really a particularly good way for people to decide whether or not to trust somebody and that has made us very reticent to get further involved in saying a particular company so let's say some company came to us and said we're the bestest and we will have backbone and we think yeah you really are and then we endorse them and then they change their mind and they do something else so we have to start auditing them and then pretty soon we have a whole EFF auditing division and that's not What about rather than auditing just have a list of companies that have been caught doing immoral or companies that don't get caught No companies that have a list saying these companies have been caught doing XYZ these companies have not been caught yet factual link to the case I think that whether someone's been caught yet is not necessarily the strongest correlation as to whether or not they're doing bad things That's a nice sharping tool though One fairly pragmatic observation about the WikiLeaks case is that WikiLeaks had several domain names registered with different registrars in different countries and that kept people finding their site at wikileaks.be while wikileaks.org was down so that's a pragmatic strategy you can take to make us off safer from that particular means of takedown I have a follow-up question to the border security stuff before What happens if I have a file full of junk about 3 gigabytes or so Now, random data looks like good crypto Right? So, I have this file full of random data I come into the country They say, what's this? It's random data We want your keys, it looks like crypto It's random data It is random data and they take my laptop Can I call you guys? Well, it looks like we're running low on time We're going to do the Q&A Hold on, I'm going to get to that Please, what I would transition with is I believe that Marsha Hoffman, who is the attorney who is focused most on border search issues, is I hope going to be available in our Q&A session in the smaller room and border search issues would be best directed to them You know, but if you're ever in trouble Please call the EFF If you want to make trouble I didn't make trouble Yeah, I mean Well, one of the things that we are going to be talking about in a bit is how to get a case that is going to help help us help you and I think that's something that Eva is going to be speaking to say now or take it at the Q&A Sure, if you come to the talk at the breakout room I will take the time to explain how we decide to take a case what we do with cases that are interesting to us but that we cannot take on because there's only 30 of us and also what sort of things not to bring to me ever One last question before we move over to the breakout room Going back to Comcast not Switzerland in particular but is the EFF's problem with what Comcast was doing or the ham-handed way they went about it? I think there are a bunch of different ways that you have to split up that question So we have degrees of concern about different things that ISPs can do Comcast's particular kind of interference was really troubling because if you're an application developer say a startup company or some kid in a dorm room somewhere writing a new application and it just so happens that your new software trips over some interference algorithm that ISPs are deploying somewhere then you're going to need to find a way to get the ISP to change that behaviour or you're going to need to understand what it is and figure out how you can avoid triggering it and if you imagine a world where there are dozens or hundreds of ISPs around the planet and they're all running around to building these kinds of systems for interference suddenly it starts to seem that the only people who could get a new protocol to run reliably on the internet would be huge companies that would have the resources to either engineer their way around every weird thing that an ISP is doing to them or go and negotiate with every ISP on the planet to make sure that their traffic is carried correctly so there are really serious policy problems with this kind of interference if you're talking about discrimination that's maybe just about bandwidth so web applications get the full capacity of the channel but peer to peer applications only get up to a third of it so some ISPs in Canada for instance have started to deploy that kind of traffic shaping on their networks now there you have some concerns that are perhaps less spectacular in the sense that it isn't going to completely prevent applications from seeing the light of day but it raises serious competitive questions about whether ISPs are actually placing themselves in the position of picking winners about which applications will be allowed to function best on tomorrow's networks and again we think it would be much wiser for an ISP to solve its traffic management problems in a way that doesn't look at what application it is that's sending the traffic so I guess I'm admitting that on cable networks for instance we have problems with congestion it's true that BitTorrent a whole stack of BitTorrent clients sitting and exchanging large files on the same street could bring one of Comcast's cable loops to its knees if they didn't do some kind of general purpose traffic shaping there but what we think they should probably do is figure out in real time each application we can afford to give each application 30 kilobytes per second right now so let's let them all have that much and then these IP addresses over here seem to have been sending a lot of data not just for the last minute but for the last three hours so let's put them in a category of long term data transfer IP addresses and give a bit more bandwidth to someone who's just fired up a YouTube video download not because it's a YouTube video download or it's web traffic but because it's a new connection that's sending data all of a sudden and you're deprioritizing stuff that's been transferring for the last three hours and we think that that makes more sense from a policy point of view and also probably more sense from an ISP's point of view in the sense that if they try to mess with BitTorrent like this BitTorrent is just going to go and find a way to sidestep all of the interference and sometimes that sidestepping will be evading detection sometimes it will be irresponsible stuff like let's ignore reset packets and suddenly the internet gets more broken so it's probably in the interests of ISPs to look for more neutral ways of achieving their network management objectives anyway I mean there are conspiracy or kind of competition arguments that some people have raised some people have said hey Comcast is messing with BitTorrent because they're afraid of a video distribution mechanism that threatens their cable marketplace and those like really complicated legal questions and antitrust questions that may be like valid questions to ask but they're really hard to answer so how have you as a comment I can say I worked for another large cable operator for several years and that question never once came up I mean that's not the consideration at all right and one hopes that it isn't but you get this it's easy to make that allegation against a cable company when they are seen doing this kind of thing so our advice to the cable companies would be don't put yourself in a position where someone can make that allegation to you be transparent about what you're doing on your network say we're shaping it we're shaping traffic, here's our algorithm if you have problems with it you know technical detailed problems like your applications being broken by it like talk to our engineers over here and just be out there and upfront about what you're doing and in the meantime I guess where our approach is let's shed light on what networks are doing because in Comcast's case when we went and spoke to them they flat out denied doing this for weeks after we'd been running tests and seeing these forged recent packets you know we were talking to senior Comcast lawyers and they just said we don't interfere with any application on our network so yeah our message would be ISPs should be transparent and think carefully about how they manage traffic and we're going to try and write tools and inform the public and give people a way to test whether ISPs claims are correct or not thank you alright thank you Arun remember to come and join EFF at the EFF table over in the exhibit room and we are now going to go to a breakout room can someone tell me the number of that room? 3 103? no no breakout the room number 3 in conjunction with track 3 alright breakout room number 3 over the whole somewhere we have plenty of other interesting things to talk about we can talk about national security letters we can talk about fair use we can talk about other IP issues and so we encourage you all to come by to catch up over in the breakout room thank you very much