Metodyka

Deklaracja

Wybrane przez Ciebie pliki są przetwarzane lokalnie w tej przeglądarce i nie są przez FileSlimmer nigdzie przesyłane. To jedna konkretna, sprawdzalna deklaracja. Ta strona wyjaśnia, w jaki sposób pozostaje ona prawdziwa i jak możesz to potwierdzić, nie ufając samemu zdaniu.

Jak możesz to sprawdzić samodzielnie

1. Otwórz narzędzia deweloperskie przeglądarki i przejdź do karty Sieć.
2. Wczytaj stronę narzędzia i poczekaj, aż skończy się ładować. Zobaczysz żądania plików HTML, CSS i JavaScript, a w przypadku niektórych narzędzi także modułu WebAssembly lub modelu AI. Wszystkie pochodzą z tej domeny.
3. Wyczyść dziennik sieciowy.
4. Wybierz plik i uruchom narzędzie.
5. Obserwuj dziennik. W trakcie przetwarzania pliku nie jest wysyłane żadne żądanie.

Wyłączenie połączenia sieciowego po załadowaniu strony to bardziej brutalna wersja tego samego testu: narzędzia działają dalej.

Jak wymusza to proces budowania

Cztery niezależne mechanizmy, z których każdy przerywa budowanie, zamiast wyświetlać ostrzeżenie:

• Skanowanie kodu źródłowego. Każdy plik, który może dotknąć Twoich bajtów, jest skanowany pod kątem użycia fetch, XMLHttpRequest, WebSocket, EventSource, WebTransport, sendBeacon i FormData. Pojedyncze wystąpienie bez adnotacji zatrzymuje budowanie. Jedynym dozwolonym wyjątkiem jest pobranie silnika lub modelu z tej samej domeny, następujące przed rozpoczęciem przetwarzania, a każde z nich ma w kodzie źródłowym pisemne uzasadnienie.
• Audyt samodzielnego hostowania. Całe drzewo kodu źródłowego i zbudowany wynik są skanowane pod kątem hostów zewnętrznych. Żadna biblioteka, czcionka, model ani plik binarny WebAssembly nie jest ładowany z CDN, więc na ścieżce żądania nie ma w ogóle żadnej strony trzeciej.
• Content Security Policy. Wdrożony nagłówek Content-Security-Policy ustawia connect-src 'self'. Nawet gdyby kod spróbował wysłać żądanie na zewnątrz, przeglądarka by na to nie pozwoliła.
• Blokada w czasie działania. Gdy zadanie przetwarzania jest aktywne, własne prymitywy sieciowe strony są przechwytywane i odrzucają żądania. To zachowanie sprawdza automatyczny test przeglądarkowy.

Czego świadomie nie obiecujemy

• Nie obiecujemy, że plik osiągnie dokładnie zadany rozmiar. Kompresja zależy od treści. Gdy celu nie da się osiągnąć bez zejścia poniżej progu jakości, FileSlimmer mówi o tym i zwraca najlepszy wynik, jaki uzyskał.
• Nie obiecujemy, że każdy plik zostanie przetworzony na każdym urządzeniu. Pamięć przeglądarki jest ograniczona, a duży plik na telefonie może zostać odrzucony, zanim zdąży doprowadzić do awarii karty. Ograniczenia urządzenia są stosowane przed odczytaniem Twojego pliku, a nie po nim.
• Nie obiecujemy określonego wyniku wydajności. Lighthouse i Core Web Vitals zależą od urządzenia i od sieci.
• Nie obiecujemy niczego w sprawie Twoich rozszerzeń, Twojego systemu operacyjnego ani Twojej sieci. Więcej na ten temat mówi polityka prywatności.

Operacje niszczące są oznaczane

Niektóre operacje z natury tracą informacje. Kompresja pliku PDF z rasteryzacją usuwa wyszukiwalny tekst, linki, formularze, adnotacje, warstwy, strukturę dostępności i podpisy cyfrowe. Edycja podpisanego pliku PDF unieważnia jego podpis. Usunięcie metadanych nie usuwa informacji widocznych na samym obrazie. FileSlimmer ostrzega przed każdą z tych operacji, a nie po niej.

Open source

FileSlimmer jest zbudowany na komponentach open source. Ich licencje i repozytoria źródłowe wymieniono na stronie z notami licencyjnymi open source, wraz z ofertą ponownego linkowania dla komponentów na licencji LGPL.