gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] Re: ACM HT03: Short Paper Results


From: Benja Fallenstein
Subject: [Gzz] Re: ACM HT03: Short Paper Results
Date: Fri, 13 Jun 2003 22:41:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2


Dear Les,

thank you for your email! It looks as if there is something missing from the end, though? The last review stops in mid-word.

Thank you, and I'm looking forward to meet you at the conference!
- Benja

Les Carr wrote:
I am pleased to inform you that your submission
(paper 192, Storm: Using P2P to make the desktop part of the Web) has been accepted as a short paper for the ACM Hypertext 2003 conference.
The quality has remained high with 25% of submissions being accepted,
and despite the short timescale, most submissions were reviewed by
four referees.

The timescale for the final version of your paper is very tight - we
need to receive the final, camera-ready copy from you by Friday 20th June.
When preparing the final version, you should take into account the referees'
comments (below) and the formatting instructions on
http://www.ht03.org/submissions.html

Thank you for your interest in HT03. We are anticipating a lively conference
and look forward to your participation.
---
Les Carr & Lynda Hardman
HT03 PC CoChairs

===================== REVIEWS ====================

Score: 8
         An interesting look at a significant work in progress

Score: 7
         Nice paper, look forward to seeing it in print. But before
         it does, please don`t use the name "Storm" so many times
         -sounds as if you are trying to sell us a product!  Also,
         you have completely misunderstood what Schneier says about
         cryptographic hashes in your reference to [10] - it is
         *NOT* "practically impossible" that two documents will
         _have_ the same hash (in fact, it is absolutely certainly
         going to  happen), but rather, it is practically impossible
         to _find_ any two documents that have the same hash. This
         is the "collision resistance" property and it means that
         is is hard to discover other documents with the same hash,
         but it is quite easy for such to exist, purely on the
         pigeon-hole principle (whether alternative documents with
         the same hash are meaningful is another matter).

Score: 5
         The motivation of `including the desktop` is valid, although
         the UI changes that your suggested approach would require
         are too numerous for such a change to be usable - a fact
         to which you allude in Section 3.   It is also unclear
         how using a straightforward hashing function, such as
         SHA-1 or MD5, would suffice to cater for all resources in
         the application space without collisions (I would argue
         that it is insufficient).   Further, the choice of URN
         naming is not new (e.g. eDonkey`s URN format for file
         sharing), and there is no discussion of the impact of
         moving from a structured naming scheme (of which users
         may rightly or wrongly make assumptions regarding content)
         to an opaque one.  Discussion of Storm`s security model
         would help the reader assess the utility of having `all
         documents stored on their local hard disk` included
         automagically by the Storm system, especially in light of
         recent discoveries of other p2p filesharing tools and
         their somewhat questionable behaviour of file publication.
         Th








reply via email to

[Prev in Thread] Current Thread [Next in Thread]