นักพัฒนาเบราว์เซอร์ Chrome การยุติการสนับสนุนโหมดการบล็อกการทำงานของ webRequest API ซึ่งช่วยให้คุณเปลี่ยนแปลงเนื้อหาที่ได้รับได้ทันทีและใช้งานในส่วนเสริมสำหรับการบล็อกโฆษณาอย่างแข็งขัน
การป้องกันมัลแวร์ ฟิชชิ่ง การสอดแนมกิจกรรมของผู้ใช้ การควบคุมโดยผู้ปกครอง และความเป็นส่วนตัว
แรงจูงใจของ Google:
- โหมดการบล็อก API นำไปสู่การใช้ทรัพยากรสูง
เมื่อใช้ API นี้ เบราว์เซอร์จะส่ง Add-on ข้อมูลทั้งหมดที่มีอยู่ในคำขอเครือข่ายก่อน Add-on จะวิเคราะห์และส่งคืนเวอร์ชันที่แก้ไขเพื่อการประมวลผลเพิ่มเติมในเบราว์เซอร์ หรือออกคำแนะนำในการบล็อก ในกรณีนี้ ความล่าช้าหลักไม่ได้เกิดขึ้นที่ขั้นตอนการประมวลผลการรับส่งข้อมูลโดยส่วนเสริม แต่เกิดจากต้นทุนค่าใช้จ่ายในการประสานงานการดำเนินการของส่วนเสริม โดยเฉพาะอย่างยิ่ง การจัดการดังกล่าวจำเป็นต้องมีการเปิดตัวกระบวนการแยกต่างหากเพื่อเสริม เช่นเดียวกับการใช้ IPC เพื่อโต้ตอบกับกระบวนการนี้และกลไกการทำให้เป็นอนุกรมข้อมูล - ส่วนเสริมจะควบคุมการรับส่งข้อมูลทั้งหมดในระดับต่ำอย่างสมบูรณ์ ซึ่งเปิดโอกาสมากมายสำหรับการละเมิดและการละเมิดความเป็นส่วนตัว จากสถิติของ Google พบว่า 42% ของส่วนเสริมที่เป็นอันตรายที่ตรวจพบทั้งหมดใช้ webRequest API มีการบันทึกไว้ว่าทุกๆ เดือน ความพยายามที่จะวางโปรแกรมเสริมที่เป็นอันตรายโดยเฉลี่ย 1800 รายการจะถูกบล็อกในแค็ตตาล็อก Chrome เว็บสโตร์ น่าเสียดายที่การตรวจสอบไม่อนุญาตให้เราตรวจจับส่วนเสริมที่เป็นอันตรายได้ทั้งหมดโดยไม่มีข้อยกเว้น ดังนั้น เพื่อปรับปรุงการป้องกัน จึงตัดสินใจจำกัดส่วนเสริมที่ระดับ API แนวคิดหลักคือการให้ส่วนเสริมที่เข้าถึงได้ไม่ใช่การรับส่งข้อมูลทั้งหมด แต่เฉพาะข้อมูลที่จำเป็นต่อการใช้งานฟังก์ชันการทำงานที่ต้องการเท่านั้น โดยเฉพาะอย่างยิ่ง ในการบล็อกเนื้อหา ไม่จำเป็นต้องให้สิทธิ์การเข้าถึงข้อมูลผู้ใช้ที่เป็นความลับทั้งหมดแก่โปรแกรมเสริม
- API การประกาศทดแทนที่เสนอ ดูแลงานการกรองเนื้อหาประสิทธิภาพสูงทั้งหมดและต้องการเพียงส่วนเสริมในการโหลดกฎการกรอง ส่วนเสริมไม่สามารถรบกวนการรับส่งข้อมูลและข้อมูลส่วนตัวของผู้ใช้ยังคงขัดขืนไม่ได้
- Google คำนึงถึงความคิดเห็นมากมายเกี่ยวกับการไม่มีฟังก์ชันการทำงานของ declarativeNetRequest API และขยายขีดจำกัดของจำนวนกฎการกรองจากที่เสนอในตอนแรก 30 ต่อส่วนขยายเป็นสูงสุดทั่วโลกที่ 150 และยังเพิ่มความสามารถในการแบบไดนามิก เปลี่ยนและเพิ่มกฎ ลบและแทนที่ส่วนหัว HTTP (ผู้อ้างอิง คุกกี้ ชุดคุกกี้) และพารามิเตอร์คำขอ
- สำหรับองค์กร คุณสามารถใช้โหมดการบล็อกการทำงานของ webRequest API ได้ เนื่องจากนโยบายสำหรับการใช้ส่วนเสริมถูกกำหนดโดยผู้ดูแลระบบที่เข้าใจคุณสมบัติของโครงสร้างพื้นฐานและตระหนักถึงความเสี่ยง ตัวอย่างเช่น API ที่ระบุสามารถใช้ในองค์กรเพื่อบันทึกกระแสการรับส่งข้อมูลของพนักงานและรวมเข้ากับระบบภายใน
- เป้าหมายของ Google ไม่ใช่การบ่อนทำลายหรือระงับส่วนเสริมการบล็อกโฆษณา แต่เป็นการเปิดใช้งานการสร้างตัวบล็อกโฆษณาที่ปลอดภัยและมีประสิทธิภาพยิ่งขึ้น
- การไม่เต็มใจที่จะออกจากโหมดการบล็อกการทำงานของ webRequest API พร้อมกับ declarativeNetRequest ใหม่นั้นอธิบายได้จากความปรารถนาที่จะจำกัดการเข้าถึงส่วนเสริมไปยังข้อมูลที่เป็นความลับ หากคุณปล่อยให้ webRequest API เหมือนเดิม ส่วนเสริมส่วนใหญ่จะไม่ใช้ declarativeNetRequest ที่ปลอดภัยกว่า เนื่องจากเมื่อเลือกระหว่างความปลอดภัยและฟังก์ชันการทำงาน นักพัฒนาส่วนใหญ่จะเลือกฟังก์ชันการทำงาน
:
- ดำเนินการโดยนักพัฒนาส่วนเสริม แสดงผลกระทบโดยรวมที่ไม่มีนัยสำคัญต่อประสิทธิภาพของส่วนเสริมบล็อกโฆษณา (ในระหว่างการทดสอบ จะมีการเปรียบเทียบประสิทธิภาพของส่วนเสริมต่างๆ แต่ไม่รวมค่าใช้จ่ายของกระบวนการเพิ่มเติมที่ประสานการทำงานของตัวจัดการในโหมดบล็อกของ API คำขอของเว็บ);
- เป็นไปไม่ได้เลยที่จะหยุดรองรับ API ที่ใช้งานอยู่ในส่วนเสริมโดยสมบูรณ์ แทนที่จะลบออก คุณสามารถเพิ่มการอนุญาตแยกต่างหากและควบคุมความเพียงพอของการใช้งานในส่วนเสริมอย่างเคร่งครัด ซึ่งจะช่วยผู้เขียนโปรแกรมเสริมยอดนิยมจำนวนมากจากการปรับปรุงผลิตภัณฑ์ของตนใหม่ทั้งหมด และหลีกเลี่ยงการตัดฟังก์ชันการทำงาน
- เพื่อลดต้นทุนค่าโสหุ้ยคุณไม่สามารถลบ API ได้ แต่สร้างใหม่ตามกลไก Promise ซึ่งคล้ายกับการใช้งาน webRequest ใน Firefox
- ทางเลือกที่เสนอ declarativeNetRequest ไม่ครอบคลุมความต้องการทั้งหมดของนักพัฒนาส่วนเสริมสำหรับการบล็อกโฆษณาและความปลอดภัย/ความเป็นส่วนตัว เนื่องจากไม่ได้ให้การควบคุมคำขอเครือข่ายอย่างสมบูรณ์ ไม่อนุญาตให้ใช้อัลกอริธึมการกรองแบบกำหนดเอง และไม่อนุญาตให้ การใช้กฎที่ซับซ้อนซึ่งทับซ้อนกันตามเงื่อนไข
- ด้วยสถานะปัจจุบันของ declarativeNetRequest API เป็นไปไม่ได้ที่จะสร้างฟังก์ชันการทำงานที่มีอยู่ของ uBlock Origin และส่วนเสริม uMatrix ขึ้นมาใหม่โดยไม่มีการเปลี่ยนแปลง และยังทำให้การพัฒนาพอร์ต NoScript สำหรับ Chrome เพิ่มเติมไม่มีจุดหมายอีกด้วย
- ความกังวลเกี่ยวกับความเป็นส่วนตัวนั้นเป็นเรื่องที่ลึกซึ้ง เนื่องจากโหมดอ่านอย่างเดียวและไม่มีการบล็อกของ webRequest API ยังคงอยู่และยังคงอนุญาตให้ส่วนเสริมที่เป็นอันตรายควบคุมการรับส่งข้อมูลทั้งหมด แต่ไม่ได้ให้ความสามารถในการรบกวนการทำงานบน บิน (เปลี่ยนเนื้อหา วางโฆษณาของคุณ เรียกใช้คนงานเหมือง และวิเคราะห์เนื้อหาของแบบฟอร์มอินพุตที่สามารถใช้งานได้หลังจากโหลดหน้าเว็บเสร็จแล้ว)
- นักพัฒนาเบราว์เซอร์ , и ซึ่งสร้างขึ้นบนเครื่องยนต์ Chromium ตั้งใจที่จะทิ้งการรองรับโหมดการบล็อก webRequest ไว้ในผลิตภัณฑ์ของตน
ที่มา: opennet.ru