[liberationtech] Job for Civil Society Protection Online

[Yosem Companys]

From: Betsy Cooper 

Dear Colleagues,

In these uncertain times, my organization, the Center for Long-Term
Cybersecurity, is contemplating new ways to help vulnerable civil society
organizations, journalists, dissidents, and other vulnerable groups
(including refugees) online.

We seek to hire a project scientist/research coordinator who will be
responsible for leading this effort. The research coordinator should
ideally have a background in cybersecurity and human rights—particularly in
regard to the needs of individuals vulnerable to targeted digital
surveillance—and be able to navigate the existing network of institutions,
organizations, and stakeholders operating in this space. Technical
expertise is also a plus. This is a short-term contract running either six
months at 50% or three months at 100%; the anticipated start date is as
soon as possible.

We are also still looking for an Events Coordinator to assist with events
for us and the School of Information.

For more on both roles, and links to apply, please see:
https://cltc.berkeley.edu/2017/02/01/work-for-cltc-project-scientist-events-
coordinator-wanted/. If you can help spread the word, I'd be extremely
grateful.

Thanks again,
Betsy
-- 
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] Happy birthday, Ralph Merkle!

[Yosem Companys]

From: Dave Horsfall 

Ralph Merkle, co-inventor of public key crypto, was born today in 1952.
Do you buy things online, with your credit card?  Then you can thank Ralph
Merkle for making it reasonably safe; he also invented crypto hashing.

(Notice that I said "reasonably" safe; it's always a risk.)

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."
-- 
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] How to make the Internet secure

[carlo von lynX]

Hello Phillip, nice reading your feedback.

On Wed, Feb 01, 2017 at 03:21:52PM -0500, Phillip Hallam-Baker wrote:
> ​I believe that mail, chat, voice, video, blog comments and mailing lists
> are all separate messaging modalities that need to be addressed in any
> replacement scheme. However, there is no reason why it should not be
> possible ​to support all of these modalities in a single message format.

Exactly. That's what we are working on.

> ​Facebook is not just a messaging infrastructure. It is also an
> infrastructure that allows social networks to be defined, published and
> applied. The main objection I have to FB is that it is walled garden.

secushare is a distributed multicast system without central nodes,
it intends to recreate a featureset like FB, Skype, Whatsapp
fully under control of the participants - no walled garden.

> Establishing a uniform identifier that has unambiguous meaning across
> domains is the key to breaking up walled gardens.

The complex operation is how to do next-gen routing from Alice
to Bob when all you know is Bob's public key address. Most
solutions route across a distributed hashtable, then optimize
such route if in-between nodes are optional. Netheads (the new
bellheads) would say, but you are still using IP - but the
meshheads say no, we are running an overlay over IP but our
architecture works also without, for instance with ad-hoc wifi.
So, akin to the historic bellheads vs netheads dispute,
this is the age of netheads vs meshheads.

> ​The reason for not using public keys is security. I want identifiers to be
> stable for long lengths of time, potentially a lifetime. It should be
> possible to rotate public keys on a weekly basis without cost to the user.

Excuse me, but you seem to be conflating PGP's need for key rotation
in order to achieve a poor man's forward secrecy with the use of public
keys for identification. Modern crypto systems would not architect it
this way. Our architecture is more like this:

master key per identity (kept offline, on a sheet of paper)
--> device key (in case a device of yours gets stolen)
--> ongoing ratchets (axolotl-style forward secrecy)

There are also peer keys. Looking up a person's device key provides
you with a route to a rendez-vous peer. That peer may be the person's
current computer, but it might aswell be the end-point of an onion
circuit. This way, looking up a person doesn't necessarily expose
that person's actual peer, and the peer keys can change as frequently
as desired. Thus, there is no need to rotate the device key itself.
Also, within the conversation there is no need to rotate the key,
because the ratchet is advanced automatically while you speak. The 
master key is needed only to be able to revoke a device key that 
may have gotten lost or stolen, that's why it can be kept on paper,
on external storage or be split over multiple parties.

Any identifier, which is not itself a public key, needs a way to
be mapped to a public key - and that is always an attack vector,
so I'm skeptical about that approach.

> UDF fingerprints can be taken of any data object. They are used in the Mesh
> to provide a unique identifier for the signature key of a master profile
> that represents a user's personal root of trust.​ The intention is to
> permit these to be offline keys that do not need to be used very often and
> may well be secured by multi-party key splitting.

Alright, so the intention is similar and the extra look-up
mechanism uses fingerprints instead of the public keys
themselves.

> ​The point of using fingerprints is to provide a baseline which needs no
> further validation or external trust sources that can be referenced by the
> infrastructures that build on top of it. Use of nicknames, etc is a very
> good idea. But just as the Internet protocols are ultimately built on IP as
> the basic unit of interchange for packets, there needs to be a basic unit
> for trust.
> ​

Yup.

> ​No.​ I am using a completely different approach using a form of
> cryptography developed by Matt Blaze in the 1990s that allows end to end
> encryption when using traditional client-server architectures.

gnunet has different protocols for different purposes. End-to-end
encrypted tunnels with axolotl-style forward secrecy are handled
by the CADET protocol. So you should be able to do what you are
setting out to do with prismproof.

Excuse me adding a musing in that regard however: Traditional 
client-server architectures introduce de-anonymization vulne-
rabilities by design, also they enable a digital equivalence of 
rich vs poor inequality, when scalability is a feature that only 
the rich, the owners of clouds and content delivery networks can 
achieve. Distributed architectures can offload the weight of 
scalability to all the participants who want to consume a certain 
information item - this way cutting out the cloud business model 
on scalability, which the users pay for by allowing being tracked.

Re: [liberationtech] Invitation to Free Open Shared: A Conversation about Privacy in Asia with Malavika Jayaram (Feb. 2)

[Lucy Lynch]

On Wed, 1 Feb 2017, Jan Gerlach wrote:


Dear all

My apologies for cross-posting. I thought some folks on this list may be
interested in attending the following event in San Francisco tomorrow.

The Wikimedia Foundation has the pleasure of inviting you to join us on
Feb. 2, 2017 for a fascinating talk by Malavika Jayaram about Privacy in
Asia. Malavika is the inaugural Executive Director of the Digital Asia Hub
 in Hong Kong (incubated by the Berkman
Klein Center for Internet & Society at Harvard University), and will talk
about different concepts of privacy and identity in the Indian and larger
Asian contexts.

A practising lawyer and then academic, her most recent research interests
cover biometrics, identity and data ethics, and emerging questions around
AI. Her work also links privacy and anonymity online with questions around
freedom of expression, assembly and autonomy. Malavika has previously been
a fellow at the Berkman Klein Center and is on the Advisory Board of the
Electronic Privacy Information Center (EPIC).


Highly recommended if you can make it - Malavika is a deep thinker and
a compelling speaker and she gets the nuances of both privacy and 
identity. Her non-US perspective is major plus -




To attend in person, please RSVP at your earliest convenience at Eventbrite

. Here is some logistical info about the event:

  - Venue: Wikimedia Foundation, 149 New Montgomery St, San Francisco, CA.
  - Doors open at 6pm; talk starts at approx. 6.15pm. We will serve light
  refreshments.
  - Please RSVP
  

at
  your earliest convenience. Capacity is limited and registration closes on
  Feb. 1, 2017.
  - Attendees will be asked to register at the reception and show ID.
  - The talk will be streamed and recorded here
  . Please find more info
  about the series here
  .


Best,
Jan

==

Jan Gerlach
Public Policy Manager
Wikimedia Foundation
149 New Montgomery Street, 6th Floor
San Francisco, CA 94105
jgerl...@wikimedia.org
-- 
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 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] How to make the Internet secure

[Phillip Hallam-Baker]

On Wed, Feb 1, 2017 at 2:15 PM, carlo von lynX 
wrote:

> Coming from: Phillip Hallam-Baker 
> > One of the big problems I have found in trying to argue for ways we can
> > improve Internet security is that there are two camps. The
> incrementalists
> > will only look at solutions that provide an improvement on the status
> qujo
> > in one area and the perfectionists insist that any solution that does not
> > solve every possible problem isn't worth considering.
>
> Oh! Finally the clean-slate camp is acknowledged. Back when we
> participated at STRINT[1] there were only 3 of us proposing a
> clean-slate approach, and we were acknowledged in the final
> report with one or two lines of text.
>
> > How about we do both?
>
> Yes, indeed. But, please, don't call us perfectionists. Our only
> difference from the incrementalists is the awareness that the
> number of deficiencies in the current TCP/IP stack is so epic[2],
> it is A LOT LESS WORK to start with a new approach. From then on
> there is still plenty to be done and a lot to increment and
> improve, and we don't want to wait until we achieve perfection.
>

​The original email was sent to IETF.​

​IETF is currently working on a replacement for TCP called QUIC which runs
over UDP. This provides for multiple streams. There is also momentum behind
the JSON encoding approach.

My point is that I am not opposed to redesigning the application layer from
scratch. But I am not going to insist on it either. I am not offering an
either/or of incremental or start from scratch. I am saying that I can fix
the security problems in SMTP with S/MIME or OpenPGP in a framework that
then allows an easy transition to Next Gen Mail.




> > Also to save time:
> >
> > [...]
> >
> > * Yes, I need help, a lot of help
>
> Have a look at gnunet.org. The description you make (that I
> replaced with [...]) sounds like things that are already possible.
> gnunet started in 2003, so it may be slightly ahead of you...


​Again, that was simply for IETF consumption. Without the recitation of
goodness, the discussion inevitably gets dragged into the weeds by someone
insisting that I have not thought of X. When chances are I have thought of
X a great deal.​



> > OK so how is this possible?
> >
> > First observation is that we now have several protocols that provide
> users
> > with end to end security that are really easy to use. The only real
> problem
> > I have with those systems is that they operate inside walled gardens.
> They
> > are not going to be a replacement for email.
>
> Doing a replacement for email means doing a replacement for Facebook.
> Many people are avoiding to ever start using mail, since they can do
> it all on Facebook and the cumbersome aspects of mail are resolved
> (instead of having to deal with user@host addresses they just click
> on people). That's why secushare is working on distributed social
> networking over GNUnet which as a side effect brings about the kind
> of mail system we all should be using: Easier than Facebook, but
> absolutely privacy-preserving. And we're not the only project heading
> in that direction. There's also Patchwork, Briar...
>

​I believe that mail, chat, voice, video, blog comments and mailing lists
are all separate messaging modalities that need to be addressed in any
replacement scheme. However, there is no reason why it should not be
possible ​to support all of these modalities in a single message format.

​Facebook is not just a messaging infrastructure. It is also an
infrastructure that allows social networks to be defined, published and
applied. The main objection I have to FB is that it is walled garden.

Establishing a uniform identifier that has unambiguous meaning across
domains is the key to breaking up walled gardens.


> 2) Extend a direct trust model into the DNS
> >
> > We all know about TOR and onion routing. Well what if I could have an
> email
> > address that included my OpenPGP fingerprint? Well we can. Just use the
> > xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
> > and we can make the fingerprint the TLD:
> >
> > al...@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE
> >
> > [...]
>
> This sounds like an incremental approach to me. Why not simply do the
> routing by public key? Why not map the nickname or realname of a person
> to their public key using a mechanism like GNS? A lot less cumbersome...


​The reason for not using public keys is security. I want identifiers to be
stable for long lengths of time, potentially a lifetime. It should be
possible to rotate public keys on a weekly basis without cost to the user.

UDF fingerprints can be taken of any data object. They are used in the Mesh
to provide a unique identifier for the signature key of a master profile
that represents a user's personal root of trust.​ The intention is to
permit these to be offline keys that do not need to be used very often and
may well be 

[liberationtech] Invitation to Free Open Shared: A Conversation about Privacy in Asia with Malavika Jayaram (Feb. 2)

[Jan Gerlach]

Dear all

My apologies for cross-posting. I thought some folks on this list may be
interested in attending the following event in San Francisco tomorrow.

The Wikimedia Foundation has the pleasure of inviting you to join us on
Feb. 2, 2017 for a fascinating talk by Malavika Jayaram about Privacy in
Asia. Malavika is the inaugural Executive Director of the Digital Asia Hub
 in Hong Kong (incubated by the Berkman
Klein Center for Internet & Society at Harvard University), and will talk
about different concepts of privacy and identity in the Indian and larger
Asian contexts.

A practising lawyer and then academic, her most recent research interests
cover biometrics, identity and data ethics, and emerging questions around
AI. Her work also links privacy and anonymity online with questions around
freedom of expression, assembly and autonomy. Malavika has previously been
a fellow at the Berkman Klein Center and is on the Advisory Board of the
Electronic Privacy Information Center (EPIC).


To attend in person, please RSVP at your earliest convenience at Eventbrite

. Here is some logistical info about the event:

   - Venue: Wikimedia Foundation, 149 New Montgomery St, San Francisco, CA.
   - Doors open at 6pm; talk starts at approx. 6.15pm. We will serve light
   refreshments.
   - Please RSVP
   

at
   your earliest convenience. Capacity is limited and registration closes on
   Feb. 1, 2017.
   - Attendees will be asked to register at the reception and show ID.
   - The talk will be streamed and recorded here
   . Please find more info
   about the series here
   .


Best,
Jan

==

Jan Gerlach
Public Policy Manager
Wikimedia Foundation
149 New Montgomery Street, 6th Floor
San Francisco, CA 94105
jgerl...@wikimedia.org
-- 
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] VISIONS : Online debate on the regulation of technologies

[Yosem Companys]

From: Matthias Debievre 

VISIONS has united 20 european actors of the civic tech, the open source
movement and other digital actors in order to build together a political
project around new technologies.

Our debate on these subjects is open to all, we would be glad to have your
input : visions.consider.it

We discuss public research, digital commons, regulation of personal data,
algorithms and civic technologies and propose the tools to make it all
happen.

This debate is a basis for constructing a program that we will then
advocate together with the actors we have united and all that share our
views and want to join us.

We want to make the technological issues emerge in the public and political
debate by various events, communication and lobbying campaigns around this
program in order to engage citizens.

We would be glad if you could take part in the debate and spread it around
to people you believe should be interested, the more participants we have
the more strength we will have to bring a free and open technology !

Have a great day !

Matthias
-- 
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] How to make the Internet secure

[carlo von lynX]

Coming from: Phillip Hallam-Baker 
> One of the big problems I have found in trying to argue for ways we can
> improve Internet security is that there are two camps. The incrementalists
> will only look at solutions that provide an improvement on the status qujo
> in one area and the perfectionists insist that any solution that does not
> solve every possible problem isn't worth considering.

Oh! Finally the clean-slate camp is acknowledged. Back when we
participated at STRINT[1] there were only 3 of us proposing a
clean-slate approach, and we were acknowledged in the final
report with one or two lines of text.

> How about we do both?

Yes, indeed. But, please, don't call us perfectionists. Our only
difference from the incrementalists is the awareness that the
number of deficiencies in the current TCP/IP stack is so epic[2],
it is A LOT LESS WORK to start with a new approach. From then on
there is still plenty to be done and a lot to increment and
improve, and we don't want to wait until we achieve perfection.

Considering that there are already several implementations[3]
going in that direction and there is even a law proposal[4]
that depends on a clean slate approach in order to be *able* to
guarantee basic civil rights by technological means, not by the
good will of the authorities. Making the web respect 
constitutional by design is possible.[5]

[1] https://www.w3.org/2014/strint/papers/65.pdf
[2] http://secushare.org/broken-internet
[3] http://youbroketheinternet.org/map
[4] http://youbroketheinternet.org/#legislation
[5] http://www.w3.org/2014/privacyws/pp/Carlo.pdf

> Also to save time:
> 
> [...]
> 
> * Yes, I need help, a lot of help

Have a look at gnunet.org. The description you make (that I 
replaced with [...]) sounds like things that are already possible.
gnunet started in 2003, so it may be slightly ahead of you...

> OK so how is this possible?
> 
> First observation is that we now have several protocols that provide users
> with end to end security that are really easy to use. The only real problem
> I have with those systems is that they operate inside walled gardens. They
> are not going to be a replacement for email.

Doing a replacement for email means doing a replacement for Facebook.
Many people are avoiding to ever start using mail, since they can do
it all on Facebook and the cumbersome aspects of mail are resolved
(instead of having to deal with user@host addresses they just click
on people). That's why secushare is working on distributed social 
networking over GNUnet which as a side effect brings about the kind
of mail system we all should be using: Easier than Facebook, but
absolutely privacy-preserving. And we're not the only project heading
in that direction. There's also Patchwork, Briar...

Still other people like the idea of maintaining compatibility with
existing SMTP infrastructure. There are several ways to go about
that. pEp is pursuing one of them.

> There are three contributions made by the Mathematical Mesh:
> 
> 1) An infrastructure for managing and using client keypairs.
> 
> Adding cryptography to a protocol is actually quite easy when both parties
> have public keypairs. So if we have an infrastructure that allows a user to
> 'glue' all their devices together into a personal mesh such that they all
> have keypairs provisioned for each cryptographic purpose they might need
> them for, cryptography becomes really easy for the user.

That is accurate.

> 2) Extend a direct trust model into the DNS
> 
> We all know about TOR and onion routing. Well what if I could have an email
> address that included my OpenPGP fingerprint? Well we can. Just use the
> xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
> and we can make the fingerprint the TLD:
> 
> al...@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE
>
> [...]

This sounds like an incremental approach to me. Why not simply do the
routing by public key? Why not map the nickname or realname of a person
to their public key using a mechanism like GNS? A lot less cumbersome...

> 3) Use of Proxy Re-Encryption (Recryption)
>
> [...]

Not sure if what you describe is similar to the pubsub mechanism we
added to gnunet which is able to distribute (multicast TBD) website
content to all short-term and long-term subscribers. This way, there
never really is a traditional web server - the web is a continous
stream, or a set of files kept forever in a distributed mesh of nodes.
See [5] for details.

> Using recryption allows us to develop protocols in which Alice is able to
> publish a single encryption key but read her email on three different
> devices, each of which has a separate decryption key so that she can
> mitigate the risk if one of the devices is lost.

Interesting, so far we are working on automation of master keys.

> Once we have that infrastructure, all else becomes straightforward. My
> original goal with the Mesh was to make it easy to configure S/MIME and
> 

[liberationtech] How to make the Internet secure

[Yosem Companys]

From: Phillip Hallam-Baker 

One of the big problems I have found in trying to argue for ways we can
improve Internet security is that there are two camps. The incrementalists
will only look at solutions that provide an improvement on the status qujo
in one area and the perfectionists insist that any solution that does not
solve every possible problem isn't worth considering.

How about we do both?

Also to save time:

* Yes, I understand the deployment problem very well, I worked with the guy
who solved the network hypertext deployment problem after 20 years of
people failing.
* Yes, everything is end to end secure,
* Yes the transport is also secure to prevent metadata attacks.
* Yes it works with OpenPGP
* Yes it works with S/MIME
* Yes you can use it with SMTP/IMAP/POP
* Yes you can use it with Jabber
* No, you do not have to use a CA
* Yes, you may use a CA where a CA adds value
* Yes, I have considered the lock in problem
* Yes, you can bolt in your own trust model
* REST/HTTPS/JSON.
* AES/RSA/DiffieHelman, moving to CurveX for production.
* Yes it is unencumbered, apart from one part which will unlock this year.
* Yes I have a strategy for QRC
* No, it is not a walled garden
* Yes, you can adapt the system to use escrow cryptography but not without
the parties knowing so this is a frontdoor, not a backdoor.
* My employer sells endpoint protection systems, the Mesh is not a
substitute for endpoint protection, thank you for your interest.
* Reference code runs on Windows, Linux and should run on OSX. It is all
MIT license, so are the protocol compiler tools.

* Yes, it is easy to use. In fact it is exactly as easy to use as the
existing protocols because the user doesn't need to know that they are
doing security
* Yes it is easy to configure.
* Yes, I need help, a lot of help

OK so how is this possible?

First observation is that we now have several protocols that provide users
with end to end security that are really easy to use. The only real problem
I have with those systems is that they operate inside walled gardens. They
are not going to be a replacement for email.

Second is that public key cryptography is now cheap in terms of both cost
and performance. We couldn't do very interesting crypto in the 90s because
machines bogged


There are three contributions made by the Mathematical Mesh:

1) An infrastructure for managing and using client keypairs.

Adding cryptography to a protocol is actually quite easy when both parties
have public keypairs. So if we have an infrastructure that allows a user to
'glue' all their devices together into a personal mesh such that they all
have keypairs provisioned for each cryptographic purpose they might need
them for, cryptography becomes really easy for the user.

2) Extend a direct trust model into the DNS

We all know about TOR and onion routing. Well what if I could have an email
address that included my OpenPGP fingerprint? Well we can. Just use the
xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
and we can make the fingerprint the TLD:

al...@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE

This means, 'only send mail to this address in compliance with a policy
signed under the fingerprint MBTVK...' Said policy could be an OpenPGP key
or it could be a Mesh mail profile.

3) Use of Proxy Re-Encryption (Recryption)

HTTPS provides end to end encryption between the user's client and the web
site serving the content. Using Proxy Re-Encryption we can provide end to
end encryption between the content creator and the user's client. This is
the part of the system that will be locked until late this year, (not that
I am sure the patent is valid, why bother checking when it expires)

We all know that two key cryptography is better than one. It is better
because encryption and decryption are different functions and using
separate keys for separate functions allows these to be done by different
parties. Recryption is three key cryptography and it is better than two key
for the same exact reason.

Using recryption allows us to develop protocols in which Alice is able to
publish a single encryption key but read her email on three different
devices, each of which has a separate decryption key so that she can
mitigate the risk if one of the devices is lost.


Job one is making it easy to manage client side keys.

Once we have that infrastructure, all else becomes straightforward. My
original goal with the Mesh was to make it easy to configure S/MIME and
OpenPGP. David Clark asked me to add SSH which I immediately realized could
be the killer app because the big problem with configuring SSH is that if
you do it to a machine at a remote site, 1000 miles away and you screw up,
someone has to get on a plane to fix it.

However, any infrastructure that allows mail application to say 'here are
the encryption keys to use to send mail to me and when to use them' can
also say 'I accept JSON format nextgen mail'. So this is an 

Re: [liberationtech] Report: Messenger apps during humanitarian crises

[Andrés Leopoldo Pacheco Sanfuentes]

Adoption is the key, right after the election I started telling
activists to move to Signal, but of course FB and stuff are so easy
and accessible, and people in the US think they're "untouchable,"
well..

It's like Amy Goodman's longtime friend said on her election show:
"USA, welcome to most of the World!" he was talking about activists
having to take precautions against their government, national
applicable Constitution et alte notwithstanding..

Best Regards | Cordiales Saludos | Grato,

Andrés L. Pacheco Sanfuentes

+1 (347) 766-5008


On Wed, Feb 1, 2017 at 11:17 AM, Nathalie Marechal  wrote:
> The Signal protocol is the gold standard of general public messenging
> apps. There are some UX issues and high-risk users should proceed with
> extreme cauion at all times, but it is widely considered the most secure
> messenging app out there.
>
>
> --
> Nathalie Maréchal
> Doctoral Candidate, USC Annenberg School for Communication and Journalism
> Senior Research Fellow, Ranking Digital Rights
> marec...@usc.edu | @MarechalUSC | www.nathaliemarechal.net
> PGP - EB43 3CE8 A759 5419 52C0  2FF1 B721 C0BF 0F43 0663
>
> On 2/1/17 11:53 AM, Jay Cafasso wrote:
>> Does anyone know how secure Signal is as a messenger app?
>>
>>
>> Jay Cafasso
>> 12559 N400E
>> Wheatfield, IN 46392 USA
>> Cell: 219.816.0722
>> Fax: 610-673-8495
>> Home GPS - Lat 41.19509, Long -86.96737
>> SN# - 36508
>> CWOP - EW5446
>>
>> www.facebook.com/jay.cafasso.7
>> 
>> Robin Storm SIT - A WRN Ambassador
>>
>> "The last temptation is the greatest treason: To do the right deed for
>> the wrong reason."   Murder in the Cathedral - St. Thomas Becket.
>>
>> Skywarn® and the Skywarn® logo are registered trademarks of the National
>> Weather Service "used with permission".
>>
>> On Feb 1, 2017 09:22, "Steven Clift" > > wrote:
>>
>> See:
>> https://engn.it/appsreport
>> 
>> 
>>
>>
>> In some situations, messaging apps may be the only way that people
>> caught up in armed conflict or crises can communicate with family,
>> friends or humanitarian organisations. Many messaging apps have
>> features that could help humanitarian organisations to reach people
>> who would otherwise be impossible to contact, or to collect
>> information that would otherwise be inaccessible. This information
>> can save lives.
>>
>> Some humanitarian organisations have already started using messaging
>> apps to communicate with people and coordinate their activities –
>> and many others are thinking about it. But there’s still a lot that
>> we don’t know.
>>
>> How and why are people affected by crises or armed conflict actually
>> using messaging apps? When and how is it appropriate to introduce a
>> new technology that not everyone will be able to access? Could
>> communicating with people through these communication channels put
>> them at greater risk?
>>
>>
>>
>> --
>> 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 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 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] Report: Messenger apps during humanitarian crises

[Nathalie Marechal]

The Signal protocol is the gold standard of general public messenging
apps. There are some UX issues and high-risk users should proceed with
extreme cauion at all times, but it is widely considered the most secure
messenging app out there.


-- 
Nathalie Maréchal
Doctoral Candidate, USC Annenberg School for Communication and Journalism
Senior Research Fellow, Ranking Digital Rights
marec...@usc.edu | @MarechalUSC | www.nathaliemarechal.net
PGP - EB43 3CE8 A759 5419 52C0  2FF1 B721 C0BF 0F43 0663

On 2/1/17 11:53 AM, Jay Cafasso wrote:
> Does anyone know how secure Signal is as a messenger app?
> 
> 
> Jay Cafasso
> 12559 N400E
> Wheatfield, IN 46392 USA
> Cell: 219.816.0722
> Fax: 610-673-8495
> Home GPS - Lat 41.19509, Long -86.96737
> SN# - 36508
> CWOP - EW5446
> 
> www.facebook.com/jay.cafasso.7
> 
> Robin Storm SIT - A WRN Ambassador
> 
> "The last temptation is the greatest treason: To do the right deed for
> the wrong reason."   Murder in the Cathedral - St. Thomas Becket.
> 
> Skywarn® and the Skywarn® logo are registered trademarks of the National
> Weather Service "used with permission".
> 
> On Feb 1, 2017 09:22, "Steven Clift"  > wrote:
> 
> See:
> https://engn.it/appsreport
> 
> 
> 
> 
> In some situations, messaging apps may be the only way that people
> caught up in armed conflict or crises can communicate with family,
> friends or humanitarian organisations. Many messaging apps have
> features that could help humanitarian organisations to reach people
> who would otherwise be impossible to contact, or to collect
> information that would otherwise be inaccessible. This information
> can save lives.
> 
> Some humanitarian organisations have already started using messaging
> apps to communicate with people and coordinate their activities –
> and many others are thinking about it. But there’s still a lot that
> we don’t know.
> 
> How and why are people affected by crises or armed conflict actually
> using messaging apps? When and how is it appropriate to introduce a
> new technology that not everyone will be able to access? Could
> communicating with people through these communication channels put
> them at greater risk?
> 
> 
> 
> --
> 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 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] Report: Messenger apps during humanitarian crises

[Jay Cafasso]

Does anyone know how secure Signal is as a messenger app?


Jay Cafasso
12559 N400E
Wheatfield, IN 46392 USA
Cell: 219.816.0722
Fax: 610-673-8495
Home GPS - Lat 41.19509, Long -86.96737
SN# - 36508
CWOP - EW5446

www.facebook.com/jay.cafasso.7
Robin Storm SIT - A WRN Ambassador

"The last temptation is the greatest treason: To do the right deed for the
wrong reason."   Murder in the Cathedral - St. Thomas Becket.

Skywarn® and the Skywarn® logo are registered trademarks of the National
Weather Service "used with permission".

On Feb 1, 2017 09:22, "Steven Clift"  wrote:

See:
https://engn.it/appsreport


In some situations, messaging apps may be the only way that people caught
up in armed conflict or crises can communicate with family, friends or
humanitarian organisations. Many messaging apps have features that could
help humanitarian organisations to reach people who would otherwise be
impossible to contact, or to collect information that would otherwise be
inaccessible. This information can save lives.

Some humanitarian organisations have already started using messaging apps
to communicate with people and coordinate their activities – and many
others are thinking about it. But there’s still a lot that we don’t know.

How and why are people affected by crises or armed conflict actually using
messaging apps? When and how is it appropriate to introduce a new
technology that not everyone will be able to access? Could communicating
with people through these communication channels put them at greater risk?



--
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 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] Liberationtech List Reminder

[Yosem Companys]

Thanks, Bram. Noted.

In the spirit of democracy, we are going to compile all the feedback we
get, tabulate it, and send it to the list once it's done. Then, we will
start working on some of the projects and hopefully subscribers will
volunteer whatever they can to make them happen.

On Wed, Feb 1, 2017 at 7:17 AM, Bram Wets  wrote:

> Hi Yosem and all,
>
> Thanks for the invitation to share some ideas for Liberationtech.
>
> Idea 1:
> An idea list where the Liberationtech community can post ideas for
> projects, upvote (and downvote) them, put your name with an idea to
> contribute.
> This would facilitate your call for ideas/projects ;-)
> I actually like the format of software bugtracking. It maybe can be used
> for such an idea list. Or a github-like structure with pullrequests...
>
> Idea 2:
> An overview of tips, good practices, tools and apps for secure
> communication and digital privacy. And the organisations and platforms that
> work on this topic.
> Yes, there is a lot out there and some organizations already have done
> terrific work. So the focus has to be on the overview, not on doing all
> there work over again.
> Additionally we can add good practices in how to reach people and teach
> them those privacy tools.
>
> Best regards,
> Bram Wets
>
>
> Bram Wets
> co-founder
> PRIVACY TRAINING CENTER
> www.privacytraining.org
>
> Unencrypted e-mail can be read by anyone! Talk to me in private using
> encryption. Here's my PGP public key: https://pgp.mit.edu/pks/
> lookup?op=get=0x919C9EBCA0430B96
>
> Yosem Companys  schreef op 1 februari 2017
> 06:00:57 CET:
>
>> We are Stanford Liberatiiontech.
>>
>> Our home page is here: http://cddrl.fsi.stanford.edu/libtech.
>>
>> To sign up to our 4K-strong mailing list, click here: https://mailman.
>> stanford.edu/mailman/listinfo/liberationtech.
>>
>> We have also curated a list of Liberationtech content at
>> https://twitter.com/Liberationtech.
>>
>> If you prefer to read our list as a newspaper, you could always check our
>> Paper.li account: http://paper.li/Liberationtech#/
>>
>> Our Liberationtech blog has been dead for a while, but we are working on
>> reviving it. If you are interested in helping out, please let us know.
>>
>> We also have a series of listservs on topics related to Liberationtech.
>> The most important lists are the following:
>>
>>- Events: https://mailman.stanford.edu/mailman/listinfo/
>>liberationtech-events
>>- Jobs: https://mailman.stanford.edu/mailman/listinfo/
>>liberationtech-jobs
>>- CfP: https://mailman.stanford.edu/mailman/listinfo/
>>liberationtech-cfp
>>
>> For the aforementioned lists, we try to compile a list of all events, job
>> opportunities, and call for papers related to Liberationtech from all over
>> the world.
>>
>> It's not a comprehensive list, so your assistance would be helpful. If
>> you hear of a job, event, or cfp that would be of benefit to Liberationtech
>> subscribers, please let us know.
>>
>> Finally, we want to take Liberationtech to the next level. What that
>> means, we don't know. But the world has changed a lot since we started back
>> in 2008: Censorship is on the rise. Internet freedom is on the decline. And
>> we have become much more of a community of hackers and cybersecurity
>> professionals who seek to protect vulnerable communities around the world.
>>
>> So if you have ideas of projects you would like to see us take on, please
>> let us know. We want the Liberationtech community to drive the process. Any
>> idea is welcome. Dream big or small. Just let us know how you think we can
>> best help.
>>
>> Thanks,
>> Yosem
>> (One of the moderators)
>>
>
-- 
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] Report: Messenger apps during humanitarian crises

[Steven Clift]

See:
https://engn.it/appsreport


In some situations, messaging apps may be the only way that people caught
up in armed conflict or crises can communicate with family, friends or
humanitarian organisations. Many messaging apps have features that could
help humanitarian organisations to reach people who would otherwise be
impossible to contact, or to collect information that would otherwise be
inaccessible. This information can save lives.

Some humanitarian organisations have already started using messaging apps
to communicate with people and coordinate their activities – and many
others are thinking about it. But there’s still a lot that we don’t know.

How and why are people affected by crises or armed conflict actually using
messaging apps? When and how is it appropriate to introduce a new
technology that not everyone will be able to access? Could communicating
with people through these communication channels put them at greater risk?
-- 
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] Liberationtech List Reminder

[Bram Wets]

Hi Yosem and all, 

Thanks for the invitation to share some ideas for Liberationtech. 

Idea 1:
An idea list where the Liberationtech community can post ideas for projects, 
upvote (and downvote) them, put your name with an idea to contribute. 
This would facilitate your call for ideas/projects ;-) 
I actually like the format of software bugtracking. It maybe can be used for 
such an idea list. Or a github-like structure with pullrequests... 

Idea 2:
An overview of tips, good practices, tools and apps for secure communication 
and digital privacy. And the organisations and platforms that work on this 
topic. 
Yes, there is a lot out there and some organizations already have done terrific 
work. So the focus has to be on the overview, not on doing all there work over 
again. 
Additionally we can add good practices in how to reach people and teach them 
those privacy tools.

Best regards, 
Bram Wets 


Bram Wets
co-founder
PRIVACY TRAINING CENTER
www.privacytraining.org

Unencrypted e-mail can be read by anyone! Talk to me in private using 
encryption. Here's my PGP public key: 
https://pgp.mit.edu/pks/lookup?op=get=0x919C9EBCA0430B96

Yosem Companys  schreef op 1 februari 2017 06:00:57 CET:
>We are Stanford Liberatiiontech.
>
>Our home page is here: http://cddrl.fsi.stanford.edu/libtech.
>
>To sign up to our 4K-strong mailing list, click here:
>https://mailman.stanford.edu/mailman/listinfo/liberationtech.
>
>We have also curated a list of Liberationtech content at
>https://twitter.com/Liberationtech.
>
>If you prefer to read our list as a newspaper, you could always check
>our
>Paper.li account: http://paper.li/Liberationtech#/
>
>Our Liberationtech blog has been dead for a while, but we are working
>on
>reviving it. If you are interested in helping out, please let us know.
>
>We also have a series of listservs on topics related to Liberationtech.
>The
>most important lists are the following:
>
>   - Events:
>   https://mailman.stanford.edu/mailman/listinfo/liberationtech-events
>- Jobs:
>https://mailman.stanford.edu/mailman/listinfo/liberationtech-jobs
>- CfP: https://mailman.stanford.edu/mailman/listinfo/liberationtech-cfp
>
>For the aforementioned lists, we try to compile a list of all events,
>job
>opportunities, and call for papers related to Liberationtech from all
>over
>the world.
>
>It's not a comprehensive list, so your assistance would be helpful. If
>you
>hear of a job, event, or cfp that would be of benefit to Liberationtech
>subscribers, please let us know.
>
>Finally, we want to take Liberationtech to the next level. What that
>means,
>we don't know. But the world has changed a lot since we started back in
>2008: Censorship is on the rise. Internet freedom is on the decline.
>And we
>have become much more of a community of hackers and cybersecurity
>professionals who seek to protect vulnerable communities around the
>world.
>
>So if you have ideas of projects you would like to see us take on,
>please
>let us know. We want the Liberationtech community to drive the process.
>Any
>idea is welcome. Dream big or small. Just let us know how you think we
>can
>best help.
>
>Thanks,
>Yosem
>(One of the moderators)
-- 
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.