<br><br>
<div class="gmail_quote">On Sun, Dec 27, 2009 at 4:59 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>Aun Johnsen wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">   John Smith wrote:<br>    > Lets assume for a second that they are smart enough to filter their<br>    > points so they aren't near their home location, we can also assume<br>    > they may not have vectorised the data, however there is a lot of<br>
    > non-home/non-work information still not being protected by a simple<br>    > SSL connection OSM could be providing.<br><br>   Let me repeat: If your tracks contain information that needs protection,<br></div>   then *please* don't upload them to OSM.  So your answer to this, if you are concerned about your security, don't contribute?<br>
</blockquote><br>Well, "concerned" is perhaps the wrong word here.<br><br>If you have GPS tracks which contain information that is so sensitive that you fear someone could be spying on your connection, retrieve the information and use it to cause damage to you, then OpenStreetMap is clearly not equipped to handle information of such importance.<br>
<br>SSL encryption might keep your employer or your internet provider or the UK government from spying on you, but the data will eventually land on the OSM servers where any number of project members deemed trustworthy in a non-ISO-certified process will have access to it, and will even be handed out through an API which may be buggy, and where anyone can commit changes into a publicly writable SVN. (Not everything commited to SVN will land in production but it is absolutely not impossible that something will escape the attention of an admin.)<br>
<br>My concern is that if we allow people to claim that their data is so sensitive that it needs SSL to upload, then the next thing they will demand is that there be a complex vetting procedure for admins - "why am I going through the hassle of uploading my data in an encrypted fashion when you don't even make your admins sign a legally binding statement about what they can and cannot do with the data", for example. The logical next step for John Smith would be to inquire about the security precautions at the site where our computers are. What locks are there, how many people have the keys, and surely we have CCTV? And so on.<br>
<br>Security is not something where you can twist a few screws somewhere and hope that it will magically improve. It needs a thorough analysis - as I said: What do we want to protect, and whom against, and then let's see where the weakest points are.<br>
<br>And then determine the price for the level of security you want, and think about whether you are willing to pay that price. Because security *never* comes for free - it will cost you more computing power, it will cost the admins more nerves, create paperwork, formalities, slow down innovation, and so on. 
<div class="im"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Isn't that the same as continuing the economic gap between industrial and developing countries? <br></blockquote>
<br></div>No, my argument has nothing whatsoever to do with the global economy; it would be just as valid if OSM were a UK only (or London only, for that matter) project. 
<div>
<div></div>
<div class="h5"><br><br>Bye<br>Frederik<br><br>-- <br>Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br></div></div></blockquote>
</div>
<div><br> </div>
<div>I very well understood you there, and mark that some of my points have been put to the extreme. Some of the socalled security concernes about OSM are covered by license disclaimers, some is covered by the fact that the source code are available so any security mechanisms can be examined by anybody to patch holes, and some are covered by OSMF's administration of the hardware. A vetting of the admins are senseless as what can be done with the data is covered by OSM's chose of License and the Disclaimer of the project.</div>

<div>My point in all of this is not that we must implement security measures now, but that it must be put on the TODO list with an appropriate priority. If anybody are able to supply a patch for lets say SSL login to the API, than please let him supply the patch, and the admins then should take a look at it to see if it can be implemented right away or if it needs more patching to be obtained. As the source code of OSM should be awailable on the svn, than people with the appropriate programing and security knowledge should be able to supply the right patch.</div>

<div>John Smith, you can put your money where your mouth is and write a patch, since you brought this up?</div>