# PoC – Proof of Concept in sede di gara  
## Sessione di Live Debug

**Scopo:** Dimostrare alla commissione d’appalto che le push E2EE sono illeggibili in transito (es. su Firebase/cloud) e diventano testo chiaro **solo sul dispositivo** dell’utente, dove risiede la chiave.  
**Cosa si mostra:** Nessun codice sorgente; solo una **dimostrazione pratica** in tempo reale.

---

## 1. Messaggio da trasmettere alla commissione

> *"L’intelligenza (la chiave di decifratura) risiede sul dispositivo dell’utente, non sul cloud. In sede di Live Debug mostriamo: (1) ciò che arriva sul cloud – un messaggio illeggibile – e (2) ciò che vede l’utente sullo stesso messaggio dopo decifratura locale: testo chiaro. La decifratura avviene fisicamente sul telefono/browser, non su server remoti."*

---

## 2. Preparazione prima della sessione

- **Dispositivo “utente”:** uno smartphone (o un secondo PC con browser) con:
  - connessione a internet;
  - push-test-cifrato aperto in HTTPS (o equivalente) e **notifiche attivate** (chiavi generate, token registrato).
- **Postazione “commissione”:**
  - PC con browser aperto su **Firebase Console** (o strumenti di sviluppo che mostrano il payload in transito);
  - opzionale: stesso browser con **DevTools → Network** (per mostrare la richiesta FCM con payload cifrato).
- **Stesso ambiente:** il messaggio inviato durante la demo deve essere quello che transita da server → FCM → dispositivo.

Checklist breve:
- [ ] Un dispositivo ha già generato chiavi E2EE e riceve push cifrate.
- [ ] Firebase Console (o FCM / progetto) accessibile e visibile su schermo.
- [ ] Possibilità di inviare una push di test (da push-test-cifrato o da API) durante la sessione.

---

## 3. Svolgimento della Live Debug (step operativi)

### Fase A – Mostrare “cosa vede il cloud / Firebase”

1. **Aprire la Firebase Console** (o lo strumento che mostra i messaggi FCM / i payload inviati).
2. **Avviare l’invio di una push cifrata** (es. da push-test-cifrato “Invia push cifrata” o da chiamata API a `send_encrypted.php`) con un testo **noto e riconoscibile** (es. *“Demo commissione – 14 marzo 2025”*).
3. **Mostrare alla commissione** ciò che risulta in console/FCM (o in Network per la richiesta a FCM):
   - **Payload in transito:** solo campi come `enc`, `ephem`, `e2ee` (dati cifrati / chiave effimera), **nessun titolo o corpo in chiaro**.
   - **Enfasi:** *“Questo è l’unico contenuto che transita e che Firebase/cloud vedono: dati illeggibili. Nessun server può leggere il testo senza la chiave privata, che non è mai uscita dal dispositivo.”*

Alternativa senza Firebase Console:
- Usare **DevTools → Network**: filtrare la richiesta a `fcm.googleapis.com` (o all’endpoint di invio) e mostrare il **body** della richiesta: stesso concetto (solo `enc`/`ephem`, niente testo in chiaro).

### Fase B – Mostrare “cosa vede l’utente sul dispositivo”

1. **Inquadrare il telefono (o il secondo browser)** dove l’utente riceve le push.
2. **Verificare** che arrivi una notifica (in primo piano o in background).
3. **Mostrare la notifica aperta** sullo schermo del dispositivo:
   - titolo e corpo **in chiaro** (es. *“Demo commissione – 14 marzo 2025”*).
4. **Enfasi:** *“Lo stesso messaggio che in transito era illeggibile, sul dispositivo diventa testo chiaro. La decifratura è avvenuta solo qui, con la chiave che non è mai stata inviata in rete.”*

### Fase C – Collegare le due viste (opzionale ma efficace)

- **Sullo stesso schermo (split o due monitor):** a sinistra (o sopra) la console/Network con il payload cifrato; a destra (o sotto) il telefono con la notifica in chiaro.
- **Frase di chiusura:** *“Un solo flusso: dati cifrati in transito, testo leggibile solo sul dispositivo. Questo è il Proof of Concept che l’intelligenza (la chiave) risiede sul dispositivo e non sul cloud.”*

---

## 4. Cosa evitare

- Non mostrare codice sorgente a meno che la commissione non lo richieda esplicitamente.
- Non fare affermazioni su “inviolabilità” assoluta; restare su: “payload in transito illeggibili” e “decifratura solo sul dispositivo”.
- Assicurarsi che rete e token siano funzionanti prima della sessione (evitare ritardi o messaggi che non arrivano).

---

## 5. Durata indicativa

- **5–10 minuti** per la sequenza A → B (e C se si usa split screen).
- Lasciare 2–3 minuti per eventuali domande della commissione (es. “dove è salvata la chiave?”, “Firebase può decifrare?” – risposta: no, la chiave non esce dal dispositivo).

---

## 6. Riferimenti tecnici (per preparazione interna)

- Protocollo e key lifecycle: **WHITEPAPER_E2EE_Willy.md**.
- Log di debug (payload cifrato e Key ID locale): **demo.html** e modalità `?debug=1` in push-test-cifrato.

---

*Documento per supporto alla dimostrazione PoC in sede di gara. Nessun codice; solo procedura operativa e messaggio da trasmettere alla commissione.*