Part A: audience strategy. Part B: system design (translated from the Fiveo1 Secure Voting Poll whitepaper v1.0). Part C: launch requirements. Part D: EU administrative directory. Summary Fiveo1 has built a mobile-first, single-file poll that records one yes/no answer per person card from each unique "footprint" (network address, device, screen and GPS position). The mechanism works. The audience does not yet exist: the site's cleaned traffic is about 1,500 unique IPs, far below any level of political relevance in California. This initiative pairs the technology with a deliberate outreach plan aimed at real California voters, and lists the privacy and integrity work needed before that outreach begins. Part A. Audience strategy The California electorate Figures below are as supplied for this document and should be verified against the California Secretary of State before publication. Measure Value Registered voters (May 2026) ~23.16 million Democratic / Republican / No Party Preference ~44.9% (~10.4M) / ~25% (~5.8M) / ~23% 2024 US Senate total votes 15.35M (Schiff 9.04M; Garvey 6.31M) 2022 US Senate total votes ~10.8M (Padilla ~6.6M; runner-up ~4.2M) No US Senate seat is on California's 2026 ballot. Padilla's term runs to 2029 and Schiff's to 2031. The 2026 cycle covers the governor's race, other statewide offices and the even-numbered California State Senate districts. Realistic engaged-audience targets These are order-of-magnitude figures for engaged unique people, not raw hits or short bot visits. Goal Engaged audience needed Why Basic visibility, early stage 10,000 – 50,000 Shows real interest and starts organic sharing Noticeable political presence 100,000 – 300,000 Can influence local discussion, media mentions, small fundraising State Senate district relevance 50,000 – 150,000+ in one district Districts hold roughly 900k–1M+ registered voters; competitive races turn on tens of thousands of votes Statewide influence 500,000 – 2M+ Statewide candidates need multi-million vote totals Where Fiveo1 stands About 1,500 unique IPs remain after removing the two heavy Guatemala testing IPs. That is pre-audience: private testing, with little sustained engagement or California concentration. Growth has to come from outreach aimed at California voters, not passive traffic. The most efficient first target is a single State Senate district, where the goal shrinks to that district's voters. A statewide voice is a much higher bar. Recommended path Choose one scope first: a specific State Senate district, or a statewide voice. Everything else follows from that choice. Stage 1 goal: reach 10,000 engaged California visitors, measured by geolocated, non-test, non-bot votes. Segment outreach by party or independent groups in the chosen district. Keep the seeded contact and election-official cards (53 people, including San Diego, Riverside, San Bernardino, Corona, Apple Valley and Victorville officials) as the launch content, and add local candidates and issues as questions. Harden security first. Political sites attract more scanning and hostility. Part B. System design: Secure Voting Poll v1.0 Abstract The poll is a single-file, self-contained, mobile-first system that binds each yes/no vote to a footprint signature: a SHA-256 hash of the voter's network address, device fingerprint, screen geometry and GPS position. The signature is computed only on the server and stored in a local SQLite database, and a SQL UNIQUE(question_id, signature) constraint enforces it. Once a signature has voted on a person card, it cannot vote there again, whatever the cache, cookie, browser or session state. Moving physically produces a new signature and permits a new vote. Each vote is stored as a full, immutable record, and a cumulative OpenStreetMap shows every footprint as a green (yes) or red (no) marker. Design goals Goal Implementation One vote per person, device and location Server-computed signature plus SQLite UNIQUE constraint Zero client trust Signature uses only server-observable headers Resistant to cache, cookies, history Enforcement lives in the database Mobile only, no keyboard Touch targets of at least 52 px; no text input on the public page Full footprint per vote IP, user agent, screen, GPS, accuracy, geocoded location, timestamp, signature Cumulative geographic view Leaflet with OpenStreetMap, one marker per vote Minimal dependencies One SQLite file, PHP files, CDN only for the map library Auto-provisioning Database and schema created on first page load Architecture Component Responsibility index.php Public page: live footprint cards, totals, people feed, map button; JSON API for signature, votes and map points; accepts vote POSTs admin.php Password-protected question manager: view and delete questions, clear votes, see recent signatures fiveo1.sqlite Single-file embedded database in WAL mode for safe concurrent reads Leaflet 1.9.4 Client-side map rendering with OpenStreetMap tiles Nominatim Free reverse geocoding from latitude/longitude to a readable street name The voter's phone (browser, Geolocation API, Leaflet, Nominatim calls) talks over HTTPS to Apache or Nginx with PHP-FPM. The server makes no outbound calls. The footprint signature signature = SHA256( ip | user_agent | screen | lat3 | lon3 ) Component Source Note ip REMOTE_ADDR Never supplied by the client user_agent HTTP_USER_AGENT The header actually received screen Client width × height Normalized to max×min, so rotation does not matter lat3, lon3 Client GPS Rounded to 3 decimals, about 110 m Why 3 decimals. At 4 decimals (about 11 m), GPS jitter shifts a stationary phone between page loads and defeats the lock. At 3 decimals the drift is absorbed, while a voter who moves to a different block gets a genuinely new signature. Why the server computes it. An earlier prototype hashed on the client. It failed because of truncation mismatches between the stored and hashed user agent, and because a malicious client could fabricate unlimited signatures. Now the client sends only screen, latitude and longitude, and the server is the sole authority. Signature stability Scenario Signature Vote again? Same phone and place, cache cleared or new browser Same Blocked Same phone, moved ~500 m Different (GPS) Allowed Same phone, Wi-Fi to cellular Different (IP) Allowed OS update changes user agent Different (UA) Allowed Different phone, same Wi-Fi and place Different (UA, screen) Allowed Database schema CREATE TABLE questions ( id INTEGER PRIMARY KEY AUTOINCREMENT, text TEXT NOT NULL, created_at TEXT NOT NULL ); CREATE TABLE votes ( id INTEGER PRIMARY KEY AUTOINCREMENT, question_id INTEGER NOT NULL, signature TEXT NOT NULL, answer TEXT NOT NULL, -- 'yes' | 'no' ip TEXT, device TEXT, -- UA truncated to 400 chars screen TEXT, lat REAL, lon REAL, accuracy REAL, -- GPS accuracy in meters location TEXT, -- reverse-geocoded name user_id TEXT, -- persistent localStorage id created_at TEXT NOT NULL, UNIQUE(question_id, signature) ); CREATE INDEX idx_votes_q ON votes(question_id); CREATE INDEX idx_votes_sig ON votes(question_id, signature); The UNIQUE(question_id, signature) constraint is the security core. SQLite itself rejects a duplicate with SQLITE_CONSTRAINT, which the PHP handler turns into an HTTP 409 duplicate_signature response, even if the application layer is bypassed. Voting lifecycle Pre-vote check. On page load the client requests its IP, obtains GPS, then asks ?action=my_signature. The server recomputes the signature and returns which questions it has already voted on. The client locks those cards and shows the earlier answer, so the voter sees the lock before touching anything. Casting a vote. The voter taps YES or NO; both buttons disable at once. The client POSTs question_id, answer, screen, lat, lon, accuracy, location and user_id. It sends no signature. The server computes it and inserts. Success returns 200 with fresh yes/no totals; a UNIQUE violation returns 409 with the same totals. Either way the client ends in the locked state with correct counts. Guarantees. Inserts are atomic, the final display is idempotent, and totals are recomputed by the server from the votes table. Threat model Threat Mitigation Clear cache, cookies or history; incognito; reinstall Signature depends on IP, UA and GPS, not the browser. Blocked. Second phone on same Wi-Fi Different signature, allowed by design (per device, not per household) Spoofed GPS A new spoofed position yields a new signature and vote. Detectable only by admin review of the map, signatures, IPs and locations. Man-in-the-middle Terminate TLS at the proxy, enable HSTS; JSON POST API, no cookies carry vote state Admin password brute force Lockout after 5 attempts with 60 s cooldown, constant-time compare, 400 ms failure delay SQL injection PDO prepared statements with bound parameters XSS All output through htmlspecialchars with ENT_QUOTES Replay with a stolen signature Signatures are public identifiers; the database rejects duplicates Carrier IP rotation mid-session Pre-check is advisory; the database is the final arbiter Known non-mitigations: VPN hopping lets one voter cast multiple votes; shared phones cannot vote per household member; GPS jitter at a rounding boundary can occasionally produce two signatures (rounding error is bounded by about 55 m). Reverse geocoding and map The client calls Nominatim once per GPS lock (jsonv2, zoom 16), preferring road, pedestrian, neighbourhood, suburb, village, town, then city. The name is stored in votes.location and shown on cards, the feed and map popups. This respects Nominatim's public policy of a valid User-Agent and under one request per second. The map uses Leaflet 1.9.4 and OpenStreetMap tiles: ?action=map_points returns all votes with coordinates; green circles for yes, red for no (7 px historical, 10 px for a live GPS tap); popups show name, answer, time, location and a 16-character signature prefix; fitBounds zooms to all points (max zoom 16). The overlay covers 84 vh (max 640 px) and closes by button or by tapping outside. People feed and administration Every question is a person card showing name, role line, last activity with location, YES and NO buttons, totals and an expandable list of full footprint blocks. The public footer shows only Fiveo1, the PO Box address and Evan Winter. The admin page is not linked publicly and supports adding people (Name — Role · Office · City), viewing counts and unique signatures, deleting a question with its votes, clearing votes, viewing the 40 latest signatures, and logging out. Deployment Requires PHP 7.4+ with pdo_sqlite, json and session; write permission on the directory (for fiveo1.sqlite plus WAL/SHM files); Apache or Nginx with TLS. The database creates itself on first request. Hardening checklist: force HTTPS with HSTS; set session.cookie_secure, httponly and SameSite=Lax; change ADMIN_PASSWORD; disable directory listing; disallow admin.php in robots.txt; schedule backups of the database and its -wal/-shm files; keep upload limits low and disable allow_url_fopen if unused; restrict directory write access to the PHP-FPM user. Action needed: the source whitepaper prints the admin password in plain text. It was deliberately left out of this document. Change it, and remove it from any published copy of the whitepaper. Part C. What this needs before a California launch These items are additions of my own, not in the original whitepaper, and are the gap between a working prototype and something safe to put in front of hundreds of thousands of people. Privacy compliance. The poll stores IP address, precise GPS coordinates and a device fingerprint tied to a political opinion. Under California privacy law (CCPA/CPRA), precise geolocation is sensitive personal information, and political views are also sensitive. A public privacy notice, a clear consent step before the GPS prompt, a retention limit, and a deletion path are needed. A qualified California privacy attorney should review this. Public map exposure. The map shows where each answer was cast. Publicly showing precise points could reveal a voter's home. Show the admin-only precise view, and publish only coarsened or aggregated points. Accurate claims. The system enforces one vote per footprint, not one per person. Describe it that way, as an informal poll and not a scientific or official election. It should be clearly labeled unofficial. Named individuals. Cards name real officials. Keep the questions factual and neutral, and avoid content that could read as impersonating or misrepresenting them. Campaign rules. If the platform will support or oppose a candidate or ballot measure, California and federal disclosure and disclaimer rules may apply. Check with the Fair Political Practices Commission or counsel. Engineering gaps from the whitepaper: per-IP rate limiting, an admin audit log, CSV export, server-side GPS plausibility checks, and a plan to move off SQLite past roughly 100 writes per second. Part D. Administrative directory: European Union institutions This part is the administrative reference for the initiative's international contacts. The authoritative source is EU Whoiswho (whoiswho.europa.eu), the electronic directory run by the Publications Office of the EU. It holds organisational charts, contact details and hierarchies for all EU institutions, bodies and agencies. Details below are as supplied by the author and should be checked against Whoiswho before use. Key institutions Institution Address Phone Web / email European Commission Rue de la Loi / Wetstraat 200, 1049 Brussels, Belgium +32 2 299 11 11 commission.europa.eu (online contact form) European Parliament Rue Wiertz 60, 1047 Brussels, Belgium (main seat); Allée du Printemps, 67070 Strasbourg, France +32 2 28 33000 (Brussels); +33 3 88 17 4000 (Strasbourg) europarl.europa.eu Council of the European Union Rue de la Loi / Wetstraat 175, 1048 Brussels, Belgium +32 2 281 61 11 consilium.europa.eu; public.info@consilium.europa.eu European External Action Service (EEAS) Rond Point Robert Schuman 9A, 1046 Brussels, Belgium +32 2 584 3013 (a specific office) eeas.europa.eu Court of Justice of the EU Palais de la Cour de Justice, 2925 Luxembourg +352 4303 1 curia.europa.eu European Central Bank Sonnemannstrasse 20, 60314 Frankfurt am Main, Germany +49 69 13 44 0 ecb.europa.eu European Court of Auditors 12, rue Alcide De Gasperi, 1615 Luxembourg +352 4398 1 eca.europa.eu European Committee of the Regions Bâtiment Jacques Delors, Rue Belliard 99-101, 1040 Brussels, Belgium +32 2 282 22 11 cor.europa.eu How to access the full directory Online portal: whoiswho.europa.eu, searchable by name, institution or organisation. EU Open Data Portal: the dataset is published there, with a SPARQL endpoint for querying the full content and CSV files listing persons for the Commission, Council, Parliament and other bodies. PDF publications: current and historical directories, for example an EEAS directory dated 01/09/2026 with staff names, emails and phone numbers. The full directory covers thousands of staff across all Directorates-General and agencies and changes often, so it is referenced here rather than reproduced. Example entries (as supplied) Name Role Contact Mr Bernd BIERVERT-LÜTH Head of Cabinet Bernd.Biervert@ec.europa.eu; +32 229-56887 Ms Petra GOMBALOVA KYSLINGEROVA Head of Office (Acting), EEAS Petra.GOMBALOVA@eeas.europa.eu; +32 2584-3013 Mr Gustavo LUENGO Hearing Officer, DG TRADE Gustavo.LUENGO@ec.europa.eu Staff roles and contacts change. Treat the entries above as illustrations of what Whoiswho holds, and confirm any individual against the live directory before contacting them. Use these contacts only for professional purposes, and for any outreach involving EU staff keep to their official channels. Fiveo1 · PO Box 312786, Avalon, California 90704 · Evan Winter