[liberationtech] Ensuring Free Access to Ideas in Public Spaces?
Hi folks, Thanks to the awesomeness that is TA3M [0], I've had a chance to talk with a few librarians who're somewhat disappointed by the fact that it's difficult to freely access knowledge at libraries: all Internet access is filtered and surveiled, reducing the freedom of expression and the free exchange of ideas. So, I promised I'd reach out to folks to see what, if anything, we can do about the situation. First, what technologies could public libraries employ that would ensure or best facilitate intellectual freedom, free expression and free access to ideas when people use the library? Different libraries will have different connectivity structures, so this is a fairly broad question. I think there's a more fundamental question, though, which is figuring out how to make libraries again responsible for providing unencumbered access to ideas. I don't know how to do this. I could help draft standards-language for "The Responsibilities of Libraries to the Public" but perhaps there's already such a document out there that could be updated or re-enforced. At this point, I'm trying to start a discussion. Thanks for your time, Nick 0: http://wiki.openitp.org/events:techno-activism_3rd_mondays -- 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 12:54 PM, Collin Anderson wrote: > Wait, forgive me Libtech for amusing myself at the cost of your collective > inboxes but, is it just me or is the security page on what purports to be a > security tool empty? https://unsene.com/security.html It's not blank at all! : : : : : : See? They have 3 empty arguments and then one really persuasive one. I swear I recognize that argument structure from somewhere... Lincoln-Douglas debates? -- 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] WC3 and DRM
On Tue, Jul 16, 2013 at 1:04 AM, Jonathan Wilkes wrote: > On 07/15/2013 11:45 PM, Catherine Roy wrote: >> >> As a member of the HTML working group and the Restricted Media community >> group, my experience is that discussions within these groups surrounding the >> EME draft have been extremely frustrating. The same scenario as with Jeff >> Jaffe's blog post has happened there. The whole thing has been rather unreal >> and this recent post[1] from a Restricted Media mailing list member sums up >> my feelings about how futile the whole exercice has been. >> >> [1] >> http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Jul/0190.html > > It seems like there are two fronts-- one, which you address by jettisoning > EME in freedomhtml, and another which is to keep member organizations from > standardizing software/hardware on EME. Is there any way for the current > members of all the working groups to put pressure on the WC3? Is there any point to messaging the draft's editors directly? http://www.w3.org/TR/encrypted-media/ If you delivered a thousand copies of the Hollyweb petition a day, you could do it for nearly a month before running out of individual signers [2]. That'd be nearly 75k letters between all 3 drafters. 2: http://www.defectivebydesign.org/oscar-awarded-w3c-in-the-hollyweb -- 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] Resources on electronic voting
On Wed, Jul 10, 2013 at 12:36 PM, Marcin de Kaminski wrote: > Sorry to ask such a general question but I need input on the issue of > electronic voting. Is there any comprehensive collection of resources or > (preferably academic) research already out there? None that I know of, but there is pvote.org. Much better than Ohio's solution :) -- 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] Resources on electronic voting
On Wed, Jul 10, 2013 at 12:36 PM, Marcin de Kaminski wrote: > Sorry to ask such a general question but I need input on the issue of > electronic voting. Is there any comprehensive collection of resources or > (preferably academic) research already out there? -- 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 tool for encrypted laptops
On Tue, Mar 26, 2013 at 8:03 AM, Michael Rogers wrote: > On 26/03/13 09:59, Julian Oliver wrote: >> For your Linux laptop why not just use an encrypted file-system and >> lid-switch? Close the lid and the machine hibernates. If you forget >> to close the lid then time it out to a screen lock. > > Last time I tried it wasn't simple to get Linux to hibernate with an > encrypted swap partition. Are there now distros that support this out > of the box? Debian. It's worked beautifully for me since Squeeze (at least, maybe Lenny?). -- 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] Microsoft Releases 2012 Law Enforcement Requests Report
On Fri, Mar 22, 2013 at 10:49 AM, Cynthia Wong wrote: > > Why are RU and CN (most glaringly) absent from the first chart > enumerating the number (and type) of requests by country? It's hard to > believe those countries' security services have no interest in > (non-Skype) Microsoft data. Is MS defining those countries as having > no legal standing to request MS data, and therefore any requests from > them would be rejected out-of-hand? I actually read it as "those countries have made no specific requests and that the missing surveillance is already accounted for in the normal operation of the system, such that no formal requests were necessary." At least, that's how I interpret that statement in light of the Businessweek-Skype article [0], which says, in part: The surveillance feature in TOM-Skype, which has 96 million users in China, scans messages for specific words and phrases. When the program finds a match, it sends a copy of the offending missive to a TOM-Skype server, along with the account’s username, time and date of transmission, and whether the message was sent or received by the user, Knockel’s research shows. Whether that information is then shared with the Chinese government is unknown. Yes, the article's talking about Skype, but if a service as popular as Skype includes such features, it's probably imprudent to assume that other MS services act differently, especially when there's a blatant hole in the data: there's no way Skype, with that feature enabled, could've turned over only 6 conversations, so I'm forced to disbelieve both sets of numbers. I make this statement under the assumption that Businessweek would be competent enough publish only independently-verifiable claims on the first page of such a sensitive article. If Businessweek is a bunch of lunkheads, then I may have to revise my opinions and suspicions. Nick 0: http://www.businessweek.com/articles/2013-03-08/skypes-been-hijacked-in-china-and-microsoft-is-o-dot-k-dot-with-it -- 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 details on China TOM-Skype vulnerability
If you want to jump straight to the data, it's here: http://cs.unm.edu/~jeffk/tom-skype/ On Fri, Mar 8, 2013 at 7:11 AM, Graham Webster wrote: > Bloomberg Businessweek reports on a researcher who cracked the list of > sensitive terms that trigger the Chinese TOM-Skype application to send > messages to a server and sometimes block transmission. > > > http://www.businessweek.com/articles/2013-03-08/skypes-been-hijacked-in-china-and-microsoft-is-o-dot-k-dot-with-it > > Remember 2008? Nart Villeneuve/Citizen Lab reported how this worked, and > the surveillance barn door was wide open. > > http://www.infowar-monitor.net/breachingtrust.pdf > > Graham > > > -- > Graham Webster 魏光明 > g...@gwbstr.com > > > > > > -- > 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 > -- 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] Deregulating the internet
To vastly oversimplify things for the purpose of making a point: The principle of end-to-end is the guiding principle here. Each bit is opaque to the network it travels on: *nobody at all* should fiddle with a bit in transit. The regulation that discourages packet recording, tampering, interference, and spoilage is to be encouraged. Regulations that encourage interference should be avoided. Anything else is tantamount to censorship. Maybe censorship for limited times or for limited purpose, but still private censorship of private speech. On Tue, Jan 29, 2013 at 3:31 PM, Albo P Fossa wrote: > I saw a petition posted for signature: "Our job is simple, to write our > Representatives and tell them that we are opposed to international efforts to > 'govern' or otherwise regulate the internet." My question for discussion is > this. If we are opposed to 'governing the internet', then are we opposed to > governing the corporations involved in controlling or meddling with access > thereto? E.g., Google, Comcast, and their ilk? Which government do we oppose? > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Gmail SSL Certificate Churn?
Sky, the cert fails because I'm (very, very slowly) trying out different PGP-SSL bridges (it's four or five projects down, at this point). Right now, this means that my cert is self-signed, and that it can be verified by checking the PGP signature on the authentication statement: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-June/003880.html So far, I've learned that this approach isn't very scalable. :) You can check the site without HTTPS by going to: www.betweennowhere.net/blog/2013/01/gmails-changing-ssl-certificates/ The betweennowhere.net site just redirects to the https://www.betweennowhere.net site anyway. On Sat, Jan 12, 2013 at 9:44 PM, Sky (Jim Schuyler) wrote: > Rapidly means several days to a week for google.com. We (Cyberspark.net) > watch the Google.com SSL certs (not gmail) and it takes at least a few days > as they roll new certs onto multiple IP addresses (round robin DNS). I have > only monitored this for the last two years, but it's been the same both > years. I have never understood why they don't or can't deploy the new certs > more rapidly, and it does set off repeated alarms within our systems. But as > long as they are valid and properly signed we just watch and smile. > > DNS rotates the address for Google.com among a number of IP addresses, and > they don't update all of those servers at the same time, so it appears to > our monitors as "thrashing" back and forth between the old and the new > certs. > > I wonder if anyone in the group knows whether there's any good reason they > should or shouldn't push new certs on all machines at the same time? > > (Nick -- would like to see what you have online, but won't blast thru a > certificate warning. Perhaps you have it somewhere else.) > > -Sky > > > On Jan 12, 2013, at 2:57 PM, John Adams wrote: > > Additionally, while you're complaining about other people's SSL > certificates, you should fix yours. :) > > > > On Sat, Jan 12, 2013 at 2:54 PM, John Adams wrote: >> >> Google has stated publically that they rapidly roll their SSL >> certificates. Nothing to see here, no blog post to write, move along now... >> >> -j >> >> >> On Sat, Jan 12, 2013 at 2:19 PM, Nick M. Daly >> wrote: >>> >>> Hi folks, can you help me understand how to interpret this data? It >>> appears that Gmail's SSL certificate changed fairly frequently during >>> the month of December. That seems wrong to me. What's this all mean? >>> >>> >>> https://www.betweennowhere.net/blog/2013/01/gmails-changing-ssl-certificates/ >>> >>> The weirdest part isn't how the 0E:66... certificate disappeared on >>> November 20th (or December 5th), but how it came back into circulation >>> on or around December 20th. >>> >>> Thanks for any clarification you can offer on this situation, >>> Nick >>> >>> -- >>> Unsubscribe, change to digest, or change password at: >>> https://mailman.stanford.edu/mailman/listinfo/liberationtech >> >> > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail
On Mon, Dec 10, 2012 at 1:42 PM, Fabio Pietrosanti (naif) wrote: > Hi all, > > for whose who has still not see that project, i wanted to send a notice > about MailVelope, OpenPGP encryption for webmail: http://www.mailvelope.com > > It's a client-side, plug-in based (similar to CryptoCat), OpenPGP email > encryption plugin available for Chrome and Firefox. > > Source code is available under AGPL on > https://github.com/toberndo/mailvelope . > > Does anyone ever security reviewed it? > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech This (could finally be) email encryption done right: encryption is performed on the user's browser, so that the server storing the communication never sees the contents of the message. However, after installing it on Chrome, I have a few concerns: 1. Mailvelope appears to use its own keystore (at least on Windows), and not the GPG keystore. Specifically, it doesn't use the GPG4Win keystore, which is the one I'd expect it to use. 2. When creating a new PGP key in Mailvelope, it has some pretty poor defaults. A. Keys are set to 1024 bits, instead of 2048 (or 4096). Anything under 2048 is probably insufficient. B. Keys are set to never expire, and that can't be configured. Different keys should be used for different purposes and should expire differently. It's not a bad idea to cause email-signing keys to expire after 3 - 5 years. Both 2.A and 2.B can be fixed through GPA or another frontend, but that's still bad key-creation practice. However, it *does* show the long-form key ID (the last 8 bytes of the fingerprint), which is probably the minimum necessary to avoid most collision attacks. Nick -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Renesys: Syrian Internet Is Off The Air
Does anybody know what the Y-axis (vertical) scale is on Akamai's graph? If the scale is in millionths of Mbps (bps) then it's not a very large change. Also, does the Y-axis start at zero, 12-billion, or what? ...You'd think a content hosting company could put together a reasonable usage graph. On Thu, Nov 29, 2012 at 10:51 AM, Amin Sabeti wrote: > Akamai graph: > https://twitter.com/akamai_soti/status/274163048263057408/photo/1 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Bitly Safety (was Stanford Bitly Enterprise Account)
On Fri, Nov 16, 2012 at 4:41 PM, Griffin Boyce wrote: > All URL shorteners have the problem of not being transparent with > destination. The risk of this is amplified on places like Twitter, > where the shortened version can be copied and pasted numerous times. > > So I would recommend using a site like unshorten.it (or bit.ly itself) > to actually see where a link leads. Someone should register long.er for stretching links :) -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Stanford Bitly Enterprise Account
Best I can tell, the only reason they're popular is because microblogging sites count links against your 140-character limit. Now, if only Twitter[0] used footnotes[1] and didn't count the URL against the message, they'd disappear. 0: https://twitter.com/ 1: https://en.wikipedia.org/wiki/Note_%28typography%29 Now, if only Twitter (https://twitter.com/) used footnotes (https://en.wikipedia.org/wiki/Note_%28typography%29) and didn't count the URL ag On Fri, Nov 16, 2012 at 8:18 AM, Nadim Kobeissi wrote: > Is there any benefit other than an aesthetic one? Centralizing all URLs > under a single authority and then obfuscating them doesn't sound like a > particularly great idea... > > > NK > > > > On Fri, Nov 16, 2012 at 9:17 AM, Eugen Leitl wrote: >> >> On Fri, Nov 16, 2012 at 03:14:35PM +0100, Alex Comninos wrote: >> > data retention and privacy implications compared to for example is.gd >> > or installing a URL shortner on Libtech's own servers? >> >> Earl shorteners are considered harmful. Don't use them. >> >> > implications of the .ly ccTLD being under Libyan jurisdiction? >> > >> > I would like to hear a little about these issues >> -- >> Unsubscribe, change to digest, or change password at: >> https://mailman.stanford.edu/mailman/listinfo/liberationtech > > > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Security / reliability of cryptoheaven ?
Correction. I completely misspoke: I read "public" as "private", and need to completely re-analyze cryptoheaven's setup. If you're the only custodian of your private key, then you're probably fairly safe. Again, I need to completely review and revise what I wrote. On Tue, Oct 9, 2012 at 7:55 PM, Nick Daly wrote: > On Tue, Oct 2, 2012 at 8:41 PM, Maxim Kammerer wrote: >> From Security FAQ [3]: >> >> “CryptoHeaven manages public keys automatically and securely. User >> simply allows others to communicate with him through the use of >> "Contacts" within the CryptoHeaven system. The system takes care of >> the exchange of the public keys automatically.” >> >> [3] http://www.cryptoheaven.com/Security/SecurityFAQ.htm > > This means that anybody who can bring legal or technical pressure > (security holes) to bear on cryptoheaven can expose your secret keys: -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Security / reliability of cryptoheaven ?
On Tue, Oct 9, 2012 at 4:18 PM, Brian Conley wrote: > Thanks for the interesting discussion, but its gone far afield from the > original question. > > Does cryptoheaven seem like a reasonable tool to depend on for journalists > or businesses requiring security for their communications? The answer to this always depends on your threat model. In this case, cryptoheaven holds your secret keys. That's a very important point: On Tue, Oct 2, 2012 at 8:41 PM, Maxim Kammerer wrote: > From Security FAQ [3]: > > “CryptoHeaven manages public keys automatically and securely. User > simply allows others to communicate with him through the use of > "Contacts" within the CryptoHeaven system. The system takes care of > the exchange of the public keys automatically.” > > [3] http://www.cryptoheaven.com/Security/SecurityFAQ.htm This means that anybody who can bring legal or technical pressure (security holes) to bear on cryptoheaven can expose your secret keys: your data's private to everybody but cryptoheaven and the folks they decide to/are forced to share your data with. If you're writing nasty things about the country in which cryptoheaven's incorporated (or where their SSL CA is incorporated), I'd advise finding a different service provider. For journalists who don't have a particular geographic focus, the issue becomes even broader: they might have different service providers (different identities) for different places. This issue is why the Certificate Patrol Firefox extension exists (to address this at a few different levels) and why this paper was produced: http://files.cloudprivacy.net/ssl-mitm.pdf Nick -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Security / reliability of cryptoheaven ?
On Tue, Oct 9, 2012 at 7:24 AM, Jacob Appelbaum wrote: > Maxim Kammerer: >> Even the CryptoHeaven solution that I criticized above is good, >> discarding minor issues that can be easily fixed, and discarding >> what's apparently a security-usability tradeoff decision: not >> incorporating a public key hash in the username (making the user >> address self-authenticating). There is apparently no solution to this >> tradeoff — see Zooko's triangle in [2]. > > Imagine an OTR extension that allows you to pass your .onion address > over an authenticated jabber/aim/whatever session - now you can meet > again on a decentralized system. You'll also already have the > username/alias/realname in the chat client, I think. I've been working on a more generalized form of protocol-independent communication for the last few months with FBuddy: https://gitorious.org/freedombuddy/freedombuddy Thanks to other FreedomBox work (and dayjob commitments) it hasn't received half as much love as it should've, but it's a good part of the way there, so maybe this is a good time to talk about it (I wanted to finish a few outstanding features first, but that might just be vanity). The essential point is that folks exchange connection information, once. From then on, automated services pull location information over any protocol that both end points share. For example, I could get your host location (which might be an .onion address, a GNUnet document ID, etc.) and pull that information down. That initial request also contained my host location, so you now know where to find me, across the many protocols we both might support. It's essentially turning the issue of dynamic connections into one of data exchange at pre-shared locations. The hard part is the second 90%, that of pushing those location updates into the services that need them. Right now, it relies on PGP for message signing and encryption, but other verification methods (OTR, others) are also possibilities. > Another useful thing is a dynamic, cryptographically secured but time > limited, federated meeting protocol. I've been working on such a > protocol and I hope to finish it before the end of the year. If you'd > like to talk about it, I bet we could put it and cables together for > something quite usable. I'd love to hear more about that when you have time. It could be very useful to FBuddy and similar tools. Nick -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Request for comments - a #CryptoParty-oriented keysigning protocol
On Fri, Aug 31, 2012 at 11:23 AM, Matt Mackall wrote: > > Not strictly related, but I've heard some rumblings lately about the PGP > web of trust being harmful because it can expose activists' social > networks. A valid concern. If you hate social graphs, don't publish your key and ask that your signed key not be published. However, it's much more difficult to build a web then, as your local key copy is the only updated copy. You'd need to send your key to all the previous signers every time your key was signed. Of course, the comparative difficulty between the two methods varies, based on how often people pull updated keys from keyservers. If none of your key signers ever pulls your updated key, publishing keys is kinda silly. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
