Re: [liberationtech] Question EFF CA Let's Encrypt
On Wed, Nov 19, 2014 at 3:13 PM, Richard Brooks r...@g.clemson.edu wrote: Just looked at this: https://letsencrypt.org/howitworks/technology/ The EFF's new CA to make things cheap and easy for installing certs. I like the goal. What I do not get from the description is how they really verify that I legitimately own the site. If I should manage to reroute some traffic and do DNS cache poisoning on a web-site address, wouldn't the system accept my web-site as valid? It seems like they are accepting the fact that you can reach the site using DNS information (which is not secured) as proof of legitimacy. Or is there something I am missing? Yes, you appear to be missing that _many_ CAs are already using domain validation less sophisticated than what is proposed there. (e.g. godaddy is one example, I believe startssl is another) E.g. you prove ownership to them by them fetching a file with a specified name over http from a single location. There are also CAs with special agreements like digicert will instantly issue to cloudflare a cert for any domain which resolves to a cloudflare IP block. -- 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] Fwd: Question EFF CA Let's Encrypt
On Wed, Nov 19, 2014 at 3:13 PM, Richard Brooks r...@g.clemson.edu wrote: Just looked at this: https://letsencrypt.org/howitworks/technology/ The EFF's new CA to make things cheap and easy for installing certs. I like the goal. What I do not get from the description is how they really verify that I legitimately own the site. If I should manage to reroute some traffic and do DNS cache poisoning on a web-site address, wouldn't the system accept my web-site as valid? It seems like they are accepting the fact that you can reach the site using DNS information (which is not secured) as proof of legitimacy. Or is there something I am missing? Yes, you appear to be missing that _many_ CAs are already using domain validation less sophisticated than what is proposed there. (e.g. godaddy is one example, I believe startssl is another) E.g. you prove ownership to them by them fetching a file with a specified name over http from a single location. There are also CAs with special agreements like digicert will instantly issue to cloudflare a cert for any domain which resolves to a cloudflare IP block. -- 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] Signed HTTP
On Tue, Mar 11, 2014 at 12:37 PM, Patrick Schleizer adrela...@riseup.net wrote: Natanael: It would probably be as easy as using SSL with a null cipher with authentication like poly1305. I preferred to sign the source files on my local hdd using a tool that internally uses gpg. That way the SSL CA's wouldn't have any power over it, neither the web server. If we were to rely on web servers / SSL CA's for this, I wouldn’t see the benefit in signing http. Please be very careful not to conflate signatures and authentication. SSL and null cipher with auth would provide authentication but not signatures. Signatures provide non-reputation, which is very useful in some contexts, and somewhat harmful in others. There are applications where non-reputation of web-page data would be quite useful. Esp if it can be extracted from inside the encryption. I'm mostly drawing a blank on why you'd want authentication without encryption, however, encryption is cheap. -- 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] Stanford blocking webmail access to those who refuse spyware
On Fri, Feb 7, 2014 at 9:52 AM, taltm...@stanford.edu wrote: This is the kind of heavy hand that Stanford is laying down on students and faculty who do not want to give up their privacy. This seemed to me like an inevitable outcome when there was little to no backlash against spyware requirements for exams in most law-schools. (unless you want the massive disadvantage of turning in your exam on paper…) I can't fathom how people it was remotely acceptable to require the installation of spyware on students systems at institutions training people for work which handles confidential client information where running such software ought to be considered an violation of professional conduct. But there you go— the world is an unfathomable place and here we have just a natural continuation of that unfathomably. Cynically, I might suggest that the issue causing the complaints is not the spyware, is that you don't get anything in return for it that you weren't already receiving. -- 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] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net
On Mon, Jan 13, 2014 at 4:57 AM, carlo von lynX l...@time.to.get.psyced.org wrote: Sorry for spoiling this apparently easy solution, but the Internet is currently more broken than that. I don't think you're spoiling it. I use 0bin only for things I'd otherwise use a non-encrypted tool for... I'm sure some users make errors by assuming too much security there, but considering that the alternatives aren't 1/100th as accessible I'd have a hard time arguing that the tools aren't a net gain. They could perhaps be improved if they suggested a more secure alternative. -- 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 14th reason not to start using PGP is out!
On Thu, Nov 21, 2013 at 12:31 AM, elijah eli...@riseup.net wrote: I don't need to beat a dead horse, but nearly every email from carlo contains one or more logical fallacies. This email contains two: the strawman fallacy (enigmail has poor security, so no usage of OpenPGP can have good security) and the composition fallacy (hkp keyservers are part of how OpenPGP works, and they leak metadata, so you can't protect metadata with OpenPGP). So, A spherical user in harmonic motion could use the system safely on alternative Tuesdays. Q.E.D. ? Common, recommended applications and usage patterns have this problem. It isn't a strawman to argue out that PGP is widely unsafe in practice, and to support that position with specific examples. AFAICT every complaint he makes is rooted in real limitations in the technology or the surrounding ecosystem as deployed, and the limitations are substantive and of a kind which could cause people harm. They may not apply universally, but that they apply at all is a problem. Instead of spending your time pattern matching his messages with prefabricated excuses to ignore them... why not also work on trying to improve the ecosystem so that the security of PGP in practice is unimpeachable, even by arguments 'merely' grounded in an assumption that a user isn't using perfect software or engaging in perfect usage? -- 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] 10 reasons not to start using PGP
On Fri, Oct 11, 2013 at 10:24 AM, Tempest temp...@tushmail.com wrote: Gregory Maxwell: My other big technical complaint about PGP is (3) in the post, that every encrypted message discloses what key you're communicating with. PGP easily _undoes_ the privacy that an anonymity network like tor can provide. It's possible to use --hidden-recipient but almost no one does. i am often a bit confused as to why people take issue with the fact that gpg/pgp isn't anonymous. i don't recall the technology ever being proposed as such. rather, effort was made to have mechanisms to verify the identity of a sender. however, if one creates an identity and keypair that as only been used over tor, what's the problem? creating and maintaining anonymity is an entirely different subject that gpg/pgp was not created to address. Security is a complicated subject. The exact properties you need to be secure depend on your threat model. You add encryption via PGP because you know you need encryption in order to be secure against your threat model. But without it being very obvious PGP has written a long term identity fingerprint encoded in the opaque base64 data which distinguishes your messages by recipients. This long term identity key can _increase_ your vulnerability to traffic analysis over using nothing at all. It does so invisibly to many users. It may be a very bad thing for your threat model. I think communications security tools ought to avoid increasing vulnerability to any common threats to the greatest extent that they can, and when they must compromise they should make it obvious. Both for non-repudiation and resistance to traffic analysis PGP dramatically reduces user security and does so in a way which is not obvious to any except the most advanced users. Both of these could be fixed with basically no user impact: Make hidden-recipient the default and allow optional clear-text recipient list on ascii armored output; add an authentication mode which is used by default instead of signing for encrypted messages that uses ring signatures (and don't allow unauthenticated encryption, geesh). effort was made to have mechanisms to verify the identity of a sender PGP actually has no mechanism for that. Thats authentication. Instead PGP substitutes non-repudiation for that purpose, which is a superset of authentication which reduces security in many situations. PGP provides basically no way for me to convince you that I'm the author of a message without also making it possible for you to prove it to the whole world. Sometimes you want this— for contracts and such— but usually you just want authentication. if one creates an identity and keypair that as only been used over tor Say you are a famous anonymous developer that creates software for dissidents to help them connect to tor. You have a nice anonymous key that is well known to belong to you. Do you think any of your users should want to send you email to anonymous one time use tech support mailboxes using that key, provably showing they were communicating to you to anyone who can monitor their email? Do you think your users will even realize that sending you messages will expose them? -- 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] 10 reasons not to start using PGP
On Fri, Oct 11, 2013 at 12:10 PM, Tempest temp...@tushmail.com wrote: a fair point. but one could significantly address this issue by hosting the public key on a tor hidden service. that would greater ensure that, in order to get your key, they would be using a system that protects against such threats. hardly an easy solution. but it can be solved with a little extra planning. Of course, if you can do this and the HS is secure, then you can just dispense with the PGP altogether. You can work around the limitations I've pointed to here... You messages via hidden services without pgp at all.. or you can create per-recipient symmetric keys which you clearsign then encrypt with hidden-recipent to each person you want to talk to, then symmetrically encrypt your actual messages, and discard once a conversation is done. But no one does, because it's hard, and some of PGP's downsides are subtle. -- 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] 10 reasons not to start using PGP
I'm surprised to see this list has missed the thing that bugs me most about PGP: It conflates non-repudiation and authentication. I send Bob an encrypted message that we should meet to discuss the suppression of free speech in our country. Bob obviously wants to be sure that the message is coming from me, but maybe Bob is a spy ... and with PGP the only way the message can easily be authenticated as being from me is if I cryptographically sign the message, creating persistent evidence of my words not just to Bob but to Everyone! When there are only two parties in an encrypted communication this is _trivial_ to solve cryptographically: just use DH to compute a shared secret and use it to authenticate the message. (Multiple parties is solvable too, but requires a ring signature or other more complicated solution). But PGP has no real solutions for that. My other big technical complaint about PGP is (3) in the post, that every encrypted message discloses what key you're communicating with. PGP easily _undoes_ the privacy that an anonymity network like tor can provide. It's possible to use --hidden-recipient but almost no one does. Its also easy to produce a litany of non-technical complaints: PGP is almost universally misused (even by people whos lives may depend on its correct use), the WOT leaks tons of data, etc. In my view the use of PGP is more appropriately seen as a statement about the kind of world we want to have— one where encryption is lawful, widely used, and uncontroversial— and less of a practical way to achieve security against many threats that exist today. -- 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] Open Whisper Systems' neat asynch FPS pre-keying
On Thu, Aug 22, 2013 at 11:03 AM, Joseph Lorenzo Hall j...@cdt.org wrote: TextSecure’s upcoming iOS client (and Android data channel client) uses a simple trick to provide asynchronous messaging while simultaneously providing forward secrecy. I've seen people want PGP to do this before— have every encrypted and signed message you send include a number of single use ephemeral reply coupons, to be used instead of key agreement with a fixed key... The primary argument against it is that if the receiver changes systems the messages will be undecodable. You can do things to prevent this, like backing up your tokens, but that defeats PFS. -- Liberationtech is a public list whose 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] Freedom Hosting, Tormail Compromised // OnionCloud
On Tue, Aug 6, 2013 at 3:11 PM, Florian Weimer f...@deneb.enyo.de wrote: (Automated updates are a mixed blessing because they could invite court orders to roll out specific versions to certain users.) No crap. _please_ don't deploy automatic updates in a sensitive environment like this without at least quorum signatures (like gitian downloader) and timed quarantine with negative signatures (harder to make strong absent a jamming proof network). -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz r...@iit.edu wrote:
Hi folks,
Thank you very much for your great feedback on the previous version. The
next version is now up at http://passlok.com, which redirects to
https://passlok.site44.com
This may come in handy now that there are problems with Tor, since PassLok
allows you to go to any computer to do encrypted mail, because there is
nothing to install. This is what PassLok was designed to do.
The other unforeseen endorsement came from the recent Black Hat conference.
Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel
encouraged everyone to base their public key cryptosystems on elliptic
curves rather than RSA. Here's a link on this:
http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/
Wait. You are using vague popular press FUD about RSA to promote a
website hosted JS encryption tool? Really?
Your code generates random values like this:
sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
a.clientY || a.offsetY || 0], 2, mouse)
sjcl.random.addEntropy((new Date).valueOf(), 2, loadtime)
try {
var s = new Uint32Array(32);
crypto.getRandomValues(s);
sjcl.random.addEntropy(s, 1024, crypto['getRandomValues'])
} catch (t) {}
Meaning that if it's used someplace where crypto.getRandomValues()
doesn't exist, it has only pure snake-oil-extract randomness.
Really
If the randomness is poor, the nonce used in ECDSA will be predictable
and the private key will be recoverable.
This isn't to say I've audited any of it, I just grepped for a couple
likely mistakes. Part of the JS code has been whitespace compressed, I
consider it unauditable.
up to a whopping
200,000 iterations for lousy keys. Since keys made in version 1.2 are no
longer compatible, this prompts upping the version to 1.3.
So, not implemented in slow-as-dirt JS 200,000 iterations should take
a random desktop cpu about 100ms or so. This is hardly wopping. It's
not far from the minimum I'd start with, for all keys not just weak
ones. Generally user provided keys are a security disaster and should
be avoided wherever it's possible, strengthening or no. Humans are
horrific entropy sources and really can't self assess how bad they
are.
--
Liberationtech list is public and archives are searchable on Google. Too many
emails? Unsubscribe, change to digest, or change password by emailing moderator
at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz r...@iit.edu wrote:
Hi folks,
Thank you very much for your great feedback on the previous version. The
next version is now up at http://passlok.com, which redirects to
https://passlok.site44.com
This may come in handy now that there are problems with Tor, since PassLok
allows you to go to any computer to do encrypted mail, because there is
nothing to install. This is what PassLok was designed to do.
The other unforeseen endorsement came from the recent Black Hat conference.
Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel
encouraged everyone to base their public key cryptosystems on elliptic
curves rather than RSA. Here's a link on this:
http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/
Wait. You are using vague popular press FUD about RSA to promote a
website hosted JS encryption tool? Really?
Your code generates random values like this:
sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
a.clientY || a.offsetY || 0], 2, mouse)
sjcl.random.addEntropy((new Date).valueOf(), 2, loadtime)
try {
var s = new Uint32Array(32);
crypto.getRandomValues(s);
sjcl.random.addEntropy(s, 1024, crypto['getRandomValues'])
} catch (t) {}
Meaning that if it's used someplace where crypto.getRandomValues()
doesn't exist, it has only pure snake-oil-extract randomness.
Really
If the randomness is poor, the nonce used in ECDSA will be predictable
and the private key will be recoverable.
This isn't to say I've audited any of it, I just grepped for a couple
likely mistakes. Part of the JS code has been whitespace compressed, I
consider it unauditable.
up to a whopping
200,000 iterations for lousy keys. Since keys made in version 1.2 are no
longer compatible, this prompts upping the version to 1.3.
So, not implemented in slow-as-dirt JS 200,000 iterations should take
a random desktop cpu about 100ms or so. This is hardly wopping. It's
not far from the minimum I'd start with, for all keys not just weak
ones. Generally user provided keys are a security disaster and should
be avoided wherever it's possible, strengthening or no. Humans are
horrific entropy sources and really can't self assess how bad they
are.
--
Liberationtech list is public and archives are searchable on Google. Too many
emails? Unsubscribe, change to digest, or change password by emailing moderator
at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Is Most Encryption Cracked?
On Wed, Jul 17, 2013 at 10:18 AM, Collin Sullivan coll...@benetech.org wrote: http://unsene.com/blog/2013/06/15/is-most-encryption-broken/ HALP. I've slipped on a snake oil spill and can't get up! [...]Here’s why we think many of these encryption algorithms are cracked; [...] • These entities want something complicated enough to keep others out, but easy enough for them to get into. Your secret is safe with them. If this is true its an argument for using standard encryption: Knowledge of the fact that the US government has cracked AES would be so insanely valuable, and it's leak so devastating a loss of capability that unless you presented an existential threat they wouldn't dare do something that could possibly leak this fact. • They are using computer technology that’s at least 30 years advanced [...] someone says “that’ll take 30 years to crack”, they mean you’ll have to take 30 years to try all the possible keys. With a quantum computer, that’s less than a second. Even Google is now buying quantum computers, this one for $10 million. This is a a bit of recursive snake-oil: I assume what this is referring to is the much criticized DWAVE systems. The dwave devices are claimed to be quantum simulated annealers. They are not purported to be quantum turing complete. They perform a single algorithm (which generalizes to classical computation, but not quantum computation) and are not even theorized to be able to do the things an actual quantum computer is theorized to be able to do. This isn't to say that they may not be useful for some applications, but it doesn't appear that breaking AES is among those applications which is it even theoretically useful for. People often misunderstand the expected capabilities of quantum computers they are not even _theorized_ to perform exponential in poly time in the general case. There are some tasks which would be much faster on quantum computers (such as quantum simulation and factoring), and other tasks that could at best be only moderately faster. Cracking symmetric ciphers generally falls into the latter category, as the best general speedup against non-linear search that quantum computation can give is a sqrt() speedup (analogous to halving the number of bits of keyspace). Though perhaps cryptographers doing cryptanalysis with the help of QC powered theorem provers might be a bit more potent at finding regular classical attacks. :) • Public domain encryption wouldn’t be allowed into the pubic unless it was cracked, because they wouldn’t be able to spy on you. They wouldn’t be promoting something as good unless it was easy for them to get into it. They’re spies after all. I know a bunch of cryptographers, and I don't know any in the US who are having their scheme suppressed in recent memory. So this one requires that you believe not that shadowy government groups are suppressing stuff, but that no one is even coming up with anything secure at all. This streaches credibility, and even if the claim were true why would this particular thing be the exception? Maybe the next step in the plan is that when their crowfunding gets taken down for being snakeoil they'll claim their work was too good to be allowed to exist? -- 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] Designing Fairness for DMCA
On Tue, Jul 16, 2013 at 1:00 PM, John Adams j...@retina.net wrote: http://www.mediabistro.com/appnewser/files/2012/02/infographic-dmca-process1.png The process here is not correct— or at least it has some unstated assumptions and a confusing presentation. For example, if— as a safe harbor enjoying service provider— the complaint is obviously bogus and as a result you don't care to lose the safe harbor in this particular instance, you can skip the entire process and deposit the DMCA notice into the trash. (This is, for example, why the public can't simply manage to keep the whitehouse website ~permanently disconnected from the internet with a stream of endless bogus complaints anti-dmca activists engaging in civil disobedience) It seems to be intermixing the roles of the safe harbor enjoying service provider and the non-protected posting party. The initial steps are all service provider roles, the but counter-notice is provided end user. The question posted there carries the wrong implication too: a user who has violated copyright is not protected from ending up in court just because they don't counter notice. -- 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] Designing Fairness for DMCA
On Tue, Jul 16, 2013 at 1:00 PM, John Adams j...@retina.net wrote: http://www.mediabistro.com/appnewser/files/2012/02/infographic-dmca-process1.png The process here is not correct— or at least it has some unstated assumptions and a confusing presentation. For example, if— as a safe harbor enjoying service provider— the complaint is obviously bogus and as a result you don't care to lose the safe harbor in this particular instance, you can skip the entire process and deposit the DMCA notice into the trash. (This is, for example, why the public can't simply manage to keep the whitehouse website ~permanently disconnected from the internet with a stream of endless bogus complaints anti-dmca activists engaging in civil disobedience) It seems to be intermixing the roles of the safe harbor enjoying service provider and the non-protected posting party. The initial steps are all service provider roles, the but counter-notice is provided end user. The question posted there carries the wrong implication too: a user who has violated copyright is not protected from ending up in court just because they don't counter notice. -- 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] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: Hi! I am a bit concerned with the CJDNS hype I am observing around. I do like that decentralized Internet is getting momentum, but I am concerned if CJDNS is really the way to achieve that. From its whitepaper it seems that it is susceptible to a Sybil attack: After this thread started I wrote to the author— as I'd pointed out before I had the same concerns initially but had spoken to him and basically came away with an impression that he was aware of the problem space and wasn't doing the dumbest possible thing as a result— and there was at least a fighting chance that the system addressed the issue, but I didn't care (or, really, have time) to understand more at the time, so I couldn't write an actual explanation. He seems to be having some problems getting onto the list, so he sent me a response to reflect up to it: - CUT HERE - The answer to ID clustering attacks is that cjdns is just really lazy, it routes to the physically nearest node whose ip address is numerically closer to the destination than your own (based on KAD). Since the physical topology is friend-to-friend, the attacker is forced to have a relatively tight cluster of nodes in physical space, they can pollute their own neighborhood but not the whole network. Pollution of one physical neighborhood would likely lead to them being de-peered by their friend who gave them the link. Re the recursive routing, it has two options. You can send direct to the destination at the switch level or you can forward to any node in the network and ask them to forward to the destination. The nodes between you and the one you asked to forward will have no access to the IPv6 dest address and if the one you are forwarding to us unfriendly, you use someone else. We've considered changing this to improve scalability but I can't figure out how to preserve this guarantee. The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Again though the physical reality of the network comes in to play. The nodes which carry the majority of the traffic are heavily peered core nodes and the operators of such are unlikely to intentionally attack the network, this is the same logic which holds BGP together despite it's painful frailty. Hope that helps Thanks, Caleb -- 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] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: Hi! I am a bit concerned with the CJDNS hype I am observing around. I do like that decentralized Internet is getting momentum, but I am concerned if CJDNS is really the way to achieve that. From its whitepaper it seems that it is susceptible to a Sybil attack: After this thread started I wrote to the author— as I'd pointed out before I had the same concerns initially but had spoken to him and basically came away with an impression that he was aware of the problem space and wasn't doing the dumbest possible thing as a result— and there was at least a fighting chance that the system addressed the issue, but I didn't care (or, really, have time) to understand more at the time, so I couldn't write an actual explanation. He seems to be having some problems getting onto the list, so he sent me a response to reflect up to it: - CUT HERE - The answer to ID clustering attacks is that cjdns is just really lazy, it routes to the physically nearest node whose ip address is numerically closer to the destination than your own (based on KAD). Since the physical topology is friend-to-friend, the attacker is forced to have a relatively tight cluster of nodes in physical space, they can pollute their own neighborhood but not the whole network. Pollution of one physical neighborhood would likely lead to them being de-peered by their friend who gave them the link. Re the recursive routing, it has two options. You can send direct to the destination at the switch level or you can forward to any node in the network and ask them to forward to the destination. The nodes between you and the one you asked to forward will have no access to the IPv6 dest address and if the one you are forwarding to us unfriendly, you use someone else. We've considered changing this to improve scalability but I can't figure out how to preserve this guarantee. The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Again though the physical reality of the network comes in to play. The nodes which carry the majority of the traffic are heavily peered core nodes and the operators of such are unlikely to intentionally attack the network, this is the same logic which holds BGP together despite it's painful frailty. Hope that helps Thanks, Caleb -- 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] CJDNS hype
On Sun, Jul 14, 2013 at 8:28 PM, Caleb James DeLisle calebdeli...@lavabit.com wrote: You'd need a botnet to attack the network because then you could have nodes spread out over physical space but clustered in keyspace. And, presumably, convince people to connect to them. If I understood correctly? -- 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] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: For me it seems far from something which would be resistant to any adversary trying to prevent communication from happening. It seems to me that it just ignores many of issues with DHTs and routing in overlay networks put out in research literature until today. Which is DHT's are basically a complete joke when it comes to attack resistance, and so it's with much face palming that I've endured near constant suggestions to Use a DHT!, often in completely inapplicable contexts, from people whos only exposure to distributed systems is DHTs. It's basically a running joke in the Bitcoin development community at this point. That said CJ is, in fact, aware of these issues— and CJDNS is at least intended to be resistant to sibyl attacks under some assumptions (I believe the main assumption is that you choose honest peers for your transport links (and that your honest peers also do so), because it isn't simply a topology blind DHT). The system is setup to require manual peering, so it isn't just a handwave— it's how you're expected to use it. (Now, how strong that requirement is isn't clear to me, e.g. how does your security fall off as a function of distance to honest nodes— or how realistic even the weakest form of that requirement is in practice, e.g. can even a spherical-technical-expert manage to reliably pick non-sybil peers— is another question.) Some of the other concerns about CJDNS is that its not— by itself— an anonymity network. Its anonymity properties are weaker than TOR's, for example. Though it may be the case that the composition of CJDNS and a high latency (/CBR) mix network might better address the spectrum of needs, there is still the risk that people may misunderstand what is actually being provided. -- 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] Government surveillance technical details hiding in plain sight
On Sun, Jun 9, 2013 at 4:32 PM, Gregory Maxwell g...@xiph.org wrote: I've been continually amazed at how poorly the public has been doing at figuring out the mechanisms used for this stuff— You don't need some insider to tell you how it works, you could have just looked up Counter evidence to my complaint that deserves mention: http://www.reddit.com/r/TrueReddit/comments/1gdquv/i_present_adobe_insight_that_same_adobe_building/ -- 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 Anonymity Network for Short Messages
On Tue, Jun 11, 2013 at 9:52 AM, Sean Cassidy sean.a.cass...@gmail.com wrote: I have created a simple anonymity network that broadcasts all messages to participants so that you cannot associate chatters. https://bitbucket.org/scassidy/dinet See also: https://bitmessage.org/wiki/Main_Page (I have some reservations about the design-as-of-last-I-looked: The round trip required to obtain the far-end's public key significantly degrades the security properties— but they've been actively developing it, so that may well have been fixed by now). -- 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
On Tue, Jun 11, 2013 at 6:56 PM, Kate Krauss ka...@critpath.org wrote: It's really easy to use these tools if you already know how to do it. I've been using PGP since 1994, if not earlier. In more recent times it's become a regular part of my workflow in discussing security critical bugs. I am a programmer and a computing expert. I do not consider the tools easy to use at all but I understand their importance and use them with other people who understand their importance, _in spite_ of the fact that they are burdensome. I am large unable to get people who do not understand their importance to use them. Or even if I get them to use them once, because the tools require an effort to use on an ongoing basis they do not use them reliably. The only shining ray of success I've experienced in this space is OTR, and but my personal experience is that even that is failing as more people move away from using pidgin and adium to chat systems which OTR does not as easily integrate with. -- 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] Mechanisms of intercepting service provider internal connectivity
On Fri, Jun 7, 2013 at 6:47 AM, Eugen Leitl eu...@leitl.org wrote: but the ability to assemble intelligence out of taps on providers' internal connections would require reverse engineering the ever changing protocols of all of those providers. This is somewhat less difficult than some people think. Various equipment manufacturers have implemented passive monitoring support on their interfaces specifically for these applications. You configure the interface to go into UP/UP state and to listen in a half duplex manner. This way you get the compatibility advantage of using standard network equipment to implement the interception, and so it will likely speak the same link-layer protocols the device being intercepted speaks. (E.g. here is some of the relevant documentation for Juniper: http://kb.juniper.net/InfoCenter/index?page=contentid=KB23036 and https://www.juniper.net/techpubs/en_US/junos11.2/topics/concept/flowmonitoring-passive-overview-solutions.html ) A lot of the mechanisms— the protocols, techniques, equipment features— for mass surveillance are easily visible to the public but the things visible to the public are all technical minutia dealing with the practical engineering challenges (Like the one you raise here— how the heck do you keep up with the ever changing layer 1/2 protocols used by service providers) that most people wouldn't even think to ask about. Using commodity hardware gets you compatibility, lower costs, and fast deployment. Even though budgets for massive surveillance no doubt allow for all kinds of specialized hardware— you can get more of it faster if you use commodity stuff with a few tweaks where you can. Here's another tidbit in public docs: Another challenge in implementing massive surveillance is the sheer volumes of traffic involved. People do seem to be aware of this one, but they argue that it makes the task impossible but there are few technical challenges which can't be solved by the suitable application of ingenuity and money. (_Lots_ of money: but keep in mind defense spending is just on another order of magnitude from regular spending. How much does a fighter jet cost? A one time use smart munition? How much more valuable is a good network tap than these devices? In light of that— how much is a fair defense industry price for one?) One way that the traffic volume problems gets solved is to realize that the vast majority of traffic is uninteresting. If you can rapidly filter the traffic you can throw out the 99% of uninteresting stuff and capture all of the rest. Filtering is, of course, computationally expensive— but it turns out that the power of 'commodity' technology can come to the rescue again: The same standard networking equipment that you need to speak the L1/L2 protocols on your optical taps also has built in line-rate packet filtering with scalability to millions of filter criteria (at no extra cost! :) ). The filtering in these devices has not historically been DPI grade: you can do stateless range/prefix matches on the packet headers, not free-form regex (although this is changing and the latest generation of hardware is more powerful— the need for NAT everywhere, if nothing else, is mandating it). But, if you can update those filters very fast— say, in under 50ms— then it doesn't matter that the filters aren't very powerful: Configure the filters to catch all known interesting hosts, the beginning of every new connection, and some small fraction (say, 1:1 of all packets) and then feed that data to analysis systems which trigger updates to the filters when they spot something interesting. They only need to be powerful enough to limit a terabit of traffic to tens of gigabits, and that level of filtering can be accomplished just on 5-tuples.. You can go even further, then, by having two sets of filters with a delay line— say implemented using the 100ms of delay-product packet buffers in high end commodity networking hardware— in between them. The first set of filters catches enough so that your analysis systems can identify and track interesting flows, and by the time the traffic makes it through the delay line the second set of filters has been updated to capture the entirety of the interesting flow. ... though the persistence of traffic and the delay created by the TCP three way handshake make going this far not terribly necessary. Of course, using filtering in this way would require a protocol between the network elements and the analysis systems so that they could rapidly and dynamically 'task' the filters like you task surveillance satellites... And it sure would be convenient if the protocol was standardized so you could get many kinds of devices speaking it. ... something like: http://tools.ietf.org/html/draft-cavuto-dtcp-03 (and here is one vendor's helpful documentation on applying it,
[liberationtech] Why we can't go back to business as usual post-PRISM.
Many people in spheres of cryptography and digital rights activism have long assumed (or—frankly—known about) pervasive government surveillance of the Internet and other communications networks. So it's unsurprising that there is something of an undertone in PRISM discussions of meh, it's terrible but it's not really news or even so far, this is less bad than I was assuming. It would be nice to think that we could go back to business as usual, quietly fighting (or tolerating) these intrusions—but I don't believe we can. The recent revelations come with a radical increase in the risk of harm from these programs, even to those who were already assuming they existed. To understand why, it might be helpful for me to share how I answer this unrelated question: Why would you use AES/RSA/etc. when the NSA employs more mathematicians than anyone else and may well have cracked them? The answer: if the popular cryptographic constructs have been cracked, the knowledge that they were cracked—even without the how—would be insanely valuable. So much so that unless you presented an existential threat to the cracking party, they would be very hesitant to use that ability against you if even a tiny risk existed that doing so could reveal their capability and thereby make it less valuable. In the case of mass surveillance programs not only is there a risk that people would change behavior—switching to SSL with PFS for all communications, making more use of high-delay mixing networks, decentralized services, non-cloud open source software, etc.—but since these programs are obviously illegal to many outside of the incestuous world of intelligence, by revealing the capability they risk it being simply taken away by the rule of law. (Even those who have convinced themselves that these programs are lawful and righteous must recognize that they are on thin ice and public opinion may go another way). And so—before the capability was made public, it _likely_ wouldn't have been used against mere political nuisances, at least not without the additional cost of creating a solid pretext for the resulting intelligence. But now this deterrent is gone: the burden of utter secrecy is reduced. And if these programs are not eliminated, greatly curtailed, or made moot, we can expect them to be employed much more freely. -- 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] Efficient digital one-way communication
On Mon, Mar 4, 2013 at 11:45 AM, Jens Christian Hillerup j...@hillerup.net wrote: Yes, and then I can scrap the stereo encoding again. I'd rather have it optional than required. And I agree, it would make more sense to pick eight notes and use them as a bitmap. We'd face the same problems as we did before with the harmonies, but that problem does not get any bigger or smaller so I don't see the point in not implementing it. Idea: parity information in the overtones? Not applicable if we go with Reed-Solomon codes, though. Modem design is a science with something like 70 years of history. The modem technology is probably a discussion hashed out on places full of DSP / modem gurus like the GNURadio lists, rather than a list full of activists. There are many complex technical considerations that depend on the properties of the underlying radio transport. Figuring out what kinds of hardware and channels (bandwidth, noise characteristics) are potentially available would be a good thing for activists to get sorted out before going to the DSP gurus and saying we want to support (one/two way) digital comms at this bitrate over this hardware / spectrum / under these conditions, what should we use here? -- 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] Internships available at leading Palo Alto tech startup
On Fri, Feb 22, 2013 at 9:52 AM, Greg Norcie g...@norcie.com wrote: Unpaid internships are illegal actually. Unless receiving course credit from a university - then they're just morally unsound :) But such a great research opportunity to go find out about more privacy invading technology and the companies that are employing it, so that you can bring their unethical conduct to light and help develop counter-measurements! -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Using Gajim Instead of Pidgin for More Secure OTR Chat
On Wed, Feb 20, 2013 at 10:27 PM, Micah Lee micahf...@riseup.net wrote: I just wrote a blog post that people here might find interesting about using Gajim, a chat client written in python, and Gajim's OTR plugin, a purely python implementation of the OTR standard, instead of Pidgin and libotr. Uh. Writing something in python does not make it magically secure. It often trades one set of security issues for another— in higher level languages programmers often have no idea what the underlying machine is doing, and surprising behavior can easily slip in. E.g. I've seen programs python programs that could be triggered to run arbitrary commands on the system, for example, because some library they called n levels deep passed arguments to an os.system(). The mistakes you need to avoid to write secure C code are more easily made but there are generally fewer ways to fail. Personally, I run pidgin in a selinux sandbox in a KVM that I use for other internet access. I'd like to also run it inside valgrind modified to exit on error, but pidgin is thoroughly and depressingly valgrind unclean and with all the white-listing required I'm not sure how much marginal value that would provide (and Openssl itself for that matter, though for stupid reasons). Perhaps Gajim is an improvement of pidgin, but the criteria for that is auditing and experience— not the language its written in. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Cryptography super-group creates unbreakable encryption
On Thu, Feb 7, 2013 at 8:36 AM, Douglas Lucas d...@riseup.net wrote: Can Silent Circle promoters explain why Zimmerman is excused from Kerckhoffs's principle? Is it because something unverifiable is allegedly better than nothing? Even if we had divine knowledge to tell us Silent Circle is secure, isn't it an overriding problem to encourage lock-in of closed source being acceptable for something as common as text-messaging? Even if it were acceptable because we trust the source this time that won't be clear to the public— and the next unscrupulous sake oil salesman who comes around using identical marketing will look just as trustworthy to the public. Accordingly, this work still demands a strong negative reaction if we're to continue to established in people's mind that snazzy names, buzzword technobable, and big claims do not show security products to be trustworthy: Only independent auditing and open code do. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Cryptography super-group creates unbreakable encryption
On Thu, Feb 7, 2013 at 9:12 AM, Christopher Soghoian ch...@soghoian.net wrote: My area of research is the intersection of law, policy and technology. As such, I am most interested in companies' surveillance policies, their commitment to transparency, and their stated willingness to tell the government to GTFO if they come and ask for backdoors. On this front, Silent Circle is extremely interesting, probably more so than any other Internet company. You may think these are your preferences, but what you're saying makes it clear that your preferences are actually subtly different. If someone says we won't put in 'lawful surveillance' backdoors but doesn't back that up with independent auditing (which can come in the form of access to source code) and you find that acceptable then what you have is a preference for _claiming_ that there are no back doors, and not a preference for being open about what the policy is (the real policy is in the software, which the public has not observed) or a preference for there being no back doors. Considering the long history of mistakes and outright lies in security software— this is simply how it is. Doubly so when you consider that lying about a backdoor or being mistaken about severe security holes is unlikely to carry consequence more negative than being open to begin with. If there were a surety bond commensurate with the loss of life that could result from mistakes and dishonesty here and there were independent auditing... plus many of a number of other things then perhaps you could say that you cared about transparency, policy, and backdoors. For many people on this list, source code is their #1 priority. That is fine. However, it is not my priority. I am more concerned with surveillance policy, because that is what I study and where I think I can be most effective in applying pressure. You're erroneously concluding that people who disagree with you have source code [as] their #1 priority— rather, I think it would be more fair in the context of security software to characterize the position has facts as #1 priority instead of warm and fuzzy hyperbole. Source code access is simply the least expensive and most direct way to start getting any real confidence that claims match reality. Following the argument that something is not necessarily better than nothing— we'd be better off if people who weren't interested in producing trustworthy software we're pressed into making fuzzy sounding fanciful claims. If all you can be effective at doing is improving the art of marketing (potential) snake oil, then perhaps you need to reevaluate what you're working on. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] What I've learned from Cryptocat
On Mon, Aug 13, 2012 at 12:38 PM, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: The average user (a very stupid, dumb user but with very strong political commitment in freedom fighting) will always trust the website / operator. We CANNOT FIX that problem in any technical/cryptographic way. That kind of user will do whatever the server operator/website will tell/ask him to do. This actually can be solved, at least largely— not in the short term, but with hard work and education. The primary problem right now is that there is basically no option except single party trust for anything except the most sophisticated users. But it doesn't have to be this way. For example, it wouldn't be hard to educate people to only install software on their secure systems via a downloading tool that verifies (cryptographically) that the software which is being installed has been independently peer reviewed by multiple parties and is free of trusted reviewers asserting that the software is unsafe. The authenticity and independence of the signing parties can be validated by the software— the user only needs to provide keys from some people he knows to bootstrap the process. It wouldn't be hard— except the tools don't exist and there are a number of practical challenges that need to be solved, and interesting tradeoffs that need to be made. (In particular, updates can't be deployed very rapidly in such a model, so we need to greatly increase the basic reliablity and security of the software before reviewed distribution can really work). Of course, the participant in needs a honest introduction in the first place— people could deny them knowledge of the existence of this secure software ecosystem entirely. But compromising a user at an obviously (to the user) important one time event is much harder than compromising them at any of hundreds of monthly technological impediment events. ___ 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 Thu, Aug 9, 2012 at 11:56 AM, Mark Belinsky mark.belin...@gmail.com wrote: Of course it's important to note that this too can be spoofed, but it's potentially better than nothing But thats so trivially spoofed and the only users it would protect would be the ones trying to get protection... A doodlegram in page_info might be better than nothing, but I'm pretty sure a page background is worse than nothing. ___ 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 Mon, Aug 6, 2012 at 6:53 PM, Nadim Kobeissi na...@nadim.cc wrote: The blog post suggests that becoming a local browser app means that Cryptocat no longer uses JavaScript cryptography. This is nonsense: JavaScript is a *language*, and since browser apps/plugins are written in an HTML5 framework, we will still be using JavaScript to implement cryptographic functions. The only thing that has changed is *the method of code delivery.* This makes me a little sad. Previously, I understood what cryptocat was for: It was an insecure system, which was still probably significantly more secure than the common default unencrypted system, for use where deployment/usability issues meant it the choice was insecure-hosted-software or totally-insecure-plaintext. Non-server-replaceable systems like OTR were strictly preferable, of course, but in reality aren't ubiquitously used like they ought to be. With it becoming a browser extension— it seems like it would gain much, although not all, of the usability challenges that precluded using OTR in the first place and in those places where the extension can't be pre-installed we still have short term SSL CA trust challenges (for the on-demand distribution of the extension). It also still retains many of the JS crypto specific technical challenges (no mlock, so no way to prevent long term keying material from hitting disk; generational GC so overwriting can't be trusted to reduce cold boot attack exposure). No doubt you'll find this an unwanted barb when you're already working hard trying to make good software to protect people, and that isn't my intention... but I don't know how to illustrate my confusion otherwise. ___ 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] New YouTube face blur tool and its human rights implications
On Wed, Jul 18, 2012 at 4:37 PM, Matisse Bustos Hawkes mati...@witness.org wrote: Hello all, I'm sure some of you saw today's news that YouTube announced a new face blur tool into their editing suite - as they put it: Whether you you want to share sensitive protest footage without exposing the faces of the activists involved, I wonder if they make timepieces which can measure timespans short enough to clock the amount of time between publication of the announcement and the arrival of the national security letters (and equivalents from the other nations google has physical presence in) requiring google to secretly record and indefinitely retain any of the originals which have been marked for deletion. I think it's good to hear that people are thinking of this, but unfortunate to see that tools like this from institutions and in forms which are structurally incapable of keeping their word, though no fault of their own. Trust should come from promises which can't be broken whenever possible, and in the case of anonymizing video we can do a lot better than cloud hosted SaaS in that regard, especially when they are specifically marketed as being for activism. Youtube could opt not to provide this feature and to leave more room for tools which run entirely under the user's control, but now that they provide it they'll likely not be able to turn it off when its starts being used in a manner which is contrary to human rights. I understand that tool accessibility is also very important, but bad technology crowds out good and anonymity tools which are centralized and deeply and fundamentally unauditable are most certainly the bad kind, even if they were made with the best intentions. I think youtube should reconsider how they're representing this tool and take the opportunity to also recommend some non-SaaS audited tools which can't so easily be secretly compromised. ___ 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
