Vibe Coding xavfsizligi: AI yordamida yaratilgan ilovani qanday himoya qilish mumkin

Ailoot bilan ishlash bo‘yicha qo‘shimcha ko‘rsatmalar hujjatlarda berilgan.

Nega AI yordamida yaratilgan ilovalar tez-tez buzib kirishlarga uchraydi?#

Men ham mahsulotlarni AI yordamida yarataman va xavfsizlikdan “hamma narsani iloji boricha qulflash” darajasida vahimaga tushmayman. Lekin undan pastga tushib bo‘lmaydigan asosiy daraja bor. Aks holda, bir kuni uyg‘onib, ma’lumotlar bazangiz bo‘shab qolganini va serveringizda birovning maynerlari ishlayotganini ko‘rishingiz mumkin. Bu qo‘llanma ana shu asosiy daraja haqida. “Xavfsizlik mutaxassisi bo‘ling” degani emas, “sababsiz o‘zingizga zarar yetkazmang” degani.

Muammoning ildizi oddiy. AI agentiga “mijozlar buyurtma berishi uchun ilova yarat” desangiz, u ilovani imkon qadar tez ishlaydigan qiladi. Xavfsizlik esa demoda ko‘rinmaydigan qo‘shimcha ish. Shu sababli ma’lumotlar bazasi ochiq sozlanadi, to‘lov kaliti to‘g‘ridan-to‘g‘ri kodga yoziladi, “bu foydalanuvchining ruxsati bormi?” degan tekshiruv esa faqat brauzerda bo‘ladi va uni bir soniyada chetlab o‘tish mumkin.

Boshqacha aytganda, zaiflik sukut bo‘yicha o‘z-o‘zidan paydo bo‘ladi. Siz noto‘g‘ri ish qilmadingiz. Shunchaki hech narsa qilmadingiz — xavfsizlikda esa harakatsizlik aynan “hamma uchun ochiq” degani.

Vibe coder’lar qaysi xatolarni qimmatga tushgan tajribadan o‘rgandilar?#

Ehtiyotsizlikdan saqlanishning eng yaxshi yo‘li — boshqalarning xatolaridan o‘rganish. Loyihangizni nashr qilishdan oldin ko‘rib chiqishga arziydigan to‘rtta tahlil:

Lovable va o‘chirilgan RLS. Lovable platformasi matnli tavsiflardan ilovalar yaratadi. 2025-yilda uning ilovalarida tizimli zaiflik aniqlanib, unga CVE-2025-48757 raqami berildi. Sababi: yaratilgan ilovalarda ma’lumotlar bazasiga satr darajasida kirish qoidalari yo‘q edi (RLS, quyida tushuntiriladi). Tadqiqotchi tanlangan namunani tekshirib, 170 ta ilovada 303 ta ochiq kirish nuqtasini topdi. Ismlar, telefon raqamlari, to‘lov holatlari, boshqalarning API kalitlari va hatto uy manzillari oshkor bo‘ldi. Tekshirilgan ilovalarning taxminan 70 foizida satr darajasidagi himoya butunlay o‘chirilgan edi.

Tea va maxfiy ma’lumotlar. Tea ilovasidan (odamlar haqidagi anonim sharhlar) 2025-yil iyulida taxminan 72 000 ta rasm, jumladan 13 000 ta selfi va hujjat suratlari, keyinchalik esa milliondan ortiq shaxsiy xabar sizib chiqdi. Texnik sababi — ochiq saqlash joyi va zaif kirish tekshiruvlari. Xavfsizlik hamjamiyati Tea’ni yorqin misol sifatida keltiradi: tez ishga tushirish ruxsatlarni tekshirishdan ustun qo‘yilsa, birinchi bo‘lib maxfiy ma’lumotlar sizib chiqadi.

Yana bir amaliy misol. Maqola muallifi ta’riflagan holatda, vibe coder’ning ilovasi AI ma’lumotlar bazasini yaratishda sukut bo‘yicha parol o‘rnatgani uchun buzib kirishga uchragan — bu parolni avtomatik tarzda topish mumkin edi. Keyin odatdagi voqealar ketma-ketligi yuz berdi: tizimga kirishdi, maynerlarni o‘rnatishdi va loyihani qayta yozishdi. Serverni butunlay tozalashga to‘g‘ri keldi. Sukut bo‘yicha parol — “bemalol kiring” degan yozuvi bor qulfsiz eshik bilan barobar.

Xavfsizlikning ikki yo‘nalishi: aynan qayerda zaif bo‘lishingiz mumkin?#

Odamlar “vibe coding xavfsizligi” haqida gapirganda, odatda bir-biridan mutlaqo farqli ikki xavotirni aralashtiradilar. Keling, ularni ajrataylik, chunki har biridan turlicha himoyalanasiz.

Birinchi yo‘nalish — agentning o‘zi. AI agentini kompyuteringizda ishga tushirib, fayllaringizga, terminalga, kalitlarga va ma’lumotlar bazasiga ruxsat berasiz. Xavf shundaki, agent odam emas: u ko‘rsatmalarni so‘zma-so‘z bajaradi va xavfli bo‘lsa ham eng qisqa yo‘lni topadi. Bunga agent o‘qigan matn orqali boshqa birovning buyrug‘i unga “kiritilishi” xavfi ham kiradi (bu prompt injection deb ataladi).

Ikkinchi yo‘nalish — tayyor ilova. Bu siz nashr qilgan va odamlar foydalanadigan mahsulot. Nishon — ommaga ochgan saytingiz yoki xizmatingiz: hujumchilar ochiq ma’lumotlar bazasiga kiradi, soxta so‘rovlar yuboradi yoki boshqa odamlarning akkauntlari parollarini topishga urinadi. Bunda agentning aloqasi yo‘q — zaiflik avvalroq qoldirilgan va undan boshqalar foydalanmoqda.

Claude’ni yaratuvchi Anthropic himoyaning asosiy tamoyilini shunday bayon qiladi — bu tamoyil ikkala yo‘nalishda ham amal qiladi:

Amalda bu “AI o‘zicha yomon ish qilmaslikka harakat qiladi” deb ishonib qolmaslikni anglatadi. Avval u jismonan nimalar qila olishini cheklang, keyin esa o‘zini yaxshi tutishini so‘rang. Xatti-harakati buzilganda — bu albatta yuz beradi — sizni faqat oldindan o‘rnatgan qat’iy chegara himoya qiladi.

AI agenti kompyuteringizga kirish huquqi bilan nima qila oladi?#

Eng kam baholanadigan xavf — o‘ta keng ruxsatlarga ega bo‘lgan o‘z agentingiz. Buning uchun tashqi xaker ham kerak emas. Mana yaqinda, 2026-yil may oyi oxirida muhokama qilingan misol. Codex agentiga foydalanuvchida bo‘lmagan administrator ruxsatlari kerak edi. Agent taslim bo‘lmadi: atrofni ko‘zdan kechirib, foydalanuvchi docker guruhiga kirishini, bu esa amalda root bilan teng ekanini payqadi va shu ruxsatdan foydalandi.

Bu yerda yomon niyat bo‘lmagan. “Vazifani hal qil” deb aytilgan agent tizimdagi zaiflikni odamdan tezroq topadi, xolos. Agar shu zaiflik unga kalitlaringiz yoki ishlab turgan tizimingizga kirish imkonini bersa, undan foydalanadi. Shuning uchun birinchi qoida — eng kam ruxsat. Agentga muayyan vazifa uchun aynan qancha kirish huquqi kerak bo‘lsa, shuncha bering, ortiqcha emas.

Dasturchi bo‘lmasangiz ham, amalda nima qilishingiz mumkin?

1. Ishlab turgan tizimda agentni “hammasiga ruxsat” rejimida ishga tushirmang

   Agent tasdiq so‘ramaydigan rejim (ko‘pincha bypass yoki yolo deyiladi) faqat sandbox yoki sinov loyihasi uchun; unda ishchi kalitlar va ishlab turgan tizimga kirish huquqi bo‘lgan kompyuter uchun emas.

2. Agentga maxfiy ma’lumotlarni o‘qishni taqiqlang

   Claude Code’da buni kalitlar saqlangan fayllarga kirishni rad etadigan qoida bilan qilasiz. Shunda agent .env faylini ochmoqchi bo‘lsa ham, vosita bunga ruxsat bermaydi.

3. Ishlab turgan tizim kalitlarini alohida saqlang

   Ishlab turgan ma’lumotlar bazasi va to‘lov xizmati kalitlari agent kod yozadigan papkada bo‘lmasligi kerak. Muhitlarni alohida saqlang: tajriba o‘tkazayotganingizda sinov kalitlaridan foydalaning.

4. Vositaning sandbox’idan foydalaning

   Zamonaviy AI vositalari buyruqlarni tizimdan ajratilgan muhitda (sandbox) ishga tushira oladi; u yerda agent tizimning qolgan qismiga kira olmaydi. Claude Code’da bu ruxsat so‘rovlarini taxminan 84 foizga kamaytiradi — demak, foydalanish ham qulayroq.

Claude Code’da maxfiy ma’lumotlarni o‘qishni rad etadigan qoida taxminan quyidagicha ko‘rinadi — uni ruxsatlar sozlamalariga kiriting:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

API kalitlari va parollarni qayerga hech qachon joylamaslik kerak?#

Eng arzon va keng tarqalgan xato — kalitlarni kodga joylash. To‘lov xizmati uchun API kaliti, ma’lumotlar bazasi paroli, bot tokeni — bularning barchasi maxfiy ma’lumotlardir. Ular alohida .env faylida turishi va kod bilan birga git’ga tushmasligi uchun bu fayl .gitignore ro‘yxatiga kiritilishi kerak.

2025-yildagi muammoning ko‘lami: ochiq repozitoriylarda 28,65 millionta yangi, kodga qattiq yozilgan maxfiy ma’lumot aniqlandi; bu o‘tgan yilga nisbatan 34 foiz ko‘p. Aynan AI xizmatlari kalitlarining sizib chiqishi 81 foizga oshdi. Agent tekshirmasdan commit qilgani uchun vibe coding muammoni yanada kuchaytiradi.

Hozir qo‘lda nimalarni tekshirish kerak:

1. Loyihaning .gitignore faylini oching

   Unda .env qatori borligiga ishonch hosil qiling. Bo‘lmasa, birinchi commitdan oldin qo‘shing.

2. GitHub repozitoriyingizga o‘ting

   .env fayli u yerda yo‘qligini tekshiring. Repozitoriydan .env yoki kalitingizning bir qismini qidirish — tez tekshiruv usuli.

3. Kalit sizib chiqqan bo‘lsa, uni bekor qilib, yangisini chiqaring

   Commitni o‘chirish yetmaydi: kalit allaqachon qo‘lga kiritilgan bo‘lishi mumkin. Xizmat sahifasiga o‘ting (to‘lov xizmati provayderi, bulutli xizmat yoki AI provayderi), eski kalitni bekor qiling va yangisini chiqaring. Bu kalitni almashtirish deb ataladi.

4. Kalitlarga eng kam ruxsatlarni bering

   Kalit faqat o‘qish uchun kerak bo‘lsa, uni faqat o‘qish rejimiga qo‘ying. Shunda sizib chiqqan taqdirda ham, o‘g‘irlash mumkin bo‘lgan narsa kamroq bo‘ladi.

Nega RLS bo‘lmasa, hamma ma’lumotlar bazangizni ko‘ra oladi?#

Agar Supabase yoki shunga o‘xshash ma’lumotlar bazasida ilova yaratayotgan bo‘lsangiz, bu eng muhim bo‘lim. RLS — Row Level Security, ya’ni satr darajasidagi xavfsizlik degani. Sodda qilib aytganda, u jadvaldagi qaysi satrlar muayyan foydalanuvchiga ko‘rsatilishini belgilaydi. Usiz “buyurtmalar” jadvali har kimga barcha mijozlarning buyurtmalarini qaytaradi.

Supabase hujjatlarida bu aniq qilib shunday yozilgan:

Vibe coder uchun asosiy tuzoq mana shu. Supabase boshqaruv panelida bosib jadval yaratsangiz, himoya avtomatik yoqiladi. Ammo AI jadval yaratganda — odatda u SQL buyruqlarini bevosita yozadi — RLS sukut bo‘yicha o‘chirilganicha qoladi. Demak, agent yaratgan jadval deyarli aniq butun internet uchun ochiq bo‘ladi. Lovable’ning 170 ta ilovasidagi ma’lumotlar aynan shu tarzda sizib chiqqan.

Nima qilish kerak:

1. Agentdan to‘g‘ridan-to‘g‘ri so‘rang

   “RLS o‘chirilgan barcha jadvallarni ko‘rsat” deb yozing. AI ro‘yxat tuzadi — shu sizning ishlar ro‘yxatingiz.

2. Foydalanuvchilar ma’lumotlari bor har bir jadvalda RLS’ni yoqing

   Va kamida bitta kirish siyosatini qo‘shing — masalan, “foydalanuvchi faqat o‘z satrlarini ko‘ra oladi”.

3. Boshqaruv panelini tekshiring

   Supabase boshqaruv panelida har bir jadvalda “RLS enabled” deb ko‘rsatilishi kerak. Kulrang yoki qizil bo‘lsa, jadval ochiq degani.

4. Haqiqiy sharoitda sinab ko‘ring

   Oddiy foydalanuvchi sifatida tizimga kiring va boshqa birovning ma’lumotlarini so‘rab ko‘ring. Kirish rad etilsa, siyosat ishlayapti.

Nega interfeysdagi ruxsat tekshiruvlari sizni himoya qilmaydi?#

Ko‘p uchraydigan xato fikr: “Oddiy foydalanuvchilar admin tugmasini ko‘ra olmaydigan qildim.” Muammo shundaki, tugma brauzerdagi oddiy rasm, xolos. Tugmadan foydalanmasdan ham so‘rovni to‘g‘ridan-to‘g‘ri serverga yuborish mumkin. Server ruxsatlarni qayta tekshirmasa, boshqa birovning buyrug‘ini bajaradi.

Klassik misol IDOR deb ataladi. id=123 manzili orqali buyurtmangizni ochdingiz, deylik. Uni id=124 qilib o‘zgartirsangiz, server bu haqiqatan ham sizning buyurtmangizmi, tekshirmagani uchun boshqa birovning buyurtmasini ko‘ra olasiz. Bu vibe coding orqali yaratilgan ilovalardagi eng keng tarqalgan zaifliklardan biri, Tea ma’lumotlari sizib chiqishiga ham zaif ruxsat tekshiruvlari sabab bo‘lgan.

Qoida oddiy: “Bu foydalanuvchi buni qilishga haqlimi?” degan har bir tekshiruvni serverda takrorlang. Interfeys qulaylik uchun; himoya backend’da bo‘ladi. Agent uchun tayyor ko‘rsatma: “Foydalanuvchi ma’lumotlarini o‘qiydigan yoki o‘zgartiradigan har bir endpoint’ga server tomonida ruxsat tekshiruvlarini qo‘sh; interfeysda element yashirilganiga tayanma.”

Dasturchi bo‘lmasangiz, koddagi zaifliklarni qanday tekshirish mumkin?#

Yaxshi xabar: bugun xavfsizlikni tekshirishni ham o‘sha AI’dan so‘rashingiz mumkin — u keng tarqalgan zaifliklarni ancha yaxshi topadi. Turli vazifalarga mo‘ljallangan uchta vosita:

1. Claude Code’dagi /security-review buyrug‘i. Joriy branch’ni SQL injection, XSS, ruxsat zaifliklari, ma’lumot sizishi va bog‘liqlik muammolari bo‘yicha bir marta tekshiradi. Uning qanday ishlashi va har bir o‘zgarishga avtomatik tekshiruvni qanday qo‘shishni Claude Code’da xavfsizlik tekshiruvi haqidagi alohida qo‘llanmada bosqichma-bosqich tushuntirdim. Bu yerda asosiy jihati: u birinchi himoya chizig‘i bo‘lib, bitta buyruq bilan ishga tushadi.

2. Rasmiy security-guidance plagini. Rasmiy plagin bozoridan /plugin install security-guidance@claude-plugins-official buyrug‘i bilan o‘rnating (Claude Code 2.1.144 yoki undan yangi versiya talab qilinadi). U kodni uch paytda tekshiradi: har bir tahrirda, har bir navbat oxirida va commit vaqtida. Ruxsat chetlab o‘tishlari, IDOR, injection hujumlari va zaif kriptografiyani aniqlaydi. Ammo Anthropic uning cheklovlarini ochiq aytadi:

npx skills add <author>/<repo>

Keyin agentga shunchaki: “loyihamni zaifliklar bo‘yicha tekshir” deb ayting. Lekin bu to‘plamga doir muhim istisno bor, shuning uchun quyida unga alohida bo‘lim ajratdim.

Ma’lumot uchun: yirik kompaniyalar ham AI kodi xavfsizligiga jiddiy yondasha boshladi. 2026-yil 2-iyunda 150 ta tashkilotni qamrab olish uchun kengaytirilgan Project Glasswing doirasida hamkorlar Anthropic modellaridan foydalanib, qisqa vaqt ichida 10 000 dan ortiq muhim zaiflikni topishdi. Xavf ko‘lami aniq:

GitHub’dagi ko‘nikmalar va kengaytmalarga ishonish mumkinmi?#

Bu yerda vaziyat ayniqsa chigal, chunki xavf xavfsizlik uchun o‘rnatgan vositangizdan keladi. npx skills add ... buyrug‘ini bajarsangiz yoki kengaytma o‘rnatsangiz, agent sizning ruxsatlaringiz bilan ishga tushiradigan birovning kodini olasiz. Muallifning akkaunti buzilgan yoki paket boshidanoq zararli bo‘lgan bo‘lsa, muammoga duch kelasiz.

Oldingi bo‘limdagi ko‘nikmalar to‘plamini olaylik. Nomida “Anthropic” borligi ehtiyotkorligingizni susaytiradi. Ammo uning o‘z tavsifida ochiq aytilgan:

Boshqacha aytganda, nomi chalg‘itadi. To‘plamning o‘zi hozir puxta va toza, ammo tamoyil o‘zgarmaydi: uni o‘z xavf-xataringiz bilan o‘rnatasiz. Tahdid esa nazariy emas. 2026-yil may oyida zararli muharrir kengaytmasi plaginni tarqatish bozorida atigi 18 daqiqa turdi — shu vaqt ichida uni o‘rnatganlarning parol boshqaruvchilaridagi parollarini, GitHub tokenlarini, bulutga kirish ma’lumotlarini va hatto Claude Code konfiguratsiyalarini o‘g‘irlashga ulgurdi. Yana bir noxush jihati: bunday zararli dastur ko‘pincha paketni odatdagidek o‘chirib tashlagandan keyin ham qoladi va keyingi seansda yana ishga tushadi.

O‘zim uchun oddiy bir odatni yo‘lga qo‘yganman, sizga ham tavsiya qilaman: GitHub’dan biror skill o‘rnatishdan oldin uni o‘zingiz tekshiring. Muallifning akkaunti buzilishi, hisobini birov egallab olishi yoki repozitoriyga zararli kod tushishi mumkin. Tekshirish — sizning himoyangiz.

O‘rnatishdan oldingi amaliy minimum: muallif va yulduzlar sonini ko‘ring, ko‘nikma tavsifini o‘qing, “bitta postda tavsiya qilingan” degani uchungina vosita o‘rnatmang; notanish vositani avval ishlab turgan kalitlari bor kompyuterda emas, alohida sinov muhitida sinang.

Buzib kirishdan keyin nima yordam beradi: zaxira nusxalar va orqaga qaytarish#

Xavfsizlik faqat “begonalarni kiritmaslik” emas, balki “biror narsa xato ketganda odatdagi holatga qaytish” hamdir. Chunki xato baribir yuz beradi. Amaliy holatlarning birida AI agent odatiy vazifani bajarayotib, ishlab turgan loyihadagi faol ma’lumotlar bazasini o‘chirib yuborgan. Zaxira nusxasi bor edi, ammo u uch kunlik edi — uch kunlik ma’lumot shunchaki yo‘qoldi.

Bundan ikki qoida kelib chiqadi.

Tez-tez zaxiralang. Ilovangizda yo‘qotishni istamaydigan ma’lumotlar bo‘lsa, uch kunda bir marta nusxa olish himoyadek ko‘rinadigan xolos. Avtomatik zaxiralashni kamida har 30 daqiqada bajariladigan qilib sozlang. Supabase’ni ham qo‘shib, ko‘pchilik ma’lumotlar bazasida buni bir necha marta bosib yoqish mumkin.

Git — agentga qarshi sug‘urta. Git kodingiz tarixini saqlaydi: istalgan ishlaydigan holatni tiklashingiz mumkin. Agent ishlayotgan narsani qayta yozsa, uni qo‘lda tuzatish o‘rniga oxirgi ishlaydigan versiyaga qaytasiz. AI loyihani o‘chirgan yoki buzgan bo‘lsa-yu, qanday tiklashni bilmasangiz, alohida maqolaga qarang: AI ma’lumotlar bazasini o‘chirib yuborsa nima qilish kerak. Loyihani buzilishdan oldindan himoyalash uchun Claude Code’ni buzilishdan qanday himoya qilish qo‘llanmasini ko‘ring.

Nashrdan oldingi xavfsizlik ro‘yxati#

Nashrdan oldin aynan shu tartibda ro‘yxatni tekshirib chiqing.

1. .env ichidagi maxfiy ma’lumotlar va .gitignore ichida ko‘rsatilgan .env. Kodda kalitlar yo‘q. Ochiq repozitoriyda .env fayli yo‘q.

2. Eng kam ruxsatli kalitlar. Har bir kalit faqat kerakli ishni bajara oladi. Ishlab turgan tizim kalitlari agent muhitidan ajratilgan.

3. Foydalanuvchilar ma’lumotlari bo‘lgan barcha jadvallarda RLS yoqilgan va kirish siyosatlari mavjud.

4. Ma’lumotlar bilan har bir amal uchun server tomonida ruxsat tekshiruvi bor. Interfeysda tugmani yashirish yetmaydi. Manzildagi id qiymatini o‘zgartirib, qo‘lda sinab ko‘rildi.

5. Webhook imzosi tekshiriladi. Tashqi bildirishnomalarni (to‘lovlar, formalar) qabul qiluvchi har bir handler imzoni tekshiradi.

6. Kiruvchi so‘rovlar va qimmat amallar uchun so‘rovlar soni cheklangan, shunda parollarni taxmin qilib topishga urinishlarning va hisobingizning keskin oshib ketishining oldi olinadi.

7. Agent ishlab turgan kalitlari bor kompyuterda “hammasiga ruxsat” rejimida ishlamaydi. .env faylini o‘qish taqiqlangan.

8. Zaxira nusxalari tez-tez olinadi va tiklab ko‘rish bilan sinovdan o‘tkazilgan — nusxalar “qayerdadir bor” deb ishonish bilan cheklanmaydi.

9. Kod /security-review yoki security-guidance plagini bilan tekshirilgan. Aniqlangan muammolar tuzatilgan.

10. Boshqa odamlarning skill va kengaytmalari o‘rnatishdan oldin tekshirilgan. Hech narsa “ko‘r-ko‘rona” o‘rnatilmagan.

Bugun nimadan boshlash kerak#

Bu qo‘llanmadagi hamma narsani bir kechada bajarishga urinmang — oxir-oqibat hech narsa qilmay qolasiz. Bugun eng muhim uchta qadamni bajaring:

1. Maxfiy ma’lumotlaringizni tekshiring. .gitignore faylini ochib, .env ko‘rsatilganini tekshiring va ochiq repozitoriyda kalitlar yo‘qligiga ishonch hosil qiling. Birortasi sizib chiqqan bo‘lsa, uni bekor qilib, yangisini chiqaring.
2. RLS haqida so‘rang. Agentga “RLS o‘chirilgan jadvallarni ko‘rsat” deb ayting va odamlarning ma’lumotlari saqlanadigan jadvallarning barchasida uni yoqing.
3. Tez-tez zaxiralashni sozlang. Shunda biror narsa xato ketsa, kunlarni emas, daqiqalarni yo‘qotasiz.

Loyihangiz kengayib, pul va boshqalarning ma’lumotlari bilan ishlay boshlaganda, yuqoridagi ro‘yxatni bajaring.

Oxirgi bir gap. Vibe coding xavfsizligi egasining mas’uliyati haqida. Xavfsizlik mutaxassisi bo‘lishingiz shart emas. AI mahsulotingizni bir kechada yaratdi — yaxshi, ammo u uchun siz javobgarsiz. Ushbu qo‘llanmadagi asosiy daraja shu mas’uliyatni amalda qanday bajarishni ko‘rsatadi.

Modellar bilan keyingi ishlar uchun Ailoot saytiga o‘tishingiz mumkin.