[liberationtech] Berlin Biennale Hackathon feat. various P2P/social projects

[carlo von lynX]

It started rather informally and even a bit rough concerning the working
conditions but yesterday it turned out so professional and productive that
it deserves to be comunicated better:

There is a hackathon event related to Berlin's Biennale, together with GNUnet, 
Briar, SecuShare, Lorea, UnlikeUs, TheGlobalSquare and a special guest from 
Bitcoin on the topic of Distributed Social Networks.

The plan is to sit down together and synchronize our development efforts; 
understand each other's architectures; to distribute tasks, share code and 
reduce duplication. Hereby we want to invite you to hack with us.

It is taking place at IN-Berlin, a hackerspace in Moabit at
Lehrter Straße 53, 10557 Berlin, until 17th of May, but most
of us will be around for several days longer and keep meeting in town.


-- 
»»» psyc://psyced.org/~lynX »»» irc://psyced.org/welcome
 »»» xmpp:l...@psyced.org »»» https://psyced.org/PSYC/
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] New Twitter transparency report

[carlo von lynX]

On Wed, Jul 31, 2013 at 03:10:42PM -0500, Anthony Papillion wrote:
> > orders. We believe it?s important to be able to publish numbers of
> > national security requests ? including FISA disclosures ?
> > separately from non-secret requests. Unfortunately, we are still
> > not able to include such metrics."

The day they will be permitted to, it will no longer be relevant.

Why make civilians feel uncomfortable day-in day-out if you can
PRISM a copy of the entire "private" traffic of direct messages
etc and include it into your XKeyscore search engine?

> Personally, I wonder what would happen if firms banded together and
> simply said 'screw it, we're publishing everything short of usernames
> and investigation details"? If a majority of firms did this, how would
> the government respond?

With more PRISM.

Don't expose to private companies how much you are using their
data. Just grab it all and throw it at your real-time indexer.

--
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] We'll make ourselves a GNU Internet.. GADS, PSYC, distributed search

[carlo von lynX]

You broke the Internet.
We'll make ourselves a GNU one.

https://gnunet.org/internetistschuld
http://internetistschuld.de
http://www.reddit.com/search?q=gnu+internet

This is the video from the talks given by Christian Grothoff, Carlo
von lynX, Jacob Appelbaum and Richard Stallman in Berlin on August 1st.
The talks are in English, even though the welcoming words are in German.

Christian Grothoff's talk summarized the recent revelations about PRISM
and their implications for non-American citizens, industries and
governments. It then presented technical solutions towards a secure
and fully decentralized future Internet, which would address key challenges
for self-determined life created by the world-wide police state.

Interesting details on this:
- A new cryptographic method for a privacy-capable DNS/DNSSEC
  replacement, called GADS.
- A faster and smarter extensible messaging syntax than XML
  and JSON, called PSYC.
- A strategy for distributed and liberated Internet search,
  called RegEx.

Carlo von lynX gave a presentation on how secushare intends to provide
messaging and Facebook-like functionality on top of GNUnet.
Keywords: Scalability by multicast;
  Social graph vs. Onion routing;
  Unsafety of your own server.

Richard Stallman and Jacob Appelbaum added closing notes of free
software and free hardware and responded to questions.


It's not about how much you want to make
believe you got nothing to hide. It's about your
civic duty to not be a predictable populace.


Big thanks to the Pirate Party for providing the venue and the
recording technology.

-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Linux distribution on encrypted USB?

[carlo von lynX]

On Tue, Sep 10, 2013 at 02:41:24PM +0200, Moon Jones wrote:
> A portable distribution on an encrypted stick.

I know of two distributions that do this.. one is TAILS and
the one I prefer is liberte linux.. and the guy who does it
is even on this list.

> But is it feasable to have a two device solution? Media1 has the
> /boot but Media2 has the strong key. Media1 boots, prompts, than
> mounts Media2, takes the key, unmounts Media2 prompting and goes
> ahead with the boot without touching the other drives.

You boot from the stick, then mount the encrypted harddrive
with your pass phrase. The laptop as such is thus no longer
a source of danger without the stick. Best of all, if you
unplug the stick the system wipes its memory and shuts down.
Both systems work this way.

-- 
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] 10 reasons not to start using PGP

[carlo von lynX]

We had some debate on this topic at the Circumvention Tech
Summit and I got some requests to publish my six reasons
not to use PGP. Well, I spent a bit more time on it and now
they turned into 10 reasons not to. Some may appear similar
or identical, but actually they are on top of each other.
Corrections and religious flame wars are welcome. YMMV.



--
TEN REASONS NOT TO START USING PGP
--
   Coloured version at http://secushare.org/PGP



   [01]Pretty Good Privacy is better than no encryption at all, and being
   [02]end-to-end it is also better than relying on [03]SMTP over [04]TLS
   (that is, point-to-point between the mail servers while the message is
   unencrypted in-between), but is it still a good choice for the future?
   Is it something we should recommend to people who are asking for better
   privacy today?

1. Downgrade Attack: The risk of using it wrong.

   Modern cryptographic communication tools simply do not provide means to
   exchange messages without encryption. With e-mail the risk always
   remains that somebody will send you sensitive information in cleartext
   - simply because they can, because it is easier, because they don't
   have your public key yet and don't bother to find out about it, or just
   by mistake. Maybe even because they know they can make you angry that
   way - and excuse themselves pretending incompetence. Some people even
   manage to reply unencrypted to an encrypted message, although PGP
   software should keep them from doing so.

   The way you can simply not use encryption is also the number one
   problem with [05]OTR, the off-the-record cryptography method for
   instant messaging.

2. The OpenPGP Format: You might aswell run around the city naked.

   As Stf pointed out at CTS, thanks to its easily detectable [06]OpenPGP
   Message Format it is an easy exercise for any manufacturer of [07]Deep
   Packet Inspection hardware to offer a detection capability for
   PGP-encrypted messages anywhere in the flow of Internet communications,
   not only within SMTP. So by using PGP you are making yourself visible.

   Stf has been suggesting to use a non-detectable wrapping format. That's
   something, but it doesn't handle all the other problems with PGP.

3. Transaction Data: He knows who you are talking to.

   Should Mallory not [08]possess the private keys to your mail provider's
   TLS connection yet, he can simply intercept the communication by means
   of a [11]man-in-the-middle attack, using a valid fake certificate that
   he can make for himself on the fly. It's a bull run, you know?

   Even if you employ PGP, Mallory can trace who you are talking to, when
   and how long. He can guess at what you are talking about, especially
   since some of you will put something meaningful in the unencrypted
   Subject header.

   Should Mallory have been distracted, he can still recover your mails by
   visiting your provider's server. Something to do with a PRISM, I heard.
   On top of that, TLS itself is being recklessly deployed without forward
   secrecy most of the time.

4. No Forward Secrecy: It makes sense to collect it all.

   As Eddie has told us, Mallory is keeping a complete collection of all
   PGP mails being sent over the Internet, just in case the necessary
   private keys may one day fall into his hands. This makes sense because
   PGP lacks [12]forward secrecy. The characteristic by which encryption
   keys are frequently refreshed, thus the private key matching the
   message is soon destroyed. Technically PGP is capable of refreshing
   subkeys, but it is so tedious, it is not being practiced - let alone
   being practiced the way it should be: at least daily.

5. Cryptogeddon: Time to upgrade cryptography itself?

   Mallory may also be awaiting the day when RSA cryptography will be
   cracked and all encrypted messages will be retroactively readable.
   Anyone who recorded as much PGP traffic as possible will one day gain
   strategic advantages out of that. According to Mr Alex Stamos that day
   may be closer than PGP advocates think as [13]RSA cryptography may soon
   be cracked.

   This might be true, or it may be counter-intelligence to scare people
   away from RSA into the arms of [14]elleptic curve cryptography (ECC). A
   motivation to do so would have been to get people to use the curves
   recommended by the NIST, as they were created using magic numbers
   chosen without explanation by the NSA. No surprise they are suspected
   [15]to be corrupted.

   With both of these developments in mind, the alert cryptography
   activist scene seems now to converge on [16]Curve25519, a variant of
   ECC whose parameters where elaborated mathematically (they are the
   smallest numbers that satisfy all mathematical criteria that were set
   forth).

   ECC also happens to be a faster and more compact encryption technique,
   which you should take a

Re: [liberationtech] 10 reasons not to start using PGP

[carlo von lynX]

Hello again. I will answer to most comments all in a single mail
to avoid clogging libtech. While I wrote this another ten mails
have slipped in, so expect another large reply to those.  :-)


On 10/10/2013 10:00 PM, Richard Brooks wrote:
> 10 reasons to give up, stop trying, hide in a corner, and die.

Sorry if I start talking about the alternatives only at the very end
of the document. This is about becoming aware of how serious the
problem is and to start directing some energy into fueling the
alternatives which are popping up like mushrooms just recently.
For the obvious reasons. And I specifically mention peer reviewing
them. So the message is: go get yourself new tools and teach your
peers to use the new tool of the day.


On 10/10/2013 10:11 PM, Pranesh Prakash wrote:
> Interesting. But someone should also write a piece called "1 reason not
> to criticise security tech without clearly stating threat model which
> serves as basis for that criticism".  What if Mallory isn't a
> well-funded governmental organization but is the admin who runs your
> employer's email servers?

That's a good point. The reason why I don't pay attention to lesser
threat models is that the loss in quality of democracy we are currently
experiencing is large enough that I don't see much use for a distinction
of threat models - especially since alternatives that work better than
PGP exist, so they are obviously also better for lesser threat models.

For example, I don't think that a dissident in Irya (ficticious country)
is better off if no-one but Google Mail knows that he is a dissident.
Should at any later time in his life someone with access to that data
find it useful to use it against the dissident, he can still do it.
And who knows what the world looks like in twenty years from now?

Not saying give up and die. Saying if you can opt for better security,
don't postpone learning about it. If you can invest money in making
it a safe option, don't waste time with yet another PGP GUI project.

> This should actually be two lists: reasons not to use e-mail, and
> reasons not to use OpenPGP over e-mail.

Fine with me. I don't think it makes much difference for the end
user whether SMTP federation or actual PGP is failing her.

> Only reasons 2, 3, 4, 5, 7, 8 are really about OpenPGP (you should've
> stuck to "6 reasons not to use PGP"), and at least three of them are
> really good reasons to look for alternatives. There are no good
> alternatives over e-mail: S/MIME unfortunately suffers from many of the
> same issues as OpenPGP, and then some more.

I don't find S/MIME worth mentioning anymore. It has so failed us.
But maybe I should for completeness?

> And reason #1 is something that the client should take care of (ideally
> with default settings), and not the encryption protocol.  Why are you
> attacking OpenPGP and OTR for this?

Because it's not true that the client can handle it. The fact that an
email address exists implies that some folks will send unencrypted
stuff to it. I experienced this. Just yesterday a friend changed his
life plans because of an unencrypted message. Yes, you could enforce
PGP once it's configured - but you can't opt out from e-mail. That is
evil.

Look at any of the alternatives instead. None of them allow you to
transmit an unencrypted message. In fact all the modern systems use
the public key for addressing, so you can't do it wrong.

> And thank you so much for the comparative chart.  It is *very* useful.

My pleasure. I felt the need to do this since I get asked for
recommendations frequently - and I don't like to say.. wait until
secushare is ready. I don't want to wait for it myself.

> Why doesn't telephony have SIP?

It should. What would the icons be that you would put there?
I'm not familiar with end-to-end encryption over SIP for instance.


On 10/10/2013 10:33 PM, Marcin de Kaminski wrote:
> Agreed. The threat model discussion clearly is too often lost in all
> the current post-Snowden debates. We need to remember that a lot if
> solutions might not be enough to protect anyone against NSAish
> authorities but more than enough against other, most real, threats
> to peoples personal safety. Regular employers, schools, parents, skiddies, 
> whatever. 

I think if employers, schools, parents, skiddies can find out who
you are exchanging encrypted messages with, that can be a very real
threat to you. Using a tool that looks like it does something
totally different.. on your screen, over the network and even on
your hard disk.. can save your physical integrity.


On 10/10/2013 09:55 PM, adrelanos wrote:
> Thank you for doing this work!
> The world needs someone facing the truth, explaining why gpg isn't the
> solution, advocating positive change. It's a communicative task, a very
> difficult one. As long there is gpg, most geeks don't see need to create
> better alternatives.

Glad someone is understanding the positivity in awareness and
will to move forward. Ignoring threats just because 

Re: [liberationtech] 10 reasons not to start using PGP

[carlo von lynX]

Next collection of answers to replies.
Expect yours to be somewhere in here.
Thanks for all the feedback!
I actually expected harsher religious replies!  :)


On 10/10/2013 10:55 PM, Enrique Piracés wrote:
> I think this is a good topic for debate among those who can or are
> currently developing security tools/protocols, and it is one way to
> further discuss usability as a security feature in communities like
> this one. That said, I think it is really bad advice and I encourage
> you to refrain from providing this as a suggestion for users who may
> put themselves or others at risk as a result of it.

The opening sentence says
"Pretty Good Privacy is better than no encryption at all ..."

> Also, I think the title is misleading, as most of the article is about
> why PGP is not an ideal solution for the future (a point where I think
> you would find significant agreement). Again, suggesting not to use
> PGP without providing a functional alternative is irresponsible.

I am suggesting four alternatives and indicating to work harder
to make them viable tools for everyone as we should no longer postpone
replacing PGP and e-mail. Of course I would also appreciate attention
regarding the fifth, secushare.


On 10/10/2013 10:57 PM, Jonathan Wilkes wrote:
> Bitmessage doesn't have forward secrecy, and AFAICT there's no
> way to easily add it later on.

If I understood the principle correctly it allows you to generate
new "accounts" freely, so you can put your *next* account name into
a message. If both sides do this, they can obfuscate their identities
a bit. And you can automate it. You could also re-key at each
message with PGP, but I presume it would make your implementation
incompatible with everybody else's.


On 10/10/2013 11:08 PM, Gregory Maxwell wrote:
> I'm surprised to see this list has missed the thing that bugs me most
> about PGP: It conflates non-repudiation and authentication.
> 
> I send Bob an encrypted message that we should meet to discuss the
> suppression of free speech in our country. Bob obviously wants to be
> sure that the message is coming from me, but maybe Bob is a spy ...
> and with PGP the only way the message can easily be authenticated as
> being from me is if I cryptographically sign the message, creating
> persistent evidence of my words not just to Bob but to Everyone!

I kind-of lumped it mentally together with forward secrecy, because
for both problems the answer is Diffie-Hellman. But you are right, it
is the eleventh reason.

> My other big technical complaint about PGP is (3) in the post, that
> every encrypted message discloses what key you're communicating with.
> PGP easily _undoes_ the privacy that an anonymity network like tor can
> provide.  It's possible to use --hidden-recipient but almost no one
> does.

Guess what, none of the alternative messaging tools would dream of
putting the recipient address close to the message. They just make
sure that it somehow gets there.

> Its also easy to produce a litany of non-technical complaints: PGP is
> almost universally misused (even by people whos lives may depend on
> its correct use), the WOT leaks tons of data, etc.

Oh yes, I completely forgot to link that long article that recently
came out criticizing the PGP web of trust.

> In my view the use of PGP is more appropriately seen as a statement
> about the kind of world we want to have— one where encryption is
> lawful, widely used, and uncontroversial— and less of a practical way
> to achieve security against many threats that exist today.

It is not enough for the purpose of protecting democracy, therefore
it's one of those statements that backfire: The adversary doesn't
care about you making that statement and can use it against you.


On 10/11/2013 12:17 AM, Jillian C. York wrote:
> Just replying to this bit of your reply to me; the rest made sense

Grrreat.

> On Thu, Oct 10, 2013 at 3:08 PM, carlo von lynX
> mailto:l...@time.to.get.psyced.org>> wrote:
> 
> >   If this is still jargony to you, hmmm... you are unlikely to understand
> >   the risks you are exposed to by using the Internet from day to day.
> >   These are concepts that anyone in the circumvention business must
> >   be aware of. You can choose to not read the Guardian article and not
> >   try to understand what's going on, but then you should better just
> >   trust that the conclusion is not made up:
> 
> No, see that's the thing: /I /get it, but I don't think I'm totally your
> target audience (I've been using PGP for years, you're talking to people
> who haven't started yet, right?)

No, not really. It is for the multipliers and activists. The ones that
carry the torch to the people. The Luciphers. You have been carrying
PGP to

Re: [liberationtech] 13 reasons not to start using PGP

[carlo von lynX]

es so invisibly to
> many users. It may be a very bad thing for your threat model.

Ouch.

> I think communications security tools ought to avoid increasing
> vulnerability to any common threats to the greatest extent that they
> can, and when they must compromise they should make it obvious.
> 
> Both for non-repudiation and resistance to traffic analysis PGP
> dramatically reduces user security and does so in a way which is not
> obvious to any except the most advanced users. Both of these could be
> fixed with basically no user impact: Make hidden-recipient the default
> and allow optional clear-text recipient list on ascii armored output;
> add an "authentication" mode which is used by default instead of
> signing for encrypted messages that uses ring signatures (and don't
> allow unauthenticated encryption, geesh).

Not clear to me how an "authentication" mode would work...


On 10/11/2013 09:10 PM, Tempest wrote:
> a fair point. but one could significantly address this issue by hosting
> the public key on a tor hidden service. that would greater ensure that,
> in order to get your key, they would be using a system that protects
> against such threats. hardly an "easy" solution. but it can be solved
> with a little extra planning.

I was just thinking to answer that you could leave out PGP entirely
in this scenario, but...

On 10/11/2013 09:24 PM, Gregory Maxwell wrote:
> Of course, if you can do this and the HS is secure, then you can just
> dispense with the PGP altogether.

Gregory said just that  ;)

> You can work around the limitations I've pointed to here... You
> messages via hidden services without pgp at all.. or you can create
> per-recipient symmetric keys which you clearsign then encrypt with
> hidden-recipent to each person you want to talk to, then symmetrically
> encrypt your actual messages, and discard once a conversation is done.
> 
> But no one does, because it's hard, and some of PGP's downsides are subtle.

Pond, TorChat and various other Tor apps do this kind of thing
in various styles. I also have a prototype of a torifyied PSYC
server so that it serves as a distributed chat system for Tor.
Anything is better than PGP.


On 10/11/2013 06:34 PM, Michael Rogers wrote:
> On 11/10/13 01:14, carlo von lynX wrote:
>>> No one anywhere has solved the problem of asynchronous,
>>> forward-secret group cryptography.
> 
>> I think you have to be a bit opportunistic about it. Briar does it
>> somehow, if I understood correctly.
> 
> Yes and no. I think Elijah's referring to the problem of encrypting a
> message to a group of recipients, so that any recipient can decrypt it
> up until a certain time, and nobody can decrypt it after that. We
> haven't solved that problem, but we do have a different solution for
> asynchronous forward-secret group communication.
> 
> No crypto innovation is involved, it's just a matter of group members
> disseminating the message over forward-secret pairwise links. I think
> Retroshare might do the same... but who knows? ;)

Yes, AFAIU Retroshare does it the same way. GNUnet will probably do
similar in the first iteration, plus we make the channel source
sign the messages so you can't modify them in transit. This allows
us to later add rekeying at the channel source. To clarify: the
channel source is not the author of the message but the host of the
channel.

-- 
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] per-cloud or How to get something ready for folks to use really quick

[carlo von lynX]

Moritz is right, mentioning the same project 8 times is a bit much,
but I can understand that it's annoying if noone bothers to tell
you what they are thinking about it. You need some decent feedback.

On Tue, Oct 08, 2013 at 01:07:20AM +0200, M. Fioretti wrote:
> http://stop.zona-m.net/2013/10/the-real-problem-that-the-percloud-wants-to-solve-and-why-its-still-necessary/
> 
> EXECUTIVE SUMMARY:
> 
> 1) I think mine is the ONLY short-term, feasible way to get the masses
>of average Internet users OUT of walled gardens while still working
>and "feeling" as a real and easy to use cloud service, while being
>a p2p federation of individually owned and used clouds, completely
>compatible with the rest of the current Internet

I know a short-termer way to do it, requiring a lot less work than
what I see on your roadmap. Also I see bumps in the road of your
roadmap which aren't easy and short-term to solve - or somebody else
would have done it already.

> 2) I will ONLY be able to work on it if I get enough funding, so
>please contribute if you can, and in any case please spread the word
>as much as possible!

Other projects are a lot further ahead than yours, so I don't think
there is such a necessity in doing what you would like to do. I'll
elaborate on the road bumps so you don't feel like I'm making this up.

http://per-cloud.com/doku.php?id=roadmap

write down a complete, CLEAR definition of the system, including:
which functions it can/must realistically provide (email + blog +
online storage and bookmarking, social networking )

E-Mail: use Pond, RetroShare or Briar over Tor

Blog: use Tahoe-LAFS, Freenet, RetroShare channels,
  Tor Hosting, I2P or whatever P2P tech I forgot

Storage: use Tahoe, Freenet, I2P or some ownCloud-app
  over Tor. Maybe a private RetroShare channel works, too.
  Best if you write a dedicated plug-in for the job.

Social Bookmarking: depends on Social Networking

Social Networking: This one is currently not solved for
  the reasons I detailed in http://secushare.org/pubsub
  but the opportunistic broadcast features of apps like
  RetroShare allow you to do some little things without
  resorting to Faceboogle.

which existing Free Software components should be used
(e.g Postfix+IMAP+Mailpile for email, apache or nginx +
PHP for Web frontends, Semantic Scuttle for bookmarking,
pump.io for social networking) ) 

E-Mail is broken, there is no way you can make it privacy-
compatible. We had a discussion on >10 reasons not to use
it in this list. Web frontends: All apps that need them
already have them, no? Semantic Scuttle sounds like something
that could make up a fine RetroShare plugin so it actually
respects privacy. pump.io doesn't have an elaborate distribution
strategy, so it only works as long as you don't follow any VIP
or become a VIP yourself - so don't expect it to perform better
than.. uh.. RetroShare. Of course pump.io would have to run behind
Tor for minimum privacy.

how to integrate those components, that is how to package
them and distribute it

That would be useful work. But first you have to get to know
all the software that can actually do the job.

 how to implement federation/social networking, with pump.io
 or similar open standards, to make things like these possible:

Federation is evil, see http://my.pages.de/dsn-vn/ - unless you do
it with home devices over Tor hidden services, cutting out the DNS
and X.509 dependencies in the process. Open standards for things
that do not work yet are evil, too. There are no open standards
that handle THE threat model and scalability challenge we are
talking about. Get over it.

Joe's percloud user panel shows when Mary mentions Johns in
her user panel, which is running autonomously on another server

That is the distribution problem I was alluding at... here and in
the pubsub document. This will only work for small social groups
with no VIPs involved. Any opportunistic distribution scheme will
in that scenario be okay, so you can also use RetroShare or Briar.

describe how to maintain the software bundle when updates or
bug fixes are released for any of its components

Deterministic build procedure and multiply signed distribution. 
Debian folks are working on this. You can also use one of the
tools for its own distribution, like RetroShare with its binary
build channels. Users can choose which channel to use and thus
which author to trust. Not good enough, but better than HTTP(S)
download.

Yes you are right that this work needs to be done. If you are
willing to give up on DNS/X.509 based systems and ready to make
one that at worst depends on a DHT (like Tor), then I suggest
openITP should give you some money to stir up an almost-do-all
package. IMHO right now the best bet at getting something up and
running really quick would be to make a RetroShare + Tor package.
In that case you would turn off RS's DHT and only use Tor's,
thus cuttin

[liberationtech] the 14th reason not to start using PGP is out!

[carlo von lynX]

I know you've all been waiting for some more criticism about PGP. Well,
since I've been forced into using it I bumped into a major security failure:

   These days mail tools are too complicated. Here come enigmail
   that is in charge of encrypting mails before they leave Thunderbird.
   But wait, didn't Thunderbird just store a draft? Yes, and since I
   happen to have IMAP configured it stored the draft to my server. Did it
   bother that I had checked the flag that I intend to encrypt the mail?
   No, the draft is on the server in the clear. I look around and find out
   that [64]Claws has been having the same bug. I'm not surprised, after
   all it's the most natural way of doing things. One person implements
   IMAP, another implements PGP support, and they never bump into each
   other and realise that the default behaviour of a mail agent that
   supports both is to do what it should in no way ever do: send the
   unencrypted mail to the server. This makes the entire effort to use PGP
   useless. I looked around for warnings, but even the [65]best manuals
   for [66]doing PGP correctly are aware of a lot of problems, but not
   this one. I am only on day three of really using PGP, and I already
   discovered a security flaw that no-one has talked about much ever
   before. Is this normal? I have Thunderbird 17.0.8 and you?
   I recommend you to turn off saving mail drafts to the server.

  64. http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2661
  65. http://we.riseup.net/riseuplabs+paow/openpgp-best-practices
  66. http://www.apache.org/dev/openpgp.html

I also recently had noticed that keyserver lookups are in cleartext by
default, which is utter madness, but that at least is being fixed and
there is good info on how to do so in [65]. Still, I wasn't expecting
that behaviour and thus exposed one of my social contacts when I did
this. If enigmail properly respected proxy settings, then the request
would have gone through Tor, but it just ignored them and went out to
fetch my contact's public key over my regular public IP. If I wasn't
monitoring my unfiltered traffic, I wouldn't even have found out.
And you call this software solid and properly peer reviewed? Srsly?

While I'm at it, let me respond to some comments that I didn't reply to
at the last round:


On Tue, Oct 15, 2013 at 04:26:34PM -0400, Ali-Reza Anghaie wrote:
> > The current policy of recommending PGP over more advanced tools is
> > probably causing damage to our end-users.
> 
> The current policy of recommending tools that don't readily replace
> PGP ~in the way end-users user it today~ is causing more damage IMO.

Excuse me, Pond has some oddly aligned buttons but the service it offers
is way more advanced than SMTP. If you really think you don't want to
trust a new cryptographic tool - and don't have the money to finance a
review - then embed PGP encrypted messages into it. Still, the number
of failures you cannot possibly experience with Pond is so high that
it is a much safer tool than the above mentioned Enigmail.

Funny.. IMAP works so well, I can even see my unencrypted draft on a
different mail agent on a different computer...  :-D

And Pond is just an example. I could as well mention PGP over RetroShare
(although it already does PGP itself) with or without Tor wrapper.
Or what about Susimail and Liberte Cables? So many alternatives to SMTP!

> That's what I mean - ~you~ aren't pointing people at Snake Oil. You're
> just delivering a message of impending doom without giving them a
> flyer on where to go next that also fits where they ~can~ go
> (supported, COTS, or whatever).

Here's a flyer.. at http://secushare.org/comparison I've been making a
comparison of the tools that are being developed. The number of problems
with e-mail are so big that I believe even not fully reviewed software is
a lesser damage - but as always you are welcome to go bullet proof by
combining the new technologies with older proven ones.

> In essence I'm saying it's dangerous to make such proclamations -
> however valid in ~our~ community - to the wide-open spaces of the
> Internet when "we" also aren't ready at-hand to provide solutions.

The document gave/gives indications on how to interpret it, including
the opening phrase that said that PGP is better than nothing.

> >> 3) It groups multiple problem sets into the responsibilty domain of
> >> PGP - when it/they don't have to be, perhaps even undesirable to be so
> >> (from both technical and sociological viewpoints).
> >
> > It's like saying if the mirror in your car is broken it has
> > nothing to do with driving, because the mirror isn't doing the
> > driving.
> 
> No it's not - it's saying the car isn't responsible for the red light
> camera. It's important to break these things out in domains for which
> they (in this case PGP) was designed.

If you want me to say PGP isn't so bad. Okay, here I say it: PGP isn't
so bad. It's actually rather cool. Only few problems like non-

Re: [liberationtech] the 14th reason not to start using PGP is out!

[carlo von lynX]

On Thu, Nov 21, 2013 at 12:27:03PM -0800, Micah Lee wrote:
> On 11/20/2013 07:30 PM, carlo von lynX wrote:
> >These days mail tools are too complicated. Here come enigmail
> >that is in charge of encrypting mails before they leave Thunderbird.
> >But wait, didn't Thunderbird just store a draft? Yes, and since I
> >happen to have IMAP configured it stored the draft to my server. Did it
> >bother that I had checked the flag that I intend to encrypt the mail?
> >No, the draft is on the server in the clear.
> 
> I haven't  been following this thread, but I just wanted to point out
> that this isn't true. Enigmail encrypts drafts before saving the
> messages to the server over IMAP.
> 
> You just need to make sure you toggle encryption to be on before the
> draft of the email gets auto-saved. Try it. Go start writing a new
> email, toggle encryption, and save a draft. Then go look in your draft
> folder and press Ctrl-U to view the source. The draft is PGP-encrypted.

I hope it does in newer versions. My version doesn't. Even now that I
have "encrypt & sign" as the default setting and pick a mail address
that I have sent encrypted mail a few minutes ago.. I start editing
the mail text, click the "Save" button and it pushes an unencrypted
copy by IMAP to my server. I logged into the server and went into its
.maildir/.Drafts/cur where it sits, happily unencrypted.

> Enigmail's about:config pref for saving encrypted drafts is
> extensions.enigmail.saveEncrypted.

Have no idea how to open about:config in Thunderbird. I see at
https://www.enigmail.net/documentation/userprefs.php that the
setting can only be accessed by Javascript and that it should
by default be "on." I presume the default has been changed
recently. This is good, better late then never, but I wonder how
many people for how many years have been saving their PGP
correspondence on their Gmail or other IMAP server including
citation of the incoming mail? How many people maybe still have
their extensions.enigmail.saveEncrypted configured to FALSE
because they started using enigmail before enigmail fixed the
setting? How many people are sending PGP mail day in and day
out and have no clue that they've been sharing their secrets
with their mail ISP for years? How many have enigmail just like
me? And I just used whatever I have.. it's not like I go hunting
for broken PGP implementations in my spare time.

Excuse me if I will laugh at anyone who dares to say it is
dangerous to use new software because it isn't guaranteed
to be safe. Can't easily be worse than PGP. The foundations
of our security are on shaky grounds all over and this
conservative attitude just reminds me of politics.


On 11/21/2013 05:23 AM, Ali-Reza Anghaie wrote:
> As it pertains to your response to me from over a month ago (below) -
> we're just on different pages. I'm not arguing the strategic problem
> statement, I'm saying you've made a tactical decision that was
> damaging. *shrug*

History will tell who is damaging the most, those who promote new
solutions or those who, just like politicians, try to cling to a
broken status quo.

> Matters little now - so many new entrants into the ecosystem we're
> already fighting the good fight against the bad fighters. Good luck,
> Cheers, -Ali

Fight? I didn't come to fight. I try to reduce the damage being done.


On 11/21/2013 01:13 PM, Julian Oliver wrote:
> Indeed, but there's a wide gulf between asserting that people should not use 
> (or
> start to use) PGP at all until a better solution is available - as he does - 
> and
> developing (and testing) alternatives in parallel. After all, any alternative
> might prove to be more or equally as vulnerable as PGP.

There are two strawmen here. I am saying (a) PGP is better than nothing
and (b) Pond and other better solutions ARE ALREADY AVAILABLE. And
considering how badly PGP/SMTP/IMAP are vulnerable, it isn't so easy
to make a software which is worse. Of course you can fumble around
with the random number generator or try to otherwise "optimise" the
crypto. But if you are aware of what you do, you be careful not to
mess up the crypto.

I am using Pond and other alternate mail systems each day. They work.
I didn't get all nervous because I forgot to flag "sign" or "encrypt"
before I hit the SEND button. It's funny: Thunderbird would rather get
back to me because I forgot to fill out the subject (which for PGP mail
should actually be abolished) then to ensure that I didn't mean to send
this encrypted. As if encryption is something you do on rainy days.


On 11/21/2013 09:31 AM, elijah wrote:
> I don't need to beat a dead horse, but nearly every email from carlo

You should neither bea

Re: [liberationtech] the 14th reason not to start using PGP is out!

[carlo von lynX]

On Fri, Nov 22, 2013 at 09:03:14PM +, Tempest wrote:
> no. i was pointing out that you expect the tech to provide a function
> for which it was never intended. if you want anonymity, encrypt your
> hard drive and install one of the many flavors of operating systems that
> are powered by tor. then, create your pgp keys after that and host it on
> a .onion.

Hmmm.. if you're anonymous, then you don't have friends to email with...
so what do you need a mail address for? And if you hand out your brand
new torified email address to your friends, you are no longer *really*
anonymous since your social graph reveals to a certain extent who you
are. After all, your friends will be too lazy to follow your lead into
torland if they don't have to.

> > No, all they need is to start using a software that does all of that
> > BY DEFAULT and there is no way to do it wrong BY DESIGN.
> 
> lol! and what is such a tool? you seem to think pond is the current

Pond, Cables, Bitmessage, Susimail, Briar, I2PBote.. even RetroShare
does that part right.

> answer. tell us what pond servers are reachable by anyone using the
> standard old e-mail system. you ignore that obvious problem that users
> are going to have with somehting like pond. since you've ignored it
> multiple times now, you can create anonymous e-mail accounts over tor.

Yes, it's about time I respond to this fallacy, but I first had to
understand why you would want to do that.

> you can encrypt those e-mails with pgp. it's a good secure design which
> still allows people who don't use pond to be able to reach you.

So you think that hiding your own traces, but leaving all the rest of
the social graph out there in the open is a good idea. Well, maybe it's
better than nothing, but the more you practice this, the more I guess
that even automated software can figure out what your former e-mail
address was, thus who you are.

> additionally, perhaps you missed this from the pond developer?

I am very thankful that Pond forces people to switch to a sane new
mail system. If you want to talk to me, you have to install it - this
is good for all participants, while requiring people to install PGP is
totally insufficient to fulfill your civic duty to not be a predictable
populace.

> "So Pond is not email. [...] Dear God, please don't use Pond for
> anything real yet. I've hammered out nearly 20K lines of code that have
> never been reviewed. Unless you're looking to experiment you should go
> use something that actually works."

If you read the 14 reasons they conclude that we have to review all the
alternative options to e-mail ASAP since insisting on PGP is causing
more harm than using new software. The IMAP failure is just an example
on how software developers can be overburdened with responsibility for
the far too complex architecture that e-mail/PGP has become. And the
idea that my grandpa would be responsible if his Thunderbird comes
configured with IMAP on Gmail is surreal. UX experts to the rescue!

> > This is all too complicated for people to even grasp let alone follow
> > and I bet half of the points in the 14 reasons still apply also to this 
> > set-up.
> > I leave it as an exercise to an interested reader to check.
> 
> no, it really isn't. you use tor for your network connectivity and you
> use gnupg for e-mail encryption.

Now that I understand how serious this is to you, I will answer fully.
Let's check with http://secushare.org/PGP ... still applicable in any case:

1. Downgrade Attack: The risk of using it wrong.
8. PGP conflates non-repudiation and authentication.
10. Workflow: Group messaging with PGP is impractical.

Applicable unless you only talk to people who themselves
use the same mail server on the Tor network:

2. The OpenPGP Format: You might aswell run around the city naked.
3. Transaction Data: Mallory knows who you are talking to.
6. Federation: Get off the inter-server super-highway
7. Discovery: A Web of Trust you can't trust.
9. Statistical Analysis: Guessing on the size of messages.
12. Overhead: DNS and X.509 require so much work.
14. The Bootstrap Fallacy: But my friends already have e-mail!

Points solved, if you can trust the mail server:

4. No Forward Secrecy: It makes sense to collect it all.
5. Cryptogeddon: Time to upgrade cryptography itself?
11. Complexity: Storing a draft in clear text on the server
13. TL;DR: I don't care. I've got nothing to hide.

The question remains... how can you trust a mail server
not to store all of your PGP or pass it on to Mallory?

Points solved in any case:

None.

In practice I don't find that a score worth making festivities about.
Pond currently only fails me on point 10.

> > That's why neither Pond nor Susimail nor RetroShare nor TorChat nor 
> > Bitmessage
> > store any clear text data on any servers! (How many more tools do I have to 
> > list
> > to make you see that there is plenty of ferment in the scene of future
> > com

Re: [liberationtech] the 14th reason not to start using PGP is out!

[carlo von lynX]

On 11/24/2013 12:38 PM, Tempest wrote:
>carlo von lynX:
>>Hmmm.. if you're anonymous, then you don't have friends to email with...
>that is an incredible logical fallacy. myself and many others
>communicate with each other without having the sligtest amoont of
>knowledge as to who each other actually are.

Ok, Mr Tempest. Now that I understand your point of view better I see
that it is a very unusual use case you have there. You are not my target
audience. For your use case PGP may just be superfine. I am talking about
the people that are currently exposing all of their social and private
life over Facebook, SMS and E-Mail. These folks should be able to speak
to their real life friends without being graphed and mapped. Btw, you
bypassed all of my criticism for your proposed solution, so there isn't
very much left to say.


On Sun, Nov 24, 2013 at 02:41:18PM -0500, Jonathan Wilkes wrote:
> >>Pond, Cables, Bitmessage, Susimail, Briar, I2PBote.. even RetroShare
> >>does that part right.
> 
> But what about Cables?  Would those Silk Road users you reference
> have been more or less safe if they had used Cables instead of
> GPG-with-Tor?

We are still talking about a scenario that is not my main focus, but..
yes. They would be safer. In detail:

- Whoever has been talking over silkroad in the clear is subject to
  investigation immediately.
- Whoever has been using PGP with the same id as in regular e-mail
  (and OpenPGP leaked it, check Fabio's thread next to this one)
  might be getting visitors at home.
- Whoever else has been using PGP is postponed for later analysis,
  either should in some other way the suitable private keys surface,
  or because someday all of that will be decrypted.
- At that point it depends on whatever is in there, if it is still
  going to get people to jail.
- Depends also on the state of democracy and justice, if limitation
  period and due process are still state of the art.
- Should those people have exchanged PGP only to then bootstrap a
  communication over safer means, then they would indeed be safer.

So the question is, what IS safer?

Arguably something that uses DJB's elleptic curves, in any case
something that does forward secrecy, but since even that will one
day be decryptable, what really counts is how the communication
is lost in much larger amounts of cover traffic and transmission
obfuscation. A tool like Pond makes it hard for an attacker to
figure out what he should try to decrypt - should he one day have
the processing power to try. That is why it is much safer than PGP
on some .onion website, where the valuable content is just waiting
to be processed. Still, if you don't trust tools like Pond, you can
always embed PGP into them - that makes them double bullet proof.

I'm describing Pond because I think I understood its architecture
the best, but the other tools might be just as good. Pointing out
how the new code hasn't been reviewed yet only re-enforces the need
to do so.

But, I repeat, it is not my interest to keep people out of jail.
I am interested in the respect for the constitution to avoid us
experiencing a further degradation of the quality of democracy.
So when you use PGP instead of something more advanced, it is
not about you. It is about us all.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Secure Email Survey

[carlo von lynX]

First of all thank you for picking up this important topic -
it's the kind of outcome out of the PGP criticism I had hoped
for. Congratulations on the insight and depth of the questions
in the form - looks like a better and more comprehensive survey
than my tentative comparison page.  :-)

The reason I am writing is because I sense that looking at the
e-mail use case by itself can favor suboptimal solutions. The
discussions of the last few days have gotten me thinking of
three imperfections in the design of Pond.

No doubt Pond is a much much more advanced solution than PGP
over e-mail, but still it has a centralized approach to
shared secret rendez-vous which I hope can in future be
resolved nicer with a privacy preserving DHT such as GNS
(there's also the possibility to exchange keys in armor,
 if you already have a secure channel via OTR or PGP)

And the other aspect is that each and every message goes to
a Pond server. There is no optimization when two people are
online at the same time and could actually have a real-time
conversation. In a way that is intentional: An asynchronous
Pond dialogue is much harder to trace. On the other hand
those Pond servers, although they have no idea what they are
hosting and for whom, have long term hidden service addresses
and could become subject to traffic analysis over an extended
period of time. Still nothing worth being concerned about -
Pond has the most advanced privacy strategy I've seen - yet
when two people are having a real-time exchange anyway, Pond
should be able to make use of such an existing channel, skip
the server involvement and deliver the message directly to
the counterpart. That implies a tighter integration with
other communication tools.

The third aspect is group communication. Pond provides none,
which is even less than PGP/SMTP.

To cut a long story short: Asynchronous messaging would find
a more advanced solution if looked at in a broader perspective
of synchronous data exchange, multiparty data exchange and in
particular scalable multiparty data exchange: None of the new
and shiny obfuscated messaging systems would be able to timely
serve a news announcements to thousands of recipients. Let
alone the numbers Twitter and Facebook deal with.

You may think - but if several thousands are going to receive
that message, why does it have to travel over a secure email
system? Because the fact that you are registered to receive
this message is politically relevant.

That's why when looking at alternatives for asynchronous
messaging I think one should also keep an eye on the
synchronous messaging and chat, at the social networking
functionality and at the distribution scalability strategy
of the entire architecture.

Things like Pond are a great solution for today, to have at
least a bunch of relevant use cases outside the reach of the
man in the middle. But if anyone was thinking we could reach
out for something like a future secure mail standard, for
that I am writing this note of warning. We need a much more
advanced and complex solution to become the next messaging
standard for the world. Something none of the existing apps
are even close to providing.


On Mon, Nov 25, 2013 at 03:01:57PM +, Dan Meredith wrote:
> All these projects are working on email or email-like communication that
> departs from traditional encrypted OpenPGP or S/MIME email in one way or
> another. Although this survey only applies to asynchronous messages
> (i.e. not synchronous chat), there is a great deal of diversity among
> the approaches. Some projects are open source, some are not. Some

We cannot recommend and should not finance anything that we
don't have the source codes for.

> projects provide services, some provide only software. There are
> centralized, federated, and peer-to-peer approaches. There are HTML5
> apps, desktop apps, mobile apps, and extensions. You get the idea.
> 
> Please let us know if we are missing any projects.

I would add liberte' cables (http://dee.su/cables) and the I2P
messaging methods (Susimail, I2Pbote I believe).

> Is the project email or email-like (or both)? In other words, does it use 
> SMTP?
>  - It uses SMTP.

There was a time when e-mail was not SMTP and there is no
reason why those two terms need to converge. SMTP is the
part of the e-mail architecture that needs replacement the most,
whereas RFC822, POP/IMAP and PGP may still have a role in
a future e-mail system (although I have criticism for each of
these building blocks).

> Do you also provide service using your software? (For example, do you provide 
> email accounts for users? This question does not apply, obviously, for p2p 
> projects).
>  - No

Hm, federation is so commonly expected to be the normality that
any distributed system is filed under "p2p" even if, like Tor, it
runs on thousands of servers, thus rather distant from what "p2p"
was supposed to mean. Tor started as P2P, but I think it isn't
anymore. I2P is heading in the same direction and I expect th

Re: [liberationtech] [cryptography] [Cryptography] Email is unsecurable

[carlo von lynX]

On Mon, Nov 25, 2013 at 11:38:59PM +0100, Fabio Pietrosanti (naif) wrote:
> SMTP is a transport protocol, with some basic signaling capability.
> 
> I don't see a single concrete, practical reason why it should
> "substituted" and not just improved here and there.

Oh no, not again. Does this have to come up every n mails?
naif, ti prego...

It's a transport protocol that expects to have cleartext
senders and recipients, that expects to connect to a DNS
hostname and to, optionally, take a X.509 certificate in
consideration for a bit of link-level encryption.

In the list of 14 reasons on http://secushare.org/PGP it
is responsible for:

- 1. Downgrade Attack: The risk of using it wrong.
- 3. Transaction Data: Mallory knows who you are talking to.
- 6. Federation: Get off the inter-server super-highway.

and in the heads of people also for:

- 14. The Bootstrap Fallacy: But my friends already have e-mail!

Additionally, since with SMTP the construction of realtime
circuits between senders and receivers is at least cumbersome,
technologies that would have an advantage out of that are
unnecesserily impeded. See my last email on how a direct link
should be considered also for mail-like applications.. to
avoid power concentrations in servers, to allow for IM and
easy negotiation of shared secrets and forward secrecy. To
allow an easy and organic functionality extention in the field
of file exchange (which e-mail currently provides, but pretty
badly) and telephony (which is considered sooo different).

Why does that zombie called "Simple Mail Transfer Protocol" have
to be kept alive long after "Simple" is actually sufficient?

-- 
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] Talks and exchange at 30c3

[carlo von lynX]

First of all I want to reach back to summar and thank openITP
for the Circumvention Tech Summit event in Berlin. For me it
created a whole new social network ;) and a specific different
perspective on the technology we are developing.

In particular the session that created a table of projects in
the field of cryptographic routing has led me to make a larger
follow-up graphic, organizing projects according to the layer
at which they are operating in a "new Internet stack" thinking:

http://youbroketheinternet.org/map

The intention is to make some things clear:

- There are plenty of projects contending for similar pieces of
  the cake, they could achieve a lot more if they were sharing
  code and learning from each other in their choices.

- On the other hand there are holes in the architecture, things
  that haven't been considered by many.

In particular there is this cultural split between people who
have been working at crypto routing and those who figure out
scalability issues. Two cultures that hardly know each other,
yet if we want to hit the jackpot, which to me means to develop
and establish a tool in the world's computing devices that
replaces the role Facebook has, must absolutely work together
on a solution.

On the routing side we have well-known names such I2P, GNUnet,
freenet and the mighty god of thunder, Tor. But who has heard
as much of blackadder, CCNx and Zyre? Luckily you have at least 
heard of Tribler, BitTorrent and secushare.

So the #scalability session is likely to become the most
interesting of the #youbroketheinternet sessions at 30c3 this
December 27th through 30th in Hamburg. Have a look at the
schedule so far:

https://events.ccc.de/congress/2013/wiki/Assembly:Youbroketheinternet

Another hot debate is likely to be the address resolution shoot
out. We'll have DNSSEC facing criticism from GNS, CurveDNS and
Namecoin.

And we will also discuss actually ready-to-use applications, like
Pond - the e-mail replacement over Tor. Show how ridiculously easy
it is to use compared to the PGP/SMTP stack. Not to mention the
gains in privacy.

Will you happen to be at the 30c3? Do you have something to show
which isn't outside the charter of #youbroketheinternet ? The
purpose of YBTI is to get projects to share knowledge and to work
together on a GNU Internet stack.

Projects fit #youbroketheinternet if:

- They are not investing in technologies that depend on DNS or X.509
  (or, to put it differently, that use the cryptographic identity
   for resolution, authentication and routing rather than trying
   to fight the lost battle of securing key discovery)

- They are not trying to fix SMTP or make XMPP scale
  (or, in other words, that aren't dependent on deploying servers
   that maintain private data in the clear)

- They don't mind Affero GPL being a political requirement
  (at the foundations of privacy we cannot afford companies to
   participate with proprietary versions or add-ons that will
   break such privacy. but they are welcome to do business over
   our upcoming infrastructure)

If your project does not fit, but you want to have religious wars
on why our selection choices may be wrong, please drop by. I am
sure we'll have some time also for that.

(That's why all the federation technologies are up in the interface
 and usability zone: we expect that if they want to be relevant in
 future they'll have to rethink everything below the HTML layer)

-- 
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] Swedish press question: How does surveillance change the citizen's behavior?

[carlo von lynX]

On Wed, Dec 11, 2013 at 01:54:31PM +0100, Anders Thoresson wrote:
> I'm thankful for any pointers.

You get dozens of interesting links like
http://pun.sagepub.com/content/3/3/381.abstract
if you startpage for "surveillance GDR" for example.

Let me cite some lines from
http://thevieweast.wordpress.com/2011/07/17/living-with-the-enemy-informing-the-stasi/

"There were a variety of things that could bring a person to the attention 
of the Stasi. Once the Stasi had targeted a suspect the goal was often to 
engender self-doubt in that person, to prevent them from living any semblance 
of a normal life, and if indeed they were guilty of some form of 'subversion,'  
to encourage them to further implicate and discredit themselves" [...] "the 
Stasi undermined their targets' self-confidence and peace of mind, rather than 
physically beating them. Although physical coercion was employed by the Stasi, 
the evidence indicates that they often preferred to utilise more 'subtle' (but 
equally effective) means of psychological torture. Isolation, sleep 
deprivation, disorientation, humiliation, restriction of food and water and 
ominous threats against the subject and their families combined with promises 
of leniency if they 'confessed' were all commonly cited interrogation tactics. 
The Stasi was not concerned with human rights and paid no more than lip s
 ervice to the notion of a democratic legal process and legitimate trials, as 
illustrated by the head of the Stasi, Erich Mielke, who maintained a policy of: 
'Execution, if necessary without a court verdict.'

Doesn't sound so historic, does it?

"For the police state to function fully however, participation from amongst 
the populace was key. Their vital tool here was to be the Inofizelle 
Mitarbeiter (I.M). IMs were unofficial collaborators who informed on work 
colleagues, friends, and even their own spouses. Informers were a part of 
everyday life, supplying the Stasi with the banal trivialities that they deemed 
necessary to neutralise their targets. During the lifespan of the communist 
regime in East Germany it is estimated from existing archival material that 
there were up to 500,000 informers active at various times. Or more starkly one 
in 30 of the population had worked for the Stasi by the fall of the GDR."

"The people of East Germany were browbeaten by the Stasi's propagation of 
fear, its far reaching tentacles spread through society in the form of 
informers hidden in plain sight. Any person deemed of particular interest had a 
Stasi file which would contain an almost minute-by-minute account of the 
suspect's life, from which the Stasi could create any motive for action they 
deemed necessary"

So let's look at the differences between Stasi and NSA:

- If the data the NSA collects were kept on paper in folders in drawers
  it would take up roughly a continent in space. That is quite a lot
  more than the Stasi ever kept in its buildings.

- The NSA usually doesn't make use of the data. It just sits there,
  still the last phrase from the citations makes sense:
  "... from which [they] could create any motive for action they deemed 
necessary"
  Italians would say, the NSA holds any single inhabitant of Earth
  by his balls or her ovaries.

- Since the NSA isn't making many people *feel* their activity
  you cannot expect a change of behaviour similar to how the GDR
  population changed its habits over 40 years of surveillance.

In the Stasi days people would go for a walk in the woods to have
an actual private conversation, and were still risking of bumping
into a wiretapped tree. Today it takes incredible amount of self-
discipline to not speak freely in a mailing list like I am doing
just now, because I have never been "punished" for doing so. But
I am starting to get afraid that one day I will.

It makes NO SENSE to me to be asking for CURRENT surveys on how
people are changing their habits. The majority is still pretending
nothing changed, as thinking about the truth would probably get them
depressed. Changing habits currently means giving up mobile telephony
and the use of the Internet for private communications. Just talk of
trivialities and hope they won't be useful for building a case against
you anyhow. Go for a walk in the woods and leave your devices at
home.

Maybe you can make such a survey in five or ten years, but right
now people are too shocked to give reasonable feedback. That's
why I suggest you look up the history of surveillance, considering
that the road to hell is paved with good intentions, so the good
intentions of the NSA aren't helpful for anyone. Their own children
will be harmed by the work they are doing.


-- 
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] Twister: P2P Decentralized Microblogging

[carlo von lynX]

On Thu, Jan 09, 2014 at 08:50:34PM +0100, Simon Rothe wrote:
> Here is another one: Twitter based on Bitmessage: https://bitchirp.org/
> 
> > Found this via Slashdot:
> >
> > "twister is the fully decentralized P2P microblogging platform
> > leveraging from the free software implementations of Bitcoin and
> > BitTorrent protocols."
> >
> > http://twister.net.co/
> >
> > Sean

The problem with the *coin platforms is long-term scalability.

First the popularity creates an amount of traffic to be broadcast
to all nodes that home computer users can quickly no longer
participate.. after a while it becomes too expensive also for
VPS and private server contributors.. in the end each of these
platforms will be in the hands of few cloud operators that can
afford to run the show. Another factor is the ever increasing
size of the history data base. In practice, these architectures 
lead to a point which is at best distributed over several political
shoulders, yet surprisingly similar to Facebook's current set-up.

Namecoin has a chance of lasting a bit longer, because transactions
are less frequent. Still Namecoin needs a caching front-end to serve
as a DNS replacement (and DNS itself won't do). At the 30c3 session
on Naming Systems that we had within #youbroketheinternet I kind of
came to the conclusion that GNS would probably be best suited for
distributing Namecoin information while also protecting the privacy
of name look-ups.

Bitcoin has a chance of lasting a bit longer, because there is so
much money involved with it. But once it gets to being operated by
a dozen different institutions in total, it starts looking very
similar to a bank cartel. In the end Bitcoin may become a thing
controlled by a cartel of banks whose only difference to paper money
is that the governments are completely cut out of the picture.

I guess we'll also see these platforms setting up servers closer to
each other topologically year by year, since having a shorter path
the signal has to travel can convince more other nodes to adopt your
transaction.. In the end we'll have a Wall Street for each of these
*coin platforms somewhere.

I presume *coin works better for small to medium sized user groups,
but there's already git for that.

Still, these technical limitations do not mean there won't be further
gold rushes and media attention.

-- 
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] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[carlo von lynX]

Synopsis:

Hi, you may have seen the popularity rising of https://ezcrypt.it and its 
imitator https://0bin.net. These are services that let you encrypt a message 
using Javascript in your own browser, then pass on the encrypted contents for 
the service to store while you pass the decryption key your browser generated 
directly to the recipient using the # part of the URL. You MUST not 
send it to the server. Once the recipient clicks on the URL her browser will 
keep the  on the client side, get the content and the necessary 
Javascript from the server and the Javascript will then access the  in 
order to decrypt the message in the browser.

In other words, this is a pretty nifty way to use existing web technology 
to implement opportunistic end-to-end encryption.

I can tell three attack vectors that an adversary can use - two active and 
a "passive" one - to gain access to the encrypted contents of the message.

1. Active local adversary attack:

This is the more obvious one: An adversary gains access to the server and 
changes the Javascript or HTML code in such a way, that an unencrypted copy of 
the message is submitted to the server. The attacker can choose to do this only 
for specific targets in order to avoid getting caught. See 
http://secushare.org/end2end for more on these kind of attacks.

2. Local man in the middle attack:

Similarly to attack 1, if the attacker cannot gain access to the server she 
can still intercept communications using false HTTPS certification and provide 
modified HTML or Javascript from there. You can protect your recipients against 
this kind of attack by having them install Certificate Patrol (see 
http://patrol.psyced.org).

3. "Passive" global adversary attack:

Although we haven't seen any evidence yet, it is reasonable to assume that 
many computing facilities offering server hosting, housing and especially 
virtual machine hosting (VPS) have been compromised using Patriot legislation 
to offer a 24/7 surveillance access to authorities. See 
http://secushare.org/2011-FSW-Scalability-Paranoia for more information on this 
kind of attack. The authority can therefore access all encrypted messages being 
stored on the server passively as they move around server memory or virtual 
hard disk. In other words, once this infrastructure is in place with the 
computing center, there is no way for the server administrator to observe such 
kind of surveillance.

Combined with the ability of a global adversary to evaluate the URLs as 
they are passed on through the Internet by means of e-mail or Facebook chat, 
the authority can extract the private key attached to the URL and apply it to 
the encrypted data obtained from the server in order to decrypt the message 
without showing up in the access logs of the server.

Conclusion / Recommendation:

There are safer ways to communicate privately: Pond, I2P, freenet, TorChat, 
RetroShare (see http://secushare.org/comparison). OTR and PGP not as much, but 
still better (see http://secushare.org/PGP for details). If you have the 
possibility to install such a software, do so. If you don't, try to at least 
pass the URL over a safe channel such as OTR. If that still isn't an option, 
then find a server that is very unlikely to be tapped by the authorities 
according to attack vector (3) and install the service from the available 
source codes. Remember to also protect yourself against attack vector (2) with 
certificate pinning practices.

Sorry for spoiling this apparently "easy" solution, but the Internet is 
currently more broken than that.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[carlo von lynX]

On Wed, Jan 15, 2014 at 01:34:01AM -0800, coderman wrote:
> On Tue, Jan 14, 2014 at 6:44 PM, Uncle Zzzen  wrote:
> >
> >> 3. "Passive" global adversary attack:
> >>
> > As long as the JS is what the owner claims it is (assuming it's code that
> > has been peer reviewed enough according to your standards), it doesn't
> > matter whether they confiscate the hard drive or just listen.

as coderman said, uncle zzzen, you are wrong. but for other reasons
than the three he mentions. it doesn't matter if the JS safely makes
it to both users' browsers if the adversary can access both the
encrypted message and the private key to decrypt it.

also you're living in the past if you think a server hard drive
needs to be confiscated to be examined. in the case of a VPS it's
enough to have a root shell on the physical host. in the case of
either a VPS or a dedicated server it's enough to p0wn the SMM.
see the recent spiegel publications that came out at 30c3.
backdoors against DELL server products are specifically described
in detail, but it is appropriate to presume that there are more
of the kind.

these days, server owners have no chance to know whether their
servers are under surveillance or not. the amount of effort
however can vary. if servers require targeted attacks then we
must avoid creating honeypots like 0bin that are worthwhile
to target... if.

if large scale server surveillance is already in place, then it
doesn't really matter where we try to entrust servers. it will
always fail. unfortunately it's not easy to tell how bad the
situation is. when was the last time you dumped and examined the
contents of your server's SMM?

> i hate the term "passive global adversary".  the adversary active
> across the global theater is able and active.

i find it relevant that the adversary doesn't need to become
detectable to apply this attack. not even the admin of such a
pastebin service can tell when the day strikes that it is being
surveilled.

> also, you're wrong three ways:
> 
> 1) if entropy is compromised (see history of RNG tampering) this
> assumption is actionable-ly false.  don't get me started on the
> OpenSSL/* RDRAND fiasco...

i think discussing the capability of the end-user devices to
provide reasonable cryptographic service is outside the scope
of my attack description. i presume this is fixable if anyone
has an interest in fixing it.

> 2) "JS is what the owner claims it is" is suspect in BULLRUN situation
> where private keys pilfered. (not to mention all the other subversive
> techniques applied)

yes, as i described in scenario (2)

> 3) the attack surface of the browser.  nuff said!   (or said again,
> "just listen" is only harmless if no prior active intervention has
> occurred)

it is reasonable to argue that the web browser is such a complex
monster it is impossible to secure. i presumed that to be obvious
but maybe it should be mentioned for completeness.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] 15 years later, why can't Johnny still not encrypt?

[carlo von lynX]

On Wed, Jan 15, 2014 at 06:00:14AM -0500, Pranesh Prakash wrote:
> Anders Thoresson  [2014-01-15 11:23:04 +0100]:
> > Comparing the findings made by Whittens and compare them to the software 
> > available today, not much seems to have happened. But does the conclusion 
> > still holds, that a lack of mass-adoption of email encryption is due to 
> > problematic UX 

I believe UX has no chance of fixing the usability if the
way the underpinnings work undermine any such effort. The
number one problem being that there EXISTS a way to message
unencrypted, and that the user is expected to make sure that
encryption is being used. Pond is a good example on how to
do away with that. Pond is easier to use, because it CANNOT
send unencrypted messages. Also RetroShare is easier to handle
than PGP. And both are really bad UX-wise as yet. Any UX
designer working on them half a day could improve them a lot
whereas trying to fix PGP+email is a lost game.

We discussed this topic in a usability session at the 30c3.
Videos will appear on youbroketheinternet.org in the coming
weeks and I'll keep libtech posted.

> There was a thread on LibTech titled "10 reasons not to start using PGP"[2] 
> that you might be interested in.

Thanks for the referral, Pranesh.  :)

Since the current reason count is at 15, you may want to
read the updated version at http://secushare.org/PGP


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] 15 years later, why can't Johnny still not encrypt?

[carlo von lynX]

On Thu, Jan 16, 2014 at 12:58:37PM +, Tempest wrote:
> > a direct, demonstration / walk through is a very different learning
> > experience compared to manuals and command lines staring back at you
> > from the abyss.
> 
> we're past that though. there is gui implementation of gpg. the "hard"
> part largely comes down to it being a new concept for novices.

no, there are several unnecessary problems that people are confronted
with specifically with pgp. you are talking as if the 15 reasons
weren't there and weren't real. we're just making things up.

> again, i'm not taking issue with the notion that installing and using
> gpg is dificult. i take issue with the reckless headline that states it
> shouldn't be used, particularly given what is stated in the op-ed. "math
> is tough so you shouldn't learn it." sounds silly, no?

you are making that claim, not me. i am saying there are better tools.
instead of insisting on a broken horse carriage, start building a car:

1. get a peer review because they deserve it
2. get better UI and UX because it *can* be done
3. get your hands dirty improving code
4. produce packages for f-droid and other OS distributions
5. use software that doesn't mess up if you click the wrong thing

you can reach me on both pond and retroshare, to name two of them.

what i am saying is that if they aren't peer reviewed enough that is
not an excuse to stick with horse carriages but a reason to start
working on it. after all it's a feasible path to take, while fixing
pgp over smtp is impossible.

remember when skype got popular? it took johnny five minutes to start
having end-to-end encrypted chat and telephony. too bad it was a
commercial product so they broke it a year or two later - but it
was the proof of concept that it can be achieved. sure, doing it
without trusting a company is more difficult, but i named several
tools that solved that problem.


-- 
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] 15 years later, why can't Johnny still not encrypt?

[carlo von lynX]

On Thu, Jan 16, 2014 at 06:25:07PM +, Tempest wrote:
> > you are making that claim, not me. i am saying there are better tools.
> 
> then change your reckless headline/title. it's that easy. otherwise,
> you're being dishonest in your trolling for attention.

no. the title is correct. there are better tools, so don't start
with PGP. that is a correct assessment and you are trolling me.

the document is aimed at multipliers as present in this mailing
list who have the competences to make those better tools usable
for the general population.

the document explicitly states that PGP is better than nothing,
but if condoms without latex are better for you (bad example you
brought up, as we should all be allergic to SMTP.. not just a few
of us) then don't start to use those based on latex.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[carlo von lynX]

On Sat, Jan 18, 2014 at 01:52:07AM +0700, Uncle Zzzen wrote:
> In that case, we shouldn't trust anything unless it's [hopefully]
> hostile-player-proof P2P, then we're back to "confiscate the hard drive"
> times.

There's one acceptable compromise left.. the one that the Tor
architecture employs... dumb relays that do useful work and
have no idea either they are doing or who they are doing it for.

> Or would they pwn all desktops as well? (I assume all phones are pwned by
> definition :) ).

My impression from 30c3 etc is that personal computers still aren't
as easily mass p0wnable as (virtual) servers and routers. Firewalls
may actually work sometimes. Operating systems may actually not be
broken sometimes. Hardware backdoors may exist but not be used in
massive way as it would compromise their effectivity.

I presume Mr Schneier is right saying that if the nation state actor
is after *your* device, then the likelihood is high it will find its
way in (especially if you use a collaborating operating system). This 
threat model only worries me if it could be applied against entire
nations in a warfare situation, which it might.

> > it is reasonable to argue that the web browser is such a complex
> > monster it is impossible to secure. i presumed that to be obvious
> > but maybe it should be mentioned for completeness.
> 
> IMHO the answer is projects like https://www.syndie.de/ that deliberately
> have a "lame html browser" as the gui, and all crypto is done outside the
> DOM.

Yes, RetroShare has HTML-compatible rich text everywhere, but no actual
web browser. We were considering something similar for secushare, too.
It's a pattern. Recover the spirit of the web and throw away the
cancerogenous parts.

> I know Syndie is not a realtime app (and chats/etc. would need some more
> functionality), but maybe it's a good idea to build "app-specific secure
> browsers" (that can't browse http[s]: urns directly) from the bottom up,
> hopefully with a saner language than javascript to control them.
> 
> Are there any "browsers" like this out there?

Yes, ever since the mid 90s.. but you probably never heard of them or
of the fact they support this feature.  ;-)


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[carlo von lynX]

On Sun, Jan 19, 2014 at 02:28:39PM +0700, Uncle Zzzen wrote:
> On 19 January 2014 08:51, carlo von lynX wrote:
> > There's one acceptable compromise left.. the one that the Tor
> > architecture employs... dumb relays that do useful work and
> > have no idea either they are doing or who they are doing it for.
> >
> As I've been hearing from I2P advocates: TOR's a road I2P is a place.

Actually with hidden services Tor's also a place while I2P is weak
in being a road...

> If a VPS is a risk, you can only trust a PC inside a residence (not
> sufficient, but mandatory).

Let's say your space at home is a better place, but it is for my
perspective of understanding a much better choice to architect
software in such a way, that no server - wherever it may be running -
is in charge of your private affairs, or - even worse - become a
pot of honey by serving unencrypted storage to dozens, hundreds,
thousands, millions of people.

> TOR has hidden services but (from what I've heard) it's less optimized in
> their architecture. What they do is take you somewhere, but there's nowhere
> to go. It's all in the cloud and the cloud is poisoned. P2P is the silver
> lining, it can live with netsplits, and as we've seen from Egypt to BART,
> netsplits are the future :(

Not all argumentation needs to be scientific, sometimes art has its
place, too. But for the sake of accuracy TorHS enable just the kind
of home servers that you were advocating - and the cloud isn't doing
a thing really, because even relay servers do not run in a cloud.
Whereas I2P is deploying relay nodes on VPS and introducing exit
nodes from what I heard, so the two technologies are converging
somewhat.

> > I presume Mr Schneier is right saying that if the nation state actor
> > is after *your* device, then the likelihood is high it will find its
> > way in (especially if you use a collaborating operating system). This
> > threat model only worries me if it could be applied against entire
> > nations in a warfare situation, which it might.
>
> I think the only winning strategy here is if nations (EU, Brasil, etc.)
> would plan develop from scratch a standard for a "snoop-free" home
> computer, where all hardware and software available on repositories.
> Can also be things like freedombox, set top box, etc.

The legislation proposal that we've put up on youbroketheinternet.org
implies that as a technical requirement for implementing constitutional
secrecy of correspondence. There shouldn't even be the need for much
of a debate considering that the current Internet is unconstitutional
and a breach of human rights. Supreme courts should establish a deadline
for upgrading the constitutionality of the Internet, otherwise it must
be shut down. Then governments would be motivated to pass the responsa-
bility of implementing this down to the industry by passing such a law.

> If you have millions of those all over your country, you level the
> playground.

Don't forget we don't have suitable software yet. All of the designs
still assume that it is reasonable to put private data on these boxes.

> If other nations take your designs and "capitalize on your intelectual
> property", even better. Each Chinese family that installs such a box,
> throws away an appliance that had backdoors by their own gov and/or other
> enemies of yours. Best is if they ban this and it becomes popular :)

Ha, you can't beat a good sense of optimism.

> > Yes, ever since the mid 90s.. but you probably never heard of them or
> > of the fact they support this feature.  ;-)
>
> > Depends on what you mean by "this feature".

Browsers allowing for other scripting languages than Javascript.
Internet Exploder is best known for this.  ;-P

> I didn't look closely, but I believe I could (and gladly would) kick uzbl
> around into - say - a syndie reader (if they had python API - that is :) ).

Is python designed to be sandboxed? Do we even want scripts
coming from remote.. anywhere remote? If not, what's the use of
having a script language for things that could be implemented
natively? Anything, which isn't native, is harder to deploy on
embedded devices.. no?

> The next level of "this feature" (if we don't want js) is to extend the 90s
> html with some standard modern set of widgets.
> For exmple: you decide that bootstrap (including all the data-* attributes
> that are later read by js) is the standard. You ignore the JS, but the
> menus would still work.
> Doesn't have to be bootstrap, but should be something that has a community
> developing themes etc.

Why not.

> Do you know about such repositories?

No.

> A higher level would be to develop a scripting language (perhaps a
> no

[liberationtech] WebRTC - The next big surveillance machine

[carlo von lynX]

> > Dunno, WebRTC is so prone to MITM.
> > I'd rather have something secure.

On Tue, Jan 21, 2014 at 09:01:49PM -0500, Lucas Dixon wrote:
> What kind of MITM attack are you thinking of? WebRTC doesn't specify a key
> authentication protocol, so not sure WebRTC is anything specific enough to

The architecture provides no way to do key authentication and then the
protocol doesn't specify any.. it's the leave-out-the-blanks strategy for
corps to fill out. Well I think I know how the leading corps such as
Google and Facebook will do it, and it will not be end-to-end secure.

> say it not secure. WebRTC is compatible with ZRTP key-authentication which
> builds in a video-based auth scheme and should stop MITM attacks (last time

You can't diffie-hellman yourself out of a MITM. If the fundamental link
is unsafe, you can make all the ephemeral keys you like - the observer can
trace them all.

> I checked). You could also use some other form of key-auth with WebRTC,
> e.g. swap key-hashes in person.

99.9% of WebRTC users will be clicking on the "call" button in Faceboogle
and not even be offered the option of having actual end-to-end secrecy.
How could that work? The web browser isn't designed for that.

So I expect WebRTC to become the next major problem for the liberation
business as it removes one more reason for people to install actual
free software - just now that free software Skype alternatives are
surfacing.

All this optimism about WebRTC will even help it being established as
something apparently better than Skype. Actually, Skype operates end-to-
end, too - unless it is being deviated. So WebRTC will deliver just the
same... unless you run your own immaculate untampered server.. but then
you are some excentric at the edge of the universe who even knows how to
set one up that employs no cheap VM, resides in your home in a reasonable
country and goes by the name of something.onion.

Hey, even if the entire liberation community was using some cool.onion
WebRTC offering, it would just be the next great honeypot and I don't
know if there are places on earth left to host big pots of honey.

And then, worst of all aspects, consider that 99.9% of folks have
downloaded their WebRTC implementation in form of a non-reproducible
binary. Some implementations' source code can't even be audited.

All in all I see plenty of opportunity for a complete surveillance of
WebRTC users. What do you see?

-- 
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] WebRTC - voice authentication to the rescue

[carlo von lynX]

On Thu, Jan 23, 2014 at 11:58:28AM -0800, Tony Arcieri wrote:
> ZRTP authentication works by negotiating what's called a "short
> authentication string" between peers. If there's no MitM, both sides will
> see the same string.
> 
> To authenticate, you start a voice/video call. You will see the person
> you're expecting, but at this point the link is insecure and may be MitMed.
> 
> However, Alice can read off the Short Authentication String to Bob. Short
> of fancy realtime video editing and voice impersonators, the string will be
> incorrect if the connection is being MitMed.

Alright, that is a nifty approach to handling the problem. Two questions
remain.. will implementations like Chrome care to show such string on the
screen and will a sufficient number of people do such a check.

> Once this has been done successfully once, ZRTP stores some "continuity
> data" so the next time you authenticate to the same person, the previous
> authentication will ensure future connections are secured.

In web architecture people usually have no identity, the identity is
defined by the server. Is ZRTP introducing a way to identify web browsers
persistently? Will the browser vendors like that? If it only happens once
both sides have ack'd that they intend to have a conversation, then I
guess it's okay to do this.

Somewhat opportunistic approach, but indeed better than Skype. Now we
just need to get people to use free and reproducible implementations
rather than binaries that can be shot at as you download them - but
that's a general problem with the current Internet.

Thanks Tony, you restored a bit of hope in WebRTC. But please ensure that
this culture of checking authentications is actually coming along with it.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] WebRTC for in-browser P2P search engines

[carlo von lynX]

On Sun, Jan 19, 2014 at 11:53:07AM -0800, Jesse Taylor wrote:
> Centralized corporate search engines such as Google are implicated in
> all three of these, i.e. they:
> 
>   * Monitor what we are searching for
>   * Censor websites by removing them from search engine indexes
>   * Shape traffic via non-transparent algorithms that can sort search
> results in a way that grants prominence to certain types of sites
> (corporate media, etc.), in order to suit the interests of
> multinational corporations and governments.

Indeed, that is no small thing.

> engines. The few existing solutions like YaCy all seem overly complex
> (and thus unusable to most users) and require downloading a standalone
> application to use. These standalone P2P search applications don't
> really make sense from a usability perspective. It's unrealistic to

Well, that depends on your platform. For users of free operating systems
it is the most natural thing to click on a software package name and
description and seconds later you have it - including cryptographic proof
of delivery. For users of smartphones it's even easier, although you have
less of a choice who you are trusting. Only retrohistoric computing
platforms such as Windoze or MacOS need you to install a free software
distribution app first. Do we even have a decent one for Windoze? Last
time I checked there were five or more and none of them did integrity
checks after downloading.

So it is rather an odd constellation that makes browser add-ons more
attractive on certain platforms, and it is hard to tell how much longer
that constellation persists.

> It seems to me that it would make more sense to use protocols like
> WebRTC  to facilitate P2P connectivity in the
> web browser, so that the searching and indexing can be done via a simple
> browser plugin that can be installed by anyone with one-click. This

WebRTC may allow for some P2P data exchange, but how do you find out
who you need to connect to in order to get information? Usually that
is achieved by means of a DHT and the web browsers don't have such a
thing. So the question is if you can integrate an add-on with a DHT
and who runs the DHT. Implementing a DHT over WebRTC sounds scary to
me (at the least) and would probably be very annoying performance-wise.
Concerning the choice of DHT I must say what I always say, have a look
at GNUnet's DHT as it has a very nifty distributed and privacy-preserving
look-up mechanism. Christian explains it in last summer's presentation
(see the video on http://youbroketheinternet.org).

> would simplify indexing (e.g. just use the bookmarks/recent sites
> visited by default, rather than forcing users manually configure it),

That would result in a strong bias towards popular things, but.. huh..
maybe you want that. OTOH if you first check the DHT whether something
has already been indexed, then you slowly crawl deeper - and you get
a popularity ranking as a side effect. You may want to talk to devs of
search engines like ixquick or DuckDuckGo (caution: PRISM prone!)

> and would allow people to just use the browser search bar as usual.

A native app can integrate into browsers just the same. It's probably
less cross-porting effort than having to port the entire add-on.

> There would still likely need to be some sort of standalone
> signaling/tracker servers set up to bootstrap search/index nodes into
> the P2P network, but most of the work -- i.e. all of the indexing,
> searching, routing, etc. -- would be done by the nodes using the browser

The way Tor and I2P are evolving suggest that an architecture based on
dumb servers hosting distributed data and computation is probably going
to be more successful. People do not expect to have their computers
slowing down just so they can search the Internet. I would therefore
opt for an app like YaCy being deployed on dumb servers with high
bandwidth and procesing power, maybe use GNUnet for the look-up and
again a lightweight end-user GNUnet node on each person's computer to
be able to take advantage of the privacy preserving look-up capabilities.
Since GNUnet intends to be integrated into web browsers anyway, it's no
big deal to also have its search engine available there. But maybe the
YaCy folks are working on something like this already.

> extension. And almost all of the complexity would be hidden from the
> average user. If P2P search could be simplified in this manner, I feel
> that the adoption would be much more rapid than if P2P search is based
> on complex standalone apps.

You just described a pretty complex and heavy browser add-on that would
make the browser even more heavyweight than it already is... I understand
that having a large Java app that does all the database, indexing and DHT
on each PC is indeed a heavy thing as well - but reimplementing the same
things in Javascript for the browser won't feel much better. The weight
is not in the way the app is served, but in what it does! Th

Re: [liberationtech] self signing certs by default

[carlo von lynX]

On Fri, Mar 14, 2014 at 04:45:01PM -0500, John Adams wrote:
> Granted, it provides a low level of encryption for clients but it does not 
> provide Non-repudiability to those users, opening them up to MitM attacks.

It is inappropriate to say "opening up to MitM" if the
alternative is plain-text HTTP which can be MitM'd by anyone anytime.

Noone has suggested that the user should be given the impression
that an opportunistic https connection is safe: Were I a browser
vendor I would not show any lock icon at all when using this mode
of https operation, yet pervasive passive surveillance is
hindered at least on the web and the attacker is forced to step
out into the open.

What we need from web browsers is:
- a way to accept self-signed certs silently
- do not show a lock, operate as if it was plain-text HTTP
- implement pinning as with Certificate Patrol add-on, so at least
  we get to enjoy TOFU

What we need from web servers is:
- generate self-signed certs for any plain-text website
  and upgrade to TLS/DHE by default

Maybe we should give these self-signed certs a standard CA name,
like using "*" as the name for the CA.

Sounds like a simple and viable band-aid all in all.
The kind of things that get discussed on the perpass list all the time.
I'm for the clean slate fixing-the-internet-for-real approach, so that's
my $.02 contribution of the day on this topic.


-- 
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] WebRTC - The next big surveillance machine

[carlo von lynX]

Summary (TL;DR):
I predict ZRTP SAS has the potential of becoming the most
widely accepted bootstrap method among people who care, if
they insist on using non self-authenticating crypto tools,
but it is not going to be good enough to hit mainstreet.
Alternatives to ZRTP SAS are presented.


On Sun, Apr 06, 2014 at 04:01:07PM -0700, elijah wrote:
> This is an old thread, but this ietf draft is apropos:
> 
> http://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-00

That's the version from last August, here's the update:
http://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-01

and IETF even has a nifty tool to see the updates:

http://www.ietf.org/rfcdiff?url1=draft-johnston-rtcweb-zrtp-00&url2=draft-johnston-rtcweb-zrtp-01

As we can see only a JSON representation has been added.

> It describes how you could use authenticate WebRTC streams using ZRTP
> implemented in javascript, even with existing browsers that use DTLS-SRTP.

That has two problems.
One concerning security, the other concerning usability.

Problem 1:

We have shown time and time again that we currently have no
secure way to bring Javascript into people's web browsers.
All methods either require a software installation or
delegating trust to the broken X.509 certification mechanism.
If ZRTP isn't provided with all web browsers as a built-in
functionality, WebRTC indeed has potential of becoming the
next big surveillance machine.

Problem 2:

I distinguish two styles of authenticating cryptographic
communications, "enabling" and "bureaucratic" ones. ZRTP
similarly to OTR and PGP are bureaucratic authentication
methods: You SHOULD be doing this procecdure to be safe,
but actually you already have a communication going, the
notion that somebody could have MITM'd you feels paranoid
and the procecdure gets annoying after a while. Majority
of people will go unsafe simply because they couldn't care
less. They just click the SAS prompt away. I notice the
problem also with OTR: half of my contacts are using it
opportunistically, risking MITM each day, even though I
wrote up a shared secret on a piece of paper last time we
met. In the case of PGP I am the pebcak myself: I catch
myself forgetting to check fingerprints after importing a
key from the server and enigmail has never tried to make
me configure the proper PGP settings. In my key store all
keys appear unauthenticated although I actually did auth
some. The fact that it is an extra bureaucratic transaction
to flag that makes it a total usability headcrash.

Enabling authentication procedures are Tor's hidden services
for example. If you don't get the fingerprint in the .onion
right you don't get a connection in the first place, so you
have a strong motivation to do that right. That's actually
the case with all public key routing technologies if the
path the public key took to get to your computer is safe.
So you may actually want to NOT put the public key into an
easy to copy-paste URL which will obviously be shared over
unsafe channels such as mail. Then again, if the channel is
a public mailing list or website, the agency would expose
itself a lot in falsifying such an obviously visible item -
so it doesn't actually happen (haven't heard of any case),
while when MITM'ing a ZRTP session people always have the
doubt something's wrong with their browser configuration
and can't easily prove the agency having attacked them.

At #youbroketheinternet we only pursue technologies that are
based on public key routing. For more than a reason. Tor is
actually the one with the flakiest implementation of it.

-- 
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] Overview of projects working on next-generation secure email

[carlo von lynX]

Hello everyone. You may remember the OpenTechFund asked
us to participate in a survey of "next-generation secure
email" projects. The result of this has materialized on
their github including an open invitation to improve it.
I found it following an announcement tweet.

Since there were many projects missing and quite some
inaccuracies concerning 1. common problems, 2. those
projects that follow a public-key routing based principle
(based on Tor, I2P etc) and 3. even the cryptography, I
forked the thing and took the initiative to work on that.

At least I think those were inaccuracies, but I may be
terribly wrong and Elijah may be dramatically right, so
I am asking you the libtech community to comment on our
debate:


This is what Elijah of LEAP and OpenTechFund says:
> Were I to accept your proposed changes, this report would grievously suffer. 
> For example, systems which use public keys as identifiers are more 
> susceptible to the problem of key synchronization, not less as you claim. 
> Also, systems which rely on both parties being online for forward secrecy 
> cannot be considered asynchronous, but the very definition of asynchronous. I 
> could go on.
> 
> You seem to have two primary issues with this report:
> 
> - You think it would be more precise to label systems that route via public 
> key as "public key routing" rather than "peer-to-peer". The difference is 
> merely semantic, because there is little motivation for public key routing if 
> you are not also building a peer-to-peer system.
> - You feel I left out the means by which people are experimenting with public 
> key discovery for systems where the key is the identifier (e.g. QR codes, 
> bluetooth, etc.). Well, I also left out any discussion of alternative key 
> discovery and validation in the overview section and left that for the 
> individual projects.

This is my reply:
> The assertions you make are not correct.
>
> 1. To achieve perfect forward secrecy only the first exchange between any two 
> partners needs to be processed. It's practical if they happen to be both 
> online on the first day they meet, but even that isn't strictly necessary. 
> Once the first exchange is settled, the ephemeral keys stay valid and can 
> even be advanced mathematically (ratchet etc). See Pond and Briar for very 
> nice examples of this principle. Your current document also contains a 
> factual inaccuracy about forward secrecy indicating you have not fully 
> understood how it works. "Without forward secrecy, an attacker might also be 
> able to capture messages today and simply wait for computers to become 
> powerful enough to crack the encryption by brute force." <- It is not correct 
> to say that forward secrecy protects from brute force, it doesn't.
>
> 2. Key sync is a problem for all. While tools like Briar, Retroshare, 
> secushare etc could use shared pubsub channels between each instance to sync 
> their "client" state and thus the keys of their social graph, using the 
> regular capabilities of their respective protocols, traditional mail tools 
> will have to come up with a special protocol, possibly on top of IMAP, that 
> allows clients to sync that sort of data. So where exactly would the more 
> susceptability be?
>
> 3. The difference between P2P and federation is only semantic, is that what 
> you say? The difference between federation and public-key routing is that 
> instead of THE server there is a vast number of relay nodes, instead of 
> letting THE server have insight about metadata SOME relays get some jobs to 
> do without really knowing what they are about, instead of making THE server 
> an ideal point to attack the communications of a certain user, there is a 
> vast number of relays that would need to be shut down in order to censor a 
> person. Have you looked at the Tor architecture anytime recently? It does 
> zero peer-to-peer because there are always relays in-between which aren't in 
> anybody's home. They are full-fledged high capacity servers in the Internet 
> backbone. You think P2P is still P2P, and I am saying P2P is dying and being 
> replaced by a non-federation of agnostic routing servers. That's why the term 
> "server" is wrong, so we call them relay nodes.
>
> 4. Experiments? Why do you have to present the old-fashioned methods related 
> to one specific tool (PGP) as the only ways to do key discovery while the 
> problem has tangible solutions that absolutely deserve being mentioned and 
> taken seriously? How dare you call other people's successes "experiments?" Do 
> they harm your world view? Would you prefer the Earth to be flat?
>
> I find it a very inacceptable abuse of your powers to simply CLOSE this pull 
> request instead of learning from its contents. I was told that you would be 
> appreciative of constructive feedback as this one, so I spent about a day and 
> a half to make YOUR document actually reflect the scientific facts. And then 
> you insist with your antiquated points of vi

Re: [liberationtech] Overview of projects working on next-generation secure email

[carlo von lynX]

On Mon, Apr 28, 2014 at 05:15:50PM +0300, Maxim Kammerer wrote:
> Are you referring to the survey from Nov 2013 [1]? Because I don't see
> anything from what I wrote wrt. Cables on that page.
> 
> [1] 
> https://mailman.stanford.edu/pipermail/liberationtech/2013-November/012255.html

Yes I was referring to that.

What you see in the document is what I wrote about Cables,
hope that's mostly correct.

The other version only has a link to your source code
and a few claims about P2P which are partially incorrect
for Cables as it isn't a P2P system.

Yet it says, "Except for Pond, all these alternatives take
a pure peer-to-peer approach." So it claims you are P2P.
Several technologies that are listed there are not P2P
in fact.

Maybe it would be more useful if OpenTechFund simply
made all those contibutions available so people who
actually understand the technologies can organize them
accordingly.


-- 
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] DuckDuckGo and PRISM

[carlo von lynX]

Talking about tools that we should not recommend, I
really don't get it why DuckDuckGo is being listed
everywhere as the number one reasonable alternative
to Google considering that they are based in the US
and subject to US legislation which enables the PRISM
program. It is just 100% naive to expect that for some
magic reason DuckDuckGo is exempted from that program.

I am sure the folks are great, just like the ones
working at Google.. and the t-shirts that were distributed
at the NYC #TA3M event are really nifty. But still, why
use a service that by law has to comply to surveillance
requirements if you can use services that are outside
US jurisdiction?

Somebody please explain.

Are we suffering from the centuries old problem that
if it is "our people" doing it, then it's okay?
That's the definition of corruption, pretty much.

-- 
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] DuckDuckGo and PRISM

[carlo von lynX]

On Tue, Apr 29, 2014 at 09:05:00AM -0400, Nathan of Guardian wrote:
> With Orweb and Orbot, we build in DDG as the default search engine.
> Since all access via Tor, it is deemed acceptable, and since they do no
> active logging, profiling, blocking of Tor, etc, DDG was chosen as our

Maybe you have a way to check that DDG doesn't do so, but they have
no way to tell you if the NSA actually does. And considering that
the NSA has always been doing everything it can, it is correct
to presume the worst by default.

> best default option. Also, their own DDG Android app/widget is
> open-source, and integrates with Orbot/Tor proxying directly.

Oh, you need an app to use search?

> > I am sure the folks are great, just like the ones
> > working at Google.. 
> Aside from being geographically located in the US, they are about as
> good as it gets for a search company. Not as just humans, but as an
> organization, and the decisions they have made WRT to privacy. As we

... are totally irrelevant considering US law that forbids them from
letting you know if the NSA has virtual memory access to all of
their servers. Probably there is just one person inside the entire
company who would know and must in no way tell anybody else.

To think that the NSA would let such a honeypot slip by is very naive.

> have seen, even if you are outside of the US, that does not make you
> safe from PRISM, or any style of legally or network-based surveillance,
> subpoena, etc.

It does make you safe from PRISM in the sense that PRISM is specific
to US jurisdiction. There may be other intelligence agencies that
may have a deal with their respective governments that allows them
to do full surveillance of ixquick.com for example. But until proven
otherwise I would rather use the search engine where bulk surveillance
is illegal rather than the one where bulk surveillance is guaranteed.

> > and the t-shirts that were distributed
> > at the NYC #TA3M event are really nifty. But still, why
> > use a service that by law has to comply to surveillance
> > requirements if you can use services that are outside
> > US jurisdiction?
> >
> > Somebody please explain.
> If there was a search engine company, service or project based outside
> of the US, that could match all the things DDG provides, I would
> definitely promote and use them. Does that exist?

Eh? ixquick provides nice results day-in day-out from my experience.
Are you willing to trade in your search query patterns for a bit of convenience?
You can make that choice for yourself, but you shouldn't for your users.

At least DDG doesn't correlate search strings to Google identification cookies,
so that is something better than nothing, but still.. why insist on services
on US soil after all we've seen? I'd rather get marshmellows from the US -
they don't have bugs in them (yet).

> I would also like to explore more decentralized, distributed search options.

YacY still adheres to the pure ideology of P2P, putting computational,
spidering and search load on each participant. There should be an
incentive for diverse people to run it in the Internet backbone and
a possibility to use a client that accesses the DHT without having
to participate in it and contribute back. Essentially, YacY should
learn from Tor.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] DuckDuckGo and PRISM

[carlo von lynX]

On Wed, Apr 30, 2014 at 12:33:52AM +0100, Bernard Tyers wrote:
> > Oh, you need an app to use search?
> Yep, it's called a web browser. Orbot is a web browser.

Exactly, so you can ship ixquick or startpage instead of DDG.
I wished there was at least one more alternative, but I haven't
seen any realistic options.

> > ... are totally irrelevant considering US law that forbids them
> > from letting you know if the NSA has virtual memory access to all
> > of their servers. Probably there is just one person inside the
> > entire company who would know and must in no way tell anybody
> > else.
> 
> It's a mixture of:
> 
> a. how hard is it for a user to search with *some reasonable
> semblence* of privacy

- google: none
- ddg: at least google makes a little less profit on you
- ixquick: there is a chance your search is actually private

> b. how trustworthy are they, or better worded "how much does the user
> *feel* they can trust them?

that is exactly the wrongest way to look at it. commerce is
all about denying the truth and making you feel good about
the damage you are doing to yourself.

> c. how easy/hard is it for government agencies to intercept/get access
> to search terms.

using DDG does not change anything about their ability to see
what you are searching for. by using DDG you merely vaguely
reduce google's ability to make business out of your data.
still google will place cookies on you whenever you surf to
a website that uses jquery or any other google api or fonts -
so the improvement isn't huge.

> To address a. with Google - it's pretty f'ing hard. People forget
> they've logged in as they use whatever service from Google. At which
> point you've lost it.
> 
> b. People hear people they trust (in other words, a lot of people on
> this list) telling them you can trust DDG.

Yes, that's the same failure that drove everyone to Google in 1997.
We just keep repeating sheep strategies.

> Their website *looks* trustworthy (worth nothing in reality, I'll
> agree), and so people will make a decision based on both of those,
> hopefully.

Hopefully? That's the foundation of the demise of humanity. The fact
that we are superficial by default. And rather trust our gut feeling
rather than collective intelligence, ignoring that gut feeling is
just a time-delayed expression of things that have been injected in
your brain when you were a child.

The last thing the world needs is people that promote this treacherous
thing called gut feeling.

> I have watched people making decisions to use a website based on
> decisions such as "well it looks like a 
> website", even though they had to go through 4-5 links which were
> served higher.

Yes, who needs experts, who needs to check out a knowledgable website
for trustworthy recommendations if you can decide by gut feeling?

> c. Most people don't take this into account as they are just trying to
> do a web search.

Yeah, they are just clicking some coloured stuff.

> Hopefully a. and b. above have been successful in reducing the
> likelihood of an issue. And as for c. this is outside the users control.

No, no and no.

> Ultimately they'll make a decision on what suits them, so lets try and
> help them be a little bit safer.

Yes, stop putting a default search engine which will expose
their interests to the NSA, even if everyone is acting in the
best intentions, the NSA included.

> > YacY still adheres to the pure ideology of P2P, putting
> > computational, spidering and search load on each participant. There
> > should be an incentive for diverse people to run it in the Internet
> > backbone and a possibility to use a client that accesses the DHT
> > without having to participate in it and contribute back.
> > Essentially, YacY should learn from Tor.
> 
> And as for Yacy.de I support any service they increases user privacy.
> When I go to their index page I get:
> 
> "Web Search by the people, for the people
> 
> YaCy is a free search engine that anyone can use to build a search
> portal for their intranet or to help search the public internet. When
> contributing to the world-wide peer network, the scale of YaCy is
> limited only by the number of users in the world and can index
> billions of web pages. It is fully decentralized, all users of the
> search engine network are equal, the network does not store user
> search requests and it is not possible for anyone to censor the
> content of the shared index. We want to achieve freedom of information
> through a free, distributed web search which is powered by the world's
> users."
> 
> If I was a non-technical user, within about 2 seconds I'd close this
> tab and go back to Google.

The projects shouldn't have to promote themselves to the end users
and the end users should understand they have not a faint chance
of figuring out what is good for them by themselves.

> They need to redesign their front page and focus on what they built it
> to do: help people search.

Maybe it would actually stick if they say "YaC

Re: [liberationtech] DuckDuckGo and PRISM

[carlo von lynX]

On Tue, Apr 29, 2014 at 04:22:04PM -0400, Nick wrote:
> Quoth carlo von lynX: 
> > At least DDG doesn't correlate search strings to Google identification 
> > cookies,
> > so that is something better than nothing, but still.. 
> 
> I think that's actually a very significant usability improvement.  
> Sure you can tell people "don't allow cookies for google, unless you 
> use any of their services, in which case don't search when you're 
> logged in, and flush all your cookies when you log out". But telling 
> them "search with ddg.gg" is rather easier, and there's actually a 
> chance they'll do it.

You have to tell people that they must stop surfing the web while
they are logged into a Goggle service. In fact to get out of the
Google machinery you would have to both pick a new Tor identity AND
clean out your cookies each time you go to a different website that
has Google includes (APIs, javascripts, fonts etc). Only then you
have a chance of stopping the correlation of your surfing activity.

Or you insert a cache proxy which is configured to never ask Google
for newer versions of the stuff.. and see if the web still works.
I tried to teach privoxy to filter out all accesses to Google domains,
but failed. But actually the web browser should be able to do this,
since it's the one running the local cache. But you can bet Mozilla
will not be able to deliver any privacy improvements as long as their
offices are paid for by Google.

> You're correct that large governmental agencies can still do 
> correlation etc themselves. But I'd still prefer have as few people 
> as possible doing that, rather than volunteer such information over 

Exactly, so start spreading the data not only into different companies
but also into different continents.

> to companies as well. And it turns a "give us your account 
> information" legal query into a "let us wiretap everything through 
> you / backdoor you" legal query. Both of which seem to be A-OK at 
> the moment, but I can imagine the present regimes ruling the latter 
> illegal sometime soon.

It is already illegal in most places on the planet, you can ask any
Supreme Court that bulk surveillance is the harshest attack on democracy
ever. But it is impossible to trace, so you won't even get to those
courts as you have no evidence, just whistleblower warnings. We need to
fix the Internet.

> Ultimately, I agree with others, search is the sort of thing where a 
> P2P, or open and distributed, system is sorely needed. Another 
> reason is the control and understanding of the algorithms that tell 
> you what's relevant to you, but that's another discussion.

Start by having liberty, security and democracy.. then let convenience follow.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Shoshanna Zuboff: Dark Google

[carlo von lynX]

Benjamin Bratton has posted a reply that hardly says anything
concrete and does not question any of the facts. Let's look at
this intelligent article again, knowing that Germany-based news
has the privilege of freedom to tell the truth when necesary
and still pay their authors for it. From a hacker's point of
view this all makes sense, while Mr Brattons blabber doesn't.
But for anyone who doesn't like to hear, Mr Bratton just
perfectly doesn't even challenge the facts provided here.
It's a classic example of a straw-man argumentation strategy.
Something very normal to do in PR and lobbyism.. or when you
honestly do not understand what the counterpart is saying.


On Thu, May 01, 2014 at 08:40:50AM -0700, Yosem Companys wrote:
> 30.04.2014
> 
> Dark Google
> 
> We witness the rise of a new absolute power. Google transfers its
> radical politics from cyberspace to reality. It will earn its money by
> knowing, manipulating, controlling the reality and cutting it into the
> tiniest pieces.

What does it mean, when a conservative mainstream media newspaper
sends such a dramatic message? You better should get started thinking
about it, if you haven't already. FAZ does not play on alarmism, it
sells newspapers for decades and doesn't need to go cheap.

> Von SHOSHANA ZUBOFF
> 
> Recall those fabled frogs happy in the magic pond. Playful.
> Distracted. The water temperature slowly rises, but the frogs don???t
> notice. By the time it reaches the boiling point, it???s too late to
> leap to safety.  We are as frogs in the digital waters, and Springer
> CEO Mathias Dopfner has just become our frog town crier.  Mr.
> Dopfner???s "Why We Fear Google" http://www.faz.net/-gsf-7oid8 (a
> response to Google Executive Chairman Eric Schmidt???s open letter, "A
> Chance for Growth" http://www.faz.net/-gsf-7o8dh) warns of danger on
> the move: "The temperatures are rising fast.???  If his cry of alarm
> scares you, that???s good. Why?
> 
> First, because there is a dawning awareness that Google is forging a
> new kingdom on the strength of a different kind of power ??
> ubiquitous, hidden, and unaccountable. If successful, the dominion of
> this kingdom will exceed anything the world has known. The water is
> close to boiling, because Google understands this statement more
> profoundly than we do.

>From a hacker's perspective, ubiquitous isn't just that everybody is
currently using Google Search, but that there hardly are any relevant
web sites out that that do not make use of any embedded Google features.
Scripts, fonts, analytics, you name it. The Internet is soaked in
Google and gladly conveys all its usage patterns to the network's
central intelligence agency. Interestingly, this aspect hasn't been
discussed much anywhere. Even political websites frequently contain
Google wiretaps. No surprise, the NSA's search engines make intense
use of the pervasive presence of Google cookies to connect the dots
between websurfing activities, even when using Tor.

> Second, because accessing the Web and the wider Internet have become
> essential for effective social participation across much of the world.
> A BBC poll conducted in 2010 found that 79% of people in 26 countries
> considered access to the Internet to be a fundamental human right. We
> rely on Google???s tools as we search, learn, connect, communicate, and
> transact. The chilling irony is that we???ve become dependent on the
> Internet to enhance our lives, but the very tools we use there
> threaten to remake society in ways that we do not understand and have
> not chosen.

By moving on from paper to electronic they gave up the fundamental
right for Secrecy of Correspondence, just there.. by mistake. In the
beginning at least it wasn't all going to a single monitoring entity.
But that is over twenty years ago.

> Something new and dangerous
> 
> If there is a single word to describe Google, it is "absolute." The
> Britannica defines absolutism as a system in which "the ruling power
> is not subject to regularized challenge or check by any other agency."
>  In ordinary affairs, absolutism is a moral attitude in which values
> and principles are regarded as unchallengeable and universal. There is
> no relativism, context-dependence, or openness to change.
> 
> Six years ago I asked Eric Schmidt what corporate innovations Google
> was putting in place to ensure that its interests were aligned with
> its end users. Would it betray their trust?  Back then his answer

Which is funny to even try, since CEOs usually only have as much
political power as they are able to drive the dividends up. All
politically correct action they can take is counter-balanced by
the damage they make by driving in revenue. So the possible
political correctness is always inferior to the needs of making
a business, which is never for free. Society always pays for it
in one way or another. It's in the architecture, so no-one is to
blame for this.

> stunned me. He and Google???s founders control the

Re: [liberationtech] Shoshanna Zuboff: Dark Google

[carlo von lynX]

I'll answer to the author as if he was reading this.
It's his problem if he doesn't.

On Thu, May 01, 2014 at 06:14:16PM +0200, hc voigt wrote:
> (1) Taking what Eric Schmidt says in Op-Ed's at face value as
> representing Google's strategy, or worse as representing Google's
> geopolitical and geoeconomic significance, power, or danger.

Does she? Or are you just claiming she does?
She just puts it in perspective and it fits.

> (2) Insisting that the author's self-pronounced confusion as to the
> history or mutability of the Internet is proof of its insidiousness,
> unaccountability and over-determination by current actors.

No.

> (3) Using a mish-mash of trigger words like 'colonize' and
> 'self-determination' without any need to link these to the presumed
> contexts, and one assumes, giving no real thought to how (quote) ???the
> whole topography of cyberspace??? does and does not resemble other kinds
> of social, political, economic or cultural geography, let alone their
> contentious histories.

You must be reading the article from your perspective which is biased.

> (4) Utter misrepresentation of the relationship between Google and the
> USA Federal Gov't, especially the NSA, including taking quotes out of
> context to ventriloquize inverted meaning (the McConnell quote here was
> about China hacking Google's servers to track dissidents, not PRISM).

Which is an absolutely legitimate context to take from. It exactly
describes the sort of collusion which is a topic of the article.

> Including patently absurd links between disparate events (such as Street
> View inadvertent capture of public wi-fi addresses = NSA hacking patrol

Inadvertent? This says all about your independence on the issue.

> because Google reported Chinese hacking to the NSA in 2010). Or how
> about this one: NSA tracked users with some insidious new secret
> technique called ???cookies,??? a weird new trick they learned in conspiracy
> with Google.

HA HA HA very funny. Like EVERYONE KNEW before Snowden how pervasive
the Google cookies operate and that it makes sense for the NSA to
attach analysis to them. No, NOBODY KNEW. Only the so-called paranoid
had a gut feeling about it.

Just because a technology such as Google API script includes is well
known doesn't mean the general public has understood the privacy
implications. Why did all airways in 2010 suddenly introduce Google
dependencies into their websites, although they had been happily
operating without them for about a decade? Am I seeing pink elephants
in the sky? Am I just paranoid? Still?

> (5) Blaming the disillusionment and disenchantment of their own earlier
> naive and shallow presumptions about some intrinsically liberating
> nature of the Internet on Google's data and advertising business model.

Which is a totally correct sentiment.

> (6) Conflating Google with all other Cloud platforms, especially
> Facebook, as one big entity with apparently deliberate ignorance of or
> disinterest in significant distinctions.

That is not of primary relevance to the article. In fact the cloud
architecture as such is the problem, but to mobilize the crowds
that isn't exactly easy thinking to promote.

> (7) Insisting that things we do know about Google and PRISM (such as
> their continuing pushback and resistance to court orders, their
> subsidized development of user tools to directly circumvent government
> surveillance, such as uproxy and google dns) are meaningless, but
> indicating the opacity of all things we don???t know about any possible
> dirty dealings is demonstrable proof of their abyssal darkness.

The good actions and good beliefs of Google employees are irrelevant
to the final result. It just shows how the deus ex machina is
further out of control than you like to admit.

> (8) Conflating user feedback and pushback regarding strange and
> disturbing new forms of data transparency with some deliberate and
> explicitly criminal mischief on Google???s part. Including
> misrepresentation of what practices were and are secret and which are
> merely unusual and controversial.

The use of a terminology such as "data transparency" demonstrates
your clear lobbyist interests. There can be no socially acceptable
such thing beyond "open data" of Governments and companies.

> (9) Demanding that the author???s confusion about the ambiguous social

Your insisting use of the word "confusion" which the article only
mentions as a description of the agressor's tactics, while you are
trying to convey the idea of the author being confused.. that alone
is a naked exposition of your special interests on the matter.

> logics of secrecy and privacy in a network society is proof of an
> innocence not merely disenchanted but one deliberately stolen by bad
> actors. Demanding that the author???s inability to articulate a coherent a
> political description of Cloud-based social systems is demonstrable
> proof, not just of a general confusion, but once again of Google???s
> willful viole

[liberationtech] Hardened servers, new hope for federation?

[carlo von lynX]

Somebody sent me this link.. http://privatecore.com/vcage/
but you don't need to follow the link as I summarize:

vCage is a proprietary Linux-based technology that uses
proprietary Intel hardware features to ensure that only
the owning company can remotely access a cloud server..
any person from a local computing center in whichever
country, armed with screwdriver and bus access tools
doesn't get to see much of anything.

In fact the RAM encryption is pretty stunning technique,
and some other aspects of the thing as well. So this is
great news for any American cloud computing company.

For us instead this technology only reduces the trust
from dozens of computing centers and companies to just
three of them: Intel, privatecore and the web site itself.

When we input our social communications we are expected
to trust these three, and our plain text data to flow
over the Internet in near perfect safety.

Edward has taught us, that everything that is feasible
must be presumed to be being done, thus we should expect
backdoors in Intel's CPUs large enough to allow access
and remote control of these cloud computing devices even
in the face of vCage, allowing an outside attacker that
knows the magic phrase to run searches in decrypted memory
and possibly file systems, all within the elegant built-in
administration website that comes with Intel's AMT.

Thus, no reason to lower the guard and welcome federation
thinking, even if privatecore chose to let us recompile
our own vCage from source. As long as private data is on
a server in the clear, it is out of reach for safety.

So far my opinion. Anything out there to challenge it?


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Google keeps the chat history even you enabled the OTR

[carlo von lynX]

On Thu, May 08, 2014 at 08:15:04AM -0500, Anthony Papillion wrote:
> The bottom line is that, bug or not, privacy conscious people need to
> simply stay away from Google. And I don't mean just Google Search or
> Chat. I mean /all/ of Google, Everything they offer.

AFAICT that's not enough. You need to make sure the cookies
are grilled because every single googleapisomething using
scripts, fonts etc from the google cdn may like to fingerprint
you as you pick the stuff up. even if you grill the cookies
your combination of browser, ip, screen resolution etc is
enough. so either you filter google domains entirely, or you
use tor combined with a cookie filter. btw, does anyone have
suitable privoxy filters? i tried to write some radical
reject-all-google-domains rules, but they don't work. not
only are all browsers p0wned by google, even privoxy is..  ;-D


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Google keeps the chat history even you enabled the OTR

[carlo von lynX]

To not pollute the list I respond to 4 interesting authors in a single mail!


On 05/09/2014 03:23 AM, Doug Schuler wrote:
> Realistically we need to develop an entire suite of publicly
> owned tools. Could the development and implementation be
> massively distributed?

http://youbroketheinternet.org and the Wau Holland Stiftung behind it
are somehow naively trying to make suitable projects interact in a way
that at least one new Internet stack comes out of it. There is a map on
the site that mentions the various projects and there are video
presentations of many of them. Once realized, the new stack would need
to get deployed to humanity, which I think is much more feasible than
people think - after all smartphones got out there, too, and, at the
beginning, the new network operates as an overlay over the old, so it
installs like an app. I2P and Orbot are already taking that step now.
I personally work on secushare which helps GNUnet out on the upper
scalability and applicability layers.

> Or is it over?   We lost all the other media

>From my perspective of potential technologies I say it is very much in
our hands. It doesn't even take enormous efforts, just a bit more
attention to the folks that are doing the job. The problem is that most
people have difficulty telling which ones are the ones doing the job
that is actually needed, and which are investing huge amounts of time in
infrastructure that won't do, faling pray to the fallacy that an upgrade
of something existing has better chances of getting deployed - history
has not confirmed that thinking. The GNU Internet will spread like some
new app and people will spend less and less time in the old one.

> "In just a few short years, starting in 1998, this company has grown to
> employ almost 50,000 people worldwide, generated sixty billion dollars
> in revenue last year, and has a current market capitalization of more
> than 350 billion dollars. Google is not only the biggest search engine
> in the world, but along with Youtube (the second biggest search engine
> in the world) it also has the largest video platform, with Chrome the
> biggest browser, with Gmail the most widely used e-mail provider, and
> with Android the biggest operating system for mobile devices." From:
>  An open letter to Eric Schmidt: Why we fear Google

As long as the Internet is itself agile, these things can change faster
than you think. Myspace and Compuserve were big too. And Napster. Not as
huge, but.. if we deploy a GNU Internet, it could come with a web
browser that treats privacy better than Google's Chrome and Firefox
offerings.. the you can use Search and Youtube more safely. At the same
time the GNU Internet could develop proper distributed search and video
distribution without involving any companies. E-Mail would be gone and
replaced since it cannot be secured properly. The challenge is to be
able to distribute essential software without getting tangled up with
special interest. Maybe the Tor model works.

Android however remains a tricky issue. You can't just fix that by
installing an app. All of hardware and operating systems is a difficult
issue really.. luckily those are not the vectors for bulk surveillance.
And if they became so, judges would be able to rule as it would no
longer be passive surveillance.


On 05/09/2014 03:31 AM, Anthony Papillion wrote:
> I fear we've already lost. I used to think that it would just take
> some sort of major scandal to wake people up to the fact that
> relinquishing their privacy wasn't such a good idea. Then, I thought,
> they'd stand up in outrage and take their privacy back with
> pitchforks. Then Snowden showed up and nothing really happened. Most
> people didn't actually change the things they do because, well, it's
> not convenient.

Actually there has been a slight cognitive advancement in the last
year.. we went from "I have nothing to hide" to "But what could I
possibly do?"

Our infrastructure is a mess, what people can do is learn to use
difficult to use protection software, that falls open when they fail to
use it right. That won't work, ever. You can make all the crypto parties
you like and write easy to learn PGP instructions at no end.

Some week ago at a YBTI presentation I asked a hacker audience how many
do OTR. Most hands went up. Then I asked how many of them have at least
one contact they do opportunistic OTR with because they don't have the
patience to share secrets or check fingerprints. Same show of hands.

"But what could I possibly do?" needs to be answered with "install this
new Internet. It works slightly different than the old, but you'll get
used to it. It is actually easier. You can forget all about addresses
and @ signs. You don't even need to be able to read and write any
longer. All you need to do is learn how to do the bluetooth handshake or
QR code scan. Or how to add a friend from somebody else's friend list
like you already do on Facebook." That software doesn't exist yet, but
from

[liberationtech] Is Google correlating people to their exit nodes every half an hour?

[carlo von lynX]

On Mon, May 12, 2014 at 03:12:06PM +0200, Fabian Keil wrote:
> Please have a look at:
> http://www.privoxy.org/user-manual/contact.html

pebcak, problem solved.

> A definition of "p0wned by google" would be great, too.

In the case of privoxy it was a joke related to my pebcak.

In the case of Chromium.. well.. you know it

In the case of Mozilla.. I just mention this habit of
checking "safebrowsing.google.com" every half an hour,
correlating a user's IP or exit node with her Google cookie.

I know that 0.0001% of the population are aware of being
spied upon by safebrowsing.google.com and capable of
turning it off.

And I know there are tons of people who think
safebrowsing.google.com is an important service that
Google could in no way make available anonymously
because.. OMG.. then it wouldn't make money with it!!

And it wouldn't make Uncle Sam satisfied.

(Yes of course "safebrowsing" could be architected
 in a way that the data is distributed anonymously
 and in respect of privacy, much like the mirror
 networks of linux distributions for example)

I presume safebrowsing.google.com isn't the only
spyware in web browsers, but one of the most efficient
ones.

Or maybe my personal observation of web browser
activity patterns are somehow misguided.
I'm just articulating what I noticed since no-one
in the community seems to have developed a critical
opinion regarding that service.

Wikipedia has no "Criticism" box about it. Neither
does https://wiki.mozilla.org/Phishing_Protection
in any way question the practice of having the 
browser periodically call "home."

I presume this could be a major scandal, but since
I'm not a major blogger it's just a little voice
on a little mailing list.

Maybe some journalist picks it up and researches
in-depth if my observations are correct?

And I wasn't considering non-free or secondary browsers.

So from this ironically desperate point of view all
browsers are p0wned.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

Thank you for a faceted browser API.

When Netscape introduced livescript in 1995, who would
have thought it would have one day be employed for
opportunistic end-to-end encryption and similar jobs.

I would kindly ask you to mention in the opening words
that such an API can only be used in an "opportunistic"
fashion as the JS code intended to use this API itself
somehow has to be delivered to the browser, which is an
as yet unsolved problem considering the failures of
certification authorities in the past.

There is a fundamental flaw in the security architecture
of the web and this new API does not address that.

Please make that clear, or you may stir false hopes and
become responsible for potential consequences. People may
be developing sensitive applications with this, not being
aware that any certification authority of any country on
earth can insert malicious code.

Best,  CvL


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

Oh, a Google employee. I know what to expect.

On Tue, May 20, 2014 at 07:39:04AM -0700, Ryan Sleevi wrote:
> > I would kindly ask you to mention in the opening words
> > that such an API can only be used in an "opportunistic"
> > fashion as the JS code intended to use this API itself
> > somehow has to be delivered to the browser, which is an
> > as yet unsolved problem considering the failures of
> > certification authorities in the past.
> 
> This is not an accurate limitation of the API, given the existence of
> SysApps (aka Extensions/Apps), which as noted in the W3C SysApps charter,
> include different security models such as signed code.

I know, but I am saying the API documentation should make that
clear. Signed code operates on X.509 or some other broken "trust
an authority" model. There exists no reasonable security model,
it is a false promise that has been delivered too long.
Time's up for promising to somehow fix the core problem later.

> This is also not a cryptographically accurate use of the term opportunistic
> encryption, though it has become quite an in vogue term.

Strawman. I didn't mention opportunistic encryption.
I used the word opportunistic for what it actually means.

> > There is a fundamental flaw in the security architecture
> > of the web and this new API does not address that.
> >
> Our charter makes this clear.

Is the charter in the introducing chapter of the specification?
Probably not. The charter is a great place to share hippie thoughts
with IETF folks, but it has no effect on the output of the WG.
It's a fig leaf.

> > Please make that clear, or you may stir false hopes and
> > become responsible for potential consequences. People may
> > be developing sensitive applications with this, not being
> > aware that any certification authority of any country on
> > earth can insert malicious code.
> 
> Luckily, this is also not true.
> 
> Certificate pinning is one such way to mitigate this threat.

Whoops wrong person. I am the author of Certificate Patrol, the
main certificate pinning implementation for Firefox. Some thousand
people and me are protected from your average government MITM attack,
but billions aren't.

And the main cause is Google. It's because Google uses certificates
inconsistently, multiple certificates for identical domains, not even
signed by the same authority. Google makes it impossible to successfully
implement a certificate pinning security scheme with a reasonable end-user
UX, and considering the interwoven interests of your government I have a
hard time believing this will change anytime soon - even if all the
employees were for it.

> Regardless, its unreasonable to suggest we are responsible for developers
> who chose to use eval on untrusted code, who choose not to use CSP, those
> who introduce XSS, and likewise, those who fail to use pinning. These are
> all complimentary tools in the developer's toolbox.

These are all symptoms of an architecture held together by band-aids,
and web crypto is inviting people to build edifices of high hopes in
security on top of a house of cards. Unless of course you are Google,
then the world is currently quite perfect.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

On Sat, May 24, 2014 at 10:31:29AM +0200, GALINDO Virginie wrote:
> Hi all,
> Could we keep here a positive and constructive mindset. Just saying...
> Virginie

liberationtech is a political mailing list. You have chosen to
advertize your politically questionable work on this list, so
you get appropriate feedback.

Criticizing your work is a very positive and constructive
contribution considering the current state of the Internet.
So please appreciate, don't let your tone sensors limit your
mental adoption rate.


> -Original Message-----
> From: carlo von lynX [mailto:l...@time.to.get.psyced.org]
> Sent: samedi 24 mai 2014 09:31
> To: Ryan Sleevi
> Cc: public-webcrypto-comme...@w3.org; liberationtech
> Subject: Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*
> 
> Oh, a Google employee. I know what to expect.
> 
> On Tue, May 20, 2014 at 07:39:04AM -0700, Ryan Sleevi wrote:
> > > I would kindly ask you to mention in the opening words that such an
> > > API can only be used in an "opportunistic"
> > > fashion as the JS code intended to use this API itself somehow has
> > > to be delivered to the browser, which is an as yet unsolved problem
> > > considering the failures of certification authorities in the past.
> >
> > This is not an accurate limitation of the API, given the existence of
> > SysApps (aka Extensions/Apps), which as noted in the W3C SysApps
> > charter, include different security models such as signed code.
> 
> I know, but I am saying the API documentation should make that clear. Signed 
> code operates on X.509 or some other broken "trust an authority" model. There 
> exists no reasonable security model, it is a false promise that has been 
> delivered too long.
> Time's up for promising to somehow fix the core problem later.
> 
> > This is also not a cryptographically accurate use of the term
> > opportunistic encryption, though it has become quite an in vogue term.
> 
> Strawman. I didn't mention opportunistic encryption.
> I used the word opportunistic for what it actually means.
> 
> > > There is a fundamental flaw in the security architecture of the web
> > > and this new API does not address that.
> > >
> > Our charter makes this clear.
> 
> Is the charter in the introducing chapter of the specification?
> Probably not. The charter is a great place to share hippie thoughts with IETF 
> folks, but it has no effect on the output of the WG.
> It's a fig leaf.
> 
> > > Please make that clear, or you may stir false hopes and become
> > > responsible for potential consequences. People may be developing
> > > sensitive applications with this, not being aware that any
> > > certification authority of any country on earth can insert malicious
> > > code.
> >
> > Luckily, this is also not true.
> >
> > Certificate pinning is one such way to mitigate this threat.
> 
> Whoops wrong person. I am the author of Certificate Patrol, the main 
> certificate pinning implementation for Firefox. Some thousand people and me 
> are protected from your average government MITM attack, but billions aren't.
> 
> And the main cause is Google. It's because Google uses certificates 
> inconsistently, multiple certificates for identical domains, not even signed 
> by the same authority. Google makes it impossible to successfully implement a 
> certificate pinning security scheme with a reasonable end-user UX, and 
> considering the interwoven interests of your government I have a hard time 
> believing this will change anytime soon - even if all the employees were for 
> it.
> 
> > Regardless, its unreasonable to suggest we are responsible for
> > developers who chose to use eval on untrusted code, who choose not to
> > use CSP, those who introduce XSS, and likewise, those who fail to use
> > pinning. These are all complimentary tools in the developer's toolbox.
> 
> These are all symptoms of an architecture held together by band-aids, and web 
> crypto is inviting people to build edifices of high hopes in security on top 
> of a house of cards. Unless of course you are Google, then the world is 
> currently quite perfect.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

On Sat, May 24, 2014 at 07:38:50AM -0700, Al Billings wrote:
> 
> On May 24, 2014, at 12:30 AM, carlo von lynX  
> wrote:
> 
> > Oh, a Google employee. I know what to expect.
> 
> and then I deleted the rest of the content. Sorry but if that?s how you want 
> to start a post, the rest isn?t worth the bother.
> 

Haha.. I was just announcing that I was going
to get to the specifics of Google's role in the
insecurity of today's web later on in the mail.

But of course you can miss out on the meat by
being disturbed by superficialities.

Next time I'll try to resist adding that little
extra bit of humor since it's obviously not
well-interpreted by everyone.

Excuse my occasional troll ways, the situation
is far too serious to not voice certain concerns.

Business as usual is not acceptable.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

Sorry libtech, some of the in-between mails were not forwarded 
to you.

On Wed, May 28, 2014 at 02:21:55PM +0200, Anders Rundgren wrote:
> Asking for "consensus" on anything security-ish under these
> circumstances is simply put impossible.

That's because you can't build consensus if some participants
have an interest on dominating over others. The method of
consensus requires the group to remove such elements in order
to be able to work out a consensus which is best for the group -
and in this case the consensus must be privacy for humanity,
not security business models for companies or obligations to
their respective governments.

So the mistake in the method you are applying is well-researched
and has an answer. Issues concerning basic constitutional rights
of citizen must not be defined by a standards body open to
entities and elements with incompatible interests.

Thus, Webcrypto CANNOT be reasonably be brought forward by
either W3C or IETF.  q.e.d.

> Following the logic in your reasoning, you should list all the
> algorithms that should be deprecated.  I'm not a cryptographer
> but I'm quite familiar with security protocols and that's where
> things go really wrong.  If you take a peek in the IETF-TLS
> list you will get an idea of the complexity building secure
> protocols.

That is a fallacy. Negotation is a bug. GNUnet comes with one
wise choice of a cipher. Should a sufficiently relevant new
cipher be invented, GNUnet will have a transition period -
but that's it. No backwards compatibility humbug forever.

> BTW, I'm not a member of the WebCrypto WG but I mentally support
> the work anyway.  If somebody comes up with a better mousetrap
> I don't think anybody will object :-)

That's why you are perpetuating this debate which is VERY
much not in the interests of the W3C members. I like it.
Thank you for letting Eleanor's and my voice be heard.

> There were requests fora high-level API that would hide the
> complexity as well as always using the "best" algorithms.

Oh that's easy.. you can look at NaCl or EthOS for inspiration.

> It was rejected and IMO on correct grounds because there
> would be endless discussions on how such a thing would work
> and in the end nobody would be happy anyway.

It is totally among the duties of the advanced lobbyist to
know how to gently and delicately break consensus processes.
Of course a consensus could be found, but only among honest
participants. If you weren't successful, this is by today's
knowledge on democracy research a proof that your work has
been undermined by at least one participant who had no
interest in achieving consensus.

Or did you expect secret services would walk into the
working group meetings armed with machine guns and coerce
everyone into stopping to work on reasonable crypto
technologies for the masses?


-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

[carlo von lynX]

On Wed, May 28, 2014 at 09:31:42PM +0200, Anders Rundgren wrote:
> Yes, I forgot to mention that standardization efforts have nothing
> to do with Democracy, Free speech, Level playing fields, or a
> Quest for the best possible solution...
> 
> It is only about playing hard-ball, hallway lobbying and general
> disrespect for small entities.

That doesn't sound like a wise statement to make
if you hope to ship this thing with Firefox.

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[carlo von lynX]

On Thu, May 29, 2014 at 09:10:08AM +0100, Security First wrote:
> While the jury is still out on how this TrueCrypt issue plays out.

Hmmm..

> What are the best alternatives to TrueCrypt for the people we work
> with and train?

http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software

dm-crypt/LUKS and freeOTFE do provide an alternative,
but not exactly as easy to use.

That page is missing an upcoming relevant player there..
Dyne's Tomb:   http://www.dyne.org/software/tomb/
But for now it can only be used from command line.

As jaromil suggests, there is no true cryptographic safety on
Windows machines, so you might as well stop trying to do that
on such a computer.

Still, I don't get these periodic DoT*-attacks against Truecrypt.
Last year there was this rumour going around about Truecrypt not
having been properly audited, and then the code that turned out
not having been audited for years was openssl.

Now there is again fear of backdoors in downloadables from some
well-intended website. But who thinks *he can download binaries
via the web and expect them to be free of backdoors?

The whole approach is broken. The web is not trustworthy. You
need someone to get the source codes, look over it, make sure
it is the correct one, generate binaries and distribute them
over safe channels.

I have been using truecrypt built from sources for a decade now,
the only trouble it gives me is performance when dealing with
legacy file systems such as NTFS.

Please get your paranoia properly structured and oriented to the
things that are well worth being paranoid about.


*) denial of trust

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[carlo von lynX]

On Thu, May 29, 2014 at 08:51:21PM +1000, Tom O wrote:
> Truecrypt has not properly been audited.
> 
> The only audit to date is what has been organised by Matthew Green of Johns
> Hopkins University.
> 
> I believe there is still more to go on this, but in light of recent events,
> one wonders of this is worth it.

You mean Heartbleed?

Nothing in the whole industry is properly audited,
some stuff is just sufficiently old.

-- 
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] [GNU/consensus] Why support "Reset the Net" ? I don't get it

[carlo von lynX]

Heya.. I saw the ACLU, AI, EFF, FSF, Greenpeace, MoveOn
and other logos on the https://www.resetthenet.org page.

Yet the things the page recommends are band-aids.
If it was that simple we could have done such a
campaign the same day the revelations came out.

- 1st of all, the main problem is mail and chat,
  so you don't solve that by HSTS

- The recommended solutions for mail and chat
  are obnoxious for normal users to install and
  will be obsolete in a year or so, since no-one
  should stick to mail and chat that does not
  protect the social graph "meta" data.

- The idea that all HTTP sites should upgrade
  to HTTPS, without at least convincing one CA
  to hand out free *.domain certificates, is just
  an amazing promotional campaign for the CA industry.

- HSTS is the greatest of all band-aids, much weaker
  than DANE, still if you use it wrong you condemn
  yourself to buying certificates for potentially a
  veeery long time. Would be better to go for the
  less bad band-aid: DANE.

- Would be better if the web browsers were supporting
  proper pinning of self-signed certificates. Or
  supporting cacert.org so people can reasonably get
  free certs. They can show the sites with a yellow
  box instead of a green one (if Mozilla thinks cacert
  is less safe, which in the current situation is a
  ridiculous assertion anyway), but leaving the web in
  a state of utter brokenness is sick.

- Would be better to fix the scalability of Tor hidden
  services so we can use .onion instead of the broken
  HTTPS thing. Or if that doesn't work, use GNUnet for
  the "light web"

- Would be better to deploy opportunistic forward
  secrecy implemented in JS over HTTP (naif has been
  working on that)

- Would be better if campaign websites weren't themselves
  collecting personal data before even saying anything
  (the first thing it shows is a prompt to drop your
  e-mail into a box.. very reassuring).

So I don't see the point in a superficial campaign that
doesn't actually fix anything about the status quo, instead
it is likely to foster further damage by not offering long-term
solutions.

If you think this makes sense, please forward it to the 
appropriate people in the appropriate organizations and 
get that support out of this.

Best,

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] [GNU/consensus] Why support "Reset the Net" ? I don't get it

[carlo von lynX]

On Thu, Jun 05, 2014 at 04:06:25AM -0700, coderman wrote:
> in terms of first steps, the https push is the most approachable.
> passive, blanket surveillance resistance maybe a band-aid, yet still
> useful.

but without intervening into browser certification politics it's
just a huge advertizement campaign for the certification industry.
i presume that wasn't intentional, but still.. that's what it boils
down to.

the change of attitude needs to happen in the browsers and in the W3C,
not in the gazillions of websites that should all invest serious
amounts of money. browsers should ship with a public-key routing
technology like tor's .onion, i2p's .i2p or gnunet's .gnu.

i have about a hundred websites. i can't get certificates for each of
them. but what i will do soon is relaunch them as website.X.onion
since all it takes is apt-get install tor and a torrc.

> > If it was that simple we could have done such a
> > campaign the same day the revelations came out.
> 
> how long did youbroketheinternet.org take? ;)

it launched a month and a half later, but that's because it isn't a
simple campaign like resetthenet. YBTI is about developing the
necessary technology to enable usable end-to-end encryption and
social graph (aka metadata) protection (and a few things more).
so it is a site that aims for a *real* solution.

> i also think all of the technologies you listed above are insufficient
> for a truly decentralized, robust, privacy enhancing infrastructure.

you mean you agree with me? of course HTTPS etc are all broken and
inadequate. or what are you referring to?

> and finally, i think we should all be working on these types of
> efforts, and others, per our interests even if they have flaws.

no, it is wasted energy. 99% of engineers insisting on working on
horse carriages after 1% told the world they invented a car and
need help improving it. to make a comparison, and to reply to
jonathan: of course I know gnunet is much more than just a TLS
and HTTPS replacement, but since people tend to think of TLS
being such a huge thing, it's good to put that in perspective that
gnunet can be a better TLS by design, as a side effect of all the
things it is.

in a couple of years 99% of engineers will find out they have
invested sooo muuuch tiime in a technology which slowly but
steadily turns obsolete - at least i hope it goes that way
because if we stick to the broken internet we are going to rid
ourselves of what is left of democracy.


-- 
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] An interesting anonymous chat project: Invisible.im

[carlo von lynX]

On Thu, Jul 10, 2014 at 04:24:38PM +0200, Piotr Chmielnicki wrote:
> On 07/10/2014 04:06 PM, hellekin wrote:
> > On 07/10/2014 10:38 AM, Keira Cran wrote:
> >> Invisible.im (http://invisible.im) is a really interesting project
> >> leveraging Tor to provide anonymous chat. It takes a fascinating
> >> approach using Tor hidden services, but is yet to be released to the
> >> public.

Fascinating. TorChat has been doing that, too.

The fact that it tries to establish Tor circuits to every other
participant doesn't make it terrifically scalable. "Federation"
over XMPP doesn't change much of anything about that. I started
putting Tor federation into psyced a year ago, thinking that it
would be better than nothing.. but for some detail it didn't work
and I really should focus on secushare as the long term solution
anyway. PSYC would be more appropriate as a wire protocol than
XMPP for reasons as simple as binary file transfers being possible
to reasons as complex as...

"For some inexplicable reason the first few messages in a chat session just 
disappear into the ether."

XEP-0190 also shows that XMPP doesn't have a terrific track
record for secure delivery. The XEP has been deprecated, yet
several server implementations still close sockets the wrong
way. There is a XEP that puts acknowledgments on top of XMPP,
but you have to make sure your code actually uses that in
order to not lose messages.

"It's entirely possible and very easy to spoof a hidden service address 
when launching an out-bound connection from a locally-hosted XMPP service. The 
XMPP service accepting the inbound connection will do nothing to verify the 
source of that connection, thus spoofing is a real risk. This is why we'll be 
forcing OTR for all chat sessions."

That sounds like *totally* a problem with XMPP or some wrong
use of it. PSYC over Tor federates with no dependency on OTR
whatsoever. Tor hidden services are self-authenticating and
forward secret. The choice of encryption strength is sufficient
for mass communications I believe - if not, I would rather
upgrade Tor. Thus, chatting is as simple as using any IRC
client and all the auth you need is to get the onion address
right. OTR usability inferno is entirely optional.

"It must also be noted that the presence of identifying OTR key material on 
the source's system may be a liability. [..] This is why we generate one-time, 
ephemeral OTR keys in anonymous mode."

I must have misunderstood, but it doesn't make sense to me that
some bug in XMPP authentication is circumvented by OTR, yet the
OTR is not used for authentication. And even without identifying
OTR key material there is still identifying onion address material
on each computer - so that is a threat that can't really be solved 
this way. Pond goes as far as one can get, methinks, concerning this.
The social graph has to be somewhere, after all... Pond encrypts the
address book and does some mumbo jumbo with TPM. I personally think
all computers should use full disk encryption and that it is
pointless to invest energy in keeping some data encrypted if the
entire OS is still easily accessible and can thus break your trust
the next time you decide to input some extra safe part's pass phrase.

> > *** It sounds like the approach taken by Ciboulette [0], to run local
> > hidden services and federate them.  Although I like the approach, I have
> > the intuition it's too much effort put on the user: while we're at the

Ah, using prosody. Means having lua on each participant's computer.

> > point of installing servers locally to mimic P2P services, why not focus
> > the effort on advancing GNUnet services directly?
> >
> > The obvious advantage of GNUnet is that it's not just for chat, but
> > provides a complete infrastructure ranging from an alternate to DNS, to
> > HTTP transport, etc. [1]

Yes, but there's more to it:

"Initial conversations with people who know a lot more about Tor than us 
suggest that hidden services don't really scale that well."

GNUnet would not make circuits to each and every other participant
but rather create mesh nets. secushare puts multicast trees on top
of that for large size channels, so there is a realistic/scientific
perspective of obtaining a system that is both anonymizing and
scalable.

As a side effect you also get file exchange, a telephony prototype
and a few other nifty things... and you get rid of legacy code
dependencies such as X.509 and DNS.

> XMPP over hidden services could be a good compromise between
> anonymity/security and usability. A non-tech user could just use a
> server he trusts. Organizations could provide trusted servers for
> internal or public use.

That is not the scenario that invisible.im suggests, as I understood -
also because in that case you *do* need OTR for end-to-end auth and
because doing "regular" federation will always lead to very popular
servers which then turn into honeypots for attack.

So I say, no, that wouldn't be such a huge prog

Re: [liberationtech] An interesting anonymous chat project: Invisible.im

[carlo von lynX]

On Fri, Jul 11, 2014 at 07:24:45PM +0200, Fabio Pietrosanti (naif) wrote:
> I feel that we don't need another IM, but we need:
> - CONSOLIDATION of existing opensource/secure technologies
> - INTEROPERABILITY among existing opensource/secure technologies

naif, I love you, but you're sooo wrong on this.  :)

> We need to focus on what's already in the user's hand, make it  ubiquous
> and interoperable.
> 
> There are other "IM approach" that try to use Tor for anonymous chatting
> such as:
> - TorChat: https://github.com/prof7bit/TorChat
> - jTorChat: https://github.com/jtorchat/jtorchat
> - Richolet: https://ricochet.im/

And none of them solve the hidden service scalability problem.

Also, invisible.im's got a point I was wrong about in my last
mail - I had forgotten why I gave up on Tor federation: Tor
auth is one way - you know who you are connecting to but you
don't know who is connecting you. Tor could possibly solve that
by providing a demonstration of ownership of the onion's private
key, but I presume this doesn't exist yet. So the protocols
need to somehow do that on top.

Using ratchets to authenticate at the current point in time
without needing an "absolute" identity (the thing about OTR
being used in an ephemeral way) is how Briar does it. It
makes it harder to reconstruct the social graph as you need
to break into both sides of a communication. If you then
periodically inform everyone of a new .onion you are about
to use, then you make it harder to link a .onion to a person,
but you risk losing people if you can't be sure everyone got
that address change - and the more friends you have, the
lesser that works as a form of social graph protection really.

No, you shouldn't have a hidden service for each friend, as
that would blow up Tor in no time. So I still see a problem
there. Ephemerals on both sides are great, but the Tor DHT
isn't built for ephemeral rendezvous events. It is built for
having as few hidden service ports as possible - and having
to establish lots of circuits to each contact, just to say -
hi - i am online now - is already a problem enough.

> Any attempt to improve security is good, but i would strongly
> concentrate on consolidating and collaborating with existing projects,
> by improving them, rather than reinventing the wheel.

Well, in a situation were none of the solutions are safe and
scalable, why on earth would you want consolidation and even
interoperability? We need at least one solution that is
recommendable, then others can be compatible to it. Standards
and interoperability are only important when dealing with
providers of proprietary technologies - we have none of those
here. What we need now is a large degree of experimentation
and most of all interest in learning from the mistakes of
others - people keep redoing the same mistakes! People keep
pushing the scalability issue aside because it is not fun to solve.

> For example i would suggest to leverage existing CryptoCat codebase, to
> adapt/improve it to the requirements of "invisible.im" .

Why?

> Remember that maybe 90% of software job is making the software product
> to works properly, not making it secure.
> 
> If someone else already have done the 90% job, just focus on the 10%
> minor security improvements here and there.

What if the problem of most implementations is at the foundation of
the architecture? Also, invisible.im are reusing prosody and libotr so
they are already doing as you say - more than I would recommend.  ;)


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Snakeoil and suspicious encryption services

[carlo von lynX]

On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai 
 wrote:
> > I was wondering if it's time to make a list of not-so-good snakeoil
> > encryption services that have popped up after the Snowden revelations.

Too much effort really. It's easier to document the technical criteria
for judgment. There are three general categories: projects that look for
real long-term solutions, band-aids for the time being (although they
frequently think of themselves as solutions) and ultimately snake-oil humbug,
although there is no clear separation line between band-aids and snake-oil.

Let's look at the long-term solutions. We keep a map of them on
http://youbroketheinternet.org - anything that uses public-key routing
instead of trying to put a band-aid over the existing Internet is in it.
Everything that has a chance of protecting metadata is there.

Everything that tries to insist on using insecure technologies such as
X.509, DNS, DANE can at best be a band-aid. Everything that tries to
put encryption on top of SMTP, XMPP, HTTP instead of underneath, is
vulnerable. If it's not vulnerable technically, it is by usability.

If you really really make no mistakes, then PGP and similar tools will
allow you to have a secret conversation, but none of this stuff properly
protects who is talking to whom. And there is a further trade-off, if the
end-to-end encryption is only granted to you by a server that sends you
the suitable javascript code and you are somehow supposed to trust it.

So from a suitably radical perspective (can we afford anything less?)
many even respected projects are more close to snake-oil than actually
useful at protecting us from the pervasive active adversary we are
confronted with. Why insist? There are many projects designed in a
more secure way.


On Fri, Jul 18, 2014 at 08:32:36AM -0700, Steve Weis wrote:
> Somewhat relevant, I recently gave a talk about "Crypto Projects that
> Might Not Suck":
> http://saweis.net/pdfs/CryptoMightNotSuck-2014.pdf

I don't really understand these slides. There is a confused mix of
libraries that could of course be used properly or not, then many
band-aids and a few recommendable things and there is no differentiation
between tools that protect metadata such as Tor and Pond and all the
rest that merely tries its best to achieve end-to-end encryption.

Combining PGP/SMTP with Tor only works if all participants use
pseudonymous mail accounts, hardly anyone does - even then, one 
small mistake can deanonymize you and having a social graph too
similar to your regular mail account might, too. Pond and I2PBote 
are way ahead concerning this, providing mail systems that protect
the social connections, and since all participants have to upgrade to
be safe, why are we still talking of solutions that use the old
broken Internet?

OTR works well for encrypted communications if we didn't fail to
activate it and respected the bureaucracy of ensuring its accuracy.
But even if we didn't fail in that, we still entrust servers with
the knowledge of our social graph. To avoid that, chat systems that 
use hidden services are better - but then there is no reason to insist
on XMPP and OTR as invisible.im does: Tor already provides end-to-end
and forward secrecy, circuits are reestablished all the time. OTR is
redundant in this case.

Browser crypto is an oxymoron. As long as the browser has no way to
verify that credibility of the code, the entire architecture is snake
oil. Some folks are producing add-ons that verify JS crypto code by
PGP signatures, but those are special solutions that expect you to
trust certain PGP keys. A redo of the certification system. Band-aids.
You may do the crypto directly in your add-on, but that won't protect
your social graph.

If you want a safe web, you should go the way of cjdns, Tor, GNUnet,
I2P: The content was delivered with end-to-end encryption underneath,
so you don't need to worry about encryption on the upper layers such
as the web browser. Any .onion site is more secure than browser crypto
(if your aim is to talk to the owner of that .onion). Using browser
crypto with end-to-end hidden services is redundant.

The slides are entirely missing out on distinguishing public-key
routing infrastructures such as Tor, I2P, GNUnet, cjdns etc from the
traditional encryption-on-top-of-broken-routing technologies. The
latter are by design all band-aids or snake-oil. Thus, your slides
are missing out on most of the interesting projects happening. Crypto 
is not just about the algorithms. It's also about where you apply them.

Best regards.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Espionge.app's lack of plausible deniability (Was: TrueCrypt Alternatives?)

[carlo von lynX]

On Mon, Oct 06, 2014 at 09:16:42PM -0700, Greg wrote:
> I believe clicking on the email I gave him would take approximately the same 
> amount of time as replying to the list, but I could be mistaken.

You joined a list where to a certain degree there is
a consensus that, given Patriot Act and similar legislation
in other parts of the world, proprietary software is
undistinguishable from snake oil or trojan horses.

Why do you even come here? You should be talking to the
sort of journalists who still haven't understood the
issues and would welcome your efforts.

How can you expect noticing some beginner's mistakes 
to be considered a major "disclosure" and deserving
special treatment according to hacker ethos standards
if most of us agree that it is completely irresponsible
to be using your technology in the first place?

I also wonder if this list should accept lobbyism and
whitewashing of proprietary efforts, be it intentional or
just honestly naive, or rather remove folks who promote
such thinking.

It's not a question of taste and certainly not a question
of liberty since the freedom to make proprietary security
software is actually an infringement of the freedoms of
the confused users who naively go out and pay for it.

At least the name of the app is honest.

Sorry, Yosem, for jumping on this thread and feeding it,
but as I elaborate in [1] "don't feed the troll" is
actually a dysfunctional strategy. If you want trolls,
lobbyists, science sceptics, loud minorities etc not to
achieve any gain from their activity you need to take
other steps than to ask people to stop replying to them.

Sorry, Greg, I don't know if you're strategic or honest,
so don't take this personally. Systemic problems need to
be addressed systemically and this thread is just a
manifestation of a systemic problem.


[1] http://my.pages.de/ppp-hurting

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Facebook available as a Tor hidden service

[carlo von lynX]

On Fri, Oct 31, 2014 at 10:12:35AM -0600, Robert W. Gehl wrote:
> Let's say people take this seriously -- to do so, they will have to use
> Javascript, which is a bad move when using Tor.

Actually no problem with Tor at all.. after all Tor creates properly
authenticated links which is a lot safer than https, let alone http.
The risks of Tor are entirely about Tor possibly being targeted more
than regular Internet routing users, which both exit nodes and hidden
services could possibly do. In the case of these Facebook hidden
services we seem to know who is running the other side, so if an
attack is coming from Facebook it can pretty much only be by being
a TAO customer.

In other words, if you are a regular Facebook user, you are not more
at risk by switching to the more secure .onion. If you are a target,
then you are not better off by switching to .onion - you can still not
trust Facebook for Javascript execution. Facebook would only have a 
harder time denying having allowed TAO on you. 

Facebook DOES allow most of its function to be used without Javascript
via https://m.facebook.com, so to enable a truly safe usage of FB it
would have to also provide an .onion for that address.

Facebook has been quite cooperative allowing users to come from Tor 
exit nodes straight into https://m.facebook.com. They even recently 
fixed the ability to post to Facebook "Pages" (with Twitter gateway 
or not) without requiring Javascript.

So for everyone who needs to do activism over FB, as questionable as
that may be, but cannot risk getting her machine TAO'd, she should
stick to https://m.facebook.com until a suitable .onion is provided.

And keep that Javascript folly switched off.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] XMPP object encryption at IETF about to die...

[carlo von lynX]

Oh great, now I have friends pointing me at libtech postings
inciting me to reply to them because they're excited to see
what I will have to say...

At least I hope to surprise them a bit. Let's see...

On Tue, Nov 11, 2014 at 02:18:49PM -1000, Joseph Lorenzo Hall wrote:
> I'm here at IETF 91 hanging with all the protocol nerds. I was talking
> to someone about OTR and they pointed out that the object-encryption
> standard for XMPP that has been put forward is about to die due to
> lack of interest and engagement:
> 
> http://tools.ietf.org/html/draft-miller-xmpp-e2e

Yes, Matt Miller presented that at the IETF before and although
Snowden was in the air no client dev came forward to say YES!
Let's do this. It was so sad, I even refrained from bashing
XMPP too loud that it is the wrong and broken protocol for the
job anyhow.

> Has anyone seen this and thinks it could be a good thing to
> standardize? I realize it's a subset of what OTR provides but I'm
> wondering if this could be something we as a community might want to
> work with in this kind of standards body.

Subset? The proper integration of E2E and PFS removing most of the
trouble we have with OTR desyncing and throwing errors in our face
would be a great improvement of the XMPP experience, given you
want to keep XMPP. And it also applies to other XMPP packets like
profile look-ups etc - things that people *expect* to be secure
when using OTR while they actually aren't. So I don't really see
what you mean by subset here. I have the impression it does more.
Is it missing socialist millionaire? That would be a problem. Do
you mean that by subset? Haven't looked at the draft recently.
It's kind-of been around in the XMPP standards discussion for 
about a decade now, ever since OTR came up.

> Any e2e-has-a-posse folks have an interest here or is standardization
> not an interest or desire?

Standardization is not the problem. You need at least one dev
who cares enough to implement all the lot of code into one of the
too many badly implemented XMPP clients. It's awful how only few
XMPP clients currently offer the full up to date OTR protocol.
I have a feeling the majority of OTR conversations are not
properly being authenticated because of things like socialist
millionaire (aka shared secrets) not being implemented everywhere.

No wait, I correct myself. Standardization IS the problem. It
leads to every spare time code writer doing his own client brew
and none of them being solid enough for humanity's needs (given
that XMPP wasn't a bad choice in the first place). What we need
is everyone working on a single solid codebase, possibly
ChatSecure, and have that available for ALL platforms, with
professional usability and no glitches.

But then again maybe it's time to kiss federation good-bye.
XMPP comes not only with a lot of problems of its own that you
can read about at http://about.psyc.eu/XMPP - it also shares
the fundamental architecture problem with PSYC being the
federation of servers. When we designed those protocols we
made the fatally wrong assumption that servers are neat, cool,
sweet and most of all SAFE. Also back in the 90s we didn't
have DHTs yet. Fifteen years later it is overdue to admit that
XMPP, SMTP and other federation protocols were designed to a
paradigm which no longer is recommendable. We should improve
those technologies that provide not only end-to-end encrypted
messaging, but also metadata protection and defense against
attacks on single points of failure like jabber.ccc.de.

http://secushare.org/comparison lists a few platforms that are 
heading in the right direction. I need to add blockchain
apps to that soonish, as Bitmessage seems to function and I'm
no longer sure it can't scale. Maybe it actually could. Please
let's get off XMPP+OTR soon and not invest huge amounts of
energy just to get rid of the bugs.

And let's stop talking about open standards for free software.
Open standards are only important when we HAVE to deal with
some company dominating the field with its proprietary tool.
As long as we do not need to interact with any proprietary
thing, we can avoid impeding development by standardization.

Just think how useful it would have been to spread cat gifs
over XMPP if XMPP weren't so impractical for binary data.
Instead it sucks, so nobody does it.

It's crazy for our civil liberties and the foundations of
democracy to be using either Facebook or Google for personal
conversations, so we should not work on an open standard that
includes those platforms. So we don't need to focus on an open
standard. We just need running AGPL code, which implies a free
protocol by definition.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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

[liberationtech] state of TeleHash

[carlo von lynX]

On Wed, Nov 12, 2014 at 09:41:40AM -0500, Doc Searls wrote:
> http://telehash.org

TeleHash = JSON + UDP + DHT.

That sounds simple & brilliant, yet too simple for many applications. This
equation is neither considering protection of the social graph (onion routing
is missing and the currently popular Tor solution doesn't work with UDP) and,
what's even harder to solve, the scalability, that large scale social
applications need.

Telehash doesn't provide distribution trees, so it only works as well as
round-robin transmission works, which can be okay if it were just UDP in an F2F
style, but this cuts out social transaction data protection. Or you try to fix
that, but then you can no longer use "just" UDP and a round-robin approach. You
need to use something like Tor which is a lot heavier than just UDP and will
not scale for the one-to-many distribution use case, let alone many-to-many.

Also, the single parts of the equation could be improved. GNUnet's GNS could be
used instead of a regular DHT, so you get to have query anonymity, reasonable
consistency, a censorship resistance strategy and more. A generic lower layer
transport system that runs well over all sorts of NAT and mesh, even bluetooth,
could make sense rather than just UDP. A more efficient syntax than JSON, like
for example PSYC.

The original planning for TeleHash didn't include any encryption at all, so
that was very simple. Now that encryption does need to be wrapped around the
UDP packets and a public key infrastructure does need to be deployed, the
question of cryptographic discovery comes up, just like for any other of the
crypto and darknet platforms.

Maybe it's better to go for a platform that was designed with all of these
aspects in mind from the start. There is a reason why so-called darknet
platforms, or we could call them public-key-based routing systems according to
#youbroketheinternet, are not so simple. TeleHash shouldn't be too simple to
actually serve a job for privacy, either.

Retrieved from "http://about.psyc.eu/TeleHash";
  • This page was last modified 20:02, 23 March 2014.
  • This page has been accessed 995 times.

> Doesn't (and shouldn't) cover everything, but it comes from good motivations 
> and hackers.

Can you point me to some free software releases that
came with evil motivations? Would love to try some of that..  :)

-- 
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] self-determination considered anti-constitutional

[carlo von lynX]

http://mic.com/articles/104144/here-s-how-bad-american-views-of-privacy-have-become-since-the-nsa-scandal
indicates that a majority of Americans is ready for legislation that
would regulate the abuse of citizen data, yet they still think they
can have the cake for free:

"Yet Americans seem to want it both ways. A majority would be willing to 
share information about themselves in order to use online services for free, 
while only a few experienced negative consequences from their online 
activities."

There is no "information about themselves" that doesn't also affect
others. If we in masses publicly show how healthy we are, we make it
easy to discriminate the sick. Insurance business becomes a fake if it
only picks the people that are healthy - and that is just an example.

Being allowed to sell your data is like being allowed to drive a car
at night with your lights off. You aren't just endangering yourself, you
are a risk to everyone you meet.

If a majority of population is allowed to sell information "about themselves"
in order to read an article for free, democracy is undermined. The secrecy
of people's thoughts and opinions is fundamental for a healthy democracy.
If you're part of a predictable populace instead, you have kissed your
liberties good-bye.

Stop calling it privacy. We are talking civil liberties.

Most democratic countries possess the equivalent of a Constitution.
In most cases it includes Secrecy of Correspondence - not as a right, but
as a necessity for the successful practice of democracy. And it includes
Freedom of Assembly - with our mobile phones leaking information who is
meeting who, where did this requirement for a successful democracy go?

Self determination is great when we are talking about crunchy vs smooth
peanut butter, also when we are talking about the human beings we find
atractive, but being allowed to sell data about ourselves is plain
anti-constitutional. Let's stop talking of self determination when we are 
actually talking of the greatest public good mankind has ever developed.
We are insulting the people that lost their lives to give us democracy.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Tech: Problem or Solution? (Saturday at Stanford at 7pm)

[carlo von lynX]

On Sat, Nov 15, 2014 at 02:07:15PM -0300, hellekin wrote:
> > Nanobots vs. Hunter-gatherers!
> > 
> > Cyborgs vs. Dinosaurs!
> > 
> > Zoltan vs. Zerzan!
> >
> *** This is a stupid way to frame the debate.  Technology is not about
> "either you're with us or you're against us", that is a childish and
> imbecile statement.

Yes, on top this is off topic for this list.

-- 
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] Tor2web support for HTTPS on .onion

[carlo von lynX]

Scusa, Giovanni...

On Tue, Nov 18, 2014 at 10:38:41AM +0100, Giovanni Pellerano wrote:
> As Facebook has recently opened its own onion site [3], we’ve been
> coordinating this release with Alec Muffett from Facebook in order to
> block access to Facebook by means of the Tor2web proxy. Because Facebook
> has a normal website, using Tor2web merely presents an option for users
> to hurt themselves.  You can see the Facebook block here:
> https://facebookcorewwwi.tor2web.org

It is non-obvious to me how accessing FB over T2W would be hurting users.
If tor2web hands the TLS negotiation through from the web browser to the
Facebook backend, the tor2web proxies therefore do not have access to
cleartext Facebook/user data, how would this be bad for the user?

Hoping to understand better, Carlo.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Tor2web support for HTTPS on .onion

[carlo von lynX]

Sorry for answering my own question, but I hope it's interesting.

On Wed, Nov 19, 2014 at 05:14:48PM +0100, carlo von lynX wrote:
> It is non-obvious to me how accessing FB over T2W would be hurting users.
> If tor2web hands the TLS negotiation through from the web browser to the
> Facebook backend, the tor2web proxies therefore do not have access to
> cleartext Facebook/user data, how would this be bad for the user?

I think I figured it out. If naif's question about Facebook using the
Tor2web mode is to be answered positively, then you are both cheating
on the onion routing. Both Tor2web and Facebook skip the relay hops on
the way to the rendez-vous point - thus there would only be the
rendezvous point as a relay between tor2web and the Facebook backbone
which can be considered rather bad for anonymity.
Did I get that right?


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Trackography

[carlo von lynX]

On Mon, Jan 05, 2015 at 09:55:37PM +0100, Anne Roth wrote:
> The video of the talk by Maria Xynou and Claudio Agosti is already
> online: https://www.youtube.com/watch?v=VmlPn1tVFVY

Congratulations to Maria and vecna for one of the few
truly interesting things coming out of this year's congress.*

During the presentation I was wondering if you are aware that
in the online advertising market there exists a practice where
the readers are auctioned off to the advertising networks
within milliseconds while the reader is waiting for the
server to produce the expected web page. Depending on which
network won the auction, you may be seeing completely different
dependencies.

For the later part of the talk concerning Terms of Service
I guess mentioning https://tosdr.org is a rather obvious
pointer so I assume your database contains a different kind
of analysis. I am not familiar with each, so I'm just making
a superficial bystander's cerebral connection.

Again, thanks a lot for your work!


*) I am quite annoyed by the abundance of broken federation
   ideology technologies that have been promoted at 31c3.
   I doubt they will work well enough to solve humanity's 
   problems with the Internet. Federation only scales in
   the cloud, and the cloud is evil.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

Concerning Whatsapp there is a very interesting clue
in a thread on "messaging" that suggests users will
never know if end-to-end encryption is being used, since
the server decides whether they are allowed to, and
the user is not informed. Knowing the NSA that means
that Whatsapp would never encrypt anything end-to-end.
Whatsapp should therefore be considered a Trojan horse 
for people seeking easy to use privacy. Read about that at

https://moderncrypto.org/mail-archive/messaging/2014/001133.html

Careful on using that mailing list however. If I
understood correctly it is being maintained by one
of the developers of TextSecure, which is the end-to-end
encryption system that has been integrated into Whatsapp,
possibly with the purpose of looking good, making good
headlines and never being actually run.

http://www.wired.com/2014/11/whatsapp-encrypted-messaging/

Of course I assume everyone is operating in the best of
intentions, including the NSA. This is just FYI.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

On Thu, Jan 15, 2015 at 08:49:31AM -0800, Steve Weis wrote:
> Note you said "users will never know" if e2e is being used, but as Moxie
> says "we'll be surfacing this into the UI" of upgraded clients.

There is a systemic legal problem by which neither Facebook, nor
Whatsapp, nor Textsecure nor Moxie are in a position to guarantee
that whatever is surfaced into the UI actually means what it says.

Still, as long as these systems are operating from U.S. American 
ground, the current legal situation is such that the President of 
the U.S.  has under the U.S. Constitution the sole and final power 
of deciding whether companies and individuals in these companies 
get to implement anything they would like to implement, or not. [1]
And the services we have been hearing about a lot operate under 
direct executive mandate of the POTUS.

So, I again express respect to Moxie and everyone involved for
trying to improve the lives of everyday users, but I see a terrible
risk in promoting any such technology considering the NSA's track
record on making use of its given privileges. The chances this is
actually happening can only be considered minimal.

It would take millions of people running independenlty built
clients from source code, and a credible procedure thereof - only
then would a hindrance for the NSA exist to exercise its privileges.

As we are by now familiar with its inner workings and strategies,
the agency will intervene in the process early enough to impede
anything like this from happening.

Prove me wrong. Give us a way to reproduce the exact client millions
of humans are relying on, from source code. And make that information
arise to the UI surface. Then we will know that Whatsapp and TextSecure
are doing the right thing, and we will have to continue worrying about
Google and Apple (the NSA may choose to pick up the TextSecure ratchets
or private keys via Android/iOS backdoors).


[1] Caspar Bowden, 31c3, 
http://cdn.media.ccc.de/congress/2014/webm-sd/31c3-6195-en-The_Cloud_Conspiracy_2008-2014_webm-sd.webm.torrent

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

On Thu, Jan 15, 2015 at 12:50:41PM -0500, Richard Brooks wrote:
> Actually, you also need to have source code for the compilers
> used and the compiler's compilers...

Yes, we have those. We have systems completely produced from
source and others that are working on complete reproduceability.

> And that ignores the use of hardware trojans.

No, it puts things in perspective. Hardware backdoors I think
are more likely to be suitable for targeted surveillance, not
mass surveillance. Targeted surveillance is not a problem for
democracy as much as bulk surveillance, so I consider that
progress.

Also having to bring backdoors down into the hardware drives
up the cost of surveillance. That is good. Surveillance must
be expensive if we want democracy to prevail.

-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

On Thu, Jan 15, 2015 at 10:45:16AM -0800, Al Billings wrote:
> Insisting that we both can and cannot (at the same time) trust people like 
> Moxie simply because they live in the USA and the NSA exists is stupid.

You are free to trust him to spend a night at your home. I would
if he was my friend, but I never met him. Yet the word "trust" in
politics is the root of most evil, and to entrust a person with the
responsability for millions of people whose civil rights may be
respected or infringed without them even finding out.. well, that
is more than trust. That is irresponsible towards all involved
people, including Moxie.

> I don’t see a suggestion of what jurisdiction the author thinks people can 
> live within where there won’t be the same issues.

Similar issues, at times, but not the same. Like Germany has this
rule that secret service wants access if you're a communications
provider for more than 9'999 users (if I was told correctly).
But the way that law is written it would not allow the secret
service to impose on the company not to deliver end-to-end 
encryption to the users.

The way laws do not apply on this topic is specific to the U.S,
shared only with non-democratic regimes. Only the U.S. Supreme
Court or an amendment to the Constitution could rectify the power
balance between citizen and president in this matter. [1]

You and I know, that no binary distribution should be trusted,
no matter where on Earth it was compiled. But that is not a point
of view the general public is ready to adopt. The mainstream press 
and the majority of people out there still believe that companies
can have an ethos, can actually do what they market, and that
proprietary software could possibly be trustworthy - at least as 
long as the press says good things about it.

To these people it is no viable argumentation to say, you must
only use free software (I say that all the time), but it does
mean something to them to find out that the laws are such that
the promises a company is making are 1. irrelevant and 2. have
to be deceptive because that is what is expected from them. That
*is* news.

At least in other countries this kind of behavior is ILLEGAL.
We don't know if it's not happening, but at least it could get
some people in trouble if they got caught with their hands in
the pudding.

> Which country should people be in where the government isn’t going to try to 
> potentially legally compel them to do things or spy on their communications? 
> Where is your utopia of freedom?

Utopia is nowhere. But you as a U.S. citizen are better off
in most democratic countries on Earth: not only do almost all
countries respect your civil rights even if you're a foreigner
(The U.S. is the only country that treats foreigners as vegetables
by law [1]. Other countries at least infringe their own laws when
they do this.) Plus, by leaving the U.S. the NSA is still supposed
to not spy on you, so it needs the GCHQ to take care of that. It
may be hard to prove, but I believe GCHQ is breaching its laws
when it does that favor to the U.S.

There are more reasons why some countries qualify as "less bad"
but I prefer not to elaborate.


[1] as before


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

Except for the totally unacceptable way you are speaking of a
human being here, you aren't saying anything which is incompatible
with what I said... so will you return on topic or do you want to
produce the impression the Whatsapp issue is about proprietary
software in general, which it isn't?


On Fri, Jan 16, 2015 at 10:19:22AM -0800, Al Billings wrote:
> The problem is that I am a practical person who lives in the real world. 
> Telling people “Throw away all of your Apple/Microsoft word processing and 
> often software. Throw away all of your games. Throw away all of the software 
> you bought because you can’t trust any of these.” is going to be met with 
> being ignored or marginalized and with utter derision. There is a reason 
> Stallman is seen as a crazy wing nut and it isn’t just because he eats his 
> own toe jam.
> 
> Yes, there are people that will only run open source software. Then there is 
> the other 99.999% of the human race. *Those* are the people that need to be 
> helped.
-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

[carlo von lynX]

Al, you may want to deviate the discussion towards the 10.000th
debate about proprietary vs free software, but the topic here is
the impossibility for a U.S. company to deliver what it promises.

Should the U.S. develop an interest in regaining international
trust, they would need to remove several inappropriate laws plus
improve the separation of powers. The U.S. is one of the world's
oldest democracies and it shows, centuries of special interest
politics have convoluted it - most Americans I meet tell me it 
actually isn't a democracy. I don't like hearing that. And I don't
like the influence it is exercising on younger democracies. And 
New York City will never go back to being as cool as it was in
the 80s.

On Fri, Jan 16, 2015 at 01:52:57PM -0600, Cypher wrote:
> I was under the impression that the government couldn't make you
> actively lie to someone. For example, if I have a message on my page
> that says "we do not collect any user data" and the government makes
> me collect data on an existing user, that's acceptable. But they could
> not stop me from changing that sign and force me to lie. I'd assume
> that would be the case with WhatsApp. Once the visuals are surfaced,
> each new encrypted connection would be forcing the service to actively
> tell a lie, which, as I understand it, isn't legal. Of course, IINAL
> so I don't know.

I remember reading or hearing that upon reception of an NSL you are
not supposed to batter an eye and change anything about the way you
interact with the public. Also, your legal theory doesn't match up
with what was said in Caspar Bowden's presentation. It's also not at
all obvious, that the NSA would openly confront the leadership of a
company. If there is any suitable technology administrator, they can
require her to cooperate without anyone else in the company knowing -
this is in fact very advantageous for the NSA, since they can consult
their own data bases for suitable people: not very strong ethically,
possibly with documented sins the NSA can blackmail them with.

And then there's also the option of accessing the infrastructure the
company is using, for instance by controlling the hosts that run any
rented VPS systems - but that is unlikely the scenario in the case
of Whatsapp. That's more the type of approach they need to use with
servers located outside the U.S.

That is why the theories the Google employees are exchanging among
each other are humbug. Of course the NSA can have a backdoor in order
to consult Google data bases and make it look like random Gmail traffic.
You may find it funny, but apparently employees at Google want to
believe PRISM can't possibly have happened. Anything that serves as
an excuse to legitimize staying in that company, earning all that money.

I haven't said anything new, just reflecting what I picked up since
those dramatic days in June.

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Videos for a GNU Internet

[carlo von lynX]

Since 31c3 has been very interesting in terms of
politics and hacking, but not as much concerning
technologies that are supposed to lead us out of
the broken Internet, here are the missing videos
from the #youbroketheinternet sessions, exploring
the options for a GNU Internet built from scratch.


Routing panel feat. I2P, cjdns, secushare and others:

http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Routing-Panel_I2P_GNUnet_Tor_secushare.webm

Sybil-attack resistant mesh routing using GNUnet:

http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Mesh-Bart_Polot-GNUnet_Wireless_Mesh_DHT.webm

cjdns, Hyperboria and Project Meshnet:

http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Mesh-Caleb_J_Delisle-cjdns-Hyperboria.webm

Mesh networking panel feat. Freifunk, cjdns and GNUnet:

http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_Mesh_Routing-Panel-cjdns_freifunk_GNUnet_net2o.webm

NaCl, a Networking and Cryptography library:

http://cdn.media.ccc.de/congress/2013/workshops/30c3-WS-en-YBTI_OS-Bernstein_Lange_Schwabe-NaCl_and_TweetNaCl.webm

"We'll make ourselves a GNU one" - YBTI project presentation
in German at Easterhegg 2014:

http://cdn.media.ccc.de/events/eh2014/webm/eh14-5808-de-Well_make_ourselves_a_GNU_one_webm.webm
in English at ThinkTwice 2014:
https://www.youtube.com/watch?v=iGxjN-lfr_Y

Enjoy, and keep your mind open for exciting new thinking.


-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Why are we leaving mesh networking to FireChat?

[carlo von lynX]

On Sat, Jan 17, 2015 at 06:24:42AM -0500, Rich Kulawiec wrote:
> I rather expect than in another generation or two the entire obsolete
> closed-source ecosystem will be viewed as an unfortunate aberration
> in the evolution of computing.  This will happen whether anyone wants
> it to or not, because it's going to be *necessary* for it to happen
> in order to ensure privacy, security, and integrity in computation.

Wonderful. I love your entire post, Rich.
Inspires me to apply the thought to a pressing issue.

Over a decade of research in mesh networking has happened.
In projects like Netsukuku, Freifunk but also the frequently
(sorry) cited GNUnet. Why the hell is the open source community
still to the 99% focused on server-connectivity-dependent
technologies, leaving the next generation of activist tools
ONCE AGAIN in the hands of proprietary offerings?

> And again, *in the context we are in here*, it's absurd to even suggest
> that closed source software should be on the table for consideration.

Here we are in libtech, for several years now, and we haven't
been able to provide a mesh networking chat tool to the folks
in Hong Kong and elsewhere?

Briar? ServalMesh? cjdns? secushare? net2o? COR? Zyre?
All prototypes? Unfinished pieces of a puzzle?

Yes, cjdns is actually a running piece of software.. but
it was done quickly, with no sybil attack protection in
place. Predictable paths, no metadata obfuscation at all.

On the other hand GNUnet, with so much resarch gone into 
every detail - but noone there to fix it up and turn it 
into an actual product. Where are all the hackers? Why are
they playing around with SMTP over Tor and similar useless
stuff? [1]

How likely is it that FireChat suffers from sybil attacks?
Do we have to wait until somebody shows us? Causing harm to
activists and population in the poorest parts of Earth? Can't
we give them something solid?

Watch those videos explaining sybil-resistant DHT routing.
Bart has really nice slides to illustrate how that works. [2]
Understand that THIS is how we should route the entire
Internet. THIS is the foundation of a GNU Internet, where
anything you do is end-to-end encrypted, authenticated and 
resistant to censorship.

Remember John Gilmore saying "The Net interprets censorship 
as damage and routes around it" ? Well, with these technologies
for the first time that is actually true.

So put your PHP and Ruby aside. We need P2P code development.
We need agnostic relay nodes, not servers. Tor was only the
beginning. We need to dig deeper. We need mesh nodes all over
the Internet backbone just as much as in the favelas and the
city center demonstrations.

This isn't fringe technology. This is the next generation. It's
the clean slate which has surveillance-resistance built-in.
I know something about scalability, and there is no reason to
expect this stuff not to scale to worldwide use. At least the
well done projects.

And we need it to be encrypted, not unencrypted like FireChat.
The reckless way that is implemented, it's only a question of 
time until people will call it BackfireChat.


> Those who see Stallman as a "crazy wing nut" have not been paying
> attention -- or perhaps lack the analytical capabilities required to
> comprehend what they observe.

Word.

>   The greatest shortcoming of the human race is man's inability
>   to understand the exponential function.
>   --- Albert A. Bartlett

Epic grand sigh.


[1] The "De-anonymizing Social Networks" attack described
in the paper by that name is probably applicable to
any popular XMPP or SMTP server, no matter how much
it is kept behind Tor.
[2] http://youbroketheinternet.org/#30c3meshnet

-- 
http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
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] Ghostery, NoScript.. add-ons frequently phone home

[carlo von lynX]

Just so you know, frequently the add-ons you recommend have
phone-home functionality just as Firefox itself.

Firefox by default connects Google to let it know your current 
IP of the day. Officially it is picking up precious info from
some safebrowsing*.google.com site.. you can disable it if you
dare to uncheck the "Block reported [evil cybercrimes]" boxes.
I was told it even lets Google have the cookie it uses to
identify you, so even if you use Tor, the five eyes immediately
know it is you. I didn't bother to check however.

Next thing it does is to connect a whole slew of
*addons.mozilla.org sites to make sure it won't miss out
on letting Mozilla know which version you are running etc.

Then it's the moment for the addons. NoScript immediately
sends a shout out to informaction.com while Ghostery...
Oh no! Ghostery! Weren't they supposed to be the good folks?
Yes, Ghostery has code in its init() function that looks
like this:

if (JUST_UPGRADED) {
metrics.recordUpgrade();
} else if (JUST_INSTALLED) {
SDK.timers.setTimeout(function () {
metrics.recordInstall();
}, 30);
} else {
metrics.recordInstall();
}

You don't need to learn coding to understand that here is
a series of if/else-if/else which, whatever condition your
addon may be in, will result in some metrics.something()
getting executed. That function then happens to produce an
HTTP request targeted at "d.ghostery.com" which tells
Ghostery which IP address you are using today and whether
you are a nice person (Ghostrank=1) or not so nice (aka
Ghostrank=0). This allows Ghostery to measure how many
people are using their tool.. which sounds reasonable from
a business model point of view. Unfortunately, the problem
with business models is, there hardly seem to be any that
go together well with privacy. So once again a privacy tool
is protecting you really well from the truly nasty people,
but cutting out a little privileged exception for itself.

Is this a serious problem? Depends. I haven't checked whether
it sends identifying cookies along. Probably the information is 
rather anonymous - you may consider this no reason to worry.

I was a bit surprised to find that Ghostery calls home even
if I unchecked all the appropriate preferences, but it does.
You can opt out by blocking the hostname in your firewall.
At least until they change it to "e." or "f."

What do you folks think about this.. should we worry about
software calling home to report things about us? Do we really
have to inspect each specific case or should we be angry anyhow?
Where is the boundary of well-educated privacy software?

How much more capitalism can the web take? I see a systemic
problem of capitalism not getting along well with
constitutional duties.


-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion  DON'T SEND ME
  irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
 http://loupsycedyglgamf.onion/LynX/OR FACEBOOGLE
-- 
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] The Google cookie that came out of nowhere

[carlo von lynX]

Juicy content from Ashkan Soltani further below.

On Sun, Apr 26, 2015 at 01:26:29PM -0700, Al Billings wrote:
> If you're the kind of person paranoid about safebrowing pings and similar, 
> yeah, you should pull the tinfoil hat tighter and block all things.

What I said in the original posting:
"I was told it even lets Google have the cookie it uses to
identify you, so even if you use Tor, the five eyes immediately
know it is you. I didn't bother to check however."

I wonder if you read that part. Should that part be accurate, then
safebrowsing is among the top vectors for mass correlation of IP
numbers (or Tor circuits) to specific browsers and human beings.
The others being font and jquery includes, search engine utilization
and maybe a few +1 buttons here and there.

We discussed this topic back in 2014, May 12th to be exact.
safebrowsing could be offered in a distributed anonymous way,
instead it is being done in a way that it de-anonymizes people to
the fie eyes.

Some weeks later I accidently met Ashkan Soltani who told me he
already dissected the issue in pre-Snowden days. Looks like it 
hardly got traction - since noone knew the implications:

http://ashkansoltani.org/2012/02/25/cookies-from-nowhere/

http://blogs.wsj.com/digits/2012/02/28/the-google-cookie-that-seems-to-come-out-of-nowhere/

It is actually quite incredible that Google has been flying under
the radar of general interest since Ashkan's story came out, given
the immense implication for mass surveillance.

P.S. I don't think you have the necessary competence to tell *anyone*
about tinfoil hats and would like to ask you to contribute to this
mailing list less frequently and more thoughtfully. Thank you.

-- 
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] What should the "liberation tech" response be to ISIS-related recruiting online?

[carlo von lynX]

On Wed, Jul 01, 2015 at 06:00:08PM +, Sean Lynch wrote:
> I don't think it's possible to simultaneously enable people to exercise
> freedom of speech on the Internet while preventing the use of the net for
> things we don't agree with. Recruiting for ISIS is just speech, and any
> tools that would enable governments to stop that would also enable them to
> stop other kinds of speech they find inconvenient.

I have two suggestions to make to handle recruitment and
abuse of suicidal radicalized persons:

1. Improve the web to better provide a rational debate on
   all the issues rather than creating rhethorical bubbles
   where the analysis of how evil capitalism and the west
   have become is put in perspective where possible and
   where the consequences of suggested action are especially
   refuted - just because the world is evil doesn't entitle
   you to make it even worse. Currently discussion platforms 
   on the web which are suited for rational debate rather 
   than populistic blabber are hard to find.

2. Take the criticism seriously. The capitalist west *is*
   destroying the foundations of human life on planet Earth.
   As long as there is no credible political effort to fix
   this, we cannot expect frustrated youth not to radicalize
   against the status quo.

Had we proper democracy, the problem would probably not
manifest itself:

- Yes, the recruiters would enjoy Secrecy of Correspondence
  enabling them to recruit without governments watching.
- But, opposing political movements would not be impeded to
  form, therefore political change would already be happening.
- Thus if we had proper democracy we would already have fixed
  wealth distribution and economic/ecologic sustainability
  instead of wondering how it is possible that although 99,9%
  of Earth population want things differently, the leading 0,1%
  continue to do as they please.
- Therefore the recruiters would not find anyone to recruit
  for stupid kamikaze action happenings.

In other words, terrorism is a problem caused by lack of
democracy. The solution is to fix democracy.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Any project missing on the updated map of a "GNU Internet" ?

[carlo von lynX]

Hey ho.. long time no see.

A newspaper intends to print our map of projects that are
possibly contributing to a complete new protocol stack for
a new Internet.. or rather.. a GNU Internet. So we updated
it. Here it is: http://youbroketheinternet.org/map

Of course a lot of projects are missing.. but it should be
the ones that aren't using a public-key based routing sub-
system anyway. Find the details of the criteria by which
EDN, GNU consensus and youbroketheinternet sort out more
and less interesting projects on http://youbroketheinternet.org

Thanks in advance for feedback.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Any project missing on the updated map of a "GNU Internet" ?

[carlo von lynX]

On Sun, Oct 04, 2015 at 11:44:35PM +0200, Lluís Batlle i Rossell wrote:
> Hi Carlo,
> 
> NixOS is available since years. I use it since 2009 everywhere.

Moved it to the green box of reliable choices.
(OT) Is it viable to have all code recompiled from source?
 How does it feel compared to Gentoo? (in case you tried that)
> 
> Maybe you could add OMEMO (Conversations implements it), and Axolotl.

I've added Axolotl although it is a frequent feature of the e2e
circuit layer. Pond, GNUnet and probably also Maidsafe have
their own DH ratchet implementations.

OMEMO would go into the red box with XMPP. Federation technology
cannot by design provide a long-term contribution to the new
Internet. Find some argumentation on http://about.psyc.eu/Federation
and further reasons to deprecate XMPP on http://about.psyc.eu/XMPP
OMEMO is riding a dead horse. There's a reason why a similar XEP
called ESessions didn't get very far either. Just recently I read
an article on how bad libpurple is.. but the problem isn't just the 
code. It's the protocol. There is no way of implementing XMPP clients
and servers that do not suck. I find it funny that people always
blame it on the implementations and think by rewriting them they can
fix a whole culture of bad choices behind them. All they get is yet
another XMPP something that sucks.

> What about things from WhisperSystems? And SMSSecure.

I can put TextSecure into the yellow box with PGP and OTR... stop
gap tools that operate over metadata unsafe infrastructure.

Understand that the GNU Internet is also about solving the 
metadata problem in a pervasive way - no exceptions for the 
lazy, metadata protection by default.

Whereas for Redphone/Signal, just like Telegram only the UI seems
to be freely available. Of course UIs and telephony implementations
are useful, but the list of tools with unsafe backends (anything
we can't compile and run ourselves is unsafe) is long and would 
require a pretty large box at the top of the map... Then again, I
can't think of that many openly published e2e client apps after all,
so a yellow box is appropriate.

> Next to IPFS there could be "morph.is".

Oh wow, morph.is looks interesting!

> As for libre hardware, maybe the Loongson-based computers are worth 
> mentioning.

I just threw opencore.org in there as a meta index for hardware.
Can't also get competent in that area myself in this lifetime.  :)

> Regards and thank you for the work!

Thanks for the feedback!


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Any project missing on the updated map of a "GNU Internet" ?

[carlo von lynX]

On Mon, Oct 05, 2015 at 04:17:05PM +0200, Lluís Batlle i Rossell wrote:
> Well, we don't have build farms for ARM, so it is common for people to
> build all there, for example. Following upstream means building more than
> gentoo, because the dependencies are totally explicit at any point.

Oh, good to know. On the other hand it should be safe to randomly use
prebuilt binaries because all binaries are reproducible, so a malevolent
provider cannot know in advance which packages will be checked for
reproducibility... yes?

> As for the rest of your advices, I'm quite aware about the uses of
> leaked metadata, the problems of xmpp, etc. :) I quite follow the project.
> I just wanted to help have more pieces in the map - I do not consider
> them a final solution.

Yes, none of the things on the map solve the entire puzzle. There's
plenty of redundancy while at the same time there isn't a complete
stack ready to go, let alone several.

> Maybe you could mention also somewhere that modern PGP thing (which is pgp at
> the end): keybase.io. It just came to mind.

There are several stop-gap opportunistic approaches to key retrieval
around.. pEp, LEAP. I think we should be leveraging the social graph
for key acquisition instead, with a private distributed implementation
like GNS for example. You use it like an address book and your social
network guarantees that you picked the correct public key, without
any state authority knowing anything.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Any project missing on the updated map of a "GNU Internet" ?

[carlo von lynX]

On Mon, Oct 05, 2015 at 05:37:50PM +, Jonathan Wilkes wrote:
> Glad to see you finally removed Oneswarm. :)

Onewhat? I don't know what that is.

> I personally find your chart difficult to read.  Nevertheless, I have a 
> suggestionthat I believe would improve its quality for a general audience:
> 
> You really need a color that means "available and widely-used".

No, I'm against furthering the effects of the hype-machine.
There are projects that are underused with no reasonable
explanation at all while there are others that are heavily
overused despite their limitations. Also, usage is not what
this map is about. It is about which code is available and
actually working for the purpose of fixing the Internet. It
is not about how many people have been unable to ship it to
Linux distributions and make a big fuzz out of.

TAILS relies completely on binaries compiled on US-American
soil. I have no idea why I should trust that. GNUnet file
sharing works great, there is plenty of interesting political
documentaries on it. I don't understand why GNUnet has an
insecure IRC channel and people on it do not actually use it.

Hype is the instrument of control of the spin doctors.
This community is just as affected as any other.

Thanks for your opinion however.

-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Any project missing on the updated map of a "GNU Internet" ?

[carlo von lynX]

On Mon, Oct 05, 2015 at 07:59:02PM +, Jonathan Wilkes wrote:
> As for "widely-used" being synonymous with "hype"-- any takers other than me? 
>  Especiallywrt anonymity-overlays?

I said neither of the two things.

I see factually that there is a gap between wide usage and rationality
which doesn't make it synonymous but still a problem and I don't see
"anonymity overlay" as being a sufficient qualifier for a scalable
authority-free alternative Internet. I use Tor every day, but several
other projects are more suitable for the plan of making a new Internet.
Tor is too much focused on providing low latency access to old Internet
offerings and we discuss its shortcomings each day on the Tor mailing
lists and meetings. Making the Internet new means kissing the client-
server model good-bye, at least for the majority of everyday uses.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Beyond the Snowden Treaty?

[carlo von lynX]

I like David Miranda's initiative to promote a global treaty
against surveillance as he proposes in his snowdentreaty.org
site (which I haven't seen, since it depends on JS)... Thanks
to the Spanish Pirates for making me notice this... but I 
doubt that is the right path to undertake:

Governments of all nations will not be happy to sign such a
treaty if it means that they will have to bring surveillance
back to secrecy and risk a serious public crisis should they
get caught.

Stopping surveillance by "choice" is out of the question:
All countries would assume that the other countries are still
spying on them, so they cannot by national strategic interest
*afford* to stop surveillance on as much population as possible.

>From my point of view the only way out of this dilemma is to
introduce an Internet that *cannot* be surveilled. This puts 
countries into a position of strategic advantage compared to
those that let themselves be surveilled.

A secure Internet cannot be introduced by "the market" as
there is no viable business model for it, but it can be
imposed by market regulation. From the year 201x on, the
Internet must be secure from surveillance.

I have worked with a team of likeminded in drafting the formal
details of such a legislation that would introduce proper
respect of constitutional principles into internetworking.

Enjoy: http://youbroketheinternet.org/#legislation

Feedback is very welcome. Thinking of making it a plain text
generated document so everyone can fork the git.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] New messenger to replace Adium and Pidgin

[carlo von lynX]

Oh, at the last Tor developer meeting I heard that this project
was looking for a new name since it doesn't make sense to wear
"Tor" in it as if that was a quality endorsement.

On Thu, Oct 29, 2015 at 03:43:58PM -0400, Kate Krauss wrote:
> Today, Tor is releasing a beta version of Tor Messenger. Compared to
> Adium or Pidgin (you can use your jabber address and all your
> contacts)--it's pretty easy to use and much safer. It's in beta,

Thanks for developing a tool that is less bad than Adium or Pidgin,
but we should really move away from federation and its terrible
lack of protection for the social graph.

With Ricochet becoming more widespread as the *real* Tor way
of doing IM, end-to-end using hidden services, why should an
old-fashioned OTR/XMPP client/server less secure tool be
promoted as *THE* Tor Messenger? It's just highly inappropriate.

I had suggested to call it "WAM" as in "Wrong Architecture
Messenger". Please let me know which more appropriate name I
can feature on http://secushare.org/comparison as a forth
best practice recommendation... *after* Ricochet, Tox and
Retroshare.

Thanks.

Sorry for trolling, but I can't help saying things.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Communication tool comparison, new edition

[carlo von lynX]

While prism-break is great, but doesn't really explain what
the individual projects deliver compared to each other. While
the EFF messaging scorecard lacks metadata protection. While
the LEAP secure email report is heavily biased by priotization
of legacy compatibilty, here is a comparison of free software
tools which goes technologically in-deep and focuses on trying
to protect our constitutional obligations and liberties for
real, without promoting broken technologies just because they
are popular. It has six sections on the following topics:

Use Case: Social Networking
Use Case: File Exchange
Use Case: Instant Messaging
Use Case: Asynchronous Messaging (E-Mail)
Use Case: Telephony and Video Conferencing
Use Case: Chatroom Idling

http://secushare.org/comparison is where you find it.
Feedback is welcome.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[carlo von lynX]

Let's frame the threat models. Bulk collection probably does 
not include using OS backdoors so the suggestion to use mutt
on BSD isn't wrong, but not necessary to move a step forward.

On Sun, Nov 01, 2015 at 05:39:29PM +0100, ma...@wk3.org wrote:
> I think mail providers should stop accepting starttls opportunisticly,
> but should start requiring it.

Whereas man-in-the-middling SMTP federation connections
(same problem as with XMPP and IRC networks) may be rather
cheap: How do mail servers check certificates? Do they
pin them down? Do they accept anything valid? Do they
ignore certificate validity? What if anything went wrong
during interserver-TLS. Will the end-user ever find out?
Do the new "Received" headers really reflect such info
and how would you explain what certain headers mean to
the end user?.. given the "Received" headers are accurate,
as questioned in previous mail. And then you may bump
into mail providers that use inconsistent certificates
like it happened for us who developed "Certificate Patrol"
to find out that the majority of our potential users can't
handle the frequent amount of questionable https 
connections the industry confronts them with, given such
freedoms in the broken X.509 standard TLS is built upon.

Yes, mail providers should require STARTTLS, but it leaves
a dozen insecurities up in the air which are structural
to the very bad protocol standards we have. It's less work
to design a new mail system from scratch than to reduce
the insecurities of SMTP from 31 to 30.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[carlo von lynX]

Thanks for taking on the challenge to discuss things for real.

On Mon, Nov 02, 2015 at 07:11:00AM -0500, Rich Kulawiec wrote:
> On Sun, Nov 01, 2015 at 06:42:23PM +0100, carlo von lynX wrote:
> > Let's frame the threat models. Bulk collection probably does 
> > not include using OS backdoors so the suggestion to use mutt
> > on BSD isn't wrong, but not necessary to move a step forward.
> 
> And why not?  If the endpoints aren't reasonably secure, then what happens
> in the middle doesn't matter.  We *could* completely re-architect SMTP
> from scratch, design and build in as much security as we possibly can,
> but if someone foolishly insists on using Windows or a smartphone to
> send/receive mail, it won't matter a bit.  (I trust everyone is aware
> that Windows 10 is spyware pretending to be an OS.  It doesn't *have*
> to be backdoored en masse, it ships that way from the factory.  And
> "smartphone security" is essentially an oxymoron.)

Certainly the way Windows is systematically imitating the G-Mail success
model by running everything you do and type through advertizement models 
is terrible. Are Android or iOS already sending everything back home?
AFAIK only Microsoft is trying to take back the lead in the race to the
bottom of civility.

As long as those OS's do not systematically send keylogging data back
to their homebases, an attacker doing a targeted attack to get at the
stuff would be visible in the traffic - thus it is not as low hanging 
fruit as bulk sniffing of TLS as seen with BULLRUN.

> So at this moment -- without a completed, peer-reviewed, implemented
> replacement for SMTP globally deployed -- the single biggest things that
> end users can do are (a) use a hardened OS (b) use a hardened email client
> (c) do not use webmail (d) do not use freemail providers.  These are easy
> steps well within everyone's reach.  They don't solve all the problems
> (and they don't try to) but they tackle the obvious/easy ones.  They raise
> the bar for attackers and they only require using things *that already exist*.

That's all true, but the bulk of mail traffic is still unencrypted...
And when it isn't, it resides on mail servers that are usually not
so very hard targets. So this is the threat order I would guess:

1. SMTP + X.509
2. your OS, especially if you didn't read the T&C of Windows
3. the ever luring Web
4. vulnerabilities in GUI mail clients

> > Do the new "Received" headers really reflect such info
> > and how would you explain what certain headers mean to
> > the end user?.. given the "Received" headers are accurate,
> > as questioned in previous mail.
> 
> I'm not questioning them, I'm pointing out that the hard cold
> reality is that you CANNOT trust any that weren't put in place
> by your own MTA.  Period, full stop, end of discussion.

So Alice sends a mail to her server. That server forwards it
to a mailing list server, adding a header about the fact that
the mailing list server was found to have an invalid certificate.
The mailing list server may forward this header or even delete
it. When Bob picks up his mail, he finds Alice wrote to the
mailing list. No reasonable way to find out, that she got MITM'd.
There may be traces of information in some untrustworthy
"Received" headers, but they could also be intentionally put
in there by the evil mailing list server to cause confusion.
At least that would be the threat model if you say "full stop.
end of discussion."

> Here's an example from this morning, reformatted for readability.

Thanks you for the nice example. I'm sorry you elaborated so much
on this, but I hope some other readers didn't know about these
problems yet and have gained knowledge this way.

> So before we even get to the question of whether or not that putative
> prior hop was via TLS, we have to answer the question of whether or
> not that hop *even existed*.  And we can't, because we are not in
> possession of the information necessary to do so.

Correct. Still it makes no sense for benevolent nodes to fabricate
false warnings about insecure TLS usage. Question is if it makes
sense for malevolent nodes to do so, maybe in order to distract
from something else.. or if it doesn't make sense for them either.
If it doesn't, then warnings in "Received" headers are useful even
if they aren't securely delivered.

> The sad reality is Paranoia is
> worse than nothing, because it relies on information that can be
> and quite often is wrong or fabricated.

You're probably right. Sorry, naif.

> > It's less work to design a new mail system from scratch
> > than to reduce the insecurities of SMTP from 31 to 30.
> 
> If you want to write

Re: [liberationtech] data manipulation

[carlo von lynX]

On Tue, Nov 10, 2015 at 12:13:43AM -0800, coderman wrote:
> On 11/9/15, Elias Groll  wrote:
> > ... I've been reporting on warnings issued by DNI Clapper and NSA Director
> > Rogers on the threat posed by data manipulation and integrity attacks.
> > These statements have been vague in nature and lacking specifics.
> 
> generally, manipulating data is done for any of the following reasons, and 
> more!

https://theintercept.com/2015/04/02/gchq-argentina-falklands/ is an
interesting story on the subject.. JTRIG managed to steer public
opinion in argentina concerning falklands, avoiding another crisis
as in 1982... using automated manipulation of opinions of individuals,
so it is quite different from regular "media manipulation" which was
available in 1982 as well and couldn't have worked.

this may sound like a cool feat to avoid a war, but consider also
that the uk managed to impede an entire population from expressing
their democratic will.

in other words, these methods based on JTRIG and KARMA POLICE
dismantle democracy at its foundation - the ability to form a
political opinion and to make government act accordingly. this is
what the secrecy of correspondence was supposed to protect us from,
but the authors of our respective constitutions didn't foresee
that we would start communicating digitally and make it laughably
easy for attackers to manipulate us completely.

for as long as we do not produce a surveillance-resistant social
networking and communication platform, we are not in a state of
democracy. anywhere in the world. i cannot imagine any higher
political priority than to fix the internet and create a distributed
social network to replace facebook and the like.

what do you think?


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] data manipulation

[carlo von lynX]

On Tue, Nov 10, 2015 at 02:32:43AM -0800, coderman wrote:
> the combination of mass spying for mass media control (including propaganda)
>  is abhorrent, and as yet unrestrained.

yes, but when you talk to bystanders who aren't getting it, please
explain the difference of a surgical invasive action on the minds
of each individual, algorithmically automated to scale to at least
the most influential people if not the entire facebook/whatsapp
populace.

> > for as long as we do not produce a surveillance-resistant social
> > networking and communication platform, we are not in a state of
> > democracy. anywhere in the world. i cannot imagine any higher
> > political priority than to fix the internet and create a distributed
> > social network to replace facebook and the like.
> 
> decentralization is a moral imperative for many reasons!

but it is important to learn from the mistakes made in 2010 and
once before in 2003: there is decentralization that has a chance
of working and decentralization that is a dead-end street yet
it keeps getting propagandized into our heads: federation. it
hasn't worked with the semantic social web in 2003, it hasn't
worked with diaspora in 2010, it's not going to work on the
next attempt either. a social networking tool which is decentralized
and actually functional to scale to humanity-wide use MUST not put
all its data onto some servers but MUST operate from the devices
directly. not purely P2P, but using the paradigms of distributed
computing as informatics has developed in the past decades.

> and a fully decentralized IT infrastructure might thwart centralized
> power most effectively.

yes, which unfortunately implies to forbid scalable remote control
technologies such as microsoft windows, google and apple os's.
it might take political awakening, a political will to save democracy
and an intervention on legislative level in response to the uprising.
so we have a bit of a chicken/egg problem here.

we might have a window of democratic opportunity if we get people to
switch to a distributed social network (there isn't any currently in
existance that fulfils all requirements so it is somewhat hypothetical)
until all the os-based remote controls are in place for the same kind
of mind control that we now experience on facebook. and even that
requires to get entire populations off of facebook.

> fully decentralizing these types of services, along with
> decentralizing the production of computing systems which support them,
> some of the most challenging problems in technology. good luck! :)

technologically we are actually in a pretty good situation, we're
almost there.. what's missing is political support which would also
boost the finalization of the technology for end-user applicability.

> P.S. these are also my favorite problems to explore. don't get discouraged!

thanks, i don't know where i get all my positivity from considering
the mess we are in. maybe because i see a way out which is a rare
privilege.

-- 
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] Stop using public IRC networks

[carlo von lynX]

*** Why we should move away from public IRC networks:

Even for things as simple as discussing the furniture of our office space we 
should not let our discussions go straight into XKEYSCORE. On mailing lists 
there is a rough chance of staying on topic but in chatrooms it is inevitable 
to also chat about private things, disclose information about our friends. 
Things that by human rights charters we are not allowed to share with Big 
Brother. We didn't break the Internet, but we have a responsibility to take 
measures, anyway.

On public IRC networks surveillance is likely to happen. Even if all 
participants use TLS to connect to the servers, most of the IRC servers in the 
network will see a copy of each spoken message. Even so-called private messages 
travel the backbone and stop by a lot of servers, so OTR is good - but still 
helpless about your metadata and about the public exchanges you have about 
where to go in the evening or how you got distracted from work. Excellent food 
for the JTRIG and KARMA POLICE agency programs.

With so much interesting and competent content going in and out of popular IRC 
networks it is naive to expect that agencies have neither broken into any of 
the servers (one is mostly sufficient - depending on the tree structure - to 
scoop up most of what happens on the entire network), nor have they set-up a 
MITM attack by which servers are confronted with falsified certificates and 
likely silently engage in fully surveilled interaction. I would be surprised if 
any IRC server were to do certificate pinning, probably just like most XMPP 
implementations it doesn't even check the validity of the certificate. It is 
therefore really really easy for a global attacker to get a complete view of 
the communications happening on an IRC network. Let alone that any individual 
operator of the servers can himself be targeted by KARMA POLICE or JTRIG, thus 
granting access to the authorities "voluntarily."

Chat server networks were built on trust, and trust is a very erosive concept. 
We must conclude these networks are securitywise a failure. Both in the case of 
XMPP and even more so with IRC.

It's really not that hard and there is nothing so public about a chatroom that 
it deserves forever storage, forever being available as material that can be 
used against us and offers zero space for true social interaction - unless we 
want to shoot ourselves in the foot and disclose private social things to the 
insolent constitution-disrespectful authorities.

*** Where can we go to have a private chat?

In a post-Snowden world, where can we go to quietly idle and occasionally chat 
like we have done for decades? In our opinion there are two answers. On 
isolated servers, if you have a reason to trust the server, or on a distributed 
chat system. Unfortunately the latter are still in dire conditions. See the 
secushare comparison for that.

It should go without saying that using any commercial offering such as Whatsapp 
or Facebook is likely worse than using an IRC network. Maybe Telegram chatrooms 
are at least safe from the Western authorities.. so for once it is somebody 
else snooping on you.

*** Is IRC Safe From Bulk Collection?

The IRC protocol as such isn't any better or worse than other 
unencrypted-by-default protocols as long as you keep your hands off the 
interserver connectivity features. So any isolated IRC is fine, just as any 
isolated PSYC server. Maybe PSYC offers a few more practical features.

It is rather unlikely an agency would make an extra effort in targeting a 
solitary server that is doing its job for a tiny mostly harmless community – 
unless you placed it in a hosting center that gets scooped in its entirety 
anyway. Should the server have obvious vulnerabilities, then it is still a 
welcome target for systematic intrusions such as HACIENDA, but if it is a 
well-kept up to date free software system it is strategically very unreasonable 
to use up a 0-day vulnerability or backdoor just for a few conversations more – 
especially if the targeted community features competent hackers that might just 
recognize the method employed and document it publicly, thus making the 0-day 
invaluable for future use.

So it really doesn't make as much sense to attack a small community of hackers 
as it totally makes sense to collect a public IRC network's low-hanging fruit. 

So we recommend to everyone who runs a channel on any public IRC network, no 
matter which, to please consider setting up an isolated chat server system 
instead.

Best regards from youbroketheinternet.org.

Version with hyperlinks available at http://about.psyc.eu/IRC


P.S. Aymeric: liked your last post, just not finding time!

-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
Liberationtech is public & archives are searchable on Google. Violations of 

[liberationtech] Trusting tools under US jurisdiction

[carlo von lynX]

On https://torrentfreak.com/anonymous-vpn-service-provider-review-2015-150228/
I frequently see VPN service providers explaining their reason for operating
from the US as follows:

>> We choose to operate in the US in order to provide no logging 
service, as there is no mandatory data retention law in the US. Additionally, 
our beloved clients are given access to some of the strongest consumer 
protection laws, and thus, are able to purchase with confidence. <<

... which may be correct if you look at all the laws except for the Patriot Act
by which companies such as DuckDuckGo, OpenWhisperSystems and even NGOs such as
riseup.net must quietly allow the authorities to obtain full access to all 
data, tell as little as possible people about it (frequently the CEO is not
informed so that they can evangelize convincingly how safe their product is,
not be all shaky and nervous like Gen. Clapper), and order the company to carry 
on promoting the notion that privacy be in safe hands. We know from PRISM and 
Lavabit how much that isn't true, but since then the US is pretending times
have changed, which - knowing the NSA - cannot be true. It would be strategic
madness to leave the knowledge over data to other nations.

In any case it is reasonable to assume that all of these privacy companies
based in the US are selling snake oil because they just cannot refuse when
the letter comes. The question is if *formally* anything has changed with
the adoption of the Freedom Act. Is PRISM a little bit more illegal now than
it was before? Would there be any judicial consequence if companies get
caught selling out to authorities again?

In any case I don't understand how people happily use riseup instead of a/i,
Duck Duck Go instead of ixquick, Signal instead of Telegram. I haven't found
any place that offers an independently built Android binary for Signal. How
reasonable is it to assume that OpenWhisperSystems can operate on US soil
without shipping an NSA backdoor in all Signal installations? What other
reason can there realistically be to actively fight the existence of
deterministically or alternatively built copies of the Signal client?

Have we learned anything from the Snowden revelations at all? The last thing 
we can do is trust humans to have the integrity to withstand the power of the
US government. It is inappropriate to expect all the crypto pop stars to be 
heroes and entrust our safety to them. Trust the maths and the facts, not the
figureheads. Do not overload the people with responsibility. One thing humanity
knows very well is how to corrupt people.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Trusting tools under US jurisdiction

[carlo von lynX]

Sorry for getting everyone into defensive mode again. This is NOT about
the cultures, the values, the good intentions the road is paved with. I
was merely pointing to a legal situation that appears obvious to me but
isn't to everyone, and the consequences we should probably take - even
if those services are provided by the best of the best.

Unfortunately none of the replies answered my question whether bulk 
collection of intelligence on humans is still enforceable by law in the
US (and I add Germany to the list of countries with suchlike phony 
legislation), but you may find theories raised interesting.

On Sat, Nov 28, 2015 at 12:34:03PM -0500, Shava Nerad wrote:
> Let's take the example of DuckDuckGo first.  Here is a search engine that
> does not log searches, does not use cookies, and does not track users.  So
> unless you think they are doing that, even though they say they do not,
> there is no information for the NSA to requisition.
> 
> This is very similar to Tor, for example, where you don't have to trust the
> system because the system does not retain logs etc. (although in the case
> of Tor, exit node operators have abused the system historically, if users
> are cautious the damage from such abuse is minimized).

Excuse me, Shava, but DuckDuckGo is *totally* unlike Tor. While Tor is
a system that by design does not allow anyone to decide whether they
should keep logs except for the user (the exit nodes only see what the
user has submitted, not who they are), DuckDuckGo *takes* that decision
and builds a business around it without being able to guarantee that it is
accurate. Not only are we unable to check what is being logged, it doesn't
even matter as long as somebody leaked the server encryption keys to the
NSA, enabling it to keep complete recordings of all transactions in the
clear without ever touching the DuckDuckGo servers. There are so many
ways how the treason against the users can be organized that the users
will never find out - that even the people at the company will not be able
to detect. Have you ever spoken to Google employees? They truly claim or
believe what the NSA has done isn't possible, so it can't have happened.
It's surreal. Everywhere there is a move towards repeatedly claiming
falsehoods knowing that the truth will have a hard time being considered.

In fact there are more than one technical possibilities to get at our 
information and if a break into the systems wasn't succesful one well 
chosen single person in a company or organization is sufficient to make 
the entire security architecture tumble down. Programs such as JTRIG and 
KARMA POLICE have surely shown that the Five Eyes know how to find that 
weakest link in the system and talk to them using the words they 
understand. We've seen the evidence of this happening. Assuming that now
that we know about it it will suddenly stop is more than naive.

> In the case of riseup, with which I'm less familiar -- but I'm familiar
> enough with the sort of situation they might be in -- I'd assume they'd do
> a Lavabit if necessary.  But that might be a lot to expect.  Knowing that
> they would is often enough to keep such things at bay.

Lavabit has been a one-off event. The man took a risk, since he was not
supposed to speak openly. And the man was probably the only person they
could reach out for, given the size of the company. There probably was
neither a weak link nor a security issue with Lavabit, so for once the
method failed. Probably the NSA has learned from that experience, but not
in a way that we would like to, because it is illogical to think that a
organization of that size is suddenly capable of taking ethical decisions
just because it got caught with the hands in the cookie jar. Literally.

On Sat, Nov 28, 2015 at 03:02:59PM -0500, Alfredo Lopez wrote:
> Just to be clear, Riseup has never turned information over to anyone and

Since whichever individual(s) would not be allowed to safely admit if 
they knew, this appears to me a legally untenable statement. You cannot
possibly know. But interestingly this is the same thing the Google
people say about things like PRISM having access to all of gmail:
It's not happening because I would know.

> I would know. Both us at May First and Riseup have fought intensely
> (sometimes together) to stop NSA data theft and other forms of
> informational bullying and so far we've been successful. It's a fight
> but riseup takes it on and that *does* separate it (and us at May First)
> from the commercial server crowd. We fight this fight every
> day...believe me.

I believe you, but why should the NSA stop bullying you just because
it found somebody to hand them the private server keys? Wouldn't that
make you worry if something is wrong? So they have to insist on annoying
you even if, by my understanding of US law and NSA mission and practices,
it would be close to absurd to think they don't have access.

> I've written a whole bunch on NSA surveillance and the main theme 

Re: [liberationtech] Skype Co-Founder Launches End-To-End Encrypted 'Wire' App

[carlo von lynX]

On Fri, Mar 11, 2016 at 05:35:04PM -0800, Yosem Companys wrote:
> http://www.tomshardware.com/news/wire-app-complete-end-to-end-encryption,31389.html

Interesting that Germany is seen in such positive light.
Germany has a Patriot Act "light" legislation whereby if
the Wire app has more than 1 users it can be obliged
by authorities to provide a 24/7 backdoor into their
systems. In this case compliance is easy if it can be
added to the binaries being distributed...

Not sure if this is accurate, however.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Panama Papers Facebook Group

[carlo von lynX]

On Wed, Apr 06, 2016 at 11:23:55AM -0500, Steven Clift wrote:
> We are over 600 members sharing news from very global sources. The nation
> by nation journalism is astounding, but many of the best emerging stories
> are not surfaced easily.
> 
> Join us:
> https://www.facebook.com/groups/panamapapers/

Facebook is not neutral. Here's an example:

https://theintercept.com/2015/04/02/gchq-argentina-falklands/

By entrusting FB to deliver group messages to all the subscribers
it empowers FB to choose which ones will appear on dashboards and
which ones will hardly be seen by anyone. And to expect that not
to happen has proven to be naive.

So maybe you should use mailing lists or forum software instead.


-- 
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] Panama Papers Facebook Group

[carlo von lynX]

On Sun, Apr 10, 2016 at 07:35:55PM -0400, Griffin Boyce wrote:
> carlo von lynX wrote:
> >So maybe you should use mailing lists or forum software instead.
> 
>   How am I supposed to post dank memes on a mailing list?  On a
> serious note, nothing is truly neutral, and if the whole goal is to

E-Mail is mechanical - each article you share ends up in the folder
of the recipients - no filtering, no logic by which something important
can disappear from your dashboard.

> just have a place to share links, then Facebook is a decent option.

No. Additionally you want to share the articles themselves rather
than the links as it means that your readers can get information
without exposing which one they considered most worth reading.

Little gestures that reduce how much we are a predictable populace
rather than a democratically enabled electorate.

If in 20 years time your kids ask you why you didn't act against
total surveillance while there was still free speech and such
you will be able to say, well, at least I helped inform the 
population on corruption scandals without exposing their interests 
in it more than technically necessary.

By using Facebook it isn't clear if the monitoring of population
interests outweighs in damage the achievements of informing people
about the Panama Papers.

Maybe you're just being another brick in the wall.
You like to?


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Android KeyStore Vulnerability: which tools are affected?

[carlo von lynX]

Which of the popular libtech tools are affected by this paper?

///++ 8< 

https://eprint.iacr.org/2016/677/20160706:055348


Breaking Into the KeyStore: A Practical Forgery Attack Against Android KeyStore

Mohamed Sabt and Jacques Traoré

Abstract: We analyze the security of Android KeyStore, a system service whose 
purpose is to shield users credentials and cryptographic keys. The KeyStore 
protects the integrity and the confidentiality of keys by using a particular 
encryption scheme. Our main results are twofold. First, we formally prove that 
the used encryption scheme does not provide integrity, which means that an 
attacker is able to undetectably modify the stored keys. Second, we exploit 
this flaw to define a forgery attack breaching the security guaranteed by the 
KeyStore. In particular, our attack allows a malicious application to make 
mobile apps to unwittingly perform secure protocols using weak keys. The threat 
is concrete: the attacker goes undetected while compromising the security of 
users. Our findings highlight an important fact: intuition often goes wrong 
when security is concerned. Unfortunately, system designers still tend to 
choose cryptographic schemes not for their proved security but for their 
apparent simplicity. We show, once again, that this is not a good choice, since 
it usually results in severe consequences for the whole underlying system.

Category / Keywords: secret-key cryptography / Android KeyStore, authenticated 
encryption, integrity

Original Publication (with minor differences): ESORICS 2016

Date: received 5 Jul 2016

Contact author: sabt mohamed at gmail com

Available format(s): PDF | BibTeX Citation

Version: 20160706:055348 (All versions of this report)

Short URL: ia.cr/2016/677


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] New Course (Fall 2016): Hacking 4 Diplomacy

[carlo von lynX]

On Mon, Sep 26, 2016 at 05:10:55PM -0500, Andrés Leopoldo Pacheco Sanfuentes 
wrote:
> No-More-Pizza, especially if it is the Empire kind, a horrible
> bastardizatrion of REAL PIZZA and bad for your health

Some basic knowledge for handling the PIZZA challenge:

- Pizza was not invented in Chicago.

- Sbarro is not an Italian Eatery. It is Mexican.

- Mexicans know sh*t about Pizza.

- Pizza was not invented in Sicily.
  Sicilians only started making decent Pizza in the 2000s.

- Most Italians in the USA are of Sicilian descent.

- Most Italians doing Pizza in the USA have no clue of decent Pizza.

- Argentinians think they got taught how to make the best Pizza
  in the world, but they too are actually having Sicilian Pizza.

- Pizza stems from Naples.

- It is also done well in mainland cities like Rome and Milan.

- If you want decent Pizza in the USA, find Italians who have arrived
  from mainland Italy within the last 15 years. Anyone who's been away
  from home too long is just making Pizza up.

- In Italy there are proper Pizza baking schools, whereas abroad
  every Italian has a business interest in claiming they know how to
  do Pizza, then they just make it up. Find Italians that actually
  learned the art of proper Pizza baking.

- In Italy there are thousands of Arabs, in particular Egyptians, who
  have learned making Pizza at the appropriate schools and do better
  Pizza than Italians in the USA. Find anyone who went to Pizza school
  in Italy, regardless of skin color or nationality.

-- 
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] E-Voting

[carlo von lynX]

On Thu, Nov 17, 2016 at 04:18:59PM +1300, Eleanor Saitta wrote:
> Yes, there has been research done.  The summary is "if you do this,
> forget about any chance of having a free and fair election, because it's
> hard not to end up accidentally hacking the election, let alone stopping
> anyone who might want to actively hack it".
> 
> There's a decade or so of research on how bad just electronic voting is,
> and another decade of research on how bad mobile phone security is.  The
> combination is geometrically worse.

Full ack. It is already a bad idea to elect people instead of making
choices on issues, it is a lot worse if you expect technology to
maintain secrecy.

But if you are interested in having people debate and decide over
issues rather than people, and they understand this can only work
in full transparency, then you can look into LiquidFeedback and
suitable apps to go with it. You should not go for anything less
since direct democracy has shown time and time again that it is
a platform for demagoguery. Liquid democracy combined with proper
methods and a legal structure can bring out the collective
intelligence of the participants instead, empowering them to take
fact-based and properly reasoned policy decisions. The technology
is like the use of paper in a virtual parliament of the people. 
Any participant should have the ability to confirm the accuracy of
the procedures, something the software does not perfectly provide,
but that is just work to be done.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] [FoRK] [zs-p2p] Thank you for choosing cyberpunk dystopia.

[carlo von lynX]

> On Sat, Dec 31, 2016 at 12:16:41AM -0800, Stephen D. Williams wrote:
> > If we all find a way to solve the anti-terrorism problem, or at least
> > carve out space for it to be solved, we'd be less at odds for protecting
> > privacy etc.  There are some promising ideas I think, but all solutions
> > so far involve painful and often unacceptable tradeoffs.

On Sun, Jan 01, 2017 at 08:58:15PM -0500, Rich Kulawiec wrote:
> A rather obvious -- but nearly entirely overlooked -- approach is
> to refuse to be terrorized.

Pretty much agree, but so far only Israel is famous for
following that path. Sigh.

In the law proposal for a secure Internet that some folks
and me worked out, we see some potential in addressing the
issue in a more systemic way:

- In order to also avoid the problem of fake news having
  a business model and the possibility of micro-invasive 
  influencing of electorate through bulk surveillance and
  big data analysis plus targeted IMHO anti-constitutional
  manipulation...

... we propose that all social interactions on the Internet
be end-to-end encrypted and anonymized by law.

The technologies aren't entirely capable of that yet, but
a strong legislational interest creates the incentive for
industry to participate in a new fair market rather than
being cut out of it, so that is not the primary problem.

Yes, this would imply that the way Facebook & co function
is no longer legal. Social networking has to become a
basic function of the Internet, like TCP/IP today. I
would love to find a way for corporations to run the
platforms of our constitutional liberties, but I see no
way this can ever avoid conflict with the constitutions
of our democracies. Social interaction cannot be a product
that is being sold to us in exchange for surveillance.

As a side effect, such a legislation also impedes SPAM,
phishing and other kinds of "cybercrime". It also implies
de-facto net neutrality and a few other nice things.

- In order to enable law enforcement, methods are provided
  for LEA's to observe specific targets rather than the
  entire population - as in accordance with the constitution.

That is *not* done by key escrow or any other method that
de-facto depends on the good will of the LEA's as depending
on any such good will is anti-constitutional by definition.
We propose physical and cryptographic consensus style of
approaches for ensuring that the number of observation
operations stays within constitutional boundaries.
Explaining that means copy & pasting the proposal itself.

Please, when making Internet advocacy, keep this option
in the back of your head: One way to deal with it all can
be to actually fix it. More on youbroketheinternet.org.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
-- 
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] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[carlo von lynX]

On Fri, Jan 13, 2017 at 07:26:29PM -0500, Sebastian Benthall wrote:
> https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/
> > > https://www.theguardian.com/technology/2017/jan/13/

I've also read 
http://www.golem.de/news/schluesselaustausch-aufregung-um-angebliche-whatsapp-backdoor-1701-125571.html
and https://tobi.rocks/pdf/whatsappslides.pdf
and to me it seems like all of the articles are
technically describing the same procedure.
The difference is only in the framing.

For Facebook it is a necessity that people not be
bothered by key changes, for anyone in the libtech
business it is an alarming signal that MITM is
technicaly possible by default and users must be
specifically aware of the issue to avoid it.

But why is anyone even expecting any true privacy
from an American proprietary product? Have the
PRISM and MUSCULAR programs suddenly been discontinued?
Has Freedom Act amended NSLs also for non-Americans?
How could Facebook afford not to pump everything they
can get into XKEYSCORE as before? Why did the European
Supreme Court rule that the US is not a safe harbor
for EU citizen data? Did I miss any recent developments?

Is it the general strategy to have people debate whether
there is a backdoor when by law Whatsapp MUST have some
backdoor?

-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[carlo von lynX]

Thx, efecto

On Sat, Jan 14, 2017 at 10:17:07AM -0300, FL wrote:
> I'm not sure that every American company, by law, must implement a backdoor, 
> as you imply. The last time I checked, iMessage was a very secure platform 
> with no known vulnerabilities — which in fact has made Apple struggle with US 
> agencies more than a few times.

Has there been any litigation with the NSA? I only
saw interaction with the FBI - and the FBI has a
less prioritary job: law enforcement. Nothing that
is worth questioning national security for, so I
would assume FBI doesn't get the same clearances
as NSA. You can't monitor an entire population if
strategically unimportant offences like child abuse
would blow your cover - thus it is mathematical that
FBI cannot have the access privileges of NSA.

By "last time I checked" you don't mean the code
that is actually deployed into those devices but
merely "checked the news", right?

-- 
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] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[carlo von lynX]

On Sat, Jan 14, 2017 at 10:48:48AM -0300, FL wrote:
> Sadly I'm not a hacker — I'm a lawyer, so I haven't checked their code nor 
> any other company's for that matter.

We have plenty of hackers but not enough lawyers, so your
view on what the laws currently actually imply is very welcome.

> However, my main point remains unaddressed — I'm not sure that American 
> companies are 'required by law' to implement backdoors.

Alright, didn't percieve that as your main point.
Well, here's what I know last time I checked:

- PRISM is a reality
- NSLs have been used to oblige such companies to
+ hand over access to their data centers
+ expect no legal harm when denying any existence of NSLs
+ expect general public to never become aware

Leaks have broken the latter promise, so those companies
had good reasons to be upset. Freedom Act has changed
NSLs in such a way that American citizen must no longer be
bulk collected, NSA must only be allowed to run "selectors"
which in the case of Whatsapp means that some backdoor
must be provided to execute surveillance on such selectors.

Also, I have to look up Casper Bowden's posts again,
somewhere the laws explicitly give zero rights to non-US
citizen - all of humanity is backdoorable and bulk
collectible. And then we have programs like
https://en.wikipedia.org/wiki/Muscular_%28surveillance_program%29
which explicitly bypass US law.

Isn't Patriot Act essentially obliging the NSA to collect
all it can? If the NSA must do that, then any company
impeding the NSA from doing so is breaching that law, no?


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
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.