Donat DA

DA Creation — F1a · Identitas

Fase 1a Panduan Induk v4.5 (paket v1.4 superset): cangkang PWA · OAuth redirect manual (tanpa popup) · Passkey PRF · Bungkus Kunci di appDataFolder · Identitas #1 genesis. Origin: · crossOriginIsolated: · Pelajaran F0 (v2o) dibawa penuh: auto-heal DOM, tombol selalu bisa ditekan, status ber-cap-waktu, laporan log lengkap.

📋 Papan Status — dibaca ulang dari kondisi nyata, bukan janji

Origin…
Cangkang (SW + isolasi)…
Akun Googlebelum masuk (Uji 2)
Kuota Drive—
Passkey PRF—
Brankas di cloud—
Perangkat terdaftar—
Identitas #1—
Kesehatan akun—

1 Cangkang PWA: manifest + Service Worker + COOP/COEP + CSP Belum

Cangkang rumah DA: halaman bisa dipasang sebagai aplikasi, cangkangnya tersimpan di perangkat (Service Worker) supaya buka-nya cepat & tetap tampil saat internet mati, dan halamannya terkunci aturan keamanan (COOP/COEP/CSP daftar putih).

🎯 APA YANG DIUJI: Apakah cangkang PWA utuh — terpasang, ter-cache, dan halaman terisolasi dengan kebijakan keamanan yang benar?
Fungsi yang divalidasi: manifest.json valid + Service Worker terdaftar & aktif + crossOriginIsolated (bukti COOP/COEP hidup) + header CSP daftar putih terpasang di halaman ini (koneksi keluar cuma boleh ke daftar: Google, jsDelivr, HuggingFace).
Rujukan: Panduan v4.5 Bagian 9.1 (CSP + isolasi), 13.6 (app shell), Fase 1a.
Kriteria lulus: manifest terbaca & valid · SW aktif · crossOriginIsolated=YA · header CSP nyata di respons halaman (dicek langsung, bukan cuma baca berkas) · semua berkas shell ada.
📋 Resep uji
  1. Klik Periksa cangkang — semua pemeriksaan jalan otomatis.
  2. (Opsional, bukti nyata) Chrome → menu ⋮ → Install app / ikon pasang di address bar → DA terbuka sebagai aplikasi sendiri.
  3. (Opsional) Matikan internet → buka ulang app terpasang → cangkang tetap tampil (data cloud memang butuh online — itu jujur).







  
2 OAuth In production + pemeriksaan kesehatan akun Belum

  
Pintu masuk Google mode produksi: redirect flow (bukan popup — supaya isolasi COOP tidak rusak, pelajaran F0 v2g). Dan tiap kali masuk, DA menampilkan cek kesehatan akun: siapa aku, kuota cukup gak, dan yang paling penting — apakah data aman di cloud & bisa dipulihkan.

  

    🎯 APA YANG DIUJI: Apakah login Google jalan di mode produksi DAN setiap masuk muncul "rapor kesehatan akun" yang jujur?

    Fungsi yang divalidasi: OAuth redirect flow scope drive.appdata + about.get (identitas & kuota) + pemeriksaan kesehatan tiap masuk: apakah da-bungkus.json & da-rantai-identitas.json ada di appDataFolder.

    Rujukan: Bagian 3.3 (kesehatan akun setiap masuk), Fase 1a.

    Kriteria lulus: login sukses via redirect · nama+email+kuota tampil · verdict kesehatan jujur: "AMAN & BISA DIPULIHKAN" kalau backup cloud ada, "⚠ BELUM ADA BACKUP CLOUD" kalau belum · hasil juga muncul di Papan Status.
  

  
📋 Resep uji
    
    
  1. Pastikan Client ID sudah diisi (tersimpan otomatis dari F0, kalau tidak: tempel lagi).
    2. 
    
  2. Klik Masuk + cek kesehatan → halaman penuh redirect ke Google (v1.4: dibangun manual — bukan popup GIS, jadi COOP same-origin tetap utuh) → pilih akun → Lanjutkan → kembali ke sini bawa #access_token=… + #state=… di fragment, di-parse otomatis + cek anti-CSRF.
    3. 
    
  3. Rapor kesehatan muncul sendiri setelah kembali. Kalau belum pernah jalan Uji 4, verdict memang "⚠ BELUM ADA BACKUP CLOUD" — itu kejujuran, bukan gagal.
    4. 
    
  4. Kalau sesuatu macet: baris "Landing terakhir (diag)" di log + tombol "Cek token dari URL" (fallback manual) bantu diagnosis — dan laporan detail menyimpan riwayat 5 landing terakhir (aman: isi fragment gak pernah disimpan).
    5. 
  

  
  
  
  







  
3 Passkey PRF — simpan otomatis tanpa pilih-milih Belum

  
Passkey dibuat dengan aturan wajib Panduan: authenticatorAttachment:'platform' — artinya browser otomatis menyimpan ke Google Password Manager / iCloud Keychain tanpa menanyakan "simpan di mana?". Dari passkey, PRF menghasilkan kunci stabil 32 byte — bahan Bungkus Recovery.

  

    🎯 APA YANG DIUJI: Apakah passkey lahir dengan aturan simpan-otomatis (tanpa dialog pilih penyimpanan) dan PRF-nya benar menghasilkan kunci 32 byte?

    Fungsi yang divalidasi: navigator.credentials.create() dengan kombinasi wajib {platform, residentKey:'required', userVerification:'required'} + ekstensi prf enabled + prf.eval mengembalikan 32 byte.

    Rujukan: Bagian 5.2 aturan simpan otomatis (Ralat v4.5).

    Kriteria lulus: passkey terbuat tanpa dialog "simpan di mana" · prf.enabled=true · eval PRF = 32 byte · credentialId tersimpan · deteksi platform authenticator tampil.
  

  
📋 Resep uji
    
    
  1. Klik Buat passkey + tes PRF → biometrik/PIN diminta → selesai.
    2. 
    
  2. Perhatikan: TIDAK ada dialog "pilih tempat penyimpanan" — itu justru tanda lulus (aturan Bagian 5.2).
    3. 
    
  3. Klik Tes PRF ulang → biometrik lagi → PRF sama-sama menghasilkan 32 byte (hex-nya tidak ditampilkan penuh demi keamanan, cuma sidik-jari 8 huruf).
    4. 
  

  
  
  







  
4 Bungkus Kunci dua lapis di appDataFolder Belum

  
Jantung brankas (standar Bagian 4.6 + 5.2): Kunci Master dibungkus dua lapis — Lapis A Bungkus Recovery (kunci dari PRF passkey, bawa ke perangkat mana pun) + Lapis B Bungkus Per-Perangkat (ECDH P-256, bisa dicabut kalau HP hilang). Dan berbeda dengan F0: bungkusnya diunggah ke appDataFolder — cloud = sumber kebenaran (Bagian 7.0), bukan cuma tidur di localStorage.

  

    🎯 APA YANG DIUJI: Apakah Kunci Master benar dibungkus dua lapis DAN bungkusnya tersimpan di cloud (bukan cuma lokal) — sehingga perangkat lain bisa pulih darinya?

    Fungsi yang divalidasi: HKDF-SHA-256 dari PRF → KEK Recovery → AES-GCM-256 bungkus MK · ECDH P-256 per-perangkat → bungkus MK · unggah da-bungkus.json ke appDataFolder · baca-ulang dari cloud → buka → catatan didekripsi → hash SHA-256 cocok.

    Rujukan: Bagian 4.6, 5.2, 7.0 (OPFS/cache, cloud sumber kebenaran).

    Kriteria lulus: da-bungkus.json ada di appDataFolder · baca-ulang dari cloud utuh · Master Key terbuka via biometrik · catatan muncul kembali di kolom & hash cocok · daftar perangkat berisi perangkat ini.
  

  
📋 Resep uji
    
    
  1. Ketik catatan uji apa pun di kolom (contoh: Tes Visi DA Creation).
    2. 
    
  2. Klik Buat Kunci Master + unggah cloud → biometrik diminta → kolom dikosongkan otomatis (plaintext tidak di-persist — pelajaran F0 v2j).
    3. 
    
  3. Tutup tab sepenuhnya, buka lagi, masuk (Uji 2) bila diminta.
    4. 
    
  4. Klik Buka Kunci dari CLOUD → biometrik → catatan muncul kembali di kolom. Sumbernya diambil dari appDataFolder, bukan dari ingatan lokal.
    5. 
  

  
  
  
  







  
5 Pemulihan satu ketukan — simulasi perangkat baru Belum

  
Ini padanan nyata "ganti HP" atau "hapus data aplikasi": semua jejak kunci lokal dilupakan, lalu aplikasi pulih total dari cloud — login satu ketukan → biometrik → kunci & catatan kembali → perangkat ini terdaftar baru di daftar perangkat cloud.

  

    🎯 APA YANG DIUJI: Apakah aplikasi bisa pulih 100% dari cloud TANPA jejak lokal dan TANPA menghafal apa pun?

    Fungsi yang divalidasi: hapus kredensial lokal (credentialId/salt cache + kunci ECDH IndexedDB + cache bungkus) → unduh bungkus dari appDataFolder → Bungkus Recovery dibuka via PRF → Master Key terbuka → Bungkus Per-Perangkat BARU dibuat & diunggah (daftar perangkat bertambah).

    Rujukan: Bagian 7.0 (pemulihan satu klik), 6.1 Jalur 1.

    Kriteria lulus: setelah "lupakan lokal", pulihkan dari cloud sukses · catatan muncul sama persis di kolom · jumlah perangkat di cloud bertambah (atau entri perangkat ini diperbarui) · tidak satu pun kode dihafal.
  

  
📋 Resep uji
    
    
  1. (Syarat: Uji 4 sudah lulus — brankas sudah di cloud.)
    2. 
    
  2. Klik 1 · Lupakan kredensial lokal → log menunjukkan apa saja yang dihapus. Catatan di kolom juga dikosongkan.
    3. 
    
  3. Klik 2 · Pulihkan dari cloud → biometrik diminta → catatan kembali di kolom hasil + perangkat terdaftar.
    4. 
    
  4. Cek Papan Status: baris Perangkat terdaftar harus sesuai.
    5. 
  

  
  
  
  







  
6 Identitas #1 + entri genesis Rantai Identitas (JWS Ed25519) Belum

  
Kamu (pengembang) mendaftar sebagai pengguna pertama — Identitas #1 — dan menandatangani entri genesis: akar kepercayaan seluruh ekosistem DA Creation. Tanda tangannya JWS Ed25519 standar (RFC 7515 + 8037) — bisa diverifikasi ulang kapan saja. Kunci privat identitas tidak pernah telanjang: dibungkus Kunci Master lalu disimpan di cloud.

  

    🎯 APA YANG DIUJI: Apakah Identitas #1 bisa mendaftar & menandatangani entri genesis yang VERIFIKASINYA JALAN — dan rantainya append-only?

    Fungsi yang divalidasi: kunci Ed25519 dibuat (WebCrypto modern; fallback @noble/ed25519 self-hosted) · entri genesis kanonik → JWS EdDSA compact → verifikasi ulang VALID · kunci privat dibungkus AES-GCM dengan Master Key → da-kunci-identitas.json + da-rantai-identitas.json diunggah · pendaftaran ulang DITOLAK (append-only — genesis cuma sekali).

    Rujukan: Bagian 5.4 (Identitas #1), Bagian 4.6 (Ed25519), Fase 1a — kriteria selesai: "Identitas #1 berhasil menandatangani entri genesis".

    Kriteria lulus: genesis tercatat + JWS terverifikasi valid saat dicek ulang DARI CLOUD · ID identitas tampil di Papan Status · klik daftar lagi = ditolak dengan pesan jelas · kunci privat identitas tersimpan dalam keadaan terbungkus.
  

  
📋 Resep uji
    
    
  1. (Syarat: Uji 4 lulus — kunci identitas dibungkus Kunci Master, dan Uji 2 — perlu cloud.)
    2. 
    
  2. Klik Daftar Identitas #1 + tandatangani genesis → biometrik diminta (membuka Kunci Master) → genesis ditandatangani & diunggah.
    3. 
    
  3. Klik Verifikasi ulang rantai (dari cloud) → rantai diunduh, tiap entri diverifikasi tanda tangannya → harus VALID.
    4. 
    
  4. Coba klik Daftar sekali lagi → harus DITOLAK (append-only: genesis tidak boleh lahir dua kali).
    5. 
  

  
  
  







  
7 Papan Status + audit kebocoran rahasia Belum

  
Dua hal: (1) Papan Status di atas harus menggambarkan kondisi NYATA — tiap baris punya sumber yang bisa dicek (cloud / browser API), bukan tulisan manis. (2) Audit kebocoran: prinsip Panduan "ciphertext tidak pernah terbuka di tempat yang salah" dibuktikan otomatis — Kunci Master & teks plaintext kamu tidak boleh ada di localStorage maupun log. Beda dengan F0: di F1a plaintext TIDAK pernah ditulis ke log — catatan yang didekripsi hanya muncul di kolom, titik.

  

    🎯 APA YANG DIUJI: Apakah tampilan status jujur (= kondisi nyata) dan tidak ada satu pun rahasia yang bocor ke tempat yang salah?

    Fungsi yang divalidasi: Papan Status dibaca ulang dari cloud + API browser · audit: (a) localStorage tidak memuat Kunci Master mentah / token / plaintext, (b) semua log bebas plaintext catatan, (c) kunci privat ECDH perangkat non-extractable (dicoba diekspor → HARUS gagal), (d) struktur bungkus cloud hanya berisi daftar kolom yang diizinkan.

    Rujukan: Bagian 9.1 (prinsip pendamping), 3.3 (kejujuran antarmuka).

    Kriteria lulus: audit bersih (0 kebocoran) · ekspor kunci privat ECDH terbukti ditolak browser · struktur bungkus lolos daftar putih kolom · papan status cocok dengan Papan Status nyata.
  

  
📋 Resep uji
    
    
  1. Jalankan Uji 2–6 dulu supaya ada yang diaudit.
    2. 
    
  2. Klik 🔄 Muat ulang dari cloud di Papan Status → cocokkan tiap baris dengan kejadian nyata tadi.
    3. 
    
  3. Klik Jalankan audit kebocoran → semua pemeriksaan otomatis. Harusnya: 0 kebocoran.
    4. 
    
  4. (Opsional nakal) Ketik teks baru di kolom Uji 4 TANPA mengenkripsi, lalu jalankan audit → tetap bersih, karena teks itu hanya hidup di kolom (memori), tidak di localStorage/log.
    5. 
  

  
  
  











  LULUS 0/7