Re: [liberationtech] Revealed: Seven years later, how Facebook shuts down free speech in Egypt | Middle East Eye

[Rich Kulawiec]

On Sun, Jan 28, 2018 at 04:59:02AM -0500, Thomas Delrue wrote:

[ a lot of things I thoroughly agree with, plus he quoted me, so of course
I agree with that, too ;) ]

Let me reiterate: Facebook, Twitter, Linkedin, etc. are NOT your friends.
They are NOT your allies.

And let me add something that I didn't cover in that snarky essay
three and a half years ago: incompetence.  It is now painfully obvious
to everyone that the technical people running these operations are
hilariously incompetent.  Facebook has admitted that they have 200M fake
profiles, which of course means that the number they know about is higher,
and that the additional number they don't know about is even higher.
Twitter has been completely overrun by a similar number of bots, and
its spokesliars continue to downplay their numbers by several orders
of magnitude.  And so on.

The people running these operations built them without first figuring out
how to run them.  They have absolutely no idea how to handle rudimentary
operational tasks like abuse reporting and response.  As a result, they
have been completely overwhelmed by attackers and abusers -- to the
point where it's now questionable who, exactly, is in effective control.

[ Before someone says "but they're so big that...", let me respond
as politely as I can: unacceptable.  Nobody made them get that big.  They
*chose* to.  Thus they also *chose* to deal with the consequences.  I am
not in the least bit sympathetic toward the ignorant newbies who built
things they have no idea how to run, plugged them into OUR Internet, and
subsequently allowed them to abuse the heck out of everyone and everything.
Scale is not a valid excuse for incompetence and negligence.  If they can't
run it properly, they should shut it down.  RIGHT NOW. ]

And that's the good news.  Here's the bad news:

One of the lessons we've learned in the past couple of decades is that
abuse is a surface indicator of underlying security issues.  Operations
which are well-run don't source or sink abuse on a chronic or systemic
basis because the people running them make it their businesss to keep
that from happening.  Conversely, operations that are massive long-term
abuse factories have put proof on the table that they have serious
security problems.  We may not know exactly what those are or where
they came from, but chronic/systemic abuse is an existence proof.

Which leads me to a pointed question: just how pathetic, exactly, does
your security posture have to be in order to provide a home for hundreds
of millions of fake profiles and/or bots?

I have little doubt that most of these operations have been quite
thoroughly pwned by any government's intelligence agency that could stop
laughing long enough to bother.

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

[liberationtech] Fwd: [p...@eff.org: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal] -- time sensitive

[Rich Kulawiec]

[ This was sent to NANOG, but many of you are also in the target groups.
Please note that the deadline is today. ---rsk ]

- Forwarded message from Peter Eckersley  -

> Date: Sun, 26 Mar 2017 16:05:34 -0700
> From: Peter Eckersley 
> To: na...@nanog.org
> Subject: EFF Call for sign-ons: ISPs, networking companies and engineers
>   opposed to FCC privacy repeal
> 
> Dear network operators,
> 
> I'm sure this is a controversial topic in the NANOG community, but EFF and a
> number of ISPs and networking companies are writing to Congress opposing the
> repeal of the FCC's broadband privacy rules, which require explicit opt-in
> consent before ISPs use or sell sensitive, non-anonymized data (including
> non-anonymized locations and browsing histories).
> 
> If you or your employer would like to sign on to such a letter, please reply
> off-list by midday Monday with your name, and a one-sentence description of
> your affiliation and/or major career accomplishments. 
> 
> Back story on what's happening:
> 
> https://www.eff.org/deeplinks/2017/03/five-creepy-things-your-isp-could-do-if-congress-repeals-fccs-privacy-protections
> https://www.eff.org/deeplinks/2017/03/senate-puts-isp-profits-over-your-privacy
> https://www.eff.org/deeplinks/2017/02/congress-contemplating-making-it-illegal-protect-consumer-privacy-online
> 
> Summary of the FCC Broadband Privacy Rules themselves:
> 
> https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf
> 
> -- 
> Peter Eckersleyp...@eff.org
> Chief Computer Scientist  Tel  +1 415 436 9333 x131
> Electronic Frontier FoundationFax  +1 415 436 9993

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

Re: [liberationtech] Data Security for International Travel

[Rich Kulawiec]

On Mon, Mar 06, 2017 at 12:50:45PM -0500, Bruce G. Potter wrote:
> For example, Get a dropbox account [...]

No.  Not Dropbox.  Never Dropbox.  A partial list of reasons why:

Dropbox Authentication: Insecure By Design

http://it.slashdot.org/story/11/04/08/1838220/Dropbox-Authentication-Insecure-By-Design

Dropbox Lack of Security - Miguel de Icaza
http://tirania.org/blog/archive/2011/Apr-19.html

You might want to change your DropBox pass -6,937,081 accounts alegedly 
hacked
https://news.ycombinator.com/item?id=9549762

How Dropbox sacrifices user privacy for cost savings

http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html

Dropbox's new security policy implies that they lied about privacy from 
the start
http://www.boingboing.net/2011/04/21/dropboxs-new-securit.html

Dropbox asks file sharing add-on to drop dead
http://www.boingboing.net/2011/04/26/dropbox-asks-file-sh.html

Dropbox bug deletes some users' files permanently

http://www.neowin.net/news/dropbox-bug-deletes-some-users-files-permanently

Dropbox Tries To Kill Off Open Source Project With DMCA Takedown

http://www.techdirt.com/articles/20110425/15541514030/dropbox-tries-to-kill-off-open-source-project-with-dmca-takedown.shtml

Dropbox Kept Files Around for Years Due to "Delete" Bug

https://www.bleepingcomputer.com/news/software/dropbox-kept-files-around-for-years-due-to-delete-bug/

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

Re: [liberationtech] Facebook: Building Global Community - What's your response to Mark Zuckerberg?

[Rich Kulawiec]

On Sat, Feb 18, 2017 at 02:23:18PM -0800, Yosem Companys wrote:
> To protect your privacy and security, stay off Facebook.
>
> But, to build movements, create an account on Facebook (or Twitter or any
> other dominant centralized social network) and try to get as many people to
> join.

[ rhetorical "you" throughout ]

I think this is a really bad idea: it's a trap.

These aren't tools that exist to facilitate your cause: these are data
harvesting and surveillance engines that will collect and collate every
scrap of data and metadata your adversaries need.  And once that corpus
exists, it WILL be acquired: it's much too valuable and much too easily
transmitted to have the slightest chance of staying in one place.

This is obvious on inspection: every architectural decision, every design
decision, every operational decision, every policy decision ever made
by these operations supports the goal of data acquisition.  It's what
they were built to do.

All the other stuff?  Shiny distraction.  Bait.  Scam.  Propaganda.

Whether the data's acquired by overt contractual arrangement, whether it's
acquired by force of law, whether it's acquired under the table, whether
it's acquired by hacking, whether it's acquired via individual employees,
it WILL be acquired.

Nobody leaves that rich a source of actionable intelligence just sitting
on the table untouched.

So all that you will accomplish by using "social networks" is:

(a) building the database your enemies need to destroy you and
your allies and your cause

(b) building it in a place where they can easily get it --
if they haven't already had it from the moment you created it.

For example:

If I were working for fill-in-the-blank, I would already have
my own people in place at Twitter and Eventbrite and Meetup
and Facebook and all the rest -- either full-time employees,
or people I've co-opted via bribes, blackmail, or other means.
They'd be there long before you were, just waiting for you to
show up and start spending your time and your effort and your
money handing them as much data/metadata as you possibly can.

I would do much the same thing if I were a sufficiently-organized,
sufficiently-funded group intent on propagating racism or fascism
or poverty or pollution or any of the things likely to trigger
opposition.

Why not?  It's cheap.  It's easy.  It's low-risk.  It's
sustainable.  It's simple.  It's deniable.  It's scalable.
In contrast to other spying/surveillance operations, which can
be expensive, complex, and risky, this is a cakewalk *because
they already built everything for me at their expense*.

What possible reason would I have for not taking advantage of it?

You'll give me data on your supporters, your allies, your
movements, their movements, your family, their families, your
friends, their friends, you employer, their employers, their
spending habits, their operating systems, their web browsers
and mail clients, your meetings -- and much more.

I'm going to end up knowing far more about you and your people
than YOU know.

If you're trying to "liberate" someone or something, the first thing
you need to do is liberate yourself from "social networks".  You should
be trying as hard as you possibly can NOT to generate this data/metadata
at all, anywhere -- instead of not only doing so deliberately, but doing
it in a place that you have zero control over and that your adversaries
can access far more easily than you can.  (Please don't even try to tell
me stuff like "my Facebook group is private".  The only possible response
to a fairy tale like that is mocking laughter.)

If you insist on blundering ahead with "social networks" anyway, because
you're too stubborn to listen or too naive to think it can happen to
you, then as soon as you become a problem for an adversary with the
requisite resources -- that is, as soon as you become effective at
annoying someone with money or power -- they're going to exploit this.

---rsk

p.s. And as if this wasn't enough, in case you haven't noticed, the US
is now demanding "social network" passwords from people entering the
country.  Howls of protest have gone up, and a joint letter from a
coalition of human rights and civil liberties organizations has been
penned.  The combined impact of all this will be zero.  This administration
doesn't care for facts or reason or petitions or protests, only about
imposing its will.  All that's necessary is shouting "TERRORISM!" repeatedly
and accusing opposers of weakness and lack of patriotism and supporting
the bad guys: this is more than enough to get the stupid segment of the
population -- which is the majority -- to support this nonsense.

And by the time it's replaced with a sane one, IF it's replaced with a
sane one, the damage will be done: this 

Re: [liberationtech] Liberationtech List Reminder

[Rich Kulawiec]

On Thu, Feb 02, 2017 at 07:30:15PM -0500, Jos? Mar?a Mateos wrote:
> I think what you are describing is better accomplished by software like
> Discourse (https://www.discourse.org/), which is the discussion engine
> behind popular sites such as BoingBoing.net. This, however, presents the
> danger of making the mailing list redundant (I prefer the mailing list
> format, but that is just a matter of preference; I understand other people
> prefer web-based systems).

It's not just a matter of preference: mailing lists (and Usenet) are
inherently and markedly superior to web-based systems.  It's not even
close.  It's a serious strategic blunder to downgrade to the latter.

Let me give you just *some* of the reasons why:

1. They're asynchronous: you don't have to interact in real time.
You can download messages when connected to the 'net, then read
them and compose responses when offline.  (This has special
revelance to this group.)

Also remember: not everyone is as fortunate and wealthy as you
are.  There are people using the Internet who have connections
that run at dialup speeds, and/or are only available sporadically,
and/or are heavily censored at the behest of their governments.
Novices ignore this reality.  Experienced people architect for it.

2. They work reasonably well even in the presence of multiple outages
and severe congestion.

3. They're push, not pull, so new content just shows up.  Web forums
require that you go fishing for it.

4. They scale beautifully.

5. They allow you to use *your* software with the user interface of *your*
choosing rather than being compelled to learn 687 different
web forums with 687 different user interfaces, all of which
range from "merely bad" to "hideously bad".

6. You can archive them locally...

7. ...which means you can search them locally with the software of *your*
choice.  Including when you're offline.  And provided you make
backups, you'll always have an archive -- even if the original
goes away.

I've seen WAY too many web-based discussions vanish forever
because a host crashed or a domain expired or a company went
under or a company was acquired or someone made a mistake or
there was a security breach or a government confiscated it.

8. They're portable: lists can be rehosted relatively easily.

9. (When properly run) they're relatively free of abuse vectors.

10. They're low-bandwidth, which is especially important at a point in
time when many people are interacting via metered services that
charge by the byte and are WAY overpriced, and getting more
overpriced every day.  This will get worse, not better,
with telecom industry consolidation and deregulation.

11. They impose minimal security risk.

12. They impose minimal privacy risk.

13. They can be freely interconverted -- that is, you can move a list
hosted by A using software B on operating system C to
host X using software Y on operating system Z.

14. They're archivable in a format that is likely to be readable long
into the future.  (I have archives of lists from the early 1980's.
Still readable with contemporary software because they're in
mbox format.  I see no sign that this will cease to be true.)

15. They can be written to media and read from it.  This is a very
non-trivial task with web forums: just try doing the equivalent
of #13 above.  Good luck with that.

Also highly relevant for this list: it's not a hard technical
problem to sneakernet a mailing list or a newsgroup across a
border on a USB stick or a memory card or a CD/DVD.

16. They handle threading well.  And provided users take a few seconds
to edit properly, they handle quoting well.

17. Numerous tools exist for handling mbox format: for example, "grepmail"
is a highly useful basic search tool.  Most search engines
include parsers for email, and the task of ingesting mail
archives into search engines is very well understood.
Excellent archiving tools exist as well.

18. The computing resources require to support them are minimal --
CPU, memory, disk, bandwidth, etc.  I set up an instance
of Mailman for someone that's working perfectly fine on a
10-year-old laptop.

19. Mailing lists interoperate.  I can easily forward a message
from this list to another one.  Or to a person.  I can
send a message to multiple lists.  I can forward a message
from a person to this list.  And so on.  Try doing this
with web forum software A on host B with destinations
web forum software X and Y on hosts X1 and Y1.  Good
luck with that.

20. Mailing lists can be uni- or bidirectionally gatewayed to
Usenet.  (The main Python mailing list is an example

Re: [liberationtech] Can you confirm these are not best practices for handling disclosure?

[Rich Kulawiec]

On Mon, Jan 30, 2017 at 05:49:08PM -0500, Zak Rogoff wrote:
> Is anyone who's knowledgeable about disclosure policies able to take a
> look at it and share your thoughts?
> 
> To me, it looks like it's not much of a protection for the researchers,
> because it's totally voluntary and apparently allows companies to ignore
> it if they make such arbitrary judgements as that the security
> researcher didn't give them a "reasonable" amount of time between
> private and public disclosure.

You're correct.  This policy is worthless, as are -- to a good first
approximation -- all the "responsible disclosure" policies I've seen.

Let me explain why I say that.

First, these are all constructed based on the supposition that security
researchers owe the companies in question something.  But we don't.
We're not their employees or business partners: we owe them NOTHING.

Now, we may *choose* to give them something -- like a heads-up about
a bug -- because we think it's a good idea or because we think it's
a nice thing to do or because it's Thursday -- but the fact that
we may exercise that choice does not magically turn it into an obligation.

Second, it is the responsibility of companies to release software
(firmware, whatever) without security issues.  They often fail to do so,
because they use poor development practices (e.g., closed source),
because they rush its development (e.g., nearly everyone), because they
skimp on QA (also nearly everyone), and because  -- particularly in the
case of DRM -- they focus far more on denying users use of their own
computing hardware than they do on protecting users' security and privacy.

Let's be clear: a failure to do that is a lapse in *their* responsibility.

We're not required to compensate for all that.  We're not even required
to try.  It's not our product.  It's not our company.  We are not required
to spend our money and our time doing the things that they were unwilling
to spend their money and their time on.  (And after all: if they *did*
spend sufficient money and time, there would be little if anything for
us to find.)

Third, by now we all know that the playbook for companies presented
with a security problem is some combination of:

A. Deny
B. Delay
C. Obfuscate
D. Threaten reseacher
E. Attempt to censor
F. Litigate
G. Relabel as feature
H. Deny and delay and obfuscate some more
I. Reluctantly fix it poorly, likely introducing a new problem
J. Take credit
K. (later) Release new product with same problem, return to (A)

These "responsible disclosure" policies are an attempt to facilitate
this approach by recasting the researcher's side of it as somehow
"responsible" for THEIR side of it.

This leaves researchers with various options, which I'll boil down
to roughly two approaches:

1. Try to do it their way.  It's more likely that this will
results in threats, censorship, litigation and possibly
prosecution than in a timely, accurate, complete fix
and credit where it's due.

2. Don't try to do it their way.  Blow this off and either
publish anonymously, or sell the vulnerability on the open market.

Vendors have only themselves to blame for this.  Had they not,
in the aggregate, accrued a long and sordid history (which they're
adding to every day) then perhaps other choices would be viable.

Fourth, "responsible disclosure" policies are based on the happy
delusion that one researcher has found has ONLY been found (and
found recently) by that researcher and not by half a dozen others
(and some time ago).

This would be convenient, and perhaps some of the time it's true
(although there is no way to prove it, only the opposite) but it's
not a solid operating assumption.  Software comes under scrutiny
because it's new, or it's perceived as important, or because it's
used in critical roles, or because it has a history of problems,
or because the vendor has a history of problems, or because the
vendor is a jerk, or because it resembles other software with
problems, or because it's deployed at a target, or for myriad
other reasons that would take up pages.  But the point is that
if it is of interest to one person, there are plenty of possible
reasons that it's of interest to other people.

Thus when researcher A dutifully does the responsible disclosure tango,
there is absolutely no way to know that researcher B quietly (and
profitably) sold the exact same thing to parties unknown three months
ago, or that researcher C, who happens to work for a nation-state, has
been happily exploiting it for two years, or that researcher D will
come across it tomorrow.

The myth of responsible disclosure is that these things never
happen and can't happen, and thus responsible disclosure actually
protects the public.  And maybe sometimes it does.  But it's
not a good bet, and as the number of researchers and the sophistication
of their tools and the 

Re: [liberationtech] How do I unblock Symantec's spam service?

[Rich Kulawiec]

I'm attempting to assist with this off-list.

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

Re: [liberationtech] Price of the #MuslimBan

[Rich Kulawiec]

On Mon, Jan 30, 2017 at 07:35:40PM +0100, ernesto ortiz wrote:
> Really? Are you sure that Republicans here -all of them- are so bad that
> undoubtedly do not hesitate to demonize the others? 

I am quite certain that Trump's supporters (which is the set of people
I'm talking about and is clearly a set that only partially overlaps
"Republicans") will do exactly that because they have been saying so,
very loudly, very often, very unmistakably, for a long time.  And you
know what?  I take them at their word.  I believe them.

Have you not been listening?

---rsk

p.s. They're doing it again RIGHT NOW, as you're reading this.
They're thrashing Starbucks because the CEO announced that they would
hire 10,000 refugees over the next 5 years.  Now we could all nitpick
that (and we probably will) but at least it's an attempt to do
something humane and decent and compassionate.  Consider carefully
what kind of a person has a problem with that and then tell me how
I could possibly demonize them any more than they already have.

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

Re: [liberationtech] Price of the #MuslimBan

[Rich Kulawiec]

> I've tried to avoid commenting too much on Trump's election to avoid
> demonizing Republicans and people in my network who support him.

And that's fine, and noble, and nice of you.  But understand very,
VERY clearly: they will not hesitate to do that to you.

If you're not a (a) white (b) Christian (c) American citizen then you're
going to be targeted.  It's not a question of "if", only of "when".
(And some people who are all three will be targeted anyway: women,
LBGTQ, journalists, academics, scientists come to mind immediately.)

When fascism comes to America it will be wrapped in the flag
and carrying a cross.
--- Sinclair Lewis

This current episode is just a test to see what kind of reaction ensues.
It's a probe for weaknesses.  It has NOTHING to do with stopping terrorism:
in fact, it's designed to increase the probability of attacks -- because
that will make subsequent steps much easier.  (Note the careful exemption
of majority-Muslim countries in which Trump owns hotels/resorts.)

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

Re: [liberationtech] Boston event: How nonprofits can use Facebook to broadcast their impact??? (Feb 27th)

[Rich Kulawiec]

[ Yes, I know I'm following up my own message.  There's a reason. ]

Here's what Facebook Live did this week:

Facebook Live 'broadcasts gang rape' of woman in Sweden
http://www.bbc.com/news/world-europe-38717186

Police in Uppsala were contacted in the morning by a woman who
said she had seen a gang rape broadcast in a closed group on
the site.  "You have been raped," one of the men said at the
end of the video and then laughed, according to the viewer.
Police later confirmed they, and "many" others, had seen the
footage.  The Facebook group is said to have several thousand
members.  Police confirmed that they had found three men, aged
between 19 and 25, and one woman at a local apartment.  The
men were arrested on the spot.

Read the whole article, all the way to the end.  It shouldn't be
surprising to anyone who's been paying attention: of *course*
a company founded by a sociopath repeatedly exhibits sociopathic
behavior: it's profitable.  Why would one expect anything else?

Now explain to me why you think it's a good idea to do anything
other than firewall their network ranges permanently.

---rsk

-- 
As democracy is perfected, the office of president represents, more and more
closely, the inner soul of the people.  On some great and glorious day the
plain folks of the land will reach their heart's desire at last and the
White House will be adorned by a downright moron. -- H.L. Mencken 7/26/1920

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

Re: [liberationtech] Boston event: How nonprofits can use Facebook to broadcast their impact??? (Feb 27th)

[Rich Kulawiec]

On Fri, Jan 20, 2017 at 08:01:56AM -0500, Deborah Elizabeth Finn wrote:
> Tech Networks of Boston (TNB) and TNB Labs (TNBL) are pleased to invite you
> to a Roundtable session on how nonprofits can use Facebook to broadcast

I can see that I'm going to have to post some basic security/privacy
recommendations again.  But in the interim, here's the short version:

Facebook is what you do to your enemies, not your allies.

---rsk

-- 
As democracy is perfected, the office of president represents, more and more
closely, the inner soul of the people.  On some great and glorious day the
plain folks of the land will reach their heart's desire at last and the
White House will be adorned by a downright moron. -- H.L. Mencken 7/26/1920

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

Re: [liberationtech] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[Rich Kulawiec]

On Sun, Jan 15, 2017 at 03:52:57PM -0200, Daniel Arnaudo wrote:
> Also anyone using Yahoo Mail on this thread might want to reconsider if
> they're concerned with privacy.

The same can be said of AOL, Hotmail/Outlook, and Gmail.  (Even though
I think very highly of Google's security people.)  The combined attacker
budget for compromising these is enormous and it seems overly optimistic
to me to assume that nobody's managed to pull it off yet.  (Maybe not in
full, but at least in part.)  I hope I'm wrong.  I'd *like* to be wrong.
I don't think I'm wrong.

---rsk

-- 
As democracy is perfected, the office of president represents, more and more
closely, the inner soul of the people.  On some great and glorious day the
plain folks of the land will reach their heart's desire at last and the
White House will be adorned by a downright moron. -- H.L. Mencken 7/26/1920

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

Re: [liberationtech] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[Rich Kulawiec]

On Sun, Jan 15, 2017 at 08:47:51AM -0600, Andr??s Leopoldo Pacheco Sanfuentes 
wrote:
> Anybody serious about decryption cannot use standard social networks,
> which are predicated on access to private data for marketing and
> "development" (eg, as test data for new features, debugging, etc)
> purposes, and naturally open to government intrusion with few
> exceptions that have proven irrelevant in the final analysis [snip]

I concur completely.  I'd also like to ask a pointed question, in re
the phrase "naturally open to government intrusion":

Do you [generic you] think that everyone working AT Facebook is working
FOR Facebook?

Of course they're not.  Any intelligence agency worth its name has
long since planted their own people inside.  It's an obvious, cheap,
effective, easy, very-low-risk potentially-high-reward move.

Plus: they get paid twice.  And if caught, they don't get executed
for espionage: they just get fired.  (Fired *quietly*.  Do you really
think Facebook would want it publicly known that an Elbonian agent was
working in devops for 6 years?  Hint: what would that do to their stock
price and 4Q earnings?)  And then they get replaced.

(And please don't tell me that Facebook could stop this.  Given that
intelligence agencies routinely plant people *inside each other*,
I sincerely doubt that they'd have any trouble getting their folks
past whatever security theater Facebook uses to screen employees.)

The same is no doubt true of any sufficiently-large "social network"
or cloud computing operation: Twitter, AWS, etc.  All that fruit hangs
much too low to be left unpicked.  The upside is huge, the downside
is negligible.

So I think the operational question is not "are they present?" --
the question is "what do they have access to?"

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

Re: [liberationtech] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[Rich Kulawiec]

Who owns WhatsApp?  Facebook.

What is the purpose of Facebook?  Surveillance and data acquisition.
They've spent billions building the infrastructure for it.  They have
expanded the nature and scope of it at every possible opportunity.
They have been caught -- over and over and over again -- lying about it.

So now, suddenly, for no particular reason, they're going to reverse
course, do the exact opposite of what they've always done *and* they're
going to tell the truth about it?  After spending billions to acquire
WhatsApp and all that valuable data?  Yeah.  That's gonna happen.

Quoting from the same story referenced earlier:

"In August 2015, Facebook announced a change to the privacy
policy governing WhatsApp that allowed the social network to
merge data from WhatsApp users and Facebook, including phone
numbers and app usage, for advertising and development purposes."

And let me quote Dave Burstein's take on this from Dave Farber's IP list:

> I just read both articles twice. I'm not a security expert, but I think I
> see what's happening here.
> 
> I believe the Guardian article was correct in the claim that Facebook
> could, sometimes read some encrypted messages, using a feature included to
> deal with users switching SIM cards, etc.  Depending on security settings,
> the user may not even be aware of the switch. Facebook "cooperates with
> legal government requests."  In England and probably other countries,
> the security agencies can legally request just about anything.
> 
> The Guardian probably was misleading writing "Facebook and others,
> could intercept.  The Guardian shouldn't have called it a "backdoor"
> without qualifying the comment with "for Facebook & Governments."
> 
> It appears that no one could use this without Facebook's help.
> Governments presumably could get Facebook's help.  It would cost Facebooks
> $B's to be shut out of India or Russia, $10's of billions if it prevented
> them from China.  I see no reason to believe Zuckerberg would resist to
> the end that kind of pressure.  Apple wouldn't; they just kicked the New
> York Times out of the App Store in China.  Google might, as evidenced
> by their willingness to exit China.
> 
> Facebook's answer to Gizmodo was so misleading the author should not
> have written the story that way. Facebook denied that this was a way for
> outsiders to crack What'sApp, which wasn't the Guardian's claim.
> But Facebook didn't address the substantive claim in the article, that
> Facebook and the governments it cooperates with can intercept (some,
> sometimes.)

I pointed out much the same thing on this list years ago.  If China
goes to Facebook and says "put in a backdoor or stop doing business here",
Facebook will put in a backdoor.  If Russia goes to Facebook and says
"give us a full data feed or stop doing business here", Facebook will
give them a full data feed.  Of course they will: there's no way they're
going to leave all money on the table.

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

[liberationtech] Fwd: [WhatsApp backdoor allows snooping on encrypted messages]

[Rich Kulawiec]

It is long *past* time for everyone involved in the kinds of activities
discussed here to completely and permanently excise Facebook's
services/products from their computing environment.  No excuses.

---rsk


- Forwarded message from Richard Forno  -

> To: Infowarrior List 
> Date: Fri, 13 Jan 2017 08:18:42 -0500
> Subject: [Infowarrior] - WhatsApp backdoor allows snooping on encrypted
>   messages
> 
> 
> WhatsApp backdoor allows snooping on encrypted messages
> 
> https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages
> 
> A security backdoor that can be used to allow Facebook and others to
> intercept and read encrypted messages has been found within its WhatsApp
> messaging service.
> 
> Facebook claims that no one can intercept WhatsApp messages, not even the
> company and its staff, ensuring privacy for its billion-plus users. But
> new research shows that the company could in fact read messages due to
> the way WhatsApp has implemented its end-to-end encryption protocol.
> 
> Privacy campaigners said the vulnerability is a ???huge threat to freedom
> of speech??? and warned it can be used by government agencies to snoop
> on users who believe their messages to be secure. WhatsApp has made
> privacy and security a primary selling point, and has become a go to
> communications tool of activists, dissidents and diplomats.
> 
> < - >
> 
> Boelter reported the backdoor vulnerability to Facebook in April 2016,
> but was told that Facebook was aware of the issue, that it was ???expected
> behaviour??? and wasn???t being actively worked on. The Guardian has
> verified the backdoor still exists.
> 
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] [FoRK] [zs-p2p] Thank you for choosing cyberpunk dystopia.

[Rich Kulawiec]

On Sat, Dec 31, 2016 at 12:16:41AM -0800, Stephen D. Williams wrote:
> If we all find a way to solve the anti-terrorism problem, or at least
> carve out space for it to be solved, we'd be less at odds for protecting
> privacy etc.  There are some promising ideas I think, but all solutions
> so far involve painful and often unacceptable tradeoffs.

A rather obvious -- but nearly entirely overlooked -- approach is
to refuse to be terrorized.  That is, after all, the point: blowing up
buildings or planes and killing people are merely tactics in pursuit of
that strategic goal.  While the immediate targets of terrorist acts
are those involved in the incidents themselves, they are few in number --
and many of them end up dead.   The real targets are you and me
and everyone else because (a) there are a lot more of us and (b) we're
not dead.  The goal is to make us afraid, and thus to provoke
ill-considered/hasty/self-destructive responses.  (Why do you think
that terrorists take pains to make sure their acts are well-documented?
Terrorism that nobody notices or pays attention to doesn't work well,
even if it does a great deal of destruction and kills a lot of people.)

Terrorism is an attack against our emotions, leveraging the fact that
we have evolved to have strong fight-or-flight responses and those
are wired very deeply into our psyches -- so deeply that we have
difficulty overcoming them with rational thought.

And so far, it's working beautifully: look at the insane response of the US
to the 9/11 attacks.  Their perpetrators could not possibly have hoped for
a better outcome.  No, I don't meant the destruction of the WTC etc. --
that's entirely unimportant.  I mean the collective national response
over the past 15 years, which has been to give these terrorists exactly
what they wanted *and* to pay for it with our blood, treasure, privacy,
and freedom.

The correct response to 9/11 -- which I'll admit that I didn't realize
at the time -- was for everyone to get up the next day and go to work
like nothing happened.  Clean up the mess, bury the dead, and keep right
on going.  Refuse to be intimidated or provoked, refuse to be manipulated,
refuse to be afraid, refuse to play along.

Of course that doesn't defeat an act of terror: but it defeats terrorism
as a strategy.  And that is something that can't be done any other way.
Only we can do it.  By individually and collectively refusing.

Let me give you a case study: Erika Brannock.  Erika was standing
near the finish line of the Boston Marathon in 2013, waiting for her
mom to run by, when the bombs went off.  She (and her sister) were very
badly injured.  Erika lost a leg, and endured a long, slow recovery in
hospitals and physical therapy and everything else that you might expect.

Her mom went back to run the Boston Marathon in 2014 -- one year
after the bombing.  And Erika went back to watch.

AND STOOD AT THE FINISH LINE AGAIN.

That, ladies and gentlemen, is how it's done.

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

Re: [liberationtech] Isaacson: The internet is broken. Starting from scratch, here's how I'd fix it.

[Rich Kulawiec]

On Thu, Dec 15, 2016 at 11:31:20AM -0500, Thomas Delrue wrote:
> A great start to fixing the internet would be to stop using closed sites
> (of which LinkedIn is one). This would go a ways to bringing us back to
> a truly _distributed_ system, as the internet was intended to be,
> instead of an internet that is centralized in the hands of a few, very
> powerful corporations that hold us in a feudal lock.

Strongly seconded.  (Also, in this particular case: LinkedIn are notorious
spammers.)  Get off Facebook.  Get off Twitter.  Stop using Yahoo and
Google to host mailing lists.  (They're really terrible at it anyway.)
And so on.  It continues to amaze and appall me that even people on this
very list continue to use and support the operations that most want to
created walled gardens, a la AOL.   In case it's not obvious, and it really
should be: they are NOT your friends.  They are NOT your allies.  They
are NOT your supporters.  Their only value is profit, and if they can
maximize it by damaging you (or anyone else) they will not hesitate to
do so.

Like this.  Here's an example of one of those walled gardens and of
the damage it's doing (h/t to Lauren Weinstein):

50 million people in Myanmar can now get Facebook, and they're
spreading a trumpian ethnic cleansing movement

http://boingboing.net/2016/12/15/50-million-people-in-myanmar-c.html

50,000,000 people are now able to get Facebook, in other
words. The net has delivered a complex basket of social
changes, among them a revival of the country's ugly, murderous
history of ethnic cleansing, fueled by blood libels about
minority Muslims attacking the Buddhist majority. The new
incitements to violence are travelling hand in hand with news
about Trump and his promise to end Muslim migration into the
USA. Trump's election is being used to normalize and justify
ethnic cleansing movements in Myanmar ("We should do like
America and do it here too. No more Muslims!").  As was the
case in earlier eras of the internet's history, these new
users equate the net with the service they use the most (once
it may have been "Netscape" and "the net"; then "the web" and
"the net"; then "Google," etc) -- they use "Facebook" and
"internet" interchangeably. This is due to increase, as
Facebook has sold the carriers on its "Free Basics" system --
a net discrimination deal with the mobile carriers, who take
bribes from Facebook to exempt the company (but not its
rivals) from their data-caps.

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

Re: [liberationtech] E-Voting

[Rich Kulawiec]

On Sun, Dec 11, 2016 at 10:08:18PM +0300, Zacharia Gichiriri wrote:
> I still believe e-voting could substantially improve election outcomes [...]

You may, of course, believe whatever you wish.  But you are completely
wrong on this point: e-voting is a disaster for election outcomes.
I suggest that you study the issue in depth, with a focus on the
security issues, for a few years -- at which point I doubt I'll have
to convince you that you're wrong: you'll have convinced yourself.

Voting systems have certain requirements for privacy, security, integrity,
reliability, etc.   Unfortunately, the privacy, security, integrity,
reliability, etc. problems that are now pervasive throughout computing
and Internet operations are antithetical to those.  In other words, the
things that voting systems absolutely must have are just about exactly
the things that contemporary Internet computing environments are
terrible at.  And the situation is getting worse, not better [1] -- so at
this point in time there is no reason whatsoever to even put e-voting
on the table for discussion.  It's not just a bad idea, it's an insanely
bad idea.

A good place to begin learning about this topic in depth is this page:

Douglas W. Jones on Voting and Elections
http://homepage.divms.uiowa.edu/~jones/voting/

That page has a large number of links to articles, reports, essays, papers,
etc. on these topics -- and to many sites which contain still more.  It's
an excellent jumping-off point for enquiry into many aspects of this problem.  

---rsk

[1] It may get much worse over the next few years, if major governments
succeed in mandating hardware and software backdoors in devices and code.
If that happens, then some/many/most end-user devices will be pre-compromised
at the factory, which considerably lowers the bar for attackers: they don't
have to create a security hole, there's already (at least) one built-in.
All they have to do is figure out how to exploit it, which is usually
a much easier task.

And it WILL get much worse over the next few years, as myriad companies
eager for quick profits deploy IoT devices that have either (a) ludicrously
bad security or -- more likely -- (b) no security.  It's only a matter
of time, and a short time at that, until these devices are conscripted
into botnets and used to attack end-user networks from inside.
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] E-Voting

[Rich Kulawiec]

On Sat, Dec 10, 2016 at 12:39:39PM +0300, Zacharia Gichiriri wrote:
> I think the subject of the discussion should be: How can we make e-voting
> more secure and credible?

Answer: don't use it.  Period, full stop, end of discussion.
Any suggestion that e-voting can be made secure is delusional.

Simple paper-based systems can be manipulated as well (study the colorful
history of elections in Chicago) but (a) it's much harder to pull off
with the kind of precision required to avoid making it obvious
(b) it doesn't scale nearly as well (c) it requires a relatively
large conspiracy (d) which means many people (e) which means a high
probability someone will screw up and (f) and even if they don't,
someone will probably talk about it.  Also (g) these attacks are very
well-known and well-understood, which means (h) so are the defenses
against them and (i) these attacks/defenses are relatively symmetrical,
which means defenders have a good chance -- unlike in e-voting, where
attackers have a many-orders-of-magnitude advantage.

You can have something vaguely resembling democracy [1] or you can
have e-voting.  Choose one.

---rsk

[1] I chose that phrase deliberately.  We're talking here about voting
systems, in the general sense of that term.  We're not talking about
the larger question of the overall electoral process, which of course
we all know is frequently manipulated from within (e.g., gerrymandering,
specious "voter ID" laws, polling locations, hours, equipment,
and staffing, etc.) and now we know is also manipulated from without
(e.g., Russian tampering with the recent US election).  These are not
technological problems per se, however, and neither are their solutions.
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] E-Voting

[Rich Kulawiec]

On Fri, Dec 02, 2016 at 02:26:49PM -0500, Andres wrote:
> Rich, the article you link to talks about the risk of one individual voting 
> machine being tampered with.

I think you missed the point Schneier was making.  It's NOT about one
individual voting machine, it's about attacker budgets.  Look at the
big picture, not the small one he used to illustrate the point.

An attacker with a $100M budget (a conservative estimate in 2004, now
clearly only a fraction of that available) isn't going to use it to
attack just one voting machine: that'd be a poor return on investment.
A 2016 attacker, who could have a budget an order of magnitude larger,
would likely attack in a systemic, distributed -- and subtle -- fashion.

> When voting online you can use any hardware (PC, Mac, Linux, iPhone
> or Android phone, public or private) to vote and later verify your vote.

That last part ("...later verify your vote") disqualifies the system
from use.  This is a well-known problem with election systems (electronic
of otherwise): if you can verify your vote at some later point, then
so can someone else.  And if someone else can verify your vote, then
you can be induced (willingly or otherwise) to vote as directed.

And even if that's addressed, there's a massive problem with this approach,
or ANY approach that allows voters to use their own computing systems.
End-user systems are compromised in enormous numbers.  This is a well-known
problem that's been discussed at length for much of this century, e.g.:

Vint Cerf: one quarter of all computers part of a botnet
http://arstechnica.com/news.ars/post/20070125-8707.html

When Cerf made that estimate, I thought -- based on my own research and
consultation with others doing similar work -- that it was too high by
perhaps 25% to 50%.  With the benefit of hindsight, I think he was right
and I was wrong.  Given the passage of time since then, the numbers are
undoubtedly far higher.  (Doubly so since nothing truly effective has
been done to reduce them or even slow down the growth rate, and many
things have happened to make the situation much, much worse.)  I suspect
that the number of compromised systems is probably ten times what it was
ten years ago and no doubt the mass deployment of IoT devices with horrible
(or no) security will make this even worse.  And if various governments
are successful in forcing vendors to build in backdoors, it will get
MUCH worse in a big hurry.

Why does this matter?  Because (as I've said ad nauseum) if someone else
can run arbitrary code on your computer, it's not YOUR computer any more.

If your phone is compromised, and you use it to vote, and you later
use that phone to verify that your vote was cast as you think it was,
how do you know that what you're seeing on the screen is correct?
Why couldn't the same malware that redirected your vote from candidate
A to candidate B also show you that you voted for candidate A?  (That isn't
a particularly challenging software problem given that the former has
been solved.)

Remember: it's not your phone any more.  It's theirs.  You may walk
around with it, you may use it, but you don't own it.  Not any more.
So why would you expect someone else's phone to behave as you think
or believe or want it to?

Does that malware exist?  I don't know.  But I do know that if a
sizable enough population starts using their phones to vote, it WILL
exist, because it will become worth someone's effort.  (And by the way:
this will require far less than even the small $100M budget from 2004.)

Substitute "tablet" or "laptop" or "smart home IoT device" or "desktop"
or whatever without loss of generality for "phone". 

Any voting system which allows voters to use their own computing devices
is fatally flawed and must be dismissed, with prejudice, immediately.

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

Re: [liberationtech] E-Voting

[Rich Kulawiec]

On Thu, Nov 17, 2016 at 06:02:36PM +0200, Andres wrote:
> Could Intel and AMD team up and hide a backdoor on the vote counting
> server's CPU? It certainly is in the realm of possibilities. However,
> it's extremely cost prohibitive, risky and as a result unlikely.

It's not cost-prohibitive for someone (not necessarily Intel or AMD)
to do this.  Not any more.

Read this:
 
Stealing an Election (Schneier on Security)
https://www.schneier.com/crypto-gram/archives/2004/0415.html#4

A lot of articles and papers and reports been written about the problems
of e-voting.  That little essay might be the most important one.  If you've
gotten to this point and haven't read it: read it.  Bookmark it.  Read it
again later.  And again.

Now consider that it was written in 2004.  Scale the number up to account
for 12 years of dramatically increased campaign expenditures and the usual
inflation.  Factor in that there are no longer merely individuals or
parties/groups trying to sway the outcome of elections, but nations.

It is not unreasonable, at this point, to presume an attacker budget in
the billion-dollar range.

Which means that lots of things we might once have ruled out as absurdly
cost-prohibitive...aren't.

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

Re: [liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[Rich Kulawiec]

On Mon, Nov 02, 2015 at 09:13:08PM +0100, carlo von lynX wrote:
[ a bunch of good points and one thing I'd like to expand/elaborate on ]

> Correct. Still it makes no sense for benevolent nodes to fabricate
> false warnings about insecure TLS usage. Question is if it makes
> sense for malevolent nodes to do so, maybe in order to distract
> from something else.. or if it doesn't make sense for them either.
> If it doesn't, then warnings in "Received" headers are useful even
> if they aren't securely delivered.

In the sense that those warnings indicate a "best case", and that
reality might be worse, yes, it does make sense to consider them.

But let me return to the first sentence above.  No, it doesn't make
any sense for benevolent (or let's say, neutral) nodes, to fabricate
false warnings, but those same nodes exhibit broken behavior all day,
every day...thus furnishing us with an ongoing stream of evidence
that we shouldn't trust their expressed opinions on *anything*.

The sad reality is that in the race to the bottom (in terms of
incompetence and negligence) the 500-pound gorillas of the email
world are leading.  (Which is another reason why I counsel everyone
to avoid them: security/privacy aside, they're junk.)  We see
erratic, aberrant, and abusive behavior emanating from these
operations constantly.  So presuming that their "Received" headers
are somewhere between "right" and "fiction" is actually a
pretty good working assumption.

One of the points that I've made for many years is that competently
managed operations do NOT emit abuse on a systemic and chronic basis.
Point problems?  Sure.  Temporary problems?  Sure.  But when the abuse
goes on for years and clearly pervades the operation, we are left with
only two possible conclusions:

1. They're doing it on purpose.
2. They're not doing it on purpose.

If it's (1), then they're malevolent and cannot be trusted.
If it's (2), then they're incompetent and cannot be trusted.

Either outcome has the same operational impact: we can't believe
anything their servers tell us, because it might be correct or might
be a mistake or it might be a deliberate fabrication.  Absent
evidence not available to us, we not only don't know, we can't know.

It's a pity, really, that we've arrived at this situation.  But here
we are, and there is no sign that it'll change -- why should it?

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

Re: [liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[Rich Kulawiec]

On Sun, Nov 01, 2015 at 06:42:23PM +0100, carlo von lynX wrote:
> Let's frame the threat models. Bulk collection probably does 
> not include using OS backdoors so the suggestion to use mutt
> on BSD isn't wrong, but not necessary to move a step forward.

And why not?  If the endpoints aren't reasonably secure, then what happens
in the middle doesn't matter.  We *could* completely re-architect SMTP
from scratch, design and build in as much security as we possibly can,
but if someone foolishly insists on using Windows or a smartphone to
send/receive mail, it won't matter a bit.  (I trust everyone is aware
that Windows 10 is spyware pretending to be an OS.  It doesn't *have*
to be backdoored en masse, it ships that way from the factory.  And
"smartphone security" is essentially an oxymoron.)

So at this moment -- without a completed, peer-reviewed, implemented
replacement for SMTP globally deployed -- the single biggest things that
end users can do are (a) use a hardened OS (b) use a hardened email client
(c) do not use webmail (d) do not use freemail providers.  These are easy
steps well within everyone's reach.  They don't solve all the problems
(and they don't try to) but they tackle the obvious/easy ones.  They raise
the bar for attackers and they only require using things *that already exist*.

> Do the new "Received" headers really reflect such info
> and how would you explain what certain headers mean to
> the end user?.. given the "Received" headers are accurate,
> as questioned in previous mail.

I'm not questioning them, I'm pointing out that the hard cold
reality is that you CANNOT trust any that weren't put in place
by your own MTA.  Period, full stop, end of discussion.

Here's an example from this morning, reformatted for readability.
This was an obvious phish sent as part of a spam run:

Received: from
cloud.3ms.ca (cloud.3ms.ca [69.167.135.45])

Received: from
cpc3-nmal18-2-0-cust792.croy.cable.virginm.net ([94.174.7.25] 
helo=HMRC.gov.uk)

The first one was added by my local MTA (that is: running on my system),
therefore it can be trusted.  The second may be accurate: it may be that
this message really did originate from on a possibly-zombie'd end-user
system connected via cablemodem that decided to HELO to cloud.3ms.cas as
hmrc.gov.uk.  Or it may be that this message was never anywhere near the
virginm.net network operation, that it originated on cloud.3ms.ca itself.
There is absolutely no way to know which *unless* you have access to
the logs on cloud.3ms.ca.  (And if it's compromised, well, then those
logs are worthless anyway.)

So before we even get to the question of whether or not that putative
prior hop was via TLS, we have to answer the question of whether or
not that hop *even existed*.  And we can't, because we are not in
possession of the information necessary to do so.

Anyone who actually works with mail servers sees this sort of
thing all day, every day.  This is common knowledge among everyone
with more than novice-level skills.  Sometimes the Received headers
are reasonably sensible; sometimes they're obviously fiction.  It takes
a combination of experience and research to determine which are
plausible -- and that's as far as it goes.  We can never make
definitive pronouncements *unless* we have access to the relevant
logs present on the system(s) that handled the hop(s) in question.

So while it's possible to write code that does what the "Paranoia"
addon does, the results are just about entirely worthless.  (Doubly
so given that most end users do not run their own MTA: thus they
can trust *no* Received lines.)  The sad reality is Paranoia is
worse than nothing, because it relies on information that can be
and quite often is wrong or fabricated.

> It's less work to design a new mail system from scratch
> than to reduce the insecurities of SMTP from 31 to 30.

If you want to write a draft for SMTPv2 (or whatever it's going to
be called) and submit it to the IETF, I commend your efforts.

---rsk

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

Re: [liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[Rich Kulawiec]

On Sun, Nov 01, 2015 at 12:32:37PM -0300, fauno wrote:
> there's a thunderbird addon called "paranoia" that does this

Correction: there's a Thunderbird addon called "Paranoia" that pretends
to do this.  Everyone should know by now that you can't trust any
"Received" headers other than those written by your own MTA.  (They might
be accurate and truthful; they might be partially wrong; they might
be complete fabrications.)

Paranoia's own documentation says:

"Click on the emoticon and you'll see a list of connections
which were made before this message arrived in your inbox,
and state of encryption of each of them."

Which means that Paranoia makes the mistake of trusting headers that
can't be trusted.

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

Re: [liberationtech] Revealed: how Whisper app tracks 'anonymous' users

[Rich Kulawiec]

On Thu, Oct 16, 2014 at 04:54:35PM +0100, Yishay Mor wrote:
 Revealed: how Whisper app tracks 'anonymous' users
 
 http://gu.com/p/42bqn

It's apparently much, MUCH worse than that:

a confederacy of 'privacy' dunces:  what we found under the hood of 
an 'anonymous' chat app used by millions 

http://www.xipiter.com/musings/a-confederacy-of-privacy-dunces-what-we-found-under-the-hood-of-an-anonymous-chat-app-used-by-millions

That's a fairly lengthy article, so here's a brief excerpt:

We found many critical issues which we will catalog below in
the Technical Details section, but the short of it is that we
found that we could:

- hijack a users' account
- post (publicly or privately) as a hijacked user
- view all of a user's current and past private messages 

In the course of this work we also discovered some other things
that highlight the broader privacy issues especially as they
relate to mobile apps and anonymity promising services.

But before we go any further. We'll share a video that
demonstrates us taking over an account and retrieving past and
current messages for a hijacked user account (without the user
knowing). As of this posting, this vulnerability is yet unfixed.

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

Re: [liberationtech] Ghostery, NoScript.. add-ons frequently phone home

[Rich Kulawiec]

I think there's a more fundamental problem here.  We're all talking
about add-ons that perform various security/privacy functions.

Why are these add-ons?  Why are they not designed-in and built-in
to the browser?

Those are only quasi-rhetorical questions, because I'm pretty sure
we all know at least some of the answers to them.  But my point is
that I think we're well past the time when all of this functionality
should be baked-in to web browsers, not added on in a crazyquilt of
sometimes-overlapping sometimes-conflicting extensions all of which
have their own UI and most of which are confusing even to people who
know what they're doing.

As much as I really, really hate suggesting this, because one of the
last things we need is more software: we need a browser built from
the whiteboard up with the contemporary threat environment in mind.
And I strongly suspect that the only way to get one will be to start over.

Anybody got a few million dollars just laying around? ;)

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

[liberationtech] Fwd, time sensitive: Technologists sign on letter re CISA bill, info sharing

[Rich Kulawiec]

This came in via Dave Farber's excellent IP mailing list.  The attached
PDF (which I hope makes it through) is the letter that Jennifer's
referring to.  Note that tonight at 8 PM EDT is the deadline if you
intend to sign onto this -- see instructions in the message below.

---rsk

- Forwarded message from Dave Farber d...@farber.net -

 Date: Thu, 9 Apr 2015 14:05:30 -0400
 From: Dave Farber d...@farber.net
 To: ip i...@listbox.com
 Subject: [IP] Technologists sign on letter re CISA bill, info sharing
 
 -- Forwarded message --
 From: Jennifer Granick jenni...@granick.com
 Date: Apr 9, 2015 2:01 PM
 Subject: Technologists sign on letter re CISA bill, info sharing
 To: Dave Farber d...@farber.net
 Cc:
 
 Dave,
 
 In case you think people on IP may be interested...
 
 Tl;dr: This is a solicitation for security experts and technologists to
 sign a letter to Congress opposing purported info sharing bills that
 actually waive privacy laws and enable more surveillance. Thanks for any
 help you can give.
 
 
 
 Hello,
 
 As you may know, there are three cybersecurity information sharing bills
 pending before Congress right now. These bills would weaken privacy laws
 and enable surveillance at a time when we need stronger privacy
 protections. These are surveillance bills, not security bills.
 
 Every one of the bills is an end run around privacy laws in the name of
 improving security information sharing with the Department of Homeland
 Security (DHS). The bills define cyber threat indicators in a confusing
 manner that could include server logs, the contents of emails, damage
 estimates, and more. This kind of private data is not what is generally
 needed to secure systems. Nevertheless, the bills say that private entities
 will be immune from liability for sharing this information  with DHS (and
 other parts of government) notwithstanding any privacy laws.
 
 Surveillance reform advocates are trying to stop these bills. There is a
 lot of support in Congress and from the White House. So, to succeed, we
 need your help and we need it now. We expect the bills to come to a vote
 mid-April.
 
 As a security expert, would you be willing to sign a letter helping to
 educate Congress about what kind of information experts actually share to
 further cybersecurity and secure systems from future attack? By helping
 Congress understand what information is useful in security, we can stop a
 bill that would needlessly waive privacy.
 
 Please let me know if you can sign on by no later than 8pm ET Sunday, April
 12. Email to jennifer at law.stanford.edu your name, title and affiliation.
 We plan to use your titles and affiliations for information purposes only,
 not to indicate that your employer is also signing the letter. For example,
 my signature would be Jennifer Stisa Granick, Director of Civil Liberties,
 Stanford Center for Internet and Society* and the asterick text would say
 *Titles and affiliations are for information purposes only. If you want
 to sign but don't want to include your title or affiliation, or don't have
 one, please indicate so, and we will respect your wishes.
 
 My plan is to circulate the letter to the sponsors of the bills and to the
 rest of Congress on Monday, April 13.
 
 Please feel free to email me or set up a call with me if you have any
 questions about the bills or the letter.
 
 Once again, I can be reached at jennifer at law.stanford.edu
 
 Finally, please do forward this request to anyone you think might be
 knowledgeable about security information sharing, and interested in sighing
 the letter.
 
 For more information on these laws, you can read here:
 
 Jennifer Granick - The Right Way to Share Information and Improve
 Cybersecurity:
 http://justsecurity.org/21498/share-information-improve-cybersecurity/
 
 OTI VERSION 2.0 OF THE SENATE INTELLIGENCE COMMITTEE'S CYBER INFORMATION
 SHARING ACT IS CYBER-SURVEILLANCE, NOT CYBERSECURITY:
 http://www.newamerica.org/oti/version-20-of-the-senate-intelligence-committees-cyber-information-sharing-act-is-cyber-surveillance-not-cybersecurity/
 
 CDT Analysis of Cybersecurity Information Sharing Act of 2014:
 https://cdt.org/insight/analysis-of-feinstein-chambliss-cybersecurity-information-sharing-act-of-2014/
 
 
 
 Thank you for your time, attention, and assistance in this important matter.
 
 

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

Re: [liberationtech] Introducing The GovLab Digest: covering innovations in Governance, delivered weekly

[Rich Kulawiec]

On Tue, Feb 17, 2015 at 07:17:18PM +0100, Christian Huldt wrote:
 Who are mailchimps.com and why should I trust them?

Spammers for hire, and no, you shouldn't -- doubly so since (like many
such operations) they embed unique-per-recipient tracking links in every
message they send.  Last time I checked they were operating over 300
domains -- e.g., mcsv94.net, mcsv95.net, mcsv96.net.  This is a tactic
used exclusively by spammers who are attempt to evade domain-based
blacklisting: there is absolutely no legitimate purpose for it.

The best way for GovLab to avoid all of this is to set up a Mailman
instance in-house.  As Ken over at the PopeHat blog has astutely observed,
when you outsource your email, you outsource your reputation.  And I'll
add to that that you also surrender the privacy of your readers to third
parties unknown to you.

That's also the best way for everyone else.  If you're trying to do
something with a mailing list that Mailman doesn't do, there's a very good
chance that what you're trying to do is wrong, stupid, silly or abusive.
(Yes, Mailman is *that* good.  And it's very well supported by an active
community.  I could use anything I want -- or write my own -- but I use
it because I think I think it's the best available by a wide margin.)

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

Re: [liberationtech] liberationtech Digest, Vol 231, Issue 1

[Rich Kulawiec]

On Wed, Jan 28, 2015 at 01:19:05PM -0500, Joe Hall wrote:
 Mailing lists like this often include a header element like this that
 you can use to unsubscribe yourself:
 
 List-Unsubscribe: 
 https://mailman.stanford.edu/mailman/options/liberationtech,
  mailto:liberationtech-requ...@lists.stanford.edu?subject=unsubscribe

You're right, this list carries RFC 2369 headers.[1]  But it's even
simpler than that.

Every correctly-run mailing list on the Internet has an associated
address of the form:

[listname]-request@[listhost]
as in:
liberationtech-requ...@lists.stanford.edu

I say correctly because it's been a standard for 18 years:

Mailbox names for common services, roles and functions
http://www.ietf.org/rfc/rfc2142.txt

and it was a very frequently-used convention for 15+ years before that.
All sensible mailing list management software (e.g., Mailman, which
operates this list) supports it.

So all you need to remember is that tacking -request onto the left
hand side of any mailing list's address should connect you to the entity
(probably software; could be a human, but probably not) that can subscribe
and unsubscribe you, and change your list options (if applicable).

But wait!  There's more.

You should also be able to reach the human(s) behind any mailing list
by using -owner in the same way, e.g., if there's a mailing list whose
address is j...@example.com, then joe-ow...@example.com should reach
whoever's behind it.  Unlike -request, which these days almost certainly
connects to software, -owner should connect you to people.  So keep in
mind that messages to -request should use the proper syntax (send help
and only that if you don't know) but messages to -owner should use
complete sentences, because otherwise you probably won't be understood.

And finally, if all else fails, it has been an absolutely mandatory
requirement since approximately forever (okay, RFC 822, which dates from
1982) that postmaster reach the human(s) responsible for the care and
feeding of whichever mail system is in play.  Any operation that doesn't
support that has no business sending or accepting email, period, full stop.
This is thus a fallback if -request doesn't seem to work and -owner
also yields no joy.

So.  First try -request.  If confusion ensues, try -owner.  If all else
fails, try postmaster.

If all of those fail, then get the cluestick ready because you're dealing
with incompetent morons who should be forced (a) to fix their horribly
broken mail system and (b) to listen to the 3-CD, 137-minute anthology
Bieber and Skrillex Tribute to Pink Floyd.  [2] On 10.  With headphones.

---rsk


[1] RFC 2369 is described here:

The Use of URLs as Meta-Syntax for Core Mail List Commands
and their Transport through Message Header Fields
http://www.ietf.org/rfc/rfc2369.txt

and on this list, these are set:

List-Id:
List-Unsubscribe:
List-Archive:
List-Post:
List-Help:
List-Subscribe:

If your mail client doesn't make it very easy for you to see those
on demand, then your mail client is misconfigured or broken.  If the
former, fix the configuration; if the latter, discard it, because
there is absolutely no excuse, in 2015, for a mail client that doesn't
facilitate compliance with an important RFC from 1998 -- doubly so one
that is key to participation in every responsibly-run mailing list
on the Internet.  (Of which, I'm happy to note, liberationtech et.al. are.)

[2] Rest easy.  I made that up.  The world is still safe.  For the moment.
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Whatsapp, a Trojan horse for seekers of easy privacy?

[Rich Kulawiec]

On Fri, Jan 16, 2015 at 10:19:22AM -0800, Al Billings wrote:
 The problem is that I am a practical person who lives in the real world.

The largest, most successful project in the history of computing has
been built entirely on open standards, open protocols, open formats,
and open source: you're using it right now to read this message.

That seems somewhat practical and real world to me.

Meanwhile, the contributions, if I may generously call them that,
of the closed-source software vendors of the world constitute in toto
a lengthy list of case studies of worst practices in software architecture,
design, implementation, and maintenance.

 Telling people ???Throw away all of your Apple/Microsoft word
 processing and often software. Throw away all of your games. Throw
 away all of the software you bought because you can???t trust any of
 these.??? is going to be met with being ignored or marginalized and with
 utter derision.

I'm a practical person who lives (and works) in the real world, and
I've done so quite well for a very long time without any Apple or
Microsoft software.  (And of course games are, in the context in
which we are operating *here*, entirely superfluous.  Nobody is going
to bring a free press to Egypt or promote women's rights in China
by playing The Sims.)  I haven't used a closed-source piece of software
since sometime the last century (SunOS 4.1, if you must know).

This wasn't always easy: but it's gotten far easier and continues to get
easier every day.  It's really quite difficult, in 2015, to identify
a computing task which can't be readily accomplished by using open
source software.  (The problem these days, sometimes, is a plethora
of competing alternatives.  But that's a nice problem to have.)

I rather expect than in another generation or two the entire obsolete
closed-source ecosystem will be viewed as an unfortunate aberration
in the evolution of computing.  This will happen whether anyone wants
it to or not, because it's going to be *necessary* for it to happen
in order to ensure privacy, security, and integrity in computation.
Anyone who is paying attention and has sufficient background to understand
contemporary events can see this happening today, every time there's
a discussion about revision histories or deterministics builds or
software signing keys or security holes or backdoors/spyware.

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

 There is a reason Stallman is seen as a crazy wing nut
 and it isn???t just because he eats his own toe jam.

Those who see Stallman as a crazy wing nut have not been paying
attention -- or perhaps lack the analytical capabilities required to
comprehend what they observe.  Haven't you noticed?  Things that
Stallman says which at the time may seem outlandish have a track
record of turning out to be quite prescient in good time.
It's happened repeatedly.  Sometimes it only takes a few years;
sometimes it takes decades.  But one need only wait and watch --
and possess at least a rudimentary sense of vision.

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

Stallman isn't often wrong.  He's usually just a bit early, and those
who lack the ability to extrapolate simply aren't able to process that.

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

Re: [liberationtech] Whatsapp, a Trojan horse for seekers of easy privacy?

[Rich Kulawiec]

On Thu, Jan 15, 2015 at 02:46:56PM -0800, Al Billings wrote:
  I thought software freedom and access to the source code was considered
  a requirement for considering a system secure.
 
 According to whom? I think open source (I???ll leave aside whether ???open 
 source??? is ???free software???) is ideal but it is not the only thing worth 
 discussing. Otherwise, we wouldn???t be discussing most mobile applications.

According to me, among others.  Open source is not merely ideal, open source
is MANDATORY.  It is not sufficient, of course, but it is necessary.
All closed-source software not only may be, but *must be* immediately
dismissed as unsuitable for use, with prejudice, as it and anyone pushing
it are both unworthy of any further discussion.  (Except, perhaps, as
examples of fraud.)

Please read:


https://mailman.stanford.edu/pipermail/liberationtech/2013-March/007499.html

Yes, this does mean that most mobile applications are (at best)
worthless crap.  Some of them, no doubt, have been backdoored deliberately.
(Why not?  It's just good business. [1])  Others likely have gaping security
and privacy holes that will remain largely undiscovered *except* for those
with access to the source code, which I hope everyone here realizes
probably includes any intelligence agency that can trouble itself
to make the effort to acquire it.  (It would be extremely naive and
appallingly stupid to suggest otherwise.)  Of course, their resources,
while quite large, are still finite so I'm sure not everything attracts
their attention: but certainly anything usable/popular enough to matter
will be swept up in due course and subjected to analysis.  Such analysis
may be shared (as we've seen) and may lead to active attempts to exploit
the application, which will, given the available expertise, probably succeed.

---rsk

[1] Just like this is good business:


http://www.propublica.org/article/zombie-cookie-the-tracking-cookie-that-you-cant-kill
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[Rich Kulawiec]

On Fri, Oct 03, 2014 at 10:23:09PM +, Jonathan Wilkes wrote:
 Hi Rich,  Your footnote #1 is dubious at best. The cost of
 aiming peoples eyes at bugs is _not_ $0. Until it is, the free software
 community has a problem with too few resources chasing too many bugs.

I'm not sure why you're bringing up by the cost, but I'll certainly
agree with the second sentence: yes, there are too many bugs and
too few people working on them.  We seem to have backed into triage
mode partly because of the aggregate size of the code in play,
partly because of the increasing sophistication of attacks, and
partly because we've all developed a lot of bad habits (including
complacency).  I think the past year and probably the next couple
of years are going to see some major changes: I think a number
of projects need to adopt an approach similar to that of OpenBSD's, [1]
which is fanatical, intolerant, pedantic, demanding...and effective.

But all that said, peer review remains the very best tool we have,
even when it sucks, even when it isn't fast enough, even when it
isn't thorough enough, even when *anything*.  That's why science,
law, engineering, medicine, et.al. use it: there isn't anything better.

Should bash have undergone this years ago?  Oh, sure.  But it didn't.
So the best we can do is to do it now, do it thoroughly, sweat the
details, argue, test, patch and try not to repeat the error(s).
And then we need to tackle all the other critical pieces of software
infrastructure: postfix and freeradius, nagios and subversion,
nginx and mariadb, top and stunnel -- everyone's laundry list will
vary, but there are a lot of semi-visible moving parts that make
up the 'net's infrastructure and no doubt many of them are languishing
in vulnerable states.

So: we need to get better at auditing code.  We need to do more code
auditing.  We need to get better at writing code so that the previous
two items aren't so onerous.  We need to [do a bunch of other things too].

We also need to insist, without exception, that everyone put all
of their work on the table for inspection.  Some will choose not to
acquiesce to that, and that's fine: but if/when that happens, we
shouldn't expend another minute on it: dismiss and move on.  As I
snarkily said back when I wrote that long piece: source or GTFO.
Anything that is not 100% open source can be, should be, and must be
discarded immediately, with prejudice.

---rsk

[1] Speaking of which, given this week's Xen vulnerability disclosure
and the resulting disruption of numerous services/sites, I think
it's worth citing this quote:

You are absolutely deluded, if not stupid, if you think that
a worldwide collection of software engineers who can't write
operating systems or applications without security holes,
can then turn around and suddenly write virtualization layers
without security holes.
--- Theo De Raadt

Seems rather prescient now, doesn't it?
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[Rich Kulawiec]

This is dragging out, so I'm going to try to be brief.

On Fri, Oct 03, 2014 at 06:07:36PM -0700, Greg wrote:
 You may also be misunderstanding our NDA.

I'm not misunderstanding it.  I didn't bother to read it, because the
mere fact that it exists is the problem.  People who are serious about
open source and peer review of code do not limit peer review, nor attempt
to legally constrain the reviewers, nor try to cherry-pick the reviewers
based on perceived expertise or personal qualities.

In or out of the pool.  You wanna be closed source?  Go for it.  But please,
stop disengenously pretending to be open source when you're clearly not.

---rsk

p.s.  In re: [...] we want to do our best to keep the software in the
hands of honest, trustworthy folks [...] -- you've got to be kidding.
I *hope* you're kidding.
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[Rich Kulawiec]

On Thu, Oct 02, 2014 at 05:50:08PM -0700, Greg wrote:
 K, thanks for the read (I read it but nothing there seems to apply,
 perhaps some of its points will be addressed below).

I'm sorry that you feel that way; I included that link because I think
the entire message applies, particularly this part:

Of course the obvious answer is A, since B is more commonly
known as snake oil.  It's garbage.  No thinking, responsible
person would ever choose B, because -- absent the history and
the research and the publication and everything else -- it might
be the instant cure for Bieberitis, or it might be sugar pills,
or it might be poison.  There's no way to know.

Espionage might be brilliant, beautiful, bug-free code that does exactly
what it's claimed to do.  Or it might be loaded with algorithmic mistakes,
coding errors, security holes and back doors.  There's no way to know.

And the reason there is no way to know is that Tao Effect is refusing
to freely/openly/completely publish the full source code, i.e.:

 Anyone is welcome, so long as they:
 
 1. Are software security professionals. (Nobody else matters in this context, 
 after all.)
 2. Don't work for government intelligence agencies.
 3. Sign the NDA we give them, the salient points of which are enumerated on 
 our site.

You're certainly welcome to set whatever policies you wish for your
software (as is everyone).  But by making this particular set of choices,
you have immediately disqualified it from any further consideration,
since it is not available for unconstrained peer review by arbitrary,
independent third parties.  (And can't be, since you've exempted
anyone who doesn't meet your criteria and since anyone who signs
your NDA is quite clearly no longer independent.)

If you're serious about security, then you must be equally serious about
independent and unlimited peer review, since -- so far -- it's the
only tool we have that's been demonstrated to work in the field.
It doesn't work very well sometimes (see Shellshock) [1] but it's still
the best we've got.  You can't have the former without the latter:
it's not a sufficient condition, but it's certainly a necessary one.

By the way #1, your statement (Nobody else matters in this context,
after all) in point #1 is absolutely, utterly, completely wrong.
Security bugs in software are identified all the time by people who are
*not* software security professionals: as one of the more well-known
examples, let me point out Cliff Stoll.  There are of course myriad
others, as everyone who has either studied the history of the field
or lived through it is quite well aware.  That's one of the reasons
why completely open, completely unrestricted peer review is important:
there's no way to know who will find something.

By the way #2, in re point #2: government intelligence agencies
either feel that your software is of sufficient interest to require
their attention or they do not.  If the latter, then they don't care.
But if the former, then in all probability they already have it or will
acquire it without your help or knowledge whenever they feel like
troubling themselves enough to do so.

---rsk

[1] Although one could argue that it *did* work in the case of Shellshock:
it just took a while.  And one of the things that's very clearly working
right now, as I'm writing this, is that the exposure of this particular
bug has triggered a massive examination of the relevant code, which in
turn has spurred copious discussion, which in turn will eventually result
in marked improvement, since there are now a large number of clueful,
experienced, motivated eyeballs peering at bash and arguing over it.

Compare/contrast this overwhelming and prompt response to this with the
laconic/anemic reactions of, let's say, Adobe:

Adobe Shockwave bundles Flash that's 15 months behind on security fixes

http://arstechnica.com/security/2014/05/adobe-shockwave-bundles-flash-thats-15-months-behind-on-security-fixes/

or Oracle:

Oracle reportedly knew of critical Java bugs under attack for 4 months

http://arstechnica.com/security/2012/08/critical-java-bugs-reported-4-months-ago/

So while Shellshock has been annoying, at least it's being worked on with
an appropriate sense of urgency.
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] TrueCrypt Alternatives?

[Rich Kulawiec]

1. Well, this has certainly been an interesting discussion, but until
Espionage is FULLY open-source, it's moot, because it hasn't (yet) been
exposed to unlimited peer review by arbitrary, independent third parties.

Please see:


https://mailman.stanford.edu/pipermail/liberationtech/2013-March/007499.html

Yes, I do note (per the Tao Effect web site) that people can apply to
see the source.

Not good enough.

2. About this comment on Reddit:

Because Espionage creates fake data for everyone, it is a fact
that at least some of the data on your drive is fake. Therefore
when you say that data is fake, it's completely believable
that it is, because some of it is. We extensively document this
feature, so the interrogator knows, too, that your hard drive
is guaranteed to contain fake data.

Plausible deniability is an interesting concept, but you know, if I'm
the one tortudeploying enhanced interrogation techniques against
you because you have something I want very very badly, I'm not going to
spend my coffee break RTFM'ing about Espionage.

To put it another way:

If you or I or anyone else are going to suggest that people put their lives
(and those of their allies, families, friends, etc.)  on the line and rely
on this concept to save them, then we should probably verify that it
actually works *first*.  This isn't an Espionage or Truecrypt et.al. issue
per se, it's a conceptual issue and one which is very hard to research,
since of course we can't just poll the people whose answers matter
the most.  (And even if we did, we couldn't trust the answers.)
In addition, some of the instance in which it failed in the field are
and will likely remain (indefinitely) unknown to us, since the only
people likely to report those failures to us are imprisoned or dead.

This it not to say that it *never* works: it probably does, some of
the time.  It is to say that we shouldn't blithely presume that it's
*always* going to work, and we especially shouldn't presume that it
will work when the stakes are high.

---rsk

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

[liberationtech] Fwd: [IP] Sophisticated iPhone and Android malware is spying on Hong Kong protesters

[Rich Kulawiec]

[ Forwarded from Dave Farber's most excellent IP mailing list. ---rsk ]

- Forwarded message from David Farber via ip i...@listbox.com -

 Date: Wed, 1 Oct 2014 12:15:09 -0400
 From: David Farber via ip i...@listbox.com
 To: ip i...@listbox.com
 Subject: [IP] Sophisticated iPhone and Android malware is spying on Hong Kong 
 protesters
 
 Begin forwarded message:
 
 From: Dewayne Hendricks dewa...@warpspeed.com
 Subject: [Dewayne-Net] Sophisticated iPhone and Android malware is spying on 
 Hong Kong protesters
 Date: October 1, 2014 at 8:59:30 AM EDT
 To: Multiple recipients of Dewayne-Net dewayne-...@warpspeed.com
 
 Sophisticated iPhone and Android malware is spying on Hong Kong protesters
 Researchers say all signs point to the Chinese government
 By Amar Toor
 Oct 1 2014
 
 http://www.theverge.com/2014/10/1/6877377/sophisticated-iphone-and-android-malware-is-spying-on-hong-kong
 
 A fake smartphone app is being used to remotely monitor pro-democracy
 protesters in Hong Kong, according to a report from the New York
 Times. Researchers from Lacoon Mobile Security say the phishing scam is
 spreading across the messaging application WhatsApp, through texts that
 read: Check out this Android app designed by Code4HK for the coordination
 of OCCUPY CENTRAL!, along with a link to download software. Lacoon
 says the software, once downloaded, can access a user's personal data,
 including phone calls, text messages, and the physical location of their
 smartphone. Code4HK ? a developer community that has helped to spread
 information about the protests ? tells the Times it had nothing to do
 with the texts.
 
 The origin of the scam remains unknown, but Lacoon CEO Michael Shaulov
 says the Chinese government is likely behind it, given the location of the
 servers and the sophistication of the operation. The company traced it to
 a computer that they say is similar to those that the Chinese government
 allegedly used to launch cyberattacks against US targets last year. The
 spread of the app remains equally unclear, though Shaulov says it was
 downloaded by one out of every ten phones that received the fake message,
 and, notably, that it has affected both Android and iOS users alike.
 
 Phishing scam targets Android and iOS users alike
 
 This is the first time that we have seen such operationally sophisticated
 iOS malware operational, which is actually developed by a Chinese-speaking
 entity, Shaulov told the Times.
 
 Today's report comes as thousands of protesters flocked to the streets
 on China's National Day, calling for Beijing to allow for free democratic
 elections in 2017. China had previously said it would allow Hong Kong to
 choose its own leader by that date, but backtracked on that promise in
 August, when it announced that all candidates would have to be approved
 by Beijing.
 
 Protesters in the Occupy Central movement have clashed with police
 since protests escalated over the weekend, and there are fears of
 further confrontation tonight, during National Day celebrations. The
 Chinese government has gone to great lengths to censor news of the
 demonstrations. Most state-run media have not mentioned it, and Chinese
 web censors have stepped up efforts to block images and videos on social
 media. On Sunday, the government blocked access to Instagram within
 mainland China, and posts on the Twitter-like service Sina Weibo have
 been aggressively deleted, according to the Times. In the past few days,
 censors have blocked any Weibo posts including the words Hong Kong,
 barricades, and umbrella ? the unofficial symbol of Hong Kong's
 movement.
 
-- 
Liberationtech is public  archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] World Congress on Internet Security (WorldCIS-2014): Call for Submissions!

[Rich Kulawiec]

This is (unsurprisingly) spam from one of the many fake conference scams
currently polluting the Internet.  I recommend permanently blacklisting the
sender and the referenced domain.

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

Re: [liberationtech] Internet Infrastructure Software Database

[Rich Kulawiec]

I think this list is a pretty good starting point.  Of course,
having said that, now I want to edit it. ;)

On Fri, Aug 01, 2014 at 02:21:12PM -0700, Bill Woodcock wrote:
 BIND
 NSD
add unbound, I think

 Sendmail
add postfix, exim, courier
add dovecot, uw-imap and descendants
add procmail, fetchmail

 Apache/httpd
move nginx here
add squid, tomcat

 sshd
change to OpenSSH

 MySQL
 PostgreSQL
add MariaDB, MongoDB, CouchDB

remove the web browsers: they're not infrastructure

 PHP
 Perl
add Python

 Operating systems:
add *BSD, not just because they're used as-is but
because they're embedded in so many devices

maybe add the Solaris/Illumos/OpenIndiana family

additions:
stunnel
OpenNNTP, INN
subversion, git, maybe other source code control systems
nagios, zenoss, zabbix, etc.
snort, nessus, nmap, tcpdump, wireshark 
puppet, chef, spacewalk, etc.

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

[liberationtech] Soghoian's written remarks for the German Parliament Committee of Inquiry

[Rich Kulawiec]

Recommended reading:


http://files.cloudprivacy.net/bundestag-testimony-csoghoian-june-26-final.pdf

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

Re: [liberationtech] New Citizen Lab report on Hacking Team's Government Surveillance Malware

[Rich Kulawiec]

I skimmed this earlier today and plan to read it in depth later: it looks
like superb work.

The most disturbing thing about it is the realization that this can't
possibly be the only such project.  Surely there are others.  Many others.

And since there are others, it's necessary to ask: are any of them
better than this one, i.e., more capable, more stealthy, etc.?
After all, it would be rather extraordinary if these researchers
just happened to come across the best one.  (Sort of like walking
into the jungle and presuming that the first lion you meet happens
to be the fiercest.  Possible, yes...but unlikely.)

Therefore we must entertain the hypothesis that these capabilities may
represent a floor rather than a ceiling.   And that, as I said above,
is disturbing.

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

Re: [liberationtech] when you are using Tor, Twitter will blocked your acc

[Rich Kulawiec]

On Mon, Jun 09, 2014 at 07:52:51PM -0700, Seth wrote:
 I'm in agreement with pretty much all the points made, but how do
 you feel this approach?
 
 1) ALWAYS publish the original source information via
 freedom/privacy/dignity respecting services using a name-space (a
 DNS domain,.onion,.gnu,.i2p,namecoin,whatever) that you control.
 
 2) Syndicate a copy of that information to the CSW (Corporate
 Surveillance Whore) networks such as Google/Facebook/Twitter to
 obtain the widest reach.
 
 3) Ease out of the CSW networks as your home grown following reaches
 critical mass.

I see where you're going with this, and I agree with the goal.  But I still
have a major problem with point #2.  Let me try to explain why via a
fictitious example.

Suppose that I were the dictator of Elbonia (the mythical country from
Dilbert cartoons).  I would be autocratic, ruthless...oh, wait, I already
*am* those things...anyway, I would be the typical tyrant attempting
to retain power in the face of democratic movements and civil rights
movements and worker's rights movement and other petty annoyances.

I would *not* block Twitter.  I would *not* block Facebook.  I would *not*
block Instagram or any of the others either.  I wouldn't do this because
the idealistic, enthusiastic, hard-working, noble young people who are
most likely to pose a serious threat to my supremacy and are also naive,
gullible, careless and stupid.  They're using Twitter and Facebook and
the rest and that is extremely helpful to me, since I very much would
like to monitor them and know who they are and where they are and what
they're up to.  They've wiretapped themselves, saving me much of the
trouble and expense.

Instead -- because I *am* the dictator, thank you very much -- I
would order the long-since nationalized telecoms and ISPs to provide a
real-time feed of network traffic to my intelligence agency.  I would
monitor who is following #OverthrowTheDictator and who is liking the
DesposeTheDictator page.   And so on.

And when the moment came that I felt really threatened, I would decapitate
their movement by disappearing the 22 or 37 or whatever most active
participants.  Not a tidy solution, I'll grant you, but effective in the
short term and it would certainly discourage others.  I could probably
do this 3-4 times before they caught on that they were making a major
strategic mistake.  That might buy me another decade in power.

Now you might say...but what about HTTPS?  Would about VPNs?  What about
Tor?  (What about Houston?  What about Detroit? Thank you David Byrne.)

Yeah.  I know.  Most inconvenient.  Fortunately, I have another way.
Several other ways, actually.

You see, Twitter wants to do business here in Elbonia.  So does Facebook.
So I would summon their corporate weasels to a meeting.  In that meeting,
one of my minions (you don't think I'd do this personally, do you?) would
explain to them that we must protect our great nation from subversives
and criminals and anarchists and terrorists (ding ding ding magic word!)
and thus we must have certain data fed to us...or, most regrettably,
we will not be able to allow them to do business in our country.

I think they'll cave.  Don't you?  After all, there are profits to be
made and it's such a small thing that I'm asking.  And if the corporate
weasels are perhaps..hesitant...than maybe some tax breaks will help.
Or maybe some help with a few bureaucratic obstacles they're currently
facing.  Or maybe an envelope full of tax-free income will help persuade
them to cooperate.  (I have plenty, you know.  We dictators have buckets
of cash.)  Or women.  Or men.  Or both.  Or cars, condos, boats: surely
they have an itch that I can scratch.

And then I will do everything I said above, content with a full real-time
feed of data-of-interest into my pet intelligence agency.

Oh...come now, you don't *really* think that corporate weasels will stand
on principle, do you?  These are trained professional liars and con men,
the finest products of business school: they don't have principles.
Or spines.  What they *do* have is greed.  Lots of it.  Their loyalty is
purchased by the highest bidder, and that will be me.  Before you know it,
they'll be working for me and moonlighting for their real employer.

But what if they're discovered?  Not a problem.  Setting up plausible
deniability is easy and we'll simply make it look like the Evil Nefarious
Diabolical Hackers associated with the local liberatiXXterrorist
movement did it.  Or we'll blame Anonymous.  Or we'll just stonewall.

Oh?  You think that maybe, just maybe, that won't work?  Fine.  There
are other ways.  I don't actually *need* the willing or even knowing
cooperation of the people at the top of those companies.  One engineer
in the right place will probably suffice.  I strongly doubt that they've
architected themselves to defend against insider attacks.  Why would they?
Why would Twitter or Facebook spend the money?  It's not THEIR data.
Their 

Re: [liberationtech] Wicker: D??j?? vu all over again

[Rich Kulawiec]

On Tue, Jun 10, 2014 at 10:08:26AM -0700, Yosem Companys wrote:
 The mention of NDAs by the Wickr founder makes it a non-starter. Their web
 site doesn't have any download link for the source files, nor mention of
 open source, but they do mention patent pending technology. How do they
 expect anyone to trust closed source, proprietary technology to be secure?

Nobody should trust closed source, ever.  No matter the reputation of those
behind it, no matter how sincere they appear to be: if it's not open source,
it's fraud.

Once again, I'll refer folks to:


https://mailman.stanford.edu/pipermail/liberationtech/2013-February/006964.html

and the rather longer and more explanatory:


https://mailman.stanford.edu/pipermail/liberationtech/2013-March/007499.html

Wickr (and anything like it) can be, should be, and must be immediately
and permanently dismissed with prejudice.

---rsk

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

Re: [liberationtech] when you are using Tor, Twitter will blocked your acc

[Rich Kulawiec]

On Sat, Jun 07, 2014 at 10:39:06AM +0100, Nariman Gharib wrote:
 what solution do you have for solve this problem?

Don't use Twitter.

Yes, I'm quite serious.  Twitter has clearly stated that they're delighted
to provide censorship-on-demand for any country that asks nicely:

http://www.businessinsider.com/twitter-censors-political-accounts-2014-5

and even some that don't ask nicely:


https://www.techdirt.com/articles/20140521/08242627307/pakistan-internet-content-regulator-asks-twitter-to-take-down-blasphemous-search.shtml

and it's only going to get worse:


http://gigaom.com/2014/05/21/twitters-selective-censorship-of-tweets-may-be-the-best-option-but-its-still-censorship/

because Twitter wants to do business in those countries, like selling
data on users to advertisers:


http://thinkprogress.org/economy/2014/04/16/3427404/twitters-acquisition-of-gnip/

Consider: if Twitter is so ready, willing and able to cave in to these
demands, what possible reason is there to think that they won't give in
just as quickly to *other* demands -- like for a data dump on all the
users in a particular country or following particular accounts or using
particular tags, including their login history with IP addresses, OS
fingerprint, and everything else that they have on them?

To borrow a phrase, it's just...good business.

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

Re: [liberationtech] when you are using Tor, Twitter will blocked your acc

[Rich Kulawiec]

On Mon, Jun 09, 2014 at 11:36:01AM +0100, Amin Sabeti wrote:
 Rick, I think you delete the problem instead of solving it!

I suspect that's because I have a different definition of the problem. ;)

Outsourcing your communications to a so-called social network whose
interests (a) diverge markedly from your own and (b) converge to a large
degree with corporations and governments is a fundamentally bad idea.

To explain:

Twitter does not exist to support your democratic movement or your
LGBT civil rights efforts or your literacy campaign or your environmental
initiative or your labor rights campaign or anything else.  Twitter exists
to make money.  The same is true of Facebook and all the rest.

You're not a customer of any of these operations.  You're the product.

http://computerfloss.com/wp-content/uploads/2013/08/facebook-and-you.jpg

You're thus of no more concern to them than the 8,274th can of beans
being loaded onto a truck at a warehouse.  You are a non-factor.
You are irrelvant and expendable.  Their concerns are directed at
(a) their customers, who make them money and (b) the governments of the
countries where they operate, who can cost them money.  (Please see
links I provided for background on these two points.)  Their customers
and various governments wield money, power and influence; you wield: nothing.

Why would you even *consider*, for even a moment, trying to make
them an important part (or any part) of your communication strategy?

So from my chair, that's not just a bad idea.  It's a really bad idea.

Now I know some people will say but but but  I'm not very responsive
to that.  There was a perfectly usable, fine Internet before Twitter
and Facebook and all the others.  There will be one afterwards, too.
There were vastly better ways to communicate; there are and will be
those as well.

But rule #1 should be and must be: do it yourself.  Don't outsource any
part of it to anyone.  Because when you do, you're subjecting *your*
communications to *their* whims, necessities, business needs, profit
motives, regulations, board of directors, shareholders, security holes,
executive decisions, privacy breaches, government-mandated backdoors
and censorship, contracts, court orders, and everyone/everything else.

That might, if you're very lucky, work out okay for you anyway.

But it's not the way to bet.

---rsk

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

Re: [liberationtech] Not an Emergency: Has TrueCrypt.org been Hijacked?

[Rich Kulawiec]

On Wed, May 28, 2014 at 07:42:02PM -0400, Griffin Boyce wrote:
   My suspicion is that either they were hacked (and had their key
 stolen), or that they were ordered to shutdown and recommend
 Microsoft's (presumably backdoored) BitLocker as a replacement.
 BitLocker's enterprise documentation makes me *incredibly*
 suspicious that it is susceptible to monitoring by third-parties.

If it's the latter, and I'll certainly grant that's a possibility,
then it was a short-sighted move on the part of whoever's responsible,
since TrueCrypt's source is available to anyone who wants to restart
the project elsewhere.  Someone will, and they'll use the results of
the just-completed code audit to improve it.

(And yes, I presume BitLocker is quite thoroughly backdoored.)

   Pardon my tinfoil hat.

Not a problem: the bar for tinfoil hat has been raised considerably
in the last year.

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

Re: [liberationtech] Not an Emergency: Has TrueCrypt.org been Hijacked?

[Rich Kulawiec]

It's probably just been hacked.  Since the principals haven't commented
yet, I suspect they're probably busy diagnosing and fixing it.  I suggest
ignoring the yapping on Twitter, having a nice microbrew, and awaiting
further developments.

And if those further developments amount to it's true, then someone
else will pick up development where this left off and soon enough we'll
have a new Truecrypt.

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

Re: [liberationtech] Auditing of Auto-Update of software commonly used by Human Rights Defenders

[Rich Kulawiec]

On Mon, May 19, 2014 at 07:24:39PM -0700, Tony Arcieri wrote:
 If you really want secure updates, depending on your threat model doing it
 correctly is a very difficult problem.

First, thanks for the pointer to the web site/paper/etc.: that's going to
make for some interesting reading later today.

Second, I think that the threat model, unfortunately, should include the
presumption of pervasive monitoring of least connection metadata: source IP,
destination IP, ports, time, duration, and traffic volume in each direction.
I have the uncomfortable thought that even if we had a solution to the
problems articulated by The Update Framework, that others would remain.
Still, it's not at all a bad idea to solve the obvious ones that are in
front of us while thinking about the others.

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

Re: [liberationtech] Auditing of Auto-Update of software commonly used by Human Rights Defenders

[Rich Kulawiec]

On Thu, May 15, 2014 at 07:36:07AM +0200, Fabio Pietrosanti (naif) wrote:
 i think that would be very important to organize a project to Audit the
 functionalities of Auto-Update of software commonly used by human rights
 defenders.

Yes, but I'll go one step further: auto-update is a horrible idea -- even
if the connection is encrypted.

Why?  Because someone observing network traffic can deduce which operating
system(s) and application(s) a target is using by doing traffic analysis:
that is, just looking at where connections are originating and terminating.

Even passively checking for the existence of updates -- that is, not
actually downloading and installing them -- can facilitate this same
traffic analysis.

The results of that analysis have many uses: one that occurs to
me offhand is that a repressive government might wish to identify
everyone who appears to be using a particular application X because
(a) it's not widely used across the entire population (b) but it's used
extensively within a certain political/social movement/organization Y.
Combined with other traffic analysis (e.g., visits to the web site of Y)
this would be useful intelligence.  Combined with research into the
security vulnerabilities of X this would be VERY useful intelligence.

Another use that occurs to me is that particular combinations of updates
could constitute a signature that facilitates the tracking of individuals.
In other words, lots of people might check for updates to A, or updates
to B, or updates to C, etc.; but how many individuals check for updates
to A, B, F and M but never C, D or J?

I'm not sure what the answer to this problem will look like, but I
suspect it's going to involve doing away entirely with the concept of
auto update.

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

Re: [liberationtech] New IT security measures underway

[Rich Kulawiec]

On Mon, Feb 03, 2014 at 03:09:24PM -0800, John Adams wrote:
 Reality: You don't understand business nor threat modeling.

Reality: I understand both *painfully* well, having worked for/consulted
to a number of Fortune 100 companies and several major universities as well
as a few ISPs and government agencies over a very long period of time.

This is not my first day on the job.

 Microsoft is, unfortunately, the backbone of most world-wide business.

That is one of the (many) painful things that I understand.  I also
recognize that it's a serious strategic error -- albeit a very
common one.  Anyone who does not immediately recognize it as a massive
blunder clearly requires a great deal of remedial education.

 Additionally, your statement of: Closed-Source software cannot be secured
 -- I prefer open source software but I disagree that it cannot completely
 be secured. It depends only on the motivation, financial resources, and
 merit of the company attempting to secure said software. 

I suggest you read the link I provided.  It is quite impossible to
secure closed-source software because of its very nature -- any such
claims may be instantly dismissed, with prejudice.  And not only may be,
but must be, because they are clearly fraudulent on their face.

The motivation doesn't matter.  The financial resources don't matter.
And the merits (or lack thereof) of the company (or university,
or government, or nonprofit, or whatever) don't matter.  These are
all totally irrelevant.  If they set for themselves the problem of
securing closed-source software then they have chosen a problem which
not only doesn't have a known solution, but *cannot* have a solution.

Let me quote Cory Doctorow from something just published this week,
as he expresses this in a pointed and entirely apropos manner:

Designing a security system without public review is a fool's
errand, ensuring that you've designed a system that is secure
against people stupider than you, and no one else.

Excerpted from:

What happens with digital rights management in the real world?

http://www.theguardian.com/technology/blog/2014/feb/05/digital-rights-management

(which, by the way, is worth reading in its entirety)

This isn't a Microsoft-specific problem, although thanks to the
widespread infestation of their products they illustrate it on a
grand scale.  The same is true of Apple and Adobe and myriad others.
Which is why discerning operations that actually care about security
don't permit these inferior products to contaminate their environments,
and why incompetent operations that want to make vague noises about
security while doing nothing truly meaningful use them in profusion.

Let me give you one example -- out of thousands of possible ones --
that illustrates why it depends only on the motivation, financial resources,
and merit of the company attempting to secure said software is dead wrong.

Let's talk about Adobe Acrobat.  It's probably Adobe's most widely-used
product.  It's so ubiquitous that a kazillion web sites with PDFs say
you'll need Acrobat instead of the more accurate you'll need a
PDF reader.  Adobe has piles of money.  Adobe has piles of employees.
They have every resource that they could possibly need to produce a simple
piece of software that reads (formatted) bytes and draws on a screen.
And they certainly have the motivation, since their name is on it
and it's installed all over the planet.

And yet it's absolute crap.  It's one of the worst pieces of commonly-used
software out there.  It has a security track record that is nothing short
of appalling.  Doubly so when you consider how long Adobe has taken to
fix some of the glaring holes in it.  You can almost set your watch by
the routine occurrence of zero-days in it.

(If you doubt this, go search for terms like Adobe Acrobat security
hole zero-day.  Make coffee first, because you're going to be reading
for a while if you actually perform a reasonable amount of due
diligence and work your way through its sordid history.  After five
or six hours, I think the picture will be quite clear.)

Adobe could pour all of its enormous financial and personnel
resources into fixing it and they would *still* fail.  This is
obvious on inspection, as math texts like to say, because it
has nothing to do with their motivation, resources or merits,
and everything to do with the fact that it's closed-source.

So, to bring this back to the discussion thread: Stanford clearly doesn't
understand security first principles, because *if they did*, they wouldn't
be fiddling around with the worthless junk they're deploying now: they
would be attacking the problem at its root, by excising all closed-source
software from the campus.

Instead they're doubling down on failure.  They're going to spend a lot
of money and a lot of time, they're going to invade the privacy of their
staff and students, and in the end, they're going to fail anyway because

Re: [liberationtech] Coursera to join censor club by blocking Iran IP space

[Rich Kulawiec]

On Thu, Jan 30, 2014 at 12:17:00PM +, Amin Sabeti wrote:
 The main point is Coursera has done something that it's not legitimate.

They were (apparently) forced to do this.  It's not like Coursera
staff woke up one day and suddenly decided to block those countries
because they had nothing better to do.  Please read:


http://hummusforthought.com/2014/01/29/us-bans-students-from-blacklisted-countries-from-getting-a-free-education/

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

Re: [liberationtech] Concerns with new Stanford University security mandate

[Rich Kulawiec]

On Sun, Jan 26, 2014 at 01:20:20AM -0800, Tomer Altman wrote:
 To Liberation Tech:
 
 Stanford is implementing a new security policy detailed here:
 
 http://ucomm.stanford.edu/computersecurity/

First, if they were serious about security, they wouldn't be using 
Microsoft products.

Second, backdooring end-user systems en masse provides one-stop shopping
to an attacker.

Third, locating PII on systems is not a solved problem in computing,
and for anyone to pretend otherwise is, at best, disengenuous.  Not
only that, but anyone who's been paying attention to the re-identification
problem knows that non-PII is quite often just as sensitive.

Fourth, the simultaneous requirement that systems be backdoored
and searchable while their disks are encrypted strongly suggests
that they intend to have a central repository of encryption keys.

Fifth, the requirement for use of centralized backup also provides
one-stop shopping to an attacker.

Bottom line: this isn't about security, it's about control and monitoring.

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

Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption

[Rich Kulawiec]

On Fri, Sep 13, 2013 at 09:14:27AM +1000, Erik de Castro Lopo wrote:
 No such agency and the like are almost certainly able (with the
 help of carriers and manufacturers) backdoor and exploit all
 the major smartphone brands and models [0].
 
 Smartphones are horrendously complex, rely heavily on untrusted
 binary blobs, have mutiple CPUs some without direct owner/user
 control (eg the CPU doing the baseband processing) [1]. 
 Currently these devices are impossibly difficult to secure.

I strongly concur: this echoes something I've said before, here and
elsewhere.  We've already seen code of dubious provenance and
nebulous justification (CarrierIQ); I would be very surprised
indeed if that was the only such piece of software in the field.
And of course smartphone-based malware is epidemic: the app
stores are full of it.  (Given recent events, I think it's reasonable
to wonder how much of that has been authored by miscreants and
how much by various governments.)  Whatever the origin, it won't be long
until that malware is accessible (for a price) to any government on this
planet wants it.

Perhaps this has already happened.

Add to that the unquenchable thirst of (telcos, governments, marketers)
for as much data as they can get any time they can get it, and carrying
a smartphone can reasonably be viewed as functionally equivalent
to wiretapping yourself.  (And let's not think for a moment that
even allegedly-benign data collection will remain so: it's all within
the reach of any sufficiently-powerful/wealthy/stealthy government
that wants it.)

And if you (generic you, the reader) think this is unduly pessimistic,
I invite you to consider the plethora of security problems already
publicly known, and to further consider that attacks always get better:
they never get worse.

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

Re: [liberationtech] iPhone5S Fingerprint and 5th amendment

[Rich Kulawiec]

That's a valid concern.

But I think you should probably be more concerned that it's only a matter
of time until malware is released which grabs the fingerprint and quietly
uploads it to someone's database.  I'm sure they'll find uses for it,
doubly so if it happens to unlock something other than a phone.

Perhaps this has already happened.

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

Re: [liberationtech] Fwd: Avaaz in grave danger due to GMail spam filters

[Rich Kulawiec]

On Wed, Sep 04, 2013 at 06:19:35PM -0400, Dave Karpf wrote:
 One distinction that I think is worth pondering though: it seems like the
 standard of serious about email is in conflict with the goal of
 frequently communicating with 20M supporters.

That's a good point.  Two responses:

1. At this moment, I see no evidence on the table that Avaaz has 20M
subscribers.  Right now they have zero, because a subscriber whose
verified provenance can't be produced on demand isn't a subscriber at all.

(I'm not picking on Avaaz here.  Everyone who runs a mailing list
should be able to do that.  I'm certain that the operators of *this list*
could, because they're using Mailman and they're using it properly.)

2. If Avaaz wishes to frequently communicate (via email) with such a
large number of people, then it should make a strong and sustained effort
to comply with standards (in the formal sense, as articulated by RFCs)
and best practices (in the informal sense, the things that all well-run
mailing lists have done for decades.)  People who do these things rarely
have serious and/or persistent issues; people who ignore them or try
to cut corners or dodge them invariably cause their own problems.
(For example, see MoveOn, which long ago got itself hardwired into
a kazillion blacklists -- including those run by people politically
sympathetic to their cause -- because they insisted on spamming.)

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

Re: [liberationtech] CFP: WorldCIST'14 - World Conference on IST; Best papers published in ISI Journals

[Rich Kulawiec]

This is a fraudulent/fake conference being promoted via spam.  I recommend
permanently blacklisting the sender.

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

Re: [liberationtech] Websites with privacy

[Rich Kulawiec]

On Wed, Sep 04, 2013 at 10:27:54PM -0700, Jillian C. York wrote:
 Is this spam?

No, it is not.  Spam is UBE (unsolicited bulk email) and there is no
evidence whatsoever that this is bulk.  It may be against list policies
(that is for the list-owners to decide) but that determination is
orthogonal to the question of whether or not it's spam.

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

Re: [liberationtech] Fwd: Avaaz in grave danger due to GMail spam filters

[Rich Kulawiec]

On Tue, Aug 20, 2013 at 12:27:24PM -0400, Matt Holland wrote:
 Rich: We actually do run our email lists in-house, sent from our own MTA's,
 with appropriate SPF records, DKIM signature, list-precedence headers, etc.
 etc. Our message to members was focused on getting into a particular tab
 at Gmail though; I think if we were having problems with those basic
 list-management issues we'd be more likely to see our messages being marked
 spam or just dropped outright.

First, it's good that you're listening in here.

Second, Gmail is a poorly-run email service.  That's somewhat surprising
to me, actually: I expect much better out of them.  But it really is
quite mediocre, and I therefore recommend against it for anyone who's
actually serious about email.  (Then again, it's not the *worst* Google
service: their horrible mangling of Usenet into Google Groups, a disaster
from its inception to the present, holds that honor.)

Third, to generalize that comment: it's not worth worrying about delivery
to Gmail/Yahoo/Hotmail/AOL.  They're either (a) crap or (b) well on their
way to being crap.  I can't fix this.  You can't fix this.  I'm pretty
sure they can't fix it or just plain don't want to fix it.  So the solution
to this isn't to turn yourselves inside-out trying to jump through Gmail's
hoops or Yahoo's hoops so that they'll accept your mail: the solution is
to tell everyone that freemail is worth what they're paying for it.
(Arguably, given recent events: it's worth less.)  To borrow from the
previous paragraph, anyone who is serious about email should get
a real email account.  Those four providers have spent the last decade [1]
proving that they can't furnish one.

Fourth, I've taken the time to evaluate -- at a cursory level -- your
mailing list operation.  Here are my findings and recommendations.
I'm sure they're incomplete (hence cursory).

1. SPF is snake-oil, as should have been obvious to everywhere when
it was introduced with this grandiose and ludicrous claim:

Spam as a technical problem is solved by SPF.

So: don't bother.

(DKIM?  DKIM shows some *potential*.  I am as yet unconvinced of its
anti-spam value, since my spamtraps receive spam all day every day that
passes DKIM validation.  Some say that DKIM has anti-forgery value, but
(a) the Internet clearly does not consider email forgery an important
problem and (b) even if it did, the problem is currently insoluble even
if DKIM is globally deployed and works perfectly.)

2. You're using Google to handle your incoming email.  Not a good choice:
see comments above.

3. You have working postmaster and abuse addresses that are
answered in a timely manner by a real live human being.  Excellent.
You're thus in compliance with the applicable portions of
RFC 5321 and RFC 2142, and you're doing what every single responsible,
ethical, and competent operation on this planet should do.

4. You're not in compliance with section 6 of RFC 2142 because
your mailing list does not support a -request address.  This is not
only mandatory, but it's been a best practice for 30-ish years.
Thus *this* mailing list supports:

liberationtech-requ...@lists.stanford.edu

because it darn well should.

5. You also don't appear to be in compliance with the long-standing
convention and best practice of -owner, which is analogous to -request,
except that (a) -request may or may not be a person but (b) -owner
is always a person.  Thus the -owner address is the one to use when
the automation behind -request isn't behaving: it provides a way
for subscribers and non-subscribers alike to initiate a conversation
with the person(s) operating any particular list.

6. You're not in compliance with RFC 2919 or RFC 2369.  Again,
using *this* list as an example, these headers are present:

List-Id: liberationtech liberationtech.lists.stanford.edu
List-Unsubscribe: 
https://mailman.stanford.edu/mailman/options/liberationtech, 
mailto:liberationtech-requ...@lists.stanford.edu?subject=unsubscribe
List-Archive: http://mailman.stanford.edu/pipermail/liberationtech
List-Post: mailto:liberationtech@lists.stanford.edu
List-Help: 
mailto:liberationtech-requ...@lists.stanford.edu?subject=help
List-Subscribe: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech, 
mailto:liberationtech-requ...@lists.stanford.edu?subject=subscribe

7. List messages are sent from an unreplyable address.  That's not
only an extremely bad idea, it's very rude.  It is the email equivalent
of sticking your fingers in your ears and saying LA LA LA LA I can't
hear you when the entire rest of the Internet is trying to tell you
that you've got a problem or are causing a problem.  All email should
always be sent from a replyable address, period.

8. You do not appear to use web bugs in your mailing list messages.
A wise choice: web bugs are malware, they're invasive and abusive, 
and they actively degrade the security of recipients...which is
a pretty 

Re: [liberationtech] Fwd: Avaaz in grave danger due to GMail spam filters

[Rich Kulawiec]

On Mon, Aug 19, 2013 at 12:32:59AM +0200, Moritz Bartl wrote:
 Subject: Avaaz in grave danger due to GMail spam filters

This should be retitled Avaaz allegedly in grave danger due to their
own extremely stupid decisions as regards running their mailing list,
and oh, by the way, Gmail's anti-spam setup is awful.

Briefly (VERY briefly) if Avaaz ran their mailing lists properly
(in-house, using COI, RFC 2142-compliant, RFC 2919-compliant, and so on)
then it would be very unlikely that they'd have an issue with Gmail...or
any other large mail provider, for that matter.  (Source: decades of
experience running mailing lists.)  As to Gmail, both their false positive
and false negative rates are far too high *and* they use quarantines
(a worst practice in mail system engineering).  So there's plenty of
blame to go around here, but really, most of it lies with Avaaz, because
this problem is fixable IN A DAY using FOSS and a little bit of clue.

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

Re: [liberationtech] abuse control for Tor exit nodes [was: Twitter Underground Market Research - pdf]

[Rich Kulawiec]

On Wed, Jun 05, 2013 at 10:16:23PM -0700, Andy Isaacson wrote:
 This is a really deeply interesting assertion.  You seem to imagine a
 bright line of abuse that is agreed on by all parties, with a policy
 that can be implemented by thoughtful operators to make the abuse
 stop.  I submit that that is not the real world, in many different
 dimensions.

[ Okay, so I have a long-winded response to this.  It's possible that
eventually I'll wander somewhere near a point. ;-) ]

Many people who are relatively new to the 'net haven't yet internalized
parts of the fundamental ethic that has allowed it to flourish.  There is
an implicit social contract that's far more important than any formal
legal document -- but because it's implicit and not overt, many don't
realize that it exists and that it serves a critical function.
One way to put it, if I might borrow a line from popular culture, is:

With great power, comes great responsibility.

Being connected to the Internet gives you incredible power.  Not because
of who *you* are -- because for all values of you (including me),
you are unimportant and expendable.  It gives you incredible power
because of *everyone else* out there.  By plugging in, you have --
whether you realize it or not, whether you acknowledge it or not --
tacitly committed yourself to living up to the responsibility that
accompanies the immense power you now have.

So like everyone else on the Internet -- from the tiniest single system
connected via a slow dialup line, to the largest distributed operation
imaginable -- you're responsible for everything your operation does to
everything and everyone else.  You don't get a free ride.  You don't
get to pass the blame along.  If there's abuse coming from YOUR system
on YOUR network on YOUR watch, then it's YOUR abuse.  You own it.
You're responsible for it.

It's always been that way -- and it has to be that way, otherwise the
Internet won't work because it can't work.  (And if you've been paying
attention during the past decade or two, you'll note that many components
of the 'net that aren't working very well are struggling for precisely
this reason.)

Responsible and ethical operations know this and design, budget, plan,
train, and staff accordingly.  Irresponsible and unethical operations
don't -- they just shrug their shoulders and try to slough off their
incompetence and negligence on someone else, often the rhetorical they.

Now...everyone is probably going to leak a small amount of abuse from
time to time.  Software breaks.  Routers lose their minds.  Users do
silly things.  System admins make typos.  Security holes get
exploited.  Stuff...happens.

The expectation is that such incidents should be isolated and
sporadic -- and that effective remedial action (where effective
remedial action may require the root password and/or wirecutters)
will be taken promptly.   The reality is that many such incidents are
pervasive, sustained and completely unaddressed.  And that is why we,
for a global value of we, find ourselves defending against myriad forms
of abuse, from ssh brute-force attacks to spam.  NONE of that abuse just
magically falls out of the sky: it all comes from somewhere...and that
somewhere is mostly irresponsible, negligent, incompetent operations.

Note that this results in massive but silent cost-shifting: someone
has to deal with that abuse, because it doesn't just vanish.  It goes
somewhere.  It impacts other networks, systems and people.  And the
people responsible for defending those need to spend their resources
to deal with it, even though they had nothing to do with its origin.
The costs of doing so are enormous: just look at the subindustries
that exist to sell products to deal with this and consider that every
single dollar/euro/yen they ever make comes from someone paying
the price for others' negligence.

And they're making billions upon billions.

Consider, for example, that companies like Cloudflare and Prolexic
probably *would not exist* if it weren't for the ongoing epidemic
of abuse.

Here's another way to phrase that fundamental ethic, also borrowing a
line from popular culture:

The needs of the many outweigh the needs of the few.

No matter how big my operation or your operation or anyone's operation
becomes, it will always be the few when compared to the rest of the
Internet: the many.  No single operation is ever more important than
all operations.  Not mine, not yours, not Google, not Reddit, not anything.

I did say I'd try to get near a point.  Alright, here goes: if you
run anything, including a Tor exit node, then you are personally,
fully responsible for all abuse sourced from that operation.  Which
means that you are responsible for figuring out how to detect it
and stuff a sock in it.  Maybe that's easy.  Maybe that's hard.
Doesn't matter: it's still your responsibility.  You signed up for
it, you implicitly agreed to it, when you plugged *your* operation
into *our* Internet.

My suggestion 

Re: [liberationtech] Yahoo Hacks [and: it's about to get MUCH worse]

[Rich Kulawiec]

[ Sorry.  Just saw this now. ]

On Tue, Apr 09, 2013 at 07:54:23AM +0100, David Miller wrote:
 On 9 April 2013 01:29, Steven Clift cl...@e-democracy.org wrote:
 
  Part of the problem maybe yahoo mail hacked accounts which are an ongoing
  disaster.
 
 What's the deal with that - I seem to get lot's of YahooMail spam...
 couldn't find anything reporting on it when I googled though

The deal with that is that Yahoo fired/laid off/whatever their entire
postmaster and abuse team most of a decade ago.  The email operation appears,
from all external appearances, to be running on a combination of autopilot
and minimal attention from very junior and inexperienced people.

The lights are on but nobody's home.

It's thus not surprising that word of this has propagated through the
spammer/phisher/ID theft/malware/etc. community: they know a good thing
when they see one, and very large provider not paying much attention to
what is happening in its own operation is more than a good thing:
it's a *great* thing.  From their perspective, of course.

They have moved in and made themselves right at home in a big way.

The results are precisely you (and many many many others) have observed:
Yahoo is a major source of outbound spam.  They have been the target
of repeated large-scale successful attacks.  Accounts are being
compromised there at a very high rate.  Dropboxes for all sorts of
nefarious activities are nearly immune from action.  And so on.

The fix for this is obvious and easy and cheap, and will never happen.

A similar process is underway at AOL, which had a terrible (and deservedly
so) reputation but thanks to the hard work of Carl Hutzler and his team,
managed to claw their way back to being a responsible member of the
Internet.  AOL rewarded this team for their diligence and professionalism
by dismissing them.  And promptly began sliding back into the abyss,
a process that is now well underway.

One of the implications of this (besides the annoyance of fending
off abuse sourced from these incompetent and negligent operations)
is that they're no longer operationally secure, even for a relatively
weak definition of secure.  That is, it should be presumed that
unknown adversaries of unknown capabilities and motivation have neatly
entrenched themselves in their infrastructure -- since we are *looking*
at evidence demonstrating that this is true.

Given Yahoo's recent corporate moves/cost-cutting there is no reason
to expect this trend to reverse.  There is every reason to expect it to
get much worse.  And a recent announcement from Yahoo promises to
exacerbate the situation badly in the near future, thanks to this
stunningly bad idea, which, predictably, they plan to blunder ahead
with despite the appalling consequences:

http://www.wired.com/threatlevel/2013/06/yahoos-very-bad-idea/
and

http://www.huffingtonpost.com/2013/06/20/yahoo-identity-theft_n_3469173.html

---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] MOOC'd

[Rich Kulawiec]

On Thu, Jun 20, 2013 at 01:17:18AM -0700, Raven Jiang CX wrote:
 My own concern lies with the fact that the a great deal of academia and
 knowledge creation is currently being funded by the inefficient tuition
 system. If the transition to MOOC is too sudden, then we might irreversibly
 damage our knowledge engines when all that money disappears from the system.

I share this concern.  Unfortunately, here in the US, education/research
is not a national priority and is very poorly funded (at all levels).
In addition, the incredible damage done by NCLB is now rippling through
the educational ecosystem, and universities now have to deal with an influx
of poorly-prepared students.  Add to this the crumbling (quite literally)
infrastructure and the mediocre (at best) pay scales for primary and
secondary teachers, the increasing (and myopic) focus on short-term
directed-for-commercial-gain research over long-term open-ended enquiry,
and we have one heck of a mess on our hands.

---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] Deterministic builds and software trust [was: Help test Tor Browser!]

[Rich Kulawiec]

On Tue, Jun 18, 2013 at 08:54:30PM -0700, Mike Perry wrote:

[ one the most insightful, thoughtful messages I've ever read here ]

There's very little I can add to that, except to say that I look
forward to reading the future, longer writeup you mentioned.

Now get to work. ;-)

---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] Quick Guide to Alternatives

[Rich Kulawiec]

On Tue, Jun 18, 2013 at 11:30:00AM +0200, Julian Oliver wrote:
 It'd be also good to add GNU/Linux however. [...[

And the BSD family, notably OpenBSD -- whose development is led in
large part by one of my favorite curmudgeons.  (As I've said elsewhere,
some of the people working on OpenBSD are nit-picking, anal-retentive,
pedantic, intolerant, fanatical, insistent, demanding and relentless:
in other words, the perfect people to be crafting an operating system.)

 Use of open source applications alone is an insufficient measure against
 snooping today, IMO. 

True.  Open source OS/applications are necessary -- but not sufficient.

---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] Oakland Cryptoparty This Sunday at 1pm

[Rich Kulawiec]

On Fri, Jun 14, 2013 at 06:41:12PM +0200, Ernad Halilovic wrote:
 First of all, thank you for all your valuable input on this list.

You're very kind, but my contributions are minor and unimportant.  Others
have done far more.

 I wanted to ask you if you have any good resources on getting the hardware
 ready for a complete move of operations out of the cloud.

I'm not sure that I understand the question.  (Could be insufficient
coffee.)  Nearly any hardware will suffice, depending of course on
how much of a computational load it's got to carry; I routinely use
10+ year old systems to handle the building block tasks of running
an operation: NTP, DNS, SMTP, HTTP, etc.  Could you drop me a line
off-list and help me understand what it is you're looking for?

---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] Oakland Cryptoparty This Sunday at 1pm

[Rich Kulawiec]

On Fri, Jun 14, 2013 at 06:34:42PM +0200, Eleanor Saitta wrote:
 The issue with this approach is that maintaining infrastructure like
 this takes an ongoing time commitment by someone who is clueful (and
 thus at least moderately expensive for broke organizations where
 everyone's constantly overworked), and that older hardware fails, and
 keeping enough spares around to get reliability adds cost and
 complexity again.
 
 I'm (definitely) not saying this is a bad idea here, but it's
 important to understand what the real costs look like for
 organizations that may not natively have this talent, or where the
 folks who are supposed to do the work also have other jobs.  For
 instance, in every small org that I've seen that does development and
 has infrastructure, infrastructure-only hires quickly get absorbed
 into development work.

All entirely valid points.  I'm going to comment on them below but
will observe that at this point, it's actually not hard at all to
keep a *lot* of spare hardware around.  Much of it's free for the
taking: folks are happy to get rid of it and are delighted if someone
backs a truck up to their loading dock.

But that's kind of a minor consideration, and your point about the
time/labor investment is a much larger and more important one.

 Running mail as reliably, securely, and conveniently as Google does
 with GMail is actually hard; this is why it's achieved the popularity
 it has, not just the cost.  I've watched many friends and orgs over
 the past 9 years decide they just didn't have the time any more.

I'm often puzzled by why so many people seem to hold Gmail in such high
regard.  IMHO, Gmail merits only a gentleman's C, no better. [1]

That's not bad by comparison.  Yahoo?  F.  Hotmail?  F.  AOL?  D. (AOL used
to be up to about a B, but after dismissing the entire postmaster/abuse
team that did such excellent work, they've regressed badly.)

Now what Gmail *did* have was a fairly slick user interface, although like
so many sites, they've taken a modestly clean, usable UI and cluttered
it up with crap.  And more crap.  And still more crap.  It's well on
its way to become horribly bloated unusable rubbish, and I'm sure that
in another revision or two it'll complete the journey.  Yay UI designers!
Mission accomplished.

Shifting gears, your point about the effort required to do it yourself
is valid.  And important.  But there's another side of this:

You're certainly correct that running your own SMTP/DNS/HTTP/etc. requires
a skillset and effort.  Vendors of these, who make their money by
convincing people that it's oh so very hard and that they simply
must outsource these tasks, have done a great job of promoting a
culture of learning helplessness over the past decade-plus.

But it's not that hard.  I think anyone with baseline system admin
skills should be able to handle it, and for many years, THEY DID.

Sure it's gotten a *little* harder, but the tools have gotten much
better too.  I think at this point a lot of the apparent difficulty
that people repeatedly bump their heads against is self-created:
it looks hard to them *because they made it so*.  Real world example:

Problem: Oh dear, our Exchange server has been 0wned.  Again.

Asserted root cause: Our firewall is inadequate.  Our IDS/IPS isn't
good enough.  Our antivirus software is outdated.  We haven't kept
it fully patched.

Asserted solution: Outsource the Exchange server to $PROVIDER.

Real root cause: Exchange.

Real solution: Don't run Exchange.  It's expensive crap.

Of course when things like this are pointed out, there follow
of litany of justifications and rationales and excuses.  The denial
runs deep.  Very few will actually take a moment to tip back their
chair, stare at the ceiling, THINK, and realize that they made the
real mistake when they signed the purchase order (or perhaps when
they were scribbling on the whiteboard), and that nothing they
can possibly do now will truly fix the situation *unless* they back
up and fix the original error.

But that would require admitting it, which is why it rarely happens.
I've watched people pour rivers of money down the toilet desperately
trying to fix unfixable problems rather than admitting they screwed up,
throwing it away, and starting over -- which would yield far better
results faster and cheaper.  Nope.  They can't bring themselves to do it.
They're too deeply invested in their own mistakes to undo them.
It would be, as they say, a career-limiting move.

So if one makes poor choices in architecture, systems, applications, etc.,
and stubbornly sticks with them, then yes, this problem set can be
made very difficult and very expensive.  And then, *yes*, it can seem
a very attractive option at that point to sidestep the whole mess
by outsourcing it.

But that doesn't undo the poor choices.  It just sloughs the problem
set off on someone else, it costs money, and it seriously degrades
one's 

Re: [liberationtech] Boundless Informant: the NSA's secret tool to track global surveillance data

[Rich Kulawiec]

On Sun, Jun 09, 2013 at 10:11:08AM -0400, Nadim Kobeissi wrote:
 On 2013-06-09, at 10:08 AM, Rich Kulawiec r...@gsp.org wrote:
  Second: stupidity, in all forms, fully deserves to be slapped down --
 
 This is where I stop reading.

I have to admit, even though I've read this half a dozen times,
I don't get it.  I tried coffee.  Nope.  I tried scotch.  Nope.
I tried staring at the clouds.  Nope.

So let me try explaining my take on it.

We're not playing around here.  There are people out there reading
this list and trying to figure out how to use technology to fight
human rights abuses, stop wars, reveal corruption, etc.  And they're
opposed, in many cases, by very smart very nasty very ruthless people
who will not hesitate to threaten, kidnap, torture and kill anyone
they perceive as a credible threat.

The advice we hand out here, the technology we create, may be the
difference in keeping the former group safe from the latter.

So if one of us makes a mistake, then we all need to know.  If I recommend
bad crypto because I don't know any better, *someone* had better smack
the crap out of me as quickly as possible before someone else makes the
mistake of listening to me.  I'll get over the momentary embarrassment:
heck, I make enough mistakes in an average day that I've gotten pretty
used to it.  I won't get over knowing that my error cost someone else dearly.

We owe that to all the people who are in the field trying to make this
world a better place.  We need to be as right as we can be, with our
limited knowledge and human propensity for mistakes.  And we need to not
worry about *who's* right or *how* they're right, because once we've
rid the world of poverty and starvation and disease and bigotry and
prejudice and violence and ignorance and superstition and repression,
then we'll have plenty of time to sit around and philosophically
debate the fine points of who should get which credit for what part of
the glorious and peaceful new reality.

Also there will be scotch.  Really, really good scotch. ;-)

So yes, stupidity SHOULD be slapped down.  So should ignorance,
superstition, prejudice, bigotry, and all of the other negative things
that -- during all of recorded human history and likely before --
have been the tools of tyrants and dictators.  Empires come and go,
political structures become fashionable and then fade away, the names
and places change constantly...but *these* things are the constant
enemy.  If we are to overcome them in those we oppose -- we must
first overcome them in ourselves.

---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] Internet blackout

[Rich Kulawiec]

On Thu, Jun 13, 2013 at 04:27:17PM -0700, Seth David Schoen wrote:
 These properties are really awesome.  One thing that I'm concerned
 about is that classic Usenet doesn't really do authenticity.  It
 was easy for people to spoof articles, although there would be
 _some_ genuine path information back to the point where the spoofed
 article originated.  It seems like if we're talking about using
 Usenet in an extremely hostile environment, spoofing and forgery
 are pretty significant threats (including classic problems like
 spoofed control messages! but also cases of nodes modifying
 message content).  

I completely agree with you: I share that concern.  I think a *possible*
fix for it -- or perhaps fix is too strong a term, let me call it
an approach -- is to remove the Path: header (among others) and use
the article body's checksum as a unique identifier.  Thus node A,
instead of telling node B I have article 123456, do you want it?,
would say instead, I have an article with checksum 0x83FDE1, do you
want it? -- slightly complicating propagation, but not unduly so.
I think this can be used to strip out all origination information:
when A presents B with articles, B will not be able to discern
which originated on A and which are merely being passed on by A.

Encrypting everything should stop article spoofing.  (Although it
doesn't stop article flooding, and an adversary could try to overwhelm
the network by injecting large amounts of traffic.  Deprecating the
Path: header actually makes this easier for an attacker.)  The use of
encryption also means that private messages can be sent from user U1
to user U2 -- yes, they'll be present on every node (eventually) but
only user U2 will be able to decrypt them using her private key.

(In other words, the way U2 discovers which messages are directed to
her is that she attempts to decrypt them *all*.  When it works: that
one was for her.  Provided an adversary does not have U2's private key,
the adversary can't figure out which ones are addressed to her.  Or who
they're from.  Or where they originated. [1])

Your mention of spoofed control messages is spot-on: that's another
problem with this.  I've been thinking that perhaps the approach to
that is to consider only allowing certain control messages: for example,
article cancellation probably shouldn't be supported.  (I briefly thought
about encrypted article cancellation but then realized that it would
only work on one node: that belonging to U2 in the example above.
Not very useful!)  I rather suspect though, that my analysis of this
is incomplete and that the best way to figure out how to deal with
control messages might be to set up a testbed network and have someone
play the role of an adversary.

Clearly, the Usenet model is very efficient for one-to-many, but
inefficient for many-to-one and one-to-one.  However, that same
inefficiency is what gives it the ability to survive major node loss
and link disruption and still work.  It's also what makes it resistant
to traffic analysis: when everyone says everything to everyone else,
it's much harder to discern who's really talking to who.

Speaking of survivability, this recent work:

Guaranteed delivery -- in ad-hoc networks
http://web.mit.edu/newsoffice/2013/ad-hoc-networks-0109.html

has direct applicability here.  Hauepler's algorithm shows that to
guarantee delivery to a network of N nodes, delivery to log2(N) nodes
will suffice.

What all this does *not* give a real-time communications medium.
But I'm not at all sure that's desirable.  Over the past few years,
I've slowly formed the hypothesis that the closer to real-time
network communications are, the more susceptible they are to
(adversarial) analysis.  I can't rigorously defend that -- like I said,
it's just a hypothesis -- but if it's correct, then it would be a good
idea, when and where possible, to make communications NON-real-time.
(Thus it might be a good idea for nodes participating in this
kind of network to randomize the time intervals for outbound
transmissions, in order to avoid generating a flurry of network
activity that can be readily associated with an external event,
a location, or a person.)

One of other nice features of a Usenet-like architecture is that
it works beautifully with sneakernet data transmission.  A micro SD
card or a USB stick can hold a *lot* of data, and they're easily
concealed, traded, or dropboxed.  It's not at all unreasonable to
conceive of a scheme where daily reports of events inside Elbonia
are transmitted by physically carrying them to a location outside
Elbonian-controlled network space and injecting them back into
the network.  Or vice-versa.

I'm not saying this is the answer.  I'm not even sure it's an
answer.  But I think it might be the foundation for one.  Now if
I could just find the funding to work on it for 6-12 months I'd
be all set. ;-)

---rsk

[1] I suspect that an adversary in possession of a large number of
nodes might be 

Re: [liberationtech] U.S. Agencies Said to Swap Data With Thousands of Firms

[Rich Kulawiec]

On Fri, Jun 14, 2013 at 02:14:16PM +0300, Maxim Kammerer wrote:
 An interesting article, showing why ?responsible disclosure? of
 exploitable bugs is a bad idea.

I concur.  I've often argued that there is no such thing as responsible
disclosure -- it's a self-serving fiction concocted to satisfy the PR
needs of companies. [1]

I'll also note that this fairly conclusively demontrates that all the blather
about how the US government wants to promote cybersecurity is 100% bullshit.

---rsk

[1] The same companies that have the arrogance to demand responsible
disclosure from people who owe them *nothing* are very often the same
companies who've failed to provide responsible coding to their own
customers.  *cough* Adobe Acrobat security hole-of-the-week *cough*
--
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] Internet blackout

[Rich Kulawiec]

On Tue, Jun 11, 2013 at 05:44:38PM -0400, Richard Brooks wrote:
 This lead me to start thinking about the possibility
 of deploying something like Fidonet as a tool for
 getting around Internet blackouts. Has anyone tried
 something like that?

Usenet has long since demonstrated the ability to route around
amazing amounts of damage and flakiness and to maintain communications
over very slow (including sneakernet) links.

Arguably, that sentence describes the normal operational state of the
network on a typical summer day just like this one, 30 years ago. ;-)

Usenet has some very nice properties for applications like this:

1. There is no centralization.  Thus there is no single target to
shut down or block.

2. Messages are not addressed to individuals.  This frustrates
some traffic analysis.

3. It's transport-agnostic.  Messages can be passed via IP, via UUCP,
by USB stick, CD, DVD, etc.

4. It's highly delay-tolerant.

5. It's content-agnostic.

6. It's highly fault-tolerant.

7. It doesn't require real-time IP connectivity.  In areas where
IP connectivity is scarce, expensive, intermittment, wiretapped
or blocked, this is a big plus.

8. It's standardized.

9. Mature open-source software already exists for it.

10. Peering relationships can be ad-hoc.

Not that it would work for this application as-is: the article
duplication method would need to be replaced because the current
one leaks origin information.  But I think that's a solvable problem.

I submitted a proposal on this very point a few months ago; haven't
heard a thing back, so my guess is that's not going anywhere.  But I
think with a relatively modest investment, the additional code could
be written and a testbed network constructed to figure out if this
really is a viable architecture.  My hunch (of course) is yes but
I'd prefer to remain skeptical until there's some experimental
evidence that it'll hold up under the kind of duress we've seen
in various countries during the past few years.

---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] Boundless Informant: the NSA's secret tool to track global surveillance data

[Rich Kulawiec]

On Mon, Jun 10, 2013 at 01:48:23PM -0700, x z wrote:
 @Rich, those are good movie scripts :-). But it does not work for 9 firms,
 and hundreds of execs all with diverse values and objectives.

Two responses.

hundreds?  Not necessary.  Not desirable, from the NSA's point of view,
either.  One person per firm would suffice, and they need not be an executive.
Surely you can't think for a moment that the NSA is incapable of placing
its own people on the datacenter staff of any major operation?

Second, how's this for a movie script?

(quoting myself)

 Ad I'd also, by the way, develop custom lookalike hardware.  (With
 the NSA's budget, this could be done with chump change.)  Who's going to
 open up a Cisco router and yank a board and look at it closely enough
 to figure out that it didn't come from Cisco?

Now quoting this (h/t to Rob Slade):


http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-From-China

This paper is a short summary of the first real world detection
of a backdoor in a military grade FPGA.  Using an innovative
patented technique we were able to detect and analyse in the
first documented case of its kind, a backdoor inserted into the
Actel/Microsemi ProASIC3 chips. The backdoor was found to exist
on the silicon itself, it was not present in any firmware loaded
onto the chip. Using Pipeline Emission Analysis (PEA), a
technique pioneered by our sponsor, we were able to extract
the secret key to activate the backdoor. This way an attacker
can disable all the security on the chip, reprogram crypto and
access keys, modify low-level silicon features, access unencrypted
configuration bitstream or permanently damage the device. Clearly
this means the device is wide open to intellectual property theft,
fraud, re-programming as well as reverse engineering of the design
which allows the introduction of a new backdoor or Trojan. Most
concerning, it is not possible to patch the backdoor in chips
already deployed, meaning those using this family of chips have
to accept the fact it can be easily compromised or it will have
to be physically replaced after a redesign of the silicon itself.

---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

[liberationtech] Edward Snowden has gone missing

[Rich Kulawiec]

http://www.theatlanticwire.com/national/2013/06/where-is-edward-snowden/66072/

I'm reminded of this exchange, which I presume everyone on this
list is familiar with:

I'd like to go back to New York.

You have not much future there.  It will happen this way: you
may be walking, maybe the first sunny day of spring.  And a car
will slow beside you, and a door will open and someone you know,
even trust, will get out.  And he will smile, a becoming smile.
But he will leave open the car door and offer to give you a lift.

---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] Boundless Informant: the NSA's secret tool to track global surveillance data

[Rich Kulawiec]

On Mon, Jun 10, 2013 at 01:30:19AM -0700, x z wrote:
 First of all, I don't feel offended by Jacob's reply to my email at all,
 probably because I know and expect his style of wording. So far I think the
 discussion is still pretty civil.

I concur.  This is what spirited discussion looks like.  It's healthy.

Let's dig in.

 - The PRISM slides do not prove such direct access (as we interpret it)
 exists.  [snip]

You're correct.   To take your point further, they don't prove *anything*,
they...well, for lack of a better word, they indicate.  They point in
a general direction, omitting significant details -- which is of course
why we're debating just what those details are.

But, that said: the NSA (and every other similar agency) has a long
history of engineering for their convenience over engineering for due
process and safeguards.  And certainly direct access is far more convenient
for them than multistep processes.  So I think it's pretty safe to say
that the NSA would very much *like* direct access if they can get it.
Which leaves us with the question of whether or not they have.  Yet.

 - The firms (Apple, Google, Facebook, etc) do not have any incentive to
 participate in such a program to offer direct access to NSA.

A, but I think they do.  There's a message I noticed on this list
this morning, which was forwarded from Dave Farber's excellent IP
(Interesting People) mailing list and explains one such incentive:


https://mailman.stanford.edu/pipermail/liberationtech/2013-June/008815.html

 Then, what kind of power do people think NSA possesses that
 can secretly coerce these firms into cooperation?? 

That kind of power.  (see link, just above).  To paraphrase an old
saying, you can get much more with a kind word and a hide nailed to
the wall than you can with just a kind word.

 Will these firm's CEO or Chief Legal Officer go to jail, for not providing
 direct access?

Maybe.  See above.  But jail is not the only possible unhappy outcome.
There are other kinds of pressure that can be brought to bear as well.

Consider the set S of {all Cxx executives at all the tech companies
mentioned so far plus the ones involved but not yet mentioned}.

Now consider the number N of members of set S who (a) are in financial
difficulty (b) have a monkey on their back (c) have something in their
past (d) did something dubious on their tax returns (e) failed to disclose
something to the SEC (f) etc.

As the size of set S increases, the probability that N=0 decreases.
And whatever N is, it provides N opportunities for leverage.

I think it's also safe to say that some of those people would do it
merely because they're asked: it appeals to their sense of patriotism.
We might argue that this is wrong, that it violates the Constitution and
thus is about as unpatriotic as it's possible to be; but they would not
agree with us.

And there's another approach: large companies like this are very
sensitive to bad press, or even the possibility of bad press.
None of them want any part of this potential future story:

US law enforcement: we could have stopped [name of future
attack], but Internet giant Blah, Inc. wouldn't cooperate.

Yeah, that's a longshot, but to risk-averse Cxx people, it might be
enough of a nonzero probability to convince them.  (And there's
already a long history of blame the Internet narratives, so it
would dovetail nicely.)  Blah, Inc.'s stock would drop a kazillion
points in the minutes after that story broke and thus so would the
personal fortunes of many.  Then there would follow recriminations
and the blame game, board meetings and firings, and in the end,
suitably obedient people would be put in place to make sure that
it never happened again.

 - If all these participating firms have built such a system to feed NSA's
 request automatically, many people would have got involved. This is not a
 trivial task, the executives need to find engineers to make it happen. And
 the number of engineers won't be small, given the diversity of data
 mentioned here. 

I think this is the strongest argument in support of your proposition.
I've spent some time over the past few days trying to figure out how
this could be done and haven't yet figured out a method that would be
likely to succeed.

On the other hand, the NSA has had years, billions of dollars, and
thousands of people to throw at the problem, so if a solution within
those constraints exists, they're far more likely to have found it
than I'll ever be.

But let me requote something you wrote:

[...] the executives need to find engineers to make it happen.

Not if the executives weren't involved.

The NSA *could* go directly to the NOC engineers, for example, and
there are certain advantages to doing so: for one, these are people
with a lot less wealth and power, thus perhaps more readily manipulated.
For another, these are the people who actually need to do the work --
unlike the Cxx-level people who don't need to be 

Re: [liberationtech] Boundless Informant: the NSA's secret tool to track global surveillance data

[Rich Kulawiec]

On Sun, Jun 09, 2013 at 09:45:31AM -0400, Nadim Kobeissi wrote:
 I don't agree with x z (and rather agree with you), but I'm really tired of 
 just how aggressive and rude you always are on Libtech. 

First: you've got to be kidding.  I've never seen a single message on
this list that goes past about 2 on a 10 scale.  (Not that I'd mind
seeing things that go higher: I really do enjoy quality flamage.)

Second: stupidity, in all forms, fully deserves to be slapped down --
hard.  I expect that if I say something stupid here (and if I haven't
already, eventually I will) that I'll get hammered for it.  Good.
I should be.  Because I would rather endure the pummelling and the
possible embarassment than persist in being wrong.  (Or worse,
making someone else be wrong too because they think I'm right when
I'm most certainly not.)

Third: anyone who can't handle the exceedingly gentle discussions here
(which are, generally speaking, held between people who are *all on the
same side*, at least in a philosophical sense), is really, really not
up to the task of liberating anything.  Because doing so will require
going up against people who will do far more than just type a few mildly
caustic words in an email message from time to time.

Jacob's contributions here are among the most cogent and useful.  I don't
care how aggressive and rude he is (and I don't think he is at all,
by the way), I care if he's right -- and he has an excellent track record
of being so.

---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] Google Denies PRISM Involvement

[Rich Kulawiec]

(Quoting myself from something I just sent to NANOG in re the
same question: are the Cxx people at Google and elsewhere telling
the truth?)

*puts on evil hat, adjusts for snug fit*

Targeting the technical people who actually have their hands on the
gear might be the best choice.  They don't have the power, wealth
and soapbox of the Cxx-level people.  They are thus far more easily
intimidated into silence.  Unlike the Cxx people, they actually spend
time in data centers.  And by keeping the Cxx people in the dark,
their public denials will carry more credibility because they will
actually believe they're telling the truth.  (When's the last time
any of them got their hands dirty crawling pulling out raised floor
tiles and running cable?)

---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] Want to shield text, photos from government? Wickr says it has an app for that | SiliconBeat

[Rich Kulawiec]

It's not open-source, therefore it not only *can* be discarded without
any further discussion, it MUST be.

---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] Stop promoting Skype

[Rich Kulawiec]

These revelations constitute an existence proof that the number
of backdoors in various services is nonzero.

There's no reason to believe that this nonzero value is 1.

After, if the NSA could backdoor them (with or without their cooperation)
then why couldn't MI6?  Or Mossad?  Or some other entity, which may or
may not be a national intelligence service?

There's also no reason to believe that this practice is limited to the US.

---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] Stop promoting Skype

[Rich Kulawiec]

On Fri, Jun 07, 2013 at 02:48:58PM +0200, Eugen Leitl wrote:
 On Fri, Jun 07, 2013 at 08:32:36AM -0400, Rich Kulawiec wrote:
  
  These revelations constitute an existence proof that the number
  of backdoors in various services is nonzero.
  
  There's no reason to believe that this nonzero value is 1.
 
 It is prudent to believe that the value is exactly one.
 This particular disclosure is a merely another data point.
 We didn't need it in order to assume the value is exactly one.

I'm not following you -- maybe I need more coffee this morning,
but I don't understand the reasoning behind your statement.

Mine is something like this: if one day, the folks from the NSA showed
up at X's door with a van full of equipment and asked nicely if they
could please bring it in, then why wouldn't their counterparts in every
other country do the same to X's sites there?  And since X wants to do
business in those countries, why would it say no?

If on the other hand this was done by the NSA without X's knowledge,
then their counterparts in other countries could try that approach
as well.

So would you mind explaining yours?  (My apologies if it's completely
obvious and I'm just being dense.)

And a side point/adjunct to this: so far, I haven't noticed Amazon
or Rackspace or Softlayer or similar on these lists.  (Again, maybe
more coffee is badly needed.)  I can't believe for a moment that
the NSA overlooked any of the major cloud computing providers.

---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] Twitter Underground Market Research - pdf

[Rich Kulawiec]

On Tue, Jun 04, 2013 at 06:44:37PM +0100, Bernard Tyers - ei8fdb wrote:
 I wonder if there is any connection between these  merchants and botnets?
 Botnet owners or spammers would seem like a great source of valid IDs.

Let me introduce a term you might/might not have heard before in other
contexts to this conversation: abuse magnet.  An abuse magnet is a service
whose operators either (a) did not anticipate the ways in which it
would be abused and architect to defeat them or (b) did anticipate them,
but simply didn't care to spend the time and money necessary.

In both cases the operators have thus neatly shifted the burden of damage
control (in terms of effort, money, etc.) onto the entire rest of the Internet.
Given that in nearly all such instances, the entire rest of the Internet
takes no action (or even realizes that this has happened) this is usually
an extremely cost-effective, low-risk strategy.  Scummy, but cost-effective
and low-risk. [1]

An example of this would be Yahoo's email service.  After Yahoo made
the decision some years ago to fire/layoff/disband its abuse team,
it wasn't long until spammers, phishers, scammers, etc. realized that
they could move in and take over the place.  And they did.  Why not?

As a result, outbound abuse from Yahoo's email service is chronic
and pervasive.  So is abuse support using it, i.e., it's quite popular
as a location for phisher dropboxes, it's frequently used to register
spammer/phisher/typosquatter/etc. domains, and so on.

Anyway, I don't particularly mean to pound on Yahoo -- although they
certainly deserve it.  My more general point is that there are entire
classes of abuse magnets out there which are either overrun by abusers
or in the process of being so.  To name a few:

- freemail services
- URL shorteners
- social networks
- cheap domains

It's therefore not at all surprising to see abusers such as phishers,
spammers and botnet operators utilizing these in combination: they're
zero/low-cost resources, they're available in abundance, they have
non-existent or wholly dysfunctional abuse desks [2], and there are few,
if any, consequences for engaging in massive abuse. [3]

And I do mean massive: for example, I wouldn't be surprised at all if
someone put proof on the table that 90% of all freemail accounts or 90% of
Twitter accounts are owned by abusers.  I'm not saying that's true,
because I can't prove it's true: I'm just saying that I wouldn't even
raise an eyebrow if someone else proved it to me, because it seems
quite reasonable.  The same will eventually be true (if it isn't already)
on social networks because there's no reason for it not to be,
and every reason for abusers to make it so.

Besides: who's going to stop them?

Certainly not service operators who want to tell their venture
capitalists/shareholders that they have 5.7 bajillion users...even
if they really do know that 5.1 bajillion of those are bogus.
What, *exactly*, is their motivation to do something about that?
(And besides, there is substantial evidence supporting the proposition
that some of them ARE the abusers.)

And all of this is before we get to the problem of hijacked accounts,
i.e., those which were opened by real live legitimate users but don't
belong to them any more.  (In the case of freemail providers, this is
already epidemic.  And getting worse.)

The fix for this mess is to think about the potential for abuse while
ideas are still at the back-of-the-envelope or scribbled-on-a-whiteboard
stage.  But few people do that, and as a result they create
architectures that are difficult to defend from abuse in production
even if they *want* to do so.  It almost never seems to occur to them,
at that early stage, that their shiny new creation may have uses other
than the ones they envision for it.

It's a poor atom blaster that won't point both ways.
--- Isaac Asimov, Foundation

One more point: operations that are this incompetent and negligent
cannot possibly provide any real assurance of security and privacy
to their users, because their putative operators are no longer in
full control of them.  Not really.  Oh, they can make noises about
doing so, and they can pretend that they're doing so...but they can't.

---rsk

[1] One of the most profound, useful, cogent statements on this
point comes from Paul Vixie via the NANOG mailing list:

If you give people the means to hurt you, and they do it, and
you take no action except to continue giving them the means to
hurt you, and they take no action except to keep hurting you,
then one of the ways you can describe the situation is it isn't
scaling well.

This explains, in one sentence, precisely why we have a spam problem
in 2013, thirty years after the fix for it was completely understood.

[2] One baseline test of this is to find out whether mail to the RFC-2142
stipulated address abuse@[domain] is handled properly.  Responsible,

Re: [liberationtech] Cell phone tracking

[Rich Kulawiec]

On Sun, Jun 02, 2013 at 10:16:20PM -0400, Nathan of Guardian wrote:
 In summary, if the focused threat you need to address is location
 tracking by carriers/operators, and you live in an area with a decent
 saturation of open wifi hotspots, I feel there is something you can do
 about it. Now your adversaries have to work a bit harder (tracking IPs
 to hotspots, physical surveillance, etc) to build a geo map of your
 comings and goings.

In re this topic, please see this paper:

Unique in the Crowd: The privacy bounds of human mobility
http://www.nature.com/srep/2013/130325/srep01376/full/srep01376.html

Abstract:

We study fifteen months of human mobility data for one and a half
million individuals and find that human mobility traces are highly
unique. In fact, in a dataset where the location of an individual
is specified hourly, and with a spatial resolution equal to that
given by the carrier's antennas, four spatio-temporal points are
enough to uniquely identify 95% of the individuals. We coarsen
the data spatially and temporally to find a formula for the
uniqueness of human mobility traces given their resolution and
the available outside information. This formula shows that the
uniqueness of mobility traces decays approximately as the 1/10
power of their resolution. Hence, even coarse datasets provide
little anonymity. These findings represent fundamental constraints
to an individual's privacy and have important implications for
the design of frameworks and institutions dedicated to protect
the privacy of individuals.

And remember Schneier's maxim: attacks always get better.  So the work
which these researchers have done (and it appears to me to be fine work)
will be extended, refined, improved.

---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] Medill online Digital Safety Guide

[Rich Kulawiec]

On Wed, May 29, 2013 at 03:21:45PM -0700, fr...@journalistsecurity.net wrote:
 I appreciate your feedback and your bluntness, Rich.
 
 But you are providing far more guidance about what to avoid than what to
 use. If journalists and other users should avoid all commercial based
 operating systems including Macs, or any system requiring anti-virus
 software, then what operating system should they use? Linux maybe? Or
 something else?
 
 Similarly, if they shouldn't use GUI-based email clients, what email
 should they use?

See below, I'll try to address these questions.

That's actually not my blunt voice.  That's my exasperated voice,
because I've grown exceedingly weary of listening to people explain
how to secure a closed-source OS/application environment.

Can't. Be. Done.

The evidence supporting that statement is already piled so high that one
could spend a lifetime examining it and not finish.  And more arrives
all day, every day.  Yet there are STILL people trying to claim
that yes, you can secure your Windows desktop if only you use anti-spyware
anti-virus anti-malware anti-anti-anti-whatever.  If only you spend enough
money.  If only you use IDS/IPS/firewalls/yadda yadda yadda.

No, you can't.

Not for any reasonable value of secure.  (Yes, yes, I'm well
aware that nothing is absolutely secure, I'm using the term
in sense of adequate to stop attacks it might plausibly face.)
People do all those things and spend ferocious amounts of money on
them and yet they are STILL routinely 0wned.  It never seems to
occur to them to step back and consider that they're doing something
fundamentally wrong; it always seems to occur to them that throwing
more money at the problem will fix it.  It won't.

And for your use case, where we can presume that the users' systems
will come under scrutiny from governments, criminal gangs, and other
unsavory people with substantial resources, including possibly the
implied or overt threat of physical force, it's absurd to even consider
that approach.  You need to discard it entirely and try something that
has an appreciable chance of working -- NOT something that's guaranteed,
as I don't think that exists, but something that at least gets you
into the game and gives you a fighting chance.

Is Linux the best choice?  Maybe.  Maybe FreeBSD is.  Maybe something
else.  We could argue (and we *have* argued, for many years) about their
relative merits and drawbacks.  I'll propose that for this purpose it may
well be entirely reasonable to create a custom Linux or BSD distribution
that has only the essentials required for reporters/editors in the field
to do their jobs.   Perhaps it should be based on something that already
exists, e.g., Tails.  But what all of those alternatives have in common is
that they raise your probability of success from zero to something non-zero.

That's not enough, of course.  Reasonably secure software environments
only stay that way if they're used appropriately: procedures are as
important as code.  So if someone equipped with one of those is so
insanely stupid as to log onto Facebook [1] or some other scam site,
then they're probably neatly undercut themselves.  Using these tools
properly takes discipline, restraint and thoughtfulness.

For example: users need to actually look at URLs before they follow
them and they need to know enough to realize that google-com.com
is probably not Google and that CIT1BANK.COM is probably not CitiBank. [2]

Yes, that's tedious.  Sorry.  But it's not as tedious as being
locked in a cell for six years while the State Department
tries to negotiate your release.

Anyway, my point is that a judicious combination of careful procedures
and minimal software applications on a robust operating system will
yield something that has a much higher level of operational
security than anything you can build around a closed-source base.
Or to put it another way, all the discipline/restraint/thoughtfulness
in the world will not help you if you insist on using Adobe Acrobat,
thus making yourself a member of the Ginormous Acrobat Security Hole
of the Month Victim's Club. [3]  Or if you choose to use Outlook
instead of mutt (see http://mutt.org), which is a pretty robust
full-featured email client that trained users can use far more
efficiently than many others.

So a constructive approach to this might be (might be):

1. Write a functional specification.  What computing
tasks do reporters/editors/etc. in the field have to do?

2. Determine what applications can perform those tasks.

3. Figure out which OS those applications will run on.

4. Figure out what the minimal installation looks like.
(No point in having FrozzleBlah 1.7 installed if it isn't used.
Less software = less attack surface, to a first approximation.)

5. Set the onboard firewall to bidirectional default deny.
Then start figuring out what holes need to be punched in it
to make (2) feasible.

Re: [liberationtech] Microsoft Accesses Skype Chats

[Rich Kulawiec]

On Tue, May 14, 2013 at 09:14:19PM +0530, Pranesh Prakash wrote:
 Heise Security is reporting that Microsoft accesses links sent over
 Skype chat.[1]

Everyone who thinks that's the *only* thing that Microsoft is quietly
doing behind everyone's back, raise your hand.

And incidentally, the proffered rationale for this doesn't fly, given
that (a) they're only sending HEAD: actually scanning destination URLs
for malware et.al. would require fetching the whole page and (b) they're
only retrieving HTTPS URLs (per Heise) which is not what someone actually
looking for malware would do.  Moreover (c) even if they classified
a URL as malicious, let's say https://example.net/blah, the recipient
of said URL is likely to access it via a data path outside their control,
thus -- unless they blocked it *inside* Skype -- they have no way to
prevent access to it and delivery of whatever malware payload awaits.

Source code is truth; all the rest is smoke and mirrors, hype and PR.
If Microsoft had the *slightest* interest in telling y'all the truth,
then they would have answered the group letter earlier this spring with
code, not with glib prose crafted by a committee of talented spokesliars.

---rsk

p.s. Heise's discovery is an existence proof that it's possible to
intercept the contents.  Therefore we must presume that other entities
besides Microsoft may have this capability -- doubly so given that some
of those entities have not only the resources, but the motivation.
--
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] Call for Papers: World Congress on Internet Security (WorldCIS-2013)

[Rich Kulawiec]

On Fri, Apr 05, 2013 at 10:29:12AM +0100, Dan Lin wrote:
 World Congress on Internet Security (WorldCIS-2013)
 Technically Co-Sponsored by IEEE Tokyo Section
 August 5-7, 2013
 Venue: Tokyo University of Information Sciences, Japan
 www.worldcis.org

I'm throwing the bullshit flag.  I think this is another fake conference
(as we've recently discussed) being promoted via spam.

---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] how spammers work, was: You are awesome, Treat yourself to a love one

[Rich Kulawiec]

On Sun, Mar 31, 2013 at 11:47:31AM +0200, M. Fioretti wrote:
 How could that happen? In the same, totally unsurprising ways in which
 always happen to everybody who takes the same measures as you (no
 offense meant, really, just a technical explanation!). It happened in
 one of these two ways (there may be others, but these are by far the
 easiest and most likely):

Excellent explanation.  Let me augment it by quoting part of something
that I sent to the mailman-users list a few years ago, in which I pointed
out that obfuscating email addresses is not going to work, e.g.,
constructs like rsk at gsp dot org are a stupid and pointless waste
of everyone's valuable time.

- begin snippet -
Briefly: spammers have many methods of acquiring addresses, including but
not limited to:

subscribing to mailing lists
acquiring Usenet news feeds
querying mail servers
acquiring corporate directories (sometimes from their web sites)
insecure LDAP servers
insecure AD servers
use of backscatter/outscatter
use of auto-responders
use of mailing list mechanisms
use of abusive callback mechanisms
dictionary attacks
purchase of addresses in bulk on the open market.
purchase of addresses from vendors, web sites, etc.
purchase of addresses from registrars, ISPs, web hosts, etc.
domain registration (some registrars *are* spammers)

and oh-by-the-way:

harvesting of the mail, address books and any other files
present on any of the hundreds of millions of compromised
Windows systems

It's therefore prudent to assume at this point that ANY email
address that's actually been used is either (a) in the hands of
spammers or (b) will be soon, and to plan defenses accordingly.

Now, what's unknown and unknowable is:

- how long it'll take
- which spammers
- whether they'll use it
- how they'll use it
- how often they'll use it
- whether they'll sell or barter it
- how competent they are at spamming
- how competent the people they sell/barter it to are at spamming
- whether the spamming technique(s) they use will be blocked
by the anti-spam measures in place
- whether the address will still be valid by the time they
get around to spamming it
- whether they might deliberately avoid it because they
think it's a spamtrap
- how long all this other stuff will take

Therefore:

Trying to keep spammers from getting your email address
is not a solvable problem for the set of email addresses that are
in routine use.  (Yes, if you run your own mail server, if you know
how to secure it, if you create one-off addresses that are never
used, then you can do it.  This is vastly beyond the technical
capabilities of most people, and it's not worth unless you are
attempting to customize a spamtrap.)

- end snippet -

So unless you have the kind of specialized skills I referred to above,
you should presume that spammers have (or will soon have) every email
address you use -- and plan your defenses accordingly. [1]

As to the example I gave above, rsk at gsp dot org: the same 
people who run worldwide botnets with sophisticated command/control,
who craft custom malware, etc., are quite capable of writing:

perl -pe 's/[ ]+dot[ ]+/./g; s/[ ]+at[ ]*/@/g'

and a hundred variants, if the need arises...and it probably won't.

---rsk

[1] Basic anti-spam defense is quite easy.  Any middling mail system
admin using an open-source MTA such as sendmail, postfix, or exim should
be able to deploy a system that blocks about 95-98% of incoming spam
with a 1 in 10e5 to 10e6 false positive rate without exerting themselves
too much.  The trick is not so much what to do but what NOT to do.
--
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] suggestions for a remote wipe software for Windows?

[Rich Kulawiec]

I think remote wipe software is a scam.  There is no way to know that
the system will ever be remotely accessible[1]; there is no way to know that
it will be booted into the operating system that was installed; there is
no way to know that the storage media will even be in the same system
when it's accessed; there is no way to know that the wiping software
will run before storage media are accessed; there is no way to know that
the wiping software will finish running; there is no way (in general)
to know that the wiping software will do a thorough enough job.

Yes, you might accidentally defend against a common thief who doesn't
know any of this and boots your laptop into your OS on their network
without a sensibly-configured firewall in the data path.  But most
of them will learn, soon enough, not to do that -- it'll probably just
take a few high-profile cases that attract enough media attention.

Use encryption -- so that your storage media are functionally pre-wiped,
so to speak, all the time.

---rsk

[1] A Faraday cage should suffice to prevent wireless communication.
--
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] Fwd: [ra...@psg.com: alexandria cable cutters?]

[Rich Kulawiec]

I don't think it's a huge leap to suggest that someone may be trying
to hobble telecommunications in/out of the Middle East, that they're
doing so for a reason, and that they'll try again.

---rsk

- Forwarded message from Randy Bush ra...@psg.com -

 From: Randy Bush ra...@psg.com
 Date: Thu, 28 Mar 2013 15:46:25 +0900
 To: North American Network Operators' Group na...@nanog.org
 Subject: alexandria cable cutters?
 
 nyt reports capture of scuba divers attempting to cut telecom egypt
 undersea fiber.
 
 
 http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html
 
 randy

- End forwarded message -
--
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] Installation free end-to-end encryption: Asking for public review / opinion / suggestion

[Rich Kulawiec]

On Thu, Mar 28, 2013 at 10:48:17AM +0100, Simon Rothe wrote:
 - fast and secure hosted by Amazon-Web-Service

I wouldn't.

(a) Nobody with any clue accepts SMTP traffic from Amazon's cloud,
as it's proven itself to be a massive source of spam and other forms of
SMTP-borne abuse.  Attempts to get Amazon personnel to deal with this
in a prompt, professional manner have failed.  Therefore it's now a
best practice to deny incoming port 25 connections that originate in:

50.16.0.0/14
67.202.0.0/18
72.44.32.0/19
75.101.128.0/17
174.129.0.0/16
79.125.0.0/18

and/or which have rDNS that resolves to hosts in the subdomains
compute-1.amazonaws.com or compute.amazonaws.com.

(b) The assertion that Amazon's cloud is secure has no proof.  Nor will
it have proof anytime soon -- which is not an Amazon-specific problem,
but a general problem with all cloud computing services.

---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] Schneier: Focus on training obscures the failures of security design

[Rich Kulawiec]

On Wed, Mar 27, 2013 at 07:45:45PM -0400, Carol Waters wrote:
 At the risk of igniting an inbox-exploding smackdown thread [...]

You say that like it's a bad thing. ;-)


I'll quote Marcus Ranum on the subject of educating users, from his essay:

The Six Dumbest Ideas in Computer Security
http://www.ranum.com/security/computer_security/editorials/dumb/

where educating users shows up as #5.  Ranum writes:

Penetrate and Patch can be applied to human beings, as well as
software, in the form of user education. On the surface of things,
the idea of Educating Users seems less than dumb: education
is always good. On the other hand, like Penetrate and Patch
if it was going to work, it would have worked by now. There
have been numerous interesting studies that indicate that a
significant percentage of users will trade their password for a
candy bar, and the Anna Kournikova worm showed us that nearly 1/2
of humanity will click on anything purporting to contain nude
pictures of semi-famous females. If Educating Users is the
strategy you plan to embark upon, you should expect to have to
patch your users every week. That's dumb.

It's worth reading the whole thing to understand the context.

( BTW: that document/rant/essay is one of the very best things
I've ever read about security.  Many, MANY people running networks
and systems would benefit greatly by the following algorithm:

1. Read it.
2. For the next week, try very hard not to do any of those things.
3. Go to step 1.

That may sound simplistic...and it is.  But I invite you to read Ranum's
rant, and then peruse any handy listing of intrusion/attack/dataloss
incidents, such as http://www.databreaches.net/ with his points in mind.
You will find, as I have, that it almost *invariably* the root cause of
the incident in question is that somebody made one of those six mistakes,
or one of the lesser ones he enumerates.  Sometimes they've made two or
three. )

---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] Privacy, data protection questions

[Rich Kulawiec]

On Tue, Mar 26, 2013 at 04:24:33PM -0700, Brian Conley wrote:
 I generally read most of your comments on this list as I find
 them insightful, however in this case, I was struck by your
 entirely hostile attitude.

You're misreading exasperation and frustration as anger, and you're
still focused on style rather than substance.  If you think I'm wrong
(and of course I might be) then make the case.  Show me how someone
can keep (let's say) a 1000-phone population in the field secure when
there's an adversary actively trying to make them otherwise.

---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] Privacy, data protection questions

[Rich Kulawiec]

On Mon, Mar 25, 2013 at 10:57:10AM -0700, Brian Conley wrote:
 Mostly I'm taking issue with your nonconstructive demeanor.

Clearly you have no idea how I write when I'm being nonconstructive. ;-)

Think equal proportions Kingsfield[1], Vader, Snape.  Season to taste with
HST and Mencken, serve at full boil.

 I've not seen you take the Guardian Project to task for trying to
 solve some of the same problems. I've not seen you take Tor project or
 Whisper Systems to task.

(a) There aren't enough hours in the day to provide extensive (security
or other) critiques of everything that comes across here.   And there
are other people whose expertise in certain areas dwarfs mine, so
until/unless I close the gap, I'll defer to them.  Also I think I should
occasionally STFU and listen.

So I respond on-list when I feel that I have something useful to say,
*usually* (but not always) when I think that has applicability beyond the
particular topic-of-the-moment.  Hence my comments in re Silent Circle,
which are far more about the inherent insecurity of closed source
software than about the specifics of Silent Circle itself -- most of
which I didn't pay any attention to because I think they're irrelevant.
And speaking of applicability beyond the topic-of-the-moment:

(b) If you read my message carefully you'll notice that I did in fact
explicitly point out that while I was using this particular project as
an example, it's by no means the only one facing the exact same issue.
Building a secure smartphone app is presently equivalent to trying
to put the roof on a house whose foundation is sinking into quicksand
and whose main floor is on fire.

So what constructive thing could I possibly say?  The entire smartphone
ecosystem is rotten to the core: the OS vendors care far more about
advertising than privacy and security [2].  Well, and they care a lot
about paying attorneys so that they can all sue each other. [3]  The app
markets are loaded with malware, spyware, adware, and crap.  And more
crap.  Also: still more crap.  Users will download and run any shiny thing
they see, doubly so if it purports to enhance their social experience --
much to the delight of the scammers and spammers running those operations.
Telcos are happy to turn user tracking/surveillance/etc. into profit
centers.  Governments want every scrap of data they can get from carriers
and there's now an entire subindustry for software that extracts data
from locked phones.

D'ya think if I asked them very nicely and politely they'd all stop?

*crickets*

There is NOTHING constructive to be done here.  It's not a fixable
situation at the moment or for the forseeable future.  The *only* thing
to do, as far as I can tell, is to stop pretending it's otherwise and
stop laboring under the delusion that smartphone apps have a chance in
hell of being secure in mass deployment scenarios.

(c) So to re-emphasize the more general point: no smartphone apps,
UNLESS you can produce a viable, workable, scalable, defensible plan
to keep the phones secure in the field.  Otherwise your app, whatever
it does, and however nifty it is, is probably going to be undercut from
the moment it's installed...or very soon thereafter, as soon as one or
two governments your users are annoying decide to deploy countermeasures.
(I think it's fair to say that, to a first approximation, the tempo
and scale of their response will be proportional to the adoption
rate and annoyance level.  Thus: the better your app and the more people
that use it, the sooner you should expect the backlash.)

And they don't *have* to crack your app if they 0wn the phones it runs on.

(I sure wouldn't.  Too much work.  Very tedious.  Better to just hijack the
phone, install a keystroke logger et.al., and compromise *all* the apps.)

(d) I don't think you [generic you] can come up with that plan (above)
and execute it.  I think you have no shot whatsoever.  But if you want
to take a crack at proving me wrong: be my guest.  I will be very surprised
but happy if you succeed.  I may even buy you beers.  Good beers.

(e) I *know* this is real unhappy news.  Sorry.  I didn't write the
cruddy smartphone software.  I didn't write the malware.  I didn't create
the situation.  I'm just pointing it out.  And yes, I know it would be
much nicer to just go on creating app after app and rolling them out
and pretending this problem doesn't exist, but ermmm...I think far more
unpleasant things than mere words on a screen will happen if lots of
people start betting their freedom and/or their lives on the security of
their smartphones/apps.

(f) And on that point (pretending), let me share with you one of the most
valuable pieces of guidance that I've ever read.  I have it printed out
and taped above where I'm working right now.  I think for many of the
projects and initiatives discussed here, it's terrific advice.  So even
if you think my analysis here isn't worth a load of fetid dingo's kidneys,
well, at least there's this:

Re: [liberationtech] Privacy, data protection questions

[Rich Kulawiec]

On Fri, Mar 22, 2013 at 04:29:38PM -0700, Brian Conley wrote:
 Nose to the grindstone Andrew. Use Rich's email to remind you this is hard,
 but its still worth doing.

I've read this multiple times and I still have no idea how your remarks
relate to what I wrote in re the (in)security of smartphones, the
resulting pervasive malware epidemic and the subsequent serious
architectural problems for application developers, including but not
limited to this one.  (serious architectural problems == you're
building on enemy territory, this probably won't end well)

Neither coffee nor scotch (both applied liberally) have yielded any
enlightenment, so I must now ask: Whiskey Tango Foxtrot, Over?

---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] Privacy, data protection questions

[Rich Kulawiec]

On Fri, Mar 22, 2013 at 09:58:17AM -0500, Andrew Haeg wrote:
 We're in the late prototype phase for Groundsourcehttp://groundsourcing.com,
 a mobile data collection and engagement platform -- designed for
 journalists, researchers, NGO's and others to use to gather first-hand
 knowledge. We've used the prototype to validate the need for the
 platform, and now privacy  data protection have moved front and center as
 we ramp up for a beta phase later this spring/summer.
 
 We've had some early discussions with the Tor Project about protecting
 journalists using the platform in countries with repressive regimes (down
 the road). We're also looking into using Wickr for encrypting
 communications. In the short term, we need advisors who can help guide our
 decisions around privacy and personal data collection  protection.

Ok.  Here's some advice.  You're not going to like it. ;-)  Sorry.
But better now than later, when lives are on the line.

I'd like to ask you to open a web browser and use your favorite
search engine to search for:

mobile malware epidemic
smartphone malware
android malware
windows phone malware

and similar.

Then I'd like you to explain how you propose to keep all those mobile
phones secure in the face of routine malware, let alone targeted and
custom malware crafted by hostile governments who would very much like
all those journalists and researchers and NGOs you mentioned to STFU
because they're saying and reporting and doing things those
governments find...disturbing.

Forget all the other security and privacy issues for a moment (some of
which I touched on in a previous list message [1]): how, EXACTLY, do you
propose to keep those phones from being infested just like a gazillion
other phones already are or will be real soon now?

Because once those endpoints are compromised, all the crafty routing and
anonymization and encryption layers you could possibly put in place aren't
going to matter very much.  And those endpoints WILL be compromised
(probably much sooner than you think) because they're going to be in the
hands of journalists and researchers and NGOs, *not* in the hands of
paranoid clueful paranoid diligent (did I mention paranoid?) geeks.

Oh, sure, someone sufficiently knowledgeable, cautious, etc.
can probably keep *one* phone secure.  Just like someone with those
qualities might be able to keep a single Windows system secure.  There are
people on this list who are capable of both of those things.  But dozens?
Hundreds?  Thousands?  Being carried around all over the place by
their owners?

There's not a chance in hell.  None.  This is not a solved problem in
computing.  Nor is there even a hint of a twitch of a notion of a
suggestion of a whisper that it will be solved anytime soon.

It's not even solved for people who've stacked the deck in their favor
(e.g., those who have the luxury of centralized control) let alone for
those who are allowing end users to connect their own.  And most of them
aren't painting big targets on their chests, they're just caught up in
the general crossfire...unlike *your* users, who are self-nominating to be
on the business end of some very serious attention from some very determined,
clueful and nasty people -- people who probably *already* have been
working on building or buying custom malware for phones because of course
that's what any prudent adversary with sufficient resources would be
doing just about now.

Yeah, okay, so I'm making the point at your expense, and I don't really
mean to do that, so I'll make it in the more general case: look, people,
unless you can produce a plan -- and more than that, a plan that's been
proven in the field to work -- for keeping, let's say, a population of, oh,
a thousand independent scattered phones free of malware, then you CAN'T
deploy your whizbang singing dancing smartphone app because it's going to
be promptly undermined.  Any government worthy of the term oppressive
is going to 0wn each and every phone of interest and is going to install
trackers, spyware, keystroke loggers, and whatever else occurs to them,
and you're not going to stop them.  At best, you might figure out that
this is happening after-the-fact and remediate some of them...until they
go back out in the field and get infested again.  Lather, rinse, repeat.

Not to put too fine a point on it (but I suppose I will anyway):

If someone else can run arbitrary code on your computer,
it's not YOUR computer any more. [2]

The phone may be in a journalist's hand or it may be in a researcher's
pocket, but it's not theirs.  *Not any more*.

Which means that your liberation app, the one that you designed and
developed and sweated over, the one that your user is trusting to
send and receive sensitive information, the one that's connecting
to a backend through umpteen layers of encryption and obfuscation
and misdirection and whatever...is now running on the 

Re: [liberationtech] list reply-all

[Rich Kulawiec]

On Wed, Mar 20, 2013 at 05:48:20AM -0400, Michael Allan wrote:
 Pardon me, but that's not true.  GNU Mailman is a decent list server
 and it ships with reply-to-sender.  You must go out of your way to
 munge the Reply-to header.  They recommend against it:
 http://www.gnu.org/software/mailman/mailman-admin/node11.html

Correct.  (That is, (a) correct that they recommend against it
and (b) correct that they SHOULD recommend against it.)  [1]

Now it's true that there are broken email clients out there that don't
handle this gracefully.  The solution is not to accomodate broken email
clients, but to insist that users of broken email clients either fix them,
get them fixed, or abandon them for others.

I will also suggest, that in the context of this particular list,
everyone should be using a mail client that permits and even better,
encourages, full editing of the To:, Cc: and Bcc: fields and that members
get in the habit of double-checking those fields before sending.
That's just good email practice, along with things like not top-posting,
not full-quoting, and not sending mail marked up with HTML.

---rsk

[1] Mailman is more than decent: it is, at the moment, the best
available software for running mailing lists, period.   Certainly all
closed-source software may be immediately dismissed from consideration,
which leaves us with things like ezmlm and majordomo, none of which
have Mailman's feature set, standards compliance, or ongoing track
record of bug fixes and improvements.  Oh, it's not perfect, and I sure
wish it wasn't written in Python: but it's the best-available, and its
authors have done an exemplary job of bug-fixing and enhancement.
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Announcing a privacy preserving authentication protocol

[Rich Kulawiec]

On Tue, Mar 12, 2013 at 06:31:56PM -0500, Kyle Maxwell wrote:
 A. This doesn't eliminate phishing because users will still enter
 their credentials at a site that doesn't actually match the one where
 the cert was previously signed. Otherwise, existing HTTPS controls
 would already protect them.

True, but phishing is not currently a solvable problem anyway; it falls
into a class of problems that can't be solved no matter how much clever
technology is developed because all of that technology presumes that
end user systems are secure...and they're not.  (Other problems in
that class: spam, email forgery, DDoS.)

A substantial percentage of end user systems are already compromised
(in full or part) and more of them are being compromised while you're
reading this.  So unless this proposal or one like comes with a plan
to remediate a few hundred million systems, it may be beautiful in theory,
but it won't work in practice.

In passing, let me note that banks and other financial institutions are
aiding and abetting phishers by doing extremely stupid things like
(a) sending email marked up with HTML (b) sending email with URLs (c) sending
email with with web bugs (d) outsourcing their email.  The irony is that
while those entities are busy *training* their customers to be phished,
they're constantly whining about how terribly awfully bad the situation is.

There is insufficient scotch to dull the pain of that much stupid.

---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] skype

[Rich Kulawiec]

On Wed, Mar 20, 2013 at 11:17:03PM -0400, Louis Su?rez-Potts wrote:
 One is tempted to suggest using other than Skype. Alternatives exist,
 and these are secure, at least according to their claims. As well,
 Skype's code is not transparent, in the way that other, open source,
 applications' are.

I'm more than tempted: I can't understand why anyone would even consider
using Skype.  It's closed-source, therefore it must be presumed insecure.
Nothing Microsoft says about it can be trusted.  There is reason to believe
that it's been successfully attacked by third parties.  etc.

I dunno 'bout y'all, but I think that's enough to blacklist it permanently.
Done.  Over.  Next?

---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] [ Spotfluxx what about it? ]

[Rich Kulawiec]

On Mon, Mar 18, 2013 at 12:59:48PM +0100, Giuseppe Calamita wrote:
 Hello, I wonder if application such as Spotflux: http://www.spotflux.com/ in
 security general terms and agency proof strength.

At first glance it appears to be a closed-source app which allegedly solves
certain security/privacy problems by shoving your traffic through their cloud.

If I'm right (and I really did only glance at it, so I may be wrong) then
that's two compelling reasons to immediately dismiss it with prejudice.

---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] list reply-all

[Rich Kulawiec]

On Tue, Mar 19, 2013 at 07:08:48PM -0400, Joseph Lorenzo Hall wrote:
 Has the possibility of reconfiguring libtech to not reply-all by default been 
 broached? Maybe I'm the only one that trips over it so often. best, Joe

This is something that has been debated numerous, and I do mean *numerous*,
times over the past few decades.  That said, I'd recommend (a) removing
the Reply-To header from the list's config and (b) using the mutt
email client, which is the best one I'm aware of and -- if you configure
it with edit_headers=yes -- makes it very very very easy to see what
you're doing *and* change it if it's not whta you want to be doing.
Mutt is lightweight, fast, portable, usable as-is, very customizable,
and presents a much smaller attack surface than many other mail clients.

I've used a *lot* of mail clients over the years; so far, mutt's the best.

---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] Here Come the Encryption Apps

[Rich Kulawiec]

On Sun, Mar 10, 2013 at 10:29:44AM +0700, Nathan of Guardian wrote:
 Glad to see such a great level of academic investigation and discourse
 coming out of this esteemed university.

I'll give him a pass on rigor, as this is an informal article and not
intended to be a journal paper.  (Besides, I write in the same style
most of the time.)  But when he asks:

What app should I use if I'm trying to overthrow my government?

I think he completely misses the point.  I think a much more fundamental
question is: 

Should I use ANY app?

My answer to that is no.  In fact: HELL NO.  Using a smartphone
strikes me as one of the most dangerous things you could possibly
do in that situation.

Yes...I know that's not a happy statement and is likely to be unpopular
here, but let me see if I can manage to back it up.

First, if you have a government that is so awful that the only alternative
left is overthrowing it, then they control the telco.  Therefore everyone
walking around with a smartphone is providing them with a 24x7 feed of
geolocation data, to the resolution available. (And that can be selectively
improved in locations of interest.)

Second, everyone using a smartphone is providing them data for traffic
analysis.  Oh, sure, it might be encrypted, but if X sends a 27313 byte
message and shortly thereafter Y and Z get a 27313 byte message...

Third, everyone using a smartphone and transmitting/receiving IP traffic
is also providing them information about their intentions, Tor and VPNs
and HTTPS notwithstanding. (Oh, look: every night, right after the
protests die down for the evening, X sends 300-400M of traffic out.
Gosh...I wonder what that is.)

Fourth, malware on phones is epidemic.  One might have a fighting
chance of stopping it if the phones are centrally managed and strictly
controlled (no downloading of apps, no updates, only a few web sites
accessible, etc.) but few have the knowledge, resources and discpline
to do that.  Plus centrally managed is not exactly the best idea
in this context.  And of course any government faced with this threat
will probably write and release more malware.  Any government that
*thinks* they might be faced with this threat in the future could
plan ahead and embed the malware in the phones somewhere in the supply
chain prior to retail sales.

(I would.  If I were the dictator of Elbonia, I'd be embedding
malware in *every* shiny gadget because of course their closed-source
nature makes it easy for me to do so.  This would constitute an
inexpensive insurance policy -- actually, now that I think about it,
I could probably just pass the costs along to purchasers and thus get
them to fund my malware.  I'd label it as a feature or as some sort
of network performance/diagnostic tool.  *cough* CarrierIQ *cough*)

Fifth, it's pretty easy to shut down the cellular network.  Yes, this
might have political and economic consequences.  So?  It's still not a
good idea to use a communications medium that your adversary can turn
off at will.  (Let me note that it's not even necessary to shut it
down entirely: local/temporary disruptions suffice and are easier to
explain away.  As we've seen.)

Sixth, and let me encapsulate it as a principle:

If you need a GUI to overthrow your government...
you're probably not going to overthrow your government.

That's harsh, condescending, snarky...but I think it's probably true.
Sorry: revolution is hard.  And if you're faced with an oppressive,
vicious, murderous government that's fighting for its existence,
I assure you that they will have people at *their* disposal who don't
need a GUI to do whatever horrible things they have in mind.

---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] recommendation for WP host

[Rich Kulawiec]

On Sun, Mar 03, 2013 at 09:10:30PM -0500, Rich Kulawiec wrote:
 On Sun, Mar 03, 2013 at 04:13:26PM -0500, Griffin Boyce wrote:
If the problem is limited to DDoS attacks, you might find that Cloudflare
  offers some relief.  
 
 I agree, but: this thread (dating from today) may be of interest:
 
   Cloudflare is down
   http://mailman.nanog.org/pipermail/nanog/2013-March/056564.html

Yes, I'm following up my own message.  The reason is that I think
a particular comment in that thread is worth quoting.  This comment
provides, in my opinion, sufficient reason to immediately rule out
Cloudflare from any further consideration whatsoever.

 From: Constantine A. Murenin muren...@gmail.com
 Date: Mon, 4 Mar 2013 12:33:42 -0800
 Subject: Re: Cloudflare is down
 
 The issue I have is not with their network.
 
 The issue is that they require ALL of their customers to hand over DNS
 control, and completely disregard any kind of situation as what has
 just happened.
 
 * They don't provide any IP-addresses which you can set your A or 
 records to.
 
 * They don't provide any hostnames which you can set a CNAME to.
 (Supposedly, they do offer CNAME support to paid customers, but if you
 look at their help page for CNAME support, it's clearly evident that
 it's highly discouraged and effectively an unsupported option.)
 
 * They don't let you AXFR and mirror the zones, either.
 
 So, the issue here, is that a second point of failure is suddenly
 introduced to your own harmonised network, and introduced in a way as
 to suggest that it's not a big deal, and will make everything better
 anyways.

 [snip]
--
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] Cryptography super-group creates unbreakable encryption

[Rich Kulawiec]

On Fri, Feb 15, 2013 at 01:35:53PM -0800, Adam Fisk wrote:
 At the risk of getting swept up in this by consciously saying something
 unpopular, I want to put my shoulder against the wheel of the open source
 process produces more secure software machine. [snip]

I've been thinking about your (excellent) comments for several weeks now.
And I'm going to argue that open source doesn't necessarily produce more
secure software, but it's a prerequisite for any credible attempt.  And
that in this particular case, there's just no substitute for it.

But before I get started, let me pointed out that I'm very much *not*
arguing that the contrapositive is true, that open source == chewy
goodness automatically.  We've all seen open source code that was junk.
Lots of it.  We've all probably written some, too; I know I have.

So here goes:

Consider this hypothetical: you have the imaginary disease Bieberitis,
which progressively imposes the characteristics of Justin Bieber on you,
then kills you.  So not only do you die, you die badly.  Clearly: it's
an awful fate.

There are only two drugs available to treat this disease.

Drug A has a history that looks something like this: the basic
biochemistry has been known for 18 years.  It's been studied at multiple
universities and research institutions.  There are numerous published
papers on it.  Early animal trials were conducted 15 years ago, and those
results were published as well, leading to another round of animal trials
with a slightly different formulation and more publication.  Following
review by independent agencies 12 years ago, limited human trials were
held, with still more publication.  A lengthy review and debate ensued,
the drug was discussed and debated at numerous conferences and meetings,
other (new) researchers weighed in with their papers, and a second
round of human trials took place 9 years ago.  Following that, review
by multiple government agencies commenced.  Additional work continued
in parallel on refinement of dosage and delivery.  Eventually, following
another blizzard of paperwork and publication, the drug was approved --
and is now available to you.  Studies are still ongoing, of course,
and it's expected that half a dozen more papers will be published in
referreed journals this year.

So: drug A has a long history.  Lots of clueful eyeballs have investigated
it personally, and many more clueful eyeballs have read the published body
of work, thought about it, argued about it, reviewed it, critiqued it,
supported it, rebutted it, and otherwise been involved in the process.
Moreover: nearly all those clueful eyeballs are INDEPENDENT clueful
eyeballs, who have, in many cases, substantial motivation to disprove
claims made -- since one of the best ways to make one's academic
reputation is to perform ingenious, ground-breaking work which
demonstrates that something everyone agrees on is completely wrong.

Now, about drug B: drug B has no publications associated with it.
It's never been independently reviewed.  It has none of the lengthy
history of A.  What's it got?  It's got a shiny color brochure written by
the marketing department that tells you how great it is, because it was
developed by some of the top people ever.  Really.  Top people.  As in:

Major Eaton: We have top men working on it now.
Indiana Jones: Who?
Major Eaton: Top...men.

That's it.  That's all you get.  Promises.  Assurances.  Hand-waving.
Top...men.

Now: which drug are you going to take?

Of course the obvious answer is A, since B is more commonly known as
snake oil.  It's garbage.  No thinking, responsible person would
ever choose B, because -- absent the history and the research and
the publication and everything else -- it might be the instant cure
for Bieberitis, or it might be sugar pills, or it might be poison.
There's no way to know.

All serious fields of intellectual endeavor use the same model as I
outlined in the development of drug A, which I'll lump under the rubric
peer review.  Architecture and law, physics and economics, medicine and
civil engineering, everybody uses this.  And they use it because, despite
its flaws, it works really, really well.  It's an essential component of
the scientific method.  It's how we make forward progress, however slowly.

Fields of study that don't use this are crap.  Astrology, creationism,
alchemy, homeopathy, phrenology, and yes, closed-source software: all crap.

There is no way we should accept what any closed-source vendor claims
about their code.  There is no reason to, no matter who they are, no
matter how much we trust them, no matter how pure their motives are.
Heck, we often can't even trust OUR OWN CODE to do what we think we want
it to do, even when we're staring right at it -- so why in the world
should we make the fantastic leap of faith to trust someone else's when
we can't even see it?

Closed-source software is the equivalent of drug B.  We're expected
to take the authors' word that it 

[liberationtech] [SPAM:####] Re: [SPAM:####] CfP: Society, Informatics and Cybernetics (March 19)

[Rich Kulawiec]

On Mon, Mar 04, 2013 at 09:42:27AM -0800, Yosem Companys wrote:
 7th International Multi-Conference on Society, Cybernetics and Informatics: 
 IMSCI 2013 (www.2013iiisconferences.org/imsci) to be held in Orlando, 
 Florida, USA, on July 9-12, 2013.

It's a scam.  This is one in a long series of fake conferences that have
been spamvertized for years.  (I have something on the order of 8000
samples of email and Usenet spam from the promoters of these.)

This particular domain is registered to:

Int'l Inst. of Informatics  Systemics
Torre Prof. La California, Suite PH-4
Av. Fco. de Miranda, La California Norte
Caracas 1071 VE
58.21223270

which organization does not seem to exist anywhere except in its own
materials.  Morever, the alternate address for that organization is:

13750 West Colonial Dr
Suite 350 - 408
Winter Garden, Florida 34787

which also happens to be the address for:

International Institute of Informatics and Cybernetics

which also does not seem to exist anywhere else.  Fascinating that two
international organizations share the same address, isn't it?

Now that phone number above -- the one in Caracas -- shows up on at
least 13 domains for other face organizations/conferences:

demset2011.org
iceme2013.org
icsit2013.org
icta2012.org
iiis-info.org
iiis.org
iiis2013.org
imsci2011.org
imsci2012.org
is11conferences.org
sistconfer.org
techconfer.org
wmsci2011.org

And they've been at it for a while, see for example:

http://pdos.csail.mit.edu/scigen/
and
http://copy-shake-paste.blogspot.com/2008/12/fake-conferences.html

And unsurprisingly that last link mentions Professor Nagib Callaos;
and what do we find in the registration for the domain that's our topic here?

Email:ncall...@usb.ve

Right.

The methodology for these fake conferences is pretty consistent: spam
mailing lists and newsgroups, hit moderators/list-owners -- who are
well-meaning of course and just trying to help out -- then accept ANY
paper, but make sure to charge hefty fees for doing so...which is of
course where the profits come from.

---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