User talk:Mike-ZeleaCom/Streetwiki

See also

2010-1-13	Streetwiki prototype. http://metagovernment.org/pipermail/start_metagovernment.org/2010-January/subject.html#2491
2010-1-15	Free Range Voting and Network of Trust projects. http://groups.google.com/group/votorola/t/7ca9e69929838f04

Proxy blind

See also

• Upgrade Democracy Report. Contact Summit. 2011.11.23-25.

Original discussion

With Thomas's permission, here are our private discussions on the design of proxy blinds. ~Mike-ZeleaCom^talk 06:08, 5 November 2010 (UTC)

From User:Mike-ZeleaCom Sat, 2 Jan 2010 15:48:21 -0500

I remember you proposing something similar for private registration
and voting a few months ago.  Somehow the technical side of it didn't
gel at that time.  But both times, it was your chase, and I was just
following along.  So please take credit, when you announce it.  Here's
my own take on the idea:

Normally the trust of other users (neighbours) ties email address (and
other personal identifiers) to street address:

   (1)
                  trust
  neighbouring   -------->  public user (email,
  users           doubt                  street address)

The new idea is to have the registrar protect the voter's identity.

    (2)

  neighbourhood  -------->  private user (email,
  registrar       vouch                   surrogate street address)

The private user is identical to a public user, except:

  a) Vouched by registrar.  The registrar knows the real street
     address of the user, but does not disclose it.

  b) Cannot receive trust from other users.  Trust level is always
     zero, so does not participate in trust network at all.  Cannot
     cast doubt on other users, either.

  c) Has a surrogate (fake) street address.  This is a real address in
     the neighbourhood at which all of the private users "live".  If
     any server needs to parse an address for the user (for some
     reason) it can parse this one.

The registrar is responsible for policing the user's street address
for sock puppets.  She not only has to verify that the user really
lives at that address, but also that nobody places a sock puppet there
in the "empty" space.  This is easy if the user lives alone.  Then she
just checks periodically that the address is empty in the streetwiki -
nobody else registering there.  But if anybody else *does* register a
sock puppet there, she has to cast doubt on it.  This is problematic,
because:

  (i) The registrar's doubt signal will reveal that the address
      belongs to one of her private users.  We'll learn something
      about the private users, statistically speaking.

If the registrant does not live alone, then it's difficult for the
registrar to police the address, at all.  She may need help.  She may
have to place a surrogate (fake) user at the private user's address:

    (2a)

  neighbouring users  -------->  surrogate user (surrogate email,
                       doubt                     street address)

Now the neighbours can police for sock puppets, casting doubt signals
if anything looks suspicious.  But this is also problematic:

 (ii) The registrar's placement of the surrogate again reveals that
      the address belongs to one of the private users.  Same
      consequences as (i).

I wish we could do (2a) for all private users, when they register.
Then anyone could verify that the number of private users (2) matched
the number of surrogates (2a).  This would increase people's
confidence that the registrars weren't corrupt.  (I recall you
suggesting something like this, a couple months ago.)  Also, anyone
could knock on the door of a surrogate user and ask "Are you really
one of the private users, vouched for by the registrar?"

But I think it'll be OK for a prototype.

From User:Mike-ZeleaCom Sat, 2 Jan 2010 16:47:23 -0500

Or how about this?

   * User registers under R-email, which gets trust from neighbours.
     Neighbours say that R-email is not a sock puppet.
 
   * User votes under V-email, which is vouched by registrar.
 
   * Only registrar knows that R and V-email belong to same person.
 
   * User promises never to vote using R-email.  Registrar checks now
     and again to confirm that R-email never votes.
 

With a little computer steam, a verifier can count how many users in
the [register] have never voted (nR).  The verifier also knows
the length of the registrar's vouch list of private users (nV).  He
verifies:

  nV <= nR

If not, then he knows the registrar is either failing to detect
R-email voters (not doing her job), or is creating her own sock
puppets in the vouch list.

From User:Mike-ZeleaCom Sat, 2 Jan 2010 17:41:18 -0500

Problem: For any V-email, bad guy can find R-email and address by:

  * Looking up date when V-email was added to registrar's vouch list

  * Searching history of streetwiki for non-voting R-emails that were
    added around that time

I was thinking: let the vouching registrar be global, and let her wait
a week or so before posting each new vouch list.  Then the bad guy
only knows the date of the new V-email within a week.  There'll be too
many new R-emails aroung that time (many thousands the world over) for
him to correlate.  But then user can *never* vote locally V-email, or
give any hint of what city she lives in - else the bad guy will have a
much shorter list of R-emails to look at.  And that's unrealistic.  So
forget this.

Better: The registrar is local, and she waits for at least 100 new
V-emails before publishing a new vouch list.  So there's a delay
(maybe months) before the user can vote.  Slight problem: it will
become easier for the bad guy to correlate, as each year goes by.
R-emails will vanish from the streetwiki as people move (or pass
away).  Eventually one R-email will be left alone, and the bad guy
will know its V-email.  (Maybe by then, the user will be too old to
care.)

Or fall back to the original idea (no R-email at all), and leave it
for bigger brains to solve. :^)

From User:ThomasvonderElbe GmxDe Sun, 03 Jan 2010 10:36:26 +0100

> I remember you proposing something similar for private registration
> and voting a few months ago.  Somehow the technical side of it didn't
> gel at that time.  But both times, it was your chase, and I was just
> following along.  

Its true, it was similiar, but it was your idea of letting a trusted 
human (registrar) do the job.

> The registrar is responsible for policing the user's street address
> for sock puppets.  She not only has to verify that the user really
> lives at that address, but also that nobody places a sock puppet there
> in the "empty" space.  This is easy if the user lives alone.  Then she
> just checks periodically that the address is empty in the streetwiki -
> nobody else registering there.  But if anybody else *does* register a
> sock puppet there, she has to cast doubt on it.  

The deal between the private person and the registrar could be, that 
potential other people living in that flat have to come to the registrar 
too in order to register (seems to be a reasonable price to pay for 
anonymity). Once there they can decide, if they want to be private too 
or not.

> This is problematic,
> because:
>
>   (i) The registrar's doubt signal will reveal that the address
>       belongs to one of her private users.  We'll learn something
>       about the private users, statistically speaking.
>
> If the registrant does not live alone, then it's difficult for the
> registrar to police the address, at all.  She may need help.  She may
> have to place a surrogate (fake) user at the private user's address:
>
>     (2a)
>
>   neighbouring users  -------->  surrogate user (surrogate email,
>                        doubt                     street address)
>                
> Now the neighbours can police for sock puppets, casting doubt signals
> if anything looks suspicious.  But this is also problematic:
>
>  (ii) The registrar's placement of the surrogate again reveals that
>       the address belongs to one of the private users.  Same
>       consequences as (i).
>
> I wish we could do (2a) for all private users, when they register.
> Then anyone could verify that the number of private users (2) matched
> the number of surrogates (2a).  This would increase people's
> confidence that the registrars weren't corrupt.  (I recall you
> suggesting something like this, a couple months ago.)  Also, anyone
> could knock on the door of a surrogate user and ask "Are you really
> one of the private users, vouched for by the registrar?"

Yes, that possibility for anyone to verify the numbers I had in mind 
back then. And I still like it.

From User:ThomasvonderElbe GmxDe Sun, 03 Jan 2010 10:51:46 +0100

>   * User registers under R-email, which gets trust from neighbours.
>     Neighbours say that R-email is not a sock puppet.
>
>   * User votes under V-email, which is vouched by registrar.
>
>   * Only registrar knows that R and V-email belong to same person.
>
>   * User promises never to vote using R-email.  Registrar checks now
>     and again to confirm that R-email never votes.
>   

This gives me the idea: Would it maybe be possible, that a private voter 
is even free to choose if he wants to vote private in certain polls and 
public in others, i.e. use V-email here and R-email there?

After all I like this version very much too. Still need to think though.

> Problem: For any V-email, bad guy can find R-email and address by:
>
>   * Looking up date when V-email was added to registrar's vouch list
>
>   * Searching history of streetwiki for non-voting R-emails that were
>     added around that time
>
> I was thinking: let the vouching registrar be global, and let her wait
> a week or so before posting each new vouch list.  Then the bad guy
> only knows the date of the new V-email within a week.  There'll be too
> many new R-emails aroung that time (many thousands the world over) for
> him to correlate.  But then user can *never* vote locally V-email, or
> give any hint of what city she lives in - else the bad guy will have a
> much shorter list of R-emails to look at.  And that's unrealistic.  So
> forget this.

How could we have a trusted and elected registrar globally? Need to 
think about this.

> Better: The registrar is local, and she waits for at least 100 new
> V-emails before publishing a new vouch list.  So there's a delay
> (maybe months) before the user can vote.  Slight problem: it will
> become easier for the bad guy to correlate, as each year goes by.
> R-emails will vanish from the streetwiki as people move (or pass
> away).  Eventually one R-email will be left alone, and the bad guy
> will know its V-email.  (Maybe by then, the user will be too old to
> care.)

Solution could be to create a new list (merge with another) with new 
V-emails for everyone as soon as the number gets below 80. That would 
solve it, right?

From User:ThomasvonderElbe GmxDe Sun, 03 Jan 2010 11:32:21 +0100

PS:

> Problem: For any V-email, bad guy can find R-email and address by:
>
>   * Looking up date when V-email was added to registrar's vouch list
>
>   * Searching history of streetwiki for non-voting R-emails that were
>     added around that time

If it were possible to use V-email in one poll and R-email in another, 
the whole problem disapears, right?
So why not give the registrar the job to once in a while check all 
polls, that in no one both emails are voting?

From User:Mike-ZeleaCom Sun, 3 Jan 2010 09:18:53 -0500

>>   * User registers under R-email, which gets trust from neighbours.
>>     Neighbours say that R-email is not a sock puppet.
>>
>>   * User votes under V-email, which is vouched by registrar.
>>
>>   * Only registrar knows that R and V-email belong to same person.
>>
>>   * User promises never to vote using R-email.  Registrar checks now
>>     and again to confirm that R-email never votes.
>
> This gives me the idea: Would it maybe be possible, that a private voter is 
> even free to choose if he wants to vote private in certain polls and public 
> in others, i.e. use V-email here and R-email there?

(I don't think so, see below.)

>> Problem: For any V-email, bad guy can find R-email and address by:
>>
>>   * Looking up date when V-email was added to registrar's vouch list
>>
>>   * Searching history of streetwiki for non-voting R-emails that were
>>     added around that time

> If it were possible to use V-email in one poll and R-email in another, the 
> whole problem disapears, right?

The problem is lessened, because using R-email to vote would allow you
to delay getting a V-email.  Any delay between the first appearance of
R-email and V-email makes it harder to tie them together.

> So why not give the registrar the job to once in a while check all polls, 
> that in no one both emails are voting?

Bad guy looks for pairs of email addresses that never vote in same
polls.  It takes computer steam, but he can do it.  Then he knows all
R-email/V-email pairs.

 So you can never vote with R-email or do anything else that ties it to
 V-email.  You have two registrations in streetwiki:
 
   R-reg: R-email + street address (real)
 
   V-reg: V-email + street address (surrogate) + personal identifiers
          (OpenID and so forth) for other voting engines

Must never allow any connection between these two to be discovered by
bad guys.  They will use phishing attacks on R-email (trying to get
voting info) and V-email (to get address info).  It will be difficult
for some people (especially older folks) to see through the tricks,
and protect their privacy.

>> I was thinking: let the vouching registrar be global, and let her wait
>> a week or so before posting each new vouch list.  Then the bad guy
>> only knows the date of the new V-email within a week.  There'll be too
>> many new R-emails aroung that time (many thousands the world over) for
>> him to correlate.  But then user can *never* vote locally V-email, or
>> give any hint of what city she lives in - else the bad guy will have a
>> much shorter list of R-emails to look at.  And that's unrealistic.  So
>> forget this.

> How could we have a trusted and elected registrar globally? Need to think 
> about this.

(It's a bad idea anyway.  Cannot use global registrar to hide the
 general location of V-email.  User's online behaviour will give away
 the location in no time.)

>> Better: The registrar is local, and she waits for at least 100 new
>> V-emails before publishing a new vouch list.  So there's a delay
>> (maybe months) before the user can vote.  Slight problem: it will
>> become easier for the bad guy to correlate, as each year goes by.
>> R-emails will vanish from the streetwiki as people move (or pass
>> away).  Eventually one R-email will be left alone, and the bad guy
>> will know its V-email.  (Maybe by then, the user will be too old to
>> care.)

> Solution could be to create a new list (merge with another) with new
> V-emails for everyone as soon as the number gets below 80. That
> would solve it, right?

Yes, that's good!  The user herself will know how many R's match her
V.  Her meta-tool will tell her, "I can see that you (V) are probably
one of these 100 R's ..."  It will list them for her, so she sees what
the bad guys see.  She can get a new V-reg anytime.  But it will cost
her a delay (the longer the better).

There's a complication.  It will be fairly easy to correlate V'old and
V'new based on voting patterns.  There may be ways of making the trail
harder to follow, though it could get complicated.  (Maybe emply your
personal autocaster for a couple of months, running in evasion-mode
:^).

This leads me to see another problem with the basic
R-non-voting/V-voting idea.  Whenever you move outside of your
district, you'll need a new V.  Otherwise the change of voting
patterns for V-email will give you away instantly!  They'll learn your
address.

So it's going to be clumsy.  It's maybe too big of a problem for us to
solve properly, especially up front.  We can hack together something
that works more or less, as long as the user is very careful, and so
forth.  There'll be problems.  But the problems will attract security
experts, and they'll figure something out.

I guess we need to be extra careful in the meantime, not to piss off
the users too much.  We have to be clear about the problems -
basically that we cannot *really* assure them of privacy yet.
Otherwise, if we give the wrong intial impression, it will be
difficult to defend the technology from attacks in the mass media.

Residential authentication by trust and authority

From private discussions between Thomas and I, this concerns how the registry might accomodate multiple schemes of residential authentication. So the P2P trust network might be augmented by a central authority (e.g. postal or electoral office) that also vouches for voters' addresses. ~Mike-ZeleaCom^talk 06:08, 5 November 2010 (UTC)

From User:Mike-ZeleaCom Tue, 19 Jan 2010 13:34:04 -0500

(                               ...  Unless I'm missing something, it
 looks like the simplest thing is to avoid messing with a registration
 authority in the first place ...                 It's difficult to
 set up, and it provides no essential benefit to the user.)

I don't think the streetwiki can authenticate an authority by doubt
signals alone (as we discussed).  It needs the trust network, too.  We
were thinking that the authority simply posts a list of the registered
street addresses.  The list is the same length as the full
[register] - one item for each user who provided proof of
address - but it contains only addresses (no identifiers etc).  The
addresses are pushed into the streetwiki, where the correponding users
appear as unidentified placeholders alongside their neighbours.

The problem is that these unidentified users are going to be baited
and forced into the open by doubt signals.  They'll be easy targets
for doubt, because they'll be unable to defend themselves without
speaking out (at least through an alias).  By the same token, their
neighbours will be unable to defend them without extending trust.
(Trust is a more serious expression, because it's risky to abuse it.
Doubt is relatively cheap.)

Another way of looking at it: with only spurious doubt signals to go
by, voting admins have no reliable grounds for trusting the authority.
They start discounting the votes of its users.  This drives the users
(again) to soliciting trust, and the authority starts using the trust
levels to authenticate its lists (a level of 1 is maybe sufficient to
retain registration).  So it boils down to this:

  a) Streetwiki with trust network, to
 
        i) Verify residential address, and
 
       ii) Verify honesty of (b) and (c);
 
  b) Additional [registries] to authenticate residential address by other
     schemes, including by authority; and
 
  c) Proxy blind to keep registration and voter ID's separate, if
     that's what a user wants.
 

These are separate facilities, but they work together.  Authority (b)
can provide an added jolt of certification on top of peer trust (a),
but it cannot provide an alternative that would stand on its own.  How
could it?  And if it could, then what would prevent the two
residential [registries] from competing and splitting the voters?