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 programistyczne i narzędzia do ochrony prywatności (m.in. obliczanie skrótów, generowanie kluczy, kodowanie i lokalne funkcje pomocnicze) 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.encrypt.click). Ta ścieżka ma limit (ok. 50 MB), a dostępność jest gwarantowana przez ok. 24 godziny. Gdy zawiedzie, przeglądarka wysyła tylko ciphertext do API uploadu encrypt.click, które może serwerowo przekazać go tymczasowym hostom zgodnym z Send. 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.

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 PartyKit. Relay przekazuje ciphertext i nie przechowuje historii czatu.

Rozmowy na żywo używają WebRTC z polityką ICE TURN-only, żeby IP uczestników nie były wymieniane bezpośrednio. Media chroni DTLS-SRTP między uczestnikami; TURN tylko przekazuje zaszyfrowane pakiety. Poświadczenia TURN pochodzą z encrypt.click (/api/turn).

Załączniki w czacie są szyfrowane po stronie klienta przed uploadem, tym samym podejściem ciphertext-first co Encrypt & share (magazyn first-party gdy dostępny; w przeciwnym razie tylko serwerowy relay ciphertextu).

Bez hasła pokoju klucz jest wyprowadzany tylko z nazwy pokoju. Ktokolwiek odgadnie nazwę, może dołączyć i odszyfrować. Relay nadal widzi obecność i metadane czasowe, nawet gdy payloady są zaszyfrowane.

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.

Opcjonalne skracanie URL

Gdy skracasz link do udostępniania, przeglądarka wywołuje punkt końcowy /api/shorten w encrypt.click. Następnie backend wysyła żądanie do wybranego serwisu skracającego adresy.

Serwis skracający otrzymuje pełny skracany adres URL. W przypadku zaszyfrowanych linków może on zawierać metadane zaszyfrowanego ładunku. Aby zapewnić maksymalną prywatność, nie korzystaj z zewnętrznych serwisów skracających w przypadku poufnych linków.

Udostępniane krótkie linki mogą pozostać w domenie encrypt.click. Po ich otwarciu encrypt.click może rozwiązać skrócony adres po stronie serwera i przekierować z powrotem do adresu encrypt.click. Dzięki temu serwis skracający widzi przede wszystkim infrastrukturę, a nie bezpośrednio przeglądarkę odwiedzającego, choć nadal może odnotować użycie danego zaszyfrowanego linku.

Pliki cookie i pamięć lokalna

Strona nie ustawia śledzących ani analitycznych plików cookie oraz nie korzysta z zewnętrznych mechanizmów śledzących ani pikseli reklamowych. Przeglądarka może używać localStorage do zapisywania preferencji (motywu i języka), a w czacie z lokalną historią także zaszyfrowanych kopert wiadomości na urządzeniu. sessionStorage może przez krótki czas przechowywać hasło pokoju podczas dołączania.

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.
  • Klientowa kontrola integralności wdrożenia porównuje załadowane assety builda z opublikowanym manifestem oraz, gdy to możliwe, z najnowszym commitem main na GitHubie.

Infrastruktura stron trzecich

Strona działa na Cloudflare Pages. Czat i tablica korzystają z PartyKit do komunikacji w czasie rzeczywistym. 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.