Come funziona la proof of location in Seek

Il motivo per cui la maggior parte delle idee crypto basate sulla posizione del 2020 è morta in silenzio è che si fidavano del GPS. Il GPS è un segnale trasmesso che qualsiasi ricevitore può ascoltare, e a un ricevitore si può far mentire su ciò che ha sentito. Gli strumenti per farlo costano una trentina di dollari su Amazon, ed è così dal 2015. Qualsiasi protocollo che paga un wallet per trovarsi su una coordinata, e verifica la presenza solo con il GPS, perde soldi a favore di wallet falsi seduti sul divano. Non è un attacco difficile, né particolarmente astuto.

La proof of location è il livello che risolve il problema. L'espressione si usa più di quanto la si definisca, quindi partiamo da una definizione. La proof of location è un'affermazione, verificabile da una parte che non era presente, che un dispositivo specifico si trovava su una coordinata specifica entro una finestra temporale specifica. È un'affermazione sulla presenza, non sulla coordinata. È in questa distinzione che si concentra la maggior parte del lavoro ingegneristico.

Il modello di minaccia. Non ci stiamo difendendo da uno Stato; quel caso limite arriva alla fine. Ci difendiamo dall'attaccante medio con un telefono, un portatile e un pomeriggio libero. Quell'attaccante può falsificare il GPS con uno strumento di serie, eseguire l'app in un emulatore e creare un wallet con una riga di codice. Quell'attaccante può aggirare qualsiasi controllo preso da solo. L'obiettivo ingegneristico è rendere il costo di aggirarli tutti insieme più alto della ricompensa del drop.

Questo articolo spiega cosa fa Seek oggi, in parole semplici, e cosa sta arrivando. È volutamente più corto sul marketing e più lungo sulla meccanica.

Livello uno, al momento della cattura: attestazione del dispositivo. Ogni richiesta di cattura porta con sé una dichiarazione firmata dal sistema operativo. Su iOS è Apple App Attest, su Android è Google Play Integrity. Seek le verifica entrambe lato server. L'attestazione dice tre cose in un'unica firma: questo è un dispositivo reale, il binario dell'app non è stato manomesso e chi chiama possiede una chiave generata su questo dispositivo per la nostra app. Un telefono con root non passa. Un emulatore non passa. Un'app ripacchettizzata che salta il controllo della posizione non passa. L'attestazione non dimostra dove si trova il telefono; dimostra che il telefono non mente sul fatto di essere un telefono. È questo che dà valore agli altri segnali.

Livello due, al momento della cattura: distanza con un margine di tolleranza. Il client ti permette di toccare il pulsante di cattura solo quando sei entro il raggio di raccolta dello spawn. Il server verifica in modo indipendente le coordinate che hai inviato rispetto a quelle dello spawn e accetta una distanza fino a settantacinque metri. Lo scarto tra il raggio del pulsante e quello del server è voluto. L'instabilità del GPS su un telefono appoggiato a un muro può spostarlo di qualche metro per motivi che non dipendono da te, e rifiutare catture dentro quel margine sembrerebbe arbitrario. Oltre i settantacinque metri la richiesta viene respinta subito, senza punteggio e senza appello a quel livello.

Livello due, continua: limiti di frequenza e tetti per spawn. Due richieste di raccolta a meno di cinque secondi l'una dall'altra ricevono un 429 da un controllo basato su Postgres che persiste tra le istanze serverless. Un singolo spawn accetta al massimo due tentativi dallo stesso account, e il secondo vale il 65 percento del primo. Questi limiti non servono a rilevare le frodi; servono a impedire che un bot che ha già superato gli altri livelli sfrutti l'endpoint più velocemente di quanto possa giocare una persona.

Livello tre, al momento della cattura: segnali ambientali, registrati ma non imposti. Ogni cattura porta anche dei flag: se la richiesta proviene da un simulatore, se Android ha segnalato che la posizione arriva da un fornitore di posizione fittizia, e la precisione GPS dichiarata in metri. Vengono registrati e mai usati per rifiutare la cattura stessa. Un client che mente su questi dati è proprio il client a cui non vuoi affidare la decisione, quindi la decisione viene presa altrove. Contano al livello quattro.

Livello quattro, al momento del pagamento: il filtro antifrode. I prelievi passano da una funzione server che legge le catture degli ultimi novanta giorni dell'account. Se una di quelle catture proviene da un simulatore, o Android ha segnalato una posizione fittizia, o l'account ha fatto due catture riuscite a meno di dieci secondi l'una dall'altra, o l'account si è spostato tra due coordinate di cattura più velocemente di quanto possa fare una persona, o un altro account ha già prelevato dalla stessa impronta del dispositivo, il prelievo viene inviato a una revisione manuale invece di essere approvato automaticamente. All'utente non viene detto quale segnale è scattato, e il suo account continua a giocare normalmente. Il rilevamento è una decisione aziendale sui pagamenti, non una punizione.

Il motivo per separare cattura e pagamento è che difendono cose diverse. Il livello della cattura difende il gioco. Se la cattura era fraudolenta, diventa valuta di gioco che non esce mai dall'app, e non costa nulla. Il livello del pagamento difende denaro reale. Ogni dollaro che esce dal sistema passa per la revisione di novanta giorni di ciò che ha portato a quel saldo, e un solo segnale sospetto in quella finestra basta per affidare la decisione a una persona. Insieme, i due livelli fanno sì che un giocatore onesto non incontri mai ostacoli al momento della cattura, e che un attaccante che è riuscito a far passare una cattura falsa non veda mai il denaro.

Livello cinque, al momento della cattura: traccia di movimento. Ogni telefono ha un accelerometro e un giroscopio sullo stesso chip che comunica con il GPS. Seek ora registra una breve finestra di movimento nei secondi che precedono una cattura, calcola un piccolo insieme di statistiche (varianza dell'intensità, attività di rotazione, numero di fotogrammi fermi) e invia questo riepilogo con la richiesta di raccolta. Un telefono che ha camminato fino a uno spawn ha una firma di movimento diversa da un telefono appoggiato su una scrivania con un simulatore GPS attivo. Oggi la firma non viene imposta al livello della cattura, per lo stesso motivo per cui non lo sono i flag ambientali: un client modificato può mentire. Finisce nel filtro antifrode dei novanta giorni, insieme ai segnali di simulatore e posizione fittizia, e una traccia di movimento piatta nello storico è un altro segnale che manda un prelievo in revisione manuale.

Un esempio concreto. Un tester usa uno strumento di spoofing GPS, imposta la coordinata su un drop di Seek dall'altra parte della città e tocca cattura. Il controllo della distanza passa perché la coordinata falsificata corrisponde. L'attestazione passa perché l'app non è modificata. La cattura viene registrata. Due ore dopo lo stesso tester fa altre tre catture, una delle quali da una coordinata diversa a dieci chilometri di distanza. La traccia di movimento di tutte e quattro è piatta (il telefono non si è mai mosso), e il controllo sugli spostamenti impossibili scatta sulle due coordinate che non si potevano raggiungere a piedi in due ore. L'account continua a giocare, continua a raccogliere e non sa che c'è qualcosa che non va. Quando il tester chiede un pagamento, la richiesta arriva a una revisione manuale con il flag dello spostamento impossibile e la traccia di movimento piatta allegati. Il revisore la respinge. I quaranta dollari di saldo raccolti dal tester non varranno mai nulla fuori dall'app.

Il quadro economico. Ciò che conta non è che falsificare la cattura sia impossibile; è che il filtro sul pagamento ripercorre tutto ciò che l'account ha fatto per arrivare a quel saldo. Un drop da due euro protetto da attestazione e distanza costa poco da attaccare una volta ed è inutile attaccarlo ripetutamente, perché il controllo sul prelievo individua lo schema prima che diventi denaro. Un drop da diecimila euro richiede un quadro più solido già al livello della cattura, ed è di questo che parla la roadmap qui sotto.

Cosa c'è nella roadmap. Il prossimo controllo in arrivo è il beacon di riserva per i drop al chiuso. Per uno spawn posizionato dentro un edificio, dove il GPS non ha senso, un piccolo beacon Bluetooth registrato per il drop permette all'app di dimostrare la presenza senza dipendere affatto dalla posizione satellitare. Il secondo filone è l'applicazione obbligatoria dell'attestazione: oggi le richieste senza attestazione vengono registrate ma ancora accettate, così possiamo misurare il tasso di falsi rifiuti sui dispositivi legittimi prima di attivare l'interruttore e respingerle del tutto. Entrambi arrivano come aggiunte piccole, noiose e verificabili allo stesso schema di cattura e pagamento già in uso.

Cosa ancora non funziona bene. Il GPS al chiuso sbaglia di dieci o quindici metri in un centro commerciale, e nessuna astuzia lato server può rimediare; la vera risposta è un beacon, ed è per questo che è nella roadmap. Una latenza inferiore al secondo non c'è e probabilmente non ci sarà, perché il filtro antifrode legge lo storico e non una singola richiesta. I dispositivi indossabili hanno meno sensori dei telefoni, quindi un sistema di proof of location calibrato sui telefoni non si trasferisce facilmente sugli occhiali. E uno Stato con un camion di apparecchiature radio può oggi aggirare qualsiasi verificatore basato su telefoni cellulari; qualsiasi protocollo che affermi il contrario non è onesto con te. Il nostro non lo farà.

Il principio di design che vale la pena dire ad alta voce. Un verificatore deve essere onesto su ciò che può e non può dimostrare. Presentare un punteggio probabilistico come un sì o un no assoluto è peggio che presentare un sì o un no assoluto basato su regole rigide, perché un punteggio crea un cursore, e ogni cursore finisce spinto verso l'accettazione di più riscatti quando gli obiettivi di coinvolgimento sono indietro. Il nostro livello della cattura non ha un cursore. O supera i controlli o no. Il livello antifrode ha un cursore, e quel cursore sta nelle mani di una persona, non nel codice.

È questa la parte sotto Seek che rende sensati gli asset ancorati e gli airdrop verificati in base alla posizione. Un publisher posiziona un token con un valore reale su una coordinata perché chi finisce per averlo si trovava su quella coordinata con un dispositivo attestato, e perché il filtro sul pagamento ripercorrerà lo storico dell'account prima che il denaro si sposti. Il whitepaper contiene la specifica completa. Questo articolo è la versione in parole semplici di ciò che succede dentro l'app.

In breve. La presenza non è una coordinata. Un singolo segnale non dimostra la presenza. Seek verifica la presenza su due livelli: attestazione, distanza e traccia di movimento al momento della cattura, e un filtro antifrode sui novanta giorni al momento del pagamento. L'ultimo punto ancora aperto, il beacon di riserva per i drop al chiuso, chiude l'ultimo caso di coordinata che il GPS da solo non può coprire. Questo è ciò che la proof of location è davvero oggi dentro Seek, ed è per questo che quel livello conta più di qualsiasi cosa più appariscente che rende possibile.