Re: [liberationtech] a privacy preserving and resilient social network)

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.29 01.52, Alireza Mahdian wrote:
> I really hope all your other facts are not based on this link you 
> sent. as Matt rightfully put it we don't know the kind of cipher 
> that was used it could have been a  very primitive one. you are 
> making a very bold statement based on a very incomplete data.

Of course not.  Frankly, I'm not worried about cryptanalysis.  If the
easiest way into a system is by breaking crypto, we've succeeded beyond
our wildest expectations.  Snowden said, in passing, that strong
crypto does in fact work; he also said that the terrible state of host
security means that this is almost never a problem for NSA.

> As for your recommended approach of not releasing research
> softwares to regular users you have to know that MANY of the
> current technologies that are being used have their roots in
> research projects. You mention Tor and so many other applications
> and ALL of them have started as a research project in academia.

Yes, they have.  The accepted standard of care in this community is that
software should not be recommended to real users for use with real data
if it is targeting high-risk use cases (which an intentionally
privacy-preserving social network designed for the Iranian context
necessarily is) until it has undergone community review and focused
security analysis from professional analysts.  Not everything in the
community is at that point yet, but we're working on getting there.

Releasing code that's clearly marked as alpha and likely dangerous is
fine, as long as you make it clear to users that this code may not, in
fact, provide any of the properties it claims to provide until such
point as it's had an appropriate degree of review.

While we can't do anything about projects coming from outside academia,
I'd love to see IRBs start to enforce this for academic projects.  It'd
likely save lives.

> My claim is that MyZone is privacy preserving and I stand by it. I
>  never claimed that it is providing anonymity and in fact I have 
> pointed out that it does not even aim for it. As the creator of 
> MyZone I did not felt the need for unlinkability as deniability is
>  provided to a needed degree.

And what I'm telling you is that on the basis of what we've seen coming
back from the field, not to mention the documents we've seen confirming
things in the past few weeks, THERE IS NO SUCH THING AS PRIVACY WITHOUT
UNLINKABILITY.

The game is in traffic analysis.  Most of what's interesting about a
conversation comes from traffic analysis.  Post-hoc deniability of
specific messages is not a useful property in evading negative security
outcomes, because the suspicion of being part of the set of people who
could have sent a message is more than sufficient to justify picking
someone up in high-risk scenarios, and in lower-risk scenarios is likely
insufficient to convince a judge.

We as a community have a fundamentally backwards idea of what privacy
means (or so we now see).  Privacy does not mean confidentiality, it
means confidentiality and unlinkability at a minimum, and in many
regimes, it means confidentiality, unlinkability, and undetectability
(because if you live somewhere where using crypto gets you killed, Tor
can't help you).

By the standards that we've been applying as a community previously,
while I stand by my comments on research software, you're not doing
bad (although the devil is in the details); the problem is those
standards were wrong.

> You probably are not going to give my app even a try but I would 
> certainly give your "Bullet proof" solution if it ever sees the 
> light of the day a try and read its documentation in full before 
> criticizing it.

I don't know where this "bullet proof" nonsense comes from -- that's not
a claim I'd make; it's childish, like talking about "military-grade
encryption"; we can do better.

I've seen a dozen architectures proposed this week for different kinds
of privacy-preserving systems.  I'm not going to install all of them and
read all of their documentation; I have work to do.  I'm happy to
provide feedback on some of them when I have time.

I'm taking the time to provide more detailed feedback on this one
because I think we need to, as a community, have a conversation around
the properties that we design solutions for.

> I have tried SO MANY of these solutions that you mentioned in a
> very restrictive environment (I come from Iran and I have first
> hand experience on whatever you are mentioning here) and trust me
> they are often so slow (you have to consider dial up bandwidth)
> that you prefer to avoid them in the first place.

I understand the bandwidth limitations of many connections in a place
like Iran.  I know Tor is too slow right now.  I'm not trying to excuse
it.  What I'm saying is that we should be working on building systems
that can compose with it and working on making it faster, or working on
building alternate systems that provide the 

Re: [liberationtech] US wiretap statistics (was re: a privacy preserving and resilient social network)

[Alireza Mahdian]

On Jun 29, 2013, at 12:26 AM, Ali-Reza Anghaie  wrote:

> On Sat, Jun 29, 2013 at 1:52 AM, Alireza Mahdian
>  wrote:
>> I really hope all your other facts are not based on this link you sent. as
>> Matt rightfully put it we don't know the kind of cipher that was used it
>> could have been a  very primitive one. you are making a very bold statement
>> based on a very incomplete data. it is as if you are claiming that if one
> 
> Actually the link and data do not say - nor was it her assertion -
> that they attacked the crypto itself. And that goes back to the whole
> of her original response (which was a broader call to arms /
> perspective). Many are often missing the broader picture on how these
> systems are attacked by capable bodies and Governments if that is,
> indeed, one of the adversary bodies you've identified.
> 
>> pointed out that it does not even aim for it. As the creator of MyZone I did
>> not felt the need for unlinkability as deniability is provided to a needed
>> degree. You probably are not going to give my app even a try but I would
>> certainly give your "Bullet proof" solution if it ever sees the light of the
>> day a try and read its documentation in full before criticizing it. I have
> 
> I think you're jumping to conclusions much the same way you suggest
> any question to you is. Your first response to any input was "this is
> to prevent modifications that would render it as a malware" in regards
> to the Open Source aspect. Which makes no sense - at all. It's not
> even defensible. You could include a license with your codebase that
> has nothing to do with the offered service as-is.
> 

> So take a step back and, seriously, ask yourself did you want input or
> did you just want praise?

*** This is a very unfair thing to say that's all I am going to respond to 
your message. Cheers Ali. 

>> tried SO MANY of these solutions that you mentioned in a very restrictive
>> environment (I come from Iran and I have first hand experience on whatever
>> you are mentioning here) and trust me they are often so slow (you have to
>> consider dial up bandwidth) that you prefer to avoid them in the first
>> place. I will consider any "constructive" criticism of my work and
>> appreciate it very much but telling me that I have solved the "wrong"
>> problem is just your opinion. I certainly wouldn't consider my self such
>> expert enough in the field to make a blunt statement like that towards
>> anybody's work. I will not respond to any of your comments from this point
>> on until I see reasonable signs that you have read my thesis and at the very
>> least understand my design choices. I owe you a thank you for the time you
>> have put to write those emails regarding my work.
> 
> Wait - are you telling someone not to make such bold statements while
> making.. wait for it.. a number of your own?
> 
> Also - as an Iranian transplant with continued involvement I'm not at
> all sure you can relate those circumstances as comprehensive to the
> rest of the world. Actually - I'd say you flat-out can't. It's not
> even that homogenous within Iran anymore.
> 
> Usability is a BIG debate point on the list - often - with some of us
> (myself included) feeling that falling within a broken system and
> being covered by regular "noise" is often better than an unusable
> system.
> 
> However - going back to what you started with - you asserted a context
> within current events and against Government. That has a big weighty
> goal attached to it and raises hackles.
> 
> So let's all start over.
> 
> Hello Alireza. I'm.. err. Ali-Reza. Congratulations on your recent
> Doctorate and welcome to Libtech.
> 
> Cheers, -Ali
> 
> 
>> 
>> On Jun 28, 2013, at 11:28 PM, Matt Johnson  wrote:
>> 
>> Well that is good news, thanks for the pointer!
>> 
>> Now all we need is for the court to report what cipher and which
>> encryption tools were used...
>> 
>> --
>> Matt Johnson
>> 
>> 
>> 
>> On Fri, Jun 28, 2013 at 10:21 PM, Eleanor Saitta  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> On 2013.06.29 01.18, Matt Johnson wrote:
>> 
>> " Encryption meaningfully prevented a wiretap for the first time
>> ever in *2012* (or so we're told, for non-intelligence domestic US
>> wiretaps), and has only ever worked five times."
>> 
>> What are you referring to? Do you have a pointer to more
>> information? I am very curious.
>> 
>> 
>> http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5
>> 
>> E.
>> 
>> - --
>> Ideas are my favorite toys.
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.17 (MingW32)
>> 
>> iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU
>> nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq
>> =Lw8s
>> -END PGP SIGNATURE-
>> 
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/l

Re: [liberationtech] US wiretap statistics (was re: a privacy preserving and resilient social network)

[Ali-Reza Anghaie]

On Sat, Jun 29, 2013 at 1:52 AM, Alireza Mahdian
 wrote:
> I really hope all your other facts are not based on this link you sent. as
> Matt rightfully put it we don't know the kind of cipher that was used it
> could have been a  very primitive one. you are making a very bold statement
> based on a very incomplete data. it is as if you are claiming that if one

Actually the link and data do not say - nor was it her assertion -
that they attacked the crypto itself. And that goes back to the whole
of her original response (which was a broader call to arms /
perspective). Many are often missing the broader picture on how these
systems are attacked by capable bodies and Governments if that is,
indeed, one of the adversary bodies you've identified.

> pointed out that it does not even aim for it. As the creator of MyZone I did
> not felt the need for unlinkability as deniability is provided to a needed
> degree. You probably are not going to give my app even a try but I would
> certainly give your "Bullet proof" solution if it ever sees the light of the
> day a try and read its documentation in full before criticizing it. I have

I think you're jumping to conclusions much the same way you suggest
any question to you is. Your first response to any input was "this is
to prevent modifications that would render it as a malware" in regards
to the Open Source aspect. Which makes no sense - at all. It's not
even defensible. You could include a license with your codebase that
has nothing to do with the offered service as-is.

So take a step back and, seriously, ask yourself did you want input or
did you just want praise?

> tried SO MANY of these solutions that you mentioned in a very restrictive
> environment (I come from Iran and I have first hand experience on whatever
> you are mentioning here) and trust me they are often so slow (you have to
> consider dial up bandwidth) that you prefer to avoid them in the first
> place. I will consider any "constructive" criticism of my work and
> appreciate it very much but telling me that I have solved the "wrong"
> problem is just your opinion. I certainly wouldn't consider my self such
> expert enough in the field to make a blunt statement like that towards
> anybody's work. I will not respond to any of your comments from this point
> on until I see reasonable signs that you have read my thesis and at the very
> least understand my design choices. I owe you a thank you for the time you
> have put to write those emails regarding my work.

Wait - are you telling someone not to make such bold statements while
making.. wait for it.. a number of your own?

Also - as an Iranian transplant with continued involvement I'm not at
all sure you can relate those circumstances as comprehensive to the
rest of the world. Actually - I'd say you flat-out can't. It's not
even that homogenous within Iran anymore.

Usability is a BIG debate point on the list - often - with some of us
(myself included) feeling that falling within a broken system and
being covered by regular "noise" is often better than an unusable
system.

However - going back to what you started with - you asserted a context
within current events and against Government. That has a big weighty
goal attached to it and raises hackles.

So let's all start over.

Hello Alireza. I'm.. err. Ali-Reza. Congratulations on your recent
Doctorate and welcome to Libtech.

Cheers, -Ali


>
> On Jun 28, 2013, at 11:28 PM, Matt Johnson  wrote:
>
> Well that is good news, thanks for the pointer!
>
> Now all we need is for the court to report what cipher and which
> encryption tools were used...
>
> --
> Matt Johnson
>
>
>
> On Fri, Jun 28, 2013 at 10:21 PM, Eleanor Saitta  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2013.06.29 01.18, Matt Johnson wrote:
>
> " Encryption meaningfully prevented a wiretap for the first time
> ever in *2012* (or so we're told, for non-intelligence domestic US
> wiretaps), and has only ever worked five times."
>
> What are you referring to? Do you have a pointer to more
> information? I am very curious.
>
>
> http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5
>
> E.
>
> - --
> Ideas are my favorite toys.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU
> nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq
> =Lw8s
> -END PGP SIGNATURE-
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahd...@gmail.com
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu

Re: [liberationtech] US wiretap statistics (was re: a privacy preserving and resilient social network)

[Alireza Mahdian]

I really hope all your other facts are not based on this link you sent. as Matt 
rightfully put it we don't know the kind of cipher that was used it could have 
been a  very primitive one. you are making a very bold statement based on a 
very incomplete data. it is as if you are claiming that if one cipher can be 
broken all the other ciphers are breakable as well (theoretically speaking all 
ciphers are breakable given unlimited amount of time). As for all your previous 
comments it just suffices to say that you will understand a lot more about my 
proposal if you read my thesis in entirety. 

As for your recommended approach of not releasing research softwares to regular 
users you have to know that MANY of the current technologies that are being 
used have their roots in research projects. You mention Tor and so many other 
applications and ALL of them have started as a research project in academia. My 
claim is that MyZone is privacy preserving and I stand by it. I never claimed 
that it is providing anonymity and in fact I have pointed out that it does not 
even aim for it. As the creator of MyZone I did not felt the need for 
unlinkability as deniability is provided to a needed degree. You probably are 
not going to give my app even a try but I would certainly give your "Bullet 
proof" solution if it ever sees the light of the day a try and read its 
documentation in full before criticizing it. I have tried SO MANY of these 
solutions that you mentioned in a very restrictive environment (I come from 
Iran and I have first hand experience on whatever you are mentioning here) and 
trust me they are often so slow (you have to consider dial up bandwidth) that 
you prefer to avoid them in the first place. I will consider any "constructive" 
criticism of my work and appreciate it very much but telling me that I have 
solved the "wrong" problem is just your opinion. I certainly wouldn't consider 
my self such expert enough in the field to make a blunt statement like that 
towards anybody's work. I will not respond to any of your comments from this 
point on until I see reasonable signs that you have read my thesis and at the 
very least understand my design choices. I owe you a thank you for the time you 
have put to write those emails regarding my work. 

On Jun 28, 2013, at 11:28 PM, Matt Johnson  wrote:

> Well that is good news, thanks for the pointer!
> 
> Now all we need is for the court to report what cipher and which
> encryption tools were used...
> 
> --
> Matt Johnson
> 
> 
> 
> On Fri, Jun 28, 2013 at 10:21 PM, Eleanor Saitta  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> On 2013.06.29 01.18, Matt Johnson wrote:
>>> " Encryption meaningfully prevented a wiretap for the first time
>>> ever in *2012* (or so we're told, for non-intelligence domestic US
>>> wiretaps), and has only ever worked five times."
>>> 
>>> What are you referring to? Do you have a pointer to more
>>> information? I am very curious.
>> 
>> http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5
>> 
>> E.
>> 
>> - --
>> Ideas are my favorite toys.
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.17 (MingW32)
>> 
>> iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU
>> nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq
>> =Lw8s
>> -END PGP SIGNATURE-
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech


--
Alireza Mahdian
Department of Computer Science
University of Colorado at Boulder
Email: alireza.mahd...@gmail.com

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] US wiretap statistics (was re: a privacy preserving and resilient social network)

[Matt Johnson]

Well that is good news, thanks for the pointer!

Now all we need is for the court to report what cipher and which
encryption tools were used...

--
Matt Johnson



On Fri, Jun 28, 2013 at 10:21 PM, Eleanor Saitta  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2013.06.29 01.18, Matt Johnson wrote:
>> " Encryption meaningfully prevented a wiretap for the first time
>> ever in *2012* (or so we're told, for non-intelligence domestic US
>> wiretaps), and has only ever worked five times."
>>
>> What are you referring to? Do you have a pointer to more
>> information? I am very curious.
>
> http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5
>
> E.
>
> - --
> Ideas are my favorite toys.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU
> nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq
> =Lw8s
> -END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] US wiretap statistics (was re: a privacy preserving and resilient social network)

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.29 01.18, Matt Johnson wrote:
> " Encryption meaningfully prevented a wiretap for the first time
> ever in *2012* (or so we're told, for non-intelligence domestic US
> wiretaps), and has only ever worked five times."
> 
> What are you referring to? Do you have a pointer to more
> information? I am very curious.

http://www.uscourts.gov/Statistics/WiretapReports/wiretap-report-2012.aspx#sa5

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHObssACgkQQwkE2RkM0wpJvgD9FMiYpwatSomo+sCOr2JQxPnU
nUC3+yZzHJ1Uyh1+23gA/0tijTIRQnh5kZzIP9Fw6uUm9JiweuRXSv4mHhhPC/Gq
=Lw8s
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Matt Johnson]

" Encryption meaningfully prevented a wiretap
for the first time ever in *2012* (or so we're told, for
non-intelligence domestic US wiretaps), and has only ever worked five
times."

What are you referring to? Do you have a pointer to more information?
I am very curious.

--
Matt Johnson



On Fri, Jun 28, 2013 at 10:13 PM, Eleanor Saitta  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2013.06.28 13.14, Jonathan Wilkes wrote:
>> Just curious, Eleanor-- once you implement your "bullet-proof"
>> privacy- preserving network, how do you plan to make the user
>> experience at all tolerable without automated mirroring like what
>> this developer has written and tested?
>
> That's going to depend on the system and the situation.  With Briar,
> we do things that are fairly similar, but we also make a point of
> taking unlinkability seriously.  Research code into social mirroring?
>  Awesome.  Protocol design intended for deployment that ignores
> unlinkability?  Not awesome.
>
> More specifically, some of this is unrelated to Alireza's proposal --
> I'm using it to illustrate the kinds of shifts that we need to
> undertake in our thinking here.  It's not about *this* tool, it's
> about every tool we build.  To that end, I suppose I do owe them a bit
> of an apology -- really, it's nothing personal about this tool (and
> certainly not anything about them, although I hope that's obvious).
> It's all of us and everything that needs to shift.
>
> Finally, I should note in passing, I'm not trying to make something
> "bullet-proof".  I care about security outcomes, not security
> theories.  What I want to see is our tools reaching the point where
> we're actually playing the game, because right now, we're not even on
> the road to the stadium.  Encryption meaningfully prevented a wiretap
> for the first time ever in *2012* (or so we're told, for
> non-intelligence domestic US wiretaps), and has only ever worked five
> times.  This is pathetic and terrifying.  Let's become an actual problem.
>
> E.
>
> - --
> Ideas are my favorite toys.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlHObREACgkQQwkE2RkM0wrI1AD/aSD1R4PCjLVMxJGfY2s1CDLP
> 0EOaFBGkh3daJdsJ6moA/0DHZM5CoIwHpUN/3O6cx7HdKSmE6VcqxTsnI6+f9kt+
> =v8og
> -END PGP SIGNATURE-
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 13.14, Jonathan Wilkes wrote:
> Just curious, Eleanor-- once you implement your "bullet-proof"
> privacy- preserving network, how do you plan to make the user
> experience at all tolerable without automated mirroring like what
> this developer has written and tested?

That's going to depend on the system and the situation.  With Briar,
we do things that are fairly similar, but we also make a point of
taking unlinkability seriously.  Research code into social mirroring?
 Awesome.  Protocol design intended for deployment that ignores
unlinkability?  Not awesome.

More specifically, some of this is unrelated to Alireza's proposal --
I'm using it to illustrate the kinds of shifts that we need to
undertake in our thinking here.  It's not about *this* tool, it's
about every tool we build.  To that end, I suppose I do owe them a bit
of an apology -- really, it's nothing personal about this tool (and
certainly not anything about them, although I hope that's obvious).
It's all of us and everything that needs to shift.

Finally, I should note in passing, I'm not trying to make something
"bullet-proof".  I care about security outcomes, not security
theories.  What I want to see is our tools reaching the point where
we're actually playing the game, because right now, we're not even on
the road to the stadium.  Encryption meaningfully prevented a wiretap
for the first time ever in *2012* (or so we're told, for
non-intelligence domestic US wiretaps), and has only ever worked five
times.  This is pathetic and terrifying.  Let's become an actual problem.

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHObREACgkQQwkE2RkM0wrI1AD/aSD1R4PCjLVMxJGfY2s1CDLP
0EOaFBGkh3daJdsJ6moA/0DHZM5CoIwHpUN/3O6cx7HdKSmE6VcqxTsnI6+f9kt+
=v8og
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 21.02, Jonathan Wilkes wrote:
> That's anecdotal evidence.
> 
> The vast majority of the smartphone userbase just learned the word
> "meta-data" a few weeks ago.  The news about the scope of NSA
> surveillance is revelatory to non-specialists. The scope of the
> surveillance is unprecendented.  There are not yet any
> peer-reviewed articles on how these revelations affect users'
> relationship to their smartphones, nor how those relationships may
> change as they more fully understand the dangers of wide-net 
> surveillance.

It is, in fact, anecdotal evidence.  We may see a sudden and massive
complete technology shift back ten years to where no one carries a
smartphone.

This is profoundly improbable, to a degree where I am willing to
discard it out of hand, in part because smartphones have in very real
ways changed our cities and the way we live in them.  I can see a
world where we demand very different privacy and security guarantees
from our phones -- I hope we're living in it.  I cannot see a world
where we just turn them all off forever.

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHOa5QACgkQQwkE2RkM0wpmBQEAjuohsEDXPQNYgM+hai7koQJO
TPBsbiXdMh7BHR64g6UA/0KhreuKlWXXOMGGFW0ne3AgtUnMFckqQ8rmNOVy8Qji
=wxXR
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 15.20, Yosem Companys wrote:
> I want to commend Alirezza.
> 
> It's very important for us to welcome all those who design and
> conduct research on liberation technologies,  I commend him for
> trying to build something of importance to all of us and dealing
> with the inevitable issues that result from doing so.
> 
> One of the great things of this list is that others with 
> liberationtech experience are kind enough to give feedback to
> folks like Alirezza.
> 
> As always, however, let's try to keep the discussion constructive. 
> Rather than simply point out why certain things may not work,
> outline your ideas about how these limitations could be overcome.
> Everything has a solution, if only we brainstorm the problem long
> enough.
> 
> It's one of the best ways we can all learn from one another and 
> continue to make progress in the field.

While I don't disagree at some level, we get a fairly complicated
architectural proposal coming through here on average of once a week;
more like once every few days lately.  Providing a thorough diagnosis
of how to fix said architecture while maintaining the quite often
incompatible goals of the original proposer would eat all of the time
of many of the people on this list.

There is, in fact, value in saying "here are the things that you have
not thought about that present problems with your design", especially
when they are in fact general issues that face many of us.  Hopefully,
folks who are doing new work in this field can look at the problems
that previous architectures have run into along the way and design
systems that don't have those issues.  This is standard engineering
practice.  If a solution is obvious while I'm writing a note like the
one I wrote, I'm happy to propose it, and do.  Sometimes however, the
answer is "I'm sorry, you're solving the wrong problem."

I think it's especially important to point out problems when systems
are presented as something that might not be purely just research
code.  I'm all for research prototypes of all kinds of crazy
architectures that we might learn something from, as long as we don't
try to deploy them to real users.  If something sounds like they might
be looking at taking on real users at some point (such as when they
start worrying about user content), then I think we have a
responsibility to make sure that errors are pointed out -- which is
why I'm taking the time to make the posts I have.

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHOavEACgkQQwkE2RkM0wpJiAD+Kf0ign7FmOY7S+EcGnJt5TGo
V6eysUhwHDv7qyFAXW8A/iG0D1cJN8EoL7hBejshKe2UUedm8RVafUJt2rtSaTKS
=zRPO
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[apologies for top-posting]

There are different kinds of linkability that matter.  Linkability
from an external adversary and my ability to identify myself to a
friend are unrelated.  If we posit a Facebook where I only connect via
Tor, only post encrypted content, and also post chaff content so the
service can't tell what content is even real, the other people who I
a) tell the username to, and b) give the encryption key to can still
use the network just fine -- from their perspective, it's the same
experience.  The difference is that from an outsider's perspective,
it's noise -- they can't tell who's connecting to the service, how
much traffic they're sending, what it is, or who's reading it.

Location privacy is a critical part of unlinkability.  If I can tell
where people are located in the physical world, I can use that to
reverse engineer an otherwise pseudonymous social graph and
disambiguate social graph chaff, as is provided with your mirroring.
Likewise, message transit times when all connections are observable
will serve to distinguish between initial post propagation and mirroring.

Services that attempt to provide deniability have an interesting
problem to deal with.  Deniability is poorly defined (c.f. the
difference between hidden volume deniability in TrueCrypt and the
deniability property in OTR).  In each case, they're trying to use
technical properties of a system to enable a user to perform a certain
kind of real-world falsehood.  Enabling your users to lie has (at
least) two failure modes: the first is that the lie isn't complete
(for Truecrypt, maintaining hidden volume confidentiality is
sufficiently difficult that I'd call it field-impossible for most
moderately technical users faced with a competent forensics
technician), which means that you may be encouraging them to take
risks that will get them caught and in more trouble than otherwise,
while not giving them the degree of security they expected.  The
second is that the lie isn't plausible -- in theory, after keys have
been published at session end, another user could fake an OTR message
as having been part of that session.  However, given a wiretap taken
to even the most minimal level of forensic standards, no judge will
ever find this plausible when presented as evidence that a separately
captured transcript might have been forged.  Again, the feature is
non-functional in the real world.

Services that claim to provide a form of deniability have an
exceptionally high bar to reach to prove any degree of field utility.
 Deniability features often make protocols much more complicated (see
mpOTR) for no real gain.  Thus, I would claim that barring further
research (both field and protocol), it should be avoided as a protocol
goal.

I am a very strong believer in distributed systems.  They are key to
any freedom we may regain online.  I also see very clearly that the
set of privacy properties that we believed were necessary are
different than we previously understood, and that we need to change
the systems we research immediately in reaction to this.

Yes, Tor is slow.  This doesn't mean it's ok to say that "well, I care
about user experience, therefor we have to give up on network
unlinkability".  You'd never dream of saying that about
authentication, right?  Well, now you've got another thing you have no
choice but to deal with.

E.


On 2013.06.28 15.01, Alireza Mahdian wrote:
> To answer your concerns Eleanor: If you are talking about content 
> unlinkability as implemented in Darknet I don't want that in a
> social network that works like Facebook. I want to be able to trust
> the contents that are published on it based on their linkability to
> their publishers. Think of Facebook with no content linkability, it
> is not even meaningful anymore. what does it mean to have a wall if
> no one knows who the wall belongs to. it is a completely different
> experience and I did not want that in MyZone. I was more aiming at
> a distributed Facebook where user contents are stored on their own
> devices and mirrored on trusted devices.
> 
> Now if you are talking about the linkability of users within the
> social graph I would also recommend you to take a look at my thesis
> where I have introduced the concept of social hosting. an advantage
> of this is that let's say user A and B are friends also B and C are
> friends but not A and C. if B chooses A as a mirror then C would at
> some point connect to A to receive B's updates or interact with B's
> profile while it is offline (writing something on B's wall for
> example) at this point the entity that monitors all the links
> (let's say the government) would wrongly assume that A and C are
> friends (linkability) while it is not true. now the users can use
> this to their advantage and when prosecuted they can deny the
> linkability by just giving the counter example of this i.e. if A
> and C are really friends and A happens to be a pers

Re: [liberationtech] Advice needed for secure IM/Voice/Video Service

[Fabio Pietrosanti (naif)]

Il 6/29/13 1:02 AM, Anthony Papillion ha scritto:

So I'm setting up a new Jabber service at www.patts.us.

I want to make it as secure and safe as possible for people to use it
and I'd like some advice. Here's what I've done so far:

1. Turned off all logging on the server (httpd, xmpp, etc)
2. Doesn't require ANY user info to register
3. Doesn't log conversations
4. Allows access via Tor
It would be a nice transparency measure to run a small web server that 
provide direct access to the full server filesystem, allowing to browse 
everything and download any files, with few exceptions such as SSH or 
SSL private keys.


That way anyone would be able to fully inspect the server, even without 
logging-in, by assessing configurations and checking out that logs are 
not kept.


--
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Jonathan Wilkes]

On 06/28/2013 12:28 PM, Eleanor Saitta wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 04.21, Rich Kulawiec wrote:

On Fri, Jun 21, 2013 at 04:56:24PM +0100, Michael Rogers wrote:

I agree - "no smartphones" is sound advice. "No phones" is even
better. But the problem is, nobody follows that advice. So we
have to be pragmatic.

[snip insightful comments]

I would like to agree with you -- and in part, I do.

But I'll suggest that the yardstick for "pragmatic" has moved
considerably during the last few weeks.

And yet, the yardstick for what users will accept hasn't moved more
than a half inch.Yes, we're going to get more people to try to use
better tools now.  They'll still fail, because the tools still aren't
designed for them and they still do actually have other jobs to do.
We're exceptionally unlikely to get people to stop carrying entire
classes of devices most of the time when they still live in a world
which all-but-requires you to carry them.

Did you know that there's a private bus line going in in San Francisco
that you can't ride without an iPhone?  Now, what was that again about
telling people to not carry phones?


That's anecdotal evidence.

The vast majority of the smartphone userbase just learned the
word "meta-data" a few weeks ago.  The news about
the scope of NSA surveillance is revelatory to non-specialists.
The scope of the surveillance is unprecendented.  There are not
yet any peer-reviewed articles on how these revelations affect
users' relationship to their smartphones, nor how those relationships
may change as they more fully understand the dangers of wide-net
surveillance.

-Jonathan
--
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] Advice needed for secure IM/Voice/Video Service

[Anthony Papillion]

So I'm setting up a new Jabber service at www.patts.us.

I want to make it as secure and safe as possible for people to use it
and I'd like some advice. Here's what I've done so far:

1. Turned off all logging on the server (httpd, xmpp, etc)
2. Doesn't require ANY user info to register
3. Doesn't log conversations
4. Allows access via Tor

Is there anything else I need to be aware of to make this more secure
for users?

Thanks,
Anthony

-- 
Anthony Papillion
Phone:   1.918.533.9699
SIP: sip:cajuntec...@iptel.org
iNum:+883510008360912
XMPP:cypherp...@patts.us

www.cajuntechie.org
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Multiple vulnerabilities in Silent Circle

[Steve Weis]

SilentCircle may also be vulernable to this DoS against the PolarSSL
library:
http://bureauofsabotage.com/report001.txt

Apparently, an attacker can send the PolarSSL lib into an infinite loop
with a malformed certificate. It affects versions 1.1.0 up to 1.2.8.
SilentCircle is using 1.1.1 here:
https://github.com/SilentCircle/silent-phone-android/blob/ffd18e90251db4964db210d6348352465531544e/jni/Android.mk#L60


On Thu, Jun 27, 2013 at 9:11 AM, Nadim Kobeissi  wrote:

> Thanks to Arturo Filastò for pointing this out:
> https://github.com/SilentCircle/silent-phone-base/issues/5
>
> Many remotely executable overflows in the ZRTP library used by Silent
> Circle.
>
> NK
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Guido Witmond]

> 
> I think the key is that it's time to *also* support the "average"
> user.  We can't stop working to create systems that are as secure as
> possible for the people who are directly targeted and whose lives are
> at risk -- but we also cannot only support that very motivated individual.
> 
> If we can improve the baseline - making everyone more secure from a
> variety of threats, we start winning at a much longer-term game; and
> we make the extra mile that people on front line have to do to be even
> more secure a bit less challenging.
> 
> This means tools have to be easier, and need to be usable at a basic
> level without training.  Is the level of security they'll be at good
> enough for {insert problematic context/country here} ? No, of course
> not, but it's a hell of a lot better than an unpatched WinXP box with
> out-of-date anti-virus and outlook express.
> 
> I feel like the ladder for security tools is missing rungs on the
> bottom 2/3ds of it, and we're at an amazing (and frightening) point in
> history to build those rungs in.
> 

Plugging my ideas again:

Eccentric-authentication.org  Not suitable for activists and
whistleblowers. Good enough for the common man and woman.

Available under AGPLv3.

Cheers, Guido.

PS with some help and financing it will be finished quicker.
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] abuse control for Tor exit nodes

[Mike Perry]

Tom Ritter:
> On 27 June 2013 05:07, Rich Kulawiec  wrote:
> > [ Okay, so I have a long-winded response to this.  It's possible that
> > eventually I'll wander somewhere near a point. ;-) ]
> > ...
> > ...
> > My suggestion (and this is based on many other kinds of operations
> > since I've never run a Tor exit node) is to do what everyone should
> > do for every operation: use a bidirectional default-deny firewall.
> > Then punch holes in it as necessary to permit desired traffic.  Use netflows
> > to detect and squash things like brute-force attacks.  (In other
> > words, if you observe a serious spike in outbound ssh connection attempts,
> > then someone is using your node, and possibly others, to conduct an ssh
> > brute-force attack.  Rate-limit it.  Or just block it for a while.)
> > Another highly useful technique is rate-limiting based on passive
> > OS fingerprinting of the source: one application is to provide
> > severely limited SMTP bandwidth to anything fingerprinting as Windows.
> > Another is to use the Team Cymru bogon list.  And still another is
> > to use the Spamhaus DROP list, since nothing good can happen by permitting
> > traffic to/from those network ranges.
> >
> > The "pf" firewall in various BSD distributions is a good choice
> > for implementing all this.  It also has the useful feature of being
> > rather resource-frugal: it's quite impressive how an old/slow box
> > running it can gracefully handle large traffic volumes.
> 
> 
> This is a very well written argument, thank you.  I'd love to see more
> discussion around the ethics of "Should I" or "Shouldn't I" put in
> (non-logging) abuse filtering on exit nodes.  Someone can always
> disguise abuse.  An intelligent DoS attack on an SSL website couldn't
> be detected by an exit node operator.  But, just as moving SSH off
> port 22 really honest-to-god does eliminate 99% of the crap you'd get
> otherwise, maybe there are similar cheap wins to be had on Exit Nodes.
>  While there are legitimate reasons to send sqlmap through Tor, I'm
> currently thinking if you actually want to test something,
> legitimately, through Tor, using sqlmap - you should be prepared to
> deal with exit blocking.  Exit blocking that could eliminate 50%, 80%,
> 95% of the crap.  I'd love to see people debate this back and forth
> more and tease out arguments for and against.
> 
> On the practical side of things, a couple questions.
> Blacklisting connects *to* the spamhaus list, and other known spammers
> (as an exit operator) would really only shut down control channels,
> no?.  Similarly, if you're an entry node, you could block connections
> *from*... but if spammers on the spamhaus blocklist were actually
> using Tor... well, they wouldn't *be on the blocklist*.  I could
> always be wrong, but I don't see this making big wins.
> 
> Shutting down SSH brute forcing would be cool.  I've joked with my
> friends "There are so many interesting thing in the world, and I have
> no little time to learn them all.  I have to prioritize. So I decided
> to skip iptables and use a wrapper (shorewall)."Do you have, or
> know of, any simple writeups for doing that, or some of the more
> complicated suggestions?

This argument comes up every so often on tor-relays.

Censorship filters, IDS systems, and rate limiting firewalls don't
belong on Tor exits anymore than they belong on the core routers of the
Internet. They belong on the leaves. Censor yourself, not others.

Imagine what would happen if the core routers of the Internet "detected"
"abuse" with even 99% accuracy (1% false positive rate). The Internet
would cease to function, due to the base rate fallacy and the relative
infrequency of actual abuse:
https://en.wikipedia.org/wiki/Base_rate_fallacy

The same math applies to Tor exits.

-- 
Mike Perry
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Yosem Companys]

I want to commend Alirezza.

It's very important for us to welcome all those who design and conduct
research on liberation technologies,  I commend him for trying to
build something of importance to all of us and dealing with the
inevitable issues that result from doing so.

One of the great things of this list is that others with
liberationtech experience are kind enough to give feedback to folks
like Alirezza.

As always, however, let's try to keep the discussion constructive.
Rather than simply point out why certain things may not work, outline
your ideas about how these limitations could be overcome.  Everything
has a solution, if only we brainstorm the problem long enough.

It's one of the best ways we can all learn from one another and
continue to make progress in the field.

Best,

Yosem, one of the list moderators



On Fri, Jun 28, 2013 at 12:01 PM, Alireza Mahdian
 wrote:
> To answer your concerns Eleanor: If you are talking about content
> unlinkability as implemented in Darknet I don't want that in a social
> network that works like Facebook. I want to be able to trust the contents
> that are published on it based on their linkability to their publishers.
> Think of Facebook with no content linkability, it is not even meaningful
> anymore. what does it mean to have a wall if no one knows who the wall
> belongs to. it is a completely different experience and I did not want that
> in MyZone. I was more aiming at a distributed Facebook where user contents
> are stored on their own devices and mirrored on trusted devices.
>
> Now if you are talking about the linkability of users within the social
> graph I would also recommend you to take a look at my thesis where I have
> introduced the concept of social hosting. an advantage of this is that let's
> say user A and B are friends also B and C are friends but not A and C. if B
> chooses A as a mirror then C would at some point connect to A to receive B's
> updates or interact with B's profile while it is offline (writing something
> on B's wall for example) at this point the entity that monitors all the
> links (let's say the government) would wrongly assume that A and C are
> friends (linkability) while it is not true. now the users can use this to
> their advantage and when prosecuted they can deny the linkability by just
> giving the counter example of this i.e. if A and C are really friends and A
> happens to be a person of interest C can always claim that A was not his
> friend and he only connected to A because it was hosting B which is a non
> threatening user. I have introduced the concept of deniability while
> providing authentication in the system. the authenticity is valid within the
> social network (if A publishes something it is traced back to A by all of
> A's friends) while the deniability is valid outside the social network (as I
> made the example). As john mentioned the user experience is very important
> if at some point this system is going to compete with something like
> Facebook therefore implementing this on top of an overlay network would not
> be a good design choice. As for any system I am not claiming that this
> system does not suffer from any drawbacks but at least it's a fully
> functioning system that provides a pretty good user experience while
> preserving their privacy. also at its full implementation it is resilient
> towards large scale DDoS attacks and black outs which is what I mean by
> resiliency.
>
> To answer John: As I mentioned in an earlier post I have done this protect
> myself from any liability if someone modifies the code rendering it a
> malware. I may publish the service layer code independently under a
> different license where anyone can modify it as they want to. However I do
> understand your point.
>
> On Jun 28, 2013, at 11:14 AM, Jonathan Wilkes  wrote:
>
>
> From: Eleanor Saitta 
> To: liberationtech 
> Sent: Friday, June 28, 2013 12:24 PM
> Subject: Re: [liberationtech] a privacy preserving and resilient social
> network
>
> [...]
>
>>Congratulations!  Your job is now to figure out how to make it faster
> while keeping the same privacy guarantees.  You don't get to opt out,
> because you can't do any meaningful work until you've done this.
> Actually it looks like there might be meaningful work here on the mirroring
> front.  Mirroring content on trusted friends' machines is something the
> Freedombox folks mused about, and the video demos what looks like
> a user-friendly implementation of the same idea.
>
> Just curious, Eleanor-- once you implement your "bullet-proof" privacy-
> preserving network, how do you plan to make the user experience at all
> tolerable without automated mirroring like what this developer has written
> and tested?
>
> Of course this is all moot while the license of "it's free and open, as long
> as you ask me first and I agree" is in effect.  I can't imagine anyone
> taking
> a serious look at the code with that.
>
> -Jonathan
>
> -Jonathan
>
> E.
>
> - --
> Ide

Re: [liberationtech] a privacy preserving and resilient social network

[Alireza Mahdian]

To answer your concerns Eleanor: If you are talking about content unlinkability 
as implemented in Darknet I don't want that in a social network that works like 
Facebook. I want to be able to trust the contents that are published on it 
based on their linkability to their publishers. Think of Facebook with no 
content linkability, it is not even meaningful anymore. what does it mean to 
have a wall if no one knows who the wall belongs to. it is a completely 
different experience and I did not want that in MyZone. I was more aiming at a 
distributed Facebook where user contents are stored on their own devices and 
mirrored on trusted devices. 

Now if you are talking about the linkability of users within the social graph I 
would also recommend you to take a look at my thesis where I have introduced 
the concept of social hosting. an advantage of this is that let's say user A 
and B are friends also B and C are friends but not A and C. if B chooses A as a 
mirror then C would at some point connect to A to receive B's updates or 
interact with B's profile while it is offline (writing something on B's wall 
for example) at this point the entity that monitors all the links (let's say 
the government) would wrongly assume that A and C are friends (linkability) 
while it is not true. now the users can use this to their advantage and when 
prosecuted they can deny the linkability by just giving the counter example of 
this i.e. if A and C are really friends and A happens to be a person of 
interest C can always claim that A was not his friend and he only connected to 
A because it was hosting B which is a non threatening user. I have introduced 
the concept of deniability while providing authentication in the system. the 
authenticity is valid within the social network (if A publishes something it is 
traced back to A by all of A's friends) while the deniability is valid outside 
the social network (as I made the example). As john mentioned the user 
experience is very important if at some point this system is going to compete 
with something like Facebook therefore implementing this on top of an overlay 
network would not be a good design choice. As for any system I am not claiming 
that this system does not suffer from any drawbacks but at least it's a fully 
functioning system that provides a pretty good user experience while preserving 
their privacy. also at its full implementation it is resilient towards large 
scale DDoS attacks and black outs which is what I mean by resiliency. 

To answer John: As I mentioned in an earlier post I have done this protect 
myself from any liability if someone modifies the code rendering it a malware. 
I may publish the service layer code independently under a different license 
where anyone can modify it as they want to. However I do understand your point.

On Jun 28, 2013, at 11:14 AM, Jonathan Wilkes  wrote:

> 
> From: Eleanor Saitta 
> To: liberationtech  
> Sent: Friday, June 28, 2013 12:24 PM
> Subject: Re: [liberationtech] a privacy preserving and resilient social 
> network
>  
> [...]
> 
> >Congratulations!  Your job is now to figure out how to make it faster
> while keeping the same privacy guarantees.  You don't get to opt out,
> because you can't do any meaningful work until you've done this.
> Actually it looks like there might be meaningful work here on the mirroring
> front.  Mirroring content on trusted friends' machines is something the
> Freedombox folks mused about, and the video demos what looks like
> a user-friendly implementation of the same idea.
>  
> Just curious, Eleanor-- once you implement your "bullet-proof" privacy-
> preserving network, how do you plan to make the user experience at all
> tolerable without automated mirroring like what this developer has written
> and tested?
>  
> Of course this is all moot while the license of "it's free and open, as long
> as you ask me first and I agree" is in effect.  I can't imagine anyone taking
> a serious look at the code with that.
>  
> -Jonathan
>  
> -Jonathan
>  
> E.
> 
> - -- 
> Ideas are my favorite toys.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
> 
> iF4EAREIAAYFAlHNuKUACgkQQwkE2RkM0wr0/wD+IVTnHPuZzNSs6hqEIP0gyaiQ
> 8J351/zcc6UWICx6suEBAIVLljasG1kp4vOMjwCclkxYdOFcsfQBJSAp2zjvWX7D
> =cHDZ
> -END PGP SIGNATURE-
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> 
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech


--
Alireza Mahdian
Department of Computer Science
University of Colorado at Boulder
Email: alireza.mahd...@gmail.com

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Jon Camfield]

On Friday, June 28, 2013 12:28 PM, Eleanor Saitta wrote:
> On 2013.06.28 04.21, Rich Kulawiec wrote:
>> On Fri, Jun 21, 2013 at 04:56:24PM +0100, Michael Rogers wrote:
>>> I agree - "no smartphones" is sound advice. "No phones" is
>>> even better. But the problem is, nobody follows that advice. So
>>> we have to be pragmatic.
> 
>> [snip insightful comments]
> 
>> I would like to agree with you -- and in part, I do.
> 
>> But I'll suggest that the yardstick for "pragmatic" has moved 
>> considerably during the last few weeks.
> 
> And yet, the yardstick for what users will accept hasn't moved
> more than a half inch.  Yes, we're going to get more people to try
> to use better tools now.  They'll still fail, because the tools
> still aren't designed for them and they still do actually have
> other jobs to do.
[snip]

> Did you know that there's a private bus line going in in San
> Francisco that you can't ride without an iPhone?  Now, what was
> that again about telling people to not carry phones?

Or the unspoken but equally massive database that our credit cards
generate about our location and detailed buying habits; but try living
any approximation of a normal life without one.

> I understand very well that giving people advice that is
> insufficient isn't acceptable.  However, giving people advice
> they're going to ignore wastes their time, destroys your ability to
> be an adviser on issues where they might take your advice, and
> doesn't result in any better outcomes.
> 
> We as the security community need to stop doing this and come up
> with a third option that understands that our users have multiple 
> priorities.  If we don't want to understand the world our users
> live in and their needs, we might as well all fuck off to a cave
> somewhere.
> 
> E.

Channeling Gunner for a moment, can we get a love bomb here?

I think the key is that it's time to *also* support the "average"
user.  We can't stop working to create systems that are as secure as
possible for the people who are directly targeted and whose lives are
at risk -- but we also cannot only support that very motivated individual.

If we can improve the baseline - making everyone more secure from a
variety of threats, we start winning at a much longer-term game; and
we make the extra mile that people on front line have to do to be even
more secure a bit less challenging.

This means tools have to be easier, and need to be usable at a basic
level without training.  Is the level of security they'll be at good
enough for {insert problematic context/country here} ? No, of course
not, but it's a hell of a lot better than an unpatched WinXP box with
out-of-date anti-virus and outlook express.

I feel like the ladder for security tools is missing rungs on the
bottom 2/3ds of it, and we're at an amazing (and frightening) point in
history to build those rungs in.

/end friday rant

Jon

> -- Too many emails? Unsubscribe, change to digest, or change
> password by emailing moderator at compa...@stanford.edu or changing
> your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Jonathan Wilkes]

 


 From: Eleanor Saitta 
To: liberationtech  
Sent: Friday, June 28, 2013 12:24 PM
Subject: Re: [liberationtech] a privacy preserving and resilient social network
  

[...]

>Congratulations!  Your job is now to figure out how to make it faster
while keeping the same privacy guarantees.  You don't get to opt out,
because you can't do any meaningful work until you've done this.

Actually it looks like there might be meaningful work here on the mirroring
front.  Mirroring content on trusted friends' machines is something the
Freedombox folks mused about, and the video demos what looks like
a user-friendly implementation of the same idea.

Just curious, Eleanor-- once you implement your "bullet-proof" privacy-
preserving network, how do you plan to make the user experience at all
tolerable without automated mirroring like what this developer has written
and tested?

Of course this is all moot while the license of "it's free and open, as long
as you ask me first and I agree" is in effect.  I can't imagine anyone taking
a serious look at the code with that.

-Jonathan

-Jonathan

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHNuKUACgkQQwkE2RkM0wr0/wD+IVTnHPuZzNSs6hqEIP0gyaiQ
8J351/zcc6UWICx6suEBAIVLljasG1kp4vOMjwCclkxYdOFcsfQBJSAp2zjvWX7D
=cHDZ
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 04.21, Rich Kulawiec wrote:
> On Fri, Jun 21, 2013 at 04:56:24PM +0100, Michael Rogers wrote:
>> I agree - "no smartphones" is sound advice. "No phones" is even 
>> better. But the problem is, nobody follows that advice. So we
>> have to be pragmatic.
> 
> [snip insightful comments]
> 
> I would like to agree with you -- and in part, I do.
> 
> But I'll suggest that the yardstick for "pragmatic" has moved 
> considerably during the last few weeks.

And yet, the yardstick for what users will accept hasn't moved more
than a half inch.  Yes, we're going to get more people to try to use
better tools now.  They'll still fail, because the tools still aren't
designed for them and they still do actually have other jobs to do.
We're exceptionally unlikely to get people to stop carrying entire
classes of devices most of the time when they still live in a world
which all-but-requires you to carry them.

Did you know that there's a private bus line going in in San Francisco
that you can't ride without an iPhone?  Now, what was that again about
telling people to not carry phones?

I understand very well that giving people advice that is insufficient
isn't acceptable.  However, giving people advice they're going to
ignore wastes their time, destroys your ability to be an adviser on
issues where they might take your advice, and doesn't result in any
better outcomes.

We as the security community need to stop doing this and come up with
a third option that understands that our users have multiple
priorities.  If we don't want to understand the world our users live
in and their needs, we might as well all fuck off to a cave somewhere.

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHNuccACgkQQwkE2RkM0wpD3wD+NghXyKBmQEXhVnEQrGK3vSK2
ewQprZPVy/QUHqlh/ggA/RHvMiUwTXJR1dGHMCEI3mEpEwD9PiYC5cS2m1/295Ft
=+88f
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Eleanor Saitta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2013.06.28 03.37, Alireza Mahdian wrote:
> First of all anonymity is not a goal here.

I'm going to come down on you kind of hard here, but it's not aimed at
you, it's aimed at everyone building systems like this.

A month ago, you could plausibly argue that it was possible to build
privacy-preserving tools that did not provided unlinkability (what you
mean when you say anonymity).

This is now revealed as obviously, laughably, tragically, and utterly
false.

Social graph and traffic analysis is the name of the game.  Content
protection actually matters much *less* than unlinkability.

If you claim to be building privacy preserving system and it either does
not provide strong unlinkability as at least an option, or creates
central points of trust failure where someone can be compelled into
compromising the network, you have done nothing.

Yes, there are different tools that are appropriate for different
contexts.  However, there is little or no point in doing further
research on so-called privacy perserving tools that do not preserve
privacy.

This sucks for folks who have grant money and research time tied up in
existing project that are now plainly irrelevant.  Tough.  The world
changed, and we as a community need to move on, in a hurry.

> A structure similar to I2P or Tor that uses overlay network would
> be very inefficient due to network delays

Congratulations!  Your job is now to figure out how to make it faster
while keeping the same privacy guarantees.  You don't get to opt out,
because you can't do any meaningful work until you've done this.

This sucks.  I would be quite happy to live in a world where these
were not the constraints we as developers had to live with.  But we
don't get that choice.

E.

- -- 
Ideas are my favorite toys.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlHNuKUACgkQQwkE2RkM0wr0/wD+IVTnHPuZzNSs6hqEIP0gyaiQ
8J351/zcc6UWICx6suEBAIVLljasG1kp4vOMjwCclkxYdOFcsfQBJSAp2zjvWX7D
=cHDZ
-END PGP SIGNATURE-
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

[liberationtech] Roundup of NSA and PRISM memes

[Reed Black]

On Tue, Jun 18, 2013 at 2:07 PM, Markus Beckedahl
 wrote:
> hi,
>
> Privacy activists just held a protest at the well-known Berlin Wall crossing
> point Checkpoint Charlie in Berlin. As President Barack Obama prepares to
> arrive in the german capital, the protest critizised excessive NSA
> surveillance and the Prism programme. The call from digital rights NGO
> Digitale Gesellschaft asked for people to come with surveillance equipment,
> posing as NSA agents and their corporate helpers.
>
> You should copy that in your country and/or city. Here are some pictures:
>
> https://netzpolitik.org/2013/yes-we-scan-privacy-activists-protest-against-prism-and-nsa-surveillance-as-president-obama-arrives-in-berlin/
> https://secure.flickr.com/photos/digitalegesellschaft/sets/72157634191380643/


Know Your Meme has a roundup of dozens of images and series similar to
this "Yes We Scan" meme. This may be useful for ongoing coverage of
privacy, domestic spying, or the sometimes surreal face of internet
advocacy.

http://knowyourmeme.com/memes/events/2013-nsa-prism-scandal
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] abuse control for Tor exit nodes

[Tom Ritter]

On 27 June 2013 05:07, Rich Kulawiec  wrote:
> [ Okay, so I have a long-winded response to this.  It's possible that
> eventually I'll wander somewhere near a point. ;-) ]
> ...
> ...
> My suggestion (and this is based on many other kinds of operations
> since I've never run a Tor exit node) is to do what everyone should
> do for every operation: use a bidirectional default-deny firewall.
> Then punch holes in it as necessary to permit desired traffic.  Use netflows
> to detect and squash things like brute-force attacks.  (In other
> words, if you observe a serious spike in outbound ssh connection attempts,
> then someone is using your node, and possibly others, to conduct an ssh
> brute-force attack.  Rate-limit it.  Or just block it for a while.)
> Another highly useful technique is rate-limiting based on passive
> OS fingerprinting of the source: one application is to provide
> severely limited SMTP bandwidth to anything fingerprinting as Windows.
> Another is to use the Team Cymru bogon list.  And still another is
> to use the Spamhaus DROP list, since nothing good can happen by permitting
> traffic to/from those network ranges.
>
> The "pf" firewall in various BSD distributions is a good choice
> for implementing all this.  It also has the useful feature of being
> rather resource-frugal: it's quite impressive how an old/slow box
> running it can gracefully handle large traffic volumes.


This is a very well written argument, thank you.  I'd love to see more
discussion around the ethics of "Should I" or "Shouldn't I" put in
(non-logging) abuse filtering on exit nodes.  Someone can always
disguise abuse.  An intelligent DoS attack on an SSL website couldn't
be detected by an exit node operator.  But, just as moving SSH off
port 22 really honest-to-god does eliminate 99% of the crap you'd get
otherwise, maybe there are similar cheap wins to be had on Exit Nodes.
 While there are legitimate reasons to send sqlmap through Tor, I'm
currently thinking if you actually want to test something,
legitimately, through Tor, using sqlmap - you should be prepared to
deal with exit blocking.  Exit blocking that could eliminate 50%, 80%,
95% of the crap.  I'd love to see people debate this back and forth
more and tease out arguments for and against.

On the practical side of things, a couple questions.
Blacklisting connects *to* the spamhaus list, and other known spammers
(as an exit operator) would really only shut down control channels,
no?.  Similarly, if you're an entry node, you could block connections
*from*... but if spammers on the spamhaus blocklist were actually
using Tor... well, they wouldn't *be on the blocklist*.  I could
always be wrong, but I don't see this making big wins.

Shutting down SSH brute forcing would be cool.  I've joked with my
friends "There are so many interesting thing in the world, and I have
no little time to learn them all.  I have to prioritize. So I decided
to skip iptables and use a wrapper (shorewall)."Do you have, or
know of, any simple writeups for doing that, or some of the more
complicated suggestions?

-tom
--
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] Surveillance 'partnership' between NSA and telcos points to AT&T, Verizon

[Eugen Leitl]

http://news.cnet.com/8301-13578_3-57591391-38/surveillance-partnership-between-nsa-and-telcos-points-to-at-t-verizon/

Surveillance 'partnership' between NSA and telcos points to AT&T, Verizon

Newly disclosed classified document suggests firms allowed spy agency to
access e-mail and phone call data by tapping into their "fiber-optic cables,
gateway switches, and data networks."

by Declan McCullagh  June 27, 2013 2:40 PM PDT

The National Security Agency entered into "collection partnerships" with a
pair of telecommunications companies that permitted tapping their fiber
links. Evidence suggests it's AT&T and Verizon.

Want to play a game of "guess who?"

A newly disclosed top secret document lauds the National Security Agency's
"productive" and long-standing surveillance "partnership" with a pair of
telecommunications providers -- that permitted tapping into their fiber links
-- but without naming names.

This is where things get interesting for clue sleuths.

Even in the top-secret document published by the Guardian today, the firms
are described only as "Company A" and "Company B." But the NSA's inspector
general did disclose that, at the time the program was being formed in the
wake of the September 11 attacks, the agency entered into the partnerships
because Company A had access to 39 percent of international phone calls, and
Company B had access to 28 percent.

Those figures closely correspond with Federal Communications Commission data
(PDF). The most recent figures publicly available in late 2001, when the
carrier "partnerships" were being expanded, reveal that AT&T carried 38.2
percent of international minutes billed to U.S. carriers. MCI, now part of
Verizon, carried 29.1 percent.

Verizon spokesman Ed McFadden would not confirm or deny his employer's
identity as company B, and told CNET today that the company "always requires
appropriate legal process" when responding to requests from any government
agency. AT&T did not respond to questions.

"Collection partnerships" with these two firms have allowed the spy agency to
vacuum up e-mail and phone call content by tapping into their "fiber-optic
cables, gateway switches, and data networks," says the 2009 report. That's
consistent with previous reports that AT&T permitted the NSA to tap into its
telecommunications facilities.

The disclosures, part of a 2009 report prepared by the NSA's Office of the
Inspector General, emphasize how crucial -- and sensitive -- the agency's
relationships with U.S. telecommunications companies have become.

These relationships also allowed the NSA to take advantage of the United
States' role as an international Internet hub, which meant that an outsize
share of worldwide traffic flows through the networks of AT&T, Verizon, and
other U.S. providers. Even e-mail messages between Latin American and African
countries, for instance, are typically routed through U.S. switches because
of the lower cost.

NSA Director Keith Alexander believed, according to the inspector general's
report, "if the relationships with these companies were ever terminated," the
agency's eavesdropping ability would be "irrevocably damaged, because NSA
would have sacrificed America's home field advantage as the primary hub for
worldwide telecommunications."

Many of these relationships predated the September 11 attacks that
dramatically increased the NSA's authority in a warrantless surveillance
program secretly authorized by President Bush. A 1981 presidential executive
order, for instance, authorized the collection of "signals intelligence
information" for foreign intelligence purposes, which the NSA views as
authorizing the interception of phone calls "transiting" the United States.

Soon after the 2001 attacks, according to the report, representatives of both
Company A and Company B "contacted NSA and asked 'What can we do to help?'"
Both had previously been "providing telephony content to NSA before 2001"
under the 1981 executive order and the Foreign Intelligence Surveillance Act.

Initially, under the Bush-era program, the NSA was temporarily authorized to
intercept "communications with at least one communicant outside the United
States or for which no communicant was known to be a citizen of the United
States." Then, in 2007, the Justice Department secretly authorized the agency
to "analyze communications metadata associated with United States persons and
persons believed to be in the United States."

Metadata is defined, according to the inspector general's report, as
encompassing phone call records and "Internet Protocol" communications, which
would include a person's IP address and what company or service they're
communicating with. (Verizon turns over metadata of all customer calls to the
NSA, meaning the logs of who called whom, every day.)

The Guardian's report today also cited a December 2012 document prepared by
the NSA's Special Source Operations (SSO) directorate discussing classified
programs codenamed EvilOlive and ShellTrumpet

Re: [liberationtech] a privacy preserving and resilient social network

[Ali-Reza Anghaie]

In your resources section - you're not drawing a direct comparison but
do note model shortcomings. No worries there.. I'm trying to
understand what your design is in the context of your opening email to
the list:

"military grade encryption and no authority can have any control over
it. one design goal behind it was actually to make it resilient
towards government imposed censorship and filtering"

Which is why I brought up I2P's existing stack for example.

I'll leave it be, I'm not trying to stir you up. I'm just trying to
understand the decisions made in that statement's context. Cheers,
-Ali


On Fri, Jun 28, 2013 at 4:19 AM, Alireza Mahdian
 wrote:
> MyZone is not addressing the same issues as Tor and I2P. I have never
> compared them to MyZone in any part of my thesis. I was also never critical
> of those systems as they are not relevant to what MyZone tries to achieve
> with the exception of Diaspora which is not a peer to peer application and
> requires its users to set up their own servers. I also specifically point
> out the security limitations of our approach in section 7.3. If the CA is
> compromised then the security of all users is jeopardized as for any PKI.
> Even if the CA is attacked (DDoS attack not a private key hijacking) the
> existing users are not affected since the public key of the CA is already
> shipped with the software.
>
> On Jun 28, 2013, at 1:56 AM, Ali-Reza Anghaie  wrote:
>
> Thank you - I read your comments on Diaspora, Tor, I2P, etc. and
> through section 4.2.2 (Adversary Model) of your thesis. I find it
> curious that some of the issues you're critical of in those systems
> you've actually implemented into your own design (e.g. you do have a
> central server/trust dependency with the CA). I may go back and
> continue reading 5 later as I'm interested in how you implement your
> CA model (4.2.1 / 6.1). My questions of the earlier sections probably
> would only be addressed further in the thesis. Until next time - good
> luck. Cheers, -Ali
>
>
> On Fri, Jun 28, 2013 at 3:37 AM, Alireza Mahdian
>  wrote:
>
> First of all anonymity is not a goal here. I have to be clear on that. A
> structure similar to I2P or Tor that uses overlay network would be very
> inefficient due to network delays). as for using a Jetty stack we chose Java
> as the language to implement this software in order to have a platform
> independent application in one code base and at it is also supported on
> Android as we are developing an smartphone app as well. Using Java has saved
> us a lot of time getting this app ready for different platforms. The jetty
> is a lightweight Java based web server that also installs on android so
> seemed like a good choice to use to serve the UIs and we chose to use web
> interface to implement the UIs as it feels more like common social networks
> like facebook and google+ also future UI enhancements are easier on a web
> app. as for the user, they are not even aware that a web server is being run
> on their computer as no installation or configuration has been done by the
> user. they only run the MyZone launcher and it opens up the browser loading
> their feed page. We have considered a lot of user feedbacks when we designed
> MyZone. this software has a somewhat complex design and there are so many
> small details involved as well so if you have any further questions
> regarding our design choices I would like to refer you to
> http://joinmyzone.com/Thesis.pdf
>
> On Jun 28, 2013, at 1:17 AM, Ali-Reza Anghaie  wrote:
>
> *nod* Yeah, that's was the hint I got.. but the bits about relay
> servers, registration, etc. Lets set those aside.
>
> How do you ~intend~ for this to behave in the wild? Every single
> client w/ a Jetty stack? And - given that footprint - why not start
> within a framework like I2P? (I'm not recommending anything, I'm
> trying to understand without going too far off-kilter.)
>
> -Ali
>
>
> On Fri, Jun 28, 2013 at 3:09 AM, Alireza Mahdian
>  wrote:
>
> those are all to protect our organization (CU Boulder) from any liability.
> also the contents that can be shared on this social network can be pretty
> much anything and since we can't control or monitor any of the contents
> being shared we had to have a strict terms of use agreement just to be clear
> that if the terms of use agreement is violated we are not gonna be liable.
>
> On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:
>
> I had similar confusion when I first started poking around - couldn't
> find a proper LICENSE file and then the ToUs including things that
> read an awful lot like Facebook instead of a distrubuted
> privacy-centric system.
>
> Including:
>
> ---
> a. You will not provide any false personal information on MyZone, or
> create an account for anyone other than yourself without permission.
>
> b. You will not create more than one personal profile.
> ---
>
> My guess is this is because of the Uni affiliation right now..
>
> Architecture right now I'm not going to com

Re: [liberationtech] eternity USENET (Re: Internet blackout)

[Rich Kulawiec]

On Fri, Jun 21, 2013 at 04:56:24PM +0100, Michael Rogers wrote:
> I agree - "no smartphones" is sound advice. "No phones" is even
> better. But the problem is, nobody follows that advice. So we have to
> be pragmatic.

[snip insightful comments]

I would like to agree with you -- and in part, I do.

But I'll suggest that the yardstick for "pragmatic" has moved
considerably during the last few weeks.

I'll also suggest that if we give our best advice and people ignore it --
that's not a very good reason to change our best advice.  Oh, we *could*:
if we modified that advice into something more palatable, then perhaps
more people would more readily accept it.   But all that would achieve
is giving us the momentary satisfaction of seeing them smile and nod and
do what we said...and that will be cold comfort when the day comes that
those steps are proven to be as inadequate as we thought they were all along.

Speaking of the last few weeks: I think, in some ways, that day has come.

Yes, this probably means saying unpopular things, like "get rid of your
smartphone".  But the goal here is not to win popularity contests,
the goal is to give the best advice we can.  (Obviously, we can and will
often disagree on just what that advice should be: hence our interesting
and enlightening argumXdiscussions.)

---rsk
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Alireza Mahdian]

MyZone is not addressing the same issues as Tor and I2P. I have never compared 
them to MyZone in any part of my thesis. I was also never critical of those 
systems as they are not relevant to what MyZone tries to achieve with the 
exception of Diaspora which is not a peer to peer application and requires its 
users to set up their own servers. I also specifically point out the security 
limitations of our approach in section 7.3. If the CA is compromised then the 
security of all users is jeopardized as for any PKI. Even if the CA is attacked 
(DDoS attack not a private key hijacking) the existing users are not affected 
since the public key of the CA is already shipped with the software. 

On Jun 28, 2013, at 1:56 AM, Ali-Reza Anghaie  wrote:

> Thank you - I read your comments on Diaspora, Tor, I2P, etc. and
> through section 4.2.2 (Adversary Model) of your thesis. I find it
> curious that some of the issues you're critical of in those systems
> you've actually implemented into your own design (e.g. you do have a
> central server/trust dependency with the CA). I may go back and
> continue reading 5 later as I'm interested in how you implement your
> CA model (4.2.1 / 6.1). My questions of the earlier sections probably
> would only be addressed further in the thesis. Until next time - good
> luck. Cheers, -Ali
> 
> 
> On Fri, Jun 28, 2013 at 3:37 AM, Alireza Mahdian
>  wrote:
>> First of all anonymity is not a goal here. I have to be clear on that. A
>> structure similar to I2P or Tor that uses overlay network would be very
>> inefficient due to network delays). as for using a Jetty stack we chose Java
>> as the language to implement this software in order to have a platform
>> independent application in one code base and at it is also supported on
>> Android as we are developing an smartphone app as well. Using Java has saved
>> us a lot of time getting this app ready for different platforms. The jetty
>> is a lightweight Java based web server that also installs on android so
>> seemed like a good choice to use to serve the UIs and we chose to use web
>> interface to implement the UIs as it feels more like common social networks
>> like facebook and google+ also future UI enhancements are easier on a web
>> app. as for the user, they are not even aware that a web server is being run
>> on their computer as no installation or configuration has been done by the
>> user. they only run the MyZone launcher and it opens up the browser loading
>> their feed page. We have considered a lot of user feedbacks when we designed
>> MyZone. this software has a somewhat complex design and there are so many
>> small details involved as well so if you have any further questions
>> regarding our design choices I would like to refer you to
>> http://joinmyzone.com/Thesis.pdf
>> 
>> On Jun 28, 2013, at 1:17 AM, Ali-Reza Anghaie  wrote:
>> 
>> *nod* Yeah, that's was the hint I got.. but the bits about relay
>> servers, registration, etc. Lets set those aside.
>> 
>> How do you ~intend~ for this to behave in the wild? Every single
>> client w/ a Jetty stack? And - given that footprint - why not start
>> within a framework like I2P? (I'm not recommending anything, I'm
>> trying to understand without going too far off-kilter.)
>> 
>> -Ali
>> 
>> 
>> On Fri, Jun 28, 2013 at 3:09 AM, Alireza Mahdian
>>  wrote:
>> 
>> those are all to protect our organization (CU Boulder) from any liability.
>> also the contents that can be shared on this social network can be pretty
>> much anything and since we can't control or monitor any of the contents
>> being shared we had to have a strict terms of use agreement just to be clear
>> that if the terms of use agreement is violated we are not gonna be liable.
>> 
>> On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:
>> 
>> I had similar confusion when I first started poking around - couldn't
>> find a proper LICENSE file and then the ToUs including things that
>> read an awful lot like Facebook instead of a distrubuted
>> privacy-centric system.
>> 
>> Including:
>> 
>> ---
>> a. You will not provide any false personal information on MyZone, or
>> create an account for anyone other than yourself without permission.
>> 
>> b. You will not create more than one personal profile.
>> ---
>> 
>> My guess is this is because of the Uni affiliation right now..
>> 
>> Architecture right now I'm not going to comment on. Going to
>> reconsider past biases first.. -Ali
>> 
>> 
>> On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
>>  wrote:
>> 
>> this is to prevent modifications that would render it as a malware. I
>> haven't signed the code yet so I am just protecting myself from such
>> liabilities.
>> 
>> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>> 
>> I like the idea, so I was checking it out. I was confused by this
>> statement in the download terms:
>> 
>> Since MyZone Client Application is open source, you will not change any
>> part of MyZone’s code without the written approval of MyZon

Re: [liberationtech] a privacy preserving and resilient social network

[Ali-Reza Anghaie]

Thank you - I read your comments on Diaspora, Tor, I2P, etc. and
through section 4.2.2 (Adversary Model) of your thesis. I find it
curious that some of the issues you're critical of in those systems
you've actually implemented into your own design (e.g. you do have a
central server/trust dependency with the CA). I may go back and
continue reading 5 later as I'm interested in how you implement your
CA model (4.2.1 / 6.1). My questions of the earlier sections probably
would only be addressed further in the thesis. Until next time - good
luck. Cheers, -Ali


On Fri, Jun 28, 2013 at 3:37 AM, Alireza Mahdian
 wrote:
> First of all anonymity is not a goal here. I have to be clear on that. A
> structure similar to I2P or Tor that uses overlay network would be very
> inefficient due to network delays). as for using a Jetty stack we chose Java
> as the language to implement this software in order to have a platform
> independent application in one code base and at it is also supported on
> Android as we are developing an smartphone app as well. Using Java has saved
> us a lot of time getting this app ready for different platforms. The jetty
> is a lightweight Java based web server that also installs on android so
> seemed like a good choice to use to serve the UIs and we chose to use web
> interface to implement the UIs as it feels more like common social networks
> like facebook and google+ also future UI enhancements are easier on a web
> app. as for the user, they are not even aware that a web server is being run
> on their computer as no installation or configuration has been done by the
> user. they only run the MyZone launcher and it opens up the browser loading
> their feed page. We have considered a lot of user feedbacks when we designed
> MyZone. this software has a somewhat complex design and there are so many
> small details involved as well so if you have any further questions
> regarding our design choices I would like to refer you to
> http://joinmyzone.com/Thesis.pdf
>
> On Jun 28, 2013, at 1:17 AM, Ali-Reza Anghaie  wrote:
>
> *nod* Yeah, that's was the hint I got.. but the bits about relay
> servers, registration, etc. Lets set those aside.
>
> How do you ~intend~ for this to behave in the wild? Every single
> client w/ a Jetty stack? And - given that footprint - why not start
> within a framework like I2P? (I'm not recommending anything, I'm
> trying to understand without going too far off-kilter.)
>
> -Ali
>
>
> On Fri, Jun 28, 2013 at 3:09 AM, Alireza Mahdian
>  wrote:
>
> those are all to protect our organization (CU Boulder) from any liability.
> also the contents that can be shared on this social network can be pretty
> much anything and since we can't control or monitor any of the contents
> being shared we had to have a strict terms of use agreement just to be clear
> that if the terms of use agreement is violated we are not gonna be liable.
>
> On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:
>
> I had similar confusion when I first started poking around - couldn't
> find a proper LICENSE file and then the ToUs including things that
> read an awful lot like Facebook instead of a distrubuted
> privacy-centric system.
>
> Including:
>
> ---
> a. You will not provide any false personal information on MyZone, or
> create an account for anyone other than yourself without permission.
>
> b. You will not create more than one personal profile.
> ---
>
> My guess is this is because of the Uni affiliation right now..
>
> Architecture right now I'm not going to comment on. Going to
> reconsider past biases first.. -Ali
>
>
> On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
>  wrote:
>
> this is to prevent modifications that would render it as a malware. I
> haven't signed the code yet so I am just protecting myself from such
> liabilities.
>
> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>
> I like the idea, so I was checking it out. I was confused by this
> statement in the download terms:
>
> Since MyZone Client Application is open source, you will not change any
> part of MyZone’s code without the written approval of MyZone’s copyright
> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu).
>
>
> Can you explain what you mean? Usually, something called "open source"
> can be modified without any additional written approval.
>
> -john
>
> --
> John Sullivan | Executive Director, Free Software Foundation
> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
>
> Do you use free software? Donate to join the FSF and support freedom at
> .
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahd...@gmail.com
>
>
> --
> Too many ema

Re: [liberationtech] a privacy preserving and resilient social network

[Alireza Mahdian]

First of all anonymity is not a goal here. I have to be clear on that. A 
structure similar to I2P or Tor that uses overlay network would be very 
inefficient due to network delays). as for using a Jetty stack we chose Java as 
the language to implement this software in order to have a platform independent 
application in one code base and at it is also supported on Android as we are 
developing an smartphone app as well. Using Java has saved us a lot of time 
getting this app ready for different platforms. The jetty is a lightweight Java 
based web server that also installs on android so seemed like a good choice to 
use to serve the UIs and we chose to use web interface to implement the UIs as 
it feels more like common social networks like facebook and google+ also future 
UI enhancements are easier on a web app. as for the user, they are not even 
aware that a web server is being run on their computer as no installation or 
configuration has been done by the user. they only run the MyZone launcher and 
it opens up the browser loading their feed page. We have considered a lot of 
user feedbacks when we designed MyZone. this software has a somewhat complex 
design and there are so many small details involved as well so if you have any 
further questions regarding our design choices I would like to refer you to 
http://joinmyzone.com/Thesis.pdf

On Jun 28, 2013, at 1:17 AM, Ali-Reza Anghaie  wrote:

> *nod* Yeah, that's was the hint I got.. but the bits about relay
> servers, registration, etc. Lets set those aside.
> 
> How do you ~intend~ for this to behave in the wild? Every single
> client w/ a Jetty stack? And - given that footprint - why not start
> within a framework like I2P? (I'm not recommending anything, I'm
> trying to understand without going too far off-kilter.)
> 
> -Ali
> 
> 
> On Fri, Jun 28, 2013 at 3:09 AM, Alireza Mahdian
>  wrote:
>> those are all to protect our organization (CU Boulder) from any liability.
>> also the contents that can be shared on this social network can be pretty
>> much anything and since we can't control or monitor any of the contents
>> being shared we had to have a strict terms of use agreement just to be clear
>> that if the terms of use agreement is violated we are not gonna be liable.
>> 
>> On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:
>> 
>> I had similar confusion when I first started poking around - couldn't
>> find a proper LICENSE file and then the ToUs including things that
>> read an awful lot like Facebook instead of a distrubuted
>> privacy-centric system.
>> 
>> Including:
>> 
>> ---
>> a. You will not provide any false personal information on MyZone, or
>> create an account for anyone other than yourself without permission.
>> 
>> b. You will not create more than one personal profile.
>> ---
>> 
>> My guess is this is because of the Uni affiliation right now..
>> 
>> Architecture right now I'm not going to comment on. Going to
>> reconsider past biases first.. -Ali
>> 
>> 
>> On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
>>  wrote:
>> 
>> this is to prevent modifications that would render it as a malware. I
>> haven't signed the code yet so I am just protecting myself from such
>> liabilities.
>> 
>> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>> 
>> I like the idea, so I was checking it out. I was confused by this
>> statement in the download terms:
>> 
>> Since MyZone Client Application is open source, you will not change any
>> part of MyZone’s code without the written approval of MyZone’s copyright
>> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu).
>> 
>> 
>> Can you explain what you mean? Usually, something called "open source"
>> can be modified without any additional written approval.
>> 
>> -john
>> 
>> --
>> John Sullivan | Executive Director, Free Software Foundation
>> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
>> 
>> Do you use free software? Donate to join the FSF and support freedom at
>> .
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>> 
>> 
>> 
>> --
>> Alireza Mahdian
>> Department of Computer Science
>> University of Colorado at Boulder
>> Email: alireza.mahd...@gmail.com
>> 
>> 
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>> 
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>> 
>> 
>> 
>> --
>> Alireza Mahdian
>> Department of Computer Science
>> University of Colorado at Boulder
>> Email: alireza.

Re: [liberationtech] a privacy preserving and resilient social network

[Ali-Reza Anghaie]

*nod* Yeah, that's was the hint I got.. but the bits about relay
servers, registration, etc. Lets set those aside.

How do you ~intend~ for this to behave in the wild? Every single
client w/ a Jetty stack? And - given that footprint - why not start
within a framework like I2P? (I'm not recommending anything, I'm
trying to understand without going too far off-kilter.)

-Ali


On Fri, Jun 28, 2013 at 3:09 AM, Alireza Mahdian
 wrote:
> those are all to protect our organization (CU Boulder) from any liability.
> also the contents that can be shared on this social network can be pretty
> much anything and since we can't control or monitor any of the contents
> being shared we had to have a strict terms of use agreement just to be clear
> that if the terms of use agreement is violated we are not gonna be liable.
>
> On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:
>
> I had similar confusion when I first started poking around - couldn't
> find a proper LICENSE file and then the ToUs including things that
> read an awful lot like Facebook instead of a distrubuted
> privacy-centric system.
>
> Including:
>
> ---
> a. You will not provide any false personal information on MyZone, or
> create an account for anyone other than yourself without permission.
>
> b. You will not create more than one personal profile.
> ---
>
> My guess is this is because of the Uni affiliation right now..
>
> Architecture right now I'm not going to comment on. Going to
> reconsider past biases first.. -Ali
>
>
> On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
>  wrote:
>
> this is to prevent modifications that would render it as a malware. I
> haven't signed the code yet so I am just protecting myself from such
> liabilities.
>
> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>
> I like the idea, so I was checking it out. I was confused by this
> statement in the download terms:
>
> Since MyZone Client Application is open source, you will not change any
> part of MyZone’s code without the written approval of MyZone’s copyright
> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu).
>
>
> Can you explain what you mean? Usually, something called "open source"
> can be modified without any additional written approval.
>
> -john
>
> --
> John Sullivan | Executive Director, Free Software Foundation
> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
>
> Do you use free software? Donate to join the FSF and support freedom at
> .
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahd...@gmail.com
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahd...@gmail.com
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Alireza Mahdian]

those are all to protect our organization (CU Boulder) from any liability. also 
the contents that can be shared on this social network can be pretty much 
anything and since we can't control or monitor any of the contents being shared 
we had to have a strict terms of use agreement just to be clear that if the 
terms of use agreement is violated we are not gonna be liable. 

On Jun 28, 2013, at 1:06 AM, Ali-Reza Anghaie  wrote:

> I had similar confusion when I first started poking around - couldn't
> find a proper LICENSE file and then the ToUs including things that
> read an awful lot like Facebook instead of a distrubuted
> privacy-centric system.
> 
> Including:
> 
> ---
> a. You will not provide any false personal information on MyZone, or
> create an account for anyone other than yourself without permission.
> 
> b. You will not create more than one personal profile.
> ---
> 
> My guess is this is because of the Uni affiliation right now..
> 
> Architecture right now I'm not going to comment on. Going to
> reconsider past biases first.. -Ali
> 
> 
> On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
>  wrote:
>> this is to prevent modifications that would render it as a malware. I
>> haven't signed the code yet so I am just protecting myself from such
>> liabilities.
>> 
>> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>> 
>> I like the idea, so I was checking it out. I was confused by this
>> statement in the download terms:
>> 
>> Since MyZone Client Application is open source, you will not change any
>> part of MyZone’s code without the written approval of MyZone’s copyright
>> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu).
>> 
>> 
>> Can you explain what you mean? Usually, something called "open source"
>> can be modified without any additional written approval.
>> 
>> -john
>> 
>> --
>> John Sullivan | Executive Director, Free Software Foundation
>> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
>> 
>> Do you use free software? Donate to join the FSF and support freedom at
>> .
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>> 
>> 
>> 
>> --
>> Alireza Mahdian
>> Department of Computer Science
>> University of Colorado at Boulder
>> Email: alireza.mahd...@gmail.com
>> 
>> 
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at compa...@stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech


--
Alireza Mahdian
Department of Computer Science
University of Colorado at Boulder
Email: alireza.mahd...@gmail.com

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Ali-Reza Anghaie]

I had similar confusion when I first started poking around - couldn't
find a proper LICENSE file and then the ToUs including things that
read an awful lot like Facebook instead of a distrubuted
privacy-centric system.

Including:

---
a. You will not provide any false personal information on MyZone, or
create an account for anyone other than yourself without permission.

b. You will not create more than one personal profile.
---

My guess is this is because of the Uni affiliation right now..

Architecture right now I'm not going to comment on. Going to
reconsider past biases first.. -Ali


On Fri, Jun 28, 2013 at 2:59 AM, Alireza Mahdian
 wrote:
> this is to prevent modifications that would render it as a malware. I
> haven't signed the code yet so I am just protecting myself from such
> liabilities.
>
> On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:
>
> I like the idea, so I was checking it out. I was confused by this
> statement in the download terms:
>
> Since MyZone Client Application is open source, you will not change any
> part of MyZone’s code without the written approval of MyZone’s copyright
> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu).
>
>
> Can you explain what you mean? Usually, something called "open source"
> can be modified without any additional written approval.
>
> -john
>
> --
> John Sullivan | Executive Director, Free Software Foundation
> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
>
> Do you use free software? Donate to join the FSF and support freedom at
> .
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahd...@gmail.com
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at compa...@stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] a privacy preserving and resilient social network

[Alireza Mahdian]

this is to prevent modifications that would render it as a malware. I haven't 
signed the code yet so I am just protecting myself from such liabilities.  

On Jun 28, 2013, at 12:51 AM, John Sullivan  wrote:

> I like the idea, so I was checking it out. I was confused by this
> statement in the download terms:
> 
>> Since MyZone Client Application is open source, you will not change any
>> part of MyZone’s code without the written approval of MyZone’s copyright
>> owner Alireza Mahdian reached at (alireza.mahdian at colorado dot edu). 
> 
> Can you explain what you mean? Usually, something called "open source"
> can be modified without any additional written approval.
> 
> -john
> 
> -- 
> John Sullivan | Executive Director, Free Software Foundation
> GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS
> 
> Do you use free software? Donate to join the FSF and support freedom at
> .
> --
> Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech


--
Alireza Mahdian
Department of Computer Science
University of Colorado at Boulder
Email: alireza.mahd...@gmail.com

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech