Re: [liberationtech] /. ITU Approves Deep Packet Inspection
scussions over at circleid.com: > >> http://www.circleid.com/posts/20121203_wcit_off_to_a_flying_start/ > >> Apparently ITU fellows are disgruntled that they cannot control the > >> media coverage and complain about all the "misinformation". > >> > >> Best, > >> André > >> > >> > >> -- > >> 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 -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] /. ITU Approves Deep Packet Inspection
There are a number of places where data security is mentioned, but not very extensively. A particularly worrying requirement is R-6.2.1/2: The DPI signatures library is required to be securely maintained and not visible to unauthorized users. I.e. ordinary users MUST not be able to see the rules that are applied during the DPI. Obviously this may be overridden through some other way. In particular, governments could mandate that DPI rules are published by any entity applying DPI at some point. Apart from this, most requirements refer to national guidelines for data security and retention. For EU countries this means the Data Protection and Data Retention Directives and national implementations of same. Other countries obviously have other rules. As you say, it is a very technical document for the most part, and does not really deal with all the implications of DPI. Thankfully, it also does nothing to mandate this kind of equipment in any way. However, thinking further, I could definitely see how _later_ standards could refer to Y.2770 to mandate a DPI-FE (functional entity) at some specific point, or, even more likely, that governments could mandate such an entity for ISPs operating within their jurisdiction. No more need for a state-run ISP in order to keep shit under control, no, hire some large telco to run your networks, and mandate use of Y.2770 compatible DPI equipment instead. That, I think, is the main danger posed by this document. TL;DR: Standards for DPI makes it easier for bad governments to outsource ISP (including DPI) onto external large telcos. E.g. Saudi + TeliaSonera. Best /P On 05 December, 2012 - Fenwick Mckelvey wrote: > Hi all, > To Nick's point re:what's the problem. I think part of the problem > with the ITU talking about DPI is that it is a case of forum-shifting. > The ITU is a less accountable body than a government. The challenge is > that on a quick skim of this document I find it highly technical in > nature and lacking in any discussion of privacy or data retention > issues. How should we regulate these technologies? Can their > regulation be left to technology firms? It'd be of note to compare the > Canadian CRTC's own debates over traffic management practices > (http://www.michaelgeist.ca/content/view/6021/125/). > > I'd also point to the great work Chris Parsons > (http://www.christopher-parsons.com/blog/) has done on this issue, > especially: http://www.deeppacketinspection.ca/. > > Happy to chat more re: framing matters. It's an interest event and I > am really appreciating all the comments here as always. > > Best, > Fen > > On Wed, Dec 5, 2012 at 10:34 AM, Petter Ericson wrote: > > Reading the draft document provided by Asher, I find nowhere any > > reference to this being a required activity for any ISP. Instead, it > > talks mainly about how data flows between generalised entities (think > > "devices"). > > > > So no, if ITU received a more governing role of the internet, that would > > not _in itself_ lead to Y.2770 being a "required standard" to implement > > for all ISPs (and I have no idea how this would happen anyway, given it > > doesn't concern itself with specififying any actions for ISPs). > > > > There are legitimate uses for DPI, though the examples cited in the > > draft seems to be more about limiting BitTorrent traffic... > > > > So basically, the standard is probably going to do mostly these things: > > a) DPI equipment manufacturers can claim to be "standards compliant" > >which is a selling point in some circumstances > > b) DPI might get more widely accepted as a technique. It is up to us and > >other hackers to make sure that censorship and traffic discrimination > >is not. > > c) It might be slightly more easy for surveillance tech to interoperate > >between manufacturers, given that the main point of the standard is > >to suggest everyone output data and accept rules in a standard way. > > > > To be frank, I have been trying to find out what the fuss has been about > > regarding this standard and come up.. not blank, as it _is_ worrying > > that ITU is spending time on this shit, but at least I haven't found > > anything to inspire the absolutely massive shitstorm I have been seeing > > in certain places (e.g. /.). Is it just because it's the ITU doing it > > rather than, say, ISO or ANSI? > > > > Best > > > > /P > > > > On 05 December, 2012 - Nicholas Judd wrote: > > > >> Hi list, Nick from techPresident here. If I could tap into your hive-mind > >> intelligence for a moment to help me be more precise about explaining why > >> th
Re: [liberationtech] /. ITU Approves Deep Packet Inspection
Transparent IPv4-to-IPv6 tunneling, detection of certain forms of abuse, QoS modificaton, traffic monitoring and shaping. Obviouly, these are mostly happening at a firewall or equivalent, which is kind of the point. Very little DPI is legitimate in core networking. /P On 05 December, 2012 - Wayne Moore wrote: > What legitimate uses do you see? > > On 12/5/2012 10:34, Petter Ericson wrote: > > There are legitimate uses for DPI, > > -- > Necessity is the plea for every infringement of human freedom. > It is the argument of tyrants; it is the creed of slaves. > > William Pitt (1759-1806) > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] /. ITU Approves Deep Packet Inspection
On 05 December, 2012 - Pavol Luptak wrote:
> On Wed, Dec 05, 2012 at 07:27:27PM +0100, Christian Fuchs wrote:
> > If this approval by the ITU is true - then it is no surprise at all,
> > but what one would expect. What else has the ITU in the past ever
> > been than an instrument that supports capitalist interests and
> > commodification of the ICT and telecommunications industries?
> >
> > DPI can advance large-scale monitoring of citizens by the
> > state-capital complex that is connected by a right-wing state
> > ideology of fighting crime and terror by massive use of surveillance
> > technologies and a neoliberal ideology of capitalist organisations
> > that want to make a profit out of surveillance and want to hinder
> > the undermining of intellectual property rights.
>
> DPI censorship is not a 'competitive' advantage, so it's quite likely that
> in a pure market society ('anarchocapitalism') without strong socialistic
> governments and their stupid Internet regulations, most Internet providers
> WILL
> NOT censor their connections, otherwise they will loose their customers. Most
> customers are not willing to pay for censored Internet if they can choose
> unfiltered free Internet. And the only one who can take them this right is
> a monopoly for laws/regulations - the centralized government.
Without being drawn wildly off-topic, let me just note that you are
assuming that the customers of a generic ISP in a "pure market society"
are the people getting the "internet" access.
/P
--
Petter Ericson (pett...@acc.umu.se)
Telecomix Sleeper Jellyfish
--
Unsubscribe, change to digest, or change password at:
https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail
I would claim that the expected behaviour would be to use any available keystore by default, or alternatively (if none is found) to install its own in a "default" location. On *nix, this is usually ~/.gnupg, and if GPG4Win is "widely" used on windows, I would expect one such keystore to be implemented. However, I am unsure how much of this can be done from browser plugins. Still, with the caveats mentioned further down the thread, I have to say this is a great thing, at first glance. More (and better) encryption tools make more (and better) encryption! Cheers /P On 11 December, 2012 - Robbie MacKay wrote: > "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." > > In some ways this is great: it means novice users don't have to worry about > getting GPG4Win or any other keystore installed first. Simplifying > encryption for end users is definitely better, though I can't speak to the > quality of their implementation. For those of us who already have a GPG > keystore set up (and existing keys) I'd definitely rather it used those. > > On Tue, Dec 11, 2012 at 9:16 AM, Nick Daly wrote: > > > 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 > > > > > > -- > Robbie Mackay > > Software Developer, External Projects > Ushahidi Inc > m: +64 27 576 2243 > e: rob...@ushahidi.com > skype: robbie.mackay > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] Roundcube PGP plugin
Hi! In case you have not tired of webmail-related PGP discussions, a friend of mine just implemented a PGP plugin for Roundcube: http://qnrq.se/rc_openpgpjs_ending_seven_years_of_roundcube_insecurity/ "Roundcube is a popular open source IMAP webmail application. Roundcube is used by Harvard University, UC Berkeley and University of Michigan. Apple Mac OS X 10.7 uses Roundcube per default in its Mail Server. While writing this a lazy Google dork estimates 133 000 public Roundcube installations. PGP support was first requested seven years ago and set critical six years ago. PGP support has been requested actively ever since. One of the core developers began the development of his PHP implementation, the Enigma plugin, two years ago but the plugin has not been made functional yet. Today I am proud to release a beta version of my Roundcube plugin that implements PGP using the OpenPGP.js (based on GPG4Browsers) JavaScript library. rc_openpgpjs enables OpenPGP to function in the user’s browser so that fundamental key storage security isn’t immediately broken by design, in opposite to the official Enigma plugin." Code is available on github: https://github.com/qnrq/rc_openpgpjs Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Skype Open Letter: CALL FOR SIGNATORIES
> I call on you to review the following draft for our Open Letter to > >>> Skype and present your name or the name of your organization as > >>> signatories: > >>> > >>> http://www.skypeopenletter.com/draft/ > >>> > >>> The letter will be released soon. Feedback is also welcome. > >>> > >>> Thank you, > >>> NK > >>> > >>> -- > >>> 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 > > > > > > -- > > Grégoire Pouget, > > New Media Desk // Bureau Nouveaux Médias > > Reporters Without Borders // Reporters sans frontières > > @fightcensors_en @fightcensors_fr > > GPG ID : 2BBC1ECE > > > > > > -- > > 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 -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] weev (@rabite) makes a Statement of Responsibility
g seditious thugs, liars and tyrants. I say this is the duty of all decent citizens left. God bless. Andrew Auernheimer (*Those who assert our right to access public web APIs can donate to the effort to overturn the Computer Fraud and Abuse Act. More info at cfaadefensefund.com. - Andrew Auernheimer) -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Mega
Seems like the good mr. Bubbles is at least partially putting his money where his mouth is. http://thenextweb.com/insider/2013/02/01/kim-dotcom-puts-up-13500-bounty-for-first-person-to-break-megas-security-system/ Have a go, everyone! Best /P On 23 January, 2013 - Bernard Tyers - ei8fdb wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 23 Jan 2013, at 12:45, Eugen Leitl wrote: > > > On Wed, Jan 23, 2013 at 07:40:13AM -0500, bbrewer wrote: > >> > >> > >> "All the money in the world", and still, so many listed problems on this > >> new service. Malicious intent, or just complete rush to give the finger to > >> the authorities? > > > > You don't seem to know Kim "dotcom" Schmitz well. > > You bet me to it. IMO, this is a two fingers from Kim Dotcom to the US > government, and a PR stunt to garner support from his new host country of New > Zealand. > > He feels hard done-by (and he has a point). It's a PirateBay.org style > campaign and will probably be resonably successful. > > The best outcome possible is to point out the issues with it (as is being > done), explain why they are important, and hammer those messages through in > the media. Those messages will miss some people (as they will only see "free > and secure"), but that's always the way. > > bernard > > - -- > Bernard / bluboxthief / ei8fdb > > IO91XM / www.ei8fdb.org > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJQ/+MOAAoJENsz1IO7MIrrAa8IAJDPY7eDe2Dz1iw1FJo3Zr08 > c8uRiyjJHPmqZt1194A7hOCax+eP+LwkFoa7DDp4NoXw8O4Frc8DogTXD+soxjDh > 4doC2y8AV9y6AC2HUMUrkyEu9M7bra9o9Cbos+sdxLptnL8qnvXE0pWTeOrPiBgZ > uu+Dq4vGyni0nZoXv7XTNox5lE/Rp0bC+9mSNZy1JmB1o7h1RyotU6OtA0ydLK94 > XvaGIyaG/PcBqz/zXjDNmRw4oI84UaYsy23gIOS+yW4D4vtwRs0lqMiZjvyJskgU > JYg6Oh+fwsVIJ1H7iJ9JhqMMuaWwQZxPU/w5qirZQlVD8x1mFE2I9G4HMfHqcMo= > =XOUN > -END PGP SIGNATURE- > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Cryptography super-group creates unbreakable encryption
w/silent-phone-base/silentphone/utils/CTCoutryCode.cpp
index dd67a09..a36db86 100755
--- a/original/silent-phone-base/silentphone/utils/CTCoutryCode.cpp
+++ b/new/silent-phone-base/silentphone/utils/CTCoutryCode.cpp
@@ -430,6 +430,8 @@ int fixNR(void *p, const char *in, char *out, int iLenMax){
else if(in[0]=='0' && in[1]=='0'){ iCheckCC=1;}
// else {strncpy(out,in,iLenMax);out[iLenMax]=0;return 0;}
+ if(in[0]=='.'){strncpy(out,in,iLenMax);out[iLenMax]=0;return 1;}
+
...
@@ -474,6 +476,8 @@ int findCSC_C_S(const char *nr, char *szCountry, char
*szCity, char *szID, int i
...
+ if(l && tmp[0]=='.')return 0;
...
diff --git a/original/silent-phone-base/silentphone/xml/parse_xml.cpp
b/new/silent-phone-base/silentphone/xml/parse_xml.cpp
index 937d86b..bcde78b 100755
--- a/original/silent-phone-base/silentphone/xml/parse_xml.cpp
+++ b/new/silent-phone-base/silentphone/xml/parse_xml.cpp
@@ -979,7 +979,7 @@ void storeXML_W(const short *pszFileName, NODE *node){
#else
char bufFn[1024];
- void convert16to8S(char *dst, int iMaxDstSize, short *src, int iLen);
+ void convert16to8S(char *dst, int iMaxDstSize, const short *src, int iLen);
--
Petter Ericson (pett...@acc.umu.se)
--
Unsubscribe, change to digest, or change password at:
https://mailman.stanford.edu/mailman/listinfo/liberationtech
[liberationtech] CNN writer on leaving Facebook
my page automatically become the passive conduits for any of my messages to all their friends just because I paid for it. That brings me to Facebook's most recent shift, and the one that pushed me over the edge. Through a new variation of the Sponsored Stories feature called Related Posts, users who "like" something can be unwittingly associated with pretty much anything an advertiser pays for. Like e-mail spam with a spoofed identity, the Related Post shows up in a newsfeed right under the user's name and picture. If you like me, you can be shown implicitly recommending me or something I like -- something you've never heard of -- to others without your consent. For now, as long as I don't like anything myself, I have some measure of control over what those who follow me receive in my name or, worse, are made to appear to be endorsing, themselves. But I feel that control slipping away, and cannot remain part of a system where liking me or my work can be used against you. The promotional leverage that Facebook affords me is not worth the price. Besides, how can I ask you to like me, when I myself must refuse to like you or anything else? I have always appreciated that agreeing to become publicly linked to me and my work online involves trust. It is a trust I value, but -- as it is dependent on the good graces of Facebook -- it is a trust I can live up to only by unfriending this particularly anti-social social network. Maybe in doing so I'll help people remember that Facebook is not the Internet. It's just one website, and it comes with a price. -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Here Come the Encryption Apps
On 10 March, 2013 - Ralph Holz wrote: > Hi, > > > For some reason some cryptographers seem to perpetuate the idea that > > correctly using crypto is something utterly complex and should be > > reserved to experts like themselves, or at least require their solemn > > approval. This is not the case with cryptographers that I know (who > > I find that an extreme interpretation of what cryptographers utter. > > But let's have data. How many tools do you know that have been written > by people with "good basic CS education, undergrad-level course in > cryptography, solid programming skills and some common sense" (your > quote) - and that have been shown to be bug-free? On the other hand, how > many tools have been developed by people who seemed to fall in those > categories and yet have been shown to be flawed? To be fair: How many tools do know that have been written and shown bug-free by _anyone_? Bugs and misimplementations are hardly the exclusive domain of undergrads. Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Slepeer Jellyfish -- 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] Announcing a privacy preserving authentication protocol
e direction the internet headed with regards to > > > privacy. Or it's total disregard of it. > > > > > > I've come up with a novel architecture of existing old and recent > > > cryptographic tools that offers a substantial improvement in security and > > > privacy. I call it Eccentric Authentication. > > > > > > Unlike the current CA-system that requires people to trust them to gain > > > security, my protocol turns that upside down. Security is what the > > protocol > > > provides. Trust is what people gain by using the system. > > > > > > The protocol is mostly compatible with the current internet as we know > > it. > > > And it prevents most phishing attacks for free. > > > > > > I have the hope that this protocol can shift the balance of security and > > > privacy a bit back towards the people. > > > > > > I've written a technical description at [1]. I hope it makes things a bit > > > clear. Feel free to comment. > > > > > > With regards. Guido Witmond. > > > > > > 1: http://witmond.nl/ecca/eccentric-authentication.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 > > -- > > 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 -- Petter Ericson (pett...@acc.umu.se) -- 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] Mozilla Persona - Getting rid of passwords on the web
Greetings, Though the video is very light on cryptographic background, it does do a good job of introducing the Mozilla ideas for a password-free web (except for your e-mail provider). Definitely worth watching, and potentially implementing, imo: http://pyvideo.org/video/1764 Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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] SUBSCRIPTION
On 03 April, 2013 - Jillian C. York wrote: > On Wed, Apr 3, 2013 at 10:39 AM, Eugen Leitl wrote: > > > On Tue, Apr 02, 2013 at 06:45:37PM +0100, Bernard Tyers - ei8fdb wrote: > > > > > Suggestion 1: Can we trial putting the UNSUBSCRIBE footer (that part of > > the > > > e-mail that no-one reads) at the top of the e-mail so everyone sees it? > > > > No, because then *everybody* has to see 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 > > > Which is worse: > > >- Everyone having to read the footer, or >- Several idiotic "how do I unsubscribe from this?" emails per week? > > Serious question. > I have not seen several per week. Rather the volume seems to be one every couple of weeks. Doing a little archive digging, I find only one sent during all of March, though I admittedly only looked at the subjects and thus might have missed a few that showed up as replies in other threads. I would argue that having a header added to each and every mail is significantly worse, though really, this mailing list is somewhat lacking in standard mailing list practises (do not top-post! ;) ) In conclusion: you are severely overstating the problem, and the solution of having the footer as header is annoying, non-standard and completely unnecessary for the slightly more tech-savvy users of this list. Best regards -- Petter Ericson (pett...@acc.umu.se) -- 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
It will take a while for things to adjust to the > >> ability of the > >> > >> Internet to make publishing dirt-cheap. > >> > >> > >> > >> > >> > >> > >> > >> On 04/08/2013 12:19 PM, James Losey wrote: > >> > >> I think it's curious how this article frames the journals > >> as "open > >> > >> access" rather than a more appropriate "pay to play" > >> > >> > >> > >> On Mon, Apr 8, 2013 at 6:05 PM, Yosem Companys > >> mailto:compa...@stanford.edu> > >> > >> <mailto:compa...@stanford.edu> <mailto:compa...@stanford.edu>> > >> wrote: > >> > >> > >> > >> From: Nathaniel Poor >> <mailto:natp...@gmail.com> > >> > >> <mailto:natp...@gmail.com> <mailto:natp...@gmail.com>> > >> > >> > >> > >> > >> > >> > >> http://www.nytimes.com/2013/04/08/health/for-scientists-an-exploding- > >> w > >> > >> orld-of-pseudo-academia.html > >> > >> > >> > >> "The scientists who were recruited to appear at a > >> conference called > >> > >> Entomology-2013 thought they had been selected to > >> make a presentation > >> > >> to the leading professional association of > >> scientists who study > >> > >> insects. But they found out the hard way that they were > >> wrong" > >> > >> > >> > >> This has been a problem for a while, but now it's > >> big enough to be a > >> > >> newspaper story. > >> > >> > >> > >> --- > >> > >> Nathaniel Poor, Ph.D. > >> > >> http://natpoor.blogspot.com/ > >> > >> https://sites.google.com/site/natpoor/ > >> > >> -- > >> > >> Too many emails? Unsubscribe, change to digest, or > >> change password > >> > >> by emailing moderator at compa...@stanford.edu > >> <mailto:compa...@stanford.edu> > >> > >> <mailto:compa...@stanford.edu> > >> <mailto: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 > >> <mailto:compa...@stanford.edu> or changing your settings > >> > >> at > >> https://mailman.stanford.edu/mailman/listinfo/liberationtech > >> > >> > >> > >> > >> > >> -- > >> > >> === > >> > >> R. R. Brooks > >> > >> > >> > >> Associate Professor > >> > >> Holcombe Department of Electrical and Computer Engineering > >> Clemson > >> > >> University > >> > >> > >> > >> 313-C Riggs Hall > >> > >> PO Box 340915 > >> > >> Clemson, SC 29634-0915 > >> > >> USA > >> > >> > >> > >> Tel. 864-656-0920 > >> > >> Fax. 864-656-5910 > >> > >> email: r...@acm.org <mailto:r...@acm.org> > >> > >> web: http://www.clemson.edu/~rrb > >> > >> > >> > >> -- > >> > >> Too many emails? Unsubscribe, change to digest, or change > >> password by > >> > >> emailing moderator at compa...@stanford.edu > >> <mailto: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 > >> <mailto: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 > >> <mailto: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 > >> <mailto: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 > >> > -- > 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 -- Petter Ericson (pett...@acc.umu.se) -- 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
Journals semifrequently acquire an exclusive copyright license, meaning that you the author can not actually put your own article up for free downloading. Instead, you need an article subscription to even access the text (except possibly "unfinished" versions). That, in short, is the difference between publishing and endorsing a specific article. Though, of course, we could just wait for Karl to wake up and tell us what he meant :) Best /P On 09 April, 2013 - michael gurstein wrote: > If I understand what you are saying I think you've got it a wee bit mixed > up... > > -Original Message- > From: liberationtech-boun...@lists.stanford.edu > [mailto:liberationtech-boun...@lists.stanford.edu] On Behalf Of Petter Ericson > Sent: Tuesday, April 09, 2013 12:29 AM > To: liberationtech > Subject: Re: [liberationtech] For everyone and their grad students: Fake, > pay-to-publish journals & conferences > > Gettings things published (as in, readable by the public) is no longer a > problem, and journals should, frankly, not concern themselves with this any > more. > [MG>] but this is precisely what journals do... i.e. they "publish" (after > selecting what to "publish* > > However, they still need to pick-and-choose among the myriads of published > works to get a high-quality and on-topic selection of articles, which they > would then endorse, rather than publish. > [MG>] they pick and choose among the myriad of non-"published"* works to > getetc.etc. > > The problem is how to make money and repute flow properly through this > system, without getting bad side effects (i.e. no publishing for poor > people/institutions, no access to what endorsements were made for poor > people/institutions, every journal turns (even more) into an echo chamber > etc. etc.). > [MG>] okay... > > That, at least, is my understanding of it. > [MG>] er... and mine > > M > > Best > > /P > > [MG>] *"publishing" of course means something different post-Internet... I > think what it means is putting something into a context which authenticates > the process of "publication" i.e. it is "published" because we/they/someone > says that it is being "published"... But maybe in the end we are saying the > same thing but using words in a slightly different way. > > On 08 April, 2013 - michael gurstein wrote: > > > Perhaps you could explain what you mean here as your comment seems rather a > > non sequitur. > > > > M > > > > -Original Message- > > From: liberationtech-boun...@lists.stanford.edu > > [mailto:liberationtech-boun...@lists.stanford.edu] On Behalf Of Karl > > Fogel > > Sent: Monday, April 08, 2013 9:30 PM > > To: liberationtech@lists.stanford.edu > > Subject: 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 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 C
Re: [liberationtech] Stop promoting Skype
You misunderstand. Signing up to these services is generally easy, and there are a number of instances up and running for each. However, there is as far as I know, no integrated service running an XMPP service, a mail server, an OStatus instance, all connected and having the same user database, reasonable connections between them etc etc. It is certainly doable to install all of these, but currently it is hard, in the sense that you need some rather in-depth knowledge to properly glue everything together. Making it easy to set up a server with a multitude of useful services will not make each and every person set such a server up, but it may mean that a much larger group of people _know_ someone who can set up such a server. Incidentally, I have been thinking, writing (one or two) blog posts on, but due to time constraints not actually implementing or promoting such a project. Best /P On 07 June, 2013 - Yishay Mor wrote: > "If all this already exists, why isn’t everybody doing it? Well, simply > because there is *no integration at all among all those objects*. " > > No. we don't need no software bundles. we don't need no sleek installers. > How long does it take me to set up a gmail account? facebook account? > flickr account? 20 seconds. how much does it cost me to set up? how much > does it cost me to maintain? (ok, skype is an exception, I do need to > install). > > See that's the standard you're competing with. Most users don't own server > space, physical or virtual, and would not in a million years be convinced > to buy any. > > Yishay > > ___ >http://www.yishaymor.org > () ascii ribbon campaign - against html e-mail > /\www.asciiribbon.org - against proprietary attachments > > > On 7 June 2013 09:47, M. Fioretti wrote: > > > On Fri, Jun 07, 2013 09:16:32 AM +0200, Eduardo Robles Elvira wrote: > > > Stop promoting google hangout and hotmail, yahoo, gmail, outlook.com... > > =) > > > > and start promoting their replacement via user-friendly bundling of > > Free Software that already exist and may run in a portable way on any > > cheap VPS: > > > > > > http://stop.zona-m.net/2013/01/the-alternatives-to-apple-facebook-c-already-exist-shall-we-package-them/ > > > > -- > > M. Fioretti http://mfioretti.com http://stop.zona-m.net > > > > Your own civil rights and the quality of your life heavily depend on how > > software is used *around* you > > -- > > 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 -- Petter Ericson (pett...@acc.umu.se) -- 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] Identi.ca, Diaspora, and Friendica are more secure alternatives to Facebook.
e money; they use data mining to sell targeted, contextual ads. "In > > some ways,” she says, “that's the source of the problem, the fact that > > we've just given up all of our data in return for free services." > > > > Community-hosted, decentralized social media, on the other hand, allow > > people to maintain ownership of their data. These platforms use a > > principle called “federation” to connect a vast network of servers to > > one another. If the NSA wants to collect the data of all the users on > > a decentralized network, it has to contend with a large number of > > disparate server owners who could be anywhere in the world, a much > > more complicated task than issuing a single subpoena or hacking into a > > centralized server. > > > > "There's a resiliency to having data spread across multiple sites; > > that's the way the web was intended to work, and we need to bring that > > back,” says Christopher Webber, the founder of MediaGoblin, a > > federated, free software replacement for YouTube, Flickr, SoundCloud, > > and other media hosting services. Other projects, like Identi.ca > > (which is similar to Twitter), Diaspora, and Friendica are > > replacements for conventional social media networks, and they work. > > The number of users on federated networks is hard to calculate—again, > > their data are spread out instead of stored centrally—but Identi.ca > > alone counts 1.5 million users. > > > > PRISM could be the impetus that gets more communities to begin using > > these networks. As of Monday morning, nearly 200,000 people have > > signed a petition that calls for an investigation of the NSA's spying > > program, and last week activists launched prism-break.org, a site that > > offers a menu of options for those looking to "opt out" of government > > surveillance. > > > > The NSA’s spy apparatus worked because of the centrally owned and > > operated networks we have relied on to socialize. How the PRISM story > > will play out politically remains uncertain, but there are more > > immediate ways for users to regain privacy. Try another social > > network, and bring your friends to experiment with you. If you oppose > > turnkey government spying, go where the NSA doesn’t have a backdoor. > > > > Disclaimer: Libby Reinish is an employee of the Free Software > > Foundation, which is a member of StopWatching.Us, a coalition of more > > than 75 organizations calling for a full congressional investigation > > of the NSA's spying program. > > -- > > 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 -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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
On 08 July, 2013 - Nadim Kobeissi wrote: > > On 2013-07-08, at 2:48 PM, Reed Black wrote: > > > On Mon, Jul 8, 2013 at 11:00 AM, David Goulet wrote: > >> > >> Furthermore, looking at those lines of code, there is simply NO comments > >> at all, > >> nothing to help peer review, to explain why this or that is done that way > >> and > >> nothing linked to any design document. This is in my opinion VERY > >> important that > >> developers design their system/subsystem beforehand *especially* a crypto > >> design > >> in a public document. And, if it has to change, the design should be peer > >> reviewed before even making one line of code. > >> > >> So, the technical critical issue, CryptoCat responded well, quickly but the > >> point here is that there is a problem in terms of how development is done > >> and > >> how *little* the maintainability of the code is. > > > > I think there is a bigger problem in the commit messages. Looking at > > the history, many are "tweak" "guehh" "update" "FIX THE BUG" and some > > of those are tied to large many-purpose Swiss Army Knife commits. > > > > Without descriptive commit messages and single-purpose commits, > > community review is highly unlikely. It takes an order of magnitude > > more effort for a reviewer to suss out the intent of a code change. > > The reviewer is also much less likely to ask about suspicious side > > effects if he's starting with infinite possibility of intent on first > > encountering the code. Few volunteers will make a routine effort. > > > > > > Remember when someone tried slipping this into the Linux kernel? > > > > + if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) > > + retval = -EINVAL; > > > > Ask if something that subtle have been spotted so quickly if it were > > one of many Swiss Army Knife "guehh" commits. > > I'm sure "guehh" and so on are either exceptions or relate to very irrelevant > commits. > If they're not, then we definitely have a commit documentation problem! > > NK Looking at the commit history, you do. Specifically, when fixing bugs, you do note the trac number, but you do not include a link to the bug in question, and neither do you mention what the actual cause of the bug was. Instead you write "Fix #", sometimes with a "hopefully", or "maybe". A brief description of what the bug/feature entailed, and how it was fixed helps immensely if anything goes wrong later, and it also makes other peoples understanding of the codebase significantly more likely. Also, there are numerous instances where you do one thing, and also various cosmetics or clean-up operations, for example d158c4cd from late May. Try to separate commits into fully independent change sets, where code functionality commits are clearly marked as such, and code cosmetics likewise. Generally, software development is messy. Try not to make that show in the commit history. Best /P > > > > > > > I think any project that relies on community review for security needs > > to first stop and ask what would make community review likely. At the > > least, that's some venue for review discussion where the developers > > are reading, single-function commits, and descriptive commit messages. > > Does anyone know if there's something like a "best practices" page to > > point to for maintaining a healthy reviewer community? > > -- > > 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 -- Petter Ericson (pett...@acc.umu.se) -- 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
> > > What are the steps for sending Bob a message using Cables? > > > > This isn't rhetorical, I'd actually like to know what the steps are. > > Roughly I think this is correct: > > 0. Download https://www.dee.su/liberte > 1. Boot any modern computer with the usb disk inserted > 2. launch Claws email client > 3) write message to bob's cable address and press send > > If you have a supported platform, you can skip 0-2 and replace it with > 'install cables' - as one might install a modern browser. I do not think that installing a modern browser entails building it from source for most people. > > If you're going to say that using Gmail easily happens in any browser on > any OS, I guess I'd tend to disagree. > > If we add "securely" into the picture, I guess I'd just laugh and laugh > and laugh. Sadly. It is really a bummer that PRISM exists and that > Google appears to be under the boot of that system. Though accessing > Gmail with Chrome is clearly better than any other choice! > Unfortunately, the question wasn't how to communicate _securely_, but how to communicate _at all_, which is what most people aim to do in the first place. Please do not pretend that @.onion is as easy to remember as j...@cervant.es or something similar, or that installing dependencies and building from source is similar to a one-click installer. Best /P > All the best, > Jacob > -- > 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 -- Petter Ericson (pett...@acc.umu.se) -- 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.
On 15 July, 2013 - Nathan of Guardian wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/15/2013 05:55 PM, Pavol Luptak wrote: > > Any idea how to have offline secure messaging (when Jabber+OTR is > > not possible to use)? > > Gibberbot already partially implements this, and we are working with > ChatSecure and others to move forward with a standards-based solution > to this. While we already have OpenPGP support on Android, we don't > think PGP is the way to go for efficient mobile chat, and also are not > ready to abandon forward secrecy as a feature. > > And so, our OTR offline solution is comprised of the following pieces: > > 1) Client/App supports XMPP extension for message delivery receipts > and auto-retry: > http://xmpp.org/extensions/xep-0184.html > > While the person you are trying to send a message to may be offline at > the very moment you want to message them, it is very likely that they > will be online at some point in the near future. If your chat client > is always running in the background on your device, it can sense when > they come online, and deliver the message you wrote earlier. By > supporting delivery receipts, you can confirm it did indeed get > through to them, and if not, continue auto-retrying until it does. The main problem I see with this is that this still requires both clients to be online at the same time, something which Threema, Heml.is etc. avoids. My phone internet access is seldom a constant thing, so this is obviously not ideal. > > 2) XMPP server that supports offline messages storage and delivery: > http://xmpp.org/extensions/xep-0160.html > http://xmpp.org/extensions/xep-0091.html > ejabberd support: http://www.process-one.net/en/ejabberd/protocols/ > http://prosody.im/doc/modules/mod_offline > > XMPP already has a well-established mechanism for this, and many > open-source servers like ejabberd and prosody support it well. > > 3) Client that supports long-lived OTR sessions. If a chat > conversation is held open, then the same OTR session key should be > used as long as possible, i.e. until one of the participants request a > session restart. > I assume that these two options go together, i.e. that an OTR session is kept alive from both ends, and offline message delivery is used to send messages over that session. Definitely a good idea - if you only work with a single client per user. Alternatively, that you would attempt to keep an OTR session going with each resource ever seen, and send multiple messages (OTR v4 according to wikipedia). Long-lived OTR session keys is also something of a relaxation of the forward secrecy requirement, is it not? (Playing a bit of devil's advocate here) > 4) Optionally: use the OTR v3 shared "extra" symmetric key generation > feature to encrypt offline messages and send those via a mobile push > service. Sidechannel message delivery definitely sounds interesting. Could you expand on the guarantees made regarding this key? Is it the same as for regular OTR keys? (PFS, etc) > Would love comments on this. Anything else we might have missed? > To be quite frank, for offline message delivery to an unknown client, the OTR model rarely holds up very well. As such, I would propose just going for XEP-0027 (PGP-encrypted messages) if there is no OTR session available, and trust the offline message delivery services of the server to get them to the destination. This drops forward secrecy, but makes it actually possible to send messages in the first place. Moving transparently onto OTR as soon as possible would still be a priority of course. Best /P > +n > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR5I2eAAoJEKgBGD5ps3qpXSsP/2Bd1R7fw4C2LeGM3RAZuFup > Jhd/YIBt4I7Yh4tIGGs2Bn7B3gCGmDXRTnqWPtj8IpE/XINB0Pr4gME0kC/xV0Kf > dFotFwps3WkihJXaR2IeK4FmDoLX4xVETqiFFwZSE4FM2zNJiVPsXIDzeIXKp//9 > HSU/Rhv4y/ycSPONqC0Wy6x+0TOM6arcTGmg9noDbnBWIGxbOEU9jKSpJhzDHSz7 > 79rMorer7KS1p88zJ+tMoprdwGqtf0wEZacwgIOKcZRUPxWveqUPcANOyGfi40u4 > 11vvbwVBj0hETTCWDtxFOO61JTLGWiqlVNd6bsPICr08cfe42s6hJEMnay00tWaJ > ovcw4MCAHP/c9sWqy5KSufa04NIMlON5g83cQRGevqnEMJYDHHlrLyFTHO8M+ZY+ > CF6wmiGJIHQyet6xxjPZH97vk+tPC6eTnoLFiNxS2SlAJYmQxmcAtqvFO+HLDBNM > wOosJ0TjA3gmDwU6udhpPbe/BBigemnFedRahta1PbRVgl/1oDwH8ecwoj9xTWtq > O/LmJbiAkqCf4YnFq+1sbyTXvRw9MBdXXJUc3vClbxmGQ6xZjMAZKnOVpbKeSmSd > v73UVvtNXsV4XfVOICbRS84dakxA3YG9P+T37un82r0tyDJUB7DXe2HZwiGHQ58T > YJUO0epUFqDfidtrWyJf > =7SnB > -END PGP SIGNATURE- > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.
Re: [liberationtech] How to contact hacktivists?
> I am also curious to know please - what is the situation with > hacktivists? How do you find them? That depends entirely on your definition of 'hacktivist'. Is it a) Most of the people on this list - i.e. activists who heavily use the internet for their activism? b) Hackers (Jargon file meaning) who are also activists, e.g. Richard Stallman and the FSF crowd? c) Hackers (Blackhat meaning) who are also activists, i.e. defacing websites, exfiltrating databases, etc. for political gain? d) Hackers (Script kiddies) who are also activists, i.e. DDoSing or using 'hacking tools' for political gain? e) Hackers (expanded Jargon file meaning) whose actions are inherently political, though they might not consider themselves as such, e.g. meshnet/crypto/subsistence projects etc.? or any number of other meanings. Disregarding the third meaning, all are rather easy to get a hold of, given some level of immersion in internet culture. Best /P -- Petter Ericson (pett...@acc.umu.se) -- 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] Random number generator failure in Rasperri Pis?
> Just came accross this article, apparently showing the bad quality of > the hardware RNG in Raspberri Pi devices. > > http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ I see nothing in the blog post indicating that the random data from the Pi HW is bad. Rather, he uses that to show how good random data should look, after which he implements RANDU to show how _not_ to do it. I have seen this being posted here and there as a "look, Pi HWrand bad" thing, but I have to wonder how many actually read the blog post, considering he even ran rngtest for a thousand runs with no failures on the output of /dev/hwrng Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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] Random number generator failure in Rasperri Pis?
On 19 July, 2013 - KheOps wrote: > Hey, > > Le 19/07/2013 14:22, Petter Ericson a écrit : > >> Just came accross this article, apparently showing the bad quality of > >> the hardware RNG in Raspberri Pi devices. > >> > >> http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ > > > > I see nothing in the blog post indicating that the random data from the > > Pi HW is bad. Rather, he uses that to show how good random data should look, > > after which he implements RANDU to show how _not_ to do it. > > > > I have seen this being posted here and there as a "look, Pi HWrand bad" > > thing, but I have to wonder how many actually read the blog post, > > considering > > he even ran rngtest for a thousand runs with no failures on the output of > > /dev/hwrng > > I might have read it and concluded too fast, and yes obviously he shows > how another implementation is failing. > > But I see this: > sudo cat /dev/hwrng | rngtest -c 1000 > which for me refers to the previously installed driver for RasPi > > and then he says: "We were lucky that none of the tests failed for that > run; sometimes there are a few failures. RANDU, on the other hand fares > very badly" > > Meaning that RANDU is really bad whereas the RasPi one would be ... > better but still failing to pass some tests in some occasions? You raise a good point. I must admit ignorance in regards to the specifics of linux, HWRNGs, /dev/hwrng and /dev/random, but my personal guess would be that /dev/hwrng supplies true random values, while /dev/random is the place to look for properly hashed and checked random output. Having true random values fail a FIPS-140 test is definitely not out of the realm of possibility, though I have no idea how common it would be. It might be a good idea to do some digging around the components and source code, though. If for no other reason than it always is. Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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] From Snowden's email provider. NSL???
On 09 August, 2013 - Moritz Bartl wrote: > On 09.08.2013 13:15, Nadim Kobeissi wrote: > > Yup, Cryptocat has had build assurance for quite some time. > > "Sorry, not possible to backdoor without people noticing" > > is still a valid line of defence and has been one for a while. > > You should think about splitting Cryptocat software development and > service operation into two separate legal entities. Service operation > could legally be based in whatever country, say, Antigua. > > There was at least one wiki meant to collect information regarding the > legal requirements per country, but I don't remember where. That would be the Digital Rights Watch, I believe (http://diriwa.org), though it is/was much more ambitious, and aims to collect all available relevant information about information and security legalities and realities. Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Naive Question
That, and civil disobedience á la Lavabit.
/P
On 09 September, 2013 - Matt Johnson wrote:
> All of the sneaky signs, email headers and web page badges assume the
> FBI, or whoever the adversary is are incompetent or inept. That does
> not see like a safe assumption to me. The only prudent approach is to
> assume your adversary is intelligent and competent.
>
> My guess is that the only defense against NSL's and the like is
> through policy. I realize that may be blasphemy on this list, but
> there it is.
>
> --
> Matt Johnson
>
>
>
> On Mon, Sep 9, 2013 at 1:26 PM, LISTS wrote:
> > What are the legal precedents in terms of "wink, wink, nudge, nudge,
> > djaknowhatimean?"
> >
> > - Rob Gehl
> >
> >
> > On 09/09/2013 02:24 PM, Shava Nerad wrote:
> >
> > You are awesome,clever, and full of tricks. :) Should I credit you with
> > this?
> >
> > yrs,
> >
> >
> > On Mon, Sep 9, 2013 at 3:40 PM, Case Black wrote:
> >>
> >> There's a more subtle variant to this idea...
> >>
> >> Regularly state ("put up a sign") that you HAVE in fact received an
> >> NSL...with the public understanding that it must be a lie (there's no law
> >> against falsely making such a claim...yet!).
> >>
> >> When actually served with an NSL, you would now be bound by law to remove
> >> any such notification...thereby signaling the event.
> >>
> >> Regards,
> >> Case
> >>
> >>
> >> On Mon, Sep 9, 2013 at 1:24 PM, LISTS wrote:
> >>>
> >>> I wonder if there's a false analogy here. Hypothetically, the
> >>> librarian's sign could fall down (maybe the wind blew it over) whereas a
> >>> notice on a site would have to be removed via coding. There would be
> >>> little other explanation, even in the case where one does not
> >>> affirmatively renew the "dead man's notice" (the countdown that Doctorow
> >>> suggests in the article). Such an affirmative act might lead a court to
> >>> believe that one has indeed informed the public about an NSL.
> >>>
> >>> - Rob Gehl
> >>>
> >>>
> >>> On 09/09/2013 12:18 PM, Dan Staples wrote:
> >>> > Presumably, if this type of approach became widely adopted, it would be
> >>> > a useful service for an independent group to monitor the status of
> >>> > these
> >>> > notices and periodically publish a report of which companies had
> >>> > removed
> >>> > their notice.
> >>> >
> >>> > On 09/09/2013 12:52 PM, Scott Arciszewski wrote:
> >>> >> Forgot the URL:
> >>> >>
> >>> >> http://www.theguardian.com/technology/2013/sep/09/nsa-sabotage-dead-mans-switch
> >>> >>
> >>> >>
> >>> >> On Mon, Sep 9, 2013 at 12:29 PM, Scott Arciszewski
> >>> >> mailto:kobrasre...@gmail.com>> wrote:
> >>> >>
> >>> >> Hello,
> >>> >>
> >>> >> I saw this article on The Guardian[1] and it mentioned a librarian
> >>> >> who posted a sign that looked like this:
> >>> >> http://www.librarian.net/pics/antipat4.gif and would remove it if
> >>> >> visited by the FBI. So a naive question comes to mind: If I
> >>> >> operated
> >>> >> an internet service, and I posted a thing that says "We have not
> >>> >> received a request to spy on our users. Watch closely for the
> >>> >> removal of this text," what legal risk would be incurred?
> >>> >>
> >>> >> If the answer is "None" or "Very little", what's stopping people
> >>> >> from doing this?
> >>> >>
> >>> >> Thanks,
> >>> >> Scott
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>>
> >>> --
> >>> Liberationtech is a public list whose archives are searchable on Google.
> >>> Violations of list guidelines will get you moderated:
> >>> https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe,
> >>> change to digest, or change password by emailing moderator at
> >>> compa...@stanford.edu.
> >>
> >>
>
[liberationtech] Silent Phone source code available on GitHub
So, Silent Circle (well, Silent Phone) is finally open source! 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 - Forwarded message from Jim Burrows - From: Jim Burrows To: SilentCircle/silent-phone-base Cc: pettter Subject: Re: [silent-phone-base] Impact of ZRTP library critical security vulnerabilities (#5) @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". - End forwarded message - -- Petter Ericson (pett...@acc.umu.se) -- 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] dark mail alliance
On 01 November, 2013 - Maxim Kammerer wrote: > On Fri, Nov 1, 2013 at 5:44 PM, Sacha van Geffen wrote: > > “Together our mission is simple: To bring the world a unique end-to-end > > encrypted protocol and architecture that is the ‘next-generation’ of > > private and secure email. What we call ‘Email 3.0.’ is an urgent > > replacement for today’s decades old email protocols (‘1.0’) and mail > > that is encrypted but still relies on vulnerable protocols leaking > > metadata (‘2.0’),” they said in a blog post announcing the alliance. > > Does their mission also include making their service offerings > redundant? E.g., anyone who does not need SMTP interoperability (let's > call this innovative concept “Email 3.0”) can use cables communication > [1], which is serverless. I would imagine that they are aiming for something with reasonably easy-to-remember identifiers (and less anonymity), as well as something where you could relatively easily sync your inbox between devices, at least as an option. I'd say join the list (or approach them directly) and post your ideas if you feel that you can contribute, though. They've got the names, media attention and marketing to get _something_ rolling which is better than the status quo. Best make it as good as possible. /P > > [1] http://dee.su/cables > > -- > Maxim Kammerer > Liberté Linux: http://dee.su/liberte > -- > 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. -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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] 13 years in the making...
Wireless communication is inherently about transmitting and receiving radio waves, and triangulating any omnidirectional radiation source is relatively easy. So the answer is "yes, assuming they have agents in close enough proximity and using the correct tools". A big thanks to the Commotion team, your work has been very useful to me personally in making localised meshes in my neighbourhood. Happy new year /P On 02 January, 2014 - S.Aliakbar Mousavi wrote: > Dear Sascha, > > Happy new year too. > Thanks for informing us. > > Before sending to the Iranian users I want to make sure about its > security. You mentioned Commotion V1.0 is safe. *Can Iranian government > find the location of users by triangulating it or so?* > > Best, > Aliakbar > > > > > On 31 December 2013 15:02, Sascha Meinrath wrote: > > > Hi all, > > > > Commotion v1.0 is out! Helping spread safe, secure, ubiquitous wireless > > connectivity for all: http://www.newamerica.org/node/99668 > > > > We've come such a helluva long way from our humble Y2K beginnings of a > > group of > > hackers meeting up in my living room... But, as Samuel Johnson once said, > > "Great > > works are performed not by strength but by perseverance" (that and an > > incredibly > > talented and dedicated team ;). > > > > Now we just need to spread the word to all our Internet Freedom-loving > > peeps. > > > > Happy New Year!!! > > > > --Sascha > > > > > > -- > > 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. > > > > > > -- > S.Aliakbar Mousavi > -- > 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. -- Petter Ericson (pett...@acc.umu.se) -- 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] Help reform copyright in the EU
Greetings As some of you may have heard about, the European Commission has _finally_ presented the public consultation on copyright they were bound to do. Unfortunately, it is a rather hefty questionnaire (80 questions), has not been translated to any member language but english, and is, on the whole, rather technical. In order to help people respond to questions relevant to them, and to help explain those questions, a site was put together by some hackers from the Austrian Pirate Party during 30c3. You can find this site at http://copywrongs.eu Please, do go there and respond to the questionnaire, getting many, varied, and opinionated responses is vital to have a good chance at making copyright actually work again. Time is rather limited (5th of February, thanks, EC) so please take the time as soon as possible to respond. TL;DR http://copywrongs.eu Go there, make your voice heard (yes also non-EU citizens) Best /P -- Petter Ericson (pett...@acc.umu.se) Telecomix Sleeper Jellyfish -- 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] Chatter
No source available. No details on protocol. No details on key exchange, generation, or anything else. No interest, sorry. /P On 05 May, 2014 - AntiTree wrote: > Highlighting this as one of those new to market secure messaging apps. > I find this one interesting just because John McAfee is apparently > involved* with it. > > http://www.chadder.im/ > -- > 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. -- Petter Ericson (pett...@acc.umu.se) -- 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.
