Architektura bezpieczeństwa
Jak naprawdę działają obietnice prywatności PDF Pro?
Wszystko na tej stronie można zweryfikować w panelu DevTools przeglądarki. Reguła główna: nie możemy mieć dostępu do Twoich plików — nawet gdybyśmy chcieli. Poniżej zobaczysz, jak ta zasada jest egzekwowana w warstwie kryptografii, magazynu i żądań.
memoryWebAssembly i JS w przeglądarce
lockAES-256-GCM
verifiedECDSA P-256
cloud_offMagazyn zero-knowledge
Cztery filary architektury
Naszą postawę bezpieczeństwa wyznaczają cztery decyzje techniczne. Egzekwuje je nie dokument polityki, lecz kod działający w Twojej przeglądarce.
1. Przetwarzanie najpierw lokalne
Wyświetlanie PDF-ów, adnotacje, wypełnianie formularzy, kompresja, łączenie, konwersja i podpisywanie odbywają się w całości w Twojej przeglądarce z użyciem WebAssembly i JavaScriptu. W przypadku tych narzędzi żadne dane plików nie opuszczają urządzenia — możesz to zweryfikować w karcie Sieć.
2. Klucze są generowane w przeglądarce
Gdy musisz udostępnić plik, klucz szyfrujący jest generowany w Twojej karcie przez Web Crypto API. Żyje w pamięci, we fragmencie URL, lub (w trybie hasła) jest wyprowadzany z hasła na urządzeniu odbiorcy za pomocą PBKDF2. Serwer nigdy go nie widzi.
3. Magazyn zero-knowledge
Przechowujemy wyłącznie szyfrogram AES-256-GCM oraz wektor inicjujący (a w trybie hasła także sól PBKDF2). Bez klucza dane te są kryptograficznie nieodróżnialne od losowych bajtów. Nawet pełny dostęp do bazy danych nie pomoże nam ich odszyfrować.
4. Uczciwa granica AI
Narzędzia AI (czat, streszczenie, tłumaczenie) potrzebują czytelnego tekstu. Tekst wyodrębniamy w przeglądarce i tylko jego treść wysyłamy do dostawcy modelu — nigdy samego pliku PDF, obrazów ani załączników. Szczegóły w sekcji AI poniżej.
Przepływ szyfrowania (Bezpieczny Transfer)
Bajt po bajcie: co dzieje się, gdy przeciągasz plik PDF do Bezpiecznego Transferu i udostępniasz link. Każdy z poniższych kroków działa 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 wyłącznie 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): żadna zgodna ze standardami przeglądarka nie wysyła # na serwer. Właśnie dlatego sam link pełni funkcję poświadczenia deszyfrującego.
Tryb hasła zastępuje krok 1 (nadawca) operacją PBKDF2-SHA256(passphrase, salt, 310_000). Sól przechowywana jest po stronie serwera; hasło przekazywane jest odbiorcy kanałem zewnętrznym.
Przepływ podpisu (ECDSA P-256)
Podpisywanie PDF wykorzystuje ECDSA na krzywej NIST P-256. Klucz prywatny jest generowany w Twojej przeglądarce; dokument nie opuszcza urządzenia.
Generowanie klucza prywatnego
Para kluczy ECDSA P-256 jest tworzona w Twojej przeglądarce przez
crypto.subtle.generateKey. Klucz prywatny eksportowany jest jako JSON Web Key (JWK) opakowany hasłem, który możesz przechowywać lokalnie.Skrót SHA-256 i podpis
Bajty PDF są w przeglądarce poddawane skrótowi SHA-256. Skrót zostaje podpisany kluczem prywatnym. Podpis trafia do PDF w kontenerze CMS (profil PAdES-B-B).
Weryfikowalny offline
Każdy, kto posiada klucz publiczny (dystrybuowany razem z dokumentem lub jako odcisk palca), może zweryfikować podpis offline. Nie potrzeba kontaktu z serwerem.
Czym to nie jest
Nasze podpisy są weryfikowalne kryptograficznie, ale nie są kwalifikowanym podpisem elektronicznym (QES) w rozumieniu eIDAS. Stanowią odporne na manipulacje dowody integralności odpowiednie do wewnętrznych procesów; nie zapewniają wiążącej mocy prawnej na poziomie regulacyjnym.
Funkcje AI — gdzie szczerze przyznajemy granice
AI Chat, AI Summary i Translate potrzebują czytelnego tekstu. Oto, co dokładnie opuszcza Twoje urządzenie, a co nie.
Tekst wyodrębniany jest w przeglądarce
PDF jest parsowany lokalnie przez pdf.js. W pamięci pozostaje wyłącznie wyodrębniony tekst (lub wynik OCR w przypadku skanowanych PDF) — oryginalny plik nie opuszcza urządzenia.
Do dostawcy trafia wyłącznie tekst
Ten ciąg tekstowy wysyłamy do dostawcy AI (Anthropic / OpenAI). Sam plik PDF, osadzone obrazy, fonty i dane formularzy nigdy nie są przekazywane do żadnego modelu AI.
Brak treningu na Twoich danych
Nasze umowy z dostawcami wyłączają trenowanie na treściach klientów. Żądania są bezstanowe — każde zamknięte w obrębie Twojej sesji.
Kiedy ma to znaczenie
Jeśli Twój dokument zawiera treści regulowane (PHI, poufne, objęte tajemnicą zawodową), w których nawet sama ekstrakcja tekstu jest wrażliwa, nie korzystaj z funkcji AI — używaj narzędzi lokalnych (podgląd, adnotacje, podpis, kompresja, konwersja) — te działają w 100% w przeglądarce.
Model zagrożeń — przed czym chronimy, a przed czym nie możemy
Jasność co do modelu zagrożeń jest pożyteczniejsza niż marketing. Oto, co architektura faktycznie zatrzymuje — i gdzie się kończy.
shieldPrzed czym chroni architektura
- Odczytaniem Twoich plików przez personel PDF Pro na naszych serwerach (nigdy nie posiadamy klucza).
- Naruszeniem bazy danych magazynu transferu (atakujący widzi szyfrogram, nie pliki).
- Ujawnieniem zawartości plików na żądanie sądu (przekażemy szyfrogram — to jedyne, co posiadamy).
- Przechowywaniem wrażliwych załączników na serwerze pocztowym (nic nie trafia do Twojej skrzynki).
- Manipulacją podpisanym plikiem PDF (weryfikacja podpisu ECDSA wykrywa każdą zmianę bajtu).
warningPrzed czym żadne narzędzie przeglądarkowe nie chroni
- Skompromitowane urządzenie końcowe (złośliwe oprogramowanie na Twoim komputerze) — klucze żyją w pamięci urządzenia, któremu trzeba ufać.
- Podejrzenie fragmentu URL przez kogoś za Twoimi plecami — traktuj link do udostępniania jak sam plik.
- Słabe hasło w trybie hasła — PBKDF2 spowalnia ataki brute-force, ale nie zabezpieczy 6-znakowego hasła.
- Przekazanie odszyfrowanego pliku przez odbiorcę — bezpieczeństwo transferu kończy się w chwili, gdy odbiorca zapisze PDF.
- Skompromitowanie samej przeglądarki lub złośliwe rozszerzenie wstrzykujące kod do strony.
Nie obiecujemy, że jesteśmy „nie do złamania". Architektura zero-knowledge znacząco podnosi koszt naruszenia — ale nie eliminuje całego ryzyka, zwłaszcza po stronie urządzenia końcowego. W najbardziej wrażliwych przypadkach łącz Bezpieczny Transfer z odrębnym hasłem i wymianą klucza zaufanym kanałem.
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 przypadku Bezpiecznego Transferu 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 są w stanie odszyfrować Twojego pliku.
Co działa lokalnie, a co po stronie serwera?
Wyświetlanie, adnotacje, wypełnianie formularzy, kompresja, łączenie, konwersja i podpisywanie działają w 100% w Twojej przeglądarce z użyciem WebAssembly i JavaScriptu — żadne dane plików nie opuszczają urządzenia. Funkcje AI (czat, streszczenie, tłumaczenie) wyodrębniają 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 iteracji do kluczy wyprowadzanych z hasła, ECDSA na krzywej NIST P-256 do podpisów cyfrowych oraz SHA-256 do skrótu dokumentu. Wszystko to działa przez natywne Web Crypto API przeglądarki — poddane audytom, ustandaryzowane i nie zaimplementowane przez nas.
Czy to prawnie wiążący podpis elektroniczny?
Podpisy PDF Pro są weryfikowalne kryptograficznie (ECDSA P-256 na skrócie SHA-256, profil PAdES-B-B), lecz nie są kwalifikowanym podpisem elektronicznym (QES) w rozumieniu eIDAS ani regulacji równoważnych. Wiążącość prawna na poziomie QES wymaga certyfikowanego dostawcy usług zaufania.
Co się stanie, gdy zapomnę hasła lub stracę link do udostępniania?
Plik jest trwale nieodzyskiwalny. To cena modelu zero-knowledge — nie ma ścieżki odzyskiwania, ponieważ nigdy nie posiadaliśmy klucza. Zapisz hasło w menedżerze haseł, a link przechowuj w trwałym miejscu.
Czy prowadzicie dzienniki aktywności plików po stronie serwera?
Prowadzimy dzienniki operacyjne (znaczniki czasu żądań, kody błędów, adresy IP do ograniczania liczby żądań), ale nigdy nie przechowujemy zawartości plików w postaci jawnej ani kluczy szyfrujących. Dzienniki przechowywane są 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 wydać tylko to, co posiadamy: szyfrogram. Bez klucza deszyfrującego — który pozostaje na urządzeniu nadawcy lub we fragmencie URL przechowywanym przez odbiorcę — szyfrogram pozostaje nieczytelny. Wezwanie sądowe nie odtworzy retroaktywnie klucza, którego nigdy nie przechowywaliśmy.
Jak samodzielnie mogę zweryfikować deklaracje kryptograficzne?
Otwórz DevTools → kartę Sieć w przeglądarce i obserwuj, co opuszcza stronę podczas wysyłki Bezpiecznego Transferu. Zobaczysz, że na serwer trafia metodą PUT szyfrogram, a nie oryginalny PDF. Kod szyfrujący wywołuje Web Crypto API wbudowane w przeglądarkę — nie nasz kod — i każdy może je zbadać.
Prywatność jako architektura, nie jako marketing.
Wypróbuj Bezpieczny Transfer i samodzielnie sprawdź kartę Sieć. Żaden plik nie zostanie wysłany jako jawny tekst.
lockWypróbuj Bezpieczny Transfer