บุคคลที่สาม

มีความเป็นไปได้น้อยมากที่เว็บไซต์จะมีเว็บไซต์ในตัวมันเองทั้งหมด ผลการประเมินเว็บ HTTP แสดงให้เห็นว่าเว็บไซต์ส่วนใหญ่ ประมาณ 95% มีเนื้อหาของบุคคลที่สามบางส่วน

Almanac ให้คำจำกัดความของเนื้อหาของบุคคลที่สามว่าเป็นเนื้อหาที่ฝากไว้ในต้นทางที่มีการแชร์และเผยแพร่แบบสาธารณะ ซึ่งมีการใช้งานอย่างแพร่หลายในหลากหลายรูปแบบ และไม่ได้รับอิทธิพลจากเจ้าของเว็บไซต์แต่ละราย ซึ่งอาจเป็นรูปภาพหรือสื่ออื่นๆ เช่น วิดีโอ แบบอักษร หรือสคริปต์ รูปภาพและสคริปต์ครอบคลุมมากกว่าสิ่งอื่นๆ ที่มารวมกัน เนื้อหาของบุคคลที่สาม ไม่ได้สำคัญต่อการพัฒนาเว็บไซต์ แต่ก็อาจจะเป็น คุณจะต้องใช้สิ่งที่โหลดจากเซิร์ฟเวอร์ที่ใช้แชร์แบบสาธารณะ ไม่ว่าจะเป็นแบบอักษรของเว็บ iframe ที่ฝังของวิดีโอ โฆษณา หรือไลบรารี JavaScript ตัวอย่างเช่น คุณอาจใช้แบบอักษรเว็บที่แสดงจาก Google Fonts หรือวัดผลการวิเคราะห์ด้วย Google Analytics คุณอาจได้เพิ่มปุ่มชอบหรือปุ่ม "ลงชื่อเข้าใช้ด้วย" จากเครือข่ายสังคม คุณอาจฝังแผนที่หรือวิดีโอ หรือจัดการกับการซื้อสินค้าผ่านบริการของบุคคลที่สาม คุณอาจกำลังติดตามข้อผิดพลาด สำหรับทีมพัฒนาของคุณเองผ่านเครื่องมือการตรวจสอบของบุคคลที่สาม

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

นั่นไม่ใช่ความหมายของการพูดคุยเรื่อง "แหล่งข้อมูลของบุคคลที่สาม" โดยทั่วไป: ความแตกต่างระหว่างบุคคลที่หนึ่งและ บุคคลที่สามนั้นเป็นเรื่องของบริบทที่มีการใช้บางสิ่ง สคริปต์ที่โหลดจากเว็บไซต์อื่นเป็นของบุคคลที่สาม และคำขอ HTTP ที่โหลดสคริปต์อาจมีคุกกี้ แต่คุกกี้เหล่านั้นไม่ใช่ "คุกกี้ของบุคคลที่สาม" จริงๆ ก็คือคุกกี้เท่านั้น และจะเป็น "บุคคลที่สาม" หรือไม่ หรือ "first-party" ขึ้นอยู่กับว่าระบบกำลังโหลดสคริปต์อยู่หรือไม่ บนไซต์ของคุณ หรือหน้าเว็บบนไซต์ของเจ้าของสคริปต์

เหตุผลที่เราใช้ทรัพยากรของบุคคลที่สาม

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

หนังสือสรุปเว็บของที่เก็บถาวรของ HTTP ให้คำอธิบายที่ดี:

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

ทรัพยากรของบุคคลที่สามทำอะไรได้บ้าง

การเข้าถึงข้อมูลบางอย่าง

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

การติดตามข้ามเว็บไซต์

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

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

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

นี่คือความแตกต่างหลัก: การจดจำข้ามเว็บไซต์ที่ไม่พึงประสงค์นั้นไม่ดี แม้ว่าบุคคลที่สามจะไม่ได้รวบรวมข้อมูลที่ละเอียดอ่อนเพิ่มเติม จากข้อมูลนี้ เนื่องจากจะทำให้ผู้ใช้เสียการควบคุมข้อมูลประจำตัว การเข้าถึงผู้อ้างอิงและที่อยู่ IP ของผู้ใช้ และคุกกี้เป็นการเปิดเผยที่ไม่ต้องการ การใช้ทรัพยากรของบุคคลที่สามจะมาพร้อมกับการวางแผนการใช้ ด้วยวิธีที่รักษาความเป็นส่วนตัว งานบางส่วนนั้นอยู่ในความรับผิดชอบของคุณในฐานะนักพัฒนาเว็บไซต์ และบางงานก็ทำโดยเบราว์เซอร์ ในบทบาท User Agent กล่าวคือ ตัวแทนที่ทำงานในนามของผู้ใช้เพื่อหลีกเลี่ยงการเปิดเผยข้อมูลที่ละเอียดอ่อน และ การรู้จำข้ามเว็บไซต์ที่ไม่ต้องการหากเป็นไปได้ ด้านล่างนี้ เราจะดูรายละเอียดเพิ่มเติมเกี่ยวกับการบรรเทาปัญหาและแนวทางในเบราว์เซอร์ และระดับการพัฒนาเว็บไซต์

โค้ดของบุคคลที่สามฝั่งเซิร์ฟเวอร์

คำจำกัดความก่อนหน้านี้ของเราเกี่ยวกับบุคคลที่สามโดยจงใจปรับเปลี่ยนวิธีการของ HTTP Almanac ที่ค่อนข้างเป็นฝั่งไคลเอ็นต์ (ตามความเหมาะสม ให้รวมผู้เขียนบุคคลที่สามไว้ด้วย เนื่องจากในมุมด้านความเป็นส่วนตัว บุคคลที่สามคือผู้ที่รู้เรื่องต่างๆ เกี่ยวกับผู้ใช้ที่ไม่ใช่คุณ

ซึ่งรวมถึงบุคคลที่สามที่ให้บริการที่คุณใช้บนเซิร์ฟเวอร์รวมถึงไคลเอ็นต์ด้วย จากความเป็นส่วนตัว ไลบรารีของบุคคลที่สาม (เช่น เนื้อหาที่มาจาก NPM หรือ Composer หรือ NuGet) ก็เป็นสิ่งสำคัญที่ควรทำความเข้าใจด้วยเช่นกัน ทรัพยากร Dependency ส่งผ่านข้อมูลนอกพรมแดนหรือไม่ หากคุณส่งข้อมูลไปยังบริการบันทึกหรือฐานข้อมูลที่โฮสต์จากระยะไกล ถ้าห้องสมุดคุณมี "โทรศัพท์หน้าแรก" ด้วย ผู้เขียนต่อผู้อื่น เนื้อหาเหล่านี้อาจอยู่ในสถานะที่จะละเมิด ความเป็นส่วนตัว และต้องมีการตรวจสอบ บุคคลที่สามผ่านเซิร์ฟเวอร์มักจะต้องเป็นผู้ส่งข้อมูลผู้ใช้จากคุณ ซึ่งหมายความว่า ที่ข้อมูลที่แสดงนั้นจะอยู่ภายใต้การควบคุมของคุณมากขึ้น ในทางตรงกันข้าม บุคคลที่สามที่ใช้ไคลเอ็นต์ ซึ่งเป็นสคริปต์หรือทรัพยากร HTTP ที่รวมอยู่ในเว็บไซต์และดึงข้อมูลโดยเบราว์เซอร์ของผู้ใช้ อาจรวบรวมข้อมูลบางอย่างจากผู้ใช้โดยตรงได้โดยไม่ต้องผ่านกระบวนการดังกล่าว ของคอลเล็กชันที่คุณเป็นผู้ไกล่เกลี่ย โมดูลส่วนใหญ่จะให้ความสำคัญกับวิธีระบุบุคคลที่สามที่เป็นฝั่งไคลเอ็นต์ ที่คุณได้เลือกที่จะรวมและเปิดเผยผู้ใช้ของคุณ นั่นเป็นเพราะคุณมีสื่อกลางที่เป็นไปได้น้อยกว่า แต่ก็คุ้มค่า พิจารณาการรักษาความปลอดภัยของโค้ดฝั่งเซิร์ฟเวอร์เพื่อให้คุณเข้าใจการสื่อสารขาออกจากโค้ด และสามารถบันทึกหรือบล็อก เป็นเรื่องที่คาดไม่ถึง รายละเอียดเกี่ยวกับวิธีดำเนินการนี้อยู่นอกเหนือขอบเขตของเรา (และขึ้นอยู่กับการตั้งค่าเซิร์ฟเวอร์ของคุณ) แต่ นี่เป็นอีกส่วนหนึ่งในจุดยืนด้านการรักษาความปลอดภัยและความเป็นส่วนตัว

เหตุใดคุณจึงต้องระมัดระวังเกี่ยวกับบุคคลที่สาม

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

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

ตัวอย่างของปัญหาด้านความปลอดภัยคือ "เว็บสกิมเมอร์" ขโมยข้อมูลบัตรเครดิต ซึ่งเป็นทรัพยากรของบุคคลที่สามที่มี บนหน้าเว็บที่ผู้ใช้ป้อนรายละเอียดบัตรเครดิต ซึ่งอาจขโมยรายละเอียดบัตรเครดิตเหล่านั้นและส่งให้กับ บุคคลที่สามที่เป็นอันตราย ผู้ที่สร้างสคริปต์แบบคร่าวๆ เหล่านี้มีความคิดสร้างสรรค์มากในการซ่อนสถานที่เหล่านั้น ข้อมูลสรุปหนึ่งอธิบายวิธีที่สคริปต์แบบสกิมเมอร์ ถูกซ่อนในเนื้อหาของบุคคลที่สาม เช่น รูปภาพที่ใช้สำหรับโลโก้ของเว็บไซต์ ไอคอน Fav และเครือข่ายโซเชียลมีเดีย ไลบรารียอดนิยม เช่น jQuery, Modernizr และ Google Tag Manager รวมถึงวิดเจ็ตของเว็บไซต์ เช่น หน้าต่างแชทสด และไฟล์ CSS

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

ตัวอย่างของบุคคลที่สามมีอะไรบ้าง

เรากำลังหารือกันว่า "บุคคลที่สาม" แต่จริงๆ แล้วมีประเภทที่แตกต่างกัน และเข้าถึงข้อมูลผู้ใช้ได้ในปริมาณที่แตกต่างกัน เช่น การเพิ่มเอลิเมนต์ <img> ลงใน HTML ซึ่งโหลดจากเซิร์ฟเวอร์อื่นจะทำให้เซิร์ฟเวอร์มีข้อมูลที่แตกต่างกัน เกี่ยวกับผู้ใช้ของคุณมากกว่าการเพิ่ม <iframe> หรือองค์ประกอบ <script> นี่เป็นตัวอย่างมากกว่า รายการที่ครอบคลุมทั้งหมด ในการทำความเข้าใจถึงความแตกต่างระหว่างรายการของบุคคลที่สามประเภทต่างๆ ที่เว็บไซต์ของคุณใช้ได้

การขอทรัพยากรข้ามเว็บไซต์

ทรัพยากรแบบข้ามเว็บไซต์คือทุกอย่างในเว็บไซต์ซึ่งโหลดจากเว็บไซต์อื่นและไม่ใช่ <iframe> หรือ <script> ตัวอย่าง รวมถึง <img>, <audio>, <video>, แบบอักษรเว็บที่โหลดโดย CSS และพื้นผิว WebGL ทั้งหมดนี้โหลดผ่านคำขอ HTTP และ ที่อธิบายไว้ก่อนหน้านี้ คำขอ HTTP ดังกล่าวจะรวมคุกกี้ใดๆ ที่เว็บไซต์อื่นตั้งค่าไว้ก่อนหน้านี้ ที่อยู่ IP ของผู้ใช้ที่ส่งคำขอ และ URL ของหน้าปัจจุบันเป็น URL ที่มา ที่ผ่านมาคำขอของบุคคลที่สามจะรวมข้อมูลนี้ไว้โดยค่าเริ่มต้น แม้ว่า จะมีความพยายามที่จะลดหรือแยกข้อมูลที่ส่งผ่านไปยังบุคคลที่สามโดยเบราว์เซอร์ต่างๆ ตามที่อธิบายไว้ใน "การทำความเข้าใจ การป้องกันเบราว์เซอร์ของบุคคลที่สาม" ต่อไป

การฝัง iframe แบบข้ามเว็บไซต์

เอกสารที่สมบูรณ์ที่ฝังอยู่ในหน้าเว็บของคุณผ่าน <iframe> สามารถขอสิทธิ์เข้าถึง API ของเบราว์เซอร์เพิ่มเติมได้ นอกเหนือจาก Trifecta คุกกี้, ที่อยู่ IP และ URL ที่มา API ที่พร้อมใช้งานในหน้า <iframe> วัน และวิธีที่ API ขอสิทธิ์เข้าถึงจะเป็นแบบเฉพาะเบราว์เซอร์ และอยู่ระหว่างการเปลี่ยนแปลง: ดู "นโยบายสิทธิ์" ด้านล่างเพื่อดูการดำเนินการปัจจุบันในการกำจัดหรือตรวจสอบการเข้าถึง API ที่ฝัง เอกสาร

การเรียกใช้ JavaScript แบบข้ามเว็บไซต์

การเพิ่มองค์ประกอบ <script> จะโหลดและเรียกใช้ JavaScript แบบข้ามเว็บไซต์ในบริบทระดับบนสุดของหน้าเว็บ ซึ่งหมายความว่า ที่เรียกใช้จะมีสิทธิ์เข้าถึงทุกอย่างที่สคริปต์บุคคลที่หนึ่งของคุณทำได้ สิทธิ์ของเบราว์เซอร์จะยังคงจัดการข้อมูลนี้ ดังนั้น การถามตำแหน่งที่ตั้งของผู้ใช้ (เช่น) ยังต้องมีข้อตกลงจากผู้ใช้ด้วย แต่ข้อมูลใดๆ ที่แสดงในหน้าเว็บ หรือ พร้อมใช้งานเป็นตัวแปร JavaScript สามารถอ่านได้ด้วยสคริปต์ดังกล่าว ซึ่งรวมถึงคุกกี้ที่ไม่ได้ส่งไปยังบุคคลที่สาม เป็นส่วนหนึ่งของคำขอ และรวมคุกกี้ที่มีไว้สำหรับเว็บไซต์ของคุณเพียงอย่างเดียวด้วย เช่นเดียวกัน สคริปต์ของบุคคลที่สามที่โหลดลงใน สามารถสร้างคำขอ HTTP เดียวกันกับที่โค้ดของคุณเองมี ซึ่งหมายความว่าหน้าเว็บอาจส่งคำขอ fetch() ไปยัง API แบ็กเอนด์เพื่อรับข้อมูล

การรวมไลบรารีของบุคคลที่สามในทรัพยากร Dependency ของคุณ

ตามที่อธิบายไว้ก่อนหน้านี้ โค้ดฝั่งเซิร์ฟเวอร์อาจรวมทรัพยากร Dependency ของบุคคลที่สามด้วย ซึ่งไม่สามารถแยกความแตกต่างจากโค้ดของคุณเองได้ โค้ดได้อย่างมีประสิทธิภาพ โค้ดที่คุณรวมไว้จากที่เก็บ GitHub หรือไลบรารีของภาษาโปรแกรมของคุณ (npm, PyPI, Composer ฯลฯ) จะอ่านข้อมูลทั้งหมดแบบเดียวกับที่โค้ดอื่นอ่านได้

ทำความรู้จักบุคคลที่สามของคุณ

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

การที่จะทำความเข้าใจเรื่องนี้ได้ต้องอาศัยกระบวนการตรวจสอบ

ตรวจสอบบุคคลที่สาม

การทําความเข้าใจสิ่งที่บุคคลที่สามทำคือกระบวนการตรวจสอบ คุณสามารถทำเช่นนี้ได้ทั้งด้านเทคนิคและไม่ใช่ด้านเทคนิค และ สำหรับบุคคลที่สามรายหนึ่งๆ และทั้งคอลเล็กชันของคุณ

ดำเนินการตรวจสอบที่ไม่ใช่ด้านเทคนิค

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

ซึ่งจะเป็นประโยชน์คู่กับการตรวจสอบทางเทคนิคที่พูดถึงเพิ่มเติม เนื่องจาก อีกรายการ คุณควรทราบถึงทรัพยากรของบุคคลที่สามที่คุณใช้เพื่อเหตุผลทางธุรกิจ (เช่น เครือข่ายโฆษณา หรือเนื้อหาที่ฝัง) เพราะจะมี ความสัมพันธ์ทางธุรกิจอยู่แล้ว ส่วนนี้เหมาะสำหรับการเริ่มต้นการประชุมที่ไม่เกี่ยวข้องกับด้านเทคนิค การตรวจสอบ การตรวจสอบทางเทคนิคยังมีแนวโน้มที่จะระบุบุคคลที่สามได้ด้วย โดยเฉพาะบุคคลที่สาม มากกว่าเหตุผลทางธุรกิจ (องค์ประกอบภายนอก ข้อมูลวิเคราะห์ ไลบรารียูทิลิตี) และรายการดังกล่าวสามารถรวมเข้ากับรายการ ให้บุคคลที่สามมุ่งเน้นที่ธุรกิจ เป้าหมายในที่นี้คือสำหรับคุณ ในฐานะเจ้าของไซต์ เพื่อรู้สึกว่าคุณเข้าใจสิ่งที่ ฝ่ายต่างๆ ที่คุณเพิ่มในเว็บไซต์กำลังทำอยู่ และสำหรับคุณในฐานะธุรกิจ จึงจะนำเสนอที่ปรึกษาด้านกฎหมายได้ กับพื้นที่โฆษณาของบุคคลที่สามเพื่อให้แน่ใจว่าคุณได้ปฏิบัติตามภาระหน้าที่ที่จำเป็น

เรียกใช้การตรวจสอบทางเทคนิค

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

ลงชื่อสมัครใช้บัญชีใหม่ในเว็บไซต์ของคุณเอง หากคุณระบุบัญชีผู้ใช้ ทีมออกแบบของคุณจะจัดกลุ่มผู้ใช้ใหม่นี้ ของกระบวนการการได้ผู้ใช้ใหม่จากมุมมอง UX แต่ก็มีภาพตัวอย่างให้เห็นถึงวิธีการจัดการดังกล่าวจากมุมมองด้านความเป็นส่วนตัว อย่าเพียงแค่คลิก "ยอมรับ" เกี่ยวกับข้อกำหนดและเงื่อนไข หรือคำเตือนคุกกี้ หรือนโยบายความเป็นส่วนตัว กำหนดภารกิจในการใช้บริการของคุณเอง โดยไม่เปิดเผยข้อมูลส่วนบุคคลหรือไม่มีคุกกี้ติดตามใดๆ และดูว่าคุณทำได้หรือไม่ และการทำเช่นนั้นยากแค่ไหน นอกจากนี้ให้ดูในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์เพื่อดูว่ามีการเข้าถึงเว็บไซต์ใดและส่งข้อมูลไปยังเว็บไซต์ใด เว็บไซต์เหล่านั้น เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จะมีรายการคำขอ HTTP แยกต่างหาก (โดยปกติจะอยู่ในส่วนที่เรียกว่า "เครือข่าย") และคุณจะเห็น จากที่นี่ที่จัดกลุ่มตามประเภท (HTML, CSS, รูปภาพ, แบบอักษร, JavaScript, คำขอที่ดำเนินการโดย JavaScript) หรือมีความเป็นไปได้ ในการเพิ่มคอลัมน์ใหม่เพื่อแสดงโดเมนของแต่ละคำขอ ซึ่งจะแสดงรายชื่อสถานที่ต่างๆ ที่มีการติดต่อ และอาจมี "คำขอของบุคคลที่สาม" เพื่อแสดงเฉพาะบุคคลที่สาม (นอกจากนี้ การใช้ Content-Security-Policy ก็อาจเป็นประโยชน์เช่นกัน การรายงานเพื่อดำเนินการตรวจสอบอย่างต่อเนื่อง ซึ่งจะอ่านต่อ)

เครื่องมือ "ส่งคำขอสร้างแผนที่" ของ Simon Hearne ก็สามารถเป็นภาพรวมที่เป็นประโยชน์สำหรับ คำขอย่อยที่หน้าเว็บที่เผยแพร่ต่อสาธารณะสร้างขึ้น

นอกจากนี้ คุณยังใช้บุคคลที่สามซึ่งมุ่งเน้นธุรกิจซึ่งเป็นส่วนหนึ่งของการตรวจสอบที่ไม่ใช่ด้านเทคนิคได้อีกด้วย (ซึ่งก็คือรายชื่อบริษัทที่คุณมีความสัมพันธ์ทางการเงินด้วยเพื่อที่จะใช้ทรัพยากรของบริษัทเหล่านั้น) เป้าหมายก็คือ เพื่อจับคู่รายชื่อบุคคลที่สามที่คุณเชื่อว่าคุณกำลังใช้อยู่ (จากบันทึกด้านการเงินและกฎหมาย) กับรายชื่อที่คุณ (โดยการดูว่าเว็บไซต์ของคุณส่งคำขอ HTTP ของบุคคลที่สามรายการใด) คุณควรสามารถระบุธุรกิจแต่ละแห่งใน 3 ส่วน บุคคลที่ส่งคำขอข้อมูลทางเทคนิค หากคุณระบุคำขอในการตรวจสอบทางเทคนิคสำหรับบุคคลที่สามไม่ได้ ที่ระบุตามความสัมพันธ์ทางธุรกิจ สิ่งสำคัญคือต้องหาสาเหตุและเพื่อให้มีแนวทางในการทดสอบ บางทีบริษัทดังกล่าว โหลดทรัพยากรเฉพาะในประเทศหนึ่งๆ หรือในอุปกรณ์บางประเภท หรือสำหรับผู้ใช้ที่เข้าสู่ระบบ วิธีนี้จะขยาย รายการพื้นที่เว็บไซต์ที่ต้องตรวจสอบเพื่อให้แน่ใจว่าคุณเห็นการเข้าถึงขาออกทั้งหมด (หรืออาจจะมีการระบุบุคคลที่สาม ที่คุณจ่ายเงินและไม่ได้ใช้ ซึ่งจะทำให้ฝ่ายการเงินของเรารู้สึกยินดีเสมอ)

เมื่อคุณได้จำกัดรายการคำขอที่ส่งไปยังบุคคลที่สามที่คุณต้องการให้เป็นส่วนหนึ่งของการตรวจสอบให้แคบลงแล้ว โดยคลิกที่ คำขอแต่ละรายการจะแสดงรายละเอียดทั้งหมด และโดยเฉพาะอย่างยิ่ง ข้อมูลที่ส่งต่อไปยังคำขอนั้น นอกจากนี้ ยัง เป็นเรื่องปกติที่คำขอของบุคคลที่สามที่โค้ดของคุณเริ่มต้นจะทำงานเพื่อเริ่มคำขอของบุคคลที่สามอื่นๆ อีกหลายรายการ บุคคลที่สามเหล่านี้ก็ "นำเข้า" เช่นกัน ไว้ในนโยบายความเป็นส่วนตัวของตนเอง งานนี้ต้องใช้แรงงานอย่างมากแต่ก็มีคุณค่า และ และมักจะแทรกอยู่ในการวิเคราะห์ที่มีอยู่ ทีมพัฒนาฟรอนท์เอนด์ของคุณควรตรวจสอบคำขออยู่แล้ว เหตุผลด้านประสิทธิภาพ (อาจใช้เครื่องมือที่มีอยู่ เช่น WebPageTest หรือ Lighthouse) และรวมข้อมูล และการตรวจสอบความเป็นส่วนตัว ในขั้นตอนดังกล่าวก็ช่วยให้ทำได้ง่ายขึ้น

วันที่ แผนที่คำขอ web.dev
แผนที่คำขอ (ง่ายขึ้นมาก) สำหรับ web.dev ซึ่งจะแสดงเว็บไซต์ของบุคคลที่สามที่ขอเว็บไซต์ของบุคคลที่สามอื่นๆ เป็นต้น

ควรทำ

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

  • ไปที่เว็บไซต์ของคุณ
  • ลงชื่อสมัครใช้บัญชีใหม่ หากคุณระบุบัญชีผู้ใช้
  • ลองลบบัญชีที่สร้างไว้
  • ดำเนินการปกติบนเว็บไซต์ 1-2 อย่าง (ซึ่งขึ้นอยู่กับสิ่งที่เว็บไซต์ทำ แต่ให้เลือกการดำเนินการทั่วไปที่ผู้ใช้ส่วนใหญ่ทำ)
  • ดำเนินการ 1-2 อย่างที่คุณทราบว่าเกี่ยวข้องกับทรัพยากร Dependency ของบุคคลที่สามโดยเฉพาะ ซึ่งอาจรวมถึงการแชร์เนื้อหากับ โซเชียลมีเดีย การเริ่มต้นขั้นตอนการชำระเงิน หรือการฝังเนื้อหาจากเว็บไซต์อื่น

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

ไฟล์ HAR และการจับภาพ

ไฟล์ HAR เป็นรูปแบบ JSON แบบมาตรฐานของคำขอเครือข่ายทั้งหมดที่มาจากหน้าเว็บ หากต้องการรับไฟล์ HAR สำหรับหน้าใดหน้าหนึ่ง ให้ดำเนินการดังนี้

Chrome

เปิดเครื่องมือสำหรับนักพัฒนาเว็บในเบราว์เซอร์ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ และ ให้เลือกสัญลักษณ์บันทึกลูกศรลงที่ด้านบนขวาใกล้กับเมนูแบบเลื่อนลง "ไม่มีการควบคุม"

แผงเครือข่าย Chrome DevTools ที่ไฮไลต์สัญลักษณ์ &quot;ดาวน์โหลด HAR&quot;
Firefox

เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือนักพัฒนาเว็บ) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ และเลือก สัญลักษณ์เฟืองที่ด้านบนขวาข้างเมนูแบบเลื่อนลง "การควบคุม" จากเมนู ให้เลือก Save All As HAR**

แผงเครือข่ายเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Firefox ที่ไฮไลต์ตัวเลือก &quot;Save All As Har&quot;
Safari

เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > พัฒนา > แสดงเครื่องมือตรวจสอบเว็บ หากคุณไม่มีเมนู "พัฒนา" ให้เปิดใช้จาก เมนู > Safari > ค่ากำหนด > ขั้นสูง > แสดงเมนู "พัฒนา" ในแถบเมนู) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้า แล้วเลือกส่งออกที่ด้านขวาบน (ทางด้านขวาของ Preserve Log คุณอาจต้องขยายหน้าต่าง)

แผงเครือข่ายเครื่องมือตรวจสอบเว็บ Safari ที่ไฮไลต์ตัวเลือกการส่งออก HAR

สำหรับรายละเอียดเพิ่มเติม คุณยังสามารถบันทึกรายการที่ส่งมายังบุคคลที่สาม (ในส่วนคำขอ) แม้ว่าข้อมูลนี้มักจะ มีความสับสนและตีความไม่ได้อย่างเป็นประโยชน์

แนวทางปฏิบัติแนะนำเมื่อผสานรวมกับบุคคลที่สาม

คุณสามารถกำหนดนโยบายของคุณเองเกี่ยวกับบุคคลที่สามที่เว็บไซต์ของคุณใช้ โดยเปลี่ยนผู้ให้บริการโฆษณาที่คุณใช้ตามแนวทางปฏิบัติของบุคคลที่สาม หรือป๊อปอัปความยินยอมในการใช้คุกกี้ที่น่ารำคาญหรือรบกวนผู้ใช้มากน้อยเพียงใด หรือคุณต้องการใช้ปุ่มโซเชียลมีเดียบนเว็บไซต์หรือ สำหรับติดตามลิงก์ในอีเมลหรือลิงก์ utm_campaign เพื่อติดตามใน Google Analytics ในทวีตของคุณ สิ่งหนึ่งที่ควรคำนึงถึงเมื่อ การพัฒนาเว็บไซต์คือระดับความเป็นส่วนตัวและความปลอดภัยของบริการวิเคราะห์ของคุณ บริการข้อมูลวิเคราะห์บางอย่างจะแลกกับ คือการปกป้องความเป็นส่วนตัว บ่อยครั้งยังมีวิธีใช้สคริปต์ของบุคคลที่สามเพื่อเพิ่มการคุ้มครองความเป็นส่วนตัวด้วย: คุณไม่ใช่ทีมแรกที่ต้องการปรับปรุง ความเป็นส่วนตัวและปกป้องพวกเขาจากการเก็บรวบรวมข้อมูลของบุคคลที่สาม อาจเป็นวิธีแก้ปัญหาอยู่แล้ว สุดท้าย ผู้ให้บริการบุคคลที่สามหลายรายให้ความสำคัญกับปัญหาในการเก็บรวบรวมข้อมูลมากกว่าเมื่อก่อน และมักมีฟีเจอร์หรือพารามิเตอร์ที่คุณเพิ่มได้ ซึ่งจะเปิดใช้โหมดปกป้องผู้ใช้มากขึ้น ต่อไปนี้เป็นตัวอย่างบางส่วน

เมื่อเพิ่มปุ่มแชร์ผ่านโซเชียลมีเดีย

ลองฝังปุ่ม HTML โดยตรง: เว็บไซต์ https://sharingbuttons.io/ มีตัวอย่างที่ออกแบบมาอย่างดี หรือคุณจะเพิ่มลิงก์ HTML แบบพื้นฐานก็ได้ ข้อดีข้อเสียก็คือ คุณจะเสีย "จำนวนการแชร์" นะ สถิติและความสามารถในการ จำแนกลูกค้าของคุณ ใน Facebook Analytics นี่คือตัวอย่างของข้อดีและข้อเสียระหว่างการใช้ผู้ให้บริการบุคคลที่สามกับการรับข้อมูลการวิเคราะห์น้อยลง

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

ตัวอย่างเช่น คุณอาจเพิ่มลิงก์สำหรับ Twitter และ Facebook เพื่อแชร์บริการของคุณที่ mysite.example.com ได้ดังนี้

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

โปรดทราบว่า Facebook อนุญาตให้ระบุ URL เพื่อแชร์ และ Twitter อนุญาตให้ระบุ URL และข้อความบางอย่าง

เมื่อฝังวิดีโอ

เมื่อคุณฝังวิดีโอจากเว็บไซต์ที่โฮสต์วิดีโอ ให้มองหาตัวเลือกการรักษาความเป็นส่วนตัวในโค้ดการฝัง เช่น สำหรับ YouTube ให้แทนที่ youtube.com ใน URL แบบฝังด้วย www.youtube-nocookie.com เพื่อหลีกเลี่ยงคุกกี้การติดตาม ปรากฏกับผู้ใช้ที่ดูหน้าการฝัง นอกจากนี้ คุณยังสามารถเลือก "เปิดใช้งานโหมดสำหรับความเป็นส่วนตัว" เมื่อสร้าง แชร์/ฝังลิงก์จาก YouTube เอง ตัวอย่างนี้เป็นตัวอย่างที่ดีของการใช้โหมดปกป้องผู้ใช้มากขึ้นที่บุคคลที่สามจัดหาให้ (https://support.google.com/youtube/answer/171780 อธิบายเรื่องนี้โดยละเอียดยิ่งขึ้น และตัวเลือกการฝังอื่นๆ สำหรับ YouTube โดยเฉพาะ)

เว็บไซต์วิดีโออื่นๆ มีตัวเลือกน้อยกว่าในเรื่องนี้ เช่น TikTok ไม่มีวิธีฝังวิดีโอโดยไม่ติดตาม ในขณะที่เขียนบทความนี้ คุณสามารถโฮสต์วิดีโอด้วยตนเองได้ (ซึ่งใช้ตัวเลือกอื่น) แต่ก็สามารถใช้ ทำงานได้มากขึ้น โดยเฉพาะเพื่อรองรับอุปกรณ์จำนวนมาก

เช่นเดียวกับวิดเจ็ตแบบอินเทอร์แอกทีฟที่พูดถึงไปก่อนหน้านี้ คุณมักจะแทนที่วิดีโอที่ฝังด้วยลิงก์ไปยังเว็บไซต์ที่แสดงได้ รูปแบบนี้จะเป็นแบบอินเทอร์แอกทีฟน้อยลงเนื่องจากวิดีโอจะไม่เล่นในหน้า แต่มีตัวเลือกว่าจะดูร่วมกับผู้ใช้หรือไม่ ประเภท ที่ใช้เป็นตัวอย่างของ "รูปแบบ Facade" ชื่อสำหรับการแทนที่เนื้อหาอินเทอร์แอกทีฟแบบไดนามิกด้วยสิ่งที่ผู้ใช้ต้องการ เพื่อทริกเกอร์ ให้แสดงขึ้น วิดีโอ TikTok ที่ฝังสามารถใช้ลิงก์แบบธรรมดาเพื่อไปยังหน้าวิดีโอ TikTok แทนได้ แต่จริงๆ แล้วมีลิงก์เพิ่มอีกเล็กน้อย คุณสามารถดึงและแสดงภาพขนาดย่อสำหรับวิดีโอและทำให้เป็นลิงก์ได้ แม้ว่าผู้ให้บริการวิดีโอ ที่เลือกไว้จะไม่ รองรับวิธีง่ายๆ ในการฝังวิดีโอโดยไม่ต้องติดตาม โฮสต์วิดีโอจำนวนมากรองรับ oEmbed ซึ่งเป็น API ที่ ลิงก์ไปยังวิดีโอหรือเนื้อหาที่ฝังไว้ จะแสดงรายละเอียดแบบเป็นโปรแกรมของวิดีโอนั้น ซึ่งรวมถึงภาพขนาดย่อและชื่อ TikTok รองรับ oEmbed (ดูรายละเอียดที่ https://developers.tiktok.com/doc/embed-videos) ซึ่งหมายความว่า คุณสามารถเปลี่ยนลิงก์ไปยังวิดีโอ TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 ให้เป็นข้อมูลเมตา JSON เกี่ยวกับวิดีโอนั้นได้ (ด้วยตนเองหรือแบบเป็นโปรแกรม) https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 และดึงข้อมูลภาพขนาดย่อ ที่จะแสดง WordPress มักจะใช้สิ่งนี้เพื่อขอ oEmbed" ข้อมูลสำหรับเนื้อหาที่ฝัง เป็นต้น คุณใช้โปรแกรมนี้ได้แบบเป็นโปรแกรม เพื่อแสดง "facade" ที่ดูอินเทอร์แอกทีฟ และเปลี่ยนไปเป็นการฝังหรือลิงก์ไปยังวิดีโออินเทอร์แอกทีฟเมื่อผู้ใช้เลือกที่จะคลิกวิดีโอ

เมื่อฝังสคริปต์ข้อมูลวิเคราะห์

Analytics ได้รับการออกแบบมาเพื่อรวบรวมข้อมูลเกี่ยวกับผู้ใช้เพื่อให้นำไปวิเคราะห์ได้ นี่คือจุดประสงค์ของการใช้งาน โดยพื้นฐานแล้ว ระบบ Analytics เพื่อเก็บรวบรวมและแสดงข้อมูลเกี่ยวกับการเข้าถึงและผู้ใช้ ซึ่งดำเนินการในเซิร์ฟเวอร์ของบุคคลที่สาม เช่น Google Analytics ได้อย่างง่ายดาย ของการใช้งานด้วย นอกจากนี้ยังมีระบบการวิเคราะห์ที่โฮสต์ด้วยตนเอง เช่น https://matomo.org/ แม้ว่าวิธีนี้จะมีประสิทธิภาพมากกว่าการใช้ ของบุคคลที่สามสำหรับเรื่องนี้ แต่การใช้งานระบบเช่นนี้บนโครงสร้างพื้นฐานของคุณเอง จะช่วยลดการเก็บรวบรวมข้อมูลได้ เพราะไม่ได้ออกจากระบบนิเวศของคุณเอง ในทางกลับกัน คุณควรจัดการข้อมูลนั้น นำข้อมูลออก และตั้งนโยบายสำหรับข้อมูลนั้น ให้เป็นความรับผิดชอบของคุณ ข้อกังวลส่วนใหญ่เกี่ยวกับการติดตามข้ามเว็บไซต์เกิดขึ้นเมื่อมีการดำเนินการแบบลับๆ และ อย่างลับๆ หรือมีผลข้างเคียงของการใช้บริการที่ไม่จำเป็นต้องมีการรวบรวมข้อมูลเลย ซอฟต์แวร์ Analytics ที่ออกแบบมาเพื่อรวบรวมข้อมูลเพื่อแจ้งให้เจ้าของเว็บไซต์ทราบเกี่ยวกับผู้ใช้

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

หากเว็บไซต์ของคุณและเว็บไซต์อื่นๆ ใช้บริการของบุคคลที่สาม บริการนั้นทำงานโดยคุณใส่ JavaScript ของบริการนั้นลงในเว็บไซต์ และจะตั้งค่าคุกกี้สำหรับผู้ใช้แต่ละราย ดังนั้นจึงควรคำนึงถึงว่าผู้ใช้อาจทำการจดจำแบบข้ามเว็บไซต์ที่ไม่พึงประสงค์ ซึ่งก็คือการติดตามผู้ใช้ในเว็บไซต์ต่างๆ บางส่วนอาจจะไม่เป็นเช่นนั้น แต่จุดยืนในการปกป้องความเป็นส่วนตัวในที่นี้คือการสันนิษฐานว่า ในความเป็นจริง บริการของบุคคลที่สามดังกล่าวจะทำการติดตามข้ามเว็บไซต์ นอกจากคุณจะมีเหตุผลที่ดีที่จะคิดหรือรู้อย่างอื่น คุณสมบัติข้อนี้ไม่ใช่เหตุผลที่ควรหลีกเลี่ยงบริการดังกล่าว แต่เป็นสิ่งที่ควรพิจารณาในการประเมินข้อดีข้อเสีย ของการใช้แอปเหล่านี้

ก่อนหน้านี้ ข้อมูลวิเคราะห์มีข้อดีคือต้องเลือกว่าจะใช้หรือไม่ใช้ข้อมูลวิเคราะห์เพียงอย่างเดียว นั่นคือรวบรวมข้อมูลทั้งหมดและละเมิดความเป็นส่วนตัวเพื่อแลกเปลี่ยน เพื่อหาข้อมูลเชิงลึกและการวางแผน หรือละทิ้งข้อมูลเชิงลึกไปโดยสิ้นเชิง อย่างไรก็ตาม จะไม่เป็นเช่นนั้นแล้ว และปัจจุบันมักมี ที่จะอยู่กึ่งกลางระหว่างปลายทั้งสองด้านนี้ ตรวจสอบผู้ให้บริการวิเคราะห์เพื่อหาตัวเลือกการกำหนดค่าเพื่อจำกัด เก็บรวบรวมข้อมูล รวมทั้งลดปริมาณและระยะเวลาในการจัดเก็บ เนื่องจากคุณมีบันทึกจากการตรวจสอบทางเทคนิค ดังที่อธิบายไว้ก่อนหน้านี้ คุณสามารถเรียกใช้ส่วนที่เกี่ยวข้องของการตรวจสอบนั้นอีกครั้ง เพื่อยืนยันว่าการเปลี่ยนแปลงการกำหนดค่าเหล่านี้ ทำให้จำนวนข้อมูลที่เก็บรวบรวมลดลงด้วย หากคุณทำการเปลี่ยนแปลงนี้ในเว็บไซต์ที่มีอยู่ การเปลี่ยนแปลงนี้จะ มาตรวัดเชิงปริมาณที่สามารถใช้เขียนให้กับผู้ใช้ของคุณ ตัวอย่างเช่น Google Analytics มีการเลือกใช้หลายรายการ (โดยค่าเริ่มต้นจึงปิดไว้) ฟีเจอร์ด้านความเป็นส่วนตัว ซึ่งหลายรายการอาจเป็นประโยชน์สำหรับการปฏิบัติตามกฎหมายคุ้มครองข้อมูลในท้องถิ่น ตัวเลือกบางอย่างที่ควรพิจารณาเมื่อตั้งค่า Google Analytics ได้รวมการตั้งค่าระยะเวลาเก็บรักษาข้อมูลที่เก็บรวบรวมไว้ (ผู้ดูแลระบบ > ข้อมูลการติดตาม > การเก็บรักษาข้อมูล) ให้ต่ำกว่าค่าเริ่มต้น 26 เดือน และเปิดใช้โซลูชันทางเทคนิคอื่นๆ เช่น การลบข้อมูลระบุ IP บางส่วน (ดูรายละเอียดเพิ่มเติมได้ที่ https://support.google.com/analytics/answer/9019185)

การใช้บุคคลที่สามในลักษณะที่รักษาความเป็นส่วนตัว

ถึงตอนนี้ เราได้กล่าวถึงวิธีปกป้องผู้ใช้จากบุคคลที่สามในขั้นตอนการออกแบบแอปพลิเคชัน คุณกำลังวางแผนสิ่งที่แอปพลิเคชันดังกล่าวจะทำ การตัดสินใจที่จะไม่ใช้บุคคลที่สามรายใดเลยเป็นส่วนหนึ่งของการวางแผนนี้ และการตรวจสอบการใช้งานของคุณก็จัดอยู่ในหมวดหมู่นี้เช่นกัน คือเป็นเรื่องของการตัดสินใจเกี่ยวกับจุดยืนด้านความเป็นส่วนตัวของคุณ อย่างไรก็ตาม การตัดสินใจนั้นไม่ค่อยละเอียดมากนัก การเลือกใช้บุคคลที่สามรายใดรายหนึ่งหรือเลือกที่จะไม่ใช้ไม่ใช่การตัดสินที่รายละเอียดเล็กๆ น้อยๆ มีความเป็นไปได้สูงว่าคุณต้องการอะไรบางอย่างระหว่างความต้องการ หรือวางแผนที่จะใช้ข้อเสนอของบุคคลที่สามบางอย่าง ลดแนวโน้มการละเมิดความเป็นส่วนตัว (ไม่ว่าจะโดยตั้งใจหรือไม่ตั้งใจ) การปกป้องผู้ใช้ใน "เวลาสร้าง" มีดังนี้ เพิ่มการป้องกันเพื่อลดอันตรายที่คุณไม่คาดคิด ทั้งหมดนี้คือส่วนหัว HTTP ใหม่ที่คุณสามารถระบุได้เมื่อแสดงผล ซึ่งจะแนะนำหรือสั่งให้ User Agent ดำเนินการเกี่ยวกับความเป็นส่วนตัวหรือความปลอดภัยบางอย่าง

นโยบาย URL ที่มา

ควรทำ

ตั้งค่านโยบาย strict-origin-when-cross-origin หรือ noreferrer เพื่อป้องกันไม่ให้เว็บไซต์อื่นๆ ได้รับส่วนหัวของผู้อ้างอิง เมื่อคุณลิงก์รายการดังกล่าวหรือเมื่อโหลดเป็นทรัพยากรย่อยตามหน้าเว็บ

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

หรือฝั่งเซิร์ฟเวอร์ ตัวอย่างเช่นใน Express

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

หากจำเป็น ให้ตั้งค่านโยบายตัวระบายเกี่ยวกับองค์ประกอบหรือคำขอที่เฉพาะเจาะจง

เหตุใดการดําเนินการนี้จะปกป้องความเป็นส่วนตัวของผู้ใช้

โดยค่าเริ่มต้น คำขอ HTTP แต่ละรายการที่เบราว์เซอร์จะส่งผ่านส่วนหัว Referer ซึ่งมี URL ของหน้าที่ส่งคำขอ ลิงก์ รูปภาพที่ฝัง หรือสคริปต์ ซึ่งอาจเป็นปัญหาด้านความเป็นส่วนตัว เนื่องจาก URL อาจมีข้อมูลส่วนตัว และ URL เหล่านั้น การพร้อมใช้งานสำหรับบุคคลที่สามจะส่งข้อมูลส่วนตัวดังกล่าวไปให้ Web.dev แสดงตัวอย่าง ของ URL ที่มีข้อมูลส่วนตัว เมื่อทราบว่าผู้ใช้มาที่เว็บไซต์ของคุณจาก https://social.example.com/user/me@example.com จะบอกคุณว่าผู้ใช้รายนั้นเป็นใคร นั่นคือการรั่วซึมที่แน่นอน แต่แม้แต่ URL ที่ไม่ได้เปิดเผยข้อมูลส่วนตัวไว้ ก็ทำให้ผู้ใช้รายนั้น (ซึ่งคุณอาจรู้จัก หากผู้ใช้เข้าสู่ระบบ) มาจากไซต์อื่น ซึ่งทำให้เห็นว่าผู้ใช้รายนี้เคยเข้าชมเว็บไซต์นั้น นี่ก็ขึ้นอยู่กับจำนวนผู้ที่เห็น ที่คุณอาจไม่ควรรู้เกี่ยวกับประวัติการเข้าชมของผู้ใช้ของคุณ

การระบุส่วนหัว Referrer-Policy (สะกดถูกต้อง!) ช่วยให้คุณสามารถแก้ไขสิ่งนี้เพื่อให้มีการส่งต่อ URL อ้างอิงบางส่วนหรือไม่มีการส่งต่อเลย MDN แสดงรายละเอียดทั้งหมดแต่เบราว์เซอร์ส่วนใหญ่มี ใช้ค่าสมมติอยู่ที่ strict-origin-when-cross-origin โดยค่าเริ่มต้น ซึ่งหมายความว่าตอนนี้ URL ที่มาได้จะส่งไปยัง บุคคลที่เป็นต้นทางเท่านั้น (https://web.dev ไม่ใช่ https://web.dev/learn/privacy) นี่คือการคุ้มครองความเป็นส่วนตัวที่มีประโยชน์ ไม่ต้องทำอะไรเลย แต่คุณสามารถทำให้แน่นแฟ้นขึ้นอีกได้โดยระบุ Referrer-Policy: same-origin เพื่อไม่ให้ผ่าน อ้างอิงข้อมูลให้แก่บุคคลที่สาม (หรือ Referrer-Policy: no-referrer เพื่อหลีกเลี่ยงการส่งต่อข้อมูลให้บุคคลอื่น ซึ่งรวมถึงต้นทางของคุณเอง) (นี่คือตัวอย่างที่ดีของความสมดุลระหว่างความเป็นส่วนตัวกับประโยชน์ใช้สอย ค่าเริ่มต้นใหม่มีการรักษาความเป็นส่วนตัวมากกว่าแต่ก่อน ยังคงให้ข้อมูลระดับสูงแก่บุคคลที่สามที่คุณเลือก เช่น ผู้ให้บริการวิเคราะห์)

นอกจากนี้ การระบุส่วนหัวนี้อย่างชัดแจ้งยังมีประโยชน์เนื่องจากคุณจะทราบแน่ชัดว่านโยบายคืออะไร แทนที่จะใช้ค่าเริ่มต้นของเบราว์เซอร์ หากตั้งค่าส่วนหัวไม่ได้ คุณอาจตั้งค่านโยบายผู้อ้างอิงสำหรับหน้า HTML ทั้งหมดโดยใช้องค์ประกอบเมตาใน <head> ดังนี้ <meta name="referrer" content="same-origin">; และหากมีข้อกังวลเกี่ยวกับบุคคลที่สามรายใดรายหนึ่ง คุณสามารถตั้งค่าreferrerpolicy ในองค์ประกอบแต่ละรายการ เช่น <script>, <a> หรือ <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

ส่วนหัว Content-Security-Policy หรือที่มักเรียกกันว่า "CSP" จะกำหนดว่าทรัพยากรภายนอกจะโหลดจากที่ไหน คีย์นี้ใช้เพื่อวัตถุประสงค์ด้านความปลอดภัยเป็นหลัก โดยการป้องกันการโจมตีแบบ Cross-site Scripting และการแทรกสคริปต์ แต่เมื่อใช้แล้ว ควบคู่ไปกับการตรวจสอบตามปกติ คุณยังจำกัดว่าบุคคลที่สามที่คุณเลือกจะส่งต่อข้อมูลไปให้บุคคลที่สามที่ใด

วิธีนี้จึงอาจเป็นประสบการณ์ของผู้ใช้ที่ไม่ดีนัก หากสคริปต์ของบุคคลที่สามรายการหนึ่งของคุณเริ่มโหลดทรัพยากร Dependency จาก ต้นทางไม่ได้อยู่ในรายการของคุณ คำขอนั้นจะถูกบล็อก สคริปต์จะล้มเหลว และแอปพลิเคชันของคุณอาจล้มเหลว (หรืออย่างน้อยก็ลดลงให้เป็นเวอร์ชันสำรองที่ล้มเหลวด้วย JavaScript) ซึ่งจะเป็นประโยชน์เมื่อมีการใช้ CSP เพื่อความปลอดภัย ซึ่งมีจุดประสงค์ปกติคือการป้องกันปัญหาการเขียนสคริปต์ข้ามเว็บไซต์ (และควรใช้ CSP ที่เข้มงวด) เมื่อคุณทราบสคริปต์ในหน้าทั้งหมดที่หน้าเว็บของคุณใช้แล้ว คุณสามารถสร้างรายการ คำนวณค่าแฮช หรือใส่ค่าแบบสุ่มได้ (เรียกว่า "nonce") สำหรับแต่ละรายการ แล้วเพิ่มรายการแฮชลงในนโยบายรักษาความปลอดภัยเนื้อหา ซึ่งจะป้องกันสคริปต์ใดๆ ไม่ได้โหลดอยู่ในรายการ ซึ่งจะต้องอบเข้าสู่กระบวนการสร้างสำหรับเว็บไซต์: สคริปต์ในหน้าเว็บของคุณต้องการ เพื่อรวม Nonce หรือให้คำนวณแฮชเป็นส่วนหนึ่งของบิลด์ ดูรายละเอียดทั้งหมดได้ในบทความเกี่ยวกับ strict-csp

โชคดีที่เบราว์เซอร์รองรับส่วนหัวที่เกี่ยวข้อง ซึ่งก็คือ Content-Security-Policy-Report-Only หากมีส่วนหัวนี้ คำขอ ที่ละเมิดนโยบายที่ระบุจะไม่ถูกบล็อก แต่จะส่งรายงาน JSON ไปยัง URL ที่ระบุ ส่วนหัวดังกล่าวอาจ ซึ่งจะมีลักษณะดังนี้ Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, และหากเบราว์เซอร์โหลดสคริปต์จากที่อื่นที่ไม่ใช่ 3p.example.com คำขอนั้นจะสำเร็จ แต่รายงานจะ จะส่งไปยัง report-uri ที่ระบุ โดยปกติแล้ว จะใช้ในการทดสอบกับนโยบาย ก่อนที่จะใช้ แต่ แนวคิดหลักคือการใช้วิธีการนี้เป็นวิธีหนึ่งในการดำเนินการ "การตรวจสอบอย่างต่อเนื่อง" นอกจากการตรวจสอบตามปกติที่อธิบายไปก่อนหน้านี้ คุณ สามารถเปิดการรายงาน CSP เพื่อดูว่ามีโดเมนที่ไม่คาดคิดปรากฏขึ้นหรือไม่ ซึ่งอาจหมายความว่ากำลังโหลดทรัพยากรของบุคคลที่สาม ทรัพยากรของบุคคลที่สามของตนเอง ซึ่งคุณต้องพิจารณาและประเมิน (ซึ่งอาจเป็นสัญญาณของการข้ามเว็บไซต์ การใช้สคริปต์การเจาะช่องโหว่ที่หลุดพ้นขอบเขตความปลอดภัยของคุณไปแล้ว ซึ่งเป็นสิ่งสำคัญที่ควรทราบด้วยเช่นกัน)

Content-Security-Policy เป็น API ที่ซับซ้อนและยุ่งยากในการใช้งาน สิ่งนี้เป็นที่รู้จักและมีงานที่ทำต่อไปเพื่อสร้าง "คนรุ่นใหม่" ของ CSP ซึ่งจะบรรลุเป้าหมายเดียวกัน แต่อาจใช้งานยากสักเท่าไหร่ นั่นยังไม่พร้อมใช้งาน แต่หากต้องการดูว่าตอนนี้กำลังมุ่งไปตรงไหน (หรือเข้าไปมีส่วนร่วมและมีส่วนร่วมในการออกแบบเลยก็ได้) ดูรายละเอียดได้ที่ https://github.com/WICG/csp-next

ควรทำ

เพิ่มส่วนหัว HTTP นี้ลงในหน้าที่แสดง: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control เมื่อมีการโพสต์ JSON ไปยัง URL ดังกล่าว ให้จัดเก็บไว้ ตรวจสอบข้อมูลที่จัดเก็บไว้เพื่อรับชุดโดเมนของบุคคลที่สามที่เว็บไซต์ของคุณร้องขอเมื่อผู้อื่นเข้าชม อัปเดตส่วนหัว Content-Security-Policy-Report-Only เพื่อแสดงโดเมนที่คาดไว้เพื่อดูว่ารายการดังกล่าวมีการเปลี่ยนแปลงเมื่อใด

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

ทำไม

ซึ่งเป็นส่วนหนึ่งของการตรวจสอบทางเทคนิคอย่างต่อเนื่อง การตรวจสอบทางเทคนิคครั้งแรกที่คุณดำเนินการจะให้ รายชื่อของบุคคลที่สามที่เว็บไซต์ของคุณแชร์หรือส่งข้อมูลผู้ใช้ไปให้ จากนั้นส่วนหัวนี้จะทำให้คำขอหน้าเว็บรายงาน บุคคลที่สามซึ่งได้รับการติดต่อแล้ว และคุณติดตามการเปลี่ยนแปลงเมื่อเวลาผ่านไปได้ การดำเนินการนี้ไม่เพียงแต่จะแจ้งเตือนคุณเกี่ยวกับการเปลี่ยนแปลงเท่านั้น ซึ่งดำเนินการโดยบุคคลที่สามที่มีอยู่ของคุณ แต่จะระบุบุคคลที่สามที่เพิ่มเข้ามาใหม่ซึ่งไม่ได้เพิ่มไว้ในการตรวจสอบทางเทคนิคด้วย การอัปเดตส่วนหัวเพื่อหยุดการรายงานเกี่ยวกับโดเมนที่คุณคาดไว้เป็นสิ่งสำคัญ แต่คุณก็ควรต้องการทำเช่นนี้ซ้ำๆ ด้วยตนเองด้วย การตรวจสอบทางเทคนิคเป็นครั้งคราว (เนื่องจากแนวทางของ Content-Security-Policy ไม่ได้แจ้งข้อมูลที่ส่ง แต่เป็นเพียง ที่มีการส่งคำขอ)

โปรดทราบว่าคุณไม่จำเป็นต้องเพิ่ม URL ดังกล่าวลงในหน้าที่แสดงทุกครั้งหรือทุกหน้า ปรับจำนวนการตอบกลับหน้าเว็บที่ได้รับ ส่วนหัวเพื่อให้คุณได้รับตัวอย่างรายงานที่ไม่มีปริมาณมากเกินไป

นโยบายสิทธิ์

ส่วนหัว Permissions-Policy (ซึ่งเปิดตัวภายใต้ชื่อ Feature-Policy) มีแนวคิดคล้ายกับ Content-Security-Policy แต่ก็จำกัดการเข้าถึงฟีเจอร์ที่มีประสิทธิภาพในเบราว์เซอร์ด้วย เช่น คุณอาจจำกัดการใช้ฮาร์ดแวร์ของอุปกรณ์อย่างตัวตรวจวัดความเร่ง กล้องหรืออุปกรณ์ USB หรือเพื่อจำกัดฟีเจอร์ที่ไม่ใช่ฮาร์ดแวร์ เช่น สิทธิ์ในการเต็มหน้าจอหรือใช้ XMLHTTPRequest แบบซิงโครนัส ข้อจำกัดเหล่านี้สามารถใช้กับหน้าระดับบนสุด (เพื่อหลีกเลี่ยงการโหลดสคริปต์จากการพยายามใช้ฟีเจอร์เหล่านี้) หรือเพื่อ หน้าเว็บเฟรมย่อยที่โหลดผ่าน iframe การจำกัดการใช้ API นี้ไม่ใช่การใช้ลายนิ้วมือของเบราว์เซอร์ คือการไม่อนุญาตให้บุคคลที่สามทำสิ่งที่รบกวนผู้ใช้ (เช่น การใช้ API ที่มีประสิทธิภาพ, การแสดงป๊อปอัป หน้าต่างสิทธิ์ ฯลฯ) ซึ่งกำหนดโดย Target Privacy Threat Model เป็น "การบุกรุก"

ส่วนหัว Permissions-Policy จะระบุเป็นรายการคู่ (ฟีเจอร์ ต้นทางที่อนุญาต) ดังนี้

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

ตัวอย่างนี้อนุญาตให้หน้านี้ ("ตัวเอง") และ <iframe> จากต้นทาง example.com ใช้ API ของ navigator.geolocation จาก JavaScript จะอนุญาตให้หน้านี้และเฟรมย่อยทั้งหมดใช้ API แบบเต็มหน้าจอได้ แต่ห้ามมิให้หน้าเว็บใดรวมถึงหน้านี้รวมอยู่ด้วย จากการใช้กล้องเพื่ออ่านข้อมูลวิดีโอ มีรายละเอียดเพิ่มเติมและรายการตัวอย่างที่เป็นไปได้ที่นี่

รายการฟีเจอร์ที่จัดการโดยส่วนหัว "สิทธิ์-นโยบาย" มีขนาดใหญ่และอาจแสดงไม่พร้อมกัน ปัจจุบันรายการคือ ซึ่งดูแลได้ที่ https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md

ควรทำ

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

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

ขออภัย การบล็อกฟีเจอร์ทั้งหมดโดยค่าเริ่มต้น แล้วเลือกอนุญาตฟีเจอร์เหล่านั้นอีกครั้ง จะต้องมีการแสดงฟีเจอร์ทั้งหมดในส่วนหัว ซึ่งทำให้ดูไม่ค่อยสัญชาตญาณ อย่างไรก็ตาม ส่วนหัว Permissions-Policy เช่นนี้ก็เป็นจุดเริ่มต้นที่ดี permissionspolicy.com/ มีเครื่องมือสร้างที่คลิกได้เพื่อความสะดวกในการสร้างส่วนหัวดังกล่าว การใช้เพื่อสร้างส่วนหัวซึ่งปิดใช้ฟีเจอร์ทั้งหมดจะทำให้เกิดสิ่งนี้:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

ทำความเข้าใจฟีเจอร์ความเป็นส่วนตัวที่มีมาในตัวเว็บเบราว์เซอร์

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

ได้แก่ Intelligent Tracking Prevention ใน Safari (และเครื่องมือ WebKit ที่สำคัญ) และการป้องกันการติดตามที่ปรับปรุงแล้ว ใน Firefox (และ Gecko) ทั้งหมดนี้ทำให้บุคคลที่สามสร้างโปรไฟล์โดยละเอียดของผู้ใช้ได้ยาก

การเข้าถึงฟีเจอร์ด้านความเป็นส่วนตัวของเบราว์เซอร์มีการเปลี่ยนแปลงบ่อยครั้ง และการติดตามข้อมูลล่าสุดจึงเป็นเรื่องสำคัญ รายการการป้องกันต่อไปนี้ ถูกต้องขณะเขียน เบราว์เซอร์อาจใช้การป้องกันอื่นๆ ด้วย รายการเหล่านี้ยังไม่ใช่ข้อมูลทั้งหมด ดูโมดูลแนวทางปฏิบัติแนะนำ เพื่อดูวิธีติดตามการเปลี่ยนแปลงในส่วนนี้ และอย่าลืมทดสอบกับเบราว์เซอร์เวอร์ชันใหม่ๆ เพื่อหาการเปลี่ยนแปลงที่อาจส่งผลต่อโปรเจ็กต์ของคุณ โปรดทราบว่าบางครั้งโหมดการท่องเว็บแบบไม่ระบุตัวตน/แบบส่วนตัวจะใช้การตั้งค่าที่แตกต่างจากค่าเริ่มต้นของเบราว์เซอร์ (คุกกี้ของบุคคลที่สามอาจถูกบล็อก โดยค่าเริ่มต้นในโหมดดังกล่าว เป็นต้น) ดังนั้น การทดสอบในโหมดไม่ระบุตัวตนอาจไม่ได้สะท้อนถึงประสบการณ์การเรียกดูตามปกติของผู้ใช้ส่วนใหญ่เสมอไป หาก พวกเขาไม่ได้ใช้การเรียกดูแบบส่วนตัว นอกจากนี้ โปรดทราบว่าการบล็อกคุกกี้ในสถานการณ์ต่างๆ อาจหมายความว่าโซลูชันพื้นที่เก็บข้อมูลอื่นๆ เช่น window.localStorage ถูกบล็อกด้วย ไม่ใช่แค่คุกกี้

Chrome

  • เราตั้งใจที่จะบล็อกคุกกี้ของบุคคลที่สามในอนาคต ตั้งแต่การเขียนนี้เป็นต้นไป ข้อความจะไม่ถูกบล็อกโดยค่าเริ่มต้น (แต่ผู้ใช้เปิดใช้ได้) ดังนี้ https://support.google.com/chrome/answer/95647 จะอธิบายรายละเอียด
  • คุณลักษณะความเป็นส่วนตัวของ Chrome โดยเฉพาะอย่างยิ่งคุณลักษณะใน Chrome ที่สื่อสารกับ Google และบริการของบุคคลที่สาม ตามที่อธิบายไว้ใน privacysandbox.com/

Edge

  • ระบบจะไม่บล็อกคุกกี้ของบุคคลที่สามโดยค่าเริ่มต้น (แต่ผู้ใช้เปิดใช้ได้)
  • การบล็อกฟีเจอร์การป้องกันการติดตามของ Edge ระบบจะบล็อกอุปกรณ์ติดตามจากเว็บไซต์ที่ไม่ได้เข้าชมและอุปกรณ์ที่ทราบว่าเป็นอันตรายโดยค่าเริ่มต้น

Firefox

  • ระบบจะไม่บล็อกคุกกี้ของบุคคลที่สามโดยค่าเริ่มต้น (แต่ผู้ใช้เปิดใช้ได้)
  • การป้องกันการติดตามที่ปรับปรุงแล้วของ Firefox จะบล็อกคุกกี้การติดตามโดยค่าเริ่มต้น การเก็บสคริปต์ ฟิงเกอร์ปรินต์ สคริปต์เข้ารหัส และเครื่องมือติดตามที่รู้จัก (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track จะให้รายละเอียดเพิ่มเติม)
  • คุกกี้ของบุคคลที่สามเป็นแบบจำกัดเว็บไซต์ ดังนั้นแต่ละเว็บไซต์จึงมีโหลคุกกี้แยกกันและไม่สามารถเชื่อมโยงกันข้ามเว็บไซต์ (Mozilla เรียกสิ่งนี้ว่า "การป้องกันคุกกี้ทั้งหมด"

หากต้องการรับข้อมูลเชิงลึกเกี่ยวกับสิ่งที่อาจถูกบล็อกและเพื่อช่วยแก้ไขข้อบกพร่อง ให้คลิกไอคอนโล่ในแถบที่อยู่หรือไปที่ about:protections ใน Firefox (บนเดสก์ท็อป)

Safari

  • ระบบจะบล็อกคุกกี้ของบุคคลที่สามโดยค่าเริ่มต้น
  • ในฐานะส่วนหนึ่งของฟีเจอร์การป้องกันการติดตามอัจฉริยะ Safari จะลดผู้อ้างอิงที่ส่งไปยังหน้าเว็บอื่นๆ ให้เป็นไซต์ระดับบนสุดแทนที่จะเป็นหน้าเว็บเฉพาะ: (https://something.example.com, แทนที่จะเป็น https://something.example.com/this/specific/page)
  • ข้อมูลเบราว์เซอร์ localStorage จะถูกลบหลังจากผ่านไป 7 วัน

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ สรุปฟีเจอร์เหล่านี้)

เปิดใช้ "โหมดแก้ไขข้อบกพร่องของการป้องกันการติดตามอัจฉริยะ" เพื่อรับข้อมูลเชิงลึกเกี่ยวกับสิ่งที่อาจถูกบล็อกและเพื่อช่วยแก้ไขข้อบกพร่อง ใน Safari เมนูนักพัฒนาซอฟต์แวร์ (บนเดสก์ท็อป) (ดูรายละเอียดเพิ่มเติมได้ที่ https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/)

ข้อเสนอ API

ทำไมเราถึงต้องมี API ใหม่

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

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

ต้องมีแนวทางใหม่: เมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามและลดการจำกัดฟิงเกอร์ปรินต์ นักพัฒนาแอปจึงต้องการ API ที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะ ที่เป็นไปตามกรณีการใช้งาน (ที่ยังคงเดิม) แต่ออกแบบมาในลักษณะที่รักษาความเป็นส่วนตัว เป้าหมายคือการออกแบบและสร้าง API ที่ใช้กับการติดตามข้ามเว็บไซต์ไม่ได้ เทคโนโลยีเหล่านี้แตกต่างจากคุณลักษณะของเบราว์เซอร์ที่อธิบายในส่วนก่อนหน้านี้ มีเป้าหมายที่จะเป็น API ข้ามเบราว์เซอร์

ตัวอย่างข้อเสนอ API

รายการต่อไปนี้เป็นเพียงตัวอย่างบางส่วนของสิ่งที่กำลังกล่าวถึงอยู่เท่านั้น

ตัวอย่างข้อเสนอ API ที่จะแทนที่เทคโนโลยีที่สร้างขึ้นจากคุกกี้ของบุคคลที่สามมีดังนี้

ตัวอย่างข้อเสนอ API ที่จะแทนที่เทคโนโลยีที่สร้างขึ้นจากการติดตามแบบแพสซีฟ

ตัวอย่างข้อเสนออื่นๆ ที่ API อื่นๆ สร้างขึ้นได้ในอนาคตโดยไม่ต้องใช้คุกกี้ของบุคคลที่สาม

นอกจากนี้ ยังมีข้อเสนอ API อีกประเภทหนึ่งให้ลองลดการติดตามโดยไม่เปิดเผยเฉพาะเบราว์เซอร์ได้ ตัวอย่างหนึ่งคืองบประมาณความเป็นส่วนตัว ในหลายๆ ด้านเหล่านี้ API ที่ Chrome เสนอเป็นครั้งแรกจะใช้งานได้ตามข้อกำหนดที่ครอบคลุมของ Privacy Sandbox

Global-Privacy-Control คือส่วนหัวที่มีเจตนาสื่อสารกับเว็บไซต์ที่ผู้ใช้ ต้องการให้เราไม่แชร์ข้อมูลส่วนตัวที่รวบรวมไว้กับเว็บไซต์อื่นๆ โดยเจตนาจะคล้ายกับ "ไม่ติดตาม" ซึ่งเลิกใช้งานแล้ว

สถานะของข้อเสนอ API

ข้อเสนอ API เหล่านี้ส่วนใหญ่ยังไม่ได้ติดตั้งใช้งาน หรือติดตั้งใช้งานหลังแฟล็กหรืออยู่ในสภาพแวดล้อมที่จำกัดเพื่อการทดสอบเท่านั้น

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

ที่ที่ดีที่สุดในการอัปเดต API ใหม่ที่เสนอคือรายการข้อเสนอของกลุ่มความเป็นส่วนตัวใน GitHub

จำเป็นต้องใช้ API เหล่านี้ไหม

หากผลิตภัณฑ์ของคุณสร้างขึ้นจากคุกกี้ของบุคคลที่สามโดยตรงหรือเทคนิคต่างๆ เช่น การเก็บลายนิ้วมือ คุณควรมีส่วนร่วมกับ API ใหม่เหล่านี้ ทดลองใช้ API และร่วมสร้างประสบการณ์ของคุณเองในการสนทนาและการออกแบบ API ในกรณีอื่นๆ ทั้งหมด คุณไม่จำเป็นต้องทราบรายละเอียดทั้งหมดเกี่ยวกับ API ใหม่เหล่านี้ในขณะที่เขียน แต่คุณควรทราบว่าจะมีอะไรเกิดขึ้นบ้าง