Cara Mengevaluasi Browser Tim: Daftar Periksa Praktis

Tentukan keputusan sebelum membuka halaman harga

Evaluasi yang berguna dimulai dari pekerjaan, bukan daftar vendor. Catat:

• alur kerja yang berizin dan sistem yang mengizinkannya;
• jumlah orang, profil tersimpan, profil tersinkron, dan sesi browser bersamaan;
• sistem operasi dan arsitektur prosesor yang perlu didukung;
• mesin browser, ekstensi, proxy, penyedia identitas, dan klien otomatisasi yang dibutuhkan;
• kewajiban lokasi penyimpanan data, retensi, ekspor, penghapusan, dan audit;
• target waktu pemulihan dan batas kehilangan data yang dapat diterima;
• kebutuhan aksesibilitas operator dan administrator;
• anggaran, periode penagihan, cakupan dukungan, dan syarat keluar; serta
• alur kerja terlarang yang tidak boleh difasilitasi produk bagi tim Anda.

Pisahkan jenis sumber daya. Paket dengan 500 profil tersimpan, 100 profil tersinkron ke cloud, lima anggota, dan sepuluh sesi bersamaan tidak menyediakan 500 sesi tim serentak. Terjemahkan setiap batas ke satuan yang digunakan alur kerja Anda.

Lalu tentukan syarat wajib yang tidak dapat ditawar. Contoh syarat yang umum:

1. build browser yang didukung dan mutakhir;
2. tidak ada kerusakan profil tanpa pemberitahuan atau penulis bersamaan;
3. identitas perorangan dengan hak minimum yang dapat dicabut;
4. tidak ada rahasia mentah dalam log biasa atau keluaran otomatisasi;
5. bukti audit yang dapat digunakan;
6. jalur pemulihan dan keluar yang telah diuji; serta
7. penggunaan sah dan berizin sesuai ketentuan layanan yang berlaku.

Jangan menutupi kegagalan syarat wajib dengan nilai rata-rata. Antarmuka yang rapi tidak menggantikan pembaru yang belum terverifikasi atau proses pemulihan yang kehilangan data.

Gunakan skala bukti sederhana

Untuk setiap butir, catat hasil dan bukti terkuat yang diperoleh.

Hasil

• Lulus: persyaratan terbukti dalam lingkungan uji yang ditentukan.
• Perlu perhatian: perilaku bertentangan dengan persyaratan atau menimbulkan konsekuensi berarti.
• Belum diverifikasi: bukti tidak ada, tidak dapat diakses, kedaluwarsa, atau terlalu ambigu untuk mengambil keputusan.
• Tidak berlaku: persyaratan memang tidak relevan bagi alur kerja, dengan alasan tercatat.

Bukti

1. Klaim publik: teks pemasaran atau penjualan.
2. Dokumentasi teknis: dokumentasi produk, keamanan, API, atau dukungan yang memiliki versi.
3. Demonstrasi yang diamati: demo langsung vendor menggunakan skenario Anda.
4. Uji coba terkontrol: tim mereproduksi perilaku dengan data sekali pakai serta mencatat versi dan hasil.
5. Bukti independen atau kontraktual: penilaian dengan cakupan tertentu, komitmen tertulis yang ditandatangani, atau ketentuan dukungan yang mencakup persyaratan.

Tingkat bukti yang lebih tinggi tidak selalu lebih baik untuk semua kasus. Laporan independen mungkin mengecualikan browser desktop, sedangkan uji coba terkontrol dapat mengujinya secara langsung. Catat cakupan, tanggal, versi, dan keterbatasan setiap artefak.

1. Status produk dan batas klaim

• □ Apakah tersedia build nyata yang dapat diinstal untuk setiap platform dan arsitektur yang Anda butuhkan?
• □ Dapatkah vendor menyebutkan versi aplikasi, versi browser, dan tanggal rilis saat ini?
• □ Apakah fitur beta, pratinjau, eksperimental, dan tersedia umum diberi label berbeda?
• □ Apakah batas serta perilaku dalam dokumentasi sesuai dengan uji coba sebenarnya?
• □ Apakah klaim keamanan, ketersediaan, enkripsi, dan kinerja dibatasi pada komponen serta bukti tertentu?
• □ Apakah keterbatasan yang diketahui, alur kerja yang tidak didukung, dan aturan akhir dukungan dipublikasikan?
• □ Apakah vendor menghindari jaminan tidak terlihat, akun tetap bertahan, atau akses ke layanan pihak ketiga?

Simpan installer, layar versi, catatan rilis, dan dokumentasi terkait pada tanggal evaluasi. Jawaban penjualan tanpa referensi yang stabil tetap merupakan klaim publik, bukan perilaku terverifikasi.

2. Isolasi dan integritas profil

Pertama, tentukan apa yang disebut profil oleh produk. Istilah itu dapat berarti direktori data browser persisten, konteks browser sementara, arsip tersinkron, sesi jarak jauh, atau kumpulan pengaturan. Semua itu tidak setara.

Chromium mendokumentasikan direktori data pengguna sebagai lokasi data pengguna dan menjelaskan cara memilih direktori khusus. Dokumentasinya juga mencatat kasus ketika dua instans yang berjalan tidak dapat berbagi satu direktori. Gunakan dokumentasi direktori data pengguna Chromium sebagai titik awal, lalu minta bukti khusus produk.

• □ Apakah setiap profil persisten memiliki batas penyimpanan dan proses yang jelas?
• □ Apakah produk mencegah dua penulis membuka data profil yang sama untuk diubah?
• □ Apakah cookie, penyimpanan, cache, riwayat, ekstensi, unduhan, izin, dan preferensi terisolasi sesuai dokumentasi?
• □ Apakah sesi sementara dan profil persisten diberi label berbeda?
• □ Apakah peluncuran bersih hanya menggunakan data profil yang dimaksud?
• □ Apakah mulai ulang mempertahankan tepat jenis data yang dijanjikan produk?
• □ Apakah izin ekstensi dan sumber pemasangannya dikendalikan?
• □ Apakah impor profil dianggap masukan tidak tepercaya dan divalidasi sebelum digunakan?
• □ Dapatkah profil rusak atau tidak kompatibel dikarantina tanpa menimpa salinan yang diketahui baik?

Bukti uji coba harus mencakup pengujian lintas profil. Simpan penanda yang tidak berbahaya di profil A, pastikan penanda tidak ada di profil B, mulai ulang keduanya, lalu ulangi setelah pembaruan aplikasi. Gunakan akun sekali pakai dan data sintetis.

3. Kemutakhiran browser, sandbox, dan pembaruan

Browser adalah komponen yang penting bagi keamanan dan memerlukan pemeliharaan berkelanjutan. Chrome beralih ke siklus rilis Stable setiap dua minggu melalui Chrome 153 pada 8 September 2026. Jadwal rilis ini tidak menentukan tingkat layanan persis yang dijanjikan setiap penyedia, tetapi menunjukkan mengapa klaim “berbasis Chromium” belum cukup tanpa bukti versi dan pembaruan.

• □ Dapatkah build browser produk dipetakan ke versi upstream yang tepat?
• □ Apakah ada target atau riwayat publik penerapan pembaruan keamanan upstream?
• □ Siapa yang memantau rilis upstream dan perbaikan mendesak?
• □ Apakah pembaruan aplikasi dan browser ditandatangani serta diautentikasi secara terpisah dari koneksi unduhan?
• □ Dapatkah digest artefak, asal-usul rilis, atau rantai penguasaan yang setara diverifikasi?
• □ Apakah peluncuran pembaruan bertahap, dipantau, dan dapat dihentikan?
• □ Apakah pengembalian versi menghindari versi yang tidak aman menurut kebijakan keamanan saat ini?
• □ Apakah migrasi skema profil diuji pada jalur peningkatan dan penurunan versi yang didukung?
• □ Apakah sandbox browser tetap aktif dalam penggunaan normal?
• □ Dapatkah vendor menjelaskan proses tanpa sandbox atau berhak istimewa beserta kebutuhannya?

Chromium menjelaskan sandbox sebagai batas yang membatasi kode tidak tepercaya dan menerapkan hak minimum baik pada kode di dalam sandbox maupun pengendalinya. Tinjau desain sandbox Chromium, lalu minta vendor menunjukkan konfigurasi produksi sebenarnya. Pernyataan bahwa produk “menggunakan Chromium” tidak membuktikan semua mitigasi upstream tetap aktif.

Untuk integritas pembaruan, The Update Framework merupakan acuan yang berguna karena secara eksplisit menangani kompromi repositori dan kunci penandatanganan. Provenance SLSA mendefinisikan informasi yang dapat diverifikasi mengenai tempat, waktu, dan cara artefak dibuat. Vendor tidak harus memakai proyek tersebut, tetapi perlu menjelaskan bagaimana desainnya menangani identitas artefak, kunci yang disusupi, pengembalian versi, pembekuan pembaruan, dan asal-usul build.

4. Identitas, perangkat, dan hak akses minimum

NIST SP 800-53 Revisi 5 mengelompokkan kontrol akses, audit, autentikasi, perencanaan kontingensi, respons insiden, dan risiko rantai pasok. Gunakan kelompok tersebut sebagai pemicu pertanyaan, bukan menganggap kesesuaian dengan kerangka kerja sebagai bukti implementasi.

• □ Apakah setiap orang mendapat identitas sendiri, bukan satu login bersama untuk tim?
• □ Apakah autentikasi multifaktor tersedia dan dapat diwajibkan bagi administrator serta peran sensitif lain?
• □ Apakah opsi autentikasi yang lebih kuat dan tahan phishing didukung saat risikonya memerlukan?
• □ Dapatkah identitas difederasikan dengan penyedia Anda, bila diperlukan, tanpa melewati otorisasi produk?
• □ Apakah peran cukup terperinci untuk memisahkan melihat, meluncurkan, mengedit, berbagi, mengekspor, menghapus, penagihan, dan administrasi?
• □ Dapatkah akses dibatasi ke organisasi, ruang kerja, folder, atau kumpulan profil eksplisit?
• □ Dapatkah perangkat, sesi, pengguna, kredensial layanan, atau undangan segera dicabut?
• □ Apakah akun layanan memiliki identitas, masa berlaku, cakupan, dan batas laju sendiri?
• □ Apakah perubahan izin dan upaya otorisasi yang gagal terlihat di jejak audit?
• □ Apakah proses pengakhiran akses menghapus akses tanpa perlu mengganti kata sandi bersama?

Untuk istilah autentikasi dan panduan tingkat jaminan terkini, lihat NIST SP 800-63B-4, yang difinalkan pada 31 Juli 2025. Konfirmasikan bagian produk mana yang tercakup oleh klaim autentikasi vendor: login situs, pembukaan aplikasi desktop, API lokal, API cloud, pemulihan, dan akses dukungan mungkin menggunakan mekanisme berbeda.

5. Data sensitif dan batas kepercayaan

Gambarkan produk sebagai aliran data. Tandai pengelola desktop, proses browser, layanan lokal, bidang kendali cloud, penyimpanan sinkronisasi, pembaru, pelapor kerusakan, alat dukungan, dan integrasi pihak ketiga. Pada setiap batas, tanyakan data apa yang melintas dan alasannya.

• □ Isi profil apa yang tetap lokal secara default?
• □ Metadata dan konten sensitif apa yang diunggah ketika sinkronisasi diaktifkan?
• □ Di mana enkripsi berlangsung, dan pihak mana yang dapat memperoleh kunci dekripsi?
• □ Bagaimana kunci lokal dilindungi, dicadangkan, dirotasi, dan dipulihkan?
• □ Apa yang dapat dibaca administrator organisasi, dukungan vendor, operator infrastruktur, dan klien otomatisasi?
• □ Apakah cookie, kata sandi, kredensial proxy, rahasia autentikasi dua faktor, dan kunci enkripsi dikecualikan dari antarmuka biasa, log, telemetri, API, serta keluaran agen?
• □ Apakah laporan kerusakan dan diagnostik dapat dipratinjau, disamarkan, mempertimbangkan persetujuan, dan dibatasi retensinya?
• □ Dapatkah dukungan bekerja tanpa meminta arsip profil mentah atau kredensial?
• □ Apakah ekstensi impor, arsip, unduhan browser, dan metadata pembaruan diperlakukan sebagai masukan tidak tepercaya?
• □ Apakah penghapusan didefinisikan untuk salinan lokal, objek cloud, cadangan, log, dan artefak dukungan?

Jangan menerima “terenkripsi” sebagai jawaban lengkap. Catat kategori data, lokasi, batas enkripsi, pemegang kunci, jalur pemulihan, dan keadaan ketika teks biasa tersedia.

6. Kolaborasi dan kemampuan audit

• □ Apakah kepemilikan profil tetap jelas saat penugasan dan serah terima?
• □ Dapatkah produk mencegah atau menyelesaikan pengeditan bersamaan secara terlihat?
• □ Apakah undangan, perubahan peran, peluncuran, penghentian, pembagian, ekspor, penghapusan, panggilan otomatisasi, dan tindakan pemulihan dicatat?
• □ Apakah setiap peristiwa mengidentifikasi manusia pelaku, beban kerja yang didelegasikan, sumber daya, waktu, keputusan, dan hasil?
• □ Apakah nilai sebelum dan sesudah dicatat untuk perubahan konfigurasi penting, dengan rahasia disamarkan?
• □ Apakah jam, zona waktu, urutan peristiwa, dan pengenal permintaan tidak ambigu?
• □ Apakah akses audit, format ekspor, retensi, dan kontrol penghapusan didokumentasikan?
• □ Dapatkah administrator mengubah atau menghapus catatan yang digunakan untuk menilai administrator tersebut?
• □ Dapatkah tim mengekspor log ke sistem pemantauan atau investigasinya?
• □ Apakah pencatatan berlanjut, memakai penyangga aman, atau memblokir operasi ketika tujuan audit tidak tersedia?

Panduan log OWASP menganjurkan pencatatan kegagalan otorisasi dan tindakan berisiko lebih tinggi, mencakup kapan, di mana, siapa, dan apa, sambil mengendalikan akses log serta menghindari rahasia teknis. Terapkan pemeriksaan itu pada peristiwa yang benar-benar diekspor produk, bukan hanya tangkapan layar di halaman keamanan.

7. Pemulihan, gangguan, dan keluar dari layanan

Klaim cadangan belum lengkap sampai pemulihan diuji. Kerangka Kerja Keamanan Siber NIST 2.0 mencakup hasil yang diharapkan untuk membuat, melindungi, memelihara, dan menguji cadangan, serta memverifikasi bahan pemulihan dan sistem yang telah dipulihkan.

• □ Dapatkah cadangan yang konsisten dibuat sambil mematuhi penguncian profil?
• □ Apakah versi lokal dan tersinkron dapat diidentifikasi serta diurutkan?
• □ Dapatkah operator memulihkan versi terpilih tanpa menghancurkan salinan saat ini?
• □ Apakah data hasil pemulihan dan kompatibilitas browser diperiksa sebelum penggunaan normal dilanjutkan?
• □ Apa yang terjadi setelah proses browser dimatikan paksa, jaringan terputus, disk penuh, unggahan terganggu, atau aplikasi mengalami crash?
• □ Apakah versi terakhir yang diketahui baik terlindungi dari perbaikan yang gagal?
• □ Dapatkah perangkat yang dicabut atau hilang dikeluarkan tanpa kehilangan satu-satunya jalur pemulihan?
• □ Apakah kunci atau kode pemulihan terlindungi dari kehilangan biasa maupun akses administrator tanpa batas?
• □ Dapatkah tim mengekspor data dalam format terdokumentasi dan memverifikasi ekspor sebelum membatalkan layanan?
• □ Apakah ada proses penghapusan dan penutupan akun yang didukung, dengan penjelasan jelas tentang retensi yang masih tersisa?

Jalankan pengujian pemulihan hanya dengan data uji coba sekali pakai, kecuali vendor dan proses perubahan Anda secara eksplisit mendukung latihan produksi. Catat waktu pemulihan, data yang hilang, langkah manual, peringatan, dan versi produk. Keberhasilan demo pada satu profil kecil tidak membuktikan kinerja atau integritas pada skala produksi Anda.

8. Otomatisasi dan kontrol pengembang

• □ Apakah produk menyediakan operasi domain berversi, bukan akses sistem berkas atau proses tanpa batas?
• □ Apakah kemampuan API, CLI, SDK, Playwright, CDP, WebDriver, webhook, dan agen didokumentasikan secara terpisah?
• □ Apakah tersedia matriks kompatibilitas browser dan klien yang tepat?
• □ Dapatkah kredensial dibatasi menurut tenant, profil, operasi, audiens, masa berlaku, laju, dan biaya?
• □ Apakah tindakan destruktif, massal, terlihat pihak luar, mengandung rahasia, atau menimbulkan biaya memerlukan kebijakan atau persetujuan lebih ketat?
• □ Apakah pratinjau terikat pada permintaan persis yang akan dijalankan?
• □ Apakah perintah yang mengubah data idempoten atau secara eksplisit menjelaskan hasil yang belum diketahui?
• □ Dapatkah operasi panjang dibatalkan dan dilanjutkan dengan aman?
• □ Apakah pencabutan berlaku saat tugas sedang aktif?
• □ Dapatkah keputusan otomatisasi ditelusuri dalam jejak audit yang sama dengan tindakan manusia?
• □ Apakah keluaran otomatisasi biasa tetap berguna tanpa mengembalikan data sesi mentah?
• □ Apakah pesan kesalahan cukup spesifik untuk pemulihan tanpa membocorkan rahasia?

Uji jalur penolakan. Token hanya baca harus gagal meluncurkan profil. Token dengan cakupan profil harus gagal mengakses folder lain. Kredensial kedaluwarsa tidak boleh diam-diam diperbarui menjadi akses yang lebih luas. Agen tidak boleh dapat mengubah panggilan yang ditolak menjadi persetujuan administrator hanya dengan menulis ulang permintaan.

9. Pengalaman operator dan aksesibilitas

• □ Dapatkah pengguna keyboard mencapai, mengoperasikan, dan meninggalkan setiap kontrol, dialog, tabel, menu, serta tindakan profil?
• □ Apakah fokus terlihat dan berurutan secara logis setelah navigasi, kesalahan, serta perubahan dialog modal?
• □ Apakah label, kesalahan, perubahan status, dan konfirmasi tindakan destruktif berfungsi dengan pembaca layar?
• □ Apakah antarmuka tetap dapat digunakan saat diperbesar dan ukuran teks dinaikkan?
• □ Apakah warna, gerakan, dan batas waktu dapat disesuaikan atau tidak menjadi syarat penggunaan?
• □ Dapatkah operator membedakan organisasi, profil, proxy, lingkungan, dan status risiko yang dipilih tanpa hanya mengandalkan warna?
• □ Dapatkah tindakan massal ditinjau tanpa memaksa pengguna melalui tabel padat yang tidak aksesibel?
• □ Apakah perilaku platform native, notifikasi, pemilih berkas, dialog kredensial, dan dialog pembaruan bekerja secara konsisten?

WCAG 2.2 menyediakan kriteria konten web yang dapat diuji, termasuk pengoperasian keyboard, urutan fokus, visibilitas fokus, ukuran target, identifikasi kesalahan, dan autentikasi yang aksesibel. Produk desktop mungkin memadukan antarmuka native dan web, sehingga pemeriksaan standar yang relevan perlu digabungkan dengan pengujian teknologi bantu pada setiap sistem operasi yang didukung.

10. Kecocokan komersial dan operasional

• □ Apakah biaya anggota, profil tersimpan, profil tersinkron, penyimpanan, lalu lintas, sesi bersamaan, laju API, pekerja otomatisasi, dan tingkat dukungan dijelaskan secara terpisah dan jelas?
• □ Batas mana yang menghentikan penggunaan, menimbulkan biaya tambahan, atau mengikuti ketentuan penggunaan wajar?
• □ Dapatkah perubahan penagihan atau kapasitas terjadi tanpa persetujuan administrator?
• □ Apakah protokol proxy, metode autentikasi, ekstensi, dan lingkungan jaringan yang didukung didokumentasikan?
• □ Apakah kebijakan dukungan mencakup insiden pembaruan browser, kerusakan profil, kegagalan pemulihan, laporan keamanan, dan pemulihan akun?
• □ Apakah status layanan, komunikasi insiden, dan jalur eskalasi benar-benar tersedia serta dipantau?
• □ Apakah kontrak menetapkan pengembalian data, penghapusan, perubahan harga, penangguhan, dan pengakhiran?
• □ Dapatkah Anda keluar tanpa kehilangan bukti yang diperlukan untuk menunjukkan migrasi yang aman?

Hitung biaya berdasarkan puncak pekerjaan bersamaan, perkiraan data tersinkron, volume otomatisasi, dan kebutuhan dukungan. Catat pajak, komitmen tahunan, biaya kelebihan penggunaan, dan tenaga migrasi. Hindari membandingkan hanya angka profil terbesar pada setiap halaman harga.

Rencana uji coba terkontrol

Gunakan akun uji, kredensial sintetis, dan profil yang dibuat khusus untuk evaluasi. Jangan mengimpor cookie produksi hanya agar uji coba terasa realistis.

1. Catat lingkungan. Catat versi aplikasi dan browser, sistem operasi, perangkat keras, jaringan, jenis proxy, kumpulan ekstensi, paket akun, dan tanggal pengujian.
2. Buat dua peran dan beberapa profil. Sertakan administrator, operator dengan akses terbatas, folder terpisah, dan setidaknya satu profil yang tidak boleh diakses operator.
3. Jalankan alur kerja normal. Luncurkan, gunakan, hentikan, serahterimakan, dan buka kembali profil. Catat keadaan yang diharapkan dan yang benar-benar terjadi.
4. Uji penolakan. Coba akses profil di luar cakupan, ekspor, perubahan peran, dan perintah otomatisasi menggunakan identitas terbatas.
5. Uji gangguan. Dengan data sekali pakai, ganggu penghentian browser atau sinkronisasi menggunakan metode yang didukung vendor atau metode lain yang aman. Verifikasi jalur pemulihan.
6. Pulihkan dan bandingkan. Pulihkan snapshot yang diketahui ke salinan baru, verifikasi integritasnya, dan pertahankan salinan saat ini sampai hasil diterima.
7. Cabut akses. Hapus pengguna, perangkat, sesi, dan kredensial layanan; pastikan penolakan di antarmuka serta API, lalu periksa peristiwa auditnya.
8. Periksa portabilitas. Ekspor data yang diizinkan, periksa format terdokumentasinya, impor kembali ke tujuan sekali pakai bila didukung, dan identifikasi yang tidak disertakan.
9. Tinjau aksesibilitas. Selesaikan tugas inti dengan keyboard dan teknologi bantu yang relevan pada setiap platform yang diperlukan.
10. Cocokkan biaya dan klaim. Bandingkan penggunaan sumber daya yang diamati serta tanggapan dukungan dengan penawaran dan kontrak.

Templat catatan keputusan

Persyaratan	Prioritas	Hasil	Bukti dan tanggal	Keterbatasan atau risiko	Penanggung jawab dan tindak lanjut
Contoh: operator tidak dapat mengekspor data sesi	Syarat wajib	Lulus	Uji coba terkontrol, versi X, YYYY-MM-DD	Hanya API; CLI belum diuji	Penanggung jawab keamanan menguji CLI

Tutup evaluasi dengan empat daftar eksplisit:

• syarat wajib yang lulus dengan bukti memadai;
• hal yang perlu perhatian dan diterima oleh penanggung jawab tertentu, beserta tanggal peninjauan;
• butir yang belum diverifikasi;
• kondisi yang memicu evaluasi ulang, seperti mesin browser, penyedia identitas, pembaru, model harga, atau format profil baru.

Tanda bahaya yang umum

Tunda keputusan ketika:

• versi browser tidak dapat diidentifikasi;
• sandbox harus dinonaktifkan untuk penggunaan normal;
• administrator dan otomatisasi berbagi kredensial permanen;
• produk mengandalkan pembagian cookie atau kata sandi mentah untuk serah terima tim;
• API dapat mengekspor rahasia yang diklaim terlindungi oleh antarmuka;
• peristiwa audit tidak menyebut pelaku atau tidak dapat diekspor;
• “cadangan” hanya berarti salinan cloud tersedia, tanpa pemulihan yang pernah dibuktikan;
• vendor tidak dapat menjelaskan penulisan yang terganggu atau akses profil bersamaan;
• alur kerja penting tidak aksesibel dan tidak memiliki alternatif;
• laporan keamanan mengharuskan pengiriman rahasia melalui email biasa; atau
• klaim produk menjanjikan tidak terdeteksi, jaminan akses akun, atau pengelakan penegakan aturan platform.

Hasil “belum diverifikasi” bukan tuduhan. Itu adalah pernyataan tepat tentang bukti yang masih kurang. Biarkan status itu terlihat sampai vendor menyediakan bukti, tim menguji perilakunya, atau penanggung jawab keputusan menerima risikonya.