Summary

  • LACNIC’s pinned open-source election distribution makes ALL the default public-link recovery mode for a newly constructed election, while leaving ONLY_BR and NONE available for explicit configuration.
  • One normalised email request is checked against three distinct records—voter, organisation membership contact and nomination supporter—and may cause vote, nomination and support links to be mailed.
  • The code deserves credit for generic responses and per-class limits. A private capability-recovery receipt would add the missing join among election rule, authority class, recovery setting, token lifetime, delivery, use and invalidation.

The important word in the code is not “email”. It is ALL.

In the public version of LACNIC’s election system captured at commit 3c2068477eb38ebbbe70039ee6e1b7b004fc69cd, both constructors for a new election select a default through ElectionLinkRecoveryMode.defaultForElectionType. The method accepts an election type and returns the same value: ALL. A regression test expects that result for a newly created BOARD election. The accompanying guide is plainer still. In this public distribution, it says, new elections start in ALL regardless of type. Administrators can choose ONLY_BR or NONE, but breadth is the initial condition.

That choice is not proof of a defect. It may be a sensible response to the most prosaic failure in remote governance: the eligible participant cannot find an old message containing a long link. Recovery can prevent a mail filter, a changed device or an overflowing inbox from disenfranchising someone who remains entitled to act. LACNIC’s own public description presents the election system as remote, secure and open source so that interested people can audit and verify it. Recoverability belongs in that promise.

But a recovered link is not merely a convenience. It is a bearer capability. Depending on the record found, it can open a voting path, let an organisation nominate, or let a contact support a nomination. Those acts arise from different institutional roles. The same mailbox can legitimately stand behind more than one of them. What cannot be assumed is that a single default explains the authority of all three.

One form crosses three registers

The recovery panel first trims the submitted address and converts it to lowercase. It then performs three searches scoped to the election. One looks for UserVoter.mail. A second looks for Organization.membershipContactEmail. A third looks for SupportNomination.supportingContactEmail. Each result is handled through its own link type: VOTER_VOTE_LINK, NOMINATION_LINK or SUPPORT_LINK.

This is better understood as a junction than as an account-reset screen. The voter record says that a person or organisational delegate may cast a ballot under the rules of one election. The membership-contact record says who can act for an organisation in making a nomination. The supporting-contact record records a narrower role in relation to an existing nomination. The strings can be identical while the powers remain different.

For each class, the implementation limits the lookup to ten matches. In the ordinary ALL path, there is no country filter. In ONLY_BR, the code applies Brazil through the country field appropriate to each record: the voter’s country, the organisation’s country, or the country of the organisation that issued the nomination. The limit is useful protection against an unbounded fan-out. It is not a total limit of ten, because the three searches are separate. Nor is it an authorisation rule. It controls how much one request processes, not why any returned record carries a valid power.

The panel then queues messages containing the available links. For voters it uses the vote-token link. For organisations it sends the nomination link only when the nomination token is non-empty. For supporters it uses the support token. The destination comes from the matched record. The public requester never receives a list on screen.

This design draws a sound boundary against direct enumeration. When no operational error occurs, the interface returns the same acceptance message whether the address matched records or not. The documentation states that the system does not disclose a match to the requester. That is an important control and should not be lost in a critique of the default.

Yet non-disclosure to the screen and delivery of authority to an inbox solve different problems. The first prevents a visitor from learning whether an address participates. The second determines what a person who controls that inbox can obtain. A generic message can conceal the match perfectly while the mail channel still carries three different kinds of institutional power.

A mode is not a mandate

ALL, ONLY_BR and NONE are configuration choices. They describe which geographical or disabled branch the software will execute. They do not record why that branch is appropriate for a particular election.

Election type matters because the principals differ. A board election, a Fiscal Commission election, an Electoral Commission election, a PDP moderator process and an ASO AC or IANA Review Committee election do not necessarily draw authority from the same electorate or rule. Even if the same recovery mechanism is suitable for every one of them, that suitability is a governance decision rather than a property of an enum.

The default compresses that decision into construction time. A new election begins broad unless an administrator deliberately narrows it. That can be a defensible product choice: safe defaults sometimes favour participation and supportability. But a reviewer later needs to distinguish three possibilities. Was ALL considered and approved? Was it inherited without discussion? Or was it temporarily necessary because another recovery channel was unavailable? The database value alone cannot answer.

The code also shows that recovery is bounded by more than the enum. It is disabled when the election is closed. The public landing must be available and have reached the N_1 opening stage. The documentation says recovery adds no calendar of its own. In other words, one feature borrows the life cycle of the election and the visibility of the landing rather than publishing an independent recovery window.

Borrowed timing is economical, but it can hide an important operational question: when should the ability to reissue a capability stop? A voting link should not be useful after a ballot is cast or voting closes. A nomination link should follow the nomination period. A support link should follow the support period and the status of the underlying nomination. The guide describes those downstream windows for the token pages, but the recovery form itself searches all three classes while the election remains open. Sending an unusable or already-spent link may be harmless. Sending a still-usable link requires the downstream gate to be right.

A receipt should show both events rather than asking the recovery screen to stand in for them.

The inbox is a delivery address, not the source of authority

Email recovery relies on a practical proposition: control of the registered inbox is an acceptable way to re-deliver a capability already assigned elsewhere. It does not mean the inbox created that capability.

The voter’s entitlement came from the electoral roll. The organisation’s nomination power came from its membership status and designated contact. The supporter’s role came from a nomination workflow. Recovery should preserve those lineages. If an address changes, is shared by colleagues, routes through a role mailbox or has been reassigned, the fact that a message was delivered cannot repair an outdated authority record.

Conversely, a current authority record can remain valid even when delivery fails. Mail can bounce. A corporate gateway can quarantine a message. A delayed queue can deliver after the useful window. A person can receive ten links but need only one. The implementation records aggregate matches and queued messages for its immediate result, and it treats a class with matches but no queued delivery as an operational failure. That is valuable process evidence. It is not yet a durable statement that the right recipient obtained a usable link at the right time.

The distinction is familiar outside elections. OWASP’s forgot-password guidance recommends a consistent public response, a side channel, strong single-use expiring tokens and controls such as per-account rate limits or CAPTCHA. NIST’s digital-identity guidance treats recovery methods as the product of documented risk analysis and couples account recovery with notification. Neither document governs LACNIC elections, and a vote link is not a password-reset token. Their relevance is architectural: recovery is a separate authority event whose evidence cannot be reduced to “mail queued”.

LACNIC’s public code already implements part of that discipline. The accepted message does not reveal whether a record exists. The searches are capped by class. CAPTCHA validation can operate when a global switch allows it and a site key is present. The request is scoped to one election, and a client IP is passed into the mail-sending operation. These are real controls.

They also expose the boundaries of the public evidence. CAPTCHA is conditional, not intrinsic to every recovery. The captured source does not establish a live rate-limit setting, token lifetime, token rotation after recovery, message delivery, inbox custody or post-use invalidation. It would be wrong to infer that any of these controls is absent from a deployed system. It would be equally wrong to infer that they exist merely because the public form returns an uninformative message.

Open source makes the question answerable, not automatically answered

The repository is unusually helpful because it makes the path inspectable. The guide names the three databases searched, the three link classes, the country mode, the per-type cap and the generic response. The code shows the control flow. Tests pin the constructor’s default. A 11 September compatibility commit keeps that expectation visible after a broad library update.

That transparency does not identify a live build. The checked sources do not show that this commit runs a current LACNIC election, that its configuration uses ALL, that CAPTCHA is enabled or disabled, or that anyone recovered a link. An earlier BTW article examined a different problem in the same open-source project: an authenticated report lookup placed an email address in a GET request path. Another archived article asked whether a live ballot identified its build. This article does neither. It examines the authority boundary inside the public recovery design, without claiming that public code and production are the same object.

This is precisely where software transparency often loses value. Publication allows outsiders to discover a consequential default, but no release receipt binds that default to an election, its rules or its deployment. Operators may know the answer internally. Readers cannot move from repository behaviour to electoral fact without inventing a bridge.

The right response is not to publish deployment secrets, voter addresses or token events. It is to publish a small aggregate statement for each election: which reviewed build and recovery mode applied, which link classes were eligible, what dates bounded the recovery surface, whether automated-abuse controls were active, and who approved any departure from the usual rule. The sensitive record stays private.

The minimum private receipt

A useful capability-recovery receipt would begin with the election identifier and the exact software or configuration generation. It would name the election type and the rule that creates each eligible role. It would state whether ALL, ONLY_BR or NONE was inherited or explicitly selected, by whom, and at what review date.

For each request, the private record would keep the authority class separate. “Voter”, “organisation nominator” and “nomination supporter” should not be collapsed into “user”. The receipt need not copy an address into a public log. A protected reference to the relevant roll or workflow row is enough. It should show that the row was current at recovery time and which downstream calendar and status gates still applied.

The token side needs its own lineage: whether the message re-sent an existing link or created a replacement; the token generation; its expiry; whether a previous token was invalidated; whether the action was already complete; and the terminal event—used, expired, revoked or superseded. A queue result belongs beside, not instead of, a delivery result. Exceptions should preserve the class and failure stage without writing tokens or addresses into ordinary application logs.

Finally, the receipt should close. Election closure, the end of voting, the end of nominations and the resolution of a support request are different events. A reviewer should be able to prove that no still-effective recovered capability outlived the act it could authorise. Where a valid link remains available for historical viewing, that read-only state should be distinguished from decision power.

The public projection can be spare: build identity, configured mode, eligible classes, effective window, aggregate requests, aggregate queued and failed deliveries, abuse-control status, invalidation policy and review owner. The private projection carries the sensitive joins. This division allows audit without turning transparency into a voter map.

Recovery is part of the election, not merely support

Remote elections fail in ordinary ways. People lose messages; addresses change; filters misbehave; organisations rotate staff. A system that cannot recover may convert an operational accident into unequal participation. Broad recovery can therefore strengthen legitimacy.

It can also shift control silently. The person operating the inbox may not be the person or organisation that originally earned the capability. A default may survive from one election type into another. A message may arrive after the political moment but before a technical flag closes. None of those possibilities proves abuse. They show why recovery deserves the same evidence discipline as initial issuance.

LACNIC’s public distribution makes the engineering legible. It distinguishes three records and three links. It limits searches and avoids a revealing response. Its remaining weakness is documentary: the default can say ALL while the audit record says nothing about why all three powers were in scope.

That gap is small enough to fix. Keep the convenient form. Keep the generic message. Keep personal data and tokens private. Add one dated, versioned receipt that joins the election’s rule to the recovery configuration and follows each capability to use or closure. Then a lost email can be repaired without making the inbox look like the institution that granted the vote.

Sources