Mobilne szyfrowanie transferu plików: bezpieczne udostępnianie w ruchu

Mobilne szyfrowanie plików działa w Safari na iOS i Chrome/Firefox na Androidzie za pomocą Web Crypto API — tego samego wywołania crypto.subtle.encrypt, które działa na desktopie. Pliki pobrane z biblioteki Zdjęcia lub aplikacji Pliki są szyfrowane AES-256-GCM zanim jakikolwiek bajt opuści telefon. Ciężkim zadaniem jest wyprowadzanie klucza PBKDF2, które na iPhone'ie 14 Pro kończy 600 000 iteracji w ok. 350 ms. Dla pliku .mov 500 MB z ostatnich wakacji prawdziwym wąskim gardłem jest przepustowość przesyłania, nie szyfrowanie. Mobilne serwisy transferu nie potrzebują natywnych aplikacji — przeglądarka ma wszystko, czego potrzeba.

Dlaczego przeglądarka bije natywne aplikacje na mobile

Natywne aplikacje iOS i Android do transferu plików (Dropbox, stara aplikacja WeTransfer sprzed 2023) żądają szerokich uprawnień, pozostają w pamięci po użyciu i wyświetlają reklamy. Przepływ pracy oparty na przeglądarce nie wymaga instalacji, działa jednorazowo i kończy się po zamknięciu zakładki. Co ważniejsze, odrzucanie przez App Store prawdziwie zero-knowledge aplikacji (opisana saga Cryptee z 2021) sprawia, że dostarczanie przez przeglądarkę to jedyny sposób na zagwarantowanie, że logika szyfrowania nie zostanie po cichu wymieniona przez aktualizację App Store. Ten sam bundle JavaScript działa wszędzie, weryfikowalny względem skrótów SHA-384.

Web Crypto API na iOS i Androidzie

Safari 17 na iOS 17+ w pełni obsługuje crypto.subtle: deriveKey, encrypt, decrypt, sign, verify. Chrome na Androidzie obsługuje je od wersji 37 (2014). Obie implementacje delegują do natywnych prymitywów systemu operacyjnego — CommonCrypto na iOS, BoringSSL na Androidzie — więc kryptografia jest sprzętowo przyspieszona przez instrukcje AES architektury ARM. Szyfrowanie fragmentu 5 MB zajmuje ok. 15 ms na Pixel 8. API nie ujawnia surowego materiału kluczowego do JavaScript (obiekty CryptoKey to nieprzejrzyste uchwyty), co pomaga przeciw złośliwym rozszerzeniom, choć mobilne przeglądarki mają ich znacznie mniej.

Obsługa dużych plików bez wysadzania pamięci

Mobilny Safari ogranicza stertę JavaScript do ok. 2 GB na iPhone'ach z 6 GB RAM, mniej na starszych urządzeniach. Naiwny wzorzec „wczytaj plik do ArrayBuffer, zaszyfruj, prześlij" zawiesza się na czymkolwiek powyżej 1 GB. Strumieniowanie jest obowiązkowe. Używaj File.slice() do odczytywania fragmentów 5 MB, szyfruj każdy podkluczem wyprowadzonym przez HKDF i przesyłaj przez fetch() z ciałem ReadableStream. Progresywne przesyłanie utrzymuje szczyt pamięci poniżej 50 MB nawet dla filmów 10 GB. Chrome na Androidzie obsługuje strumieniowe żądania fetch od wersji 105; Safari dodało pełne wsparcie w wersji 17.4.

Bateria i kwestie cieplne

AES-256-GCM jest tani sprzętowo — rozszerzenia kryptograficzne ARMv8 sprawiają, że działa prawie z prędkością DRAM. Szyfrowanie 1 GB na iPhone'ie 14 Pro zużywa ok. 2% baterii, głównie przez radio podczas przesyłania, nie przez CPU. Gdzie użytkownicy czują ciepło, to PBKDF2 przy wysokiej liczbie iteracji; 1,2 miliona iteracji (zalecenie OWASP 2024) zajmuje 700 ms i chwilowo podnosi A17 do 90°C. Zredukowanie do 600 000 iteracji równoważy bezpieczeństwo i termikę. Argon2id z m=32MB jest łagodniejszy dla trwałych obciążeń, bo memory-hardness jest wolniejsza, ale mniej energochłonna.

Komórkowe, Wi-Fi i niezawodność przesyłania

Mobilne przesyłania zawodzą. Tunel metra, winda, przełączenie z Wi-Fi na LTE — każde z nich kończy naiwne fetch(). Niezawodny mobilny transfer używa wznawianych przesyłań z potwierdzeniem na poziomie fragmentu, protokołów jak tus.io (specyfikacja tus 1.0, szeroko obsługiwana) lub wieloczęściowych przesyłań S3. Każdy fragment 5 MB przesyła się niezależnie; nieudany fragment jest wysyłany ponownie. Klient przechowuje stan fragmentów w IndexedDB, żeby przeładowanie zakładki przeglądarki lub eksmisja zakładki przez iOS nie restartowała całej pracy. SwissTransfer i HexaTransfer implementują wznawialne przesyłania; mobilny przepływ web WeTransfer tego nie robi — stąd przesyłania 2 GB przez LTE tam często kończą się niepowodzeniem.

Klawiatura i problem UX hasła

Wpisywanie 16-znakowego silnego hasła na klawiaturze telefonu to udręka. Oferuj alternatywy: skanowanie kodu QR zawierającego hasło z ekranu nadawcy, wklejanie z natywnego menedżera haseł (iOS wypełnia z Keychain przez odpowiedniki .well-known/apple-app-site-association dla web) lub użycie passkey zarejestrowanego podczas wcześniejszego transferu. Dla przypadków jednorazowych użyj Web Share Target API, żeby aplikacja towarzysząca (np. Signal) wstrzyknęła hasło bez konieczności ponownego wpisywania.

Dostępność i małe ekrany

iPhone SE 4,7 cala nie pomieści desktopowego interfejsu drag-and-drop. Mobilne interfejsy szyfrowania powinny uwzględniać viewport: pełnoekranowy selektor pliku, paski postępu widoczne nad miękką klawiaturą, etykiety VoiceOver na każdym przycisku (role="progressbar" z aria-valuenow dla dostępności) i minimalny cel dotykowy 44×44px zgodnie z wytycznymi Apple HIG. Nie ukrywaj kontrolek za stanami hover — na dotykowym nie ma hovera. Testuj z iOS Low Power Mode, który ogranicza timery w tle i psuje aktualizacje postępu oparte na pollingu.

Pułapki Safari na iOS

Safari na iOS ma kilka pułapek. Zdarzenia postępu przesyłania Fetch API nie wyzwalają się niezawodnie przed iOS 16.4. File System Access API nie jest obsługiwane, więc nie możesz strumieniować dużych plików z lokalnego magazynu tak jak Chrome. Safari agresywnie eksmituje nieaktywne zakładki pod presją pamięci, co kończy aktywne przesyłania. Środki zaradcze: użyj XMLHttpRequest ze zdarzeniami postępu jako fallback (nadal działa dobrze), utrzymuj zakładkę na pierwszym planie podczas przesyłania i ostrzeż użytkownika, by nie blokował ekranu dla dużych plików. Ekran włączony wyczerpuje baterię, ale zapobiega eksmisji zakładki.

Fragmentacja urządzeń Android

Android obejmuje urządzenia od Pixel 8 Pro do 80€ smartfonów Moto e14 z Android Go. Web Crypto działa na wszystkich, ale wydajność różni się znacznie — MT6762 przy 2 GHz potrzebuje 1,8 sekundy na 600 000 iteracji PBKDF2, gdzie smartfon klasy Apple M3 potrzebuje 200 ms. Wykrywaj urządzenie przez Device Memory API i Hardware Concurrency, skaluj liczbę iteracji odpowiednio (w dół do 300 000 dla urządzeń Go) i ostrzegaj użytkowników na połączeniach tylko komórkowych, że przesyłania powyżej 1 GB mogą być zawodne. Efekt: zaszyfrowany transfer działa na większości telefonów na świecie bez wymagania flagowca.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.