C2PA untuk Website: Sekarang Manifest Bisa Ditautkan ke HTML

Ada perubahan kecil di C2PA 2.4 yang dampaknya bisa besar untuk publisher web.

HTML sekarang punya mekanisme resmi untuk diasosiasikan dengan C2PA Manifest Store.

Bukan lewat workaround.

Bukan dengan menyimpan metadata provenance hanya di image yang ada di halaman.

Spesifikasi 2.4 menambahkan dua metode untuk HTML:

manifest inline menggunakan `<script type="application/c2pa">`

atau external manifest menggunakan `<link rel="c2pa-manifest">`.

Dan spec menyatakan external manifest via `link` adalah pendekatan yang lebih disukai.

Buat publisher, ini menarik karena Content Credentials mulai bergerak dari file media menuju halaman web sebagai asset yang bisa punya provenance binding sendiri.

Tetapi jangan buru-buru menyimpulkan:

“Berarti tinggal pasang satu tag di WordPress lalu beres.”

Justru di HTML, detail implementasinya lumayan tricky.

HTML Bisa Menjadi Asset C2PA

Selama ini banyak orang mengasosiasikan Content Credentials dengan:

foto,
video,
audio.

Masuk akal karena ecosystem awal provenance memang kuat di media.

C2PA kemudian memperluas support ke berbagai format dokumen.

Di 2.4, HTML secara eksplisit mendapat embedding specification.

Ini berarti sebuah dokumen HTML dapat memiliki C2PA Manifest Store yang terkait dengannya.

Ada dua pola.

Pertama, inline.

Manifest Store di-base64 lalu ditempatkan di `<head>`:

`<script type="application/c2pa">`

Browser akan mengabaikan script type yang tidak dikenal sebagai executable JavaScript.

Jadi manifest bisa berada di dokumen tanpa menjadi code yang dijalankan.

Kedua, external.

HTML memakai:

`<link rel="c2pa-manifest" href="…">`

untuk menunjuk ke external Manifest Store dengan media type `application/c2pa`.

Spec memilih external reference sebagai preferred approach.

Kenapa External Manifest Menarik?

Manifest bisa punya ukuran.

Kalau disimpan inline, HTML menjadi lebih besar.

Dengan external manifest, publisher dapat menyimpan provenance di endpoint terpisah.

HTML hanya membawa reference.

Ini juga lebih natural untuk web architecture.

Namun external tidak berarti lepas dari asset.

Manifest tetap harus punya hard binding ke HTML.

Inilah bagian yang sering terlewat.

Link Bukan Sekadar Link

Jika kita memasang:

`<link rel="c2pa-manifest" href="…">`

itu bukan sekadar pointer informational.

External Manifest Store harus mengandung content binding sesuai hard binding requirement.

Artinya manifest perlu secara kriptografis terikat ke byte representation HTML.

Validator kemudian dapat memeriksa hubungan tersebut.

Kalau HTML berubah, binding dapat invalid.

Jadi implementasi tidak cukup:

buat manifest statis,
pasang link di semua halaman.

Setiap page punya content yang berbeda.

Setiap versi page bisa berbeda.

Manifest harus mengikuti asset yang ditandatangani.

HTML Hashing Itu Sensitif

Spesifikasi 2.4 menyebut sesuatu yang sangat penting untuk CMS.

Hash didefinisikan atas byte representation dokumen yang disimpan.

Jika proses lain me-re-serialize HTML:

mengubah whitespace,
mengurutkan ulang attribute,
mengubah quote style,
atau melakukan transformation,

content binding bisa invalid.

Spec bahkan menyebut CMS, CDN, atau HTML formatter sebagai contoh proses yang bisa mengubah serialization.

Ini practical issue besar.

Website modern jarang mengirim raw HTML yang tidak berubah.

Ada:

CMS rendering,
cache,
minification,
CDN,
edge rewriting,
security proxy,
personalization,
A/B testing,
ad insertion.

Kalau semua ini mengubah byte representation setelah signing, provenance binding bisa gagal.

Karena itu signing point harus dipilih dengan sangat hati-hati.

Sign Setelah Final Serialization

Untuk pipeline yang me-re-serialize HTML, spec merekomendasikan manifest ditambahkan setelah final serialization step, atau external manifest digunakan sebelum final manifest generation dengan workflow yang sesuai.

Buat publisher, terjemahannya:

jangan tanda tangani template terlalu awal.

Tanda tangani representasi final yang benar-benar akan dianggap asset.

Kalau origin server menghasilkan HTML lalu CDN minify, signing di origin mungkin invalid setelah CDN.

Kalau CDN tidak mengubah byte, situasi berbeda.

Kalau page personalized per user, kita punya problem lebih kompleks lagi.

Apakah setiap personalized variant menjadi asset berbeda?

Secara binding, potentially yes.

Ini alasan adopsi HTML provenance perlu architecture design, bukan plugin dekoratif.

Inline Manifest Punya Exclusion Khusus

Kalau manifest disimpan inline di `<script type="application/c2pa">`, ada circular problem:

hash dokumen perlu mencakup dokumen,
tetapi dokumen mencakup manifest yang membawa hash.

C2PA menyelesaikan dengan exclusion range.

Untuk inline HTML, `c2pa.hash.data` assertion mengecualikan seluruh script element manifest dari hashing.

Hash dihitung atas dokumen setelah exclusion tersebut.

Untuk external link, manifest tidak tertanam di body sehingga hash dihitung atas keseluruhan document.

Detail seperti ini penting bagi implementer.

Jangan bikin base64 sendiri lalu berharap validator menerima.

Gunakan SDK atau tooling yang sesuai 2.4.

Validator Mencari di `<head>`

Untuk HTML, validator melihat `head`.

Ia mencari:

script dengan `type="application/c2pa"`

atau:

link dengan `rel="c2pa-manifest"`.

Dokumen tidak boleh punya lebih dari satu association.

Tidak boleh dua script C2PA.

Tidak boleh script dan link sekaligus.

Jika multiple ditemukan, validator melaporkan failure terkait multiple manifests.

Ini juga meaningful untuk CMS plugin ecosystem.

Jangan sampai dua plugin provenance aktif bersamaan dan masing-masing menyisipkan manifest.

Site mungkin terlihat normal di browser, tetapi validation gagal.

External URI Resolution Bersifat Opsional bagi Validator

Ini nuance penting.

Kalau validator menemukan link external, resolution URI-nya optional.

Artinya kita tidak boleh berasumsi setiap consumer selalu fetch remote manifest.

Implementer perlu memikirkan durability dan availability.

Manifest URL harus stabil.

Content type benar.

Access tidak membutuhkan session aneh.

Cache policy jelas.

Kalau endpoint hilang, external reference menjadi kurang useful.

Provenance infrastructure butuh operasi jangka panjang.

Bukan sekadar publish hari ini.

Apa Bedanya dengan Schema.org JSON-LD?

Sangat berbeda.

Schema.org biasanya menjelaskan entity dan page semantics:

Organization.
Article.
Person.
Product.

C2PA manifest menjelaskan provenance dan authenticity information dengan cryptographic binding.

Keduanya bisa sama-sama berada di `<head>`.

Satu mungkin menggunakan JSON-LD script.

C2PA inline memakai script `application/c2pa`.

Tapi tujuan dan trust model berbeda.

Schema.org tidak otomatis tamper-evident.

C2PA bukan semantic SEO vocabulary pengganti Schema.org.

Publisher bisa memakai keduanya.

Satu untuk machine-understandable content semantics.

Satu untuk provenance.

Ini dua layer.

Apakah C2PA HTML Cocok untuk WordPress?

Secara konsep, iya.

Secara implementation, harus realistis.

WordPress page dapat berubah karena:

theme,
plugin,
dynamic block,
related posts,
comment count,
ad,
timestamp,
cache busting,
personalization.

Jika HTML output berubah setelah manifest dibuat, binding dapat invalid.

Pendekatan yang lebih feasible mungkin:

pilih page stabil,
gunakan static-ish rendering,
sign setelah cache final,
pastikan CDN tidak rewrite,
atau buat dedicated evidence page dengan controlled output.

Jangan mulai dari homepage yang setiap menit berubah.

Mulai dari asset web yang stabil.

Ini berlaku juga untuk GEO.or.id.

Kalau ingin eksperimen C2PA pada website, evidence report atau static research page lebih masuk akal daripada seluruh site langsung.

C2PA untuk HTML Bisa Menjadi Menarik bagi Evidence Publishing

Bayangkan GEO.or.id menerbitkan:

AI visibility observation report.

Halaman punya timestamp.

Content final.

Screenshot evidence.

Methodology.

Reviewer.

Manifest HTML dapat memberi provenance pada page tersebut sebagai digital asset.

Image screenshot juga dapat punya Content Credentials sendiri jika workflow mendukung.

Sekarang publisher punya dua layer:

page provenance,
asset provenance.

Ini tidak membuat evidence otomatis benar.

Tetapi chain of custody lebih jelas.

Kalau page berubah, binding akan menunjukkan perubahan.

Kalau screenshot punya provenance, history asset dapat dianalisis.

Untuk evidence infrastructure, ini menarik.

Jangan Klaim AI Search Akan Memproses Tag Ini

Sekali lagi, temptation GEO.

Karena manifest sekarang ditautkan ke HTML, mudah berkata:

“AI crawler bisa baca dan lebih percaya.”

Secara teknis, validator bisa menemukan association.

Tetapi tidak ada dasar universal bahwa AI search engine tertentu akan memakai `rel="c2pa-manifest"` sebagai ranking atau citation signal.

Per Agustus 2026, framing yang aman:

C2PA 2.4 membuat provenance HTML machine-discoverable dalam standard.

Platform dapat mengimplementasikan consumer jika mereka memilih.

Apakah Google, ChatGPT, Gemini, Perplexity, atau engine lain menggunakannya untuk ranking/citation harus dibuktikan per platform.

Jangan ubah standard support menjadi ranking claim.

Operational Risk: Manifest Endpoint Jadi Infrastructure

Kalau memakai external manifest, endpoint `.c2pa` harus diperlakukan serius.

Availability.

Backup.

Retention.

Versioning.

Access control.

Content type.

HTTPS.

Monitoring.

Kalau page tetap hidup tetapi manifest server mati, provenance experience rusak.

Kalau manifest salah version, validator bisa gagal.

Kalau manifest diganti tanpa binding yang benar, validation akan menunjukkan masalah.

Jadi Content Credentials untuk web membawa tanggung jawab operasi.

Ia bukan snippet marketing sekali pasang.

Ada satu operational detail yang juga perlu dicatat: versioning manifest dan page harus bergerak bersama.

Kalau publisher memperbarui satu paragraf, asset HTML berubah. Manifest lama tidak boleh diperlakukan seolah masih merepresentasikan versi baru. Workflow perlu menghasilkan credential baru atau menjalankan proses yang sesuai untuk versi asset tersebut.

Dengan kata lain, provenance HTML membuat discipline publishing menjadi lebih eksplisit.

Start Kecil

Publisher yang mau eksperimen bisa membuat pilot:

satu static article,
satu evidence page,
satu research report,
atau satu press release penting.

Workflow:

finalize HTML,
generate manifest,
host external manifest,
inject `link rel="c2pa-manifest"`,
validate,
test melalui production delivery path,
pastikan CDN tidak mengubah bytes,
monitor setelah deploy.

Kemudian edit page.

Lihat bagaimana binding berubah.

Re-sign.

Test lagi.

Belajar dari lifecycle.

Jangan langsung 50 ribu page.

Provenance di Web Akhirnya Mendapat Tempat yang Lebih Natural

Perubahan HTML di C2PA 2.4 terlihat kecil karena cuma satu `script` atau `link`.

Di balik tag itu ada shift besar.

Website tidak lagi hanya container yang menampilkan file dengan provenance.

Dokumen HTML sendiri bisa menjadi asset dengan C2PA association.

Ini membuka kemungkinan untuk:

publisher pages,
reports,
evidence,
documentation,
research,
official statements,
dan structured web publications

memiliki provenance yang lebih formal.

Tetapi implementation reality tetap kompleks.

Dynamic HTML.

CDN.

Caching.

Personalization.

Re-serialization.

Semua bisa memengaruhi hard binding.

Jadi kalau ada satu prinsip:

jangan perlakukan `rel="c2pa-manifest"` seperti meta tag SEO.

Ia bukan deklarasi ringan.

Ia pointer ke provenance object yang harus terikat secara kriptografis dengan asset HTML.

Ketika dipasang benar, value-nya jauh lebih besar daripada markup dekoratif.

Ketika dipasang asal, validator akan menunjukkan bahwa infrastructure di belakangnya belum siap.