Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On 2013-08-06, at 3:19 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Griffin Boyce: Al, We may have to disagree as to the way forward. I hate to be contentious, but it seems unlikely that Tor applied a patch without reading firefox's changelog. Two days ago I presented a talk which emphasized how useful Tor is -- and I stand by that. Tor is still the best option for maintaining one's anonymity. Hi Griffin, Do you plan to release security advisories for all updates to the Linux kernel, GNU user space utilities and other dependences in the commotion router firmware? How is this, in any way, shape or form, relevant? Are you seriously opening up Commotion's bug handling in order to sort of justify this Tor situation? Tor had forked Firefox into its own browser, which is called Tor Browser. Mozilla issued an advisory for Firefox the day the bug was discovered, about five weeks ago. Tor should have issued a similar advisory for Tor Browser and consequently the Tor Browser Bundle, especially considering that the Tor Browser Bundle is by far *the* most visible way for end-users to download and use Tor these days. I suppose no but perhaps I'm mistaken? Has anyone done so with new commotion releases? I don't see[0][1] such notes, am I missing something? It seems impractical to note every change from downstream projects. Clearly you seem to disagree but I do wonder where you draw the line? Do your projects have some example where we might see the line in action, so to speak? As far as I can tell, we issued a security advisory within twenty-four hours. Actually, Tor issued a security advisory for Tor Browser a full 39 days after Mozilla did for Firefox. We spent more than a full day of multiple people's time working non-stop to understand the scope, the impact and the outcomes of this issue. We were already working on this task when you and another decided to jump up and down to let us know that we were failures by any other name. I'd say thanks but that isn't the word that comes to mind… I'd say thanks but that isn't the word that comes to mind… Dude, you're supposed to be Tor's outreach guy! Come on! The Tor Project does not triage every single Mozilla Firefox bug. We do try to understand which bugs are security critical. We do aim to track and put our energy into ensuring our browser uses the latest ESR releases. This generally includes lots of code fixes, security as well as other kinds of fixes, though we may not always fully understand every issue - we tend to trust Mozilla's lead on this topic. TBB requires lots of effort to forward port our privacy preserving patches as they are not in the mainline Mozilla repositories. We did this as we always do with TBB releases and we released patched versions of the software before we ever even learned of the exploit discovered this weekend that targets old, unpatched users: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) By a general count, it was around a month ago that we released patched versions. We normally just note that we've bumped the included projects to their latest stable versions - though in the case of our latest alpha, we specifically said[2]: In addition to providing important security updates to Firefox and Tor, these release binaries should now be exactly reproducible from the source code by anyone. Do you think that we should include that text with every single release? ie: This update provides important security updates to Firefox and Tor or something along those lines? Shall we just put that in every single release note? Is that really helpful? Actually, isn't that exactly what you've said I should do with my own project, Cryptocat, numerous times? It's actually really illuminating that you in fact are committing the exact same outreach and mitigation blunders that you keep criticizing other projects for. If you have a suggestion for how we might improve, I'm open to hearing it - though as far as I am able to tell - there isn't much to be done except to say security update next to firefox update in our normal release notes. That isn't very helpful as nearly every Firefox update in ESR is a security or stability related release. Please do feel free to suggest something constructive - if we have room for improvement, we're happy to make it! I think your entire email is not constructive. Roger's email with the actual advisory was awesome. Maybe he should represent Tor on this list from now on. NK All the best, Jacob [0] https://commotionwireless.net/download/openwrt [1] https://commotionwireless.net/blog/new-commotion-release-dr1-ready-testing [2] https://blog.torproject.org/blog/tor-browser-bundle-30alpha2-released -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to
[liberationtech] Postdoc Position in Peer-to-Peer Finance
Dear Colleagues, Applicants are invited for a EPSRC/Digital Economy Programme full-time funded post-doctoral position investigating digital connectivity and peer-to-peer relationships in financial services. The position is fixed term until 09/12/2014 with the likelihood of a three month extension. The project, 3rd Party Dematerialisation and Rematerialisation of Capital (3DaRoC), will evaluate the role of infrastructural designs and its effects on the patterns of use of financial services provided by digital intermediaries. You are expected to have (or be about to complete) a PhD in Information Systems, Information Science, Behavioural Science, Financial Services, Financial Computing, Economics, Geography, Sociology, Anthropology, Interaction or Experience Design, with experience in using ethnographic or survey-based research techniques. Candidates with research experience or enthusiasm for digital technology and innovation would be especially welcomed. You will be expected to lead on the development of fieldwork, analysis of data, and to develop business models around new technology deployments, as well as working with project partners and supporting the work of the other researchers. The direct line supervisor will be Dr. Adam Fish (Lancaster), and you will be based in the Department of Sociology. Informal enquiries may be made to Dr. Fish at a.fi...@lancaster.ac.uk. This is a full time fixed-term post beginning 15 October, or as soon as possible after this date. Please see the link below for my information: http://hr-jobs.lancs.ac.uk/Vacancy.aspx?ref=A775 Best, Adam -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Nadim Kobeissi: On 2013-08-06, at 3:19 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Griffin Boyce: Al, We may have to disagree as to the way forward. I hate to be contentious, but it seems unlikely that Tor applied a patch without reading firefox's changelog. Two days ago I presented a talk which emphasized how useful Tor is -- and I stand by that. Tor is still the best option for maintaining one's anonymity. Hi Griffin, Do you plan to release security advisories for all updates to the Linux kernel, GNU user space utilities and other dependences in the commotion router firmware? How is this, in any way, shape or form, relevant? Are you seriously opening up Commotion's bug handling in order to sort of justify this Tor situation? I'm asking for the clear line. Simple enough. Firefox's advisory seems fine to me but Griffin and you seem to suggest otherwise. I don't see an example of this suggestion being carried out by other projects - so either I misunderstand or we're exceptional. Either is fine with me, or another option which I'm not aware of - I'm sure that one of those is the case... This has nothing to do with 'justifying' anything - it has to do with asking for a clear example of what seems reasonable and is *already* done by someone. Please feel free to answer the question, we're happy to learn from an example. Are either of you involved in such an example? Might we learn from your example? If so, where might we see it? Tor had forked Firefox into its own browser, which is called Tor Browser. Mozilla issued an advisory for Firefox the day the bug was discovered, about five weeks ago. Tor should have issued a similar advisory for Tor Browser and consequently the Tor Browser Bundle, especially considering that the Tor Browser Bundle is by far *the* most visible way for end-users to download and use Tor these days. I think Tails is perhaps more popular but that is a side note, I suppose. I suppose no but perhaps I'm mistaken? Has anyone done so with new commotion releases? I don't see[0][1] such notes, am I missing something? It seems impractical to note every change from downstream projects. Clearly you seem to disagree but I do wonder where you draw the line? Do your projects have some example where we might see the line in action, so to speak? As far as I can tell, we issued a security advisory within twenty-four hours. Actually, Tor issued a security advisory for Tor Browser a full 39 days after Mozilla did for Firefox. Mozilla issued an updated blog post in the last day or so because of us contacting them. They clarified the specific issue around the same time as us. Al has already pointed this out - he works at Mozilla, so I suppose he seems to agree that we don't need to copy every advisory they write into our release notes. We spent more than a full day of multiple people's time working non-stop to understand the scope, the impact and the outcomes of this issue. We were already working on this task when you and another decided to jump up and down to let us know that we were failures by any other name. I'd say thanks but that isn't the word that comes to mind… I'd say thanks but that isn't the word that comes to mind… Dude, you're supposed to be Tor's outreach guy! Come on! I've asked for specific clarity on the level of granularity, I have yet to see a reply that addresses my question. The Tor Project does not triage every single Mozilla Firefox bug. We do try to understand which bugs are security critical. We do aim to track and put our energy into ensuring our browser uses the latest ESR releases. This generally includes lots of code fixes, security as well as other kinds of fixes, though we may not always fully understand every issue - we tend to trust Mozilla's lead on this topic. TBB requires lots of effort to forward port our privacy preserving patches as they are not in the mainline Mozilla repositories. We did this as we always do with TBB releases and we released patched versions of the software before we ever even learned of the exploit discovered this weekend that targets old, unpatched users: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) By a general count, it was around a month ago that we released patched versions. We normally just note that we've bumped the included projects to their latest stable versions - though in the case of our latest alpha, we specifically said[2]: In addition to providing important security updates to Firefox and Tor, these release binaries should now be exactly reproducible from the source code by anyone. Do you think that we should include that text with every single release? ie: This update provides important security updates to Firefox and Tor or something along those lines? Shall we just put that in every single release
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. NK Al -- Al Billings http://makehacklearn.org On Tuesday, August 6, 2013 at 1:28 AM, Nadim Kobeissi wrote: On 2013-08-06, at 3:19 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Griffin Boyce: Al, We may have to disagree as to the way forward. I hate to be contentious, but it seems unlikely that Tor applied a patch without reading firefox's changelog. Two days ago I presented a talk which emphasized how useful Tor is -- and I stand by that. Tor is still the best option for maintaining one's anonymity. Hi Griffin, Do you plan to release security advisories for all updates to the Linux kernel, GNU user space utilities and other dependences in the commotion router firmware? How is this, in any way, shape or form, relevant? Are you seriously opening up Commotion's bug handling in order to sort of justify this Tor situation? Tor had forked Firefox into its own browser, which is called Tor Browser. Mozilla issued an advisory for Firefox the day the bug was discovered, about five weeks ago. Tor should have issued a similar advisory for Tor Browser and consequently the Tor Browser Bundle, especially considering that the Tor Browser Bundle is by far *the* most visible way for end-users to download and use Tor these days. I suppose no but perhaps I'm mistaken? Has anyone done so with new commotion releases? I don't see[0][1] such notes, am I missing something? It seems impractical to note every change from downstream projects. Clearly you seem to disagree but I do wonder where you draw the line? Do your projects have some example where we might see the line in action, so to speak? As far as I can tell, we issued a security advisory within twenty-four hours. Actually, Tor issued a security advisory for Tor Browser a full 39 days after Mozilla did for Firefox. We spent more than a full day of multiple people's time working non-stop to understand the scope, the impact and the outcomes of this issue. We were already working on this task when you and another decided to jump up and down to let us know that we were failures by any other name. I'd say thanks but that isn't the word that comes to mind… I'd say thanks but that isn't the word that comes to mind… Dude, you're supposed to be Tor's outreach guy! Come on! The Tor Project does not triage every single Mozilla Firefox bug. We do try to understand which bugs are security critical. We do aim to track and put our energy into ensuring our browser uses the latest ESR releases. This generally includes lots of code fixes, security as well as other kinds of fixes, though we may not always fully understand every issue - we tend to trust Mozilla's lead on this topic. TBB requires lots of effort to forward port our privacy preserving patches as they are not in the mainline Mozilla repositories. We did this as we always do with TBB releases and we released patched versions of the software before we ever even learned of the exploit discovered this weekend that targets old, unpatched users: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) By a general count, it was around a month ago that we released patched versions. We normally just note that we've bumped the included projects to their latest stable versions - though in the case of our latest alpha, we specifically said[2]: In addition to providing important security updates to Firefox and Tor, these release binaries should now be exactly reproducible from the source code by anyone. Do you think that we should include that text with every single release? ie: This update provides important security updates to Firefox and Tor or something along those lines? Shall we just put that in every single release note? Is that really helpful? Actually, isn't that exactly what you've said I should do with my own project, Cryptocat, numerous times? It's actually really illuminating that you in fact are committing the exact same outreach and mitigation blunders that you keep criticizing other projects for. If you have a
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 12:30 PM, Jacob Appelbaum ja...@appelbaum.netwrote: Please feel free to answer the question, we're happy to learn from an example. Are either of you involved in such an example? Might we learn from your example? If so, where might we see it? Tails references upstream advisories, or at least did so in the past. https://tails.boum.org/security/Numerous_security_holes_in_0.18/ I actually think they are going overboard with those, but it's an example. The whole situation is pretty funny, by the way, since Mike Perry (TBB dev) was accused of maintaining Freedom Hosting by those OpDarknet clowns two years ago: http://pastebin.com/qWHDWCre -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? Your point is unclear in practice. Please do spell it out and if possible, please demonstrate how you do so in your own projects? All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On 2013-08-06, at 12:55 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? What's the alternative, Jake? Wait until the NSA exploits an innumerable amount of Tor users and then quickly write an advisory for a bug that was quietly fixed without a warning from Tor five weeks but still exploited? Because that is exactly what happened this time. Tor can just go on doing this again and again, or yes, you could issue advisories. You are maintaining your own browser called Tor Browser. Stop shifting blame onto Firefox. You're the guy who told me to never shift blame when you have a security vulnerability in the software you yourself are shipping. Practice what you preach. I sound harsh, sure, but at least I'm being productive and not freaking out about my ego. NK Your point is unclear in practice. Please do spell it out and if possible, please demonstrate how you do so in your own projects? All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Maxim Kammerer: On Tue, Aug 6, 2013 at 12:30 PM, Jacob Appelbaum ja...@appelbaum.netwrote: Please feel free to answer the question, we're happy to learn from an example. Are either of you involved in such an example? Might we learn from your example? If so, where might we see it? Tails references upstream advisories, or at least did so in the past. https://tails.boum.org/security/Numerous_security_holes_in_0.18/ I agree - Tails does a pretty good job of referencing upstream but they don't email out an advisory for each issue in each upstream project. Nor do they do a specific analysis of each bug spending many days of people time per bug. Somewhere there is a line and clearly, we failed to meet the high standards of a few folks on this list. I'm mostly curious if that high standard will be expressed in a cohesive manner where we might learn from it. I actually think they are going overboard with those, but it's an example. Where do you draw the line? I guess with release notes that bump versions, mention that users should upgrade and so on? I tend to like the Tails way of doing things - I have advocated for a little more linkage to security advisories. Still, I think it is not as critical as a secure updater or packaging TBB for various packaging systems. We're understaffed, so we tend to pick the few things we might accomplish and writing such advisory emails is weird unless there is an exceptional event. Firefox bugs and corresponding updates are not exceptional events. :( Also, I'll note even Tails doesn't reference sub-modules of the specific projects - they are just linking to DSA and related pages. The whole situation is pretty funny, by the way, since Mike Perry (TBB dev) was accused of maintaining Freedom Hosting by those OpDarknet clowns two years ago: http://pastebin.com/qWHDWCre It is awful for Mike and I can't even begin to find it funny in the least. Though I'll take your point that it is rich with awful irony. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Nadim Kobeissi: On 2013-08-06, at 12:55 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? What's the alternative, Jake? That was a list of choices and you didn't choose one. Please choose one or more - though not all of them make sense when put together. It was a question and well, your answer isn't much of an answer. Wait until the NSA exploits an innumerable amount of Tor users and then quickly write an advisory for a bug that was quietly fixed without a warning from Tor five weeks but still exploited? This is not accurate. We heard about attempts at exploitation and within ~24hrs we released an advisory - we had already released fixed code a ~month before exploitation was found in the wild. Please do not mix up the time-line. To restate: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) The exploit was found in the wild on last weekend, I learned about it on or around August 4th. Please note that our patched versions were released nearly a month before this was found in the wild. There is no reason to support the conclusion that we silently fixed anything in response to an exploit. Please consider that your statement is entirely unsupported by evidence, Nadim. Because that is exactly what happened this time. Tor can just go on doing this again and again, or yes, you could issue advisories. You are maintaining your own browser called Tor Browser. Stop shifting blame onto Firefox. You're the guy who told me to never shift blame when you have a security vulnerability in the software you yourself are shipping. Practice what you preach. Your assessment of this situation is incorrect. We regularly release updates that include updates to included code and often, we make note of the fact that the upstream code has security fixes included. There is no blame shifting, only a question of how to best share that information in a way that users will understand. I have asked repeatedly for examples and for details of how to improve things - you seem only interested in slinging mud. Perhaps this isn't the most useful way forward? I sound harsh, sure, but at least I'm being productive and not freaking out about my ego. I don't think you are being productive at this point in the conversation. You are correct and I agree with you - you are harsh - I'll extend this commentary: it reflects poorly on you(r ego) and very little is gained by such behavior. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 1:07 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Somewhere there is a line and clearly, we failed to meet the high standards of a few folks on this list. I'm mostly curious if that high standard will be expressed in a cohesive manner where we might learn from it. Well, in the end, it's all done for the users. Keeping software up-to-date is easier than following advisories, even more so if there is an auto-update functionality. So I don't understand the big deal about not reissuing advisories for upstream projects, which takes a lot of time for dubious effect. Although the point becomes moot once you are talking about libraries that are not directly used, unlike major Firefox-level applications. E.g.: https://blog.torproject.org/blog/new-openssl-vulnerability-tor-not-affected http://pastebin.com/qWHDWCre It is awful for Mike and I can't even begin to find it funny in the least. Though I'll take your point that it is rich with awful irony. I don't think anyone took those guys seriously back then (or anyone whose opinion matters, at least). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Surveillance Society
From: David Murakami Wood d...@queensu.ca Surveillance Society | Vol.11, No.1/2 (2013) Surveillance Futures http://library.queensu.ca/ojs/index.php/surveillance-and-society/issue/current edited by Kirstie Ball, Clive Norris and David Murakami Wood. This is a double issue featuring both papers from open submission and papers originally presented at the 5th Biannual Surveillance Studies Network / Surveillance Society Conference, 'Watch This Space? Surveillance Futures' organized by Kirstie Ball, Ben Gould, Nicky Green, Clive Norris and Charles Raab. Featuring 12 new articles... Rob Michael Pallitto - Bargaining with the Machine: A Framework for Describing Encounters with Surveillance Technologies Steve Mann Joseph Ferenbok - New Media and the power politics of sousveillance in a surveillance-dominated world Patrick O'Byrne Alyssa Bryan - Resisting Public Health Surveillance: Anonymous HIV Testing and the Imperative of Health Natasha Saltes - ‘Abnormal’ Bodies on the Borders of Inclusion: Biopolitics and the Paradox of Disability Surveillance Chiara Fonio Stefano Agnoletto - Surveillance, Repression and the Welfare State: Aspects of Continuity and Discontinuity in post-Fascist Italy Helen M. Hintjens - Screening in or out? Surveillance of unwanted humanity across the EU Kees Boersma - Liminal Surveillance. Intensified use of an existing CCTV system during a local event Inga Kroener - 'Caught on Camera': The media representation of video surveillance in relation to the 2005 London Underground bombings Séverine Germain - A prosperous ‘business’. The success of CCTV through the eyes of international literature Christopher Gad Lone Koefoed Hansen - A Closed Circuit Technological Vision: On Minority Report, event detection, and enabling technologies Jennifer R. Whitson - Gaming the Quantified Self Baki Cakici - Sustainability through surveillance: ICT discourses in design documents plus a research note by Emily Smith David Lyon on Survey Findings from Canada and the USA on Surveillance and Privacy from 2006 and 2012, and reviews of Bauman and Lyon's Liquid Surveillance, Magnet's When Biometrics Fail, Gilliom and Monahan's SuperVision and Larsen's Setting the Watch. Surveillance Society | http://www.surveillance-and-society.org …over a decade of independent, genuinely open-access, free, peer-reviewed academic publishing!-- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Jacob Appelbaum: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? Your point is unclear in practice. Please do spell it out and if possible, please demonstrate how you do so in your own projects? Just a couple friendly concepts. Your message wasn't addressed to me. By the way, it didn't occur to me to blame the Tor Project. I don't know about every average Josphine, Josue, and Tsu, Anu, etc. on the streets of the world, but it is obvious to me from my user standpoint that the TBB is a patched verion of Firefox (admittedly, one has to dig a bit to determine which version of the underlying Firefox it is based on, which I wouldn't expect the average user do to or know.). Ther average user of neither software likely doesn't see or read security adviseries, although I think they happily allow the latest versions o Firefox to automatically update themselves. TBB users are at special risk of being targeted for spying (according to recent news reports), hacking/exploits (as is the case in this instance), and this may be increasingly true in the future. Oops. I'm a slow typist (just getting up): From Jacob Applebaum's next mail to a mail: I tend to like the Tails way of doing things - I have advocated for a little more linkage to security advisories. Still, I think it is not as critical as a secure updater or packaging TBB for various packaging systems. We're understaffed, so we tend to pick the few things we might accomplish and writing such advisory emails is weird unless there is an exceptional event. Firefox bugs and corresponding updates are not exceptional events. :( Also, I'll note even Tails doesn't reference sub-modules of the specific projects - they are just linking to DSA and related pages. The point I was getting to is that several parrallel strategies come to mind: (1) It would not be a bad idea to post applicable Firefox-issued security avisories to one of your lists (2) Even have an RSS feed of them available through the TBB, as well as RSS of TBB releases, and what security issues are covred including one advised by Firefox. This could notify of stable, alpha and beta releases, so everyone knows when security updates are available, possibly at the cost of stability. (3) When you get an update mechanism going, for stability reasons, you probably want it to automatically only update to stable or beta releases[?]. However, you could have a parrallel release schedule to get these upstream patches out ASAP. I realize labor is involved here; but if at all possible, updating your last stable patch to work with the latest Firefox release ASAP and releasing it as a stable/beta while continuuing development on a more major/feature-related update that will start as an alpha release when ready. (possibly backporting some TBB-only-security fixes only to your last patch when it makes sense). Obviously, this is free software, and you must work ithin the constraints of your resources. The frequent security updates would have the most tangible benefit for most users, but it would be a decent user service to notify of security issues that apply/could apply to the TBB as well. Thanks for your invaluable work. Asa -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Maxim Kammerer: On Tue, Aug 6, 2013 at 1:07 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Somewhere there is a line and clearly, we failed to meet the high standards of a few folks on this list. I'm mostly curious if that high standard will be expressed in a cohesive manner where we might learn from it. Well, in the end, it's all done for the users. Keeping software up-to-date is easier than following advisories, even more so if there is an auto-update functionality. So I don't understand the big deal about not reissuing advisories for upstream projects, which takes a lot of time for dubious effect. I tend to agree. Although the point becomes moot once you are talking about libraries that are not directly used, unlike major Firefox-level applications. E.g.: https://blog.torproject.org/blog/new-openssl-vulnerability-tor-not-affected We wrote that because people asked us about those specific OpenSSL issues, if I remember correctly... http://pastebin.com/qWHDWCre It is awful for Mike and I can't even begin to find it funny in the least. Though I'll take your point that it is rich with awful irony. I don't think anyone took those guys seriously back then (or anyone whose opinion matters, at least). Sadly, Mike took their harassment seriously. It was awful. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Asa Rossoff: Jacob Appelbaum: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? Your point is unclear in practice. Please do spell it out and if possible, please demonstrate how you do so in your own projects? Just a couple friendly concepts. Your message wasn't addressed to me. By the way, it didn't occur to me to blame the Tor Project. Thanks for your response! I don't know about every average Josphine, Josue, and Tsu, Anu, etc. on the streets of the world, but it is obvious to me from my user standpoint that the TBB is a patched verion of Firefox (admittedly, one has to dig a bit to determine which version of the underlying Firefox it is based on, which I wouldn't expect the average user do to or know.). Ther average user of neither software likely doesn't see or read security adviseries, although I think they happily allow the latest versions o Firefox to automatically update themselves. Understood. TBB users are at special risk of being targeted for spying (according to recent news reports), hacking/exploits (as is the case in this instance), and this may be increasingly true in the future. Probably, yes. I think that is a fair assessment - though it applies to anyone who uses privacy, security and anonymity software, I think. Oops. I'm a slow typist (just getting up): From Jacob Applebaum's next mail to a mail: I tend to like the Tails way of doing things - I have advocated for a little more linkage to security advisories. Still, I think it is not as critical as a secure updater or packaging TBB for various packaging systems. We're understaffed, so we tend to pick the few things we might accomplish and writing such advisory emails is weird unless there is an exceptional event. Firefox bugs and corresponding updates are not exceptional events. :( Also, I'll note even Tails doesn't reference sub-modules of the specific projects - they are just linking to DSA and related pages. The point I was getting to is that several parrallel strategies come to mind: (1) It would not be a bad idea to post applicable Firefox-issued security avisories to one of your lists Part of the issue - from my perspective - is that 'applicable' is a bit nebulous. Nearly every bug *might* turn into an anonymity destroying bug with some engineering effort. (2) Even have an RSS feed of them available through the TBB, as well as RSS of TBB releases, and what security issues are covred including one advised by Firefox. This could notify of stable, alpha and beta releases, so everyone knows when security updates are available, possibly at the cost of stability. I like this idea - though I wonder how users would feel about it? Will they read it? Should it be our own RSS feed or an RSS feed of Mozilla's data? (3) When you get an update mechanism going, for stability reasons, you probably want it to automatically only update to stable or beta releases[?]. I tend to prefer 'secure' update over 'automatic' update. However, you could have a parrallel release schedule to get these upstream patches out ASAP. I realize labor is involved here; but if at all possible, updating your last stable patch to work with the latest Firefox release ASAP and releasing it as a stable/beta while continuuing development on a more major/feature-related update that will start as an alpha release when ready. (possibly backporting some TBB-only-security fixes only to your last patch when it makes sense). Sure, that seems reasonable. Obviously, this is free software, and you must work ithin the constraints of your resources. The frequent security updates would have the most tangible benefit for most users, but it would be a decent user service to notify of security issues that apply/could apply to the TBB as well. I think there is a balance here and I think adding more specific data to release notes is a reasonable improvement. I also think an RSS feed is a really good idea, thanks for that! I'll pass it on to those
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On 2013-08-06, at 1:23 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 12:55 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? What's the alternative, Jake? That was a list of choices and you didn't choose one. Please choose one or more - though not all of them make sense when put together. It was a question and well, your answer isn't much of an answer. Yes, to be absolutely clear, I think Tor should issue advisories for confirmed security issues in Tor Browser, since Tor Browser is a fork of Firefox and is independently maintained. This is exactly what Tor did this time, except next time you shouldn't wait five weeks for the situation to explode. Wait until the NSA exploits an innumerable amount of Tor users and then quickly write an advisory for a bug that was quietly fixed without a warning from Tor five weeks but still exploited? This is not accurate. We heard about attempts at exploitation and within ~24hrs we released an advisory - we had already released fixed code a ~month before exploitation was found in the wild. Please do not mix up the time-line. To restate: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) The exploit was found in the wild on last weekend, I learned about it on or around August 4th. Please note that our patched versions were released nearly a month before this was found in the wild. There is no reason to support the conclusion that we silently fixed anything in response to an exploit. Please consider that your statement is entirely unsupported by evidence, Nadim. I could be mistaken. Where's the advisory that was issued the day after, that mentions that a critical Tor Browser vulnerability was fixed? Because that is exactly what happened this time. Tor can just go on doing this again and again, or yes, you could issue advisories. You are maintaining your own browser called Tor Browser. Stop shifting blame onto Firefox. You're the guy who told me to never shift blame when you have a security vulnerability in the software you yourself are shipping. Practice what you preach. Your assessment of this situation is incorrect. We regularly release updates that include updates to included code and often, we make note of the fact that the upstream code has security fixes included. There is no blame shifting, only a question of how to best share that information in a way that users will understand. I have asked repeatedly for examples and for details of how to improve things - you seem only interested in slinging mud. Perhaps this isn't the most useful way forward? How am I only interested in slinging mud?! How are you even allowed to adopt a tone like this while doing your job as an advocate for Tor? I'm simply trying to advocate for Tor not waiting five weeks before releasing an advisory next time! Comments like this are really just not acceptable, Jake. NK I sound harsh, sure, but at least I'm being productive and not freaking out about my ego. I don't think you are being productive at this point in the conversation. You are correct and I agree with you - you are harsh - I'll extend this commentary: it reflects poorly on you(r ego) and very little is gained by such behavior. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised: I LOVE NADIM AND JAKE
Because that's become a trolling-engagement thread, i cannot resist to hijack it. I LOVE NADIM AND JAKE!** -naif ** Especially when they engage in trolling Il 8/6/13 12:32 PM, Jacob Appelbaum ha scritto: -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Hi, Maxim Kammerer wrote (06 Aug 2013 09:52:36 GMT) : Tails references upstream advisories, or at least did so in the past. https://tails.boum.org/security/Numerous_security_holes_in_0.18/ Right, and we have no plan to stop doing this. What we've been doing for years when releasing a new Tails that fixes security issues (that is, basically every single one we've put out) is: 1. Users are told your version of Tails has known security issue on startup if needed; this one has a link to a security announce like the one Maxim pointed to. 2. We issue a release announcement, such as https://tails.boum.org/news/version_0.19/, that starts with All users must upgrade as soon as possible, but doesn't point to the corresponding security advisory. After reading this thread, I wonder if we should perhaps change this, and have this sentence link to the security advisory. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Jacob Appelbaum: I like this idea - though I wonder how users would feel about it? Will they read it? Should it be our own RSS feed or an RSS feed of Mozilla's data? I don't like the idea. You need to worry about the upgrading behavior of casual users of TBB, who aren't going to bother to read advisories. Republishing advisories takes a lot of your valuable time. Added to that, every fucking tiny crash-bug in Firefox may grow to a full-blown exploit like we've seen. The people that do read the advisories, can find them at the Firefox ESR advisory page (https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html). I do think you might want to bother to link to that list of vulnerabilities when releasing a new version of TBB with an security-updated Firefox. I also like the approach of the TAILS project. They just start every single release announcement with 'Numerous security bugs found in TAILS X.XX', which makes it crystal clear for the average user they need to upgrade. Every time. Also: please make separate blog posts for regular and alpha releases. It's been confusing before. Make sure the regular release sits on top on the blog listing. Let me propose the announcement of June 26th as I would've (retrospectively) liked to see it: Subject: Security release. New Tor Browser Bundles. Body: All of the Tor Browser Bundles have been updated with the new Firefox 17.0.7esr. This includes fixes to a href=https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html;8 vulnerabilities/a, of which 4 have critical impact, and 4 have high impact. We bstrongly/b urge you to update to the latest version of the Tor Browser Bundle (2.3.25-10) as soon as possible. [continue with download-easy link and list of updates] Nadim Kobeissi: How am I only interested in slinging mud?! How are you even allowed to adopt a tone like this while doing your job as an advocate for Tor? I'm simply trying to advocate for Tor not waiting five weeks before releasing an advisory next time! Comments like this are really just not acceptable, Jake. Nadim, you need to calm the fuck down. Take a deep breath, re-read your own emails, and consider whether you need to apologize for your unproductive stampede. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised: I LOVE NADIM AND JAKE
I must admit, it can be entertaining at times. (now is not one of those times). ;3 Griffin On 8/6/13, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Because that's become a trolling-engagement thread, i cannot resist to hijack it. I LOVE NADIM AND JAKE!** -naif ** Especially when they engage in trolling Il 8/6/13 12:32 PM, Jacob Appelbaum ha scritto: -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Just another hacker in the City of Spies. #Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de My posts, while frequently amusing, are not representative of the thoughts of my employer. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Joseph Lorenzo Hall: On 8/6/13 6:41 AM, Jacob Appelbaum wrote: (2) Even have an RSS feed of them available through the TBB, as well as RSS of TBB releases, and what security issues are covred including one advised by Firefox. This could notify of stable, alpha and beta releases, so everyone knows when security updates are available, possibly at the cost of stability. I like this idea - though I wonder how users would feel about it? Will they read it? Should it be our own RSS feed or an RSS feed of Mozilla's data? Not sure if this is practical but the TBB splash screen could give some notion of the implications of using an old specific TBB... e.g., with the version check return one or more critical vulns that have been patched, to warn the user and encourage immediate update? We do have an update indicator - soon, we'll have an updater as well, I think. We had a few discussions about it at the TorDev meeting in Munich last month. Frankly, I'm not sure this is solving a problem Tor/TBB has, but it strikes me that a warning along the lines of the following for old TBB would not be bad: Holy shit, this TBB is from 12 months ago! You're crazy to use such an outdated version. Please update! We do put a fairly large message on the splash page. We could probably improve the warning page based on elapsed time - currently it is just one page locally stored, I think. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Nadim Kobeissi: On 2013-08-06, at 1:23 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 12:55 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? What's the alternative, Jake? That was a list of choices and you didn't choose one. Please choose one or more - though not all of them make sense when put together. It was a question and well, your answer isn't much of an answer. Yes, to be absolutely clear, I think Tor should issue advisories for confirmed security issues in Tor Browser, since Tor Browser is a fork of Firefox and is independently maintained. This is exactly what Tor did this time, except next time you shouldn't wait five weeks for the situation to explode. This is where the confusion comes into play, I think. Please note the advisory we released this week: https://lists.torproject.org/pipermail/tor-announce/2013-August/89.html We specifically address the one thing we *know* that is being exploited and we note that there are other issues, though we don't go into depth as upgrading is the only path forward. Now note the Mozilla security issues for the Firefox ESR releases: https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html You're on the one hand saying that we did the right thing and on the other, you're saying that we should issue an advisory for *confirmed* security issues. Mozilla confirmed a handful. Doesn't that imply that our advisory should have covered every thing Firefox fixed between versions? And if so, should we note everything, even if it doesn't *appear* to be a security issue? Just in case? Now on the one hand, you're saying we waited five weeks - when in fact we didn't, we released an advisory within a day of discovering that TBB was being targeted, which is different from Firefox generally I might add. We did also note with the release of 3.0alpha2 that it included security and stability fixes as we often do when we bump Firefox. So clearly between hey, upgrade and exploit discovered there is a middle ground. I'm confused by the middle ground you have chosen. It doesn't seem that we should wait until exploits are in the wild to note the security features of new releases (which we didn't, but we didn't issue an advisory for every Firefox issue), and yet, if an exploit is discovered, we should post an advisory that specifically addresses what we know about it, no? Wait until the NSA exploits an innumerable amount of Tor users and then quickly write an advisory for a bug that was quietly fixed without a warning from Tor five weeks but still exploited? This is not accurate. We heard about attempts at exploitation and within ~24hrs we released an advisory - we had already released fixed code a ~month before exploitation was found in the wild. Please do not mix up the time-line. To restate: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) The exploit was found in the wild on last weekend, I learned about it on or around August 4th. Please note that our patched versions were released nearly a month before this was found in the wild. There is no reason to support the conclusion that we silently fixed anything in response to an exploit. Please consider that your statement is entirely unsupported by evidence, Nadim. I could be mistaken. Where's the advisory that was issued the day after, that mentions that a critical Tor Browser vulnerability was fixed? Once we triaged the bug with Mozilla - both Tor and Mozilla posted updates: https://blog.mozilla.org/security/2013/08/04/investigating-security-vulnerability-report/ https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable We even posted a blog before we had all the details: https://blog.torproject.org/blog/hidden-services-current-events-and-freedom-hosting We also
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
intrigeri: Hi, Maxim Kammerer wrote (06 Aug 2013 09:52:36 GMT) : Tails references upstream advisories, or at least did so in the past. https://tails.boum.org/security/Numerous_security_holes_in_0.18/ Right, and we have no plan to stop doing this. What we've been doing for years when releasing a new Tails that fixes security issues (that is, basically every single one we've put out) is: 1. Users are told your version of Tails has known security issue on startup if needed; this one has a link to a security announce like the one Maxim pointed to. Seems reasonable. 2. We issue a release announcement, such as https://tails.boum.org/news/version_0.19/, that starts with All users must upgrade as soon as possible, but doesn't point to the corresponding security advisory. After reading this thread, I wonder if we should perhaps change this, and have this sentence link to the security advisory. I tend to think that cross linking is a good idea. All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
konfku...@riseup.net: Jacob Appelbaum: I like this idea - though I wonder how users would feel about it? Will they read it? Should it be our own RSS feed or an RSS feed of Mozilla's data? I don't like the idea. You need to worry about the upgrading behavior of casual users of TBB, who aren't going to bother to read advisories. Republishing advisories takes a lot of your valuable time. Added to that, every fucking tiny crash-bug in Firefox may grow to a full-blown exploit like we've seen. I tend to agree with this problem - almost any little bug can turn into an anonymity or security issue. :( The people that do read the advisories, can find them at the Firefox ESR advisory page (https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html). I do think you might want to bother to link to that list of vulnerabilities when releasing a new version of TBB with an security-updated Firefox. I also like the approach of the TAILS project. They just start every single release announcement with 'Numerous security bugs found in TAILS X.XX', which makes it crystal clear for the average user they need to upgrade. Every time. I think linking to https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html is a good idea. I've emailed some people about it - I think it should go into the ChangeLog. Also: please make separate blog posts for regular and alpha releases. It's been confusing before. Make sure the regular release sits on top on the blog listing. Good idea. Let me propose the announcement of June 26th as I would've (retrospectively) liked to see it: Subject: Security release. New Tor Browser Bundles. Body: All of the Tor Browser Bundles have been updated with the new Firefox 17.0.7esr. This includes fixes to a href=https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html;8 vulnerabilities/a, of which 4 have critical impact, and 4 have high impact. We bstrongly/b urge you to update to the latest version of the Tor Browser Bundle (2.3.25-10) as soon as possible. [continue with download-easy link and list of updates] Sounds very reasonable. Nadim Kobeissi: How am I only interested in slinging mud?! How are you even allowed to adopt a tone like this while doing your job as an advocate for Tor? I'm simply trying to advocate for Tor not waiting five weeks before releasing an advisory next time! Comments like this are really just not acceptable, Jake. Nadim, you need to calm the fuck down. Take a deep breath, re-read your own emails, and consider whether you need to apologize for your unproductive stampede. Our interactions don't need to be so stressful. Perhaps we'll all be calmer in the future... All the best, Jacob -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
But, this is the Firefox / Tor Browser Bundle exploit. The question is how FBI gained access to Freedom Hosting? What kind of exploits did they use? Pavol On Mon, Aug 05, 2013 at 09:08:49PM -0500, Kyle Maxwell wrote: According to THN[0] and several linked supporting sites from there (particularly notable are analyses from Kenneth Buckler[1] and Vlad Tsyrklevich[2]), the payload delivered the MAC address and Windows hostname to 65.222.202.54[3]. I've read in public sources that that address is assigned to SAIC but I have not seen any hard data on that. [0]: http://thehackernews.com/2013/08/Firefox-Exploit-Tor-Network-child-pornography-Freedom-Hosting.html [1]: https://code.google.com/p/caffsec-malware-analysis/source/browse/trunk/TorFreedomHosting/ [2]: http://tsyrklevich.net/tbb_payload.txt On Mon, Aug 5, 2013 at 8:22 PM, liberationt...@lewman.us wrote: On Mon, Aug 05, 2013 at 06:18:02PM -0400, r...@privacymaverick.com wrote 0.6K bytes in 0 lines about: : Does anybody have any indication on how the alleged operator of : Freedom Hosting was identified. Everybody seems to be focusing on : the javascript exploit but from what I've read, it appears that was : placed on the server after the alleged operator was taken down and : the operation compromised, or is my timing off? This is far more interesting to me than anything else. I've been wondering the same thing. -- @kylemaxwell -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- __ [Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542] -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
In fact, I wrote the advisory in question and generally write all of them (with input from Mozilla developers and other security team members). Al -- Al Billings http://makehacklearn.org On Tuesday, August 6, 2013 at 2:30 AM, Jacob Appelbaum wrote: Mozilla issued an updated blog post in the last day or so because of us contacting them. They clarified the specific issue around the same time as us. Al has already pointed this out - he works at Mozilla, so I suppose he seems to agree that we don't need to copy every advisory they write into our release notes. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Except this issue was a Firefox issue, fixed in ESR 17.0.7 and which we had posted an advisory for six weeks ago today. So, yes, you're asking Tor to copy and paste Firefox advisories. The issue wasn't a Tor-specific issue except that the way it was being spread targeted the TBB. It was a Firefox security issue, fixed in the last release. The people affected are those who hadn't gotten current. Al -- Al Billings http://makehacklearn.org On Tuesday, August 6, 2013 at 2:45 AM, Nadim Kobeissi wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised: I LOVE NADIM AND JAKE
GRAPPA! On Tue, Aug 6, 2013 at 12:51 PM, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Because that's become a trolling-engagement thread, i cannot resist to hijack it. I LOVE NADIM AND JAKE!** -naif ** Especially when they engage in trolling Il 8/6/13 12:32 PM, Jacob Appelbaum ha scritto: -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- *Note: *I am slowly extricating myself from Gmail. Please change your address books to: jilliancy...@riseup.net or jill...@eff.org. US: +1-857-891-4244 | NL: +31-657086088 site: jilliancyork.com http://jilliancyork.com/* | * twitter: @jilliancyork* * We must not be afraid of dreaming the seemingly impossible if we want the seemingly impossible to become a reality - *Vaclav Havel* -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tuesday, August 6, 2013 at 9:58 AM, Brian Conley wrote: Al, I'm not a developer, so please bear with me. Do you disagree that TBB is forked software? That depends on your definition. They aren't taking a fork of Firefox and running off with it for a year or two. They are (and I don't know the process) either forking each ESR release or applying our ongoing ESR patches to an ESR line. In either case, I think of it as Firefox ESR + Tor patches, not really as a fork. If I fork Firefox and build my own browser from there, do I have no responsibility to my users to fix bugs that originated in your original code, now that my codebase is separate from yours? Except they did that and do that. That isn't the issue here. The bug was fixed six weeks ago. TBB took that fix. The users that got exploited were *not* running the current version. Firefox assigns CVEs and issues advisories for any externally reported security issue we fix and for internally reported issues that are not simply memory corruption or crashes. There is no point in the Tor folks cutting and pasting our advisories onto their site. They *may* wish to link to our advisories on our site but that's up to them. Al-- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised: I LOVE NADIM AND JAKE
No, it really is one of those times, at least for me. :D On Tue, Aug 6, 2013 at 6:44 AM, Griffin Boyce griffinbo...@gmail.com wrote: I must admit, it can be entertaining at times. (now is not one of those times). ;3 Griffin On 8/6/13, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Because that's become a trolling-engagement thread, i cannot resist to hijack it. I LOVE NADIM AND JAKE!** -naif ** Especially when they engage in trolling Il 8/6/13 12:32 PM, Jacob Appelbaum ha scritto: -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Just another hacker in the City of Spies. #Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de My posts, while frequently amusing, are not representative of the thoughts of my employer. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2013 10:18 AM, Pavol Luptak wrote: The question is how FBI gained access to Freedom Hosting? What kind of exploits did they use? Freedom Hosting offered web hosting services to people that asked for it, yes? A hypothesis I've seen floating around (without evidence, that's all it is) is this: The FBI asked for and received web space on Freedom Hosting. They uploaded an app that they knew had a couple of vulnerabilities that allowed for server side code execution and used them to compromise other sites on that machine. No need to send ninjas to raid the cookie jar when you can say, Mother, may I? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Livin' la vida alpha test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIBNJAACgkQO9j/K4B7F8GoOgCg6tLxg4LDf08CX64XsLTBQvlj kmQAn34OwraBqPwY8EH+rt2O1QLd6zC8 =eZ9N -END PGP SIGNATURE- -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
When the user's version is outdated you already display an update notice. You could add those items from https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html that apply to the current version. Listing particular vulnerabilities makes it clear that you actually should update and that it isn't just a superfluous notice that's just for annoying the user. I wouldn't duplicate the actual advisories, but listing them is a good idea IMO. Perhaps something like: --- This version of TOR Browser is based on Firefox ESR 17.0.6. You need to upgrade to fix the following security issues: Fixed in Firefox ESR 17.0.7 MFSA 2013-59 XrayWrappers can be bypassed to run user defined methods in a privileged context MFSA 2013-56 PreserveWrapper has inconsistent behavior MFSA 2013-55 SVG filters can lead to information disclosure MFSA 2013-54 Data in the body of XHR HEAD requests leads to CSRF attacks MFSA 2013-53 Execution of unmapped memory through onreadystatechange event MFSA 2013-51 Privileged content access and execution via XBL MFSA 2013-50 Memory corruption found using Address Sanitizer MFSA 2013-49 Miscellaneous memory safety hazards (rv:22.0 / rv:17.0.7) - (With links to Mozilla's advisories and red-orange-yellow highlighting just like in the original page) -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised: I LOVE NADIM AND JAKE
Jillian C. York jilliancy...@gmail.com schrieb: GRAPPA! On Tue, Aug 6, 2013 at 12:51 PM, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Because that's become a trolling-engagement thread, i cannot resist to hijack it. I LOVE NADIM AND JAKE!** -naif ** Especially when they engage in trolling Il 8/6/13 12:32 PM, Jacob Appelbaum ha scritto: -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- *Note: *I am slowly extricating myself from Gmail. Please change your address books to: jilliancy...@riseup.net or jill...@eff.org. US: +1-857-891-4244 | NL: +31-657086088 site: jilliancyork.com http://jilliancyork.com/* | * twitter: @jilliancyork* * We must not be afraid of dreaming the seemingly impossible if we want the seemingly impossible to become a reality - *Vaclav Havel* -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech The dogs! #OHM2013 -- Sent from my mobile -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] [drone-list] [nodrones] what can I do ?
- Forwarded message from Robert Naiman nai...@justforeignpolicy.org - Date: Mon, 5 Aug 2013 14:23:36 -0500 From: Robert Naiman nai...@justforeignpolicy.org To: malachy kilbride malachykilbr...@yahoo.com Cc: No Drones List Serv nodro...@lists.riseup.net, David Soumis david...@charter.net Subject: Re: [drone-list] [nodrones] what can I do ? Reply-To: Robert Naiman nai...@justforeignpolicy.org, drone-list drone-l...@lists.stanford.edu I don't deny at all the difference you point out between issues where the primary impact is on Americans vs. the primary impact is on foreigners, not at all. That is a huge and crucial - and I think, permanent - fact of the terrain. My point was not that it's easy, all we have to do is emulate NSA. My point was that NSA shows it's possible through engagement to make the system move. It's certainly worth noting that far and away the most friction has been generated so far around the issue of drone strikes on Americans. That was the marquee issue of the Rand Paul filibuster, That has been the marquee issue of the ACLU strategy. Arguably, the events of the last two years have significantly vindicated this strategy - that's what has worked the best to throw mud on the policy in mainstream debate. And there is a big spillover effect on making the whole policy controversial. I think we should try to learn from the Congressional strategy and tactics of people who are doing better than we are, even if our issues have different dynamics. I think most people who care about NSA spying and are politically engaged would say that the Amash-Conyers amendment was a spectacular success - going from apparently almost no controversy to almost passing on the floor of the House in the space of about a month or so. So, it's worth noting: what did the Amash-Conyers amendment try to do? Did it try to repeal the Patriot Act? Did it try to shut down the NSA? No. It tried to defund *one controversial thing* that the NSA is doing. So, here is a question to which I do not know the answer. But I think it's a good question that we should be trying to figure out. What is the analogue of the Amash-Conyers NSA amendment on drone strikes? What's the thing that could get us on to the playing field of mainstream debate? On Fri, Aug 2, 2013 at 9:03 PM, malachy kilbride malachykilbr...@yahoo.comwrote: One thing I wonder about is how we get congress to respond to those of us against killer drones? How do we get a critical mass of people against the killer drones? Killer drones versus the NSA issue isn't a good comparison. Comparing and contrasting the Bradley Manning v. Edward Snowden is a better way to look at it. Polling shows the surveillance and spying revealed by Snowden resonates more with Americans versus the whistle-blowing of Bradley Manning. Americans are not behind Manning the way they are sympathetic to Snowden. Americans seem to be responding more to the spying drones (on them!) as opposed to the killer drones used against those who have darker skin and live in Muslim countries. We are dealing with issues like race and anti-Muslim sentiment and what happens to Americans as opposed to what happens to non-Americans. This is in part what led us into war and occupation in Afghanistan and Iraq and allows the killer drone strikes to take place in Yemen, Pakistan, Sudan, Afghanistan, and Iraq. I agree that congress will respond to our concerns about the killer drones but only if our numbers are greater than now. So, how do we get these numbers to join us when we are dealing with prejudice and indifference? How do we create a narrative that appeals to apparently what Americans do respond to, their self interest? They don't want the spying on Americans but they do want the drones on the borders seeking out Mexicans and then they don't seem to be too upset by the killer drone strikes in various countries used against Muslims. So what is the argument we use to get more people to join us in pressuring congress? *From:* Robert Naiman nai...@justforeignpolicy.org *To:* David Soumis david...@charter.net *Cc:* No Drones List Serv nodro...@lists.riseup.net *Sent:* Friday, August 2, 2013 6:43 PM *Subject:* Re: [nodrones] what can I do ? Getting more people to contact their legislators would be really helpful. Look what happened with the NSA issue. A couple of months ago, the political terrain was not so different from the drone issue. A month after the Snowden revelations, the status quo NSA policy was almost defeated on the floor of the House. What happened in between the Snowden revelations and the House vote? People contacted their legislators. On Fri, Aug 2, 2013 at 4:55 PM, David Soumis david...@charter.net wrote: I'm hearing this more and more from people. What can we do to help? The obvious is to join us to hold signs, to attend vigils, and so forth, but I think it has to go well beyond that. Contacting legislators to demand they put
[liberationtech] Secrecy News -- 08/06/13
- Forwarded message from Steven Aftergood safterg...@fas.org - Date: Tue, 06 Aug 2013 06:48:11 -0700 From: Steven Aftergood safterg...@fas.org To: eu...@leitl.org Subject: Secrecy News -- 08/06/13 Reply-To: safterg...@fas.org X-Mailer-LID: 1 X-Mailer-RecptId: 399049 X-Mailer-SID: 1866 X-Mailer-Sent-By: 2 Format Note: If you cannot easily read the text below, or you prefer to receive Secrecy News in another format, please reply to this email to let us know. SECRECY NEWS from the FAS Project on Government Secrecy Volume 2013, Issue No. 72 August 6, 2013 Secrecy News Blog: http://blogs.fas.org/secrecy/ ** MILITARY TESTS DATA MINING OF SOCIAL MEDIA FOR SPECIAL OPS ** U.S. TRADE POLICY, AND MORE FROM CRS MILITARY TESTS DATA MINING OF SOCIAL MEDIA FOR SPECIAL OPS The U.S. military has been investigating the use of sophisticated data mining tools to probe social media and other open sources in order to support military operations against money laundering, drug trafficking, terrorism and other threats. But the window for doing so may be closing as the social media landscape changes, according to an internal assessment. U.S. Special Operations Command (SOCOM) National Capital Region (NCR) conducted a series of experiments over the past year under the rubric QUANTUM LEAP that was intended to test non-traditional tools and techniques to advance the SOCOM mission. An after-action report on the first experiment said it was successful in identifying strategies and techniques for exploiting open sources of information, particularly social media, in support of a counter threat finance mission. Counter threat finance refers to efforts to disrupt an adversary's finances. A copy of the SOCOM NCR report was obtained by Secrecy News. See Project QUANTUM LEAP: After Action Report, 12 September 2012: http://www.fas.org/irp/eprint/quantum.pdf Major lessons learned were the pronounced utility of social media in exploiting human networks, including networks in which individual members actively seek to limit their exposure to the internet and social media..., the report said. The QUANTUM LEAP project, which did not utilize classified intelligence, relied heavily on participation by private sector firms identified in the report, who demonstrated tools they had developed to enhance the ability to discover relationships, human networks, and geospatial features from open source data. A tool called Social Bubble permitted the search of Twitter-related content to explore human networks associated with the [counter threat finance] scenario and enabled identification of various entities... associated with the moneylaundering network. A tool called Recon was used to reconstruct source documents from a raw data stream. Another tool served to collect large quantities of data from the 'deep web', or sources which are accessible via the internet but not necessarily indexed or linked via a world wide web page. And another called Semantica is capable of ingesting structured and semi-structured data and displaying it in a 'triplet' format, e.g. two entities and a relationship, such as [A is owned by B]. More than 200 additional open-source tools and sources were identified relevant to counter threat finance, the SOCOM report said. The report said that as valuable as the opportunity created by new techniques for data mining of open sources appears to be, it may prove to be transient. We are currently in a 'window' of opportunity for exploitation of social media sources for application to CTF [counter threat finance] or other SOCOM NCR missions. This window could be as narrow as 18-24 months before the social media phenomenon transforms. This future transformation is unknown and could offer additional opportunities, or existing opportunities could be closed, but the only thing that is certain is that there will continue to be rapid change. There are also unresolved legal issues. Legal review of the appropriate use and application of social media data is in its infancy. Social media is transforming notions of privacy and distinctions between personally identifiable information (PII) and self-reported public information will have to be established by precedent in case law, the report said. Almost all information relevant to the QUANTUM LEAP experiment has a locative context [revealing the location of the source]. Location based services (LBS) are becoming integrated into every facet of our lives and are becoming much more accepted. There is a cultural/generational component to acceptance of LBS in social media, the report said. SOCOM Public Affairs did not respond to requests for comment or further information about the project, and the report describing the effort (labeled draft) has not been formally released. However, the report was kept unclassified, facilitating its dissemination and discussion among the interested public. Meanwhile, the future of SOCOM National Capital Region is itself
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Plausible and clever in it's simplicity. Moral of the story: host your own server. Anybody know what ever happened to Publius[1]? Did that concept ever go anywhere? 1 http://www.cs.nyu.edu/waldman/publius/ On 8/6/2013 1:38 PM, The Doctor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2013 10:18 AM, Pavol Luptak wrote: The question is how FBI gained access to Freedom Hosting? What kind of exploits did they use? Freedom Hosting offered web hosting services to people that asked for it, yes? A hypothesis I've seen floating around (without evidence, that's all it is) is this: The FBI asked for and received web space on Freedom Hosting. They uploaded an app that they knew had a couple of vulnerabilities that allowed for server side code execution and used them to compromise other sites on that machine. No need to send ninjas to raid the cookie jar when you can say, Mother, may I? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Livin' la vida alpha test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIBNJAACgkQO9j/K4B7F8GoOgCg6tLxg4LDf08CX64XsLTBQvlj kmQAn34OwraBqPwY8EH+rt2O1QLd6zC8 =eZ9N -END PGP SIGNATURE- -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech *R. Jason Cronk, Esq., CIPP/US* /Privacy Engineering Consultant/, *Enterprivacy Consulting Group* enterprivacy.com * phone: (828) 4RJCESQ * twitter: @privacymaverick.com * blog: http://blog.privacymaverick.com -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 12:28 PM, R. Jason Cronk r...@privacymaverick.com wrote: ... Anybody know what ever happened to Publius[1]? Did that concept ever go anywhere? 1 http://www.cs.nyu.edu/waldman/publius/ wow, that takes me back. i remember running publius when it launched back in the DeCSS days. from what i recall there was a subsequent tangler censorship resistance project, then nothing. curious if anyone else know more... -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
* Jacob Appelbaum: This is not accurate. We heard about attempts at exploitation and within ~24hrs we released an advisory - we had already released fixed code a ~month before exploitation was found in the wild. Please do not mix up the time-line. To restate: 2.3.25-10 (released June 26 2013) This was released with the following announcement (there wasn't a posting to the tor-announce mailing list): | All of the Tor Browser Bundles have been updated with the new | Firefox 17.0.7esr. There is also a new Tor 0.2.4.14-alpha release | and all of the packages have been updated with that as well. | | https://www.torproject.org/download/download-easy | | Tor Browser Bundle (2.3.25-10) | | Update Firefox to 17.0.7esr | Update zlib to 1.2.8 | Update HTTPS Everywhere to 3.2.2 | Update NoScript to 2.6.6.6 https://blog.torproject.org/blog/new-tor-browser-bundles-and-tor-02414-alpha-packages I'm not sure if Tor Browser Bundle users (or even Firefox users) realize that for some time now, almost all Firefox updates from Mozilla contain security-relevant fixes. But noting the security aspect each time your switch to a newer Firefox ESR version can't hurt. On the other hand, those who don't already know this are probably difficult to reach without automated updates. (Automated updates are a mixed blessing because they could invite court orders to roll out specific versions to certain users.) -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 3:11 PM, Florian Weimer f...@deneb.enyo.de wrote: (Automated updates are a mixed blessing because they could invite court orders to roll out specific versions to certain users.) No crap. _please_ don't deploy automatic updates in a sensitive environment like this without at least quorum signatures (like gitian downloader) and timed quarantine with negative signatures (harder to make strong absent a jamming proof network). -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
Hi folks, Thank you very much for your great feedback on the previous version. The next version is now up at http://passlok.com, which redirects to https://passlok.site44.com This may come in handy now that there are problems with Tor, since PassLok allows you to go to any computer to do encrypted mail, because there is nothing to install. This is what PassLok was designed to do. The other unforeseen endorsement came from the recent Black Hat conference. Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel encouraged everyone to base their public key cryptosystems on elliptic curves rather than RSA. Here's a link on this: http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/ In addition to needing nothing to install and doing 521-bit elliptic curves on top of AES-256, which PassLok has done for a while, here's the new stuff in version 1.3: 1. Much more resistant to dictionary attack and rainbow tables, thanks to variable key stretching using PBKDF2. PassLok analyzes your key and applies more iterations if it feels your key is less than perfect, up to a whopping 200,000 iterations for lousy keys. Since keys made in version 1.2 are no longer compatible, this prompts upping the version to 1.3. 2. Increased resistance to tampering. Now there is a link to a youtube video of me reading the SHA256 hash of the source code. This is going to be darn hard to fake by an attacker. 3. There's a detailed PDF manual. It is invoked from the help screen. 4. The built-in subliminal channel has been extended to signatures as well as encrypted messages. It is free, so please feel free to use it and tell me how to improve it further. The link is repeated at the bottom -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz r...@iit.edu wrote:
Hi folks,
Thank you very much for your great feedback on the previous version. The
next version is now up at http://passlok.com, which redirects to
https://passlok.site44.com
This may come in handy now that there are problems with Tor, since PassLok
allows you to go to any computer to do encrypted mail, because there is
nothing to install. This is what PassLok was designed to do.
The other unforeseen endorsement came from the recent Black Hat conference.
Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel
encouraged everyone to base their public key cryptosystems on elliptic
curves rather than RSA. Here's a link on this:
http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/
Wait. You are using vague popular press FUD about RSA to promote a
website hosted JS encryption tool? Really?
Your code generates random values like this:
sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
a.clientY || a.offsetY || 0], 2, mouse)
sjcl.random.addEntropy((new Date).valueOf(), 2, loadtime)
try {
var s = new Uint32Array(32);
crypto.getRandomValues(s);
sjcl.random.addEntropy(s, 1024, crypto['getRandomValues'])
} catch (t) {}
Meaning that if it's used someplace where crypto.getRandomValues()
doesn't exist, it has only pure snake-oil-extract randomness.
Really
If the randomness is poor, the nonce used in ECDSA will be predictable
and the private key will be recoverable.
This isn't to say I've audited any of it, I just grepped for a couple
likely mistakes. Part of the JS code has been whitespace compressed, I
consider it unauditable.
up to a whopping
200,000 iterations for lousy keys. Since keys made in version 1.2 are no
longer compatible, this prompts upping the version to 1.3.
So, not implemented in slow-as-dirt JS 200,000 iterations should take
a random desktop cpu about 100ms or so. This is hardly wopping. It's
not far from the minimum I'd start with, for all keys not just weak
ones. Generally user provided keys are a security disaster and should
be avoided wherever it's possible, strengthening or no. Humans are
horrific entropy sources and really can't self assess how bad they
are.
--
Liberationtech list is public and archives are searchable on Google. Too many
emails? Unsubscribe, change to digest, or change password by emailing moderator
at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz r...@iit.edu wrote:
Hi folks,
Thank you very much for your great feedback on the previous version. The
next version is now up at http://passlok.com, which redirects to
https://passlok.site44.com
This may come in handy now that there are problems with Tor, since PassLok
allows you to go to any computer to do encrypted mail, because there is
nothing to install. This is what PassLok was designed to do.
The other unforeseen endorsement came from the recent Black Hat conference.
Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel
encouraged everyone to base their public key cryptosystems on elliptic
curves rather than RSA. Here's a link on this:
http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/
Wait. You are using vague popular press FUD about RSA to promote a
website hosted JS encryption tool? Really?
Your code generates random values like this:
sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
a.clientY || a.offsetY || 0], 2, mouse)
sjcl.random.addEntropy((new Date).valueOf(), 2, loadtime)
try {
var s = new Uint32Array(32);
crypto.getRandomValues(s);
sjcl.random.addEntropy(s, 1024, crypto['getRandomValues'])
} catch (t) {}
Meaning that if it's used someplace where crypto.getRandomValues()
doesn't exist, it has only pure snake-oil-extract randomness.
Really
If the randomness is poor, the nonce used in ECDSA will be predictable
and the private key will be recoverable.
This isn't to say I've audited any of it, I just grepped for a couple
likely mistakes. Part of the JS code has been whitespace compressed, I
consider it unauditable.
up to a whopping
200,000 iterations for lousy keys. Since keys made in version 1.2 are no
longer compatible, this prompts upping the version to 1.3.
So, not implemented in slow-as-dirt JS 200,000 iterations should take
a random desktop cpu about 100ms or so. This is hardly wopping. It's
not far from the minimum I'd start with, for all keys not just weak
ones. Generally user provided keys are a security disaster and should
be avoided wherever it's possible, strengthening or no. Humans are
horrific entropy sources and really can't self assess how bad they
are.
--
Liberationtech list is public and archives are searchable on Google. Too many
emails? Unsubscribe, change to digest, or change password by emailing moderator
at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
We're understaffed, so we tend to pick the few things we might accomplish and writing such advisory emails is weird unless there is an exceptional event. Firefox bugs and corresponding updates are not exceptional events. :( Pardon me, But it does seem that this one was. No? Sent with AquaMail for Android http://www.aqua-mail.com -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] NSA Xkeyscore VPN reference question
On Thu, Aug 1, 2013 at 11:26 AM, Julian Oliver jul...@julianoliver.com wrote: It looks very bogus to me precisely because it's so general, like aspects of some other slides. Perhaps the slide is a where we want to be in 5 years rather than what we can do now. Especially since that deck is literally 6 years old (January 2007, per the title slide). -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 06, 2013 at 01:50:31PM +0300, Nadim Kobeissi wrote: Yes, to be absolutely clear, I think Tor should issue advisories for confirmed security issues in Tor Browser, since Tor Browser is a fork of Firefox and is independently maintained. This is exactly what Tor did this time, except next time you shouldn't wait five weeks for the situation to explode. This is insane advice. Every ESR point release of firefox 17 has fixed multiple CVEs. Your advice would have them doing a RED BLINKING LETTERS blogpost on *every* TBB release. This is not sustainable and will create security fatigue in users, exactly similar to how SSL warning dialogs trained everybody to just click accept back in the ninetys and the bad old oughties. We have to move past the bug the user again model of security system deployment. -andy -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 10:19 PM, Andy Isaacson a...@hexapodia.org wrote: We have to move past the bug the user again model of security system deployment. In the general sense, yes. Silent automatic updates are a truly good thing in many use cases and environments. However, in the case where the user has an explicitly more detailed threat model - the sort of case where Tor may be an important component of the overall infrastructure - requiring said user to exercise some situational awareness is de rigeur. Tor itself recognizes this principle quite clearly on its download page: Want Tor to really work? You need to change some of your habits, as some things won't work exactly as you are used to. This is proper and correct, because use cases that involve using Tor as more than just a poor man's VPN[0] require correspondingly greater thought and practice of solid operational security principles. This means, yes, taking active steps to safeguard your browser, from patching to not using Javascript to thinking about when and what you write. I don't want to delve too far into victim-blaming here, but it's clear that users caught by this *particular* operation were relatively low-hanging fruit. -- @kylemaxwell -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Anonymity Smackdown: NSA vs. Tor
So Robert Graham, professional security dude and sometimes friendly troll, posted a blog article[0] about weaknesses in Tor, centered on likely attacks by the NSA. The key, obviously, is the primary assertion that the NSA runs lots of Tor nodes. I've seen this assertion before, and while it's certainly a reasonable assumption, I don't know if anybody outside the NSA actually has hard evidence for that. Runa Sandvik's excellent talk[1] at DEF CON 21 started to address this, but clearly more work remains to be done here. Assuming that assertion holds, the architectural criticisms start to matter more: 3 hops, 1024 bit RSA keys, etc. Other criticisms are really about operational security: sending non-encrypted traffic (e.g. HTTP) over Tor that can be monitored at the exit node or running the Tor proxy on the same system as the browser. Actually, that latter is arguably an architectural problem as well, with experiments like Whonix and Portal of Pi[2] trying to address this. These are important considerations for users who use Tor as more than just a free VPN and have a much more complicated threat model. [0]: http://blog.erratasec.com/2013/08/anonymity-smackdown-nsa-vs-tor.html [1]: https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Sandvik [2]: https://github.com/grugq/PORTALofPi -- @kylemaxwell -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Moratorium on Snark
Tonight, I managed the final leg of my journey without being hassled by security. This unprecedented event has prompted me to consider a snark-free future. Feel like agreeing to not snark at each other? It's not really productive, and we all seem to snark at each other at the worst possible times. ~Griffin -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On 2013-08-06, at 4:49 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 1:23 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 12:55 PM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-08-06, at 11:46 AM, Al Billings alb...@openbuddha.com wrote: Nadim you seem confused by how this works. Tor doesn't need to issue advisories for Firefox issues. We, at Mozilla, already issue them. Perhaps they can link to them clearly but if you want to know about security issues Mozilla fixes in Firefox, you're best served by reading Mozilla advisories. There's not much point in duplicating them on a second site. Tor would be better served by writing advisories for its own, unique, security fixes. Tor doesn't need to issue advisories for Firefox issues. Tor needs to issue advisories for Tor Browser issues, and not five weeks later when s**t hits the fan. I really don't think one can reasonably disagree with the above statement. Tor Browser is a Firefox fork. Should we issue a single advisory for each possible security issue that Firefox has already noted in their change log? Each confirmed security issue? Should we ask for a second CVE to cover each CVE they receive? What's the alternative, Jake? That was a list of choices and you didn't choose one. Please choose one or more - though not all of them make sense when put together. It was a question and well, your answer isn't much of an answer. Yes, to be absolutely clear, I think Tor should issue advisories for confirmed security issues in Tor Browser, since Tor Browser is a fork of Firefox and is independently maintained. This is exactly what Tor did this time, except next time you shouldn't wait five weeks for the situation to explode. This is where the confusion comes into play, I think. Please note the advisory we released this week: https://lists.torproject.org/pipermail/tor-announce/2013-August/89.html We specifically address the one thing we *know* that is being exploited and we note that there are other issues, though we don't go into depth as upgrading is the only path forward. Now note the Mozilla security issues for the Firefox ESR releases: https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html You're on the one hand saying that we did the right thing and on the other, you're saying that we should issue an advisory for *confirmed* security issues. Mozilla confirmed a handful. Doesn't that imply that our advisory should have covered every thing Firefox fixed between versions? And if so, should we note everything, even if it doesn't *appear* to be a security issue? Just in case? Now on the one hand, you're saying we waited five weeks - when in fact we didn't, we released an advisory within a day of discovering that TBB was being targeted, which is different from Firefox generally I might add. We did also note with the release of 3.0alpha2 that it included security and stability fixes as we often do when we bump Firefox. So clearly between hey, upgrade and exploit discovered there is a middle ground. I'm confused by the middle ground you have chosen. It doesn't seem that we should wait until exploits are in the wild to note the security features of new releases (which we didn't, but we didn't issue an advisory for every Firefox issue), and yet, if an exploit is discovered, we should post an advisory that specifically addresses what we know about it, no? Wait until the NSA exploits an innumerable amount of Tor users and then quickly write an advisory for a bug that was quietly fixed without a warning from Tor five weeks but still exploited? This is not accurate. We heard about attempts at exploitation and within ~24hrs we released an advisory - we had already released fixed code a ~month before exploitation was found in the wild. Please do not mix up the time-line. To restate: 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June 30 2013) The exploit was found in the wild on last weekend, I learned about it on or around August 4th. Please note that our patched versions were released nearly a month before this was found in the wild. There is no reason to support the conclusion that we silently fixed anything in response to an exploit. Please consider that your statement is entirely unsupported by evidence, Nadim. I could be mistaken. Where's the advisory that was issued the day after, that mentions that a critical Tor Browser vulnerability was fixed? Once we triaged the bug with Mozilla - both Tor and Mozilla posted updates: https://blog.mozilla.org/security/2013/08/04/investigating-security-vulnerability-report/ https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable You will note that this was
Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
On Wed, Aug 07, 2013 at 07:20:21AM +0300, Nadim Kobeissi wrote: You will note that this was posted recently. However, 5 weeks ago, Mozilla posted a security advisory for Firefox and fixed the issue. Tor then updated the Tor Browser Bundle with the fix, 5 weeks ago, *without releasing a security advisory.* You released the security advisory after shit hit the fan, this week Just to clarify: the security advisory I wrote this week was telling users that an exploit had been seen in the wild, and explaining what we knew about that. This was not intended to be a five-weeks-late by-the-way-there-was-a-vulnerability announcement. We already told people, five weeks ago, to upgrade, and set the TBB homepage to tell them There is a security update available for the Tor Browser Bundle. Click here to go to the download page. The novel thing here was that a potential vulnerability, which Mozilla had described as This crash is potentially exploitable when they put out their fix, was actually exploitable in practice and was being actively exploited. The advisory was intended to make people aware of the new situation, and also collect some facts into one place. The advisory you released this week should have been released 5 weeks ago for Tor Browser, on the day Mozilla released an advisory for Firefox, and on the day you updated Tor Browser. I spoke with Roger and he in fact confirmed that no advisory was released by Tor five weeks ago when Tor fixed the vulnerability. Tor waited until the exploit was in the wild. We did in fact wait until the exploit was in the wild to tell people that the exploit was in the wild. How we (including the broader community) can keep users informed about the security state of their software is indeed a fine question to ponder. But it's not clear to me that this you didn't tell them yes we did well you should have told them differently format is the right way to make progress. (And we should also listen to folks like Andy, who point out that there's never going to be a simple answer. I've been involved in too many I wonder if that bug we just fixed is really exploitable, and how we should classify it discussions to believe that the predictions are always accurate -- and they can be inaccurate either by overestimating or by underestimating.) --Roger -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
