Metodologia

L'affermazione

I file selezionati vengono elaborati in locale in questo browser e non vengono caricati da FileSlimmer. Questa è un'affermazione specifica e verificabile. Questa pagina spiega come viene mantenuta vera e come puoi confermarla senza fidarti della frase in sé.

Come puoi verificarlo tu stesso

1. Apri gli strumenti per sviluppatori del tuo browser e passa alla scheda Rete.
2. Carica la pagina di uno strumento e lascia che finisca di caricarsi. Vedrai richieste per HTML, CSS, JavaScript e, per alcuni strumenti, per un modulo WebAssembly o un modello IA. Provengono tutte da questo dominio.
3. Svuota il registro di rete.
4. Seleziona un file ed esegui lo strumento.
5. Osserva il registro. Non viene inviata alcuna richiesta mentre il file viene elaborato.

Spegnere la connessione di rete dopo che la pagina si è caricata è la versione più grossolana dello stesso test: gli strumenti continuano a funzionare.

Come la build lo impone

Quattro meccanismi indipendenti, ciascuno dei quali fa fallire la build invece di limitarsi ad avvisare:

• Scansione del sorgente. Ogni file che può toccare i tuoi byte viene analizzato alla ricerca di fetch, XMLHttpRequest, WebSocket, EventSource, WebTransport, sendBeacon e FormData. Una sola occorrenza non annotata blocca la build. L'unica eccezione consentita è il download di un motore o di un modello dalla stessa origine che avviene prima dell'inizio dell'elaborazione, e ciascuno di essi porta con sé una giustificazione scritta nel sorgente.
• Controllo dell'hosting in proprio. L'intero albero dei sorgenti e l'output compilato vengono analizzati alla ricerca di host di terze parti. Nessuna libreria, nessun font, nessun modello e nessun binario WebAssembly viene caricato da una CDN, quindi nel percorso delle richieste non c'è alcuna terza parte, già in partenza.
• Content Security Policy. L'intestazione Content-Security-Policy distribuita imposta connect-src 'self'. Anche se del codice tentasse una richiesta verso l'esterno, il browser la rifiuterebbe.
• Blocco a runtime. Mentre un'operazione di elaborazione è attiva, le primitive di rete della pagina stessa vengono intercettate e rifiutano. È questo il comportamento verificato dal test automatico nel browser.

Che cosa deliberatamente non promettiamo

• Non promettiamo che un file raggiungerà una dimensione esatta. La compressione dipende dal contenuto. Quando un obiettivo non può essere raggiunto senza scendere sotto la soglia minima di qualità, FileSlimmer lo dice e restituisce il miglior risultato raggiunto.
• Non promettiamo che ogni file verrà elaborato su ogni dispositivo. La memoria del browser è limitata, e un file di grandi dimensioni su un telefono può essere rifiutato prima che possa far bloccare la scheda. I limiti del dispositivo vengono applicati prima che il tuo file venga letto, non dopo.
• Non promettiamo un punteggio di prestazioni. Lighthouse e i Core Web Vitals dipendono dal dispositivo e dalla rete.
• Non promettiamo nulla riguardo alle tue estensioni, al tuo sistema operativo o alla tua rete. Vedi la dichiarazione sulla privacy.

Le operazioni distruttive sono segnalate

Alcune operazioni perdono informazioni per loro natura. La compressione rasterizzata dei PDF rimuove il testo ricercabile, i collegamenti, i moduli, le annotazioni, i livelli, la struttura di accessibilità e le firme digitali. Modificare un PDF firmato ne invalida la firma. Rimuovere i metadati non rimuove le informazioni visibili nell'immagine stessa. FileSlimmer avvisa prima di ciascuna di queste operazioni, non dopo.

Open source

FileSlimmer è costruito su componenti open source. Le loro licenze e i loro repository sorgente sono elencati nella pagina delle note open source, compresa l'offerta di ricollegamento per i componenti LGPL.