Bezpieczeństwo i prywatność
Przystępne podsumowanie sposobu, w jaki encrypt.click obchodzi się z Twoimi danymi. Ma charakter wyłącznie informacyjny i nie stanowi porady prawnej.
Bez kont, bez logowania
encrypt.click nie ma kont użytkowników, logowań ani profili. Nie musisz się rejestrować ani podawać danych osobowych, żeby korzystać z narzędzi.
Narzędzia w przeglądarce
Narzędzia do ochrony prywatności (słowa AES, kapsuła czasu, steganografia, szyfr fotograficzny i szyfr spektralny) działają w przeglądarce za pomocą Web Crypto i innych lokalnych API. Ich dane wejściowe nie są wysyłane do encrypt.click w celu przetworzenia.
Gdy narzędzie pobiera na Twoje żądanie dane publiczne (np. losowość drand dla Kapsuły czasu przez nasze proxy w tej samej domenie), żądanie nie zawiera haseł ani poufnych danych w postaci jawnej.
Szyfrowane udostępnianie wiadomości i plików
Encrypt & share uruchamia AES-GCM w przeglądarce zanim cokolwiek zostanie wysłane. Hasło zostaje na Twoim urządzeniu, dopóki sam go nie skopiujesz lub nie wyślesz.
Automatyczny upload preferuje first-party magazyn ciphertextu (/upload w tym serwisie). Ta ścieżka ma limit ok. 90 MB i miesięczny budżet, a dostępność jest gwarantowana przez ok. 24 godziny. Gdy jest pełna lub niedostępna, najpierw pytamy; jeśli się zgodzisz, przeglądarka wysyła tylko ciphertext do API uploadu encrypt.click, które serwerowo przekazuje go tymczasowym hostom zgodnym z Send (pliki do 50 MB). Te hosty powinny widzieć ciphertext i egress serwera - nie bezpośredni upload plaintextu z przeglądarki.
Odbiorcy otwierają linki na encrypt.click (często /u). Materiał szyfrowany może być we fragmencie URL (przy zwykłym ładowaniu strony nie jest wysyłany na nasze serwery) albo wskazywać na wgrany ciphertext. Opcjonalne opakowanie PNG może ukryć link share w obrazku do przekazania offline.
Przesyłanie jest darmowe, dlatego sprawdzamy użycie zautomatyzowane lub nietypowo intensywne. Zwykłe przesyłanie przechodzi bez dodatkowych kroków; gdy przesyłanie wygląda na zautomatyzowane albo urządzenie przesłało dużo danych, przeglądarka musi najpierw rozwiązać krótkie zadanie obliczeniowe (proof-of-work). Działa ono na Twoim urządzeniu i nie bierze w nim udziału żadna strona trzecia. Każde kolejne zadanie w ciągu godziny trwa dwa razy dłużej, a rozwiązane pozwala urządzeniu przez godzinę dalej przesyłać pliki, w ramach tych samych stałych dziennych limitów.
Szyfrowany chat, rozmowy, whiteboard i pliki
Wiadomości czatu, wskaźniki pisania i sygnalizacja rozmów są szyfrowane w przeglądarce (AES-GCM) zanim dotrą do relay. Relay przekazuje ciphertext i nie przechowuje historii czatu, z wyjątkiem zapisanych pokoi, gdzie trzyma zaszyfrowane wiadomości (najwyżej 1000 na pokój, w Unii Europejskiej), dopóki któryś z członków nie usunie pokoju albo minie 90 dni bez wizyt. W pokojach bez historii na serwerze wiadomości mają dodatkowo utajnianie z wyprzedzeniem: klucz wysyłania każdego członka przesuwa się z każdą wiadomością i trafia do innych tylko pod kluczami z krótkotrwałych par kluczy, które nigdy nie są zapisywane, więc nagrany ruch pozostaje zamknięty nawet dla kogoś, kto później pozna hasło.
Rozmowy na żywo używają WebRTC z polityką ICE TURN-only, żeby IP uczestników nie były wymieniane bezpośrednio. Oprócz DTLS-SRTP każda ramka dźwięku i obrazu jest szyfrowana end-to-end w przeglądarce algorytmem AES-256-GCM (insertable streams na wzór SFrame, wideo w VP8 lub VP9). Klucz mediów każdego nadawcy jest losowy, wędruje tylko wewnątrz szyfrowanego i podpisanego kanału pokoju, dla każdego odbiorcy jest dodatkowo zapieczętowany efemerycznym kluczem ECDH P-256 i jest wymieniany za każdym razem, gdy ktoś opuszcza rozmowę. Ponieważ klucze mediów nigdy nie przechodzą przez handshake DTLS, nagranie dziś ruchu rozmowy i złamanie tego handshake'u później, na przykład komputerem kwantowym, nie odsłania mediów nikomu, kto nie zna sekretu pokoju. Przeglądarki bez szyfrowania ramek nie mogą dołączać do rozmów. Poświadczenia TURN pochodzą z encrypt.click (/api/turn).
Załączniki w czacie są szyfrowane w przeglądarce przed wysłaniem, tak samo jak w Encrypt & share. Trafiają do naszego własnego magazynu i są usuwane po 24 godzinach, także w zapisanych pokojach. Gdy nasz magazyn jest niedostępny, zaszyfrowany plik trafia zamiast tego do publicznej instancji Send w UE, gdzie może zostać do 7 dni.
Nowe pokoje zawsze wymagają hasła o długości co najmniej 16 znaków, które przejdzie kontrolę siły, i można je tworzyć tylko przez formularz. Hasło nigdy nie jest częścią linku, więc przekaż je osobno.
Whiteboard używa tej samej infrastruktury realtime do wspólnych kresek i stanu. Traktuj dostęp jak w czacie: do wrażliwych rzeczy użyj silnego hasła.
Zapisane pokoje używają losowego klucza przenoszonego we fragmencie linku, który nigdy nie dociera do serwera. W każdym pokoju każda wiadomość jest podpisywana w przeglądarce kluczem właściwym dla pokoju, dzięki czemu pozostali członkowie zauważą, gdy nazwa pojawi się z innym kluczem, a tryb wiadomości jest związany z kluczem pokoju, więc serwer nie może go zmienić. Zapisane pokoje dodają do każdej wiadomości podpis ML-DSA-44 i łączą zapisane wiadomości każdego autora w łańcuch, więc przeglądarki zauważą, gdy serwer pominie, przestawi lub zatrzyma wiadomości.
Skracanie linków
Po zaszyfrowaniu przeglądarka wysyła link do /api/shorten w encrypt.click, który skraca go naszą własną usługą l.encrypt.click. Nie korzystamy z zewnętrznych skracaczy. Jeśli skracanie się nie uda, dostaniesz pełny link.
Krótki link przechowuje pełny link razem z zaszyfrowaną treścią, ale nigdy hasła. Kto ma krótki link, nadal potrzebuje hasła, dlatego użyj wygenerowanej frazy lub innego silnego hasła.
Krótki link tworzy się automatycznie, więc zaszyfrowana treść każdego udostępnienia trafia na l.encrypt.click niezależnie od tego, który link ostatecznie wyślesz. Pełny link przenosi treść we fragmencie adresu URL, którego przeglądarka odbiorcy nigdy nie wysyła na serwer.
Pliki cookie i pamięć lokalna
Strona ustawia jedno funkcjonalne ciasteczko, ec-lang, i to dopiero wtedy, gdy wybierzesz język w menu. Zawiera wyłącznie dwuliterowy kod języka, nic więcej, jest ważne przez rok i nie służy do śledzenia. Pierwsza wizyta bez niego jest wyświetlana w języku przeglądarki. Przeglądarka może używać localStorage do motywu oraz, tam gdzie historia czatu jest zachowywana, do zaszyfrowanych wiadomości, a w zapisanych pokojach także do zapamiętania, dokąd sprawdzono historię każdego członka. Pamięć sesji może przez chwilę przechowywać hasło pokoju podczas dołączania, a klucz pokoju, który przyszedł w linku, trzyma tak długo, jak otwarta jest dana karta, aby klucz mógł zniknąć z paska adresu. IndexedDB przechowuje klucz podpisu, który przeglądarka tworzy dla każdego pokoju czatu i każdej tablicy, a dla zapisanych pokoi także ziarno postkwantowego klucza podpisu, zapieczętowane kluczem wyprowadzonym z linku pokoju; klucze prywatne nigdy nie opuszczają urządzenia.
Cloudflare, jako dostawca hostingu, może zależnie od ruchu i ustawień przeglądarki ustawiać pliki cookie związane z bezpieczeństwem i ochroną przed nadużyciami, zgodnie z własnymi zasadami.
Bezpieczeństwo sieci i transportu
- Cały ruch idzie przez HTTPS z nowoczesnym TLS.
- HTTP Strict Transport Security (HSTS) jest włączone z includeSubDomains i preload.
- Content Security Policy (CSP) ogranicza skrypty, style, fonty i połączenia; zamiast szerokiego unsafe-inline dla skryptów używane są hashe skryptów inline.
- Osadzanie w iframe jest wyłączone przez frame-ancestors 'none' i X-Frame-Options: DENY.
- Kontrola porównuje nowo pobrane pliki z manifestem tego samego serwera. Nie potwierdza autentyczności kodu uruchomionego w przeglądarce ani nie chroni przed przejętym hostingiem.
Infrastruktura stron trzecich
Strona działa na Cloudflare Workers. Czat i tablica w czasie rzeczywistym są przekazywane przez Durable Objects w tym samym Workerze (PartyServer). Przekazywanie połączeń może wykorzystywać Cloudflare TURN lub innych skonfigurowanych dostawców TURN. Gdy własna usługa przesyłania jest niedostępna, tymczasowe serwery przechowujące szyfrogramy (instancje zgodne z Send) mogą otrzymać zaszyfrowane dane.
encrypt.click nie prowadzi własnej bazy danych zawierającej dane wejściowe narzędzi. Ochrona API przed nadużyciami wykorzystuje przechowywany w pamięci, solony skrót adresu IP o krótkim czasie życia (około 60 sekund). Cloudflare może również stosować własne mechanizmy ochrony przed botami i żądania weryfikacyjne.
Odpowiedzialne zgłaszanie
Jeśli uważasz, że znalazłeś problem bezpieczeństwa lub prywatności w encrypt.click, napisz na mail@encrypt.click. Podaj dość szczegółów do odtworzenia i unikaj testów, które mogłyby zaszkodzić innym użytkownikom.
Podsumowanie o charakterze nieprawnym
Ta strona w przystępny sposób podsumowuje, jak encrypt.click obchodzi się z danymi. Nie jest umową ani pełnym regulaminem. Nie udzielamy gwarancji pełnego bezpieczeństwa; korzystasz z narzędzi na własne ryzyko.