User:Mike-ZeleaCom/Streetwiki

A streetwiki is a semantic wiki that serves as the front end of a residential voter registry, backed by a neighbourhood trust network. This page outlines the use cases and requirements for residential voter registration at the local level, and floats some design proposals. This is a work in progress; all are welcome to contribute.

Use cases

Use cases are functional scenarios from the perspective of the user. Note that some of the scenarios assume a particular technical design, but for purposes of description only.

Compiling a residential register

The main purpose of the voter registry is to compile a residential register. The register includes the following properties, per registrant (user):

• Personal identifiers - online identifiers (email address, OpenID, and so forth) that identify the user on one or more vote-servers
• Location - specifies the electoral districts, and so forth, where the user is primarily resident
• Trust level - provides a degree of assurance that the registration is bona fide

Most of the other use cases follow directly or indirectly from this main purpose.

Policing for local sock puppets

Note that users will have access to (a) all of the information shown on the following diagrams, such as street maps, locations of registrants on the map, and lines of trust; (b) the full residential address of each registrant down to the street and apartment number; which details will also be viewable on the map overview, perhaps as in this mockup; (c) each registrant's email address and other online identifiers; and (d) all other data from the register.

[SOCK1] Creation of isolated sock puppet network.

A user (C) registers several fake users (sock puppets), and extends trust to them [SOCK1]. C then tricks another user (D) into trusting one of the sock puppets. With two trusters, both at a level of 2, the entire network of sock puppets can rise to 2 by cross-authenticating [SOCK2].

[SOCK2] Soliciting external trust.

A third user (A) eventually notices that the locations of the sock puppets are bogus. She informs C and D. D withdraws trust from the sock puppets, but C does not. Consequently, A and B withdraw trust from C [SOCK3].

[SOCK3] Detection and withdrawal of trust.

C cannot easily regain trust by re-registering under another identity. Her address on Riverside Park is known. Any re-registration at that address is going to be suspect.

Localized responsibility

C (above) asks friends to extend trust from a remote neighbourhood. They try, but range limitations (2 km or so, in the city) prevent them from extending trust. The remote neighbourhood is not burdened with responsibility for policing actions that do not concern it.

Policing for remote sock puppets

A user lives in one place, but has a second residence elsewhere. The two places are served by different local voter registries. The user registers at both. Later, an acquaintance is browsing through the other registry and notices the second registration. She explains to the user that he ought to register only at his primary residence. He unregisters from the other place.

Verification of registers

A technically inclined user wishes to verify the registrations of the voter register for her hometown. She visits the trustserver (see diagram), and finds the output directory in which the registers are stored. It is the same directory as used by the vote-servers, to compile their voter lists:

http://reluk.ca/system/host/obsidian/home/v/votorola/out/votrace/

She copies the current snapshot to her own computer. Here it is, at time of writing:

http://reluk.ca/system/host/obsidian/home/v/votorola/outarc/votrace/snap-2012-1d-4/

Based on the snapshot of user input (_in_registration.txt), she compiles a register using the same software as the trustserver used. She then compares the output to the trustserver's original register for her hometown (e.g. Tor.xml). The two match exactly.

Next she verifies the user input itself. From the revision history of the streetwiki, she recreates the state of the user pages at the time just prior to the snapshot. She then issues the same command that was issued on the trustserver in order to generate her own snapshot of the user input (_in_registration.txt):

nice votrace snap --churn

She compares the two files. They match, except for a single registrant/user. She looks at the revision history for the corresponding user page and sees that the page was edited by the user at about that time. This explains the discrepency.

She checks with a wiki verification service. It reports no incidences of revision-history tampering, for that streetwiki. She concludes that the register contains no errors, and the registry can probably be trusted. (She re-checks it now and again, just to be sure.)

Local self-determination

A neigbourhood defines itself. It is not an administrative unit. Users lay out their own neighbourhood and way-segement pages. They add their own links to local resources, and so forth. They use the associated talk pages to discuss local matters.

Unskilled users

Some users are unfamiliar or otherwise unskilled with computers. They may include the elderly, the physically/mentally infirm, and children.

Requirements

The requirements generally follow from the use cases. Each requirement specifies the use cases that it enables.

Handshake verification of trust extension

When a trust edge is extended from a source user (S) to a destination user (T), it may typically extend only to T.username (wiki identifier). In that case, S must confirm that T.identifier (typically email address) is the intended target. For example, S must receive a confirmation message that clearly specifies T.identifier (not T.username) as the recipient of trust.

In addition, the person identified by T.identifier must confirm (or have already confirmed) that T.username is her own. For example, she must receive a message that identifies her as T.username. It should therefore be difficult for an imposter T to solicit trust, either by using an incorrect T.identifier (her own); or the correct one, with the intention of altering it later.

Required for integrity of trust extensions in #Compiling a residential register.

Public user location

Trust levels alone are insufficient to detect sock puppets. The residential address of those trusted must also be made public.

Required for #Policing for local sock puppets and #Policing for remote sock puppets.

Range-limited trust

Required for #Localized responsibility.

Data are recorded in snapshots

User input and registers are stored as snapshots, and made available for purposes of verification. Snapshots are static. No alteration is ever made to the data within a snapshot.

Required for #Verification of registers.

Correct way orientation

Ways that run east/west on the ground are presented horizontally in the wiki. Although vertical alignments may be easier to implement in some cases, they are too disorienting.

Required for #Unskilled users.

Way segment pages

Ways may be broken into relatively short segments (way segments), displayed on separate pages. Local users may customize the title, layout and content of way-segment pages. Content may be added above/below any template-generated views.

Required for #Local self-determination.

Ad hoc neighbourhoods

Neighbourhoods and way segments may overlap and cut across each other.

Required for #Local self-determination.

Prototype

A minimal prototype is currently running under the Votorola architecture. The pollwiki prototype (this wiki) is temporarily doubling as a multi-area streetwiki too. It has no street layouts. It mostly just serves as a user interface for entering registration data and trust edges.

• Property:Truster - How to extend trust to a neighbour
• Registration instructions - Follow links in Wiki:List of local areas
• Set-up instructions - For a pollwiki, as the pollwiki prototype is currently doubling as a streetwiki
• Web API
  • Wiki   Instructions and access
  • Data queries (access)
  • Page RDF (access)
• Web UI - Reference streetwiki (this wiki)

[RA] Registration architecture. An example of how streetwikis relate to other facilities in the context of a broader architecture. © 2013 Michael Allan, original

Trust network

The trust network is a directed graph of user-to-user trust edges that are extended by the users for the purpose of cross-authenticating the voter registry. Individual trust edges are stored as wiki properties in the source (user) page. During compilation of the register (by the trustserver), the edges are traced to determine the level of trust for each particular registration. These levels are then incorporated into the resulting register.

A trust edge extends from a source to destination user node (T). It pertains to the following attributes of the latter's registration:

• T.identifier (email address is likely to be best, for this purpose)
• T.location

The trust edge asserts, “Yes. That's the email address of my neighbour across the street, she's a real person, and she really does live there.” More formally:

• T.identifier is the identifier of a person (P) living at T.location. It is not the identifier of a bot or other imposter, posing as P.
• T.location is the primary residence of P.
• P is registered exactly once at T.location. For each other user (U), where U.location equals T.location, U.identifier is the identifier of a person other than P.

A given source node may extend trust to any number of destination nodes (subject to any bars imposed by the configuration), but may extend at most one edge to each. The extension of trust is configured and controlled by runtime scripts on the trustserver.

In a fully elaborated network, each destination node is evaluated at a particular level of trust, which is recorded in its entry in the register. The recorded level (t) depends exclusively on the levels among the source nodes, where it is calculated as the highest level that does not exceed the count n(t) of sources at that level or higher. In other words, to have a trust level of 3, a voter must have 3 or more immediate trust sources, each itself having a trust level of 3 or higher.

t ≤ n(t)

where:

(t) is the trust level

n(t) is the count of immediate source nodes at level (t) or higher

The ultimate trust source is the root node, which is the trustserver administrator. All trust edges must be traceable to the root, otherwise they are discounted in the elaborated network. Unlike an ordinary node, the root has a high (effectively infinite) trust level, and it may extend any number of edges (primary trust edges) to the same destination. The maximum trust level in the network is limited by the redundancy of primary edges extending from the root.

Doubt signaling

translating from here

but talk pages (users, buildings, streets) are maybe sufficient for expressing doubt

Proxy blind

A proxy blind is a proposed method for implmenenting a private voting option. It works by splitting the registrant's identity in two: 1) a registration ID and 2) a voting ID or proxy. The equivalence of the two ID's is a secret between the registrant and registrar (the blind). The identity of the voter, as such, is therefore unknown to anyone else. No full design sketch has been drawn yet. See the design discussions under User talk:Mike-ZeleaCom/Streetwiki#Proxy_blind from which the following notes are taken:

  * 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.

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

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.

See also User talk:Mike-ZeleaCom/Streetwiki#Residential_authentication_by_trust_and authority:

 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.

And see the thread: The case for anonymity, continued.

Streetwiki user interface

An early proposal for the layout of a way (street etc) is http://reluk.ca/project/streetwiki/way.xht. It doesn't yet meet the requirements.

Addenda

See also

• Registration framework
• Votorola/t - An architectural example of how streetwikis relate to other facilities within the broader context of broad-based system guidance

Glossary

See also the registration glossary.

primary trust edge

An edge that extends directly from the trustserver administrator.

sock puppet

A second registration under a false identity. See http://en.wikipedia.org/wiki/Sockpuppet_(Internet).

trust network

A directed graph of user-to-user trust edges that are extended by the users for the purpose of cross-authenticating the voter registry.

use case

A functional scenario from the perspective of the user. A way of using a system.

way

A road, corridor, canal or other passage along which residences are situated.

way segment

A relatively short, lengthwise portion of a way.

Property settings

• Date (2010-01-16)
• Form (Semantic MediaWiki)
• Form (MediaWiki)
• Origin (Votorola)
• Purpose (Stuff:Outcast)
• Stage (alpha)

Notes

Credits should also be added here. Meantime, please see User talk:Mike-ZeleaCom/Streetwiki.