- cypherpunks-legacy - lists.cpunks.org

Re: [liberationtech] IGP Blog :: Technology as symbol: Is resistance to surveillance technology being misdirected?
by Evgeny Morozov 06 Jul '18

06 Jul '18

My problems with Milton Mueller's argument are manifold: 1. I'd argue there is no "budding movement" engaged in "resistance" to "surveillance technology"; Mueller is attacking strawmen here. There are a) reporters who are interested in how and why some Western companies keep breaking the export laws (would we prefer them not to report on such stuff, even if the laws are stupid?) b) technology activists who oppose much of this technology in principle, regardless of whether it's used in democracies or autocracies c) politicians, NGOs and activists - many of them dedicated to a particular issue (e.g., free speech or corporate social responsibility) or country (e.g. Iran) who see surveillance trade as an opportunity to advance their own agenda and attract media attention to whatever cause they are fighting. Yes, there are moments when agendas of all these groups overlap but to treat this as a movement that somehow aims to ban these tools instead of addressing foreign policy issues to me seems unfair. Yes, there is always a danger of succumbing to techno-fetishism, of assuming that "fixing internet freedom agenda" = "fixing freedom agenda" (didn't someone write a book about it?) but I'm yet to see anyone involved with surveillance trade posit anything along these lines. As has already been pointed out on this list, people who actually go to these fairs and get us all these wonderful corporate brochures are on the record as fierce critics US foreign policy (which may explain their occasional travel problems!). I also think it's a bit misguided to expect people concerned with CSR and making sure that tech companies behave ethically to switch careers midstream and become critics of US foreign policy; these are not mutually exclusive pursuits but I don't know why we should deny validity to one of them. 2. I think that Mueller himself misdirects his anger; the root of the problem is in US domestic policy towards surveillance, it's not in its foreign policy. But to backtrack a bit: the technologies that are up for export go far beyond DPI (see this list by Bugged Plant - http://buggedplanet.info/index.php?title=Main_Page) Many of them are actually single purpose, despite all the hot rhetoric on this list - and yes, many of them do look like weapons to me. (Well, some are in theory dual purpose if you count fighting terrorism from, say, Saudi Arabia or Tehran a valid government activity). So if one really wants to do something about them, one has to inquire about why there is demand for such tools among Western law enforcement agencies, how it all ties to FBI's Going Dark problem, FBI's plans for CALEA-2, and so forth. (I touched upon some of these issues in my keynote at 28C3 two days ago). To imagine that we can kill the market in these tools if we can only straighten the US policy on Saudi Arabia (good luck on that front) seems naive to me. I'll concede that the media coverage did not get into the domestic angle - but it's an opportunity for the future. Media-wise, the big task ahead is to actually making local media - newspapers in Italy, Germany, Denmark, Sweden, Israel, etc - excited about this narrative, so that they can chase both local suppliers and the extent to which these companies first came into being thanks to domestic demand. 3. I take issue with the anti-regulation skepticism (defeatism?) expressed both by Mueller and others on this list. Yes, some sanctions are too broad and they end up hurting ordinary uses but it's not a given that ordinary users will be hurt if the new sanctions are kept narrow and target individual companies and actually learn from the unintended consequences of earlier rounds of sanctions on Syria and Iran. No one is arguing that sanctions will solve the problem; they will only raise the costs (btw, this WaPo article<http://www.washingtonpost.com/world/national-security/trade-in-surveillance…>quotes a State Department rep saying exactly this - no one is starry-eyed about the effectiveness of sanctions). Likewise, I am not fully convinced that requiring tech companies to a) verify where their gear is used b) turn it off if it's used in Syria or Iran or Country X is such a terrible idea. What's the argument against? That a bunch of hackers will break into, say, Jordan's censorship system and turn off the country's Internet filtering system remotely? Well, great - let's celebrate. Similarly, I don't think that requiring Western tech companies to verify that the gear they sell is used in the countries where it's been shipped to (by checking IP addresses, for example) somehow constitutes pervasive surveillance. And even if it does, what's so bad about watching a bunch of authoritarian governments? I understand that Mueller's cyberlibertarian philosophy does not allow for any censorship or surveillance, no matter how beneficial, but I'm not sold on this in the context of tools sold to dictators. 4. I'll be the first to acknowledge that some of the media reports on surveillance trade have been a) populist and anti-corporatist b) technologically illiterate (DPI in Israel was a good example of this) c) lazy (Bloomberg, in particular, has a soft spot for quoting the same set of people). And yet compared where we were in 2010 or 2009 - with all the silly reporting about "Twitter Revolutions" in Iran - that's still a sea change (for the better) in media coverage. Next frontier for Bloomberg, WSJ and others is to make a more explicit connection to why these tools are made in the first place, thus linking foreign policy to very mundane issues of domestic surveillance. So those are just a few of my problems with Mueller's argument. Evgeny _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-dev] #466 (signed-introducer-announcements) landed!
by Brian Warner 06 Jul '18

06 Jul '18

Thanks to Zooko's hard work in getting pycryptopp-0.6.0.(mumble) released yesterday, I was finally able to land the #466 signed-introducer code last night. What does this mean for users? * tahoe now depends upon the new pycryptopp: next time you update, you'll need to do 'setup.py build' so it will pick up 0.6.0 * the first time your node wakes up with the new code, it will create a NODEDIR/private/server.privkey file, containing the new Ed25519 private signing key. This is a binary file, not meant for copy/paste or human interaction. * server IDs are changing. The old (foolscap-based) IDs look like "rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the Welcome page will show new server IDs that look like "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old ones are a SHA1 hash of the tub's public SSL certificate, the new ones are an Ed25519 public verifying key) Internally, this opens up the door for a bunch of stuff: * Introducer announcements are now extensible dictionaries, instead of fixed-size tuples. This allows servers to cleanly advertise new services, and include additional metadata like how much space they have available. This will be used by the upcoming Accounting work to advertise an alternate storage-server object from which per-account connections can be obtained. #666 * Announcements are signed, which means the Introducer doesn't get to modify the metadata, reducing its authority a little bit. This gets us one step closer to having a distributed introduction mechanism (the signed announcements can simply be flooded, without worrying about what the other nodes might do to them in transit). #68 * Server nodes are known by their Ed25519 public verifying key, rather than by their Foolscap SSL TubID. This enables secure non-SSL messaging (sign a request instead of sending unsigned requests over a validated-SSL connection), so we can switch from Foolscap to e.g. HTTP for share transport, which should make the Tahoe protocol easier to port to other languages (Foolscap offers more features than we really need, and its need to check the SSL certificate is an implementation hassle). #510 * Clients can securely reference a server by its pubkey, which will be the basis for explicit "which servers am I willing to use" configuration. #467, #295 What about compatibility? All combinations of V1/V2 client/introducer should work as expected: * new (V2) clients can talk to old (V1) Introducers just fine: they'll detect the lack of V2 methods and talk down to the introducer (sending it unsigned V1-format tuples instead of signed V2-format dictionaries). * old V1 clients can talk to new V2 introducers: they send announcements to the old method name, the Introducer will upgrade the tuples to dictionaries (unsigned, of course) for distribution to V2 clients, and distributes the original tuple to V1 clients * new V2 Introducers can talk to old V1 clients just fine: the client will subscribe with the old V1 method, causing the Introducer to downgrade new-style announcements for the V1 client * V1 clients always get tuples, V2 clients always get dictionaries. *Signed* announcements will only happen when all three participants (announcing client, Introducer, subscribing client) are V2. What about serverid compatibility? * over the last few months we've refactored the way clients use storage servers, to split their notion of "serverid" (aka "peerid") into several pieces. V2 announcements provide specific values for these different pieces, so that some can remain the same as before, while others are new. (this process is about 80% complete) * "serverid" will be used to mean the Ed25519 pubkey (but some code still uses it to mean the tubid.. this will eventually be fixed). This is the servers's long-term secure identifier, suitable for #467-style server designation. Old V1 nodes won't have serverids, so it won't be possible to securely reference a V1 node, so using #467 will depend upon upgraded servers and an upgraded Introducer. * "name" is used to describe servers on the Welcome page, and is either the pubkey (if available) or the tubid. It is not secure, in the sense that it could be spoofed, and so shouldn't be used for #467-style server designation. * "permutation seed" is used by the server-selection algorithm. It is provided by the server (which can use anything it likes). Brand new V2 servers use the ed25519 serverid. Old V1 servers use the foolscap tubid (i.e. when V1 tuples are upgraded by the Introducer to V2 dicts, it adds a "permutation-seed-base32" key derived from the tubid). V2 servers which wake up with existing shares will use their tubid forevermore, since that probably means other clients have known them by the tubid, so they'll be expecting share placement based upon the old tubid. This allows backwards compatibility for old shares while allowing brand new empty servers to live in the future, not the past. * "lease seed" is always the tubid, and continues to be used to generate the per-share per-server lease-renew/cancel secrets. To safely use a shared secret, you have to send that secret over a very specific channel, which means they're tied to a transport protocol and a verifiable endpoint. So they won't be usable in a post-Foolscap world anyways. The plan (as part of #666) is to replace shared-secrets with per-lease Ed25519 keypairs. * "foolscap write enabler seed" is also the tubid, for exactly the same reasons. We'll need to replace both lease-management and mutable-file write-management before we can move from Foolscap to unencrypted HTTP. Open questions: * serverids currently include a short version marker: the "v0-" in "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". Does that get in the way of cut-and-paste? Would it be better to use something like "v0fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq"? When we abbreviate these in places like the FileChecker results page (to identify specific servers), is there a way to get the v0- out of the abbreviated form? (maybe use a "-v0"/"v0" suffix? maybe define the abbreviated form to skip the prefix, so this example appears as just "fcmgu"?) * are there places where I've missed the tubid-to-serverid transition? I spotted one just now, the "My nodeid" field on the welcome page. * Next steps: push forward on the Accounting work, specifically looking for ways to display (to clients) which servers you're using, and then maybe to exert some control over that list. There are some UI questions to figure out: I can imagine managing this config with both tahoe.cfg (have a config key with a list of serverids) and via a web page (a <table> with enable/disable checkboxes), but the latter requires some web-security frameworking that we don't have in place yet (and might not want to rely upon anyways). Let me know if you have an questions.. I imagine some of this is as clear as mud. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Secrecy Power Sinks Patent Case
by EEkid＠aol.com 06 Jul '18

06 Jul '18

Secrecy Power Sinks Patent Case By Kevin Poulsen 02:00 AM Sep. 20, 2005 PT When New England inventor Philip French had his epiphany 15 years ago, he didn't dream it would lead to an invention that would be pressed into service in a top-secret government project, or spawn an epic court battle over the limits of executive power. He was just admiring a tennis ball. The ball's seam, with its two symmetrical halves embracing each other in a graceful curve, intrigued him. "I thought, my god, I bet you can do something with that kind of shape," he recalls. He was right. French and two colleagues went on to design and patent a device now called the Crater Coupler, a simple, foolproof connector for linking one pipe or cable to another without nut threads or bolted flanges. The device is interesting on its own, but the broader legal legacy of the invention may be more important. In a little-noticed opinion this month, a federal appeals court ruled against the Crater Coupler patent holders and upheld a sweeping interpretation of the controversial "state secrets privilege" -- an executive power handed down from the English throne under common law that lets the government effectively kill civil lawsuits deemed a threat to national security, even if the state is not a party to the suit. The ruling is notable as a rare appellate interpretation of the state secrets privilege as it applies to patent holders. As such, it is a potentially worrying development for inventors -- particularly those developing weapons, surveillance and anti-terror technologies for government contractors -- who may find infringement claims dismissed without a hearing under the auspices of national security. It also offers a fascinating, if limited, view into the machinery of official secrecy at a time when the privilege is being exercised as never before. "It's the most powerful privilege the government has," says William Weaver, senior adviser to the National Security Whistleblowers Coalition. "It's the nuclear option. It never fails." French says he and his partners -- Charles Monty and Steven Van Keiren -- got the first inkling of a national security application for the Crater Coupler a decade ago. While shopping the new design around to "a whole mess of quick-disconnect companies," the trio received an intriguing inquiry from Lucent Technologies, the reincarnation of the legendary Bell Labs research center, and at that time still part of AT&T. Lucent wanted to evaluate the Crater Coupler for use as a fiber-optic "wetmate" -- an airtight connector for two fiber-optic cables designed to operate underwater. It was part of a contract with a U.S. government agency that, the company said, would have to remain unnamed. "It was a secret black job, they couldn't divulge what it was for," says French. "Who it was for, the Navy or the CIA, or who knows, they never said." A Lucent spokesman confirmed that the company had contact with French in 1995, but wouldn't discuss the details, citing government secrecy concerns. But according to French, the inventors agreed to help Lucent try to adapt the Crater Coupler to the company's needs, with the expectation that Lucent would license the group's patent if it all worked out. The inventors sent over plans, sketches and a model, and French began consulting and advising a Lucent engineer in monthly phone calls. After about a year of development and testing, Lucent had good news for the inventors: The device passed all the tests, shaming a competing, clunky design that French says resembled an old thermos. But when the inventors got on the phone with Lucent's lawyers to discuss license terms, the company dropped a bomb. "Almost the first thing they said was, 'Well, we don't have to do anything, because this is under some sort of provision for military secret stuff where we don't have to pay anything,'" says French. French felt betrayed. "This was after a year of encouragement, with me helping them and them informing us of their progress," says French. "That was one hell of a shock." Lucent eventually offered the inventors $100,000 for the right to produce 1,000 wetmate couplers. The offer caused a rift between French and his partners: They wanted to make a counteroffer of $500,000, but French -- in his 60s and recently retired -- wanted to take what was on the table. "I said, well, Lucent doesn't have to do a thing, so why don't we take $100,000 and be happy with that?" Unable to agree, French's partners bought him out for a flat $30,000. "I used some of the money to have a garage built," French says. Lucent rejected the remaining inventors' counteroffer, and in 1998 Monty and Van Keiren, now incorporated as Crater Corp., filed a federal lawsuit in eastern Missouri against Lucent alleging patent infringement, trade-secret theft and breach of contract. Crater's attorney, Robert Schultz, says there's a question of basic fairness. "Lucent's made a ton of dough, and my clients are out in the cold," says Schultz. The patent-infringement portion of the case has since been dismissed, under a federal law that says a company can't be sued for infringement if the development was for the exclusive use of the government. After a year of pretrial wrangling, the case had progressed to the point that Schultz could start subpoenaing documents to support his claim, when the government intervened to assert the state secrets privilege. Never passed by Congress, the privilege has its roots in English common law and was cemented into American jurisprudence by a landmark 1953 Supreme Court case titled U.S. v. Reynolds. In Reynolds, the widows of three men who died in a mysterious Air Force crash sued the government, and U.S. officials tried to quash the lawsuit by claiming that they couldn't release any information about the accident without endangering national security. The Supreme Court upheld the claim, establishing a legal precedent that today allows the executive branch to block the release of information in any civil suit -- even if the government isn't the one being sued. According to research by Weaver, an associate professor of political science at the University of Texas, the government invoked the privilege only four more times in the next 23 years. But following the Watergate scandal, the executive branch began applying state secrecy claims more liberally. Between 1977 and 2001, there were at least 51 civil lawsuits in which the government claimed the state secrets privilege -- in every case successfully. "There was more oversight of presidential activity" after Watergate, says Weaver. "In response to that, I think presidents resorted to the state secrets privilege to keep that oversight from cramping their style." Under Reynolds, the head of a federal agency must personally intervene to invoke the privilege. In Crater v. Lucent, it was Richard J. Danzig, then-secretary of the Navy, who did the honors. In a March 1999 declaration, Danzig claimed that permitting Crater to pursue a legal inquiry into the government's alleged use of their coupler would tip off U.S. adversaries to certain highly classified government operations and "could be expected to cause extremely grave damage to national security." "Those operations and programs are currently ongoing," Danzig wrote. "It is therefore my opinion that disclosure of information concerning them would permit potential adversaries to adopt specific measures to defeat or otherwise impair the effectiveness of those operations and programs." Judge E. Richard Webber granted the government's request immediately, and blocked the Crater inventors from obtaining any information from Lucent or the feds about the government's alleged use of the Crater Coupler or any other coupling device. In the legal battle that followed, it emerged that the order covered an astonishing 26,000 documents -- some of which were not only unclassified, but had already been entered into the public record. In 2002, Webber examined those documents in chambers, and concluded that not one of them would be available for Crater's use in pressing its case. Schultz turned to the Federal Circuit Court of Appeals. This month a divided three-judge panel ruled (.pdf) that the lower court had properly applied the state secrets privilege. "I would have thought that courts would be more hesitant to apply it to the patent area, but in this case there was no hesitancy whatsoever," says Weaver. In a dissenting opinion, Circuit Judge Pauline Newman wrote that the ruling efficiently killed Crater's lawsuit, and argued that a saner solution would have been to proceed with the case behind closed doors -- a procedure already used to protect classified information during criminal espionage prosecutions. "Although there may be areas of such sensitivity that no judicial exposure can be countenanced -- such as, perhaps, the formation of the Manhattan Project -- there is no suggestion that the sensitive information concerning the Crater Coupler cannot be protected by well- established judicial procedures for preserving the security of sensitive information," Newman wrote. Schultz argues that the secrecy order shouldn't apply to documents concerning an unclassified presentation that Lucent held in which it allegedly showed off the Crater Coupler. He plans to ask for a rehearing of the appeal but claims to be optimistic that the case can proceed with or without access to the evidence. If so, it would be a rarity, says Steven Aftergood, director of the Federation of American Scientists' Project on Government Secrecy. "The privilege has worked very effectively for the government," says Aftergood. "In almost every case where they've invoked it, it leads to the termination of litigation." Indeed, the list of cases in which the state secrets privilege has been invoked seems a pantheon of injustice. The privilege was upheld in 1982 to prevent former Vietnam War protestors from learning more about an illegal CIA and NSA electronic surveillance effort that targeted them during the 1970s. In 1991, it was used to stop a lawsuit by a banker who'd unwittingly been roped into an illegal CIA money-laundering operation, and who claimed the agency had ruined his career when he tried to get out. In 1998, workers at the Nevada airbase known colloquially as Area 51 were blocked from learning what chemicals they'd been exposed to during illegal burning of toxic waste by base administrators. In 2004, the Bush administration resorted to the privilege to silence former FBI translator Sibel Edmonds, who said she was fired from the bureau after reporting security breaches and misconduct in the agency's translation program. And in perhaps the most disturbing case, this year the Justice Department asserted the privilege to kill a lawsuit by Maher Arar, a Syrian-born Canadian citizen who, in 2002, was picked up by U.S. officials as a suspected terrorist while changing planes at JFK, and promptly shipped off to Syria for a year of imprisonment and torture. "Here's a guy who was a victim of a crime, that is, kidnapping, who was sent by us to a foreign country to be tortured to get information for us," says Weaver. "That violates all kinds of laws and the Convention Against Torture and who knows what else." Weaver says the state secrets privilege is a blunt instrument that too often utterly obliterates any further inquiry by the plaintiffs in a civil case. "I'm not saying it's always invoked for evil purposes -- it almost certainly is not. But we can't tell when it is, and that's the problem." He faults Jimmy Carter for being the first president to use the privilege with frequency, and George W. Bush for using it systematically. "This presidency is the first one in history to use the secrecy privilege in a programmatic, organized comprehensive policy," Weaver says. "It's the first secrecy presidency." "It effectively shuts down the judicial process," says Aftergood. "It tells people that they cannot have their day in court because national security will not permit it, and that's a terrible message to send." Justice Department spokeswoman Cynthia Magnuson says the department generally doesn't comment on how the state secrets privilege is applied. "The only thing I can say is it's applied if appropriate only," she says. But if the outcome sometimes seems unjust, it's a necessary trade-off to preserve national security, says Washington attorney Shannen Coffin, a lawyer at Steptoe and Johnson and a former U.S. deputy assistant attorney general from 2002 to 2004. "That is the balance the court has struck in certain circumstances," says Coffin. "A lawsuit that relates to monetary damages isn't nearly as important as protecting the security of the American people." While at the Justice Department, Coffin was involved in several cases asserting the privilege. "I've been in meetings with cabinet officials that have invoked the privilege, and they don't take it lightly," Coffin says. If there's been an increase in the exercise of the privilege, "It is simply a recognition that information is a weapon in the modern day and age," says Coffin. "And that is a serious concern for national security." Coffin says bold action, like withholding 26,000 documents in the Crater case, is sometimes necessary to prevent a U.S. adversary from compiling bits and pieces of seemingly harmless, unclassified information into a state secret. That "mosaic theory" of national security is frequently cited in litigation surrounding the privilege, and Department of Justice attorney Lisa Olson raised the argument in the Crater case last year. "The more information that is disclosed, the easier it becomes to disclose more, and soon the floodgates are opened and nothing is secret," Olson told Judge Webber. A Navy spokeswoman declined to comment on the Crater case, but outside experts say it's easy enough to guess the nature of the top- secret project the government is protecting. "It's all but self- evident that it has to do with the clandestine monitoring of fiber- optics communications cables on the ocean floor," says Aftergood. "They've been interested in it since the first fiber-optic cable was ever invented," says James Bamford, author of two books on the NSA. "It's clear that they have a major operation in terms of tapping into sea cables." Fiber-optic cables were well on their way to supplanting less-secure communications technologies at the time that Lucent approached the Crater inventors, and it's been widely reported that the switch threatened to cut off the electronic spies at the NSA. "There's been this huge shift from using satellite communications, which is very easy to tap into, to using both terrestrial and transoceanic fiber- optic cables, and that's presented a major problem for NSA," says Bamford. To counter that problem, and keep the electronic intelligence flowing, NSA has reportedly developed sophisticated techniques for wiretapping undersea cables, relying on specially equipped Navy submarines, the most advanced of which is the newly recommissioned USS Jimmy Carter, fresh from a $1 billion upgrade that reportedly includes state-of-the-art technology for tapping into undersea fiber- optic communications. French, now 74 and living in Maine, is not a party to the case since his partners bought out his interest in the invention. But he still has bad feelings over the affair. "If it had been war time, World War II, I'd have given it to them. But if they're hiding behind some friggin' law, basically to screw somebody...." says French, trailing off. Lucent spokesman John Skalko says the court's secrecy order prevents him from addressing the inventors' claims in depth. "We deny any breach of contract or any misappropriation of trade secrets," says Skalko. "You can't try this case in your publication, it's only to be tried in a court of law," Skalko adds -- a prospect that seems increasingly unlikely. http://www.wired.com/news/technology/0,1282,68894,00.html? tw=wn_story_page_prev2 ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Secrecy Power Sinks Patent Case
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [IP] When suburban moms embrace the surveillance society
by d f tweney 06 Jul '18

06 Jul '18

"Sheepdom" hardly seems apt -- what sheep polices the other sheep, after all? That's the dog's job, and in this case the dog wasn't doing it. This is an inevitable result of ubiquitous surveillance. As YouTube proves, we are far more adept at watching each other than the government could possibly be. In the future, it's not "Big Brother" that will be watching us, but millions of Little Brothers. Maybe that's a little creepy. On the other hand it can work both ways. And if the surveillance extends to the halls of government (and those who work in government) then we will have an unprecedented level of transparency into the workings of our democracy. We've already got C-SPAN -- what we need now are a hundred thousand webcams all over Washington. Especially in our representatives' offices. -- Dylan Tweney writer/editor dylan(a)tweney.com http://dylan.tweney.com David Farber wrote: > > >Begin forwarded message: > >From: Greg Brooks <gregb(a)west-third.com> >Date: August 4, 2006 1:36:42 AM EDT >To: dave(a)farber.net >Subject: When suburban moms embrace the surveillance society >Reply-To: gregb(a)west-third.com > >Dave, for IP if you wish. > >There's an interesting piece in the Riverside (CA) Press-Enterprise >[1] about >a woman who got her house toilet papered and decided to hunt down the >culprits. She didn't want to involve the police, reasoning that >they had >better things to do, so she took the following steps: > >* She canvassed local stores to see which one had a run on toilet >paper. > >* She then got the manager of the store to show her surveillance >videos, >allowing her to see the personalized letterman's jacket of one of the >purchasers, as well as the license plate of the vehicle they got into. > >* Finally, she used a high school yearbook (matched to the school >based on >the letterman's jacket) and online databases to get the names, >phone numbers >and addresses of all the teens spotted in the store tapes. > >To me, this is a bit more than a "talker" feature. One takeaway, >IMHO, is >that we're pretty far down the road to sheepdom when average >citizens start >thinking "well, everything's monitored all the time anyway - let's >see if I >can make use of that." > >Warm Regards, >Greg Brooks >West Third Group > >[1] http://news.yahoo.com/s/ap/toilet_paper_caper > > > > >------------------------------------- >You are subscribed as dft(a)tweney.com >To manage your subscription, go to > http://v2.listbox.com/member/?listname=ip > >Archives at: http://www.interesting-people.org/archives/interesting- >people/ ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] When suburban moms embrace the surveillance society
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [liberationtech] IGP Blog :: Technology as symbol: Is resistance to surveillance technology being misdirected?
by Evgeny Morozov 06 Jul '18

06 Jul '18

My problems with Milton Mueller's argument are manifold: 1. I'd argue there is no "budding movement" engaged in "resistance" to "surveillance technology"; Mueller is attacking strawmen here. There are a) reporters who are interested in how and why some Western companies keep breaking the export laws (would we prefer them not to report on such stuff, even if the laws are stupid?) b) technology activists who oppose much of this technology in principle, regardless of whether it's used in democracies or autocracies c) politicians, NGOs and activists - many of them dedicated to a particular issue (e.g., free speech or corporate social responsibility) or country (e.g. Iran) who see surveillance trade as an opportunity to advance their own agenda and attract media attention to whatever cause they are fighting. Yes, there are moments when agendas of all these groups overlap but to treat this as a movement that somehow aims to ban these tools instead of addressing foreign policy issues to me seems unfair. Yes, there is always a danger of succumbing to techno-fetishism, of assuming that "fixing internet freedom agenda" = "fixing freedom agenda" (didn't someone write a book about it?) but I'm yet to see anyone involved with surveillance trade posit anything along these lines. As has already been pointed out on this list, people who actually go to these fairs and get us all these wonderful corporate brochures are on the record as fierce critics US foreign policy (which may explain their occasional travel problems!). I also think it's a bit misguided to expect people concerned with CSR and making sure that tech companies behave ethically to switch careers midstream and become critics of US foreign policy; these are not mutually exclusive pursuits but I don't know why we should deny validity to one of them. 2. I think that Mueller himself misdirects his anger; the root of the problem is in US domestic policy towards surveillance, it's not in its foreign policy. But to backtrack a bit: the technologies that are up for export go far beyond DPI (see this list by Bugged Plant - http://buggedplanet.info/index.php?title=Main_Page) Many of them are actually single purpose, despite all the hot rhetoric on this list - and yes, many of them do look like weapons to me. (Well, some are in theory dual purpose if you count fighting terrorism from, say, Saudi Arabia or Tehran a valid government activity). So if one really wants to do something about them, one has to inquire about why there is demand for such tools among Western law enforcement agencies, how it all ties to FBI's Going Dark problem, FBI's plans for CALEA-2, and so forth. (I touched upon some of these issues in my keynote at 28C3 two days ago). To imagine that we can kill the market in these tools if we can only straighten the US policy on Saudi Arabia (good luck on that front) seems naive to me. I'll concede that the media coverage did not get into the domestic angle - but it's an opportunity for the future. Media-wise, the big task ahead is to actually making local media - newspapers in Italy, Germany, Denmark, Sweden, Israel, etc - excited about this narrative, so that they can chase both local suppliers and the extent to which these companies first came into being thanks to domestic demand. 3. I take issue with the anti-regulation skepticism (defeatism?) expressed both by Mueller and others on this list. Yes, some sanctions are too broad and they end up hurting ordinary uses but it's not a given that ordinary users will be hurt if the new sanctions are kept narrow and target individual companies and actually learn from the unintended consequences of earlier rounds of sanctions on Syria and Iran. No one is arguing that sanctions will solve the problem; they will only raise the costs (btw, this WaPo article<http://www.washingtonpost.com/world/national-security/trade-in-surveillance…>quotes a State Department rep saying exactly this - no one is starry-eyed about the effectiveness of sanctions). Likewise, I am not fully convinced that requiring tech companies to a) verify where their gear is used b) turn it off if it's used in Syria or Iran or Country X is such a terrible idea. What's the argument against? That a bunch of hackers will break into, say, Jordan's censorship system and turn off the country's Internet filtering system remotely? Well, great - let's celebrate. Similarly, I don't think that requiring Western tech companies to verify that the gear they sell is used in the countries where it's been shipped to (by checking IP addresses, for example) somehow constitutes pervasive surveillance. And even if it does, what's so bad about watching a bunch of authoritarian governments? I understand that Mueller's cyberlibertarian philosophy does not allow for any censorship or surveillance, no matter how beneficial, but I'm not sold on this in the context of tools sold to dictators. 4. I'll be the first to acknowledge that some of the media reports on surveillance trade have been a) populist and anti-corporatist b) technologically illiterate (DPI in Israel was a good example of this) c) lazy (Bloomberg, in particular, has a soft spot for quoting the same set of people). And yet compared where we were in 2010 or 2009 - with all the silly reporting about "Twitter Revolutions" in Iran - that's still a sea change (for the better) in media coverage. Next frontier for Bloomberg, WSJ and others is to make a more explicit connection to why these tools are made in the first place, thus linking foreign policy to very mundane issues of domestic surveillance. So those are just a few of my problems with Mueller's argument. Evgeny _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-dev] #466 (signed-introducer-announcements) landed!
by Brian Warner 06 Jul '18

06 Jul '18

Thanks to Zooko's hard work in getting pycryptopp-0.6.0.(mumble) released yesterday, I was finally able to land the #466 signed-introducer code last night. What does this mean for users? * tahoe now depends upon the new pycryptopp: next time you update, you'll need to do 'setup.py build' so it will pick up 0.6.0 * the first time your node wakes up with the new code, it will create a NODEDIR/private/server.privkey file, containing the new Ed25519 private signing key. This is a binary file, not meant for copy/paste or human interaction. * server IDs are changing. The old (foolscap-based) IDs look like "rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the Welcome page will show new server IDs that look like "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old ones are a SHA1 hash of the tub's public SSL certificate, the new ones are an Ed25519 public verifying key) Internally, this opens up the door for a bunch of stuff: * Introducer announcements are now extensible dictionaries, instead of fixed-size tuples. This allows servers to cleanly advertise new services, and include additional metadata like how much space they have available. This will be used by the upcoming Accounting work to advertise an alternate storage-server object from which per-account connections can be obtained. #666 * Announcements are signed, which means the Introducer doesn't get to modify the metadata, reducing its authority a little bit. This gets us one step closer to having a distributed introduction mechanism (the signed announcements can simply be flooded, without worrying about what the other nodes might do to them in transit). #68 * Server nodes are known by their Ed25519 public verifying key, rather than by their Foolscap SSL TubID. This enables secure non-SSL messaging (sign a request instead of sending unsigned requests over a validated-SSL connection), so we can switch from Foolscap to e.g. HTTP for share transport, which should make the Tahoe protocol easier to port to other languages (Foolscap offers more features than we really need, and its need to check the SSL certificate is an implementation hassle). #510 * Clients can securely reference a server by its pubkey, which will be the basis for explicit "which servers am I willing to use" configuration. #467, #295 What about compatibility? All combinations of V1/V2 client/introducer should work as expected: * new (V2) clients can talk to old (V1) Introducers just fine: they'll detect the lack of V2 methods and talk down to the introducer (sending it unsigned V1-format tuples instead of signed V2-format dictionaries). * old V1 clients can talk to new V2 introducers: they send announcements to the old method name, the Introducer will upgrade the tuples to dictionaries (unsigned, of course) for distribution to V2 clients, and distributes the original tuple to V1 clients * new V2 Introducers can talk to old V1 clients just fine: the client will subscribe with the old V1 method, causing the Introducer to downgrade new-style announcements for the V1 client * V1 clients always get tuples, V2 clients always get dictionaries. *Signed* announcements will only happen when all three participants (announcing client, Introducer, subscribing client) are V2. What about serverid compatibility? * over the last few months we've refactored the way clients use storage servers, to split their notion of "serverid" (aka "peerid") into several pieces. V2 announcements provide specific values for these different pieces, so that some can remain the same as before, while others are new. (this process is about 80% complete) * "serverid" will be used to mean the Ed25519 pubkey (but some code still uses it to mean the tubid.. this will eventually be fixed). This is the servers's long-term secure identifier, suitable for #467-style server designation. Old V1 nodes won't have serverids, so it won't be possible to securely reference a V1 node, so using #467 will depend upon upgraded servers and an upgraded Introducer. * "name" is used to describe servers on the Welcome page, and is either the pubkey (if available) or the tubid. It is not secure, in the sense that it could be spoofed, and so shouldn't be used for #467-style server designation. * "permutation seed" is used by the server-selection algorithm. It is provided by the server (which can use anything it likes). Brand new V2 servers use the ed25519 serverid. Old V1 servers use the foolscap tubid (i.e. when V1 tuples are upgraded by the Introducer to V2 dicts, it adds a "permutation-seed-base32" key derived from the tubid). V2 servers which wake up with existing shares will use their tubid forevermore, since that probably means other clients have known them by the tubid, so they'll be expecting share placement based upon the old tubid. This allows backwards compatibility for old shares while allowing brand new empty servers to live in the future, not the past. * "lease seed" is always the tubid, and continues to be used to generate the per-share per-server lease-renew/cancel secrets. To safely use a shared secret, you have to send that secret over a very specific channel, which means they're tied to a transport protocol and a verifiable endpoint. So they won't be usable in a post-Foolscap world anyways. The plan (as part of #666) is to replace shared-secrets with per-lease Ed25519 keypairs. * "foolscap write enabler seed" is also the tubid, for exactly the same reasons. We'll need to replace both lease-management and mutable-file write-management before we can move from Foolscap to unencrypted HTTP. Open questions: * serverids currently include a short version marker: the "v0-" in "v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". Does that get in the way of cut-and-paste? Would it be better to use something like "v0fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq"? When we abbreviate these in places like the FileChecker results page (to identify specific servers), is there a way to get the v0- out of the abbreviated form? (maybe use a "-v0"/"v0" suffix? maybe define the abbreviated form to skip the prefix, so this example appears as just "fcmgu"?) * are there places where I've missed the tubid-to-serverid transition? I spotted one just now, the "My nodeid" field on the welcome page. * Next steps: push forward on the Accounting work, specifically looking for ways to display (to clients) which servers you're using, and then maybe to exert some control over that list. There are some UI questions to figure out: I can imagine managing this config with both tahoe.cfg (have a config key with a list of serverids) and via a web page (a <table> with enable/disable checkboxes), but the latter requires some web-security frameworking that we don't have in place yet (and might not want to rely upon anyways). Let me know if you have an questions.. I imagine some of this is as clear as mud. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Domestic surveillance and warrantless wiretaps
by Matt Blaze 06 Jul '18

06 Jul '18

Like many people, I found last week's Newsweek cover piece, revealing Thomas M. Tamm as the principal source for James Risen and Eric Lichtblau's 2005 NY Times story that broke the warrantless wiretap story, to be a riveting read. But I actually found a sidebar to the story even more interesting. That story talks about the now famous 2004 incident at Ashcroft's hospital bed in which several top DoJ officials threatened to resign. It turns out that was not about warrantless content collection, but rather about the wholesale collection of call records: http://www.newsweek.com/id/174602/output/print This story raises a number of new -- and ultimately quite disturbing -- questions about the nature of the wiretap program and the extent of its reach into the domestic communication of innocent Americans. In particular, put together with other reports about the program, it seems to corroborate claims that telcos (including my alma matter AT&T) provided the NSA with wholesale access to domestic call detail records, and that top DoJ officials worried seriously that this violated the law. I discuss the implications of this in more detail on my blog; perhaps some here will find it interesting: http://www.crypto.com/blog/metatapping -matt --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Judge says no to law enforcement cell-phone tracking request
by Gregory Hicks 06 Jul '18

06 Jul '18

http://rcrnews.com/news.cms?newsId=24009 ---------------------------------------- By Heather Forsgren Weaver Sep 6, 2005 WASHINGTON A federal judge in New York has ruled that law enforcement may not track someone without probable cause, according to News.com by CNET. Burton Ryan, an assistant U.S. attorney, had tried to obtain a "pen register" tap that would track constantly a target whenever his cell phone was in use. U.S. Magistrate Judge James Orenstein said no. To require that type of information, Ryan must apply for a wiretap, which requires probable cause. "I don't know anything about the specific case, but it is true that location information only attaches to a court order obtained with probable cause," said Les Szwajkowski, a former FBI agent now with Raytheon Corp "This is exactly the role magistrates are supposed to play. They are not rubber stamps." The rules implementing the Communications Assistance for Law Enforcement Act said that law enforcement was entitled to pen register information from a cell-phone conversation at the beginning and end of the call. This information would make it similar to a pen register in the wired world, which gives the date, time and number called. Because the location is fixed in the wired world, the location is known. According to CNET, Orenstein said that more definitive rules need to be established. "My research on this question has failed to reveal any federal case law directly on point. Moreover, it is my understanding based on anecdotal information that magistrate judges in other jurisdictions are being confronted with the same issue but have not yet achieved consensus on how to resolve it. If the government intends to continue seeking authority to obtain cell-site location information in aid of its criminal investigations, I urge it to seek appropriate review of this order so that magistrate judges will have more authoritative guidance in determining whether controlling law permits such relief on the basis of the relaxed standards set forth (under federal law), or instead requires adherence to the more exacting standard of probable cause," wrote Orenstein. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0