[OSM-talk] Why doesn't OSM implement a simple measure to protect it's users and passwords?
kakrueger at gmail.com
Tue Dec 22 23:15:28 GMT 2009
On 01/-10/-28163 08:59 PM, John Smith wrote:
> So adding comments to trac and sending emails on this topic is doing nothing?
I think pretty much everything has already been said on this topic, but
writing emails and trac tickets is so much easier than writing
And John, you are a java programmer, right? So you would presumably
actually have the technical skills to write patches, which admittedly
not everyone has.
> If I had access to servers I could have had it implemented server side
> 5 minutes ago, there is no point doing anything in editors until the
> server supports it, since based on Tom's comment we don't even know
> what to expect in terms of crypto to even know where to start.
> So what exactly is it in your opinion that I could be doing that I'm
> not already?
As Frederik already said, I think the most useful thing would be to get
JOSM and merkartor to support OAuth. That would significantly reduce the
risk of exposing the username and password in cleartext, as it would
then limited it to the login page and also send it much less frequently,
as OAuth tokens are valid indefinitely. It would also allow to implement
alternative authentication methods such as e.g. OpenID, which would then
no longer require to reveal any password to OSM at all anymore. So
OpenID would be another thing you could work on. I had already started
with a proof of concept implementation (
http://trac.openstreetmap.org/ticket/2500 ) but never got around to
incorporating the suggestions or integrating it correctly with the other
authentication mechanisms. So there are many things you could
productively do to help improve protection of user name and password if
you have the necessary skills. Suggesting to move the entire
infrastructure into a different country without concrete suggestions is
not one of them though!
And to all those who are worried about their employer sniffing their OSM
activity, I would seriously suggest not (miss)using your employers IT
infrastructure for your hobby or use a proper anonymising proxy instead.
Adding SSL encryption just adds a false sens of privacy on data that is
published openly immediately after wards through the API and planet
dumps anyway. A more useful exercise would imho be to educate users that
e.g. GPX traces marked private aren't actually private, but can be
downloaded as a dot cloud through the api, just not as a full GPX file.
More information about the talk