[tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch
isis at torproject.org
Tue Jul 17 20:08:50 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
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 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.
isis agora lovecruft
 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"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the tor-dev