Re: [tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch

[Isis <isis@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On Sun 15 Jul 2012 at 10:13, thus spake Tom Ritter:
> > Contra:
> > * No support for deltas (we can use rsych protocol over HTTP if we
> > really need this).
> 
> It's a little hackish, but I believe there is a 'standard' way to do
> this in HTTP also.  A client issues a GET (or PUT) request to a
> resource, and recieves an Etag that identifies this version of the
> object.  The client then issues a PATCH Request to update the object,
> sending the Etag, and either structured XMLor JSON with the fields to
> replace, or binary data with a Range header indicating where in the
> object to replace.

While this is quite a clever use for Etags, I have to point out that there
would be no identity verification[0] in this scheme, in addition to Etags
being subject to birthday attack enumeration (even if we use a secure
hash). Therefore, Mallory, knowing the location of the OONIB server, can
simply compute many random Etags and issue a PATCH of a blank string to each
one, erasing all the collected data.
 
> If the Etag the client sent is the object stored on the server, the
> PATCH succeeds and overwrites the data. If the Etag does not match,
> the client is out of date and must issue a GET, resolve differences,
> and then the PATCH.

Mallory can also /GET...

Perhaps I am biased towards opposition to Etags merely because of their
nastier uses for tracking. I kind of wish they would be removed from the
protocol, and I don't want to create any legitimate use for them that might
deter their removal.

<(A)3
isis agora lovecruft

[0] Identity verification in the "yes-this-is-the-same-client-as-before"
sense, not the "this-person-is-named-holger-and-they-live-in-osterreich"
sense.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQBcZSAAoJEKOttnos24s11WkQAIQj8lmm10bm4eiGsrcf0syb
v/j/+N9vYut4+EmDzgsTvVdpYA53IkVTVfZWs9kKuiUUTNJnjHqbTlF7UfUvzcxJ
EfWft+0N0sw8crqAHrENHPoNICLhU1cxxozYYAkGEkx8IOP8/W/WdOqTc49Ybzqz
yjUQuUUzLBg0QXY7S+3dPYEjjl+4RVNMzr9awCq97m/H102BXkkR5OC1cwL/gCsl
4FcgHMKP6SkZhIX+zs8MR9AP8ADp9x5uPTd2+nF+u6v0ri0NDdkrHqiQIRmpj42R
lvE1I0UZuFjhMZT3HEi2c0XP2KtfcncyBM/CISu4H26AO6KyOA3b6jmUwzkuGHjF
HubZKARU82bg+2bRzAiNrq/uEX1ni3NWLm/c/kziEF1G1RsA1Ghy9G5EnHPQ/PQF
npHBscHgnpYjiwKJmq4jdSByA8CrcGRdPrcJQQZN8WVa0wfvHn2jsi7a6J3cBGu8
uJ3dpVJrX9UMicV4o/q1iu5cS+piKHkOE5SeTKAySoNyIVMLJQU6zZhoQxLXhQxE
c7ZgYAMp4eZeROU8qeQ+A+7mDER83PjzYHr27JhFJ8Zg5+7v6IMcHc7qtbnL9VE2
fgEqgjkzkQnmT3k75daVql2zche9zfX3pEniUxYDCzZCv2T4zb/ysBTMuv0ktYxU
1lPJTfRx3Lyx42Zo9kxf
=CwCQ
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev