Unit 9 / 11

Privasi, Kebenaran dan Penggunaan Selamat

Keuntungan:

  • Keupayaan untuk meminta kebenaran dengan justifikasi, konteks dan senario penolakan, menggunakan prinsip keistimewaan paling rendah
  • Keupayaan untuk menyimpan data sensitif yang disulitkan dengan Rantai Kunci/Keystore, menggunakan pengecilan data dan mengawal kecenderungan kecerdasan buatan untuk menambah terlalu banyak kebenaran
  • Keupayaan untuk mengurus aliran data pengguna ke awan atau perkhidmatan kecerdasan buatan sebagai keputusan privasi, mendapatkan persetujuan pengguna dan menggunakan teknik keselamatan hanya untuk tujuan yang dibenarkan dan pertahanan.

Aplikasi mudah alih berfungsi pada peranti paling peribadi pengguna: ia mengetahui lokasi, kenalan, foto, data kesihatan, mikrofonnya. Akses ini adalah kuasa yang hebat, dan kuasa bermakna tanggungjawab. Privasi dan keselamatan bukanlah "ciri tambahan" dalam pembangunan mudah alih, tetapi prinsip yang dijalin ke dalam seni bina dari awal; Ini dipanggil privasi dengan reka bentuk. Selain itu, ini bukan sahaja pilihan beretika, ia adalah kewajipan undang-undang (KVKK, GDPR) dan kedai (App Store, Google Play). Dalam unit ini, kita akan belajar cara meminta kebenaran dengan betul, memproses data dengan selamat, menggunakan AI sebagai pembantu dalam bidang ini dan melindungi diri kita daripada perangkapnya. Terdapat isu kritikal tambahan dalam konteks AI: data pengguna yang pergi ke model AI (terutamanya awan) adalah keputusan privasi itu sendiri.

Seni meminta izin: keistimewaan paling rendah

Prinsip asas keselamatan adalah keistimewaan paling rendah (tidak meminta lebih banyak keistimewaan daripada yang diperlukan oleh pekerjaan). Apl anda hanya perlu meminta kebenaran yang benar-benar diperlukan, pada masa ia memerlukannya. Jika tiada ciri kamera, kebenaran kamera tidak akan diminta; Jika lokasi diperlukan hanya apabila peta dibuka, kebenaran "semasa menggunakan" adalah mencukupi, bukan "selalu". Kebenaran yang berlebihan menyebabkan kemudaratan tiga kali ganda: ia menjejaskan kepercayaan pengguna, membawa kepada penolakan kedai dan meningkatkan risiko kebocoran data.

Masa dan penjelasan yang betul untuk meminta kebenaran adalah kritikal. Minta kebenaran pengguna dalam konteks dan dengan justifikasi, seperti "Akses kamera diperlukan untuk mengimbas resit anda." iOS memerlukan penerangan ini dalam Info.plist; Perihalan kosong atau mengelirukan ialah penolakan kedai.

Jenis kebenaran

pendekatan yang buruk

pendekatan yang baik

masa

Minta semua semasa pelancaran

gesaan apabila menggunakan ciri tersebut

Skop

"Sentiasa lokasi"

"lokasi semasa menggunakan"

Penerangan

Kosong atau generik

Konkrit, justifikasi khusus

status penolakan

Apl ranap/ranap sistem

Sila tawarkan alternatif

Petua: Apl anda sepatutnya boleh terus berjalan apabila kebenaran ditolak. Jika pengguna menolak kamera, tawarkan pilihan "log masuk manual". Pengenaan "benarkan atau apl tidak akan berfungsi" adalah pengalaman buruk dan masalah kedai. Sentiasa minta senario penolakan apabila mencetak kod kebenaran ke AI.

Persetujuan dan kod privasi dengan AI: pertimbangan

AI dengan cepat menjana kod meminta kebenaran, tetapi ia mempunyai dua perangkap biasa. Pertama, menambah lebih banyak kebenaran daripada yang diperlukan: ​​lokasi, kenalan boleh secara pukal meletakkan kebenaran storan "untuk berjaga-jaga". Kedua, melangkau senario penolakan: hanya tulis status "dibenarkan" dan abaikan penolakan. Untuk setiap permit yang dijana anda akan ditanya "adakah ini benar-benar perlu?" dan "apa yang berlaku jika ditolak?" Tanya soalan anda.

Awas: Kod sampel yang dijana oleh AI mungkin menyimpan data pengguna tanpa penyulitan atau menghantarnya secara tidak selamat. Data sensitif (kata laluan, kesihatan, kewangan) hendaklah disimpan dalam storan selamat pada peranti (Keychain — iOS, Keystore — Android; kawasan bilik kebal yang disulitkan pada sistem pengendalian) dan dihantar pada rangkaian melalui sambungan yang disulitkan (HTTPS/TLS). AI tidak selalu melakukan ini secara spontan; Tanya dengan jelas dan sahkan.

Pengurangan data dan penghantaran data ke AI

Data yang anda tidak kumpulkan tidak boleh bocor. Pengurangan data (hanya mengumpul data yang sebenarnya diperlukan) ialah alat yang paling berkuasa untuk privasi. Dalam ciri AI, prinsip ini dua kali ganda penting: apabila menghantar data ke LLM awan atau perkhidmatan AI luaran, data itu berada di luar kawalan anda. Sebelum menghantar nota kesihatan, kandungan perbualan atau maklumat peribadi pengguna ke awan, tanya tiga soalan: (1) Adakah data ini benar-benar diperlukan? (2) Bolehkah ia diproses pada peranti? (3) Jika ia hendak dihantar, adakah pengguna mengetahui dan meluluskannya? Ia adalah keperluan undang-undang dan etika untuk memaklumkan pengguna dengan jelas bahawa data mereka akan dihantar ke perkhidmatan AI.

Penggunaan yang selamat dan tumpuan pertahanan

Amaran daripada perspektif IT dan keselamatan: teknik yang dipelajari dalam modul ini adalah untuk kegunaan yang dibenarkan dan defensif sahaja. Adalah sah untuk menguji keselamatan aplikasi anda sendiri, melindungi data pengguna dan menutup kelemahan. Merekayasa songsang aplikasi orang lain tanpa kebenaran, mengumpul data pengguna tanpa kebenaran atau menggunakan AI untuk mencipta perisian hasad adalah menyalahi undang-undang dan tidak beretika. Apabila meminta bantuan keselamatan AI, sentiasa berada dalam rangka kerja mempertahankan sistem anda sendiri.

tiga kes mini

Kes 1 — Penafian cuti berlebihan. Aplikasi nota meminta kebenaran kamera, mikrofon, lokasi dan kenalan pada permulaan dengan kod yang dihasilkan oleh AI. Google Play menolak keluaran itu, memetik "kebenaran tidak berkaitan fungsi". Keluaran telah diluluskan apabila pasukan hanya mengeluarkan kebenaran penyimpanan yang sebenarnya digunakan. Pengajaran: setiap cuti tambahan adalah risiko.

Kes 2 — Storan tanpa kata laluan. Apl kesihatan menyimpan ukuran pengguna dalam fail teks biasa seperti dalam contoh AI. Audit keselamatan mendapati sesiapa yang memperoleh peranti itu boleh membaca semua data kesihatan. Data dialihkan ke storan yang disulitkan dengan Keystore/Keychain. Pengajaran: data sensitif sentiasa kekal disulitkan.

Kes 3 — Tolak ke awan tanpa pemberitahuan. Sebuah aplikasi menghantar nota harian pengguna ke LLM awan untuk meringkaskannya, tetapi ia tidak memberitahu pengguna. Apabila ia dilaporkan dalam akhbar, berlaku kehilangan kepercayaan dan penelitian undang-undang. Pasukan itu menambah pemberitahuan dan pengesahan yang jelas, serta pilihan pada peranti. Pelajaran: pengguna mesti mengetahui dan mengesahkan bahawa data akan dihantar ke AI.

Gesaan lemah / Gesaan kuat

Gesaan lemah: "Minta kebenaran lokasi."

Gesaan berkuasa: "Minta kebenaran lokasi pada iOS/Swift dengan prinsip keistimewaan paling rendah. - Hanya kebenaran 'apabila digunakan', bukan 'selalu' - Penerangan Info.plist: 'Untuk menunjukkan kedai berdekatan' - Jika kebenaran ditolak: tawaran pilihan untuk memilih bandar secara manual, ranap sistem - Jika kebenaran telah ditolak sebelum ini, ubah hala ke tetapan daripada perlu tambahkan lagi kebenaran.

Templat yang boleh disalin

Templat untuk meminta kebenaran: "Minta kebenaran [jenis kebenaran] untuk [platform].- Skop minimum (apabila menggunakan/mengikut keperluan)- Dalam konteks, dengan penjelasan yang munasabah- Alternatif yang sopan jika berlaku penolakan, jangan sekali-kali ranap- Berikan Info.plist / entri Manifes juga Jangan tambah kebenaran tambahan; justifikasi setiap kebenaran."

Templat audit kebenaran: "Semak kebenaran yang diminta oleh aplikasi saya: [senarai kebenaran + sifat]. Untuk setiap kebenaran: adakah ia benar-benar diperlukan? Adakah skop yang lebih sempit sudah mencukupi? Adakah ia akan menyebabkan penolakan kedai? Tandakan tidak diperlukan."

Templat storan data selamat: "Simpan data sensitif ([jenis]) dengan selamat untuk [platform]:- Disulitkan dengan Rantai Kunci/Keystore- Jangan simpan dalam ingatan untuk jangka masa yang tidak perlu- Jangan bocor ke dalam log dan sandaran Sediakan kod dan langkah pengesahan."

Templat untuk menghantar data kepada AI: "Saya sedang mempertimbangkan untuk menghantar data berikut kepada perkhidmatan AI awan: [data]. Nilaikan: adakah ia benar-benar perlu? Bolehkah ia diproses pada peranti? Jika dihantar, medan manakah yang harus ditutup? Bagaimanakah persetujuan pengguna harus diperolehi? Syorkan reka bentuk yang paling selamat dari segi privasi."

Kesilapan biasa

  • Meminta kebenaran lebih daripada yang diperlukan. Bahaya tiga kali ganda iaitu kepercayaan, kelulusan kedai dan keselamatan.
  • Meminta kebenaran secara pukal pada permulaan. Permintaan untuk kebenaran tanpa konteks ditolak; minta ciri serta-merta.
  • Tidak menulis skrip penolakan. Apl ranap apabila kebenaran ditolak adalah buruk dan ditolak.
  • Menyimpan data sensitif tanpa kata laluan. Kesihatan, kewangan dan kata laluan mesti disimpan dalam storan yang selamat.
  • Menghantar data ke awan/AI tanpa memaklumkan pengguna. Pelanggaran undang-undang dan etika; Pemberitahuan dan kelulusan diperlukan.
  • Penggunaan teknik keselamatan yang tidak dibenarkan. Ia hanya sah untuk tujuan pertahanan pada sistem anda sendiri.

Secara ringkasnya

Privasi dan keselamatan direka dari awal, tidak ditambah kemudian. Prinsip asas adalah keistimewaan paling rendah: minta hanya kebenaran yang diperlukan, apabila perlu, dengan justifikasi, dan tawarkan alternatif yang sopan sekiranya penolakan. Data sensitif disimpan dalam storan yang disulitkan dan dihantar melalui sambungan yang disulitkan. Pengurangan data ialah perlindungan terkuat: data yang anda tidak kumpulkan tidak boleh bocor. Menghantar data kepada AI, terutamanya kepada awan, adalah keputusan privasi itu sendiri; Keperluannya dipersoalkan, jika boleh, pada peranti diutamakan, pengguna dimaklumkan dan kelulusannya diperolehi. Setiap kod yang dihasilkan disemak terhadap kecenderungan AI untuk menambah kebenaran yang berlebihan dan menyimpan dengan tidak selamat. Teknik keselamatan digunakan untuk tujuan yang dibenarkan dan pertahanan sahaja.

Tugasan permohonan

Buat senarai kebenaran yang diminta oleh aplikasi (projek atau khayalan anda sendiri) dan minta AI menyemak mana yang tidak diperlukan atau melampaui batas dengan "Templat audit kebenaran". Perhalusi atau alih keluar sekurang-kurangnya satu kebenaran dan tulis senario penafian untuk ciri tersebut. Selain itu, jika anda menghantar data pengguna ke awan, tentukan reka bentuk yang paling selamat dengan "Templat keputusan penghantaran data kepada AI" dan tulis teks kelulusan pengguna.

senarai semak

  • [ ] Saya meminta setiap kebenaran dengan justifikasi, dengan prinsip keistimewaan yang paling sedikit.
  • [ ] Saya meminta kebenaran dalam konteks, pada masa ciri, bukan pukal semasa pelancaran
  • [ ] Saya menulis skrip penolakan untuk setiap kebenaran, tiada ranap sistem
  • [ ] Saya menyimpan data sensitif yang disulitkan dengan Rantai Kunci/Keystore
  • [ ] Saya meminimumkan data pergi ke awan/AI dan menambah kelulusan pengguna
  • [ ] Saya menggunakan teknik keselamatan hanya pada sistem saya sendiri untuk tujuan pertahanan