Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Mega

Rich Kulawiec rsk at gsp.org
Sun Jan 27 11:36:44 PST 2013


On Sun, Jan 27, 2013 at 02:03:37AM -0800, Brad Beckett wrote:
> Mega needs an optional Chrome and Firefox plugin -- what Crypto.cat did,
> but it could be optional.
> 
> They also need a desktop client like Dropbox so I can encrypt my files
> automatically prior to uploading.

No.  What they, and everyone else doing similar things, needs to do
(instead of trying to reinvent or replace software) is to work with the
software we already have, e.g., scp, rsync, gpg, etc.  We see evidence
all day every day that writing correctly-functioning software is hard;
mostly we see it in the form of bugs.  Investing yet more effort in
yet another client is a waste: just make it work with software that
already exists, is reasonably mature, has been peer-reviewed, and so on.

Moreover, make it work with the simplest software available that will
accomplish the task, as that minimizes not only the requirements but
the computational footprint and quite likely, the security/privacy risks.
Should I *really* need to fire up a web browser, with all the massive
complexity and risk that involves, just to upload or download a file?

This isn't really an issue specific to the problem domain here: one of
the things that has unfortunately happened, particularly in the last 10-15
years, is that people have stopped reading section 1 of the 'nix manual,
or perhaps to be more precise, there's been an influx of people who've
never started.  As a consequence of that, there's been a steady parade
of code on Freshmeat and Sourceforge and elsewhere that never needed to
be written: its functionality *already existed* either in toto, or to
such a high degree that a minor change to existing software or a shell
script wrapped around it would have solved the problem with a fraction
of the time, effort, and complexity.

Thus we have lots more programs, which is great; but lots more buggy
and insecure programs, which is not so great.

I'm not advocating that people should stop writing code.  As someone
who supported "open source" many years before that term entered the
lexicon, I understand that having a diverse ecosystem of collaborating
and competing projects is a good thing.  But I am saying that "writing
demonstrably secure code" is not yet a solved problem in computing
and we tend to fail at it far more than we succeed.  So while we work
on figuring out how to do better, one way to minimize the extent of our
failures is to minimize the extent of our code: e.g., we don't *need*
82 different clients to upload/download encrypted files, we need one
that works and that has been peer-reviewed, attacked, defended, dissected,
and otherwise stared at by enough clueful eyeballs that we think it
has a shot of maybe being approximately right.  On a good day.

---rsk



More information about the liberationtech mailing list