Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
John Sullivan jo...@fsf.org writes: Nick liberationt...@njw.me.uk writes: The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. F-Droid does a lot of this. I couldn't find a standard way to get the exact source snapshot a particular app's build comes, nor what the build parameters were, although via the web site the app pages do give release numbers. They're hard at work on deterministic builds now, apparently, and I would guess that some of these essentially UI fixes will happen along with that. That info is in the server metadata file for the app (for example the git tag for the source that was used to build the app, and the build parameters). Probably just needs to be exposed in the UI. Thanks, John; agreed. I saw your mail just after I filed https://gitlab.com/fdroid/fdroiddata/issues/76 about this very question. By the way, I've also updated the post at https://openitp.org/circumvention-tech/app-stores-and-trustable-code.html to give F-Droid some more credit -- I think I relied too much on those UI routes existing, when that's not necessarily a reliable indicator of what F-Droid is doing on the back end. Had I talked to you or someone else at F-Droid first, though, I could have discovered just how much of the proposal was already implemented there! Sorry not to have done so. In a private conversation with Brian Behlendorf, he pointed out that there's a more general version proposal that should really be the goal. I'd like to do a second piece on his proposal, but as I'm not sure I'll get to it soon, I'm posting it here just so it has some circulation. Quoting him (inner text is his, outer text is my reaction): Karl Fogel wrote: Brian Behlendorf wrote: If we're proposing ideas for phone OS and app store folks, we should start from first principles: * End users should be able to trust that the code installed on their system came as intended by the app author and as verified by the App Store against their policies. * End users should be able to modify and recompile Open Source apps, and if they redistribute those modified works (whether direct or though app stores again), downstream recipients should be able to use the same means to verify the modified works. This suggests to me the following process: * App developer builds install image, generates a checksum, optionally signs it with a private pubkey. * App developer sends install image, source code to app store, who perform their acceptance tests, build their own copy of the install image, then validate that both install images checksum to the same number. * App developer publishes image name, version number, checksum, and signature to a well-known location on their own SSL website (the same way they did for robots.txt - call it appchecksums.txt) so that their identity can be tied to a registered domain name and SSL cert. * App store publishes the install image, checksum, and URL to their repository, making it available to all downloaders. If it's an Open Source package they also provide a clear URL to the specific revision of the code that builds the install image, as well as the OSI-approved license used. * App store client on the phone is asked to install the app. First they download the package, as well as the corresponding appchecksums.txt file from the developer's own website. If they don't match, error out or prompt for exception handling. If they do, feel free to install. * App store client on the phone provides a means to download the source code if the app developer wishes to allow it - and it points to the same bundle of code that the app store used to verify the build. This gets the app store out of the business of generating their own builds from a public tree (they still build, but only what the app developer asks them to build). It also removes the historic dependency on a public tree, just in case the project is closed or the code hosting service disappears. Thoughts? My thought is: spot-on. I had meant that the app store should host a copy (e.g., a git or hg clone) of every source tree it builds; in any case, many other people will have copies. The app store just needs to publish the snapshot checksum -- the content ID checksum -- and the distributed archive of the Internet can take it from there. So yes, the store should host a copy of the tree, and in the case of open source apps, that copy happens to match one or more other copies found out on the Net anyway. The commit ID is the main thing. But your overall idea: that the app store can still usefully prove to the *author* as well as to the public that what's being shipped matches the intended code, seems really good to me
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
Nick liberationt...@njw.me.uk writes: The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. F-Droid does a lot of this. I couldn't find a standard way to get the exact source snapshot a particular app's build comes, nor what the build parameters were, although via the web site the app pages do give release numbers. They're hard at work on deterministic builds now, apparently, and I would guess that some of these essentially UI fixes will happen along with that. (I don't mean to sound like a complainer: F-Droid is fantastic. I just hope they'll take it all the way :-) ). But to be honest I'm not sure why people who are happy to use a completely proprietary mobile computing system would care that much about this. They have already voted with their feet that freedom (and by extension security and privacy) are not important to them. Sure, there may be plenty of people who are ignorant enough of how computers actually work to not realise the sacrifices they're making, but I don't think this article is targeted for them. It's about reducing the number of exposure points. With most app stores, you have to trust the author for each app you have installed, *and* you have to trust the app store. If you can get that down even to just having to trust the app store, that's still a win. One can't just say security and privacy are or are not important to someone -- it's a matter of tradeoffs. Different people have different tradeoffs they want to make; app stores that offer verified open source apps give them more of a continuum along which to make that decision. Best, -K -- 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] Proposal for more-trustable code from app stores; comments welcome.
Thoughts welcome on the usefulness of this proposal: https://twitter.com/OpenITP/status/514836088511537152 Quick summary is: Today, app stores don't even clearly *distinguish* open-source from closed-source apps, let alone do the builds themselves. It would be great if app stores built open-source apps directly from the public source tree, stating exactly which snapshot was used. And it would be even better if they did so with deterministic builds -- though even just knowing that the app store had done the build themselves (instead of the app's author doing it) would be a huge win, and deterministic builds would be gravy. Details in the article. -Karl -- 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] Silent Phone source code available on GitHub
Joseph Lorenzo Hall j...@cdt.org writes: Definitely what I call disclosed source. I doubt they'd license with an open source license, let alone accept external commits. As long as the license allows review, static analysis, debugging compilation, etc. -- i.e., things needed for technical evaluation -- that's a good thing. Right? Sure; good is a rather wider domain than open source :-). My point is just don't call it open source if it isn't -- people are counting on those words meaning something specific dependable. They'll think they can fork the code, or, you know, base a business on it, and then be surprised when the license bites them. -K On Fri Oct 4 12:02:11 2013, Karl Fogel wrote: Petter Ericson pett...@acc.umu.se writes: So, Silent Circle (well, Silent Phone) is finally open source! Thank you, Petter -- it sounds like this release was a lot of hard work. But it doesn't appear to be actually open source. At least, I couldn't find a license file containing an open source license. Actually, I didn't see any license file at all, so I went looking for a source file, and the first one I found was: https://github.com/SilentCircle/silent-phone-android/blob/master/src/com/silentcircle/silentphone/TiviPhoneService.java ...which contains this license header in a comment at the top: Copyright © 2012-2013, Silent Circle, LLC. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Any redistribution, use, or modification is done solely for personal benefit and not for any commercial purpose or for monetary gain * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name Silent Circle nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. [...] That first term is incompatible with open source (prohibition on commercial use means it's not open source). For clarification: http://opensource.org/faq#commercial Of course, I'd love to see the code switched to an open source license, and am happy to help you choose one, if you'd like help. A good place to start is http://opensource.org/licenses. Having the code visible to the world is still a gain from a security perspective, and I don't mean to diminish that. However, visible is not the same as open source. Best, Karl At least, the previous version, with the next one coming in a couple of weeks. This, to me, is absolutely wonderful news, as it is finally possible to get a proper security audit of the whole shebang. Github issue: https://github.com/SilentCircle/silent-phone-base/issues/5 The released repo: https://github.com/SilentCircle/silent-phone-android /P From: Jim Burrows notificati...@github.com Subject: Re: [silent-phone-base] Impact of ZRTP library critical security vulnerabilities (#5) To: SilentCircle/silent-phone-base silent-phone-b...@noreply.github.com Cc: pettter pett...@acc.umu.se @pettter, Soon is today, well, actually last night. We've just released the sources to Silent Phone for Android V1.6.5. And, yes, we released them one week after we released 1.6.6 to the Play Store, so they're a little bit stale, *BUT*... what delayed us was making sure that they were buildable from the GitHub repo outside our build environment. That means, assuming we got it right, that you can check out our repo here on GitHub, build your own APK, install it on your phone and run it instead of our Play Store version. And to make lemonade out of the lemons of being one release behind, we plan on releasing 1.6.6 in a couple of weeks, so, if you try to build 1.6.5 and find that we blew it somehow, you can post an issue here and we've already got a release planned to fix it in. I'm really sorry that soon took this long. It was absolutely NOT my plan, but this summer has been really really hectic (for obvious reasons) and we're a small company with limited resources. The slowness has really frustrated me, as has the fact that when I yell, What idiot set those priorities? each time something delayed posting here, the answer was always me. I can try to blame all the Snowden, NSA, Prism brouhaha and the time and resource pressures it has put us under, but in the end, I'm the one who grits his teeth and says, Yes, that's more important than the GitHub release. Make it so. I'd be happy to have you sympathize with me for the decisions I've faced this summer, but I absolutely would not disagree with you if you blamed me for the delay. I
Re: [liberationtech] Feedback req: Tinfoil SMS
Griffin Boyce grif...@cryptolab.net writes: My feedback is that Tinfoil SMS will not gain much traction as its name marginalizes its users. Wanting more security is not sketchy. Wanting privacy is not a tinfoil hat situation. Cheekiness can be good, but this is a space where you start out at a disadvantage and having a name that inspires confidence is important. +1 all over what Griffin said. For the same reason I wear a suit when showing up to a protest :-), it would be nice to choose app names that don't force potential users to reconsider their self-identity. Let's mainstream security, not marginalize it. -K -- 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] Silent Phone source code available on GitHub
Petter Ericson pett...@acc.umu.se writes: So, Silent Circle (well, Silent Phone) is finally open source! Thank you, Petter -- it sounds like this release was a lot of hard work. But it doesn't appear to be actually open source. At least, I couldn't find a license file containing an open source license. Actually, I didn't see any license file at all, so I went looking for a source file, and the first one I found was: https://github.com/SilentCircle/silent-phone-android/blob/master/src/com/silentcircle/silentphone/TiviPhoneService.java ...which contains this license header in a comment at the top: Copyright © 2012-2013, Silent Circle, LLC. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Any redistribution, use, or modification is done solely for personal benefit and not for any commercial purpose or for monetary gain * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name Silent Circle nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. [...] That first term is incompatible with open source (prohibition on commercial use means it's not open source). For clarification: http://opensource.org/faq#commercial Of course, I'd love to see the code switched to an open source license, and am happy to help you choose one, if you'd like help. A good place to start is http://opensource.org/licenses. Having the code visible to the world is still a gain from a security perspective, and I don't mean to diminish that. However, visible is not the same as open source. Best, Karl At least, the previous version, with the next one coming in a couple of weeks. This, to me, is absolutely wonderful news, as it is finally possible to get a proper security audit of the whole shebang. Github issue: https://github.com/SilentCircle/silent-phone-base/issues/5 The released repo: https://github.com/SilentCircle/silent-phone-android /P From: Jim Burrows notificati...@github.com Subject: Re: [silent-phone-base] Impact of ZRTP library critical security vulnerabilities (#5) To: SilentCircle/silent-phone-base silent-phone-b...@noreply.github.com Cc: pettter pett...@acc.umu.se @pettter, Soon is today, well, actually last night. We've just released the sources to Silent Phone for Android V1.6.5. And, yes, we released them one week after we released 1.6.6 to the Play Store, so they're a little bit stale, *BUT*... what delayed us was making sure that they were buildable from the GitHub repo outside our build environment. That means, assuming we got it right, that you can check out our repo here on GitHub, build your own APK, install it on your phone and run it instead of our Play Store version. And to make lemonade out of the lemons of being one release behind, we plan on releasing 1.6.6 in a couple of weeks, so, if you try to build 1.6.5 and find that we blew it somehow, you can post an issue here and we've already got a release planned to fix it in. I'm really sorry that soon took this long. It was absolutely NOT my plan, but this summer has been really really hectic (for obvious reasons) and we're a small company with limited resources. The slowness has really frustrated me, as has the fact that when I yell, What idiot set those priorities? each time something delayed posting here, the answer was always me. I can try to blame all the Snowden, NSA, Prism brouhaha and the time and resource pressures it has put us under, but in the end, I'm the one who grits his teeth and says, Yes, that's more important than the GitHub release. Make it so. I'd be happy to have you sympathize with me for the decisions I've faced this summer, but I absolutely would not disagree with you if you blamed me for the delay. I own it. Silent Phone for iOS sources, Silent Text for Android, and then Silent Phone for Android 1.6.6 source releases are all in the pipeline, and if you'll forgive me for using a word that I myself have sullied, they should all be here soon. -- -- 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] OneTime 2.0 (beta): one-time pad system.
Andy Isaacson a...@hexapodia.org writes: OneTime 2.0-beta is ready for review and testing, as threatened [1]. See http://red-bean.com/onetime/ At a quick glance, it appears you have not added any message authenticity to the system, correct? Do you have any thoughts on how to add tamper resistance to onetime? Well, I figured the pad is the authentication. If the message decrypts at all, then the person who sent it to you must have the pad you expect them to have, so they must be the person you think they are :-). (Or did you mean something else, like message integrity?) When decryption fails, one sees an error like: DecodingError: unable to decode (wrong pad?). There's a regression test for this, by the way. Best, -K -- 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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
Tony Arcieri tony.arci...@gmail.com writes: How? At the very least Alice/Bob need an authenticated/trusted channel for this. If Alice sends Bob her public key over an untrusted channel, it can be intercepted by an MitM posing as Bob who can then intercept all traffic between Alice/Bob In the real world, one often has a temporary-but-secure channel with someone (e.g., you meet them in person briefly somewhere, with a trusted intermediary who knows both of you). Then later, you want to communicate securely with your new acquaintance. It doesn't mean MitM never happens. But let's not deny away real world scenarios by imposing theoretical limitations where they don't necessarily apply. Often when you want to communicate with someone, you already have some shared bit of context that allows you to bootstrap authenticated identities. -K -- 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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
Francisco Ruiz r...@iit.edu writes: Scenario: you, Alice, realize you're under NSA surveillance. You need to get a crucial bit of information to your friend Bob, right away. You've been using PGP, but now you suspect the NSA may have installed a bug on your machine. Your keystrokes are being recorded. What can you do? Use PassLok instead. I wrote PassLok with three guiding principles in mind: 1. Absolutely nothing should be installed or even written in the computer. Alice should be able to go to the local library or borrow someone else's smartphone, and leave no traces behind. 2. Best security available. No compromises. 3. Graphical interface. Only one screen, as clean as possible. Therefore, PassLok is written entirely in javascript. Once you load the page at https://passlok.site44.com (http://passlok.com redirects you there), you can save the file and you have PassLok even offline. You can view the source and convince yourself that it is not connecting with any server. If you know some cryptography, you can see that it is using the well-known SJCL routines for AES encryption/decryption and elliptic curve functions. Since the elliptic curves implemented in the current version of SJCL only go up to the 384-bit NIST curve, I added the 521-bit NIST curve (equivalent to a 15000-bit RSA key in predicted security) so that PassLok uses that as a default. Even at 521 bits, the public keys are small, as you can see from my lock (public key) below. PassLok performs public-key cryptography using the Diffie-Hellman key exchange rather than RSA, so you can use whatever secret key you want. Hopefully something that is both very hard to guess and easy to remember, so you never have to write it down. PassLok will help you to come up with a strong key, but won't force you in any way. PassLok can sign and verify signatures, too (many PGP implementations, such as Mailvelope, cannot), and can also include a second secret message under a separate key, to beat the rubberhose attack. If you are not sure about the authenticity of something, PassLock can make a short ID that you can read over the phone. All of it from a single screen. I want people to use PassLok and uncover any bugs it might still have, before I move on to a Gmail plugin based on its engine. I believe it is already very secure and easy to use by those who know a little cryptography. Hopefully the metaphor used throughout PassLok, about locks and keys rather than private/public key pairs, will also make it usable by novices. I'll appreciate any feedback you can give me. The link is repeated at the bottom. Thanks! Francisco, thanks for posting this. At the PassLok site, some text can be clicked on to cause expandable/contractable instructions to appear. It would be nice if there were an icon (like a turnable triangle icon or something) that made this more obvious -- otherwise, the title words just look like normal text and one might not think to click on it. (Yes, you say so at the top, but I think users tend to only read text that looks like it's relevant to the immediate task at hand, not general instructions that appear at the top of the page, far away from the targets to which they apply.) Also, it will not be obvious to many people that View Source on the page is how they get the code for inspection and possible self-hosting. Maybe you could put up an explicit instruction about that, in the same place where other sites might have (say) a GitHub link? -Karl -- 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 Android guide?
Jon Camfield j...@joncamfield.com writes: Julian - this is an excellent and concise quickstart guide to Android security -- have you considered posting it into https://github.com/opensafermobile/materials ? Those materials which were posted on the http://safermobile.org/ site (which is now offline), but they're beginning to show their age. You may be interested in the Guardian ROM project, currently under way: http://shadowdcatconsulting.com/blog/2013/2/13/guardian-rom-secure-android-rom.html I think it may be behind its originally-planned schedule, as is normal with such things :-), but I know Kyle Davidson is actively working on it. -K On Saturday, July 13, 2013 10:30 AM, Julian Oliver wrote: ..on Sat, Jul 13, 2013 at 03:13:41PM +0200, Jerzy Łogiewa wrote: Hello! If I want Android phone and have it be most secure, how to do it? Is there some guide with steps? Like this: 1- Buy some handset such as X, Y 2- Re-flash to Z firmware 3- Change P settings to J ... 4- Install OrBot, RedPhone, and so on What is recommended here by experts? PS: I am willing to have device ONLY for secure communications. Disclaimer: while some journalists/people call me an expert I've never, ever named myself as such! Firstly, smartphones are a huge risk if you're really concerned about your security. Nonetheless, here's a start: You can install CyanogenMod - and not install the Google suite - for a pleasant and largely Google-free experience. To be safer, don't install a nightly build. Take out the SIM card. Flash CyanogenMod using the simple instructions for your device on their website. Encrypt the file-system once the device is installed. Set up a 6-or-more line swipe pattern without visual feedback (and keep your screen clean!). Disable developer mode and MTP browsing, until you need it. Connect the device to a wireless network you control. Install DroidWall (or similar open source firewall) and lock down any unknown and/or promiscuous processes (vastly less with CyanogenMod than Android). Don't use Google Play. Download and install OopenVPN client and tunnel to your favourite trusted OpenVPN server. Put on OrBot and run the OrWeb Tor browser. Edit your exit nodes to those that suit. Install Firefox and requisite extensions that protect against cookie tracking etc. Use StartPage instead of Google as your default search engine. Don't install any random games or other software. If you need something like a PDF reader, be sure it's open source and the APK you download checksums out (SHA256). I've done the above, more or less, with my last two Android phones. My SIII is especially good to work with. I've audited it on the wire and I trust working with it so far. How you use it is another thing. If you rarely need to make calls over the cellular network then use Airplane Mode until you need to call - that'll get you off the grid where cell provider location tracking/logging is concerned. Better still, don't use a SIM card at all and tunnel/ZRTP VoIP with something like RedPhone. Cheers, -- 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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
Moritz Bartl mor...@torservers.net writes: Surespot looks like an open source alternative: https://www.surespot.me/ https://www.surespot.me/documents/how_surespot_works.html surespot's code may be excellent (I haven't looked at it), but their front page at https://surespot.me/ makes a promise it shouldn't make: | You can delete your message from the receivers phone. | | Be confident sending private information and pictures. You have | control over your messages, when you delete a sent message it will | be removed from the receivers phone and images are not sharable | unless you make them so. Software can't be simultaneously open source on the client side and make promises about how the client side will behave. Actually, one can't really make that commitment even when the client side is closed-source (for example, if a closed-source app runs on an open source OS, then when the app tries to delete the message, the OS can retain a copy). But anyway, the loophole is even easier to exploit when the application code itself is open source. Surespot is just one of several apps making such claims. I wrote a bit of a rant about this trend here: http://www.rants.org/2013/06/09/privacy-promises-and-client-side-betrayal/ Again, this is not about their code, which may be fantastic. It's just about their marketing language around the code. Best, -Karl technical overview User creation- When a user is created in surespot two ECC (secp521) key pairs are generated, one for key derivation, and one for signing. The username plus keypairs create a 'surespot identity'. This identity is stored on the device symmetrically encrypted using 256 bit AES-GCM with a PKCS5S2 key derived from the user's password (plus salt and other data). The public keys are uploaded to the server where they are signed by the server using the server's private key. A user may create multiple identities and switch between them at will. User authentication- To login the client generates a signature using the identity's private signing key against the username, password, and randomly generated data. The server validates the client provided username, password, and aforementioned signature against its stored public signing key for the identity in question. If successfully verified the client is issued a session cookie which authenticates them for future requests until the session expires or they logout. As the exchange occurs over SSL, session cookies are thought to be a secure enough mechanism to facilitate authentication, but in the future every request could be validated against the signature. The fact that messages could not be decrypted by a session hijacker given the end to end encryption nature of the system also factors into this decision. Identity backup/restore- As the private key stored on the device is the, uh key, to unlocking all of the data, it is of utmost importance. In the case of a lost or stolen device, if the key is lost along with it, so is all of the data. Identity backup/restore and key versioning help to mitigate this problem. A user may backup their (encrypted) identities (username and key pair history) to device storage, or the cloud and restore them upon demand. Obviously the security is only as strong as the password used to store the identity in whatever cloud service and the surespot password, so make them strong! Never shall a private key be stored on a surespot server. Man in the middle- MITM is currently thwarted by the following: standard SSL implementation. When a user is created and its public keys uploaded to the server, the server signs the public keys. Clients that download the public key then validate the signature of the key against the hardcoded server public key in the client. This ensures a MITM attack trying to use a rogue key pair to impersonate a user will be prevented. Key versioning/revoking- A user may generate a new pair of key pairs at any time. This process is as follows: the user requests a “key token” from the server the user generates a new pair of key pairs and uploads them to the server along with an authentication signature (username, password, random) and a token signature (the received key token, password) generated by the identity's existing signing private key. the server validates the password and both signatures and if valid increments the “key version” and signs and stores the public keys in the database. the server notifies other users involved in conversations with the revoker that the key has been revoked. clients will receive this revoke notification and act accordingly. the old keys are now considered revoked and any message sent using them will be rejected by the server. Use case: lost/stolen phone- adam lost his phone, luckily he has his identities backed up on Google drive adam buys a new phone and installs surespot adam restores his identities from the backup adam generates a new pair of key pairs successfully attacker with old phone receives revoke
Re: [liberationtech] Resources on electronic voting
phryk in...@phryk.net writes: No clue if it was already covered in this thread, but Estonia just opened up the code of their e-voting system: http://news.err.ee/politics/0233b688-b116-44c3-98ca-89a4057acad8 Note that while they released the code, it's not open source: https://github.com/vvk-ehk/evalimine/blob/master/LICENSE (Which is sad; not sure why they did that.) I've been using E-Vote by Massimo DiPierro lately and been pretty happy with it, by the way: https://github.com/mdipierro/evote -K -- 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] One time pad Management system?
Paul Elliott pelli...@blackpatchpanel.com writes: Are there any practical one time pad management systems out there, GPLed for GNU/Linux? Is anyone working on one? If not, does anyone want to start? Thank You for considering this question. http://red-bean.com/onetime I'm actively working on v2 and hope to have it released pretty soon (the changes are not difficult, it's just writing the regression tests, maintaining format compatibility, and stuff like that that takes time). You can see the v2 changes on this branch: http://viewvc.red-bean.com/onetime/branches/2.x/ (Am moving it to GitHub or Gitorious soon, but it started out in Subversion and that's where the source can be browsed right now.) The main changes coming out in v2 are: - A fix for an embarrassing bug (one with no security implications as far as I'm aware, but that causes the output to be larger than necessary. Yes, I somehow wrote the encryption and compression calls in the wrong order years ago, don't ask me how :-) ). - A change to stop a tiny theoretical information leak (OneTime uses Pad IDs to keep track of which stretches of which pads have been used before; the Pad IDs in theory leaked a tiny bit of information about the pad. Which is silly -- there's no need to have even a theoretical leak, since one can just ensure that the stretch of pad used for ID purposes is never used for encoding, and that's what I should have done in the first place). - A few improvements in option handling and other UI stuff. Now, one might reasonably ask: why would anyone want to use a one-time pad system in practice? I use it for a few different kinds of rare situations. One, if I'm not reasonably confident about the provenance of GnuPG on a system, but I am confident about the provenance of its Python interpreter. Two, to bootstrap trust: e.g., if my GnuPG public key has changed, those who share a pad with me can get the new one via a method that is not dependent on any old public keys. Three, to throw a little diversity into the surveillance stream: watchers no doubt have bots looking for saving messages in PGP and various other popular encryption formats. OneTime makes 'em work a little harder! :-) -K -- 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] DecryptoCat
Jens Christian Hillerup j...@hillerup.net writes: So what do we do about this? Opening the source code as an argument for security no longer suffices. How can we raise money for rigid and independent quality assurance of software that in this case is designed to potentially saving lives? And how can we make sure that this money flows into the fund and out to the QAers on a regular basis? For what it's worth: OpenITP's Peer Review Board [1] is intended to help with exactly this. It's under development; Eleanor Saitta on this list can give a better sense of where things stand at this point, but I wanted to let you know the effort is under way. By the way, I don't agree with the original blog post's [2] ad hominem remarks about Cryptocat's developers. The most popular programs are always where people are most excited to find bugs. It's therefore hard to compare Cryptocat's development against that of other security projects, given that many of those projects are not as popular as Cryptocat -- in other words, it's hard to establish what the baseline is or should be. So I wish people would be more circumspect about flinging around words like incompetent; it just sets a bad tone and doesn't help anything. Cryptocat's response [3] is exemplary. -Karl [1] http://wiki.openitp.org/peerreviewboard:start [2] http://tobtu.com/decryptocat.php [3] https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ -- 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] Encryption Works: How to Protect Your Privacy in the Age of NSA Surveillance
Micah Lee micahf...@riseup.net writes: I have added the CC license to the bottom of the web version: https://pressfreedomfoundation.org/whitepapers/encryption-works-how-protect-your-privacy-age-nsa-surveillance And I've also uploaded the source LibreOffice ODT, so it'll be easier for people to create derivative works: https://pressfreedomfoundation.org/sites/default/files/encryption_works.odt Wonderful, thanks (and I see you put a link to the ODT at the bottom of the web page too). -Karl On 07/02/2013 03:01 PM, Karl Fogel wrote: Micah Lee micahf...@riseup.net writes: Freedom of the Press Foundation just published a whitepaper about how to protect your communications from NSA (or any other) surveillance. Micah, thanks ( nice job). Two quick questions: 1) The CC-BY license info is only visible on the PDF; any reason it's not on the web version? 2) Is the document available in source form (that is, whatever master format you edited to generate both web and PDF versions)? The reason I ask (2) is that if someone wanted to make either an abbreviate or an extended version of this guide, it would be easiest for them to start from that source format. Best, -Karl https://pressfreedomfoundation.org/whitepapers/encryption-works-how-protect-your-privacy-age-nsa-surveillance The whole thing was inspired by this Edward Snowden quote: Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Specifically we go over: * What crypto is and what makes it secure * What sort of software you can trust * Using Tor, and global adversaries * How OTR works and how to use it right * How PGP works and how to use it right * How Tails can help ensure high endpoint security -- 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] Help with Privacy online
Justin Breithaupt usacomputert...@gmail.com writes: I would like to know what services are available for e-mail that don't share my private information, like Gmail does when it shares my info. A simple answer is: riseup.net (and donate some money to them, if you can afford to, by the way). The answer might get more complicated (and more difficult to implement) the more deeply you delve into your needs, of course. But for a start, riseup.net is probably a good place to look. I would also like to know the best way to secure a Ubuntu based PC against privacy and security problems that allow the government and other people into your PC. This is a more complicated topic. Use good passwords, only install open source software, and don't run unnecessary services (e.g., don't run a web server on your laptop, database server, etc, unless you have to). Make sure your screen lock goes on automatically; also remember to turn it on when you leave the laptop alone. Don't get seen on camera typing your password. Etc :-). (As other replies indicate, really thinking about this problem gets complicated.) -- 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] Encryption Works: How to Protect Your Privacy in the Age of NSA Surveillance
Micah Lee micahf...@riseup.net writes: Freedom of the Press Foundation just published a whitepaper about how to protect your communications from NSA (or any other) surveillance. Micah, thanks ( nice job). Two quick questions: 1) The CC-BY license info is only visible on the PDF; any reason it's not on the web version? 2) Is the document available in source form (that is, whatever master format you edited to generate both web and PDF versions)? The reason I ask (2) is that if someone wanted to make either an abbreviate or an extended version of this guide, it would be easiest for them to start from that source format. Best, -Karl https://pressfreedomfoundation.org/whitepapers/encryption-works-how-protect-your-privacy-age-nsa-surveillance The whole thing was inspired by this Edward Snowden quote: Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. Specifically we go over: * What crypto is and what makes it secure * What sort of software you can trust * Using Tor, and global adversaries * How OTR works and how to use it right * How PGP works and how to use it right * How Tails can help ensure high endpoint security -- 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
Alireza Mahdian alireza.mahd...@gmail.com writes: this is to prevent modifications that would render it as a malware. I haven't signed the code yet so I am just protecting myself from such liabilities. Hi, Alireza Mahdian. Please don't call the code open source nor free software when it's not. In this case, it's not: the requirement to get your permission before changing the code violates the Free Software Defintion and the Open Source Definition in clear unambiguous ways. If you place these additional restrictions on people's freedom, then the software is simply not open source. You can distribute it under any terms you want, but don't call those terms something they are not -- that's just misleading. Thank you, -Karl (with my opensource.org hat on, which it usually isn't when I post here) On Jun 28, 2013, at 12:51 AM, John Sullivan jo...@fsf.org wrote: I like the idea, so I was checking it out. I was confused by this statement in the download terms: Since MyZone Client Application is open source, you will not change any part of MyZone’s code without the written approval of MyZone’s copyright owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu). Can you explain what you mean? Usually, something called open source can be modified without any additional written approval. -john -- John Sullivan | Executive Director, Free Software Foundation GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=8096. -- 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 -- Alireza Mahdian Department of Computer Science University of Colorado at Boulder Email: alireza.mahd...@gmail.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] Quick Guide to Alternatives
Moritz Bartl mor...@torservers.net writes: On 17.06.2013 21:06, micah wrote: Do you have any suggestions for what Riseup can do to resolve that concern for you? I don't disagree with you, I'm just curious about solutions here. I am happy to repeat myself, since the issues I have with Riseup have not been addressed so far. Tactical Tech should not be recommending Riseup, and Riseup only, without stressing that you *always* have to trust the operators and the systems behind them, and at least mention some alternatives to Riseup. A longer article should also discuss that Gmail is probably better security-wise than some random open source installation. In the end it depends on your threat model, right? Anyway: #1 There was a point in time when Riseup purposely decided to stop pushing decentralization. A lot of work was and is put into features that are *not* documented properly and not easily available to replicate. #2 As an example, the website states minimal logging. What the hell is minimum logging other than marketing speech? Why don't you tell you're users what you are logging, up to the last byte? Especially when you provide a sensitive service like email, extra care should be put in the documentation and specification of logging policies. And by that I mean down to the config files of the syslog daemon. Riseup makes a more specific promise than just minimal logging. They say: We do not log your IP address and some other things, at https://help.riseup.net/en/about-us . It's not the up to the last byte you're asking for above, but it's more specific than just minimal logging. #3 How hard is it to be transparent about money and sponsors? There's some big money behind Riseup now, and you guys should be very open about the sources. Surprisingly hard. It's actually a fair bit of work to maintain up-to-date donor pages, especially when you have some donors who want to remain anonymous and other donors who want to be listed under a name slightly different from the one they donated under, etc... I'm not saying this is the reason Risup isn't showing that information. But the answer to your direct question is: surprisingly hard. (Speaking from abundant personal experience, running one US non-profit organization and being on the board of another.) There's an opportunity cost to maintaining that information publicly. Whoever takes on the task gives up something else they could be doing -- something that might be more interesting and feel more productive to them. Volunteers are surely standing by, and all that :-). -- 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] Privacy Promises and Client-Side Betrayal.
Hi. I thought this might be of interest here: http://www.rants.org/2013/06/09/privacy-promises-and-client-side-betrayal/ Thesis: Apps that promise self-destructing data, promise emails that can be un-sent, etc, are making promises they cannot keep -- at least not if they are to work with recipients who use open source software (but in principle they can't work reliably even in proprietary environments). We can't expect most users to follow these things at the level of detail we do -- so it's all the more important that we try hard to avoid making users promises that we can't keep. (I'm aware that we is a fuzzy term here and doesn't always include the people who most often make such promises... But we can call it when we see it, at least.) Best, Karl -- 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] For everyone and their grad students: Fake, pay-to-publish journals conferences
If we'd all stop using the verb publish when we really mean endorse, much conversation on this topic would be clearer. (Not aimed at anyone here, by the way; just a general observation :-) .) -Karl Richard Brooks r...@acm.org writes: Part of the problem is the use of publications to drive academic retention, tenure, promotion. Publications should be vetted by a set of peers that only allow publication of quality goods. The journals are supposed to be the gate-keepers and enforcers of quality. This means that the people trying to publish have an incentive to publish as much as they can. Having the authors pay gives the supposed gatekeepers an economic incentive to publish more and lower quality. If costs are not paid by the subscribers (who should in principle only pay for quality goods) then it is hard to find a model that is going to keep the bar high enough. Professional societies (IEEE, ACM, etc.) can probably maintain quality in this scenario. But that decreases the number of journals and the amount of available info... On 04/08/2013 04:19 PM, michael gurstein wrote: I'm wondering whether some global equivalent of the copyright collection societies http://en.wikipedia.org/wiki/Copyright_collective might not work although they would need to be updated to reflect current issues around CC and related licensing… Richer institutionscould pay in for access to Open Access journals perhaps on a pay per usage basis and given a relatively modest cost structure for OA journals this might be sufficient to cover operating costs on a Robin Hood basis for poorer and LDC libraries. …just a thought. M *From:*liberationtech-boun...@lists.stanford.edu [mailto:liberationtech-boun...@lists.stanford.edu] *On Behalf Of *LISTS *Sent:* Monday, April 08, 2013 10:58 AM *To:* liberationtech@lists.stanford.edu *Subject:* Re: [liberationtech] For everyone and their grad students: Fake, pay-to-publish journals conferences Indeed, this would be a problem. However, it's already a problem, which is to say that poorer universities cannot afford subscriptions to EBSCO and whatnot to begin with, and thus their faculty have trouble keeping up with research in comparison to those at richer schools. What I'm suggesting here could at least alleviate this problem, because richer schools would subsidize /access/ to research. Moreover, I'm imagining that the cost of pay-to-publish would be far lower than for-profit schemes like TF and Elsevier, thus enabling poorer school's libraries to save money and actually increase their faculty's ability to do research (assuming that's their mission). However, I don't have numbers on this, so I could be wrong. - Rob Gehl On 04/08/2013 11:52 AM, Glassman, Michael wrote: The problem with this is that faculty from wealthier universities will have much more capability to publish than faculty from less wealthy universities. And those who can get their work supported by those with money have an upper hand of getting more information out than those who do not have their work supported. There is already enough of this in grants perhaps. Maybe we could envision something like low cost subscriptions so that individuals or universities could pay a small fee to journals they use a lot. This works well on a number of political blogs. Michael From: liberationtech-boun...@lists.stanford.edu mailto:liberationtech-boun...@lists.stanford.edu [liberationtech-boun...@lists.stanford.edu mailto:liberationtech-boun...@lists.stanford.edu] on behalf of LISTS [li...@robertwgehl.org mailto:li...@robertwgehl.org] Sent: Monday, April 08, 2013 1:45 PM To: liberationtech@lists.stanford.edu mailto:liberationtech@lists.stanford.edu Subject: Re: [liberationtech] For everyone and their grad students: Fake, pay-to-publish journals conferences Or, potentially, university libraries could shift from buying subscriptions to paying for their university faculty's publication fees. If the ultimate product is an open access publication, then the issue isn't paying for access, but rather paying to produce the public good. - Rob Gehl On 04/08/2013 11:42 AM, michael gurstein wrote: Publishing may be dirt cheap but any systematic/formal e.g. academic publishing isn't free... So the problem is that while there is a necessary and valuable shift from commercial publishing (and outrageous profiteering) to open access online publishing there really aren't any good business models yet to cover the (much less but not totally trivial) costs of the new forms of academic publishing. If for whatever reason (and there are lots including the issues pointed to here) one doesn't want to go to a pay for
Re: [liberationtech] Vote results on Reply to Question
Yosem Companys compa...@stanford.edu writes: We voted on #2 because that was the issue Joseph Lorenzo Hall raised (see: http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03767. html). He specifically asked for the following: Has the possibility of reconfiguring libtech to not reply-all by default been broached? Maybe I'm the only one that trips over it so often. best, Joe The question Joe raised is not the one that was on the ballot. Michael Allen has already explained why. You could, for example, *add* a mailing list's address to a Reply-to header while leaving any existing Reply-to (the one the poster set) intact, thus avoiding the can't find my way back home problem. There are arguments for and against that, but in any case that choice was not on the ballot. The ballot presented a choice that no one asked for, as far as I'm aware. Regarding the present-day setting of the list: FYI, the list settings are configured as follows: (1) Should any existing Reply-To: header found in the original message be stripped? If so, this will be done regardless of whether an explicit Reply-To: header is added by Mailman or not. - No (2) Where are replies to list messages directed? Poster is *strongly* recommended for most mailing lists. - This list I cannot tell from the archives what the list actually does, because Reply-to headers are not preserved in the archives in any form, not even in the mbox file downloads, as far as I can tell. (If someone could look at one of my messages, in their own personal email client archive, and say how many Reply-to headers there are and what's in them, that would be useful, since I always set Reply-to explicitly to a personal address.) In any case, if you're saying that the list now adds the list address to Reply-to, but also preserves any other information already in the Reply-to header (if any), then that's an interesting outcome... but it's not one of the possible results from the question actually voted on: * Do you want replies to Liberationtech list messages directed to reply-to-all or reply-to-poster? I don't object to a democratic result, but there was mis-formed ballot here, and an unclear presentation of the issue at hand. If we want to do it right, it's a bit more complex than what we actually did. I guess this problem comes up in democracies a lot :-). -Karl -- 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] Vote results on Reply to Question
M. Fioretti mfiore...@nexaima.net writes: Karl, in this message from you there was one Reply-To header, set to: Karl Fogel kfo...@red-bean.com, liberationtech liberationtech@lists.stanford.edu Thank you. Then we're at least avoiding the can't find my way back home problem, which is good. about the general issue: most decent email clients can recognize messages from mailing lists and allow their user to ignore the reply-to header. Which is what I (and many other people) do, on this and any other mailing list I'm subscribed to. You may set it to mickeymo...@mouseton.com, and by default my replies to all messages sent to liberationtech@lists.stanford.edu would still go ONLY to liberationtech@lists.stanford.edu Oh, none of this is an issue for me personally. My mail client is heavily scripted customized already. I'm worried, instead, that someone else will send a private message (say a private reply for my eyes only) and have it accidentally go to the list. I've seen this happen on other lists that add the list address to Reply-to, and it's not pretty. In other words, the failure mode of the current setting is much more severe than the failure mode of leave Reply-to alone, since if someone accidentally sends a message privately that should have been public, the recipient can always point this out and then the sender can simply re-post to the list. And that failure mode makes everyone vulnerable, since what the private responder is saying might contain information that is private about me too! But that's always been the argument against the current setting. If the vote is that we live with this danger, then that's the vote. At least we're only adding to reply-to, never destroying any data. -Karl -- 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
Tom Ritter t...@ritter.vg writes: Hi all - at the risk of shilling, my company has released an Open Source tool called You'll Never Take Me Alive. If your encrypted laptop has its screen locked, and is plugged into power or ethernet, the tool will hibernate your laptop if either of those plugs are removed. So if you run out for lunch, or leave it unattended (but plugged in) at starbucks, and someone grabs your laptop and runs, it'll hibernate to try to thwart memory attacks to retrieve the disk encryption key. Not foolproof, but something simple and easy. It the moment it only supports Bitlocker, but support for Truecrypt is coming[0]. If you have suggestions - add them to the github issues page. https://isecpartners.com/news-events/news/2013/march/yontma.aspx https://github.com/iSECPartners/yontma What a terrfic idea, Tom -- thanks. Your paragraph above doesn't mention it, but appears this is (right now) only for MS Windows. Any chance of Linux support coming soon, and in the long run of getting folded in as a kernel service so that I can just configure it from my System Settings menu eventually? :-) I'm sure others will be asking about Mac OS X too. -K -- 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] Please Vote on Reply to Question
I vote that the list not munge the Reply-to header. Some call this reply-to-poster, but it really means leave Reply-to however the original poster set it. If OP set it to the list, that's fine; usually the OP sets it to their preferred personal address, of course. http://producingoss.com/en/mailing-lists.html#reply-to has all the references I know of on this ancient and well-exercised debate :-). Best, -Karl Sarah A. Downey sa...@getabine.com writes: Reply to poster as default. Thanks. On Thu, Mar 21, 2013 at 7:36 AM, Collin Sullivan coll...@benetech.org wrote: I vote for reply-to-list as default. Yosem Companys: Dear Liberationtech list subscribers, Several of you have petitioned to change Liberationtech mailing list's default reply to option from reply-to-all to reply-to-poster. Given the debate (see links below), we have decided to put the issue up for a vote: - Do you want replies to Liberationtech list messages directed to reply-to-all or reply-to-poster? Please vote by submitting your preference to me by 11.59 pm PST on Sunday, March 24, 2013. Any votes received after this date and time will not be counted. Thanks, Yosem One of your moderators PS To read a summary of the advantages and disadvantages of reply-to-all, click on the corresponding links below: - Reply-to-all considered useful: http://marc.merlins.org/netrants/reply-to-useful.html - Reply-to-all considered harmful: http://www.unicom.com/pw/reply-to-harmful.html If you'd like to read the entire debate on the Liberationtech list, please click on the links below: http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03767. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03768. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03769. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03771. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03772. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03773. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03774. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03775. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03776. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03777. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03778. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03779. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03780. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03781. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03782. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03783. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03788. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03789. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03790. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03791. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03799. html http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg03801. html -- 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 -- Collin Sullivan Human Rights Program Associate Benetech Human Rights Program Email: colli...@benetech.org GPG: 0x78657D4D XMPP: collin.sulli...@riseup.net OTR: A0946621 68E641FA 4DFBF9F0 10B20AA9 88601348 11C7957D 5A99DAF7 1D0DD4BC EE243287 943AD67A https://www.benetech.org - Technology Serving Humanity https://www.martus.org - Martus Human Rights Bulletin System https://www.hrdag.org - Human Rights Data Analysis Group -- 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] Can HAM radio be used for communication between health workers in rural areas with no cell connectivity?
fl...@pgm.com writes: Thanks to Ali-Reza for reposting Dr. Dey's reply. If you are looking for lowest-cost short to medium range communications using ham radio, Android phones are not the answer. You still need VHF or UHF radio hardware. There are at least 20 radio manufacturers in China that make small variations on a common design of VHF transceiver, that can be bought for less than USD 50 each (often much less). Radio repeaters can be built using these same transceivers. There is also a huge surplus of transceivers in the US that have been made obsolete by the FCC's narrow band mandate, that you can buy for a few dollars, particularly interesting for higher power mobile radios. Shipping will be your major expense there unless you are able to do a freight container full at once. The biggest problem in most countries is almost always getting legal permission to use amateur radio for other public purposes. Solve that problem for your group, and find out what frequencies and power levels are permissible, and the technical issues are much easier. Because it's related to the same problem domain, I'll point out: The OpenBTS project is an open-source software-based GSM access point, that allows people to use standard consumer GSM cell phones to communicate in a network that anyone (with the right hardware) can set up. http://en.wikipedia.org/wiki/OpenBTS http://openbts.blogspot.com/ http://wush.net/trac/rangepublic http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTS (I'm not sure whether the burden of having the right hardware for OpenBTS is lower or higher than the burden of having ham radio tranceivers.) HTH, -Karl -- 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] Safe app like Dropbox?
Gilson Schwartz gilson.schwa...@gmail.com writes: I did install Cloudfogger but after a trial I just can´t find my way out of the app. Any hints? Their Help desk was unsupportive after a first mail asking for help. On the general topic of this thread: FileRock just got open sourced. I haven't used it, but have seen it billed as a secure Dropbox clone. http://blog.filerock.com/2012/12/were-going-open-source/ -Karl On Sun, Jan 6, 2013 at 8:35 AM, Brad Beckett bradbeck...@gmail.com wrote: Or better yet -- encrypt your data with CloudFogger, it's free: http://www.cloudfogger.com/en/ I told DropBox long ago that encryption would reck havoc on their de-duplication and that people would continue to use it until they feel their data is secure. 2 years ago I asked for two factor authentication. They ignored me, and a lot of accounts were compromised. Now they have 2 factor. I still do not trust my data on Amazon servers therefor I encrypt. The nice thing about CloudFogger is that well it's free and also has matching mobile apps. - Brad Beckett On Sun, Jan 6, 2013 at 2:05 AM, Eugen Leitl eu...@leitl.org wrote: On Sun, Jan 06, 2013 at 09:49:25AM +0100, Jerzy Łogiewa wrote: Hello! Dropbox is completely convenient, but source is closed and I do not really want storing my data on their server. What other app exist? Anything truly open and support own remote storage, but working as: drop into folder, auto syncro happens on a supported platform? Try OwnCloud. -- 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] Google Bows Down To Chinese Government On Censorship
Maxim Kammerer m...@dee.su writes: On Fri, Jan 4, 2013 at 8:50 AM, Martin Johnson greatf...@greatfire.org wrote: This latest move was fully controlled by Google and can as such only be described as self-censorship. The impression I am getting from my contacts at Google is that this is not true. That is, Google apparently lost to Chinese Cyber experts in being able to keep this censored keywords system up, and decided to drop it altogether. PR team then, for whatever other reasons, decided to keep complete silence on the subject. Of course, one can then ask why didn't Google simply force HTTPS on Chinese users to begin with, but they probably considered complete block of Google by GFC too real a possibility, and were too afraid to lose market share. [not directed at Maxim, just a general thought on this topic] Rushes to judge Google about its handling of China should probably be tempered by the knowledge what the Chinese government really wants is to push local companies like Baidu. The government's protectionist policy for Chinese web technology companies just happens to mesh nicely with their censorship policy in this case. So if Google pushes too hard, the overall result will just be to give more market share to Baidu, which doesn't really help the cause of freedom for Chinese Internet users either. Google's executives understand this very well. There's a good argument to be made that the things they could do to look brave and principled are not the things that would actually help information freedom in China in the long run. Please note that I'm not making a shades of gray point, just a complexity point. Best, -Karl -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
