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 > > _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
