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ą nieczytelne dla nas. Chmura przechowuje tylko szyfrogram. Wyprowadzanie odbywa się na urządzeniu.
- 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, certificate pinning
Cały ruch sieciowy to TLS 1.3 z nowoczesnymi szyframi. Na iOS i Androidzie pinujemy certyfikaty do naszego łańcucha CA, by zapobiec atakom man-in-the-middle korporacyjnych proxy — z udokumentowanym obejściem dla administratorów sieci, którzy go potrzebują.
Między urządzeniami: szyfrowanie end-to-end
Gdy aktywna, synchronizacja w chmurze używa odrębnego zestawu kluczy wyprowadzonych na urządzeniu. Serwer synchronizacji (Supabase Storage, region UE) przechowuje szyfrogram i nie może odszyfrować. 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: przez proxy, nigdy bezpośrednio
Wywołania do Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) idą przez Supabase Edge Function, która trzyma klucz API 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 security@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 privacy@fluera.dev.