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

[Kai Krueger]

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 
patches... ;-)

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.

Kai


>
>