Re: Family specifications (was: Re: perfect-privacy.com, Family specifications, etc)

[Scott Bennett <bennett@xxxxxxxxxx>]

Hi Paul,
     On Thu, 20 May 2010 15:12:38 -0400 Paul Syverson
<syverson@xxxxxxxxxxxxxxxx> wrote:
>On Thu, May 20, 2010 at 01:44:36PM -0500, Scott Bennett wrote:
>>      Oh.  My.  Goodness.  Gracious!  I go to sleep for a few hours, and the
>> discussion descends into total confusion because a number of participants,
>> including some tor developers, did not bother to read the proposal by Bruce
>> from perfect-privacy.com.  He did *not* propose, for example, any equivalent
>> to #include statements.  He did *not* propose, for example, any method of
>> allowing a node to specify other members of a Family.
>
>Your interpretation of what Bruce said makes sense. But it is not
>how I parsed, "BelongToFamily xyz" in his message. I read it the same
>way it seems that Roger did, as giving a list: node x, node y, and
>node z.  And then we're off and running. I think what Bruce/you

     You parsed "xyz" as meaning "x,y,x" or perhaps "x y z"?  How bizarre.
Even the current MyFamily statement doesn't do that.

>suggest is better than what I proposed to avoid the problems Roger and
>Andrew noted. As I said before, it's not how MyFamily now works. And I

     No, indeed it's not.  Bruce was proposing an alternative method, one
that looks far more sensible than the current method.

>believe Andrew/Roger/me/others were addressing trying to use the
>existing functionality in a different way, which was another
>disconnect. Anyway, this is certainly an idea worth considering.
>
>Now, should you ever say you are in multiple families at once?

     That's an interesting question, and I'm not sure of the answer.
However, it's worth noting that it would not open any useful attack
because each time a node adds itself to a Family reduces by some amount
its probability of being selected for a route.

>And should there be a lattice structure for families, hmmm? ;>)
>
     Not sure what that would accomplish.  Seems to me that a client
would maintain a list of Family names that it has encountered.  Each
time it encounters a descriptor with a Family name not already present
in its list, it would add a new entry for that Family to the list.
Each node claiming membership in a Family would have an membership
entry linked off of the appropriate entry in the Family list.  When
a new descriptor for a node is encountered, it would be checked for
Family designation(s) against the appropriate membership list(s) to see
whether the membership list(s) should be updated.  If a node vanishes
from the directory, its memberships should be removed.  If an entry in
the Family list ends up with no membership entries linked from it, then
that Family entry should be removed from the Family list.
     It's just mundane list maintenance stuff.  Shouldn't be a big deal.
Each node's descriptor entry in tor's internal representation of the
directory would link directly to the appropriate Family list entry.  If
multiple Family designations are permitted for a node, then the internal
directory entry would instead anchor a short list of pointers to the
Family list entries.  I suppose a bit could be reserved somewhere nearby
that would say whether the field in the internal directory entry were
a direct pointer or a list anchor in order to accommodate the most likely
case, namely, that a node would be a member of, at most, a single Family.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/