Re: [liberationtech] E-Voting
On 2016.11.15 02.57, Zacharia Gichiriri wrote: > Hi, > > Are there any countries that have implemented a form of mobile voting? > Is there any research on the potential, challenges and applicability of > mobile voting? > Considering the explosive growth of mobile phones across Africa, would > the use of mobile phones for elections (citizens voting through mobile > phones) improve election outcomes and transparency? Yes, there has been research done. The summary is "if you do this, forget about any chance of having a free and fair election, because it's hard not to end up accidentally hacking the election, let alone stopping anyone who might want to actively hack it". There's a decade or so of research on how bad just electronic voting is, and another decade of research on how bad mobile phone security is. The combination is geometrically worse. Paper is good. People watching other people use paper has a pretty well understood set of failure models. The problems of electoral integrity and transparency are social and political ones, not technical ones, and if you add more technology without solving the social and political issues, all you're going to do is make a much more convenient crisis. E. -- Ideas are my favorite toys. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] New essay series
Hi folks, I've started a new series of Patreon-supported[1] essays, many of which will be relevant to folks here. The first one is up at http://dymaxion.org/essays/pleasestop.html. In it, I ask folks to stop writing secure messaging tools, not because we have too many of them (although there are too many not pushing the state of the art forward), but rather because we have so much else that we need written. E. 1: Patreon is a subscription service for supporting folks working independently. If you like this essay, you can subscribe to support future ones at https://patreon.com/dymaxion. -- Ideas are my favorite toys. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Reporta App???
As far as I can tell, Reporta is a grade A example of a large NGO with a reasonable degree of funding doing absolutely everything wrong in application development and potentially putting their users at real risk. IWMF has been completely unresponsive, but I'm hoping we can get some meaningful media coverage on the issue to press the point in this specific case, and also as an example to other organizations that may be tempted to put users in harms way. There are basic ethics around doing no harm that are not optional, and as far as I can tell, with this application IWMF has failed in every possible way. E. On 2015.09.30 21.29, Igor Ursu wrote: > who is tech team who built it? > is it open source? > code review? > why all the permissions needed? > data storage locations? acess? > why so much need for informations when opens? > why so much informations in policy? > > > Information Collected Automatically > We use tools, including third-party analytical software, to automatically > collect certain data about the device on which you use Reporta, including but > not limited to: (i) device properties, such as the device identifier; (ii) > the device operating system and firmware; (iii) mobile phone carrier; (iv) > geographical data such as country, region and/or city; (v) when and where you > activate Reporta; (vi) the manner in which you use Reporta; (vii) the > frequency with which you use Reporta to communicate with and issue alerts to > others; and (viii) other similar data. We may also use server log analysis > tools to gather and analyze information regarding errors experienced by > users. This information may be collected via several technologies, including > cookies. > The above information belongs to IWMF. > > USE OF PERSONALLY INDENTIFIABLE INFORMATION. > IWMF will collect Personally Identifiable Information from Reporta. IWMF may > use the Personally Identifiable Information you provide, separately or in > combination with other information IWMF collects, for the following purposes > (but not limited to such purposes): > To communicate with you about IWMF and your use of Reporta; > > To process the Check-in’s, Alerts, SOS messages and other communications you > make through Reporta (as defined in How to Use Reporta) and provide services > you have requested; > To alert you to upgrades, service updates, special offers and other > information about IWMF and the programs we offer; and > To administer promotions and surveys. > > We may also use the information you provide to operate and maintain Reporta > and to improve our effectiveness, content, services and communications with > you; to enforce the Terms of Use accompanying Reporta; and to detect and > protect against error, fraud and any other unauthorized or illegal activities. > -- Ideas are my favorite toys. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] The Future of Security Journalism
On 2015.01.26 21.06, J.M. Porup wrote: Here's my reply: Security Journalism, Full Speed Ahead! I’ll Go First https://medium.com/@toholdaquill/security-journalism-full-speed-ahead-34e490742056 What a shocking failure at understanding what she wrote. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] (n+1)sec = more privacy on the internet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.12.10 11.31, Dmitri Vitaliev wrote: Dear Libtech In recognition and celebration of Human Rights Day, eQualit.ie is proud to release the first public draft of a provably secure protocol for group messaging on the Internet https://learn.equalit.ie/wiki/Np1sec The protocol provides for end-to-end security of synchronous communications between any number of people. It is efficient and builds on recent advancements in cryptographic research. Security properties of (n+1)sec include: * Confidentiality: the conversation is not readable to an outsider * Forward secrecy: conversation history remains unreadable to an outsider even if participants’ encryption keys are compromised * Deniable authentication: Nobody can prove your participation in a chat * Authorship: A message recipient can be assured of the sender’s authenticity even if other participants in the room try to impersonate the sender * Room consistency: Group chat participants are confident that they are in the same room * Transcript consistency: Group chat participants are confident that they are seeing the same sequence of messages Hi! This is great news and I'm delighted to see a new effort in this space, especially one that's taken review seriously from the beginning. I'm curious, however, how the requirements for the protocol where arrived at. In particular, I notice that you're supporting group chat with no specific provision made for a moderator role to eject a participant from a chat room. When I've talked to users about their actual use of group chats, this is a consistent requirement and far more important than deniability, the utility of which is still unclear at best. Would you talk a bit about how you arrived at that list of properties and how moderator ejection will be implemented, assuming uncooperative clients? E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlSIkXoACgkQQwkE2RkM0wpfagD/b2VStN7R6VNHDr4ZEqvmTnTp lo2X4hKKX4SLDq2iaBQA/238TyDI/ZgGzgWT2bNGk3kq4xnFQj0fiRkv0oXzRYpl =hXFg -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Facebook available as a Tor hidden service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.31 21.46, The Doctor wrote: It may raise the hair on the backs of some of our necks, but protestors have been known to find one another and organize actions using Facebook. Facebook setting up a Tor hidden service would not facilitate anonymity (perhaps pseudnonymity, if one were to set up a dedicated FB account) but it would certainly help implement circumvention of traffic or DNS filtering. Much more important than organization is outreach. If you're trying to get a political message out, you have to go where the audience is, and that means Facebook as much as anywhere these days, despite the whole organic reach stupidity. It would be good for people publishing political messages on Facebook to retain the option of locational anonymity, even in cases where they're using an account under a real name. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlRUumkACgkQQwkE2RkM0wqnawD/Ze3T5Bf9FiiJLXAmCH8Uh22q C/twzML+5Bmou1VFmNMA/jOMfGExl5fbZKVgyqtHLel1jSfgjIT51Z3CwJ5zrtV0 =5jIa -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQyydsACgkQQwkE2RkM0wpV/QD/R+Iu4JCX/sp9/gOA+XF7oyts p29Jw9tl3mT7Jbq2VvEBAJjUR+HB0Qmgfs/gFuHdhx1sJWdHa/qGpAg6xIU2Ouvl =jcFs -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? If so, I'd love to see the research that you've done that justifies the feature set you've selected, because this would be a seriously amazing addition to the field (I'm completely sincere here). 95+% of the time when I see people talking about deniability, they have no direct field experience to back up their assertions of utility, and the arguments they make look exactly like yours. If you're going to contest my statement, feel free to provide reliable field data. Short of that, you're simply wrong here. You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. Again, field data or nothing. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQtWRkACgkQQwkE2RkM0wosIgD+P4NbMFYfFWk9c9oR2uP1pnWz 8FoePGWnDU9n38kEd6cA/j2ZvOtQGlUVlGnItrFBr0CFlqEK6F9srLPnZm6qKOss =3Tmh -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.02 20.39, Greg wrote: There are different types of deniable encryption systems, with very _different_ deniability properties. What you're failing to see here, I think, is that your adversary is almost never a cryptographer. You adversary is a goon who likes to crush fingers, who's heard a rumor that your tool lets people hide things from him. He doesn't like it when people hide things from him. He thinks you're hiding something from him. He's going to keep crushing your fingers until you prove to him that you aren't. You don't have that many fingers left. Unlike you, I've done my homework and researched the deniability properties of encryption systems and why some are better than others. Field outcomes aren't about math. That's the point I'm trying to make here. The precautionary principle and a Do No Harm approach to software development are incredibly important when looking at the requirements specification of security tools intended to be used in a hostile environment. I cannot stress this strongly enough. Real-world field experience is the only reasonable and reliable guide for determining the appropriate design of security systems; anything else is at best a amateur[1]. For novel capabilities, *careful* field testing in moderate risk environments is necessary to establish a baseline. Building a real loop with existing training programs to ensure that you get field feedback when systems are used is similarly critical. Building software because it's cool is fine, as are projects we do because we believe in them, but at a certain point, there's a bar. Recommending your tools for use in the field in hostile environments is that bar. Beyond that bar, we have an ethical obligation to attempt to act in a professional manner. E. [1]: I mean this in the literal sense of the word, not to be in any way demeaning. There are requirements for professionalism in this field; operational field outcomes reviews are as much a requirement as proper code review, cryptoanalytic review, UX testing, QA, and good documentation. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQttVsACgkQQwkE2RkM0woj9gD/c1eOZvCwwNcElcYKb9fHrIb6 KRnpWph84MhD9N8e9e0A/0UtT0GzwTTyFbI2h3l7jPjIsqnwRn3rmKgpx8DRX7L1 =oYU9 -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.02 21.37, Greg wrote: Have you read everything in the reddit r/security link I sent you? Of course not. It turns out I have other things to do than read voluminous ramblings by folks on Reddit who don't actually do field work. I'll add it to my queue for when I've got a slow Sunday. You have two possible defensible stances based on everything you have said so far: 1. Activists shouldn't encrypt any data whatsoever. 2. Activists should use Espionage-style PD if they are going to choose to use encryption. You have failed to demonstrate this in any way, other than by brute force assertion, appear to have no field experience, and frankly, it's not clear if you ever even had a real security audit or cryptographic review. Brute assertion for commercial products, in particular, tends to be indicative of a failure to understand real-world deployment constraints. As does naming something Espionage, but that's largely irrelevant. I'm going to stop responding to this thread from this point on, because it's clear to me that no further useful discussion will occur here. Everyone else, hopefully this exchange has been educational as far as the kinds of testing we should be seeing tools go through. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQtuu4ACgkQQwkE2RkM0wr+vgD/a4pHH9SKosesYRv8G6xfDyjA /JZ0CWTDXTfbpMGDH0sBAJrFO63qudSYMP2cjPs93Fp5/4nv51Xgg3QUrL+xMbN8 =rahm -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.28 04.15, Greg wrote: Dear Rory, See this list on ArsTechnica's forum: http://arstechnica.com/civis/viewtopic.php?f=21t=1245367 I work for Tao Effect LLC, our software is on that list, and you can read about how its plausible deniability compares to TrueCrypt's here (forgive this subreddit's insane color scheme): http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n In case anyone on this list wants a license, here's a code for 15% off: LIBERATIONTECH There are 10 of them and you can use them on espionageapp.com http://espionageapp.com/. They expire November 1st. While code available is nice, it's sadly not really sufficient to make this relevant for the activist world. Non-multiplatform tools aren't a replacement for Truecrypt, and having to pay for licenses makes your tool completely inaccessible to most folks in authoritarian regimes or in the majority world who may actually need it. Furthermore, when dealing with the exigencies of security in the field, having to deal with license keys at all imposes a serious overhead to expedient solutions in emergencies. And finally, the least useful part of Truecrypt is the deniability. There are very good reasons why tools that attempt to provide deniability may actually significantly harm field outcomes, something which developers seem to not understand. (Also, it's bloody hard to get right, and almost everyone fails, although I haven't looked at this solution in particular.) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQq0xAACgkQQwkE2RkM0wq0hwD/a/cWXFzWRDtBR9YtzxNvtZra zDovJhYWMG4mS/SIBjcBAIh6gCKBZOIXcPJ13TasQy9V3H/h4Gu0kIZz5eMBFGci =K6CP -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.30 18.01, Jonathan Wilkes wrote: Hi Eleanor, I understand the logic of the argument, but are there news stories about people being harmed in the field due specifically (or mainly) to deniability of the software they are using? (Or research on the topic, though I'm not sure how it could be a falsifiable or reproducible.) I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQrJRoACgkQQwkE2RkM0wohJQD/crteV0ZMLmZe5cbuNUgYrw45 FZYX657kGhcl0sYmfQMA/2YD3SBHWyqThFjWuF8xuhAh7BkQwEo3ouNchdAbBtml =2qRF -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.05.24 09.54, GALINDO Virginie wrote: Anyway, thanks for taking the time to share your view with us. You are pointing us to an interesting problem, that we discussed intensively. We are currently trying to see how to word warning to developers in the specification to encourage them to understand the web security big picture. That task is not easy due to the always-living side of the security/cryptography science. I find this approach a little worrying. While clearly warning developers is obviously preferable to *not* doing so, it's also been shown to be largely insufficient over the past 20-odd years. If the default behavior of a system is unsafe, developers will generally implement that behavior, regardless of what your documentation warns them to do. It would be better for the state of web security to provide a significantly more limited but default safe API. If there is no API, developers needing to solve related issues will roll their own and get it wrong -- the state we have now. If there is a safe API, they're more likely to make architectural choices on the basis of that API, because you've shaped the level of effort from either way I'm going to have to do everything to I can stay within this box that I recognize as being trustable, or I can do all the work myself. Shipping an API that allows developers to be unsafe puts you right back in the position where they can choose to shoot themselves and their users in their respective heads with no extra effort. Every time we see bug classes entirely eliminated at the platform level, we see those bugs mostly go away in the wild. Every time we see guidance provided, we see little or no impact in the incidence of those bugs. The web crypto API will be used in life-safety critical code. If you get this wrong, people will die. Enjoy your guidance. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlOAgCQACgkQQwkE2RkM0wpFxgD/QhvqIBmveR+H29P7dV76c9fC GZPvyZtFvSxvaZM++pcA/jftFah8wVbjsUz13A8kWl+Acd/ZSyZZCZQATPQAKJaX =SanX -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] LUKS Self-Destruct feature introduced in Kali Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.01.31 11.31, Amin Sabeti wrote: In the Iran case, I think using TrueCrypt would be better because hiding files is more important than destroying it. For instance, it would be not practical to destroy files when the authorities confiscate your laptop. Be aware that even if Truecrypt gets everything right (something the forthcoming audit will hopefully reveal), the list of requirements for using deniable volumes correctly in a manner that does not reveal their existence is quite long, even just look at what's present in their documentation. If you're going to rely on this for opsec, please carefully evaluate whether you are up to dealing with this level of effort. An incompletely hidden volume that shows clear intent may raise more flags than a simple encrypted volume. Likewise, if you're using tools that support data deniability features and believe you may be questioned, please evaluate carefully what you'll do if accused of having hidden a non-existent hidden volume. Developers of such tools, consider carefully whether by adding features like this you're actually improving security outcomes for your users; consider talking to them about it, maybe. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlLrkN4ACgkQQwkE2RkM0wrRPAD9GvR+jLaFhResDvsW/ZziLw0W vz6BuDgRR3nK3olL81MA/iwfQ4TGPV9HxdJKWFy9AtEE7eFZjTnEgvabkzJzG9mq =easI -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] quid pro quo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.09.10 20.27, Lucas Gonze wrote: Let's say major corps like ATT and Chase are doing favors for NSA. Why would they if not for a quid pro quo? And if they are getting favors in return, isn't that illegal? I wonder if there is evidence to show what the payback is. So, large companies have their own intelligence concerns, in terms of corporate espionage with respect to competitors, the potential actions of regulatory bodies in the countries they operate, and actions by activists and civil society groups that may target them. Some instances of this kind of thing are documented in Eveline Lubber's book Secret Manouvers in the Dark: Corporate Spying on Actvists: http://www.amazon.com/Secret-Manoeuvres-Dark-Corporate-Activists/dp/0745331866. Many of the folks who end up working in corporate intelligence or situation management are ex-intelligence, and in some cases retain their clearances. We have evidence (mostly from domestic intelligence agencies where evidence showed up in court) that shows a a revolving door for intelligence products between companies and agencies. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlIxt7MACgkQQwkE2RkM0wom7QD/STk2mtQiMxJEyTmpHZ7ZIxlf xtd3a0voYbbjGNF3xv8A+wVBf61OUXZF5x7ABytUY0Xs0t2uk3SZFFGs0LkQnG7A =HbF3 -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] secure download tool - doesn't exist?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.07.01 12.19, adrelanos wrote: - you still have to tell the user you must download tool X before you can download Y This, of course, is a global problem everywhere. A secure channel requires a shared secret, in this case between the developers and the end user. How does the user get their initial OS image if it didn't come with their machine or they didn't buy it in a brick and mortar store (both hard for FLOSS). Solutions in the non-general case are nice, but we should also remember that we have no general case solution either. (Likewise for firmware, but that's much worse) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHR7i8ACgkQQwkE2RkM0wq/RgD+MMJ/9eXI2byOijdvuhliXPWc 7SR2Txav51dJ8P74smsA/jNZaidqpkxTI2wkXjJMbnU4S+ZLBH1G3GGivXHYXcsO =txp0 -END PGP SIGNATURE- -- 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] secure download tool - doesn't exist?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.07.01 15.15, Julian Oliver wrote: ..on Mon, Jul 01, 2013 at 06:03:01PM +, adrelanos wrote: In response to the tool doesn't exist... apt-get install tor torify wget http://path.to/file And how did you verify the trust path for your initial debian install? E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHR//cACgkQQwkE2RkM0wo9mAD9GwoHERwiRIza0muFV7ttrSz5 sDuCSL74mHavhtZl4+kBAKEpICsWTSlqt73NQpP9c61i9KXLcmx6kvbUSeGvN4Rc =14Kf -END PGP SIGNATURE- -- 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] secure download tool - doesn't exist?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.07.01 17.28, adrelanos wrote: Eleanor Saitta: On 2013.07.01 15.15, Julian Oliver wrote: ..on Mon, Jul 01, 2013 at 06:03:01PM +, adrelanos wrote: In response to the tool doesn't exist... apt-get install tor torify wget http://path.to/file And how did you verify the trust path for your initial debian install? Thats a different issue to be discussed and solved separately. No, it really isn't. Either you have a trustable chain or you don't. Now, admitting that you have no trustable chain is fine; it means you're looking at outcomes and scope of compromise required to affect a single user, etc., because that's all that you've got left. In fact, it's useful to start thinking this way, because then, while chain of custody in the download process is still important, you start thinking about detection of interference rather than assuming that your house-of-cards updater will always work. Which it won't, no matter how good it is, if for no other reason than that it will have bugs which someone will eventually exploit. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHSOSMACgkQQwkE2RkM0wqFdAEAje76I5CbHdDQ+HtBB2b2b5Eg iXspCoeAQ0t0eda0fL0A+wT2eaCEyXRlqLFAp8UW9f6Y6m8hqddR3yAvST+ACuNV =gqUf -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.29 11.15, Jonathan Wilkes wrote: It simply doesn't make sense to claim that someone didn't do meaningful work when describing part of the research they've done as awesome. Wat? I never said this work wasn't meaningful -- please don't attribute things to me I never said. We need more research into things like social sharing for decentralized systems. That part's awesome. However, a research proposal is not a field-appropriate system, and the architecture for one is (generally) unlikely to turn into one without nontrivial evolution or a lot of luck. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHO+moACgkQQwkE2RkM0wp9/gEAj6r1TRi3CLTKeFW0ICAEglYq J4Vtspiuz84NhJcADhMA/3P8oZeLuOufKDeuoFOayJJcox+a26mhwdUHsG1PPEkO =0f9e -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.29 11.09, David Golumbia wrote: put more simply: the notion of a privacy-preserving social network is an inherent contradiction in terms. No, it's totally not. You can definitely build systems that allow people to have meaningful levels of privacy toward anyone not in the set of people with whom they choose to share data, while still letting them reasonably efficiently speak with those they want to speak with. I don't see why there's anything inherently contradictory in this. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHO+sQACgkQQwkE2RkM0wqCtQD/biQwnDGjxlqW6Ea/yZkYpbz2 6zTBdBW/zloHGzvZNAwA/1xbE7g2fXIa5EVLMoCR8t7q6MK7sXMeBpLaoY9rmgYF =aa3t -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.29 11.49, David Golumbia wrote: I really think that is wrong, because it looks at the problem from a purely technical level. I'm not. I'm trying to solve specific technical problems which support larger social ends. This is documented spy operations 101, all over any history of CIA, NSA, etc., you care to read. In fact, it's old-fashioned spying, and the fetish for pursuing technological intelligence makes it easy to overlook the more pedestrian kind. This is fine. I'm not saying that using a network like this will make you invulnerable to HUMINT. What I am saying is that networks can a) force your adversary to use HUMINT (which is a lot more expensive), and possibly even give you some tools to help maintain your social graph integrity, etc. People want social network like things. Not everyone in the world is running a terrorist cell, and it makes no sense to expect them to restructure their social lives as though they were, any more than it makes sense to ask them to restructure their digital lives similarly. People want to share what they're doing with people they know and like, and they want to do so in ways which have social currency, i.e. which while they don't have to be at all centralized, are an identifiable medium with identifiable social affordances. This is going to happen and even if we could get rid of it, it would mean a massive and terrifying distortion of the social lives of everyone in the world, to the point where the [state security services] would have won. If we build tools that force spooks to use HUMINT to get in, we've won. Folks running intelligence operations of any kind will need to learn better tradecraft, which has always been true. Privacy-preserving, as a property, doesn't mean if you don't think about what you're doing in the world you can run black ops on this platform. It means you can keep what you're doing here private against mass observation by the motivated and targeted observation by the non-resourced. Or, at least, I think that's a bar that's actually meaningful and can be achieved; what you're talking about can't. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHPBckACgkQQwkE2RkM0wriPAD/fRfv8dsBPeBvjXGeXt6QPiWR k6kDlU5Uy40mF9bNhB4BAJw23ZbDxfdOd+Wc/U8L8nelLC2xhApiSdYUkZ58s7n2 =dOeD -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 tl;dr-summary: Surveillance is not a scale-free property, and the notion of privacy is a notion that refers primarily to surveillance at scale. Targeted exploitation attempts are expensive and that expense represents the existing social contract (flawed as though it may be) between populations and intelligence agencies. Until we can by technical means return to that contract, we are not in a position to otherwise change it by legal or social means. On 2013.06.29 12.28, David Golumbia wrote: Further, the snoops use HUMINT to get technical access. it only takes one compromised friend on Facebook to allow downloading a huge amount of data, for example. Because this is not a privacy-preserving system; it is designed to encourage people to spread information by any means necessary. Privacy preservation is not purely a matter of comms protocols, but also user behaviour shaping and the tools you give users to control where their data is sent by default. I don't even think it's clear that HUMINT is more expensive than technical intelligence, and the budgets of snoop agencies are not so constrained that cost is something we can take comfort in. HUMINT is more expensive than SIGINT if you want to target an entire population. If you want to target a specific individual, then yes, that's an open question. If we can make spying on people as expensive as doing it via SIGINT, we have won the largest victory probable over intelligence forces within the current scope of their operations, and now the questions become centered around oversight and budget reduction. Privacy-preserving, as a property, doesn't mean if you don't think about what you're doing in the world you can run black ops on this platform. It means you can keep what you're doing here private against mass observation by the motivated and targeted observation by the non-resourced. Or, at least, I think that's a bar that's actually meaningful and can be achieved; what you're talking about can't. I'm having trouble parsing the two properties you lay out here; they are both much more complicated than I'd want to make them. I find privacy to be a simple property: I'm not going to be snooped on by the govt without a warrant; companies are not going to collect my data and do inappropriate things with it. These are matters of law and governance. It is not possible given what we have available to us as general purpose capabilities in this moment to technically guarantee that you won't get snooped on without a warrant at the fullest level of that statement, which you seem to be insisting on taking. I believe that the world in which law and governance ensure these principles is not only achievable, but the only meaningful kind of privacy we can hope for. Our political sphere is governed by laws, not human beings. The notion that rule of law can effectively constrain US intelligence forces is not borne out by 20th or 21st century history. Back to the original proposition, which did not appear to be yours: building a social network and proclaiming it to be privacy-preserving suggests to users that they will not be spied on. While there may be some truth to the difficulty such networks would pose for commercial data collection, any sense of security from government spying such a network creates will be false. Incorrect. No, we cannot and should not suggest to users that by using such and such network they will not be spied on; what we can do is provide them with a deeper understanding of how such a network can and cannot protect their privacy and against which kinds of actions from which kinds of adversaries. However, we can in fact build technical systems that make mass surveillance infeasible expensive. Until such point as we do so, we have little or no functional ability to bargain with the black state that is completely out of control. That will be true until and unless we have a legal structure built to prevent that spying, in which case the technical methods aren't necessary to begin with. Technical capabilities for surveillance will always be abused if they exist. The law does not have a track record to claim otherwise. Unless we have a technical structure to prevent mass spying, it will happen, in which case the legal methods are of secondary import. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHPGE0ACgkQQwkE2RkM0wqb3gD+LdWHETIs1CFI5XOfFwfi9ZBg 47GMjznHnf0ZjsKfbJ0A/jkAFaoB+TEfuGUvlG43hoFdOfngszjV6+DAlNGcALct =zob2 -END PGP SIGNATURE- -- 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] eternity USENET (Re: Internet blackout)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.29 12.37, Jacob Appelbaum wrote: Eleanor Saitta: None of those tools exist right now, not for locational privacy and metadata obfuscation. I disagree about the existence. Perhaps, I think we might be able to agree on certain values of 'unusable' rather than saying they don't exist? What is the tool that provides for metadata obfuscation for email? What is the tool that provides for locational privacy with GSM data? What is the tool that provides for anonymity when ordering food on Seamless? I include this last example specifically because it's trivial. We (mostly) live in cities that have evolved cultures and ways of interacting that do not preserve our privacy. In the past decade, many of those services have started to involve either the Internet or, now, smartphones. When you ask someone to stop carrying a phone, you're asking them to stop living in a city. Not by moving, obviously - they don't have to go anywhere, but for someone who lives in the West and currently uses a smartphone, they're functionally leaving; they're changing their life to a radical degree and giving up on most of the conveniences of an urban existence. For a lot of these things, yes, they're just unusable right now; we mostly see eye to eye there. However, when we're talking about mass culture change (which is what I'm speaking about here -- this is about the question of whether everyone will stop carrying phones, not about whether folks in specific high-risk scenarios should), unusable means non-existent. Privacy against state surveillance is one small factor in most people's lives, and as much as people may be outraged, they're unlikely to 'move out of the city' over it. I think that this is an interesting bit of advice and it really depends a lot on a person's context. I think it may be an unequal burden to not carry a phone that is always switched on. For some it is easy and for others, it simply doesn't reflect their contextual requirements. Are you a sysadmin? Are you on call as a doctor? Is your partner really controlling or excessively worried? Probably it isn't possible to take the advice of not carrying a phone. Or at least - there are times when not carrying a phone builds up a kind of stress that isn't worth the effort. See above. You're asking people to completely disrupt the structure and fabric of their social lives, often now people who have never had an independent social life that didn't involve coordinating things on a cellphone (if you're under, say, 26, this is probably you). There are some people who definitely won't be able to not carry a phone, yes, but for most people, all it means is completely changing every physical social interaction they have. No big deal. Yes, in some and possibly even many cases this may be well-warranted, at least until the tools become usable, but in most it isn't feasible. There is no point in giving advice to people that won't be followed. It's likely actually worse than useless, because it encourages learned helplessness and fear. If we know the tools aren't usable and that the disruption to people's lives is of a magnitude inconsistent with their motivation, then we need to carefully consider what we tell people. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHPG+sACgkQQwkE2RkM0wruKgD+JjPPthhSRs3H3f+7+dWApoRS En1veWTOEj93QWJX7bYBAIVW3AE5nhZqAesJ1lP9dnIg8A4H/wn5WQOtcV74dgiv =HSuD -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.28 03.37, Alireza Mahdian wrote: First of all anonymity is not a goal here. I'm going to come down on you kind of hard here, but it's not aimed at you, it's aimed at everyone building systems like this. A month ago, you could plausibly argue that it was possible to build privacy-preserving tools that did not provided unlinkability (what you mean when you say anonymity). This is now revealed as obviously, laughably, tragically, and utterly false. Social graph and traffic analysis is the name of the game. Content protection actually matters much *less* than unlinkability. If you claim to be building privacy preserving system and it either does not provide strong unlinkability as at least an option, or creates central points of trust failure where someone can be compelled into compromising the network, you have done nothing. Yes, there are different tools that are appropriate for different contexts. However, there is little or no point in doing further research on so-called privacy perserving tools that do not preserve privacy. This sucks for folks who have grant money and research time tied up in existing project that are now plainly irrelevant. Tough. The world changed, and we as a community need to move on, in a hurry. A structure similar to I2P or Tor that uses overlay network would be very inefficient due to network delays Congratulations! Your job is now to figure out how to make it faster while keeping the same privacy guarantees. You don't get to opt out, because you can't do any meaningful work until you've done this. This sucks. I would be quite happy to live in a world where these were not the constraints we as developers had to live with. But we don't get that choice. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHNuKUACgkQQwkE2RkM0wr0/wD+IVTnHPuZzNSs6hqEIP0gyaiQ 8J351/zcc6UWICx6suEBAIVLljasG1kp4vOMjwCclkxYdOFcsfQBJSAp2zjvWX7D =cHDZ -END PGP SIGNATURE- -- 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] eternity USENET (Re: Internet blackout)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.28 04.21, Rich Kulawiec wrote: On Fri, Jun 21, 2013 at 04:56:24PM +0100, Michael Rogers wrote: I agree - no smartphones is sound advice. No phones is even better. But the problem is, nobody follows that advice. So we have to be pragmatic. [snip insightful comments] I would like to agree with you -- and in part, I do. But I'll suggest that the yardstick for pragmatic has moved considerably during the last few weeks. And yet, the yardstick for what users will accept hasn't moved more than a half inch. Yes, we're going to get more people to try to use better tools now. They'll still fail, because the tools still aren't designed for them and they still do actually have other jobs to do. We're exceptionally unlikely to get people to stop carrying entire classes of devices most of the time when they still live in a world which all-but-requires you to carry them. Did you know that there's a private bus line going in in San Francisco that you can't ride without an iPhone? Now, what was that again about telling people to not carry phones? I understand very well that giving people advice that is insufficient isn't acceptable. However, giving people advice they're going to ignore wastes their time, destroys your ability to be an adviser on issues where they might take your advice, and doesn't result in any better outcomes. We as the security community need to stop doing this and come up with a third option that understands that our users have multiple priorities. If we don't want to understand the world our users live in and their needs, we might as well all fuck off to a cave somewhere. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHNuccACgkQQwkE2RkM0wpD3wD+NghXyKBmQEXhVnEQrGK3vSK2 ewQprZPVy/QUHqlh/ggA/RHvMiUwTXJR1dGHMCEI3mEpEwD9PiYC5cS2m1/295Ft =+88f -END PGP SIGNATURE- -- 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] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [apologies for top-posting] There are different kinds of linkability that matter. Linkability from an external adversary and my ability to identify myself to a friend are unrelated. If we posit a Facebook where I only connect via Tor, only post encrypted content, and also post chaff content so the service can't tell what content is even real, the other people who I a) tell the username to, and b) give the encryption key to can still use the network just fine -- from their perspective, it's the same experience. The difference is that from an outsider's perspective, it's noise -- they can't tell who's connecting to the service, how much traffic they're sending, what it is, or who's reading it. Location privacy is a critical part of unlinkability. If I can tell where people are located in the physical world, I can use that to reverse engineer an otherwise pseudonymous social graph and disambiguate social graph chaff, as is provided with your mirroring. Likewise, message transit times when all connections are observable will serve to distinguish between initial post propagation and mirroring. Services that attempt to provide deniability have an interesting problem to deal with. Deniability is poorly defined (c.f. the difference between hidden volume deniability in TrueCrypt and the deniability property in OTR). In each case, they're trying to use technical properties of a system to enable a user to perform a certain kind of real-world falsehood. Enabling your users to lie has (at least) two failure modes: the first is that the lie isn't complete (for Truecrypt, maintaining hidden volume confidentiality is sufficiently difficult that I'd call it field-impossible for most moderately technical users faced with a competent forensics technician), which means that you may be encouraging them to take risks that will get them caught and in more trouble than otherwise, while not giving them the degree of security they expected. The second is that the lie isn't plausible -- in theory, after keys have been published at session end, another user could fake an OTR message as having been part of that session. However, given a wiretap taken to even the most minimal level of forensic standards, no judge will ever find this plausible when presented as evidence that a separately captured transcript might have been forged. Again, the feature is non-functional in the real world. Services that claim to provide a form of deniability have an exceptionally high bar to reach to prove any degree of field utility. Deniability features often make protocols much more complicated (see mpOTR) for no real gain. Thus, I would claim that barring further research (both field and protocol), it should be avoided as a protocol goal. I am a very strong believer in distributed systems. They are key to any freedom we may regain online. I also see very clearly that the set of privacy properties that we believed were necessary are different than we previously understood, and that we need to change the systems we research immediately in reaction to this. Yes, Tor is slow. This doesn't mean it's ok to say that well, I care about user experience, therefor we have to give up on network unlinkability. You'd never dream of saying that about authentication, right? Well, now you've got another thing you have no choice but to deal with. E. On 2013.06.28 15.01, Alireza Mahdian wrote: To answer your concerns Eleanor: If you are talking about content unlinkability as implemented in Darknet I don't want that in a social network that works like Facebook. I want to be able to trust the contents that are published on it based on their linkability to their publishers. Think of Facebook with no content linkability, it is not even meaningful anymore. what does it mean to have a wall if no one knows who the wall belongs to. it is a completely different experience and I did not want that in MyZone. I was more aiming at a distributed Facebook where user contents are stored on their own devices and mirrored on trusted devices. Now if you are talking about the linkability of users within the social graph I would also recommend you to take a look at my thesis where I have introduced the concept of social hosting. an advantage of this is that let's say user A and B are friends also B and C are friends but not A and C. if B chooses A as a mirror then C would at some point connect to A to receive B's updates or interact with B's profile while it is offline (writing something on B's wall for example) at this point the entity that monitors all the links (let's say the government) would wrongly assume that A and C are friends (linkability) while it is not true. now the users can use this to their advantage and when prosecuted they can deny the linkability by just giving the counter example of this i.e. if A and C are really friends and A happens to be a person of interest C can
Re: [liberationtech] a privacy preserving and resilient social network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.28 13.14, Jonathan Wilkes wrote: Just curious, Eleanor-- once you implement your bullet-proof privacy- preserving network, how do you plan to make the user experience at all tolerable without automated mirroring like what this developer has written and tested? That's going to depend on the system and the situation. With Briar, we do things that are fairly similar, but we also make a point of taking unlinkability seriously. Research code into social mirroring? Awesome. Protocol design intended for deployment that ignores unlinkability? Not awesome. More specifically, some of this is unrelated to Alireza's proposal -- I'm using it to illustrate the kinds of shifts that we need to undertake in our thinking here. It's not about *this* tool, it's about every tool we build. To that end, I suppose I do owe them a bit of an apology -- really, it's nothing personal about this tool (and certainly not anything about them, although I hope that's obvious). It's all of us and everything that needs to shift. Finally, I should note in passing, I'm not trying to make something bullet-proof. I care about security outcomes, not security theories. What I want to see is our tools reaching the point where we're actually playing the game, because right now, we're not even on the road to the stadium. Encryption meaningfully prevented a wiretap for the first time ever in *2012* (or so we're told, for non-intelligence domestic US wiretaps), and has only ever worked five times. This is pathetic and terrifying. Let's become an actual problem. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHObREACgkQQwkE2RkM0wrI1AD/aSD1R4PCjLVMxJGfY2s1CDLP 0EOaFBGkh3daJdsJ6moA/0DHZM5CoIwHpUN/3O6cx7HdKSmE6VcqxTsnI6+f9kt+ =v8og -END PGP SIGNATURE- -- 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] US wiretap statistics (was re: a privacy preserving and resilient social network)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.29 01.18, Matt Johnson wrote: Encryption meaningfully prevented a wiretap for the first time ever in *2012* (or so we're told, for non-intelligence domestic US wiretaps), and has only ever worked five times. What are you referring to? Do you have a pointer to more information? I am very curious. http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5 E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq =Lw8s -END PGP SIGNATURE- -- 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] Is Ecuador the Safe Haven We Want to Believe In?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.26 18.26, hellekin wrote: Ecuador won a huge credibility bump in hackerdom when it offered political asylum to Julian Assange. That is confirmed with Edward Snowden jumping from HK to Ecuador via the Red Block to evade the Angry Murder of U.S. crows. There is a pattern here: if you leak U.S. secrets, you can go to Ecuador. How cool is that? Unfortunately, the flip side of the Ecuadorian coin might not be as bright as it seems. I don't think anyone is assuming that Ecuador is a bright and shining city on a hill when it comes to civil liberties. What it is is a tactically and potentially strategically useful jurisdiction for a specific class of people in some situations. As with Hong Kong and Russia, I wouldn't assume that anyone is endorsing it as such. I mean, if they are, yes, they should go do some reading, but that's just not germane to the conversation for the most part, unless we're talking about civil rights in a whole pile of other places as well. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHLdb8ACgkQQwkE2RkM0wo/lAD8CbW8emlRpNIbbgtFdgOEJ9Sg TqwvUdGs3J0E5MocMpMA/jKt8Fbiu0f23QMYAOB1I/1LFGEFvqJcgRU2VDmcJu8+ =FQlD -END PGP SIGNATURE- -- 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] Call for Participants @ Noisy Square - Putting the Resistance back in OHM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.25 04.32, Eugen Leitl wrote: On Mon, Jun 24, 2013 at 09:08:59PM -0300, hellekin wrote: They are ramping such a system up but it isn't in place yet, remember, they are firing 600 people in the following years. *** I guess you mean: outsourcing to the private sector. The budgets in general will shrink a lot in the coming years, whether black, or not. There's only that much parasite load a given host can bear, especially if energy intake is going down. It might be well the last big splurge in sigint, and they will have to let many analysts go. The data might be still collected, for a while, before the number of tap points goes down to attrition, but less and less can be made from it. Perhaps we're witnessing Peak Spook. While I love this notion, I see absolutely no evidence for it in any way. I think we're going to see the opposite -- surveillance is still getting cheaper, fast, and I don't see much real sign of the big players cutting their budgets. While I don't know that they'll be able to achieve the same kind of geopolitical reach that the NSA has, I'd assume that most country's internal police will be looking to reach a similar pervasiveness of surveillance. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHJrGgACgkQQwkE2RkM0wr9rQD6Amb2dwibQ3ztHaLgdq5UWAf7 8cFFWXIdsTuXFFDmp2wA/R5hgIY6/yPdvWebt8zinbcH+8ycPbc9M120MyYrjPtc =oi8v -END PGP SIGNATURE- -- 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] Call for Participants @ Noisy Square - Putting the Resistance back in OHM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.25 07.37, Lex van Roon wrote: In my opinion, us (the people) being divided is whats taking away our power, and that's imho much, MUCH more important then governments losing their power and cracking down on us (the people) so that they can stay in power. If we unite, we've got a chance of beating them. If we dont unite, we will lose our freedom, thats how I see it. So how about we let go of all the fearmongering and actually start talking with each other how to fix the problems we're currently facing, instead of slinging (unfounded, imho) mud around .. This mud is very well founded, TYVM, but that's separate from my point here: Is this the pitch of left unity at any cost? Because no, actually, it turns out that unity isn't the best thing ever. Do you want a big tent that means nothing? Do you think that the OHM orga is united in fighting for the destruction of the power of all governments to oppress their citizens? Their actions indicate otherwise. The pushback you're getting here is that no, we're not all actually on the same side. If you want a claim to unity, first show that you're on the same side. There are reasons for going that aren't about unity, and opportunities there that do still make it interesting, but they're about what can be done in a contested, unsafe space. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHJrj8ACgkQQwkE2RkM0woHdQD9G/vnEvr9IYZRQsszirJN61PG iHLgLTUVyIfahwYYs0sA/3UEXYmB4bNihz3xiKnfIyqmiT5knEFYkv82dfkJBGw2 =/i9J -END PGP SIGNATURE- -- 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] Call for Participants @ Noisy Square - Putting the Resistance back in OHM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.25 09.00, Douwe Schmidt wrote: Please help us to put the Resistance Back in OHM What is the line where the organizers of a hacker event are so given over to collaboration that the event becomes unreclaimable? Would they have to be shown to be stealing candy from small children? And the abuse that orga team has hurled at my friends? What happens about that? ps. we are still working on a multi-quadrocopter-powered air bridge to bring people into the village without touching OHM-ground. You will then be in a radically democratic and borderless territory free from oppression and surveillance. It must be said that this might be a one-way-ticket, aka the Ecuadorian-lock-in. Ok, get this working and I might be tempted. ;-) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHJrrgACgkQQwkE2RkM0wrcbQD7BCcVJ5mXaB5JDa3vAZyzou4W V6d1KG/8rS/0KUqetp8A/0wts7H9sgUB6e4vjLgH0rHwJgy9CPuHY9I+SbDBkm/I =72p7 -END PGP SIGNATURE- -- 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] Call for Participants @ Noisy Square - Putting the Resistance back in OHM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.24 07.19, Douwe Schmidt wrote: Dear LibTech Readers, In a little bit over a month OHM2013 is happening in The Netherlands. There has been a lot of controversy in the run-up to this gathering. There was criticism of the involvement of tech security company Fox-IT, then there was a heated debate on the presence of Dutch High-tech Crime Unit in a village of their own. Both discussions have calmed down. But the relevance of these topics was clarified and reinforced. It's very sad that the organizing team has not actually taken any meaningful steps to address either their complicity with the manufacture of surveillance equipment, their acceptance of the promotion of a fascist police force, or the way they treated people who had previously been part of their own team during the discussion that ensued. In fact, as far as I can tell, absolutely nothing has happened on their end, they've just out-waited any discussion. A lot of people are asking me to change my mind on attending, and it sounds like you guys are going to have a lot of fun, but I'm finding myself pretty unmotivated to change my mind given that much of the organizing team doesn't seem to care at all about human rights. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHIayEACgkQQwkE2RkM0wpEqwD/b0/oaJEcff0Dwj0ELR4CByiR ZDTh75L6HCSoXRxBoyQBAJn9e29RAuXFzA+ohaRVtRu/hwmD5PezbKXBFxaNMhFu =gbiw -END PGP SIGNATURE- -- 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] PrivateCore and secure hosting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.20 22.55, Steve Weis wrote: Hi Eleanor. I am a co-founder of PrivateCore and happy to answer questions. I'll keep it non-commercial and focus on the technical answers for this mailing list: Thanks for responding! [It isn't] clear how the initial keying is performed ...Please let me know if you have more questions. To have a secure channel between two processes/compartments (in this case, the CPU of the hosted machine and the remote, non-service-provider-controlled system), they must share a secret. Just encrypting local system memory with a key generated on the CPU doesn't permit secure communication - e.g., you have no way of getting data in and out of the compartment. Doing computation on known inputs where trojaned hardware can read both the input data and the code isn't useful, because the work can just be done in parallel by your adversary. So, to provide useful benefit, I assume you must have a method for secret-sharing between processes/compartments. What is it? E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHEuE0ACgkQQwkE2RkM0wpwiQD9HcScoAMTi5hpPYTSEDjdetpg 4rFKX/8wh+DlyaMF2mIA/2yvPf2EL1SK+eNrWrE9xz8vCue+as2AI/osNHB05uZX =k5++ -END PGP SIGNATURE- -- 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] Deterministic builds and software trust
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.20 04.34, Mike Perry wrote: We also include the full set of git hashes, version tags, and input source hashes in the bundles themselves, so you know exactly what went into your bundle if you want to try to match it at a later date... Have you considered asking developers to sign commits? That seems like it's the next step in terms of being able to verify a complete chain of code pedigree. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHDrd0ACgkQQwkE2RkM0wqzVwEAlPJUeCUVmHJqXd+tlNhMrkUf 8oJ9xuMT71ph90IaK3kA/R+FznDuOYdSedSz3bbFNpM/q1E81cNL52jxDNzbWhpK =Rqmp -END PGP SIGNATURE- -- 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] PrivateCore and secure hosting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So, a bunch of us were talking about secure hosting in Tunis. At one point in a side conversation, PrivateCore came up as a tool that might be interesting when you're looking at aggressive malware. It's designed to allow you to perform certain kinds of secure computations in a context where you can't trust anything off the CPU die, including your north bridge or main memory, while still allowing you to use commodity x86 hardware. This is interesting, as CPU packages are relatively more expensive to tamper with than complete boards are, and represent a smaller (the smallest possible?) target when looking at issues like firmware rootkits. Sadly, their available online documentation doesn't make it clear how the initial keying is performed; e.g., are they relying on secrets already baked into the chip or using some initialization process? If the latter, how do they guarantee a trusted path to the chip during initialization, and if the former, how do they ensure that the secret is actually secret to all parties but the initializer? If anyone knows more about them, I'd be quite interested to hear it. (There's a larger issue of their technology not being open source, for our context, but that's a separate issue.) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlHDsWwACgkQQwkE2RkM0wovOwD+NFxHfUuR5KPfbYpxzTMXVNZX jnYSrl2YEHQBzmKUFIEA/1GHlD8jm3Zw13LSJQC0MrlZ0Ev4cpnBT4B59KAm7DVL =oQCa -END PGP SIGNATURE- -- 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] Oakland Cryptoparty This Sunday at 1pm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.14 18.20, Rich Kulawiec wrote: Now since I have (once again) opened my big mouth, I'll step up as well: if any organizations want to get their email out of the cloud/third parties, contact me off-list. I have a pretty good stash of disused hardware that could be put to work -- better that it be used for good than gathering dust. The issue with this approach is that maintaining infrastructure like this takes an ongoing time commitment by someone who is clueful (and thus at least moderately expensive for broke organizations where everyone's constantly overworked), and that older hardware fails, and keeping enough spares around to get reliability adds cost and complexity again. I'm (definitely) not saying this is a bad idea here, but it's important to understand what the real costs look like for organizations that may not natively have this talent, or where the folks who are supposed to do the work also have other jobs. For instance, in every small org that I've seen that does development and has infrastructure, infrastructure-only hires quickly get absorbed into development work. Running mail as reliably, securely, and conveniently as Google does with GMail is actually hard; this is why it's achieved the popularity it has, not just the cost. I've watched many friends and orgs over the past 9 years decide they just didn't have the time any more. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlG7RiIACgkQQwkE2RkM0wpplAD9EofYcu2avh9PSeI6C1jjggUh stkxtMIY8X5T68vyclUA+wQ+HO3a/JINZfKmpignWZMjPBdMhiA0mXT5wDecT9lZ =gkuS -END PGP SIGNATURE- -- 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] Guardian reporter delayed e-mailing NSA source because crypto is a pain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.12 11.54, micah wrote: I'm constantly hearing from people who complain about the UI in things like gnupg. I feel your pain, I do not want to argue that you are wrong. However, I do want to argue that complaining doesn't help to solve the problem. I've asked every single person who has complained about this problem to me recently, have you filed a bug about your issues? and everyone's response is: no. I've done this, and guess what? It works! I filed bugs and had discussions on the gnupg mailing list that have made your experience with that tool a little bit better. There are many ways that I think it can be improved still, don't get me wrong, but the gnupg developers are reasonable people who want to make the software better, and probably have been hearing these complaints for years and years and would welcome a way to make people stop complaining. It seems there are a lot of people out there who have a clear idea of what is good and what is bad UI and are pretty vocal about when something is bad. How about turning that into clear bugs that describe better workflow and UI? You dont have to be a crypto nerd, or a C programmer to make this stuff better and easier to use. Is there any point in filing a bug that says Please have a professional designer re-work all use flows in this system from scratch? (No.) Is there any point in filing a bug that says Please remove features X, Y, Z, Q, R, N, and M because they're too confusing for novice users? (No, especially when X is the entire web of trust.) Filing bugs isn't enough -- it's an entire design effort. Individuals may see a thing and think hey, this could be changed, but what's needed is a top-to-bottom redesign, and that does not translate into a simple set of clear bugs. I don't believe that the GPG designers have the resources available to do this design effort as it stands, and it's not just them, it's the entire ecosystem that needs to be involved and work together. We'd love to see this fixed. If it was this easy, it would have been done years ago. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlG4nLkACgkQQwkE2RkM0wpFNAD9Ez3mXSJRDrU5ViXz7+k1xbdd iObK9CUbmIpPTmL+BoUA/315DpJFjW4FbO5L2yyTAix7X2QuV7UTzYaX4/XwZHF6 =nDoe -END PGP SIGNATURE- -- 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] Internet blackout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.06.11 17.44, Richard Brooks wrote: This lead me to start thinking about the possibility of deploying something like Fidonet as a tool for getting around Internet blackouts. Has anyone tried something like that? Not Fidonet, because the world has moved on, but Briar is designed with a similar store-and-forward architecture as a delay-tolerant messaging system with strong security guarantees, intended to work across whatever transport is available in the moment for exactly this kind of situation. While we're a ways from being ready for use in any kind of high-risk (or even low-risk-but-real) scenario, we've got an early alpha out if you want to play with it. We're also looking for more help, especially from developers (Java; Android, Swing, JDBC, concurrency, etc.); we're happy to mentor less-experienced developers. More info here: http://briar.sourceforge.net/get-involved.html. /ad E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlG3/sgACgkQQwkE2RkM0wpIyQD/d3gZhRQ7gfFOZwD5u5HnIK2H HUVDJgIkIltdL3EmNTwA/RUgVH0i9w6v+5AjuWxHukljXsJgUoI8YmhXPzjoRLdg =LOBj -END PGP SIGNATURE- -- 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] Medill online Digital Safety Guide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm going to step into this thread just once (and try to stick to that); apologies for top-posting this. I come from the security community. I understand very well many of the arguments you're making and even agree at a technical level with most of them. However, let's talk about human outcomes. Human outcomes are the only thing that matter even a little bit in security -- not could you be owned, but were you actually owned, and did that mean you didn't get out in time/accomplish your objective. Nothing else matters. You cannot force people to adopt proper security procedures. You cannot scare people into adopting them -- you can't scare people into doing anything. It's useful for us to understand where we'd like people to end up, but we have to start with where people are and deal with the fact that they have limited time, limited capability to adapt, and limited resources. This means that many people will be owned, and many people will get hurt. Our goal, our only real goal, in doing security work in this context, can be to *statistically* reduce the number of people who get hurt and *statistically* increase the number of people who achieve their objectives. Yes, I don't like the current set of trends we're seeing in computer architectures, and I've got my own projects that are fighting them, but we also have to work within those trends, because computing is a social practice and if you aren't were the users are, you're crying alone in a corner. Asking people whose job is to be a professional journalist to go use a text-based mail client means you lose, because they're not going to. You *might* get them to give up the power and convenience of gmail to switch to a thick-client, but more than that? Forget it. You might get someone who's a writer to switch to a linux box, but asking a professional photographer to ditch Lightroom and switch their whole workflow around? Forget it. You might even get your journalists to adopt a nice hardened workflow for document intake that keeps them safe from almost all of the malware that people try to pass them, but you have to understand that they will jump around the edge of that system sometimes when things are blowing up, and *THIS IS FINE*. Their job isn't to be secure, it's to get the story out. Sometimes this means they go to jail. It's ok. They signed up for it. It sucks, and we want to help them reduce the chances, we want to make sure they understand the risks of their actions, but in the end, it's their call. The point of humanitarian technology is to empower people, and that means empowering people to take risks and make decisions that we consider completely insane. It's ok. Yes, in some situations, all we can do is tell people either you do all of this of you're going to be owned. That's fine. Our job for those situations is to see how much we can lower that bar, based on where the users are, what they need, and what we can do. Lowering the bar for other hackers doesn't help normal users, although in some cases it may be a prerequisite. I could go on for a while longer -- one of the things we need to think more about is how we can go from defense in depth to a more epidemiological approach to security, and how we can use the most sophisticated pattern-and-behavior matching processor we've ever invented and that we've been ignoring for years (the user), but I'll stop here. The bottom line: meet the user where they are, think about outcomes, not ideals, and understand that you're going to fail, most of the time, and that that's maybe ok. E. On 2013.06.01 07.40, Rich Kulawiec wrote: On Wed, May 29, 2013 at 03:21:45PM -0700, fr...@journalistsecurity.net wrote: I appreciate your feedback and your bluntness, Rich. But you are providing far more guidance about what to avoid than what to use. If journalists and other users should avoid all commercial based operating systems including Macs, or any system requiring anti-virus software, then what operating system should they use? Linux maybe? Or something else? Similarly, if they shouldn't use GUI-based email clients, what email should they use? See below, I'll try to address these questions. That's actually not my blunt voice. That's my exasperated voice, because I've grown exceedingly weary of listening to people explain how to secure a closed-source OS/application environment. Can't. Be. Done. The evidence supporting that statement is already piled so high that one could spend a lifetime examining it and not finish. And more arrives all day, every day. Yet there are STILL people trying to claim that yes, you can secure your Windows desktop if only you use anti-spyware anti-virus anti-malware anti-anti-anti-whatever. If only you spend enough money. If only you use IDS/IPS/firewalls/yadda yadda yadda. No, you can't. Not for any reasonable value of secure. (Yes, yes, I'm well aware that nothing
Re: [liberationtech] A Digital Safe Haven for Syria
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.05.27 10.57, Yosem Companys wrote: From: *David Farber* d...@farber.net mailto:d...@farber.net Anyone believe this would actually work? LETTER A Digital ?Safe Haven? for Syria Technically? Yes. I and other folks have done the logistical evals, looking at a variety of sites, etc. Politically? That's a fascinating and open question. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlGjvYAACgkQQwkE2RkM0wrDkQD/XaurdhRKOpd+3Ulr2No9ryIZ AryoBmdrEPPfu8K9waIA/0W2onOzsOJwmYZdWVgdCpNFlZUdOFO//5vky071Bq/y =5vUr -END PGP SIGNATURE- -- 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] New Yorker debut's Aaron Swartz's 'Strongbox.'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.05.16 10.45, Fabio Pietrosanti (naif) wrote: On 5/16/13 12:05 AM, Eleanor Saitta wrote: Which parts of the Dead Drop architecture do you think are unnecessary for a leaking platform? First of all leaking is not necessarily whistleblowing (it's like cracking vs hacking wording debate :P) . Well, in this case, the system was designed to receive leaked documents, fairly specifically; I think that's probably a reasonable term here. If i would had to take actions on DeadDrop i would simplify as follow: - Make everything work only with 1 server Why do you think that less compartmentalization will result in a more secure system, if that system is likely to be under active attack by corporate and nation state security forces? A journalist (or a group of journalist) need to work on received material online and not offline because they need to search databases, browse google and apply investigative techniques to investigate on the topic. And do it in an efficient way, because time is always a scarce resource. There is a difference between reading leaked documents and doing investigation. It's perfectly reasonable to have another laptop right next to the viewing workstation, where story notes go, searches are run, less confidential background material is looked at, etc. Additionally they need, for efficiency purpose, to collaborate on the received material and to do so there are excellent platform for sharing it like http://www.DocumentCloud.org or DMS (document management system) like Alfresco (www.alfresco.com/) that can help extracting text, applying semantic analysis, collaborating on documents. This depends on the kind of documents you're talking about, and the kind of story. If you've been given a dump of millions of documents that need to be analyzed in the manner you're talking about, sure. Not all leaks look like that; many don't. In a case like this, it might be a reasonable decision to, having looked at a document dump, move it to a non-airgapped machine where it can be accessed in a collaborative way. However, one might well not want to bring over potentially incriminating records of messages with a source into that environment, and one might wish to ensure that unnecessary metadata had been removed from documents first, again to protect sources. So i really think it's unrealistic to handle dozen or hundreds of submission per month by copying received data offline, decrypting and analyzing it offline trough a different workstation. What do you base your assumptions of submission rate and workload on? IMHO in a realistic workflow, at first the journalist evaluate the data received quickly, identifying if it's spam or ham, define how securely he should handle that data, and then will apply appropriate operational security procedure depending on the data received. If you do this on a non-airgapped machine that's been compromised and you figure out that what you've been handed is serious, it's a bit late, no? Operational security isn't magic sauce you can spread around afterwards. - Too Many Servers Looking at https://raw.github.com/deaddrop/DeadDropDocs/master/Deployment.jpg we see that there are 4 servers, 1 switch, several dedicated hardware for operational security (external encrypted hard drive) with a quite complex installation procedure https://github.com/deaddrop/DeadDropDocs/blob/master/README.md . This increase the cost and effort required to startup a whistleblowing initiative in terms of hardware, software, services and skill set required. ...because this is what's needed, in this architecture. You're talking about analyzing hundreds of submissions a month collaboratively and using large scale document analysis systems, and you're worried about buying a few boxes and hiring a sysadmin? - Too Much Customized Software Looking at the installation procedure there are several customized procedures and software such as using Hardened GRSecurity linux kernel, requiring to manually maintain security update for all kernel release, and manual setup of a Certification Authority (with OpenSSL), requiring manual handling and management of certificate via command line. Well, if folks start shipping properly hardened distributions (and there are some arguments for moving over to tails, for this reason), then this'd be a bit less work. Again, just because it's hard doesn't mean it's not necessary. I just find it overkill for a general use. What's general use? E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlGU8ScACgkQQwkE2RkM0wqiDAD+KmN7RbtPcvwdI6NvGqFEuOyI ZqzNGf8/PdSikhjDgg0A/2ZO7E4bSrIwF1NX3iBQdChBcJV4T1D+odCCLMq7i67f =HYnk -END PGP SIGNATURE- -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https
Re: [liberationtech] New Yorker debut's Aaron Swartz's 'Strongbox.'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.05.17 00.05, Fabio Pietrosanti (naif) wrote: I like deaddrop uber-paranoid approach. I'm just convinced that's overkill, designed to be excessively scarifying usability efficiency, thus not being suitable for the many uses that we'd love to see starting up their anonymous whistleblowing initiatives. This is a system designed in a Western context for the use of rich-world professional media organizations. Yes, it's not going to be achievable for everyone. Is very important, in my own view, to let an ecosystem of initiatives to start with few or no effort because it's better to have 10.000 diverse, distributed whistleblowing sites rather than few big and complicated ones. What level of risk is it appropriate for organizations to expose their (indirect) users to? What level of risk mitigation do you as a software developer have an obligation to those individuals for? I don't ask this in a flip way. Democratization of access doing things like running a whistleblowing system is great. On the other hand, encouraging people to start doing activities by making things easier when you know people aren't going to be able to properly defend themselves is maybe a bit problematic. Obviously, it's their call, but as a tool-builder, you're not isolated from that decision. This is a question that runs through a lot of our field right now. If you release software that encourages high-risk behavior (like, say, secure communications for activists) but don't do basic due diligence (like getting it audited and fixing the identified issues), this is a problem. If we teach people how to do some secure communications and thus encourage them to talk about risky things online but we know they're not actually going to know enough to stay safe, have we raised awareness, or just put them in danger? That kind of enemy (corporate or nation state security) would attack the organization and the people, not the server (placed in a unknown location behind a Tor Hidden Services). Not necessarily. It's often very expensive for governments in terms of PR for them to come after media organizations directly. Using this example, if the FBI sends a subpoena to the New Yorker for the contents of this system, a bunch of journalists dutifully troop off to jail instead of turning the system over, and the case blows up to the front page of every single newspaper in the country for a week. A corporation has even less recourse -- they likely can't even sue until something has been published, and then often the most they can do is throw a libel suit around. This isn't true in every context, but different avenues of attack always have different kinds of defense. If you constrain your adversary in terms of what actions they can take, that's a victory. Separately, if you're not trying to defend against nation state or corporate security forces, exactly who are receiving leaks on? And if that enemy would attack the servers, it would reasonably do it only after many weeks or months that the incriminated submissions has been done, after the information has been already leaked and published. This makes no sense. Why would they do that? If they don't know about a leak, sure, but that's not always the case, and there are times when an organization might want to just keep an eye on what's going through a server like this. Regarding compartmentalization, that's to be done trough proper system/filesystem/network sandboxing system for efficiency purpose, by using SELinux/Apparmor/Iptables modern systems. Even US NSA abandoned most physical compartmentalization practices by applying logical compartmentalization (see NSA Mobility Package or NSA Trusted Systems as examples). No, they didn't. They offer non-compartmentalized tools for some situations. SIPRNet workstations are airgapped from NIPRNet, etc. VM breakout attacks are a very real thing and the notion that virtual separation is sufficient for compartmentalization when under serious attack is very, very dangerous. Obviously, it should go as read that there are tradeoffs here, and I agree that this design is suitable for specific scenarios, not everywhere. Again, though, why the emphasis on a single machine? I can understand saying that there should be a lower admin bar -- that seems entirely reasonable, but hardware is *cheap*, especially when you're looking at very low throughput use cases. Cheap isn't free, even in the developing world, but a server here can be something as light as a raspberry pi. Humans are the expensive part of any deployment scenario for a system like this. In that scenario if the journalist workstation is compromised also the scope of his investigation is compromised, regardless the secure viewing workstation is secure. If national security forces are listening to journalist workstation, they know what's going on. They know some things, sure. Compromise is not an all or
Re: [liberationtech] Schneier: Focus on training obscures the failures of security design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.03.28 00.45, Carol Waters wrote: At the risk of igniting an inbox-exploding smackdown thread, I think the following piece by Schneier http://www.darkreading.com/blog/240151108/on-security-awareness-training.html is definitely worth a read and thoughtful discussion; particularly from the POV of both trainers and developers. While I understand where he's coming from, and while he may even be correct when it comes to the strict integrity of the host system with which the user is interacting, he's significantly wrong if we take even a slight expanded view of what security is. Security is the ability to maintain agency in the performance of some set of real human actions in the world, in the face of hostile acts, and, moreover, to have some degree of assurance of one's continued agency. Much of security is and will always be about user behaviour. We cannot separate physical security from digital security, nor can, in our modern heavily surveilled world, we separate awareness of one's behavioural threat model and the interactions between things like the linkability and confidentiality properties of a channel, the data one is sending over that channel, and what one's adversaries capabilities and intents are. Real security awareness training (and I don't think for a second that what most people are given as this is sufficient, except in the literal sense of making them aware the problem exists) must give people the tools to understand these kinds of calculations and tradeoffs on their own. Yes, we must do far, far better than we are right now with our tools -- we need our tools to do everything that a computer can do to keep its humans safe, but even that isn't enough. It's great to have a self-driving car that will ensure you never get into a car accident, but when your actual adversary is an MQ-9 doing signature strikes, it's not going to help at all. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlFUUVUACgkQQwkE2RkM0wpI5gD/bhcx3PdCr3e960ZXBvyChigU TkaC/jVeqsRtiJgZoXcBAImvJkEHwNHtqdTSaff4jTMRY7TqZL48lcZxX9bREZWD =Y0kj -END PGP SIGNATURE- -- 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] A Different Technology Query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.03.10 04.28, Bruce Potter wrote: Apologies if this is too far afield, but a friend in a small island needs assistance with an unexploded ordinance problem. Is there a list or other resource I can refer him to? While this is at best only a partial solution and obviously you're going to want to find an expert here, you and other folks on the list may be interested in the Explosive Remnants of War Collection Points project that came out of the Joint Interagency Field Experimentation, aka Camp Roberts: http://www.erw-cps.com/index.html. It's a very simple and cheap design for containing small amounts (1kg) of high explosive, for instance unexploded RPGs. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlFI4d8ACgkQQwkE2RkM0wpBlwD9EFOGNB6nhMLbB82ND4z4wsN9 sMthtDOx8VDQODjtJ/UA/j9CxItj5sf9eSx1sfblpJn7STGUCKnnIXYJV1N3Ddq4 =XwY0 -END PGP SIGNATURE- -- 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] Skype Open Letter: CALL FOR SIGNATORIES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013.01.23 01.09, Nadim Kobeissi wrote: OpenITP will sign. Put me down individually, too. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlD/4JgACgkQQwkE2RkM0wpMtAD+N/z+ydCj3RMJmJEVE0r4Zxwg cZ53YZc4Btn8GcaQJ70A/0zSDkNSvvxV+e1GNIMbutYTYuT5h/MJGqChLMpvCIYs =/3RJ -END PGP SIGNATURE- -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] OkayFreedom
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2012.10.29 07.14, Sam de Silva wrote: Perhaps there should be a 'TripAdvsor' for digital security tools ... Expect a more thorough announcement once I've had time to get some stuff written up properly, but OpenITP will be running a public, open, and transparent peer review board to provide at least one instance of this function, up through an including sponsoring audits of tools by commercial security teams. We'll also be working to ensure that the teams we work with have proper threat models, security documentation, and well-considered user experiences for their tools. More in the next couple of months, E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iF4EAREIAAYFAlCOQnQACgkQQwkE2RkM0woNXAD9G5Isp8QLndGM/5hgAZKKmMZm nuL4EX/IG/KSgg2VYeAA/Aj2Vzf74/JMU+fm9CwTeYTyzy972tKz3nZ/ZCa+ezJW =XSuf -END PGP SIGNATURE- -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] What I've learned from Cryptocat
On 2012.08.06 17.54, xmux wrote: On 08/06/2012 08:50 PM, Nadim Kobeissi wrote: Suggestions welcome!! Don't provide the insecure version at all? How many people use the Chrome plugin vs. the website version currently? The insecure version is currently the only thing which is interesting about cryptocat. (And, to be clear, the secure version does not yet exist; when it does, it will be marginally interesting at best when compared with the less secure version which fills a much needed position within an ecosystem of tools.) E. -- Ideas are my favorite toys. ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
Re: [liberationtech] What I've learned from Cryptocat
On 2012.08.06 17.51, Jacob Appelbaum wrote: Jillian C. York: It's difficult. I'm not a technologist, but I understand the issues and the user needs well. My type, I'd surmise, is few and far between. Security experts have obvious reasons for being conservative, and I get that. Nevertheless, there are a lot of users who would benefit from *a little bit* of added security. The question, then, as I see it, is: *How do we provide that little bit while still making users aware of risks?* The problem is that the little bit is effectively zero. What's the difference between Facebook chat over SSL and Cryptocat over SSL? Without a browser extension/plugin - there is little to no difference. You have to trust the server and the server operator to not be a bad actor in both cases. It is true that you have to trust the server operator in both cases. However, having a server configuration which does not completely compromise user privacy (vs. the operator) by default, like Facebook does, is still a significant improvement in many use cases, as is the ability to have a diversity of server operators. If you insist on only permitting tools which offer a mythical perfect standard of security, you ensure that many at risk users will use plaintext tools that offer no security at all. Yes, it is likely that cryptocat will be broken in a non-plugin version, and that people will die because of it. However, it is also likely that cryptocat will save lives, vs. plaintext alternatives, and that a plugin version of cryptocat will also be broken at some point, and that people will die because of that. We need an ecosystem of tools, not a magic bullet. The Security Community as such has done much good over the years. However, security professionals who are unwilling to acknowledge that different users have different needs, that online security exists within a larger constellation of risk analysis, and that usability can and often does trump pure security even when viewed purely through risk analysis and outcomes are doing a grave disservice to both their field and their users. It has been 21 years since PGP was released. To this day, it remains a niche product at best. Users with real world security concerns rarely if ever use encrypted email. It is exactly this attitude which is to blame. If you want to continue being irrelevant, go right ahead. The rest of us have real world problems to solve. E. -- Ideas are my favorite toys. ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
Re: [liberationtech] What I've learned from Cryptocat
On 2012.08.06 18.40, Jacob Appelbaum wrote: Eleanor Saitta: It is true that you have to trust the server operator in both cases. However, having a server configuration which does not completely compromise user privacy (vs. the operator) by default, like Facebook does, is still a significant improvement in many use cases, as is the ability to have a diversity of server operators. That is only true if they play nice. No, some potentially good server operators, in aggregate, are better for a population of users than a single operator known to leak data under many conditions. So this is where a lot of people take issue - you say will be without the acknowledgement that SSL has major issues and that it is thus, broken by many actors, right now. At least with the plugin version, we can try to mitigate that harm right now. Except that with your harm mitigation, you push many potential users back to plaintext, where they are guaranteed to be owned. What percentage of potential cryptocat users would the plugin version have to stop from using the tool for you to accept that there was a place for the non-plugin version? If it's 100%, what you're actually saying is that you would rather those users had no security than even a chance at security through diversity. It has been 21 years since PGP was released. To this day, it remains a niche product at best. Users with real world security concerns rarely if ever use encrypted email. It is exactly this attitude which is to blame. Right and OTR is the counter example. Will Cryptocat be the middle ground, where it's perfectly easy to use cryptography but missing key items that make it safe? OTR in a traditional thick client is an example of a tool which provides good security while being realistically usable for technical users with full access to their machine. Don't get me wrong, it's great, but there are also users who can and will not be able to use it. They need tools too. It seems that you're speaking generally here because otherwise, it's unbelievably rude and frankly, silly. For better or worse - I've contributed countless hours to helping Nadim with Cryptocat. I am largely speaking generally, but I'm also speaking specifically in the sense that you've actively undermined the utility of a tool here by encouraging Nadim to not make it available to users who cannot install software, which is and was the only reason to use it. Having both versions available is a reasonable compromise, but suggesting that the web version never be used is counterproductive given the userbase in question. I understand and appreciate your contributions in time -- I'm definitely not attempting to minimize that -- but you're still refusing to acknowledge that there exists an underserved userbase. E. -- Ideas are my favorite toys. ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
Re: [liberationtech] Independent Communications Platform - Need Programming Crew
Please see the Briar Project, at http://briar.sourceforge.net. We're happy to take on more resources, but yes, there are people working on things like this. E. On 2012.07.31 16.12, David Majlak wrote: Thesis: To provide an independently and individually(collectively) controlled communications platform in order to decentralize human reliance on corporate platforms and testy government infrastructure (i.e. dictatorships, censorship, etc). -- Ideas are my favorite toys. signature.asc Description: OpenPGP digital signature ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
Re: [liberationtech] If we want to be anonymous in #azerbaijan we take batteries out of our cellphones
On 2012.06.18 13.29, Parker Higgins wrote: On 6/18/12 8:36 AM, Yosem Companys wrote: Hi Liberationtech folks, is this always the case? I've heard cases where people can still be tracked whether they have batteries in their cell phones or not... I've spoken with mobile security researchers who have given me the impression that this theory hasn't been tested very much. It's theoretically possible that some phones could be recording or transmitting without the main battery, but the equipment that would be required to test is prohibitively expensive and you'd have a hard time demonstrating anything but an evidence of absence. Unless there's a specific secondary battery powering a transmitter, it is improbable in the extreme that an unpowered passive device can have its location tracked at a distance of more than, say, a hundred meters, and any tracking at all is extremely unlikely. Cellphones don't work that way, and physics says no, basically. Now, *people* are very easy to tail, when you have a human doing the work. That's a different story. There are almost certainly many more pressing issues to worry about when it comes to locational privacy than a battery-less phone. E. -- Ideas are my favorite toys. signature.asc Description: OpenPGP digital signature ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
Re: [liberationtech] FB-like Twitter-connect soon. How can we avoid all this tracking?
On 2012.05.25 16.37, Sarah A. Downey wrote: I'll respond to your everything must be open source statement, although I'm fairly certain it won't have any effect on your opinion that closed always equals bad. And please keep in mind that we're giving away a /free /add-on with /zero /tracking of or advertising to its users. It's an unnecessarily restrictive and self-handicapping position that software /must /be open source to be useful for privacy. Plenty of open source privacy tools have come and gone in the past because they aren't sustainable without funding. Our software does what it says, and it's designed to be simple enough that the vast majority of Internet users--people who aren't coders or particularly tech savvy--can use it. The problem here is that we don't trust you. It's nothing personal. We don't trust anyone, unless we can verify. If we can't see exactly what the tool does, we don't have a way of verifying what it does. This is critical normally, but much more important for tools that claim to provide privacy or security protection. There are a lot of ways around this. Open source is one of them. Providing source access to independent auditors under a license that does not restrict them from talking about what it does and how it does it is another. If you're not willing to be open about exactly how your tool protects my privacy, why should I trust that you got it right? No, I don't expect all users will check, or care, but some of us will, and we tell others what they should use. Privacy, like crypto, is *hard*. Would you trust someone who claimed to have a super-secure crypto algorithm that they wrote themselves that's never been peer reviewed? No. Why should we do it with a privacy tool? E. -- Ideas are my favorite toys. signature.asc Description: OpenPGP digital signature ___ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click yes (once you click above) next to would you like to receive list mail batched in a daily digest? You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
