[OSM-dev] Client trustworthyness

SteveC steve at asklater.com
Mon Jun 29 11:36:44 BST 2009


On 17 Jun 2009, at 21:44, Iván Sánchez Ortega wrote:

> El Miércoles, 17 de Junio de 2009, SteveC escribió:
>> So it looks like you grab a node and it has id^H^Hversion n and you  
>> upload
>> after changing it n+1. Or something.
>
> AFAIK, the API doesn't work like that. When uploading data, you have  
> to
> provide the version number you downloaded, *not* the expected version.
>
>> If the database has some id^H^Hversion >n+1 it shouts 'EPIC FAIL'  
>> and the
>> client says uh-oh you're out of date.
>
> It's the API the one that checks that.
>
>> But, the client could just try uploading n+2 or n+3... n+m until it
>> succeeds. Is that correct?
>
> If I were to code a malicious OSM client, I'd download the new  
> version numbers
> fresh whenever I was to upload any data.
>
>> Curious, did anyone look at throwing tokens around instead of  
>> versions
>> or some other way where you don't have to trust the client? I assume
>> this would be computationally expensive.
>
> So what? I could always download the latest version number of every  
> element
> just prior to uploading it. Even if you want to use the weirdest  
> crypto hash
> scheme ever invented, I see no way you could prevent malicious  
> clients from
> re-downloading versions/hashes/tokens or whatever.
>
>
> I think you're proposing a bad solution to a problem that doesn't  
> exist :-)

just curious :-)

>
>
> Cheers,
> -- 
> ----------------------------------
> Iván Sánchez Ortega <ivan at sanchezortega.es>
>
> http://ivan.sanchezortega.es
> MSN:i_eat_s_p_a_m_for_breakfast at hotmail.com
> Jabber:ivansanchez at jabber.org ; ivansanchez at kdetalk.net
> IRC: ivansanchez @ OFTC & freenode

Best

Steve





More information about the dev mailing list