สิ่งที่ manifest ของ Chrome ส่วนขยายบอกเราได้จริง และสิ่งที่มันบอกไม่ได้

ส่วนขยาย Chrome ทุกตัวจะมาพร้อมไฟล์ manifest.json ซึ่งแทบจะเป็นตัวกำหนด “เพดานความสามารถ” ระดับเบราว์เซอร์ไว้เกือบทั้งหมด ไม่ว่าจะเป็น API ที่ร้องขอ รูปแบบโฮสต์ สคริปต์ฝังหน้าแบบคงที่ สิทธิ์แบบขอเพิ่มภายหลัง และปลายทางภายนอกที่อนุญาตให้สื่อสารได้ ไฟล์นี้เป็นไฟล์สาธารณะในแพ็กเกจที่คุณติดตั้งเข้าไป มัน ไม่ได้ ยืนยันว่ารันไทม์โค้ดใช้ความสามารถที่ประกาศไว้จริงไหม ข้อมูลใดถูกส่งออกจากเครื่อง และการเข้าถึงบัญชีใดเกิดจากการล็อกอินบนเว็บแยกต่างหากหรือไม่

ผมอ่านส่วนขยายสำหรับงาน scraping และระบบอัตโนมัติบนเบราว์เซอร์ทั้งสิบตัวที่คัดมาเพื่อการตรวจสอบนี้ รวมถึงของ Thunderbit เองด้วย ภาพรวมต่างกันชัดเจนมาก ตัวหนึ่งไม่ประกาศสิทธิ์เข้าถึงเว็บไซต์ใดๆ แบบถาวร แต่อีกตัวประกาศสิทธิ์ถึง 13 รายการ รวม clipboardRead ด้วย และ Thunderbit เป็นส่วนขยายเดียวในชุดนี้ที่ประกาศ debugger ซึ่งเป็นความสามารถในการแนบ CDP ที่มีโปรไฟล์ความเสี่ยงต่างจากการเข้าถึงหน้าเว็บ, OAuth หรือสคริปต์ที่ผู้ใช้ส่งเข้ามาเอง

ทั้งหมดนี้ไม่ใช่การกล่าวหา สิทธิ์ที่กว้างมักเป็นวิธีที่ซื่อสัตย์ที่สุดในการสร้างฟีเจอร์บางอย่าง ส่วนสิทธิ์ที่แคบก็อาจแปลว่าผลิตภัณฑ์ทำได้ไม่เยอะกว่า ประเด็นคือความแตกต่างมันใหญ่จริง ถูกเผยแพร่อยู่แล้ว และไม่เคยถูกพาเข้าไปอยู่ในตารางเปรียบเทียบ

วิธีที่ตรวจสอบนี้ทำ

แต่ละส่วนขยายถูกดาวน์โหลดเป็นไฟล์ .crx จาก endpoint อัปเดตของ Google เอง — URL เดียวกับที่ Chrome ใช้ — จากนั้นจึงแตกไฟล์และวิเคราะห์ ไม่มีการติดตั้งส่วนขยายใดๆ และไม่มีการรันโค้ดของส่วนขยายใดๆ นี่คือการอ่านไฟล์ JSON ไฟล์หนึ่งเท่านั้น

การดาวน์โหลดถูกเว้นจังหวะไว้ประมาณหนึ่งคำขอต่อทุกสองวินาที ทุกไฟล์ .crx, SHA-256 และ manifest.json ที่แตกออกมาถูกเก็บไว้เป็นหลักฐานประกอบ Thunderbit ถูกประมวลผลผ่านสคริปต์เดียวกับอีกเก้าตัว ไม่ได้ใช้ช่องทางพิเศษใดๆ ดังนั้นแถวของมันจึงถูกคำนวณแบบเดียวกับตัวอื่นทุกประการ

การวิเคราะห์ใช้หลักฐานอยู่สองประเภทและแยกจากกันชัดเจน:

• พฤติกรรมคงที่ที่ประกาศไว้: รูปแบบโฮสต์และรายการ content_scripts รวมถึง matches, run_at และ all_frames
• ความสามารถที่โค้ดรันไทม์เข้าถึงได้: API ที่ระบุใน permissions หรือ optional_permissions ข้อความเหล่านี้บอกว่าโค้ด อาจ ขอใช้หรือเรียกอะไรได้บ้าง ไม่ได้บอกว่ามันใช้จริง

ไม่มีการให้คะแนนเชิงอันดับแบบ “ทรงพลังที่สุด” debugger, userScripts, การเข้าถึงโฮสต์แบบกว้าง, OAuth scopes, การเข้าถึงคลิปบอร์ด และการส่งข้อความภายนอก ล้วนเปิดเผยข้อมูลคนละแบบและต้องมีเงื่อนไขก่อนใช้งานต่างกัน การเอามาเทียบกันต้องมี threat model ซึ่งการตรวจแบบอ่านเฉพาะ manifest นี้ไม่ได้ให้มา

ขนาดด้านล่างเป็นขนาดรวมหลังแตกไฟล์ หน่วย MiB (2²⁰ ไบต์) รวมจากรายการใน ZIP

ข้อมูล ณ 2026-07-29 ส่วนขยายมีการอัปเดตได้ โปรดตรวจซ้ำก่อนอ้างอิง

สิ่งที่ manifest ทั้งสิบตัวประกาศ

เอกสารอ้างอิงทางการ: คู่มือการประกาศสิทธิ์ของ Chrome

ยังมีอีกสองตัวที่อยู่ในรายชื่อคัดเลือก แต่ไม่ได้อยู่ในตาราง ด้วยเหตุผลที่ควรพูดถึงแยกต่างหาก

ความต่างนี้เป็นการออกแบบ ไม่ใช่ผลจากขนาดไฟล์

Agenty ไม่ได้ประกาศ host permissions และไม่ได้มี content scripts เลย สิทธิ์ทั้งสี่ของมันคือ activeTab, scripting, identity และ identity.email activeTab เป็นสิทธิ์แบบแคบ: มันให้เข้าถึงแท็บปัจจุบัน หลังจาก คุณคลิกส่วนขยายเท่านั้น และใช้ได้จนกว่าคุณจะเปลี่ยนหน้า ไม่มีอะไรทำงานบนหน้าเว็บของคุณถ้าคุณไม่เรียกใช้มันเอง ทั้งหมดนี้อยู่ใน 2.2 MiB

Axiom.ai ประกาศ http://*/* และ https://*/*, inject content scripts ที่ match <all_urls> และแตกไฟล์ออกมาเป็น 37.1 MiB จาก 232 ไฟล์ — ใหญ่กว่า Agenty ถึง 17 เท่า พร้อมสิทธิ์เข้าถึงทุกหน้าที่คุณเปิดแบบต่อเนื่อง

Hexomatic อยู่ในกลุ่มเดียวกับ Agenty: มีสองสิทธิ์ (storage, tabs) ไม่มี host permissions และ content scripts จำกัดอยู่แค่สองโดเมนของตัวเอง

Clay for Chrome เป็นอีกแบบที่ควรแยกพิจารณา: มันประกาศ *://*/* เป็น host permission แต่ inject content scripts เฉพาะบนโดเมนของตัวเอง สิ่งที่ “ทำได้” แบบถาวรกว้างมาก แต่พฤติกรรมอัตโนมัติจริงกลับแคบ ตารางสิทธิ์อย่างเดียวทำให้สองอย่างนี้ปนกัน

ห้าจากสิบตัวเข้าถึงไฟล์บนเครื่องคุณได้

file:/// ไม่ใช่เว็บไซต์ แต่มันคือไฟล์ในเครื่องคุณที่ถูกแสดงในแท็บเบราว์เซอร์ — PDF ที่เปิดไว้, ไฟล์ HTML export, ใบแจ้งหนี้ที่ดาวน์โหลดมา

เอกสารอ้างอิงทางการ: Chrome match-pattern documentation

สามส่วนขยายบอกไว้ตรงๆ อีกสองตัวเข้าถึงได้โดยไม่ระบุคำนี้: <all_urls> ครอบคลุม scheme file: ด้วย

http://*/* และ https://*/* ไม่ครอบคลุม file://; <all_urls> กับ *://*/* ก็ไม่เหมือนกันในจุดนี้เช่นกัน ทั้งห้าตัวนี้เข้าถึง scheme ดังกล่าวได้ผ่านวิธีใดวิธีหนึ่งจากสองแบบนั้น — ไม่ใช่เพราะ wildcard แบบที่เลือกเอง

Chrome บังคับให้ทุกอย่างนี้อยู่หลังสวิตช์ “Allow access to file URLs” แบบแยกต่อส่วนขยาย ซึ่ง ปิดอยู่เป็นค่าเริ่มต้น ดังนั้นการประกาศจึงเป็นการ “ขอ” ไม่ใช่ “ได้รับแล้ว” นับแบบตรงไปตรงมาคือห้าจากสิบ และ สองในห้าตัวนั้นไม่เคยเขียน file:// ไว้ใน manifest เลย: Axiom.ai และของเรา

การนับนี้รวม web_accessible_resources ด้วย ไม่ใช่แค่ content scripts และ host permissions เท่านั้น Table Capture ระบุ file://*/* ไว้ตรงนั้น หากตัดบล็อกนี้ออกไปจะทำให้มันไปอยู่ผิดกลุ่มราวกับเป็นส่วนขยายที่เข้าถึงไฟล์ได้โดยไม่ต้องระบุ scheme

สิทธิ์ที่คุณไม่เห็นจนกว่าจะมีการร้องขอ

optional_permissions ถูกประกาศไว้ล่วงหน้า แต่จะถูกร้องขอในรันไทม์ จึงไม่ปรากฏใน prompt ตอนติดตั้ง มีสองส่วนขยายที่ใช้มัน และตัวหนึ่งสำคัญมาก

userScripts จะยังไม่พร้อมใช้งานจนกว่าจะมีการร้องขอ และคนที่ดูแค่จำนวน permission จะมองไม่เห็นมัน

มันยังมี gate เพิ่มอีกชั้นหนึ่ง ซึ่งสิทธิ์อื่นๆ ในการตรวจครั้งนี้ไม่มี และถ้าไม่พูดถึงตรงนี้จะทำให้ดูเกินจริง การประกาศ userScripts ยังไม่พอจะใช้ได้: Chrome ต้องมีการกระทำจากผู้ใช้ก่อน ก่อน Chrome 138 จะต้องเปิด Developer Mode ทั่วทั้งระบบที่ chrome://extensions ตั้งแต่ Chrome 138 เป็นต้นมา จะเป็นสวิตช์ต่อส่วนขยายชื่อ Allow User Scripts บนหน้ารายละเอียดของส่วนขยายนั้น และปิดไว้เป็นค่าเริ่มต้น ดังนั้นสำหรับการติดตั้งปกติ ความสามารถนี้ถูกประกาศไว้แต่ยังไม่ทำงาน ข้อเท็จจริงที่แม่นคือ Table Capture สามารถ ทำให้ API userScripts ใช้งานได้หลังผู้ใช้เปิด gate ของ Chrome การตรวจนี้ไม่ได้วัดว่าผู้ใช้ไปที่หน้าตั้งค่านั้นบ่อยแค่ไหนหรือเปิดสวิตช์หรือไม่

ทั้งคู่ไม่ซ่อนอะไรไว้; ทั้งสองอย่างอยู่ใน manifest ตารางที่ละเลยบล็อก optional จึงประเมินผลิตภัณฑ์สองตัวต่ำกว่าความเป็นจริง

จังหวะการฉีด ไม่ใช่แค่ขอบเขต

เวลา ที่ content script ถูก inject ก็มีผลและเปลี่ยนภาพรวม document_start คือ hook ที่เร็วที่สุดที่ Chrome มีให้ ส่วน all_frames จะเข้าถึง embedded จากบุคคลที่สามด้วย

ทั้งหมดในชุดนี้ที่ inject แบบคงที่ลงทุกเฟรม เรียงตามเวลาที่ประกาศไว้:

Table Capture และ Listly ใช้ hook ที่เร็วที่สุดร่วมกับ match pattern ที่กว้าง Axiom.ai และ Clay for Chrome ใช้ timing เดียวกันแต่เฉพาะบนโดเมนของตัวเอง — ความดุดันเท่ากัน แต่เป้าหมายแคบ

สำหรับการประกาศแบบคงที่ <all_urls> พร้อม all_frames คือเพดานความกว้างของการ match และทั้ง Table Capture กับ Thunderbit อยู่ตรงนั้น แต่เวลาที่ประกาศต่างกัน: Table Capture ใช้ document_start; content script แบบคงที่ของ Thunderbit ใช้ document_end ส่วน API ที่รันไทม์เข้าถึงได้เป็นอีกคลาสของความสามารถ และสรุปจากตารางนี้ไม่ได้

จำนวน permission อย่างเดียวเป็นสถิติที่สรุปได้แย่ Table Capture ประกาศสี่สิทธิ์ — น้อยกว่าหลายตัวในนี้ — แต่ inject ที่ document_start ลงทุกเฟรมบน <all_urls> และยังมี userScripts เมื่อร้องขอ

ใครมีสิทธิ์ส่งข้อความถึงส่วนขยายได้

externally_connectable ควบคุมว่าเว็บเพจหรือส่วนขยายอื่นใดบ้างที่จะส่งข้อความตรงไปยัง background script ของส่วนขยายได้ ค่าเริ่มต้นของมันไม่ค่อยเป็นไปตามสัญชาตญาณ

การไม่ใส่คีย์นี้เลยคือค่าที่เปิดกว้างกว่า ค่าเริ่มต้นของ Chrome เมื่อ externally_connectable ไม่อยู่ใน manifest คือ ส่วนขยายใดๆ ก็เชื่อมต่อได้ แต่เว็บเพจไม่ได้ การประกาศมันจึงเป็นการ จำกัด การเข้าถึง

ถ้าอ่านแบบนี้ ตารางจะพลิกความหมาย:

กฎของ Chrome มี สองชั้น จากเอกสารอ้างอิงของ manifest:

ค่าที่เปิดกว้างเป็นค่าเริ่มต้นเกิดจาก การไม่มีคีย์ทั้งก้อน เท่านั้น เมื่อมีคีย์แล้ว ทั้งสองฟิลด์ย่อยจะเริ่มต้นที่ปิด และการระบุค่าจะเป็นการขยายแต่ละช่องทาง

Axiom.ai ประกาศคีย์แต่ใส่เฉพาะ matches ดังนั้น ids จึงไม่ถูกตั้งค่า ซึ่งหมายความว่า ไม่มีส่วนขยายใดส่งข้อความถึงมันได้ — ช่องทางจาก extension ปิดอยู่ ไม่ได้เปิดทิ้งไว้ สิ่งที่มันเปิดคือ web origins 7 แห่ง ซึ่งมีเพียงหนึ่งเดียวที่เป็นโดเมนของ Axiom: อีกสองแห่งระบุเจ้าของไม่ได้ (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*) ส่วนที่เหลือคือ localhost, 0.0.0.0, โฮสต์ของ Google APIs และแพลตฟอร์มโซเชียลขนาดใหญ่หนึ่งแห่งที่มันไม่ได้เป็นผู้ดำเนินการ

Hexomatic เปิดช่องทางจาก extension ไปยัง IDs ที่ระบุไว้ 8 ตัว เมื่อมีคีย์แล้ว baseline คือ extension ศูนย์ตัว การระบุ 8 ตัวจึงขยายเป็น 8 ตัว ส่วน matches อีก 6 รายการก็ขยายช่องทางอีกด้านจากไม่มีให้มี สิ่งที่น่าสังเกตคือ 2 ใน 6 นั้นคือ http://localhost:8000/* และ http://localhost:3000/* ผ่าน HTTP ธรรมดา — อะไรก็ตามที่ตอบบนพอร์ตเหล่านี้บนเครื่องผู้ใช้จะอยู่ในรายการอนุญาต

เจ็ดในสิบตัวละคีย์นี้ไปเลย รวมถึงของเรา และทั้งเจ็ดตัวนี้จึงอยู่บนค่าเริ่มต้นแบบเปิดสำหรับการส่งข้อความจาก extension ไปยัง extension ส่วนสองตัวปิดช่องทางนี้: Magical ปิดอย่างชัดเจนด้วย ids: [] และ Axiom.ai โดยการประกาศคีย์แต่ไม่ระบุ ids ส่วน Magical เป็นตัวเดียวที่ปิด ทั้งสองช่อง พร้อมกัน

บรรทัดสุดท้ายนี้เองคือเหตุผลที่ต้องอ่าน manifest ไม่ใช่นับแค่ permission ส่วนขยายเดียวกันอาจกว้างมากในแกนหนึ่ง แต่กลับเข้มที่สุดในชุดนี้อีกแกนหนึ่ง

แกนที่ไม่มีใครนับ: OAuth scopes

manifest สามารถมีบล็อก oauth2 ได้ และ scopes ข้างในนั่นคือการเข้าถึงบัญชีของคุณกับบริษัทอื่น — เป็นความสามารถคนละแบบกับสิ่งด้านบน และไม่มีการนับ permission ไหนสะท้อนได้

เอกสารอ้างอิงทางการ: รายการ Google OAuth 2.0 scopes

https://www.googleapis.com/auth/drive คือ scope ที่กว้าง Google มี scope ที่แคบกว่านี้ชื่อ drive.file ซึ่งให้เข้าถึงเฉพาะไฟล์ที่แอปสร้างขึ้นเองหรือไฟล์ที่ผู้ใช้เลือกเองอย่างชัดเจน; แต่ auth/drive คือมองเห็น แก้ไข สร้าง และลบได้ทั่วทั้ง Drive ของผู้ใช้ ส่วน auth/spreadsheets มีลักษณะเดียวกันกับทุก spreadsheet ที่บัญชีเข้าถึงได้ Axiom.ai และ Table Capture จับคู่ scope ของบัญชี Google เข้ากับการเข้าถึงหน้าเว็บแบบ <all_urls> ด้วย

ตารางนี้มีข้อจำกัดสองข้อในการตีความ Scope คือ “ขอ” ไม่ใช่ “ได้จริง” — Google จะแสดงหน้าขออนุญาตและผู้ใช้สามารถปฏิเสธได้ และส่วนขยายอาจไม่เรียกใช้ API เลยก็ได้ อีกอย่างคือ manifest มองเห็นเฉพาะ OAuth ที่ทำผ่าน flow ของ Chrome identity เท่านั้น ถ้าส่วนขยายส่งคุณไปหน้า sign-in บนเว็บแทน มันจะไม่ประกาศอะไรตรงนี้เลย เลขศูนย์ทั้งเจ็ดหมายถึง “ไม่ได้ร้องขอในไฟล์นี้” ไม่ได้หมายถึง “ไม่มีสิทธิ์เข้าถึงบัญชี Google ของคุณ” — รวมถึงของเราด้วย ซึ่งเป็นเหตุผลว่าทำไมแกนนี้จึงถูกรายงาน ไม่ได้ถูกกล่าวอ้างว่าแคบ

ส่วนขยายของเราเอง เมื่อวัดด้วยสเกลเดียวกัน

Thunderbit 4.6.4 ถูกส่งผ่าน parser ของ manifest เดียวกับอีกเก้าตัว ไฟล์แพ็กเกจมีขนาด 15.9 MiB หลังแตกออกเป็น 78 ไฟล์

พฤติกรรมคงที่ที่ประกาศไว้: มี <all_urls> อยู่ทั้งใน host permissions และในส่วน match ของ content script สคริปต์แบบคงที่รันใน all_frames ที่ document_end เนื่องจาก <all_urls> ครอบคลุม file: manifest นี้จึงสามารถเข้าถึงไฟล์ในเครื่องได้หลังผู้ใช้เปิดสวิตช์อนุญาตไฟล์ของ Chrome แล้ว Thunderbit ยังละ externally_connectable ไว้ด้วย ดังนั้นค่าเริ่มต้นของ Chrome จึงอนุญาตข้อความจากส่วนขยายใดก็ได้ แต่ไม่ให้เว็บเพจส่งถึง

เพดานความสามารถของรันไทม์: อาร์เรย์ permissions มีสตริง 9 ตัว: activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups และ tabs Chrome รู้จัก 8 ตัวนี้ว่าเป็น permission; commands เป็นคีย์ระดับบนของ manifest ไม่ได้มีผลในฐานะรายการในอาร์เรย์นี้ Thunderbit เป็นส่วนขยายเดียวในชุดนี้ที่ประกาศ debugger ซึ่งสามารถแนบ CDP ไปยังแท็บได้ manifest ยังเปิดให้ scripting สำหรับการลงทะเบียนในรันไทม์ด้วย API เหล่านี้สร้างความสามารถมากกว่าแถว static document_end แต่การอ่าน manifest อย่างเดียวไม่สามารถยืนยันได้ว่า Thunderbit เรียกเมธอด CDP ใดจริง หรือไปลงทะเบียนสคริปต์เวลาใด

ความต่างนี้กันไม่ให้เราเปรียบเทียบแบบลวงๆ หลายแบบ การไม่มี cookies ที่แคบกว่าไม่ได้บอกว่าโค้ดที่มี debugger จะเข้าถึงอะไรไม่ได้ การไม่มี clipboardRead ก็ไม่ใช่หลักฐานว่าคลิปบอร์ดเข้าถึงไม่ได้ ในทางกลับกัน การมี debugger ก็ไม่ใช่หลักฐานว่ามีการใช้เส้นทางนั้นจริง การตอบคำถามพวกนี้ต้องอาศัยการอ่าน source หรือ tracing ตอนรัน ซึ่งการตรวจครั้งนี้ไม่ได้ทำ

ในเครื่องมือนี้ Thunderbit กว้างในแง่การเข้าถึงไซต์แบบคงที่, เป็นหนึ่งเดียวในชุดที่ประกาศ debugger และอยู่บนค่าเริ่มต้นของ Chrome สำหรับการส่งข้อความระหว่างส่วนขยาย ไม่มีการจัดอันดับ “แข็งแรงที่สุด” แบบหนึ่งเดียว เพราะการตรวจนี้ไม่ได้ให้ threat model กลางสำหรับ CDP, OAuth, userScripts, คลิปบอร์ด และการเข้าถึงโฮสต์

การออกแบบที่รัดกุมซึ่งไม่มีใครเอามาโฆษณา

TexAu มีขนาด 0.3 MiB — เล็กที่สุดในกลุ่มนี้ถึงสองเท่า — และมันระบุเว็บไซต์เฉพาะไว้ถึง 14 แห่ง แทนที่จะใช้ wildcard: เครือข่ายโซเชียล แพลตฟอร์มนักพัฒนา แพลตฟอร์มเผยแพร่ ผลิตภัณฑ์แชต ผู้ให้บริการข้อมูลธุรกิจ และโดเมนของตัวเอง content scripts ของมัน match ตรงกับทั้ง 14 แห่งนั้นพอดี

คุณอ่าน manifest นี้แล้วจะรู้ได้อย่างแม่นยำว่าส่วนขยายทำงานบนหน้าไหนบ้าง มันยังเป็นการเปิดเผยเชิงผลิตภัณฑ์ด้วย — รายชื่อเป้าหมายบอกได้ตรงไปตรงมามากกว่าการตลาดว่าเครื่องมือนี้ “มีไว้ทำอะไร”

ข้อแลกเปลี่ยนก็มีจริง: รายชื่อแบบระบุชื่อจะ scrape เว็บไซต์ที่ไม่ได้อยู่ในรายการไม่ได้ และเป้าหมายใหม่แต่ละตัวต้องออก release ใหม่ แต่ “14 โดเมนที่ระบุชื่อ” กับ “ทุก URL ที่มีอยู่” เป็นข้อเสนอคนละเรื่องกันมาก และมีเพียงข้อเดียวที่อ่านออกได้ชัด

สองผลิตภัณฑ์ที่ไม่ตรงกับที่รายชื่อบอก

ส่วนขยายของ Captain Data ไม่ได้ถูกแจกแบบสาธารณะ endpoint อัปเดตของ Google ตอบกลับด้วย HTTP 204 พร้อม body ว่าง สำหรับ extension ID ของมัน — เป็นคำตอบของสิ่งที่ Store จะไม่ให้บริการแบบไม่ระบุตัวตน ส่วนหน้า listing ของมันกลับให้บริการได้แบบไม่ต้องล็อกอิน — HTTP 200, 509,829 bytes สิ่งที่การดึงข้อมูลนี้หาไม่เจอคือหมายเลขเวอร์ชัน, วันที่อัปเดตล่าสุด หรือจำนวนติดตั้ง; บันทึกของสคริปต์เองระบุว่าค่า null ตรงนั้นเป็นหลักฐานที่อ่อน และไม่พบกำแพงให้ล็อกอิน ผมยืนยันได้แค่ว่า ID นี้มีจริงและเป็น first-party จึงน่าจะเป็นการแจกแบบ link-only หรือไม่ได้ขึ้นรายการ แต่ผมแยกจากการถอดออกจาก Store ไม่ได้ และจะไม่เดา

Dataflow Kit ไม่มี Chrome extension เลย เว็บไซต์ของมันอธิบายว่าเป็นเว็บแอปที่โฮสต์เอง มีการเลือกแบบ point-and-click และ REST API ถึงอย่างนั้นมันก็ไปอยู่ใน short list ของ Chrome extension อยู่ดี — ซึ่งก็มักเป็นวิธีที่รายชื่อประเภทนี้ถูกสร้างขึ้น

ความเก่าและขอบเขตเข้าถึง เพราะสองอย่างนี้ตรวจฟรีได้

metadata ของ Store เพิ่มบริบทในการคัดเลือกผลิตภัณฑ์เหนือกว่า permissions fields ชุดเดียวกันนี้ถูกเก็บสำหรับทุก extension เมื่อ 2026-07-30

มีผลิตภัณฑ์สามตัวที่ไม่ได้ปล่อยอัปเดตมานานกว่าหนึ่งปี และ Hexomatic เกือบสองปี สำหรับ extension เรื่องนี้สำคัญกว่ากับ library: Chrome มี stable release ใหม่ประมาณทุกสี่สัปดาห์ และแพลตฟอร์มส่วนขยายเองก็เปลี่ยนไปอยู่ข้างใต้ตลอด userScripts ย้าย gate สำหรับผู้ใช้ใน Chrome 138; extension ที่ปล่อยครั้งสุดท้ายในปี 2024 ถูกสร้างบนกติกาชุดหนึ่ง ไม่ใช่กฎเดียวกับเบราว์เซอร์ที่บังคับใช้มันตอนนี้

อีกสองอย่างที่ตารางนี้ไม่ได้บอกคืออะไรบ้าง Install count ถูก แบ่งเป็นช่วงโดย Google — 1,000 / 3,000 / 7,000 / 10,000 / 100,000 / 200,000 — จึงเทียบได้แค่ระดับลำดับขั้น ไม่ใช่ละเอียดกว่านั้น และบางผลิตภัณฑ์ก็โฆษณาตัวเลขที่ใหญ่กว่านี้ในสื่อของตัวเอง วันที่ล่าสุดไม่ได้บอกว่าบำรุงรักษาดีแค่ไหน หรือความเสี่ยงด้าน permission เป็นอย่างไร

ผลพลอยได้ที่มีประโยชน์อย่างหนึ่งคือ: เวอร์ชันใน Store ตรงกับเวอร์ชันใน manifest ของทั้งสิบแพ็กเกจที่วิเคราะห์ ไฟล์ CRX ที่ตรวจคือสิ่งที่ Store กำลังให้บริการอยู่จริง ไม่ใช่สำเนาที่ล้าสมัย

ความสดใหม่มีผลต่อว่าควรทำงานต่อหลังคัดเลือกมากแค่ไหน แต่มันไม่ได้เปลี่ยนความหมายของ manifest ส่วนขยายที่ใช้โดเมนระบุชื่อและอัปเดตล่าสุดเมื่อปีที่แล้วอาจยังเปิดพื้นที่หน้าเว็บน้อยกว่าส่วนขยายที่ใช้ wildcard แล้วเพิ่งปล่อยเมื่อวาน เวอร์ชันใหม่กว่าอาจยังเป็นตัวเลือกที่ดีกว่าในเชิงปฏิบัติ หากมันตามการเปลี่ยนแปลงของ Chrome ทัน สำหรับ shortlist ให้ใช้วันที่ใน Store ตัดสินว่าควรทดสอบอะไรซ้ำ แล้วใช้ manifest ตัดสินว่าตรงไหนต้องตรวจความสามารถให้ลึกขึ้น อย่าเอาสองคอลัมน์นี้มารวมเป็นคะแนนเดียว

สิ่งที่ manifest ไม่ได้บอกคุณ

permission ที่ประกาศไว้คือเพดาน ไม่ใช่พฤติกรรม <all_urls> หมายความว่าส่วนขยาย อาจ อ่านทุกหน้าได้ ไม่ได้แปลว่ามันอ่านจริง หรือข้อมูลใดๆ ออกจากเครื่องคุณจริงหรือไม่ การพิสูจน์ว่ามีอะไรเกิดขึ้นจริงต้องดูทราฟฟิกเครือข่ายตอนรัน — เป็นงานคนละแบบ ไม่ได้ทำในที่นี้ และสิ่งใดด้านบนไม่ควรถูกอ่านว่าเป็นหลักฐานการใช้งานผิดปกติ

รีวิวที่เกี่ยวข้อง: Chrome extension testability experiment

อีกสามขอบเขตที่ต้องจำไว้:

• Chrome เป็นคนคุมหลายอย่างไว้ การเข้าถึงไฟล์ปิดอยู่เป็นค่าเริ่มต้น; activeTab ตั้งใจให้แคบ; optional permissions ต้องมี prompt ตอนรัน; ผู้ใช้จะเห็นรายการ permission ตอนติดตั้ง
• permission ที่กว้างมักจำเป็นจริง เครื่องมือที่หน้าที่คือ “ดึงตารางจากทุกหน้าที่คุณเปิด” ย่อมทำงานด้วย allowlist ของโดเมนแบบระบุชื่อไม่ได้ บางครั้งขอบเขตที่แคบคือความมีวินัย บางครั้งก็แค่หมายถึงผลิตภัณฑ์ที่เล็กกว่า
• หนึ่งเวอร์ชัน หนึ่งวัน ตัวเลขทุกตัวมาจากแพ็กเกจที่ให้บริการเมื่อ 2026-07-29

ข้อแก้ไขสำคัญในการวิเคราะห์

ตัวเลขที่เผยแพร่นี้ใช้กฎสามข้อที่มักพลาดได้ง่ายเวลาเขียน manifest parser แบบเร็ว ข้อแรก <all_urls> รวม file: scheme ด้วย แต่ Chrome ยังล็อกการเข้าถึงไฟล์จริงไว้หลังสวิตช์ที่ผู้ใช้ควบคุม ข้อสองต้องดู web_accessible_resources.matches ควบคู่กับ content scripts และ host permissions เพราะตรงนั้นคือที่ Table Capture ระบุ file://*/* อย่างชัดเจน ข้อสาม externally_connectable มีค่าเริ่มต้นต่างกัน ขึ้นกับว่าคีย์ทั้งก้อนหายไปเลย หรือมีคีย์แต่ sub-field ว่าง ตารางด้านบนใช้กฎเหล่านี้อย่างสม่ำเสมอ

การนับ permission ของ Thunderbit ยังแยกสตริงดิบกับ permission ของ Chrome ที่รู้จักออกจากกัน อาร์เรย์ของมันมี 9 รายการ แต่ commands เป็นคีย์ระดับบน จึงทำให้ค่าที่ใช้ที่นี่คือ 8 permission ที่ Chrome รู้จัก บวก 1 สตริงที่ไม่ถูกรู้จัก สุดท้าย การประกาศ static content_scripts ไม่ใช่หลักฐานว่าโค้ดเรียก scripting.registerContentScripts หรือเมธอด CDP ใดๆ ความเป็นไปได้เหล่านั้นจะปรากฏเฉพาะในมุมความสามารถรันไทม์ ไม่ใช่พฤติกรรมที่สังเกตได้ raw manifest, CRX hash และผลลัพธ์จาก parser คือ audit trail สำหรับการทำ normalization เหล่านี้ ดังนั้นผู้อ่านไม่จำเป็นต้องเชื่อเพียงคำบรรยาย

สำหรับการตัดสินใจติดตั้งจริง ควรเทียบอย่างน้อยสี่มิติแยกกัน: หน้าเว็บใดอยู่ในขอบเขตโดยค่าเริ่มต้น, ผู้ใช้ต้องทำอะไรเพื่อปลดล็อกการเข้าถึงเพิ่ม, API ของเบราว์เซอร์หรือบัญชีใดจะพร้อมใช้, และใครจากภายนอกสามารถส่งข้อความถึงส่วนขยายได้ โมเดล activeTab ของ Agenty, userScripts ที่มี gate ของ Table Capture, OAuth scope ของ Drive ใน Axiom.ai และการประกาศ debugger ของ Thunderbit ไม่ได้อยู่บนสเกลเส้นตรงเดียวกัน แต่เป็นคำตอบต่างกันของคำถามด้านความเสี่ยงที่ต่างกัน

นี่คือการเปรียบเทียบดังกล่าวเมื่อใช้กับสี่ดีไซน์ที่ตั้งใจให้ต่างกัน:

ตารางนี้ก็ยังไม่ทำให้เกิดผู้ชนะ Agenty ที่เข้าถึงหน้าเว็บแบบถาวรได้แคบ ไม่ได้บอกอะไรเกี่ยวกับ backend ว่าทำอะไรกับข้อมูลที่ส่งเข้าไป Axiom.ai มี account scope ซึ่งเทียบตรงๆ กับการอ่านหน้าเว็บปัจจุบันไม่ได้ Table Capture ประกาศ userScripts แต่ยังไม่ทำงานจนกว่าผู้ใช้จะเปิด gate แยกของมัน Thunderbit มี permission debugger ซึ่งเปิดพื้นผิวควบคุมเบราว์เซอร์กว้างมาก แต่ manifest ไม่บอกว่าโค้ดเรียก CDP domain หรือ method ใด แต่ละแถวบอกว่าควรตรวจอะไรต่อ: ทราฟฟิกเครือข่ายตอนรัน, source code, flow การขอ consent หรือ trace ของ browser API

การแยกสิ่งเหล่านี้ยังสำคัญตอนอ่าน install prompt ของ Chrome ด้วย จำนวน permission ดิบๆ ไม่สามารถบอก timing, ขอบเขตถึงเฟรม, OAuth scope, web_accessible_resources, หรือการละคีย์ externally_connectable ได้ ในทางกลับกัน การประกาศที่กว้างไม่ได้พิสูจน์ว่ามีการเก็บหรือส่งออกข้อมูล สิ่งที่มีประโยชน์จาก manifest audit คือแผนทดสอบรันไทม์ที่เรียงลำดับความสำคัญ: ระบุ surface ข้อมูล, จด user gate, แล้วสังเกตว่าช่องทางที่ประกาศไว้ถูกใช้จริงหรือไม่

วิธีอ่านของคุณเอง

รีวิวที่เกี่ยวข้อง: browser automation guide

1. chrome://extensions → Details จะแสดง site access ที่ได้รับอนุญาต และให้คุณเปลี่ยนเป็น on click สำหรับสิ่งที่ไม่ต้องการการเข้าถึงแบบถาวร นั่นช่วยลดครึ่งหนึ่งของ site access ที่กล่าวถึงด้านบน แต่ไม่แตะเรื่องการรับข้อความเข้า (externally_connectable ยังคงเข้าถึง service worker ได้ไม่ว่าอย่างไร) หรือสิทธิ์ระดับเบราว์เซอร์
   Thunderbit มี debugger ประกาศไว้ตรงนี้ด้วย เอกสารความปลอดภัยของ extension จาก Chromium เองระบุว่า debugger API “may in some cases also sidestep other typical restrictions, such as host permissions or file access” ดังนั้นการตั้ง site access เป็น “on click” จึงไม่ได้จำกัดสิ่งที่มันเข้าถึงได้ และการควบคุมนี้ก็ไม่แตะ tabs, webNavigation, clipboardRead, downloads หรืออะไรใน optional_permissions ด้วย
2. สำหรับไฟล์ดิบ แพ็กเกจจะอยู่ใต้ไดเรกทอรี Extensions/<id>/<version>/ ของ Chrome ให้อ่าน 6 ฟิลด์: permissions, optional_permissions, host_permissions, content_scripts (รวม matches, run_at และ all_frames ภายใน), externally_connectable — จำไว้ว่า การไม่ใส่คีย์ คือค่าที่เปิดกว้างสำหรับผู้ส่งข้อความจาก extension — และ web_accessible_resources ซึ่ง matches ของมันสามารถระบุ scheme ที่ content scripts ไม่ได้ระบุ Thunderbit มีสองรายการ <all_urls> ในฟิลด์สุดท้ายนี้ที่เปิด index.html และสคริปต์ bundled สองไฟล์ให้ทุก origin พร้อม use_dynamic_url: false ซึ่งทำให้หน้าเว็บทดสอบได้ว่า URL ของ extension แบบคงที่เหล่านี้ resolve หรือไม่
3. ตรวจวันที่อัปเดตล่าสุดของ listing เทียบกับเวอร์ชัน Chrome ปัจจุบัน

การเปิดเผยและทรัพยากร: บทความนี้เผยแพร่โดย Thunderbit ซึ่งมีส่วนขยายอยู่ในตารางและ parser ชุดเดียวกัน open-source scraper pillar ของเราครอบคลุมเครื่องมือที่ไม่ใช่ส่วนขยาย

ลอง Thunderbit เพื่อดึงข้อมูลเว็บ

สรุปสั้นๆ

ส่วนขยายสำหรับ scraping และ automation ทั้งสิบตัว รวมของเราเอง อ่านจาก manifest ของตัวเอง

Agenty ไม่ประกาศ site access และไม่มี content scripts, ทำงานเฉพาะบนแท็บที่คุณกำลังดูตอนคลิกมัน อยู่ที่ 2.2 MiB Axiom.ai ประกาศทุก URL ของ HTTP และ HTTPS ครอบคลุม 37.1 MiB Magical ประกาศ 13 permission รวม clipboardRead — และยังเป็นส่วนขยายเดียวในที่นี้ที่ปิด inbound messaging ทั้งหมดได้สนิท Table Capture ประกาศแค่ 4 permission, และ inject ที่ document_start ลงทุกเฟรมบน <all_urls> — ซึ่งเป็นเพดานการ match แบบเดียวกับที่ของเราไปถึง แต่เร็วกว่า — พร้อม userScripts เมื่อร้องขอ TexAu เล็กที่สุด และระบุเป้าหมายมากที่สุด — 14 pattern ครอบคลุม 13 properties ที่ต่างกัน มันไม่ใช่ตัวเดียวที่ระบุชื่อโดเมน: Clip to Clay ระบุไว้สองแห่ง (clay.com กับอีกหนึ่งไซต์ของบุคคลที่สาม) ส่วน Hexomatic และ Clay for Chrome ระบุโดเมนของตัวเอง TexAu เป็นตัวเดียวที่รายชื่อส่วนใหญ่เป็นเว็บไซต์ของคนอื่น ห้าจากสิบตัวเข้าถึงไฟล์บนเครื่องคุณได้, และสองตัวในนั้น — Axiom.ai กับของเรา — ไม่ต้องเขียน file:// เลย

Thunderbit ของเราอยู่ฝั่งที่กว้างกว่า: ใช้ <all_urls> ทั้งสำหรับ host access และการ inject แบบคงที่ พร้อม debugger ซึ่งไม่มีส่วนขยายตัวอื่นในชุดนี้ประกาศไว้ มันอยู่บนค่าเริ่มต้นของ Chrome ที่อนุญาตให้ส่วนขยายใดก็ได้ส่งข้อความมา และเข้าถึง file:// ได้หลังผู้ใช้เปิด gate ของ Chrome แล้ว

การประกาศคือเพดาน ไม่ใช่พฤติกรรม และทั้งหมดนี้ไม่ได้ชี้ว่ามีการใช้งานผิดปกติ แต่สิ่งเหล่านี้เผยแพร่ไว้ ตรวจได้ฟรี และช่องว่างระหว่างสองปลายสุดนั้นใหญ่กว่าที่เห็นบนหน้าโปรดักต์มาก

ลอง Thunderbit เพื่อดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

permission ที่กว้างแปลว่าส่วนขยายทำอะไรผิดหรือเปล่า — และทำไมการนับ permission อย่างเดียวไม่พอ?
ไม่ใช่ และเพราะการนับอย่างเดียวมองไม่เห็นสองอย่าง <all_urls> หมายความว่าส่วนขยาย อาจ อ่านทุกหน้าที่คุณเปิด แต่ไม่ได้บอกว่ามันทำจริงหรือข้อมูลใดหลุดออกจากเครื่อง และเครื่องมือที่ถูกสร้างมาเพื่อดึงข้อมูลจากทุกหน้า ย่อมทำงานจาก allowlist ของโดเมนแบบระบุชื่อไม่ได้ สิ่งที่พบคือ “ความต่างของขอบเขต” ไม่ใช่การประพฤติมิชอบ — การพิสูจน์พฤติกรรมจริงต้องวิเคราะห์ทราฟฟิกตอนรัน ซึ่งการตรวจนี้ไม่ได้ทำ ส่วนเรื่องการนับ: การตั้งค่า injection ไม่ใช่ permission ดังนั้น Table Capture จึงประกาศ 4 แต่ยัง inject ที่ document_start, ลง all_frames, match <all_urls> ด้วย และ optional_permissions จะไม่ปรากฏใน install prompt เลย — Table Capture สามารถขอ userScripts ตอนรัน ซึ่งทำให้รันสคริปต์ใดๆ ที่ผู้ใช้ส่งมาใน context ของหน้าเว็บได้ และ Magical สามารถขอ webRequest ได้

ตัวไหนขอสิทธิ์น้อยที่สุด?
Agenty: 4 permission, ไม่มี host permissions, ไม่มี content scripts มันพึ่ง activeTab ซึ่งให้เข้าถึงแท็บปัจจุบันหลังคลิกส่วนขยายเท่านั้น และใช้ได้จนกว่าจะเปลี่ยนหน้า Hexomatic ตามมา ด้วย 2 permission และ content scripts ที่จำกัดเฉพาะโดเมนของตัวเอง

ส่วนขยายจะเข้าถึงไฟล์ในเครื่องของฉันได้อย่างไรโดยไม่ประกาศ file://?
เพราะ <all_urls> รวม scheme file: อยู่แล้ว Listly, Magical และ Table Capture ระบุ pattern file:// ไว้ชัดเจน — Magical ใน content scripts และ Table Capture ใน web_accessible_resources ส่วน Axiom.ai และ Thunderbit เข้าถึงได้ผ่าน wildcard โดยไม่ต้องเขียนคำนี้เลย http://*/* และ https://*/* ไม่ครอบคลุม file:// Chrome ปิดการเข้าถึงไฟล์ไว้เป็นค่าเริ่มต้นหลังสวิตช์แยกต่อส่วนขยาย จึงเป็นการ “ขอ” ไม่ใช่ “ได้อนุญาตแล้ว”

externally_connectable คืออะไร และทำไมการไม่ใส่มันถึงเป็นตัวเลือกที่เปิดกว้างกว่า?
มันคือการระบุ web origins หรือ extension IDs ที่ส่งข้อความถึง background script ของส่วนขยายได้ ค่าเริ่มต้นของ Chrome เมื่อคีย์นี้ หายไป คือส่วนขยาย ใดๆ เชื่อมต่อได้ และ ไม่มี เว็บเพจไหนเชื่อมต่อได้ เจ็ดในสิบตัวนี้ละคีย์นี้ รวมถึง Thunderbit เมื่อมีคีย์อยู่ Hexomatic เปิดช่องจาก extension ไปยัง 8 IDs ที่ระบุ Axiom.ai เปิด web origins 7 แห่งแต่ปิดช่อง extension และ Magical ระบุ list ว่างทั้งสองฝั่ง จึงปิดทั้งสองช่อง

manifest ของ Thunderbit เองประกาศอะไรบ้าง?
<all_urls> สำหรับ host access และ static content-script injection, ทำงานใน all_frames ที่ document_end; ขนาด 15.9 MiB จาก 78 ไฟล์; และมีสตริง 9 ตัวใน permission array โดย 8 ตัวที่ Chrome รู้จักคือ activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups และ tabs ส่วน commands เป็นคีย์ระดับบนของ manifest และไม่มีผลในอาร์เรย์นี้ ไม่มีส่วนขยายตัวอื่นในชุดนี้ที่ประกาศ debugger Thunderbit ยังเข้าถึง file:// ผ่าน <all_urls> หลังเปิด gate การเข้าถึงไฟล์ของ Chrome และไม่ได้ประกาศ externally_connectable พฤติกรรมตอนรันไม่ได้ถูก execute ดังนั้นการตรวจนี้ไม่ได้อ้างว่า extension เรียก CDP หรือ scripting methods ใดจริง