Architektura bezpieczeństwa
Jak naprawdę działają deklaracje prywatności PDF Pro.
Wszystko na tej stronie można zweryfikować w DevTools Twojej przeglądarki. Główna zasada: nie powinniśmy mieć możliwości dostępu do Twoich plików — nawet gdybyśmy chcieli. Poniżej opisano, jak ta zasada jest egzekwowana na warstwie kryptografii, przechowywania i żądań.
memoryWebAssembly i JS po stronie klienta
lockAES-256-GCM
verifiedECDSA P-256
cloud_offSzyfrowane przechowywanie po stronie klienta
Cztery filary architektoniczne
Cztery techniczne decyzje definiują postawę bezpieczeństwa. Są egzekwowane przez kod uruchamiany w Twojej przeglądarce — a nie przez dokument polityki.
1. Przetwarzanie lokalne w pierwszej kolejności
Przeglądanie, dodawanie adnotacji, wypełnianie formularzy, kompresja, łączenie, konwersja i podpisywanie plików PDF są wykonywane w całości w Twojej przeglądarce za pomocą WebAssembly i JavaScript. W tych narzędziach żadne dane pliku nie opuszczają urządzenia — można to zweryfikować w karcie Sieć.
2. Klucze generowane po stronie klienta
Gdy musisz udostępnić plik, klucz szyfrujący jest generowany przez Web Crypto API w Twojej karcie. Pozostaje w pamięci, we fragmencie URL lub (w trybie hasła) jest wyprowadzany na urządzeniu odbiorcy za pomocą PBKDF2. Serwer nigdy go nie widzi.
3. Szyfrowane przechowywanie po stronie klienta
Przechowywany jest wyłącznie szyfrogram AES-256-GCM wraz z wektorem inicjującym (a w trybie hasła także sól PBKDF2). Bez klucza dane te są kryptograficznie nieodróżnialne od losowych bajtów. Nawet rootowy dostęp do bazy danych nie pomógłby nam ich odszyfrować.
4. Uczciwa granica AI
Narzędzia AI (czat, podsumowanie, tłumaczenie) potrzebują czytelnego tekstu. Ekstrahujemy tekst po stronie klienta i wysyłamy do dostawcy modelu wyłącznie ten tekst — nigdy samego pliku PDF, obrazów ani osadzonych załączników. Pełne szczegóły w sekcji AI poniżej.
Przepływ szyfrowania (Bezpieczny transfer)
Krok po kroku — bajt po bajcie — co dzieje się, gdy upuszczasz PDF w Bezpiecznym transferze i udostępniasz wygenerowany link. Każdy krok poniżej wykonuje się w przeglądarce, z wyjątkiem przechowywania szyfrogramu.
Nadawca — w przeglądarce
// 1. generate a fresh 256-bit key
key = crypto.subtle.generateKey({name:"AES-GCM", length:256})
// 2. random 96-bit IV per file
iv = crypto.getRandomValues(new Uint8Array(12))
// 3. encrypt the PDF bytes locally
ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes)
// 4. upload ciphertext + iv — nothing else
id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}})
// 5. build the share link with the key in the URL fragment (#)
link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
Serwer — przechowuje tylko szyfrogram
ciphertext = opaque bytes // cannot be decrypted without the key
iv = 12-byte nonce
expiry = 24 h (free) / 30 d (Pro)
// the URL fragment (#...) is NEVER sent to the server by browsers
▼
Odbiorca — w przeglądarce
// 1. browser loads the page; the "#..." fragment stays client-side
rawKey = location.hash.slice(1)
// 2. fetch the ciphertext
ct = await fetch("/api/transfer/" + id)
// 3. decrypt locally using Web Crypto
pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct)
// 4. file ends up in the recipient's Downloads folder
Gwarancja bezpieczeństwa opiera się na kroku 5 (nadawca) i kroku 1 (odbiorca): fragment URL po znaku # nie jest przesyłany do serwera przez żadną zgodną ze standardem przeglądarkę. To właśnie sprawia, że sam link staje się poświadczeniem deszyfrującym.
Tryb hasła zastępuje krok 1 (nadawca) operacją PBKDF2-SHA256(hasło, sól, 310_000). Sól jest przechowywana po stronie serwera; hasło jest przekazywane odbiorcy poza pasmem.
Przepływ podpisywania (ECDSA P-256)
Podpisywanie PDF wykorzystuje ECDSA na krzywej NIST P-256. Klucz prywatny jest generowany w Twojej przeglądarce; dokument nigdy nie opuszcza urządzenia.
Generowanie klucza prywatnego
Para kluczy ECDSA P-256 jest generowana w Twojej przeglądarce przez
crypto.subtle.generateKey. Klucz prywatny jest eksportowany do chronionego hasłem JSON Web Key (JWK), który możesz przechowywać lokalnie.Hash SHA-256 i podpisanie
Bajty PDF są hashowane SHA-256 po stronie klienta. Ten hash jest podpisywany kluczem prywatnym. Podpis jest osadzany w PDF w kontenerze CMS (profil PAdES-B-B).
Weryfikowalne offline
Każdy, kto ma klucz publiczny (dystrybuowany wraz z dokumentem lub jako odcisk palca), może zweryfikować podpis offline. Komunikacja z serwerem nie jest wymagana.
Czym to nie jest
Nasze podpisy są weryfikowalne kryptograficznie, ale nie są kwalifikowanymi podpisami elektronicznymi (QES) w rozumieniu eIDAS. To dowody integralności z wykrywaniem manipulacji, odpowiednie dla wewnętrznych procesów, a nie dla wiążącej mocy prawnej na poziomie regulacyjnym.
Funkcje AI — gdzie jesteśmy szczerzy co do granicy
AI Chat, Podsumowanie AI i Tłumaczenie wymagają czytelnego tekstu. Oto co dokładnie opuszcza Twoje urządzenie, a co nie.
Tekst ekstrahowany w przeglądarce
PDF jest parsowany lokalnie przez pdf.js. W pamięci pozostaje wyłącznie wyekstrahowany tekst (a dla zeskanowanych PDF — wynik OCR); plik źródłowy pozostaje na Twoim urządzeniu.
Do dostawcy trafia tylko tekst
Wysyłamy ten ciąg tekstowy do dostawcy AI (Anthropic / OpenAI). Sam PDF, osadzone obrazy, czcionki i dane formularzy nigdy nie są przesyłane do żadnego modelu AI.
Brak trenowania na Twoich treściach
Nasze umowy z dostawcami wyłączają trenowanie na treściach klientów. Żądania są bezstanowe — każde ograniczone do Twojej sesji.
Kiedy to ma znaczenie
Jeśli dokument zawiera treści regulowane (PHI, niejawne, objęte tajemnicą zawodową), w których nawet ekstrakcja tekstu jest wrażliwa, pomiń funkcje AI i użyj narzędzi lokalnych (podgląd, adnotacje, podpis, kompresja, konwersja) — działają w 100 % w przeglądarce.
Model zagrożeń — przed czym chronimy, a czego nie możemy zatrzymać
Jasność co do modelu zagrożeń jest bardziej pożyteczna niż marketing. Oto co architektura faktycznie zatrzymuje i gdzie się zatrzymuje.
shieldPrzed czym chroni architektura
- Pracowników PDF Pro czytających Twoje pliki na naszych serwerach (nigdy nie posiadamy klucza).
- Naruszenia na poziomie bazy danych magazynu transferu (atakujący widzi szyfrogram, nie pliki).
- Sądowego nakazu ujawnienia treści plików (możemy przekazać szyfrogram — to wszystko, co posiadamy).
- Przechowywania wrażliwych załączników przez serwer pocztowy (nic nie trafia na Twój serwer pocztowy).
- Modyfikacji podpisanego PDF (weryfikacja podpisu ECDSA wykryje każdą zmianę bajtu).
warningPrzed czym żadne narzędzie przeglądarkowe nie może obronić
- Skompromitowanego punktu końcowego (złośliwe oprogramowanie na Twoim urządzeniu) — klucze znajdują się w pamięci urządzenia, któremu trzeba ufać.
- Podglądania fragmentu URL przez ramię — traktuj link udostępniający jak sam plik.
- Słabego hasła w trybie hasła — PBKDF2 spowalnia brute force, ale nie czyni bezpiecznym hasła 6-znakowego.
- Przekazania przez odbiorcę odszyfrowanego pliku — bezpieczeństwo transportu kończy się, gdy odbiorca zapisze PDF.
- Kompromitacji samej przeglądarki lub złośliwego rozszerzenia wstrzykującego kod na stronę.
Żadnych deklaracji o „niemożliwości włamania". Szyfrowanie end-to-end znacząco podnosi koszt naruszenia — nie eliminuje całego ryzyka, zwłaszcza po stronie urządzenia. W najbardziej wrażliwych przypadkach połącz Bezpieczny transfer z osobnym hasłem i wymianą klucza przez zaufany kanał.
Powiązane lektury
Najczęściej zadawane pytania
Czy PDF Pro może odszyfrować moje pliki?
Nie. Klucze szyfrujące są generowane i przechowywane w przeglądarce użytkownika. W Bezpiecznym transferze serwer przechowuje wyłącznie szyfrogram AES-256-GCM oraz wektor inicjujący (a w trybie hasła także sól). Klucz nigdy nie trafia do naszej infrastruktury. Nawet z pełnym dostępem do bazy danych nasi operatorzy nie odszyfrują Twojego pliku.
Co dokładnie działa lokalnie, a co na serwerze?
Przeglądanie, adnotacje, wypełnianie formularzy, kompresja, łączenie, konwersja i podpisywanie działają w 100 % w przeglądarce dzięki WebAssembly i JavaScript — żadne dane plików nie opuszczają urządzenia. Funkcje AI (czat, podsumowanie, tłumaczenie) ekstrahują tekst lokalnie i wysyłają do dostawcy modelu wyłącznie ten tekst (nigdy samego PDF).
Jakich algorytmów używa PDF Pro?
AES-256-GCM do szyfrowania symetrycznego (Bezpieczny transfer), PBKDF2-SHA256 z 310 000 iteracjami dla kluczy wyprowadzanych z hasła, ECDSA na NIST P-256 do podpisów cyfrowych oraz SHA-256 do haszowania dokumentów. Wszystko to działa za pośrednictwem natywnego Web Crypto API przeglądarki, które jest audytowane, ustandaryzowane i nie zostało napisane przez nas.
Czy to jest prawnie wiążący podpis elektroniczny?
Podpisy PDF Pro są weryfikowalne kryptograficznie (ECDSA P-256 na haszu SHA-256, profil PAdES-B-B), ale nie są kwalifikowanymi podpisami elektronicznymi (QES) w rozumieniu eIDAS lub równoważnych regulacji. Dla mocy prawnej na poziomie QES wymagany jest certyfikowany kwalifikowany dostawca usług zaufania.
Co się stanie, jeśli zapomnę hasła lub stracę link?
Plik staje się trwale nieodzyskiwalny. To kompromis szyfrowania end-to-end — nie ma ścieżki odzyskania, ponieważ nigdy nie posiadaliśmy klucza. Zapisz hasło w menedżerze haseł, a link w trwałym miejscu.
Czy prowadzicie po stronie serwera dzienniki aktywności plików?
Prowadzimy dzienniki operacyjne (czasy żądań, kody błędów, adresy IP do limitowania), ale nigdy nie zawartość plików w postaci jawnej ani kluczy szyfrujących. Dzienniki są przechowywane przez krótki czas — aktualne okresy retencji znajdziesz w naszej polityce prywatności.
Czy nakaz sądowy może zmusić was do ujawnienia moich plików?
Możemy przekazać tylko to, co mamy: szyfrogram. Bez klucza deszyfrującego — który pozostaje na urządzeniu nadawcy lub we fragmencie URL trzymanym przez odbiorcę — szyfrogramu nie da się odszyfrować. Wezwanie sądowe nie odzyska wstecznie klucza, którego nigdy nie przechowywaliśmy.
Gdzie mogę samodzielnie zweryfikować twierdzenia kryptograficzne?
Otwórz DevTools przeglądarki → kartę Sieć i obserwuj, co opuszcza stronę podczas uploadu w Bezpiecznym transferze. Zobaczysz szyfrogram wysyłany metodą PUT do serwera, a nie oryginalny PDF. Kod szyfrujący wywołuje Web Crypto API, wbudowane w Twoją przeglądarkę — to nie nasz kod — i każdy może je zweryfikować.
Prywatność jako architektura, a nie marketing.
Wypróbuj Bezpieczny transfer i sam sprawdź kartę Sieć. Żadne pliki nie są nigdy przesyłane jawnie.
lockWypróbuj Bezpieczny transfer