[OSM-dev] Client trustworthyness

[Iván Sánchez Ortega]

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 :-)


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090617/1dadb0df/attachment.pgp>