Threat Model
Oletamme laitteen varkauden, verkkoliikenteen sieppauksen ja tahattoman paljastumisen varmuuskopion tai pilvisynkronoinnin kautta. Oletamme, että käyttäjän tunnistetiedot voivat vaarantua. Emme oleta valtiollisia toimijoita, joilla on fyysinen pääsy avattuihin laitteisiin — Fluera ei ole salaisuustyökalu, se on oppimistyökalu.
Tämän mallin sisällä kolme takuuta:
- Paikallinen data on lukukelvotonta ilman avainta. Varastettu laite tuottaa salatun blobin.
- Synkronoitu data on meille lukukelvotonta. Pilvi säilyttää vain salatekstiä. Avaimen johtaminen tapahtuu laitteella.
- Telemetria on suostumukseen perustuvaa ja anonymisoitua. Analytiikka ei voi yhdistää käyttäjää sisältöön, ei edes täydellisen tietomurron tapauksessa.
Lepotilassa: SQLCipher, AES-256
Jokainen Flueran muistikirja elää paikallisessa, SQLCipher-salatussa SQLite-tietokannassa — laajasti auditoidussa laajennoksessa, joka salaa läpinäkyvästi jokaisen tietokannan sivun AES-256-CBC:llä ja varmistaa eheyden sivukohtaisesti HMAC-SHA512:lla.
Avaimen johtaminen käyttää PBKDF2:ta SHA-256:lla ja 256 000 iteraatiolla (OWASP-mukaisesti). Salalause säilytetään alustan avainsäilössä — Keychain iOS/macOS:ssa, Keystore Androidissa, DPAPI Windowsissa, libsecret Linuxissa. Sitä ei koskaan lähetetä palvelimillemme.
Siirrossa: TLS 1.3, sertifikaatin kiinnitys
Kaikki verkkoliikenne kulkee TLS 1.3:n yli moderneilla cipher suiteilla. iOS:ssä ja Androidissa kiinnitämme sertifikaatit CA-ketjuumme estääksemme yrityksen välityspalvelimien aiheuttamat man-in-the-middle-hyökkäykset — dokumentoidulla ohituksella verkonvalvojille, jotka sitä tarvitsevat.
Synkronointi laitteiden välillä: päästä päähän
Pilvisynkronointi, kun se on käytössä, käyttää erillistä, laitteella johdettua avainsarjaa. Synkronointipalvelin (Supabase Storage, EU-alue) säilyttää salatekstiä eikä voi purkaa sitä. Synkronointi on muistikirjakohtainen opt-in — voit pitää jotkin muistikirjat vain paikallisina samalla kun synkronoit toisia.
Avainten kierto: kun se käynnistetään miltä tahansa laitteelta, kaikki tulevat payloadit salataan uudella avaimella. Vanhat salatekstit pysyvät vanhempien klienttien luettavissa, kunnes vahvistat migraation kaikilla laitteilla.
P2P-yhteistyö: suora, salattu
Reaaliaikainen yhteistyö käyttää WebRTC DataChannelia DTLS-SRTP-salauksella. Supabase Realtime toimii vain signalointivälittäjänä — yhteyden muodostamisessa — ei varsinaisen canvas-liikenteen välityspalvelimena. Kättelyn jälkeen canvas-muokkaukset virtaavat peer-to-peer. Palvelin ei näe niitä.
Rajoittavien NAT:ien tapauksessa liikenne kulkee TURN:n kautta; tässä tapauksessa välityspalvelin näkee vain salattuja DTLS-paketteja, joita se ei pysty purkamaan.
Tekoälykutsut: välityspalvelimen kautta, ei koskaan suoraan
Kutsut Google Geminiin (Socratic Mode, Ghost Map, LaTeX-OCR, Exam Session) kulkevat Supabase Edge Functionin kautta, joka pitää API-avaimen palvelimella. Asiakaslaitteet eivät koskaan näe avainta. Välityspalvelin valvoo tilauskohtaisia rate limit -rajoja ja kirjaa kutsujen kestot laskutusta varten — ei koskaan canvas-sisältöä.
Jos poistat tekoälyominaisuudet käytöstä kohdassa Asetukset → Yksityisyys, mitään canvas-sisältöä ei lähetetä Geminille, ei myöskään laitepohjaisen OCR:n varatoimena.
Telemetria: opt-in, hashattu, sallittu lista
Tuoteanalytiikka on oletuksena pois päältä. Kun se on käytössä, tapahtumat rajoittuvat palvelinpuolen sallittuun listaan (istunnon alku/loppu, ominaisuuden kutsu, tekoälykutsun kesto — ei koskaan sisältöä). Käyttäjä-ID hashataan laitteella SHA-256:lla; selkokielinen ID ei koskaan poistu asiakkaalta. Tapahtumat säilytetään 180 päivää, minkä jälkeen ne aggregoidaan tai poistetaan.
Auditointiloki (institutionaaliset tilit)
Jokainen pääsy jaettuihin muistikirjoihin — kuka, miltä laitteelta, milloin — kirjoitetaan append-only-auditointilokiin. Pääkäyttäjät voivat viedä lokin CSV- tai JSON-muodossa compliance-tarkastuksia varten. Loki on write-once: poisto vaatii dokumentoidun perustelun ja kirjataan itse.
Palautus ja avaimen menetys
Jos kadotat salalauseen, salatusta datasta tulee palautumaton. Tämä on tarkoituksellista — vaihtoehto olisi palautuspolku, joka väistämättä heikentäisi salausmallia. Institutionaalisille tileille voidaan konfiguroida valinnainen pääkäyttäjän hallinnoima palautusavain; tämä on dokumentoitu trade-off, jonka instituutio valitsee tietoisesti.
Vastuullinen paljastus
Turvallisuustutkijat ovat tervetulleita. Ilmoita haavoittuvuuksista osoitteeseen security@fluera.dev PGP-salauksella (avain julkaistu GitHub-profiilissa). Vastaamme 24 tunnin sisällä, paikkaamme kriittiset ongelmat 72 tunnin sisällä ja mainitsemme ilmoittajat Hall of Fameissa, ellei anonymiteettiä toivota.
Soveltamisala: Fluera-sovellus (kaikki alustat), synkronointipalvelu, tekoälyvälityspalvelin ja tämä markkinointisivusto. Soveltamisalan ulkopuolella: kolmannet osapuolet (Supabase, Google, Apple, Sentry, RevenueCat) — ilmoita kullekin toimittajalle erikseen.
Ulkoiset auditit
Fluera ei ole tällä hetkellä SOC-2- tai ISO-27001-sertifioitu. Ne ovat enterprise-roadmapilla ja ne ilmoitetaan julkisesti, kun ne valmistuvat. Mieluummin emme ilmoita kontrolleja, joita emme voi itsenäisesti todentaa.
Alikäsittelijöiden lista on julkinen ja ajan tasalla. Tietojenkäsittelysopimus (DPA) on saatavilla pyynnöstä osoitteesta privacy@fluera.dev.