Press ESC to close

Dari Steam hingga Chrome: Mengapa Firefox Add-Ons Meminta “Resep Dapur”?

Sekitar awal 2023, saat saya masih mengembangkan versi awal NetMeter Web, seorang teman bertanya santai:

“Nanti upload ke Firefox juga kan?”

Saya jawab tanpa mikir panjang: PASTI.
Saat itu, sejujurnya saya memang belum masuk dan membaca ke detail kebijakan publishing Firefox Add-ons.

Yang ternyata Firefox menulis hal seperti ini:

Sumber: https://extensionworkshop.com/documentation/publish/source-code-submission/

Dan itu memang tertulis di panduan resmi Firefox Add-ons:
Jika kode extension sulit dibaca manusia (misalnya karena minification atau bundling), developer diminta mengunggah full source code untuk keperluan review.

Pada saat itu, saya mulai bertanya:

Bagaimana jika sebuah extension memiliki business logic bernilai yang sengaja di-minify (bukan di-obfuscate), bukan untuk menyembunyikan perilaku, tetapi untuk melindungi desain dan algoritma internal?

Terlebih untuk extension yang sepenuhnya local-first (misal extension Form Recover ini), risiko kebocoran tetap perlu dipertimbangkan, bukan karena tidak percaya reviewer, tetapi karena sifat produknya sendiri.


Bukan Saya Saja yang Ragu

Menariknya, keraguan ini bukan hanya milik developer indie. Di salah satu diskusi publik, seorang perwakilan perusahaan (Intovation) menulis:

Petikan diskusi dari penulis forum: https://discourse.mozilla.org/t/submitting-addon-source-code/124035

“Our company has invested significantly… and we are hesitant to submit it for review without exploring potential alternatives.”

Perhatikan dua kata kunci di situ:

  • invested significantly (baca: berinvestasi habis-habisan pada produk)
  • hesitant (baca: ragu-ragu karna alasan upload source code)

Kalau perusahaan yang sudah keluar biaya R&D besar saja ragu, rasanya wajar jika developer kecil juga berhati-hati.


Bagaimana Marketplace Lain Melakukan Review?

Di titik ini saya jadi penasaran, apakah marketplace lain juga seketat ini soal source code?

Mari kita lihat beberapa contoh Marketplace software atau aplikasi dari yang klasik sampai modern.


1. Nokia – Symbian / Ovi Store 📱

Era: 2000–2012

  • Yang di-submit: file binary .SIS / .SISX
  • Proses: Symbian Signed
  • Mekanisme: developer membeli sertifikat (Publisher ID), lalu binary ditandatangani secara digital

Nokia tidak pernah meminta source C++ atau Python mentah. Mereka memverifikasi identitas developer, bukan isi kode.


2. BlackBerry App World

Era: 2008–2013

  • Yang di-submit: .COD atau .BAR
  • Proses: Sangat ketat di signing keys

BlackBerry terkenal paranoid soal keamanan, tapi pendekatannya jelas dan karna kriptografi dan identitas, bukan membedah source code developer.

Blackberry tidak pernah meminta Source Code developer, karna itu bertentangan dengan filosofi mereka sendiri.


3. Samsung Tizen Store

Era: 2012–sekarang

  • Yang di-submit: .TPK atau .WGT
  • Proses: automated scan + manual UI test

Samsung tidak pernah meminta source code Netflix, Disney+, atau app besar lain.
Mereka fokus ke perilaku aplikasi, bukan resep dapurnya.


4. Java ME (J2ME) ☕

Era: 1998–2010

  • Yang di-submit: .JAR dan .JAD
  • Proses: operator-based verification

Bahkan di era HP jadul, yang diuji adalah fungsi dan izin, bukan file .java mentah.

5. Chrome Webstore

Era: 2010–Sekarang

  • Yang di-submit: .ZIP
  • Proses: Automated review + behavioral analysis + policy enforcement

Fokus audit mereka adalah: apa yang extension lakukan, bukan bagaimana algoritmanya ditulis.

Pendekatan ini memungkinkan Chrome menampung extension bernilai komersial tinggi, sekaligus tetap menjaga keamanan user melalui sandbox, permission model, dan penegakan policy yang ketat.


6. Android (Google Play)

Era: 2008–sekarang

  • Yang di-submit: .APK / .AAB
  • Review: automated + behavioral analysis

Di Google Play, ada aplikasi bernilai jutaan bahkan miliaran dolar. Dan Google tidak pernah meminta full source code.

Review di Google Play mengaudit apa yang aplikasi lakukan, bukan bagaimana algoritmanya ditulis.


7. iOS (Apple App Store)

Era: 2008–sekarang

  • Yang di-submit: .IPA
  • Review: sangat ketat di behavior, UI, dan privacy

Apple terkenal sangat galak soal review, tapi ada satu hal konsisten, dimana source code tetap milik developer.

8. Huawei AppGallery (HarmonyOS)

Konteks: Huawei di-ban Amerika pada tahun 2019, lalu membuat OS sendiri (HarmonyOS NEXT) yang lepas total dari Android. Ini adalah ekosistem baru terbesar di dekade ini.

  • Yang di-submit: file binary .HAPP atau .APP
  • Review: Mereka sangat ketat di Copyright & Identitas (wajib verifikasi entitas bisnis/paspor)

Mirip dengan perilaku market-place besar lain, HarmonyOS atau Huawei tidak pernah meminta “resep dapur” kodingan kita.

9. Steam Publisher

Konteks: industri game adalah salah satu industri dengan tingkat perlindungan IP (intellectual property). Di dunia game development, obfuscation, anti-tamper, dan asset protection adalah standar, bukan pengecualian.

Jika Steam meminta developer game untuk menyerahkan full source code, bisa dibayangkan dampaknya bagi industri, terutama untuk game AAA dengan aset dan engine bernilai jutaan dolar.

Steam melakukan review melalui:

  • binary analysis
  • behavioral checks
  • compliance terhadap kebijakan platform

Bukan dengan meminta “resep dapur” engine, shader, atau gameplay logic milik developer.

Pendekatan ini masuk akal, karena di industri game, source code dan asset adalah aset inti perusahaan yang nilainya sering kali jauh melampaui platform distribusinya sendiri.


Sebagai Penutup

Dengan melihat semua ini, rasanya wajar jika sebagian developer merasa model review Firefox cukup berbeda arah dengan praktik industri secara umum.

Bukan berarti Firefox salah, atau developer lain benar. Tapi jelas ada perbedaan filosofi:

  • Firefox: audit lewat keterbukaan kode
  • Marketplace lain: audit lewat perilaku aplikasi

Firefox adalah browser legendaris, dan kebijakan ketat mereka kemungkinan besar lahir dari niat baik: melindungi pengguna.

Namun di dunia extension maupun aplikasi modern saat ini yang sering kali sudah menjadi produk dengan nilai bisnis, perbedaan pendekatan ini layak untuk didiskusikan secara terbuka.

Bagaimana menurut kalian?


Catatan:
Artikel ini ditulis pada Januari 2026, ketika Firefox Add-ons masih mewajibkan pengunggahan source code untuk extension dengan kode yang di-minify atau dibundle. Kebijakan dapat berubah di masa depan seiring perkembangan ekosistem dan regulasi platform.

Muhammad K Huda

A non exhausted blogger person within fullstack engineer (spicy food), open source religion, self-taught driver and maybe you know or don't like it. Simply says, Hello from Me!

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Cek untuk notifikasi e-mail jika komentar dibalas.

This site uses Akismet to reduce spam. Learn how your comment data is processed.