Fluera

Architektura

Jak Fluera dba o bezpieczeństwo Twoich notatników.

Ta strona opisuje model bezpieczeństwa na poziomie, jakiego oczekuje czytelnik techniczny — oficer bezpieczeństwa, CISO uniwersytetu, ciekawy deweloper. Streszczenie nietechniczne zacznij od /pl/security.

Model zagrożeń

Zakładamy kradzież urządzenia, przechwycenie ruchu sieciowego oraz przypadkowe ujawnienie przez kopie zapasowe lub synchronizację w chmurze. Zakładamy, że poświadczenia użytkownika mogą zostać przejęte. Nie zakładamy przeciwników na poziomie państwowym z fizycznym dostępem do odblokowanych urządzeń — Fluera nie jest narzędziem do prywatności, jest narzędziem do nauki.

W ramach tego modelu trzy gwarancje:

  • Lokalne dane są nieczytelne bez klucza. Skradzione urządzenie produkuje zaszyfrowany blob.
  • Synchronizowane dane są szyfrowane w tranzycie i w spoczynku. Sync w chmurze nie jest end-to-end: dane przechowujemy na infrastrukturze UE (Supabase, eu-north-1). Jako administrator danych mamy do nich techniczny dostęp — nigdy ich nie sprzedajemy ani nie używamy do reklam.
  • Telemetria jest opt-in i zdeidentyfikowana. Nawet w przypadku pełnego naruszenia analityka nie może powiązać użytkownika z jego treścią.

W spoczynku: SQLCipher, AES-256

Każdy notatnik Fluery żyje w lokalnej bazie SQLite zaszyfrowanej za pomocą SQLCipher — szeroko zwalidowanego rozszerzenia, które przezroczyście szyfruje każdą stronę bazy danych za pomocą AES-256-CBC i przeprowadza kontrolę integralności HMAC-SHA512 na każdej stronie.

Wyprowadzanie klucza używa PBKDF2 z SHA-256, 256 000 iteracji (zgodnie z OWASP). Hasło jest przechowywane w pęku kluczy platformy — Keychain na iOS/macOS, Keystore na Androidzie, DPAPI na Windows, libsecret na Linuksie. Nigdy nie jest wysyłane na nasze serwery.

W tranzycie: TLS 1.3

Cały ruch sieciowy to TLS 1.3 z nowoczesnymi zestawami szyfrów.

Między urządzeniami: synchronizacja w chmurze UE

Gdy aktywna, synchronizacja w chmurze przesyła dane szyfrowane w tranzycie (TLS) i przechowuje je zaszyfrowane w spoczynku na infrastrukturze UE (Supabase, region eu-north-1). Synchronizacja nie jest end-to-end: jako administrator danych mamy do treści techniczny dostęp. Nigdy jej nie sprzedajemy ani nie używamy do reklam. Synchronizacja jest opt-in dla notatnika — możesz zachować niektóre tylko lokalnie, a inne synchronizować.

Współpraca P2P: bezpośrednia, szyfrowana

Współpraca w czasie rzeczywistym używa WebRTC DataChannel z szyfrowaniem DTLS-SRTP. Supabase Realtime działa tylko jako broker sygnalizacji — konfiguracja połączenia — a nie jako przekaźnik dla rzeczywistego ruchu kanwy. Po uzgodnieniu edycje kanwy płyną P2P. Serwer ich nie widzi.

Wywołania AI: w UE, przez proxy

Wywołania do modeli Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) są obsługiwane przez Google Vertex AI i przetwarzane w UE (europe-west4 NL / europe-west1 BE), przez nasze proxy, które trzyma poświadczenia po stronie serwera. Urządzenia klienckie nigdy nie widzą klucza. Proxy egzekwuje limity per-plan i loguje czas trwania wywołań do rachunkowości — nigdy treści kanwy.

Telemetria: opt-in, hashowana, na liście dozwolonych

Analityka produktu jest domyślnie wyłączona. Gdy aktywna, zdarzenia są ograniczone do białej listy po stronie serwera (start/koniec sesji, wywołanie funkcji, czas trwania wywołania AI — nigdy treść). ID użytkownika jest hashem SHA-256 na urządzeniu; ID w postaci zwykłego tekstu nigdy nie opuszcza klienta. Zdarzenia są przechowywane przez 180 dni, potem agregowane lub usuwane.

Dziennik audytu (konta instytucjonalne)

Każdy dostęp do współdzielonych notatników — kto, z którego urządzenia, kiedy — jest zapisywany w dzienniku audytu append-only. Administratorzy mogą eksportować logi do CSV lub JSON do audytów zgodności. Logi są zapisywane raz: usunięcie wymaga udokumentowanego powodu i samo zostaje zarejestrowane.

Odzyskiwanie i utrata klucza

Jeśli stracisz hasło, zaszyfrowane dane stają się nie do odzyskania. Jest to celowe — alternatywa byłaby ścieżką odzyskiwania, która z konieczności osłabiłaby model szyfrowania. Dla kont instytucjonalnych można skonfigurować opcjonalny klucz odzyskiwania trzymany przez administratora; jest to udokumentowany kompromis, który instytucja świadomie wybiera.

Odpowiedzialne ujawnianie

Badacze bezpieczeństwa są mile widziani. Zgłaszaj podatności na lorenco@fluera.dev z szyfrowaniem PGP (klucz opublikowany na profilu GitHub). Potwierdzamy w ciągu 24 godzin, łatamy krytyczne problemy w ciągu 72 i wymieniamy zgłaszających w hall of fame, chyba że wolą pozostać anonimowi.

Zakres: aplikacja Fluera (wszystkie platformy), usługa synchronizacji, proxy AI i ta strona marketingowa. Poza zakresem: usługi stron trzecich (Supabase, Google, Apple, Sentry, RevenueCat) — zgłaszaj odpowiednim dostawcom.

Oceny zewnętrzne

Fluera obecnie nie ma certyfikacji SOC 2 ani ISO 27001. Są one na planie rozwoju Enterprise i zostaną publicznie ogłoszone po ukończeniu. Wolimy nie deklarować kontroli, których nie zweryfikowaliśmy niezależnie.

Lista podwykonawców jest publiczna i aktualna. Umowa o przetwarzaniu danych dostępna na żądanie pod lorenco@fluera.dev.