-----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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev