[OSM-talk] Fwd: Why doesn't OSM implement a simple measure to protect it's users and passwords?

[John Smith]

---------- Forwarded message ----------
From: John Smith <deltafoxtrot256 at gmail.com>
Date: 2009/12/23
Subject: Re: [OSM-talk] Why doesn't OSM implement a simple measure to
protect it's users and passwords?
To: Frederik Ramm <frederik at remote.org>


2009/12/23 Frederik Ramm <frederik at remote.org>:
> Why should we?

I gave several good reasons, but you chose to rebuff my question with
a silly question.

> Firstly, I don't see what harm the UK government can do with your password.

It's not just passwords, that's just the most obvious case, why would
I even consider uploading private traces in future if the UK govt goes
ahead and you fail to protect my privacy properly, OSM is worst off
because people will upload less data that can be useful for
vectorising.

> And all the data you're uploading will be theirs for the taking anyway.

At least if they request it from OSM they're be required to get a
warrent and potentially face legal challenges, when they pull data
over the wire en mass what legal recourse is there?

> As I said above, the "everything else" is unencrypted anyway. And the
> password - if you use a password for OSM that you use anywhere else, too,
> then you have a security problem that SSL is not going to solve.

And as I said above, the password is just the most obvious example of
lax security.

> It is difficult because with the current authentication scheme (HTTP Basic
> Auth), the authentication token (from which username and password can be
> derived) is transmitted with every request, This means we cannot simply
> "make the login encrypted" - we would have to make ALL uploading
> communications encrypted, and that would have the potential to use quite a
> lot of processing power. Which we'd rather use for other things, i.e. faster
> response times ;-)

Then ask for donations for hardware or to buy hardware that can handle
the requests, SSL really isn't a resource issue like it used to be,
hardware has continued to improve greatly and demands from encryption
is now a minor concern.