บุคคลที่สามคืออะไร
มีความเป็นไปได้น้อยมากที่เว็บไซต์จะมีเว็บไซต์ในตัวมันเองทั้งหมด ผลการประเมินเว็บ 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) และรวมข้อมูล และการตรวจสอบความเป็นส่วนตัว ในขั้นตอนดังกล่าวก็ช่วยให้ทำได้ง่ายขึ้น
ควรทำ
เปิดเบราว์เซอร์ที่มีโปรไฟล์ผู้ใช้ใหม่ที่ดูสะอาดตา เพื่อคุณจะได้ไม่ได้ลงชื่อเข้าใช้และไม่มีข้อตกลงที่จัดเก็บไว้ จากนั้นให้เปิดเบราว์เซอร์ เครื่องมือการพัฒนา แผงเครือข่าย เพื่อดูคำขอขาออกทั้งหมด เพิ่มคอลัมน์ใหม่เพื่อแสดงโดเมนของแต่ละคำขอ และตรวจสอบ "คำขอของบุคคลที่สาม" เพื่อแสดงเฉพาะบุคคลที่สาม หากมี จากนั้นให้ทำดังนี้
- ไปที่เว็บไซต์ของคุณ
- ลงชื่อสมัครใช้บัญชีใหม่ หากคุณระบุบัญชีผู้ใช้
- ลองลบบัญชีที่สร้างไว้
- ดำเนินการปกติบนเว็บไซต์ 1-2 อย่าง (ซึ่งขึ้นอยู่กับสิ่งที่เว็บไซต์ทำ แต่ให้เลือกการดำเนินการทั่วไปที่ผู้ใช้ส่วนใหญ่ทำ)
- ดำเนินการ 1-2 อย่างที่คุณทราบว่าเกี่ยวข้องกับทรัพยากร Dependency ของบุคคลที่สามโดยเฉพาะ ซึ่งอาจรวมถึงการแชร์เนื้อหากับ โซเชียลมีเดีย การเริ่มต้นขั้นตอนการชำระเงิน หรือการฝังเนื้อหาจากเว็บไซต์อื่น
ขณะทำงานเหล่านี้ ให้สร้างระเบียนของทรัพยากรที่ขอจากโดเมนที่ไม่ใช่ของคุณ โดยดูที่แผงเครือข่าย ตามที่อธิบายไว้ นี่คือบุคคลที่สามบางส่วนของคุณ วิธีที่ดีในการทำเช่นนี้คือใช้เครื่องมือเครือข่ายของเบราว์เซอร์เพื่อจับภาพเครือข่าย บันทึกคำขอในไฟล์ HAR
ไฟล์ HAR และการจับภาพ
ไฟล์ HAR เป็นรูปแบบ JSON แบบมาตรฐานของคำขอเครือข่ายทั้งหมดที่มาจากหน้าเว็บ หากต้องการรับไฟล์ HAR สำหรับหน้าใดหน้าหนึ่ง ให้ดำเนินการดังนี้
Chrome
เปิดเครื่องมือสำหรับนักพัฒนาเว็บในเบราว์เซอร์ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ และ ให้เลือกสัญลักษณ์บันทึกลูกศรลงที่ด้านบนขวาใกล้กับเมนูแบบเลื่อนลง "ไม่มีการควบคุม"
Firefox
เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือนักพัฒนาเว็บ) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ และเลือก สัญลักษณ์เฟืองที่ด้านบนขวาข้างเมนูแบบเลื่อนลง "การควบคุม" จากเมนู ให้เลือก Save All As HAR**
Safari
เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > พัฒนา > แสดงเครื่องมือตรวจสอบเว็บ หากคุณไม่มีเมนู "พัฒนา" ให้เปิดใช้จาก เมนู > Safari > ค่ากำหนด > ขั้นสูง > แสดงเมนู "พัฒนา" ในแถบเมนู) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้า แล้วเลือกส่งออกที่ด้านขวาบน (ทางด้านขวาของ Preserve Log คุณอาจต้องขยายหน้าต่าง)
สำหรับรายละเอียดเพิ่มเติม คุณยังสามารถบันทึกรายการที่ส่งมายังบุคคลที่สาม (ในส่วนคำขอ) แม้ว่าข้อมูลนี้มักจะ มีความสับสนและตีความไม่ได้อย่างเป็นประโยชน์
แนวทางปฏิบัติแนะนำเมื่อผสานรวมกับบุคคลที่สาม
คุณสามารถกำหนดนโยบายของคุณเองเกี่ยวกับบุคคลที่สามที่เว็บไซต์ของคุณใช้ โดยเปลี่ยนผู้ให้บริการโฆษณาที่คุณใช้ตามแนวทางปฏิบัติของบุคคลที่สาม หรือป๊อปอัปความยินยอมในการใช้คุกกี้ที่น่ารำคาญหรือรบกวนผู้ใช้มากน้อยเพียงใด หรือคุณต้องการใช้ปุ่มโซเชียลมีเดียบนเว็บไซต์หรือ สำหรับติดตามลิงก์ในอีเมลหรือลิงก์ 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!&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 ที่จะแทนที่เทคโนโลยีที่สร้างขึ้นจากคุกกี้ของบุคคลที่สามมีดังนี้
- กรณีการใช้งานข้อมูลประจำตัว: FedCM
- กรณีการใช้งานของโฆษณา: การวัดคลิกส่วนตัว การระบุแหล่งที่มาส่วนตัวที่ทำงานร่วมกัน Attribution Reporting, Topics, FLEDGE, PARAKEET
ตัวอย่างข้อเสนอ API ที่จะแทนที่เทคโนโลยีที่สร้างขึ้นจากการติดตามแบบแพสซีฟ
- กรณีการใช้งานของการตรวจจับการประพฤติมิชอบ: โทเค็นความน่าเชื่อถือ
ตัวอย่างข้อเสนออื่นๆ ที่ API อื่นๆ สร้างขึ้นได้ในอนาคตโดยไม่ต้องใช้คุกกี้ของบุคคลที่สาม
นอกจากนี้ ยังมีข้อเสนอ API อีกประเภทหนึ่งให้ลองลดการติดตามโดยไม่เปิดเผยเฉพาะเบราว์เซอร์ได้ ตัวอย่างหนึ่งคืองบประมาณความเป็นส่วนตัว ในหลายๆ ด้านเหล่านี้ API ที่ Chrome เสนอเป็นครั้งแรกจะใช้งานได้ตามข้อกำหนดที่ครอบคลุมของ Privacy Sandbox
Global-Privacy-Control คือส่วนหัวที่มีเจตนาสื่อสารกับเว็บไซต์ที่ผู้ใช้ ต้องการให้เราไม่แชร์ข้อมูลส่วนตัวที่รวบรวมไว้กับเว็บไซต์อื่นๆ โดยเจตนาจะคล้ายกับ "ไม่ติดตาม" ซึ่งเลิกใช้งานแล้ว
สถานะของข้อเสนอ API
ข้อเสนอ API เหล่านี้ส่วนใหญ่ยังไม่ได้ติดตั้งใช้งาน หรือติดตั้งใช้งานหลังแฟล็กหรืออยู่ในสภาพแวดล้อมที่จำกัดเพื่อการทดสอบเท่านั้น
ระยะการบ่มเพาะสาธารณะนี้มีความสำคัญ ผู้ให้บริการเบราว์เซอร์และนักพัฒนาซอฟต์แวร์ต่างรวบรวมการพูดคุยและบอกเล่าประสบการณ์ว่า API เหล่านี้ มีประโยชน์หรือไม่ และทำตามจุดประสงค์ที่กำหนดจริงๆ หรือไม่ นักพัฒนาซอฟต์แวร์ ผู้ให้บริการเบราว์เซอร์ และผู้ที่มีบทบาทในระบบนิเวศอื่นๆ ใช้ระยะนี้ มาปรับปรุงการออกแบบของ API ให้ดียิ่งขึ้น
ที่ที่ดีที่สุดในการอัปเดต API ใหม่ที่เสนอคือรายการข้อเสนอของกลุ่มความเป็นส่วนตัวใน GitHub
จำเป็นต้องใช้ API เหล่านี้ไหม
หากผลิตภัณฑ์ของคุณสร้างขึ้นจากคุกกี้ของบุคคลที่สามโดยตรงหรือเทคนิคต่างๆ เช่น การเก็บลายนิ้วมือ คุณควรมีส่วนร่วมกับ API ใหม่เหล่านี้ ทดลองใช้ API และร่วมสร้างประสบการณ์ของคุณเองในการสนทนาและการออกแบบ API ในกรณีอื่นๆ ทั้งหมด คุณไม่จำเป็นต้องทราบรายละเอียดทั้งหมดเกี่ยวกับ API ใหม่เหล่านี้ในขณะที่เขียน แต่คุณควรทราบว่าจะมีอะไรเกิดขึ้นบ้าง