บุคคลที่สามคืออะไร
ค่อนข้างหายากที่เว็บไซต์จะมีสมบูรณ์ในตัวเอง สถิติเว็บ HTTP แสดงให้เห็นว่าเว็บไซต์ส่วนใหญ่ประมาณ 95% มีเนื้อหาของบุคคลที่สามบางส่วน
Almanac ให้คำจำกัดความเนื้อหาของบุคคลที่สามว่า "โฮสต์" บนต้นทางที่แชร์และเป็นสาธารณะ ซึ่งมีการใช้งานกันอย่างกว้างขวางในเว็บไซต์ต่างๆ และเจ้าของเว็บไซต์นั้นๆ ไม่มีอิทธิพล ซึ่งอาจเป็นรูปภาพหรือสื่ออื่นๆ เช่น วิดีโอ แบบอักษร หรือสคริปต์ รูปภาพและสคริปต์มีความสำคัญมากกว่าสิ่งอื่นใดที่ผสานรวมกัน เนื้อหาของบุคคลที่สามไม่จำเป็นต่อการพัฒนาเว็บไซต์ แต่ก็อาจเป็นไปได้ด้วย คุณจะต้องใช้สิ่งที่โหลดจากเซิร์ฟเวอร์ที่แชร์สาธารณะ ไม่ว่าจะเป็นแบบอักษรเว็บ, iframe ที่ฝังไว้ของวิดีโอ, โฆษณา หรือไลบรารี JavaScript ตัวอย่างเช่น คุณอาจใช้แบบอักษรบนเว็บที่แสดงจาก Google Fonts หรือวัดการวิเคราะห์ด้วย Google Analytics คุณอาจเพิ่มปุ่ม "ชอบ" หรือ "ลงชื่อเข้าใช้ด้วยปุ่ม" จากโซเชียลเน็ตเวิร์ก คุณอาจฝังแผนที่หรือวิดีโอ หรือจัดการการซื้อสินค้าผ่านบริการของบุคคลที่สาม ติดตามข้อผิดพลาดและบันทึกของทีมพัฒนาเองผ่านเครื่องมือตรวจสอบของบุคคลที่สาม
สำหรับวัตถุประสงค์ด้านความเป็นส่วนตัว ควรพิจารณาคำจำกัดความที่แตกต่างกันเล็กน้อยและกว้างน้อยลง กล่าวคือ ทรัพยากรของบุคคลที่สาม (โดยเฉพาะสคริปต์ของบุคคลที่สาม) แสดงจากแหล่งที่มาที่แชร์และเป็นสาธารณะและใช้กันอย่างกว้างขวางตามที่แสดงให้เห็น แต่บุคคลอื่นที่ไม่ใช่เจ้าของเว็บไซต์ก็เขียนขึ้นด้วยเช่นกัน แง่มุมของนักเขียนของบุคคลที่สามคือหัวใจสำคัญเมื่อพิจารณาวิธีปกป้องความเป็นส่วนตัวของผู้ใช้จากผู้อื่น ซึ่งจะช่วยให้คุณพิจารณาว่ามีความเสี่ยงอะไรบ้าง แล้วตัดสินใจว่าจะใช้ทรัพยากรของบุคคลที่สามโดยพิจารณาจากความเสี่ยงเหล่านั้นอย่างไร อย่างที่ได้กล่าวไปแล้ว ข้อมูลเหล่านี้จะช่วยให้คุณเข้าใจบริบทและรู้ว่าต้องทำอะไรบ้างและต้องแลกกับอะไร และหมายความว่าอย่างไร
แต่นี่ไม่ใช่เป้าหมายเมื่อพูดถึง "ทรัพยากรของบุคคลที่สาม" โดยทั่วไป ความแตกต่างระหว่างบุคคลที่หนึ่งและบุคคลที่สามคือบริบทที่มีการใช้บางสิ่ง สคริปต์ที่โหลดจากเว็บไซต์อื่นเป็นทรัพยากรของบุคคลที่สาม และคำขอ HTTP ที่โหลดสคริปต์อาจมีคุกกี้ แต่จริงๆ แล้วคุกกี้เหล่านั้นไม่ใช่ "คุกกี้ของบุคคลที่สาม" จริงๆ เป็นเพียงคุกกี้ และจะเป็น "บุคคลที่สาม" หรือ "บุคคลที่หนึ่ง" ขึ้นอยู่กับว่าสคริปต์กำลังโหลดในหน้าเว็บของเว็บไซต์หรือหน้าในเว็บไซต์ของเจ้าของสคริปต์
เหตุผลที่เราใช้ทรัพยากรของบุคคลที่สาม
ผู้ให้บริการบุคคลที่สามเป็นวิธีที่ยอดเยี่ยมในการเพิ่มฟังก์ชันการทำงานให้กับเว็บไซต์ ฟีเจอร์ดังกล่าวอาจเป็นฟีเจอร์ที่ผู้ใช้เปิดเผยหรือฟังก์ชันของนักพัฒนาซอฟต์แวร์ที่มองไม่เห็น เช่น การติดตามข้อผิดพลาด แต่ฟังก์ชันเหล่านี้จะลดภาระงานด้านการพัฒนาซอฟต์แวร์ของคุณ และผู้อื่นจะเป็นผู้บำรุงรักษาสคริปต์เอง ซึ่งก็คือทีมพัฒนาของบริการที่คุณรวมไว้ ทั้งหมดนี้ได้ผลเพราะความสามารถในการประสานรวมของเว็บ คือสามารถรวมส่วนต่างๆ เข้าด้วยกันเป็นองค์ประกอบโดยรวมที่มากกว่าผลรวมของส่วนเหล่านั้น
Web Almanac ของที่เก็บถาวรของ HTTP ให้คำอธิบายที่ชัดเจน ดังนี้
บุคคลที่สามจะเป็นแหล่งรวมรูปภาพ วิดีโอ แบบอักษร เครื่องมือ ไลบรารี วิดเจ็ต เครื่องมือติดตาม โฆษณา และสิ่งอื่นๆ ที่คุณจินตนาการได้ว่าจะฝังไว้ในหน้าเว็บของเรา วิธีนี้จะช่วยให้สามารถสร้างและเผยแพร่เนื้อหาบนเว็บได้แม้จะไม่ใช่ความรู้ด้านเทคนิคก็ตาม หากไม่มีบุคคลที่สาม เว็บก็คงจะเป็นสื่อทางวิชาการที่น่าเบื่อ เน้นข้อความเป็นหลัก แทนที่จะเป็นแพลตฟอร์มที่สมบูรณ์ สมจริง ซับซ้อน และเป็นส่วนสำคัญในชีวิตของพวกเราหลายๆ คนในปัจจุบัน
ทรัพยากรของบุคคลที่สามทำอะไรได้บ้าง
การเข้าถึงข้อมูลบางอย่าง
เมื่อคุณใช้ทรัพยากรของบุคคลที่สามในเว็บไซต์ โดยไม่คํานึงถึงทรัพยากรดังกล่าว ระบบจะส่งข้อมูลบางอย่างไปให้บุคคลที่สามนั้น เช่น หากคุณรวมรูปภาพจากเว็บไซต์อื่น คำขอ HTTP ที่เบราว์เซอร์ของผู้ใช้สร้างจะส่งต่อส่วนหัวผู้อ้างอิงพร้อมด้วย URL ของหน้าเว็บและที่อยู่ IP ของผู้ใช้
การติดตามข้ามเว็บไซต์
จากตัวอย่างเดียวกันนั้น เมื่อรูปภาพโหลดจากเว็บไซต์ของบุคคลที่สาม รูปภาพอาจใส่คุกกี้ได้ และจะส่งคุกกี้นั้นกลับไปยังบุคคลที่สามเมื่อผู้ใช้ขอรูปภาพนั้นในครั้งถัดไป ซึ่งหมายความว่าบุคคลที่สามสามารถทราบว่ากำลังใช้บริการของตนในเว็บไซต์ของคุณ และสามารถส่งคุกกี้กลับมาได้ ซึ่งอาจจะมีรหัสที่ไม่ซ้ำกันสำหรับผู้ใช้รายนั้น ซึ่งหมายความว่าในครั้งถัดไปที่ผู้ใช้เข้าชมเว็บไซต์หรือเว็บไซต์อื่นๆ ที่มีทรัพยากรจากบุคคลที่สาม ระบบจะส่งคุกกี้รหัสที่ไม่ซ้ำกันดังกล่าวอีกครั้ง วิธีนี้จะช่วยให้บุคคลที่สามสร้างบันทึกตำแหน่งที่ผู้ใช้ดังกล่าวเข้าชมได้ ซึ่งได้แก่ เว็บไซต์ของคุณ เว็บไซต์อื่นๆ ที่ใช้ทรัพยากรของบุคคลที่สามรายเดียวกันทั่วทั้งอินเทอร์เน็ต
นี่คือการติดตามข้ามเว็บไซต์ คือช่วยให้บุคคลที่สามรวบรวมบันทึกกิจกรรมของผู้ใช้ในหลายเว็บไซต์ได้ ตราบใดที่เว็บไซต์เหล่านั้นทั้งหมดใช้ทรัพยากรที่มาจากบุคคลที่สามรายเดียวกัน ซึ่งอาจเป็นแบบอักษร รูปภาพ หรือสไตล์ชีต หรืออาจเป็นทรัพยากรแบบคงที่ทั้งหมด นอกจากนี้ยังอาจเป็นแหล่งข้อมูลที่มีการเปลี่ยนแปลงตลอดเวลา เช่น สคริปต์ ปุ่มโซเชียลมีเดีย และโฆษณา สคริปต์ที่รวมไว้สามารถรวบรวมข้อมูลได้มากกว่านี้ เนื่องจากเป็นแบบไดนามิก โดยสามารถตรวจสอบเบราว์เซอร์และสภาพแวดล้อมของผู้ใช้ และส่งต่อข้อมูลดังกล่าวกลับไปยังผู้เริ่มต้น สคริปต์ต่างๆ สามารถดำเนินการนี้ได้ในระดับหนึ่ง เช่นเดียวกับทรัพยากรแบบไดนามิกที่ไม่ได้นําเสนอเป็นสคริปต์ เช่น การฝังโซเชียลมีเดีย โฆษณาหรือปุ่มแชร์ หากคุณดูรายละเอียดของแบนเนอร์คุกกี้ในเว็บไซต์ยอดนิยม คุณจะเห็นรายชื่อองค์กร ที่อาจเพิ่มคุกกี้การติดตามให้กับผู้ใช้ของคุณเพื่อสร้างรูปภาพกิจกรรมสำหรับสร้างโปรไฟล์ของผู้ใช้รายนั้น อาจมีได้หลายร้อยรายการ หากบุคคลที่สามให้บริการโดยไม่เสียค่าใช้จ่าย วิธีหนึ่งที่สามารถสร้างผลลัพธ์ทางเศรษฐกิจให้กับบุคคลที่สามได้ก็คือ พวกเขารวบรวมและสร้างรายได้จากข้อมูลนี้
โมเดลภัยคุกคามความเป็นส่วนตัวเป้าหมายมีคำแนะนำที่เป็นประโยชน์สำหรับประเภทของปัญหาด้านความเป็นส่วนตัวที่เบราว์เซอร์ควรปกป้องผู้ใช้ เอกสารฉบับนี้ยังอยู่ระหว่างการอภิปรายในขณะที่เขียนขึ้น แต่ก็ช่วยให้มีการแยกประเภทระดับสูงของภัยคุกคามความเป็นส่วนตัวที่มีอยู่ ความเสี่ยงจากแหล่งข้อมูลของบุคคลที่สามหลักๆ คือ "การรู้จำข้ามเว็บไซต์ที่ไม่พึงประสงค์" ซึ่งเว็บไซต์จะระบุผู้ใช้คนเดียวกันในหลายๆ เว็บไซต์ และ "การเปิดเผยข้อมูลที่ละเอียดอ่อน" ซึ่งเป็นที่ที่เว็บไซต์อาจรวบรวมข้อมูลที่ผู้ใช้พิจารณาว่ามีความละเอียดอ่อน
นี่คือความแตกต่างที่สำคัญ: การจดจำข้ามเว็บไซต์ที่ไม่พึงประสงค์เป็นผลไม่ดี แม้ว่าบุคคลที่สามจะไม่ได้รวบรวมข้อมูลที่ละเอียดอ่อนเพิ่มเติมก็ตาม เพราะทำให้ผู้ใช้ไม่สามารถควบคุมตัวตนของตนเองได้ การเข้าถึง URL ที่มาและที่อยู่ 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 ของหน้าปัจจุบันเป็นผู้อ้างอิง ที่ผ่านมา คำขอของบุคคลที่สามทั้งหมดจะรวมข้อมูลนี้โดยค่าเริ่มต้น แม้ว่าจะมีความพยายามลดหรือแยกข้อมูลที่ส่งไปยังบุคคลที่สามโดยเบราว์เซอร์ต่างๆ ตามที่อธิบายไว้ใน "การทำความเข้าใจเกี่ยวกับการปกป้องเบราว์เซอร์ของบุคคลที่สาม" เพิ่มเติม
การฝัง iframe แบบข้ามเว็บไซต์
เอกสารที่สมบูรณ์ซึ่งฝังไว้ในหน้าเว็บผ่านทาง <iframe> จะขอสิทธิ์เข้าถึง API ของเบราว์เซอร์ได้เพิ่มเติม นอกเหนือจากคุกกี้ 3 ประเภท ที่อยู่ IP และผู้อ้างอิง API ที่พร้อมใช้งานสำหรับหน้าเว็บ <iframe>d และวิธีขอสิทธิ์เข้าถึงนั้นมีไว้สำหรับเบราว์เซอร์เท่านั้น
และขณะนี้กำลังมีการเปลี่ยนแปลง: โปรดดู "นโยบายสิทธิ์" ด้านล่างเพื่อดูความพยายามในการลดหรือตรวจสอบการเข้าถึง 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 เพื่อทำการตรวจสอบอย่างต่อเนื่องอาจเป็นประโยชน์สำหรับข้อมูลเพิ่มเติม)
เครื่องมือ "Request Map Generator" ของ Simon Hearne อาจเป็นภาพรวมที่มีประโยชน์ของคําขอย่อยทั้งหมดที่หน้าเว็บที่เผยแพร่ต่อสาธารณะสร้างขึ้น
นอกจากนี้ คุณยังรวมบุคคลที่สามซึ่งมุ่งเน้นธุรกิจซึ่งเป็นส่วนหนึ่งของการตรวจสอบที่ไม่ใช่ด้านเทคนิคได้ด้วย (กล่าวคือ รายชื่อบริษัทที่คุณมีความสัมพันธ์ทางการเงินด้วยเพื่อใช้ทรัพยากรของบริษัท) เป้าหมายคือเพื่อจับคู่รายการของบุคคลที่สามที่คุณเชื่อว่าคุณใช้อยู่ (จากบันทึกด้านการเงินและกฎหมาย) กับรายการที่คุณใช้อยู่จริง (โดยดูว่าเว็บไซต์ส่งคำขอ HTTP ของบุคคลที่สามรายการใดที่เว็บไซต์ของคุณสร้าง) คุณควรสามารถระบุสำหรับบุคคลที่สามทางธุรกิจแต่ละรายได้ว่ามีการส่งคำขอขาออกทางเทคนิคใดบ้าง หากไม่สามารถระบุคำขอในการตรวจสอบทางเทคนิคสำหรับบุคคลที่สามซึ่งระบุโดยความสัมพันธ์ทางธุรกิจ คุณควรหาสาเหตุและให้คำแนะนำในการทดสอบ บางทีทรัพยากรของบุคคลที่สามจะโหลดเฉพาะในประเทศใดประเทศหนึ่ง ในอุปกรณ์บางประเภท หรือสำหรับผู้ใช้ที่ลงชื่อเข้าสู่ระบบ การดำเนินการนี้จะเพิ่มรายการพื้นที่เว็บไซต์ที่ต้องตรวจสอบและยืนยันว่าคุณเห็นการเข้าถึงขาออกทั้งหมด (หรืออาจระบุทรัพยากรของบุคคลที่สามซึ่งคุณจ่ายเงินและไม่ได้ใช้ ซึ่งจะให้กำลังใจฝ่ายการเงินเสมอ)
เมื่อคุณจำกัดรายการคำขอสำหรับบุคคลที่สามที่คุณต้องการเป็นส่วนหนึ่งของการตรวจสอบให้แคบลงแล้ว การคลิกที่คำขอแต่ละรายการจะแสดงรายละเอียดทั้งหมดของคำขอนั้น โดยเฉพาะข้อมูลที่ส่งไปยังคำขอนั้น นอกจากนี้ ยังเป็นเรื่องปกติที่คำขอของบุคคลที่สามซึ่งโค้ดของคุณเริ่มขึ้น แล้วเริ่มต้นคำขอของบุคคลที่สามอื่นๆ จำนวนมากไปด้วย บุคคลที่สามเพิ่มเติมเหล่านี้ยังได้รับการ "นำเข้า" มายังนโยบายความเป็นส่วนตัวของคุณเองด้วย งานนี้ต้องใช้ความพยายามแต่มีคุณค่า และมักจะแทรกลงในการวิเคราะห์ที่มีอยู่ได้ ทีมพัฒนาฟรอนท์เอนด์ของคุณควรตรวจสอบคำขอเพื่อเหตุผลด้านประสิทธิภาพอยู่แล้ว (โดยอาจมีความช่วยเหลือจากเครื่องมือที่มีอยู่ เช่น WebPageTest หรือ Lighthouse) และการรวมการตรวจสอบข้อมูลและความเป็นส่วนตัวลงในกระบวนการดังกล่าวจะช่วยให้ทำได้ง่ายขึ้น
ควรทำ
เปิดเบราว์เซอร์ที่มีโปรไฟล์ผู้ใช้ใหม่ที่เรียบง่ายเพื่อไม่ต้องลงชื่อเข้าใช้และไม่มีข้อตกลงที่บันทึกไว้ จากนั้นเปิดแผงเครื่องมือการพัฒนาเบราว์เซอร์ แผงเครือข่ายเพื่อดูคำขอขาออกทั้งหมด เพิ่มคอลัมน์ใหม่เพื่อแสดงโดเมนของคำขอแต่ละรายการ และเลือกช่องทำเครื่องหมาย "คำขอของบุคคลที่สาม" เพื่อแสดงเฉพาะบุคคลที่สาม หากมี จากนั้นให้ทำดังนี้
- เข้าชมเว็บไซต์ของคุณ
- ลงชื่อสมัครใช้บัญชีใหม่หากคุณระบุบัญชีผู้ใช้
- ลองลบบัญชีที่คุณสร้าง
- ดำเนินการตามปกติบนเว็บไซต์ (ขึ้นอยู่กับสิ่งที่เว็บไซต์ของคุณทำ แต่ให้เลือกการทำงานทั่วไปที่ผู้ใช้ส่วนใหญ่ทำ)
- ดำเนินการ 1 หรือ 2 อย่างที่คุณทราบว่าเกี่ยวข้องกับทรัพยากร Dependency ของบุคคลที่สามโดยเฉพาะ ซึ่งอาจรวมถึงการแชร์เนื้อหาไปยังโซเชียลมีเดีย การเริ่มขั้นตอนการชำระเงิน หรือการฝังเนื้อหาจากเว็บไซต์อื่น
เมื่อทำงานเหล่านี้แต่ละอย่าง ให้บันทึกทรัพยากรที่ขอจากโดเมนที่ไม่ใช่ของคุณ โดยดูที่แผงเครือข่ายตามที่อธิบาย นี่คือบุคคลที่สามบางส่วนของคุณ วิธีที่ดีคือการใช้เครื่องมือเครือข่ายของเบราว์เซอร์เพื่อเก็บบันทึกคำขอเครือข่ายในไฟล์ HAR
ไฟล์ HAR และการบันทึก
ไฟล์ HAR คือรูปแบบ JSON ที่เป็นมาตรฐานของคำขอเครือข่ายทั้งหมดที่สร้างจากหน้าเว็บ ในการรับไฟล์ HAR ของหน้าเว็บหนึ่ง ให้ทำดังนี้
Chrome
เปิดเบราว์เซอร์สำหรับนักพัฒนาเว็บ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ แล้วเลือกสัญลักษณ์บันทึกลูกศรลงที่ด้านขวาบนใกล้กับเมนูแบบเลื่อนลง "ไม่มีการควบคุม"
Firefox
เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > เครื่องมือเพิ่มเติม > เครื่องมือนักพัฒนาเว็บ) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ แล้วเลือกสัญลักษณ์ฟันเฟืองที่ด้านบนขวาข้างเมนูแบบเลื่อนลงการควบคุม เลือกบันทึกทั้งหมดเป็น HAR** จากเมนู
Safari
เปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ (เมนู > พัฒนา > แสดงตัวตรวจสอบเว็บ ถ้าคุณไม่มีเมนู "พัฒนา" ให้เปิดใช้งานจาก เมนู > Safari > ค่ากำหนด > ขั้นสูง > แสดงเมนูพัฒนา ในแถบเมนู) ไปที่แผงเครือข่าย โหลด (หรือรีเฟรช) หน้าเว็บ และเลือกส่งออกที่ด้านขวาบน (ทางด้านขวาของหน้าต่าง "เก็บบันทึก") คุณอาจต้องขยายหน้าต่าง
สำหรับรายละเอียดเพิ่มเติม คุณยังบันทึกสิ่งที่ส่งต่อไปยังบุคคลที่สาม (ในส่วนคำขอ) ได้ด้วย แม้ว่าข้อมูลนี้มักมีการสร้างความสับสนและไม่สามารถตีความได้อย่างเป็นประโยชน์
แนวทางปฏิบัติแนะนำเมื่อผสานรวมบริษัทอื่น
คุณสามารถตั้งค่านโยบายของคุณเองเกี่ยวกับบุคคลที่สามที่เว็บไซต์ของคุณใช้ เช่น เปลี่ยนผู้ให้บริการโฆษณาที่ใช้ตามแนวทางปฏิบัติของผู้ให้บริการ ป๊อปอัปความยินยอมในการใช้คุกกี้ของผู้ใช้นั้นน่ารำคาญหรือรบกวนเพียงใด หรือต้องการใช้ปุ่มโซเชียลมีเดียในเว็บไซต์หรือลิงก์ติดตามในอีเมลหรือลิงก์ 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 ไม่มีวิธีฝังวิดีโอโดยไม่ต้องติดตามขณะที่เขียนข้อความนี้ คุณสามารถโฮสต์วิดีโอด้วยตนเองได้ (วิธีนี้เป็นทางเลือก) แต่อาจทำงานมากขึ้น โดยเฉพาะอย่างยิ่งการรองรับอุปกรณ์จำนวนมาก
เช่นเดียวกับวิดเจ็ตแบบอินเทอร์แอกทีฟที่พูดถึงก่อนหน้านี้ เป็นไปได้ที่จะแทนที่วิดีโอที่ฝังอยู่ด้วยลิงก์ไปยังเว็บไซต์ที่ให้บริการ
โฆษณาแบบนี้จะมีการโต้ตอบน้อยลงเนื่องจากวิดีโอจะไม่เล่นในบรรทัด แต่จะปล่อยให้ผู้ใช้เลือกได้ว่าจะดูร่วมกับผู้ใช้หรือไม่ ตัวอย่างนี้สามารถใช้เป็นตัวอย่างของ "รูปแบบส่วนหน้า" ซึ่งเป็นชื่อสำหรับแทนที่เนื้อหาแบบโต้ตอบแบบไดนามิกด้วยสิ่งที่ผู้ใช้ต้องดำเนินการเพื่อทริกเกอร์เนื้อหา คุณสามารถใช้ลิงก์ธรรมดาไปยังหน้าวิดีโอ 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" สำหรับเนื้อหาที่ฝัง คุณสามารถใช้การเขียนโปรแกรมเพื่อแสดง "ส่วนหน้า" แบบอินเทอร์แอกทีฟและสลับไปฝังหรือลิงก์ไปยังวิดีโออินเทอร์แอกทีฟเมื่อผู้ใช้เลือกที่จะคลิก
เมื่อฝังสคริปต์ Analytics
Analytics ได้รับการออกแบบมาเพื่อรวบรวมข้อมูลเกี่ยวกับผู้ใช้เพื่อใช้ในการวิเคราะห์ ด้วยเหตุผลนี้ โดยพื้นฐานแล้ว ระบบ Analytics เป็นบริการสำหรับรวบรวมและแสดงข้อมูลเกี่ยวกับการเข้าถึงและผู้ใช้ โดยทำในเซิร์ฟเวอร์ของบุคคลที่สาม เช่น Google Analytics เพื่อการติดตั้งใช้งานที่ง่ายดาย นอกจากนี้ยังมีระบบการวิเคราะห์แบบโฮสต์เองด้วย เช่น https://matomo.org/ แม้ว่าวิธีนี้จะได้ผลมากกว่าการใช้โซลูชันของบุคคลที่สาม อย่างไรก็ตาม การใช้งานระบบเช่นนี้บนโครงสร้างพื้นฐานของคุณเองจะช่วยลดการเก็บรวบรวมข้อมูลได้เพราะระบบไม่ได้ออกจากระบบนิเวศของคุณเอง ในทางกลับกัน การจัดการ การนำข้อมูลออก และการกำหนดนโยบายสำหรับข้อมูลจะกลายเป็นความรับผิดชอบของคุณ ข้อกังวลส่วนใหญ่เกี่ยวกับการติดตามข้ามเว็บไซต์คือการดำเนินการด้วยวิธีเก็บซ่อนเป็นความลับ หรือเป็นผลข้างเคียงของการใช้บริการที่ไม่จำเป็นต้องมีการรวบรวมข้อมูลเลย ซอฟต์แวร์ Analytics ได้รับการออกแบบมาอย่างตั้งใจให้รวบรวมข้อมูลเพื่อแจ้งให้เจ้าของเว็บไซต์ทราบเกี่ยวกับผู้ใช้ของตน
ที่ผ่านมาเราใช้วิธีการรวบรวมข้อมูลทั้งหมดที่ทำได้เกี่ยวกับทุกสิ่ง เช่น ตาข่ายจับปลาขนาดใหญ่ แล้วนำไปวิเคราะห์เพื่อหารูปแบบที่น่าสนใจในภายหลัง หลักความคิดลักษณะนี้ทำให้รู้สึกไม่สบายใจและไม่กังวลเรื่องการรวบรวมข้อมูลที่กล่าวถึงในส่วนที่ 1 ของหลักสูตรนี้ ในตอนนี้ เว็บไซต์จำนวนมากคิดก่อนว่าจะถามอะไร จากนั้นจึงรวบรวมข้อมูลที่เฉพาะเจาะจงและจำกัดเพื่อตอบคำถามเหล่านั้น
หากบริการของบุคคลที่สามบางรายการถูกใช้งานโดยเว็บไซต์ของคุณและเว็บไซต์อื่นๆ และคุณใส่ JavaScript ของบริการนั้นลงในเว็บไซต์และตั้งค่าคุกกี้ให้ผู้ใช้แต่ละราย คุณก็ควรพิจารณาว่าบริการดังกล่าวอาจทำการรู้จำข้ามเว็บไซต์ที่ไม่พึงประสงค์ ซึ่งก็คือการติดตามผู้ใช้ทั่วเว็บไซต์ บางส่วนอาจไม่เป็นเช่นนั้น แต่จุดยืนในการปกป้องความเป็นส่วนตัวในที่นี้คือการสันนิษฐานว่า ที่จริงแล้ว บริการของบุคคลที่สามนั้นเป็นการติดตามข้ามเว็บไซต์ เว้นแต่คุณจะมีเหตุผลอันดีที่ควรคิดหรือไม่ทราบ ซึ่งไม่ใช่เหตุผลที่ควรหลีกเลี่ยงบริการดังกล่าว แต่เป็นสิ่งที่ต้องพิจารณาในการประเมินข้อดีของการใช้บริการ
ข้อดีและข้อเสียของข้อมูลวิเคราะห์คือการเลือกว่าจะใช้หรือไม่ใช้ Analytics เพียงอย่างเดียว นั่นคือรวบรวมข้อมูลทั้งหมดและละเมิดความเป็นส่วนตัวเพื่อแลกเปลี่ยนกับข้อมูลเชิงลึกและการวางแผน หรือบอกข้อมูลเหล่านี้ไปเลย แต่เหตุการณ์กลับไม่เป็นเช่นนี้อีกต่อไป และตอนนี้มักจะมีจุดเริ่มต้นที่อยู่ตรงกลางระหว่างปลายสุดทั้งสองด้านนี้ ตรวจสอบตัวเลือกการกำหนดค่าจากผู้ให้บริการวิเคราะห์เพื่อจำกัดข้อมูลที่รวบรวม รวมถึงลดปริมาณและระยะเวลาของพื้นที่เก็บข้อมูล เนื่องจากคุณมีระเบียนจากการตรวจสอบทางเทคนิคที่อธิบายไว้ก่อนหน้านี้แล้ว คุณจึงเรียกใช้ส่วนที่เกี่ยวข้องของการตรวจสอบนั้นอีกครั้งได้ เพื่อยืนยันว่าการเปลี่ยนแปลงการกำหนดค่าเหล่านี้ลดปริมาณข้อมูลที่รวบรวมได้จริง หากกำลังทำการเปลี่ยนแปลงนี้ในเว็บไซต์ที่มีอยู่ วิธีนี้ก็จะช่วยชี้วัดเชิงปริมาณสำหรับนำไปให้ผู้ใช้เขียนได้ ตัวอย่างเช่น 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 เพื่อหลีกเลี่ยงการส่งต่อให้บุคคลอื่น รวมถึงต้นทางของคุณเอง)
(นี่คือตัวอย่างที่ดีของสมดุลระหว่างความเป็นส่วนตัวกับประโยชน์ใช้สอย ค่าเริ่มต้นใหม่มีการรักษาความเป็นส่วนตัวมากกว่าที่ผ่านมามาก แต่ยังคงให้ข้อมูลระดับสูงแก่บุคคลที่สามที่คุณเลือก เช่น ผู้ให้บริการวิเคราะห์)
นอกจากนี้ยังควรระบุส่วนหัวนี้ให้ชัดเจนด้วยเนื่องจากคุณจะทราบแน่ชัดว่านโยบายคืออะไร แทนที่จะอาศัยค่าเริ่มต้นของเบราว์เซอร์
หากตั้งส่วนหัวไม่ได้ คุณอาจตั้งค่านโยบาย URL ที่มาสําหรับหน้า 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 ที่มักเรียกกันว่า "CSP" จะเป็นตัวกำหนดว่าสามารถโหลดทรัพยากรภายนอกได้จากที่ใด
โดยจะใช้เพื่อวัตถุประสงค์ด้านความปลอดภัยเป็นหลักโดยการป้องกันการโจมตีด้วย Cross-site Scripting และการแทรกสคริปต์ แต่เมื่อใช้ควบคู่กับการตรวจสอบตามปกติ ก็อาจทำให้บุคคลที่สามที่คุณเลือกส่งข้อมูลไปได้
วิธีนี้อาจทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ไม่ดี หากสคริปต์ของบุคคลที่สามรายการใดรายการหนึ่งเริ่มโหลดทรัพยากร Dependency จากต้นทางที่ไม่ได้อยู่ในรายการ คำขอดังกล่าวจะถูกบล็อก สคริปต์จะดำเนินการไม่สำเร็จ และแอปพลิเคชันดังกล่าวอาจล้มเหลวได้ (หรืออย่างน้อยก็ถูกลดทรัพยากรให้เป็นเวอร์ชันสำรองที่ล้มเหลวด้วย JavaScript) วิธีนี้มีประโยชน์เมื่อมีการนำ CSP ไปใช้เพื่อความปลอดภัยซึ่งเป็นวัตถุประสงค์ปกติของ CSP ซึ่งก็คือการป้องกันปัญหาการเขียนสคริปต์ข้ามเว็บไซต์ (และในการดำเนินการนี้ ให้ใช้ CSP ที่เข้มงวด) เมื่อคุณทราบสคริปต์ในหน้าทั้งหมดที่หน้าเว็บใช้แล้ว คุณสามารถสร้างรายการสคริปต์ คำนวณค่าแฮช หรือเพิ่มค่าสุ่ม (ซึ่งเรียกว่า "ค่าพิเศษ") สำหรับสคริปต์แต่ละรายการ จากนั้นเพิ่มรายการแฮชลงในนโยบายรักษาความปลอดภัยเนื้อหา วิธีนี้จะช่วยป้องกันไม่ให้ มีการโหลดสคริปต์ที่ไม่ได้อยู่ในรายการ ซึ่งจะต้องมีส่วนต่อท้ายกระบวนการผลิตของเว็บไซต์ โดยสคริปต์ในหน้าจะต้องมีค่า 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 ไม่ได้แจ้งว่ามีการส่งข้อมูลใดบ้าง เพียงแต่มีการส่งคำขอเท่านั้น)
โปรดทราบว่าไม่จำเป็นต้องเพิ่มขนาดนี้ลงในหน้าที่แสดงทุกครั้งหรือทุกๆ หน้า ปรับจำนวนการตอบกลับในหน้าที่ได้รับส่วนหัวเพื่อให้คุณเห็นตัวอย่างซึ่งเป็นตัวแทนของรายงานซึ่งมีปริมาณไม่มากเกินไป
นโยบายสิทธิ์
ส่วนหัว Permissions-Policy (เปิดตัวภายใต้ชื่อ Feature-Policy) นั้นคล้ายคลึงกันกับ Content-Security-Policy แต่จะจำกัดการเข้าถึงฟีเจอร์ที่มีประสิทธิภาพของเบราว์เซอร์ เช่น คุณสามารถจำกัดการใช้ฮาร์ดแวร์ของอุปกรณ์อย่างตัวตรวจวัดความเร่ง กล้อง หรืออุปกรณ์ USB หรือจำกัดฟีเจอร์ที่ไม่ใช่ฮาร์ดแวร์ได้ เช่น สิทธิ์ในการแสดงแบบเต็มหน้าจอหรือใช้ XMLHTTPRequest แบบซิงโครนัส
ข้อจำกัดเหล่านี้สามารถใช้ได้กับหน้าระดับบนสุด (เพื่อหลีกเลี่ยงการโหลดสคริปต์จากการพยายามใช้ฟีเจอร์เหล่านี้) หรือหน้าที่มีเฟรมย่อยซึ่งโหลดผ่าน iframe ข้อจำกัดในการใช้งาน API นี้ไม่ได้เกี่ยวข้องกับการเก็บลายนิ้วมือของเบราว์เซอร์ แต่เป็นการไม่อนุญาตให้บุคคลที่สามทำอะไรที่รบกวน (เช่น การใช้ API ที่มีประสิทธิภาพ การแสดงหน้าต่างสิทธิ์ให้เปิดขึ้นมา ฯลฯ) ซึ่งจะกำหนดโดย Target Privacy Threat Model ว่า "intrusion"
ส่วนหัว Permissions-Policy ถูกระบุเป็นรายการคู่ (ฟีเจอร์ ต้นทางที่อนุญาต) ดังนั้น
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
ตัวอย่างนี้อนุญาตให้หน้านี้ ("ตัวเอง") และ <iframe> จากต้นทาง example.com ใช้ API ของ navigator.geolocation จาก JavaScript ได้ หน้านี้และเฟรมย่อยทั้งหมดสามารถใช้ API เต็มหน้าจอได้ และห้ามไม่ให้มีหน้าเว็บใดๆ ซึ่งรวมถึงหน้านี้ไม่ให้ใช้กล้องเพื่ออ่านข้อมูลวิดีโอ มีรายละเอียดเพิ่มเติมและรายการตัวอย่างที่เป็นไปได้ที่นี่
รายการฟีเจอร์ที่ส่วนหัว Permissions-Policy จัดการจะมีเป็นจำนวนมากและอาจซ้ำกันได้ ขณะนี้ระบบเก็บรักษารายการนี้ไว้ที่ 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 ที่เกี่ยวข้อง) และ Enhanced Tracking Protection ใน 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
- ส่วนคุกกี้ของบุคคลที่สามจะถูกบล็อกโดยค่าเริ่มต้น
- ในฐานะที่เป็นส่วนหนึ่งของฟีเจอร์ Intelligent Tracking Prevention ที่ทำให้ Safari ช่วยลด URL ที่มาซึ่งถูกส่งต่อไปยังหน้าอื่นๆ ให้เป็นเว็บไซต์ระดับบนสุดแทนที่จะเป็นหน้าเฉพาะ (
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 ใหม่
แม้ว่าฟีเจอร์และนโยบายการรักษาความเป็นส่วนตัวใหม่ๆ ในผลิตภัณฑ์เบราว์เซอร์จะช่วยรักษาความเป็นส่วนตัวของผู้ใช้ แต่ก็ยังมีอุปสรรคด้วยเช่นกัน เทคโนโลยีเว็บจำนวนมากสามารถนำมาใช้สำหรับการติดตามข้ามเว็บไซต์ได้ แม้ว่าจะได้รับการออกแบบและใช้เพื่อวัตถุประสงค์อื่นๆ ก็ตาม ตัวอย่างเช่น ระบบการรวมศูนย์ข้อมูลประจำตัวจำนวนมากที่เราใช้ทุกวันจะใช้คุกกี้ของบุคคลที่สาม โซลูชันการโฆษณามากมายที่ผู้เผยแพร่โฆษณาใช้สร้างรายได้ในปัจจุบันนั้นสร้างขึ้นจากคุกกี้ของบุคคลที่สาม โซลูชันการตรวจจับการฉ้อโกงจำนวนมากอาศัยการเก็บลายนิ้วมือ เกิดอะไรขึ้นกับกรณีการใช้งานเหล่านี้เมื่อไม่มีคุกกี้ของบุคคลที่สามและการเก็บลายนิ้วมือ
อาจทำให้เบราว์เซอร์แยกความแตกต่างของ Use Case ต่างๆ ได้ยากและมีโอกาสผิดพลาดได้ง่าย และแยกการใช้งานที่ละเมิดความเป็นส่วนตัวออกจากการใช้งานของผู้อื่นได้อย่างน่าเชื่อถือ นี่จึงเป็นเหตุผลที่เบราว์เซอร์หลักส่วนใหญ่บล็อกคุกกี้ของบุคคลที่สามและการเก็บลายนิ้วมือ หรือตั้งใจที่จะดำเนินการดังกล่าวเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
จำเป็นต้องมีแนวทางใหม่ นั่นคือเมื่อคุกกี้ของบุคคลที่สามเลิกใช้แล้วและลดการเก็บลายนิ้วมือ นักพัฒนาแอปจึงต้องการ API ที่สร้างขึ้นเพื่อวัตถุประสงค์ซึ่งตรงตามกรณีการใช้งาน (ซึ่งยังไม่หมดไป) แต่ออกแบบในลักษณะที่รักษาความเป็นส่วนตัว เป้าหมายคือการออกแบบและสร้าง API ที่ใช้กับการติดตามข้ามเว็บไซต์ไม่ได้ เทคโนโลยีเหล่านี้ต้องการที่จะเป็น API แบบหลายเบราว์เซอร์ ซึ่งต่างจากฟีเจอร์ของเบราว์เซอร์ที่อธิบายในส่วนก่อนหน้านี้
ตัวอย่างข้อเสนอ API
รายการต่อไปนี้เป็นเพียงตัวอย่างบางส่วนของสิ่งที่กำลังพูดคุยกันอยู่เท่านั้น
ตัวอย่างข้อเสนอ API เพื่อแทนที่เทคโนโลยีที่สร้างจากคุกกี้ของบุคคลที่สาม
- กรณีการใช้งานข้อมูลประจำตัว: FedCM
- กรณีการใช้งานโฆษณา: การวัดคลิกส่วนตัว, การระบุแหล่งที่มาส่วนตัวที่ทำงานร่วมกันได้, การรายงานการระบุแหล่งที่มา, หัวข้อ, FLEDGE และ PARAKEET
ตัวอย่างข้อเสนอ API เพื่อแทนที่เทคโนโลยีที่สร้างบนการติดตามแบบแพสซีฟมีดังนี้
- กรณีการใช้งานการตรวจจับการประพฤติมิชอบ: โทเค็นความน่าเชื่อถือ
ตัวอย่างข้อเสนออื่นๆ ที่ API อื่นๆ จะสร้างในอนาคตได้โดยไม่ต้องมีคุกกี้ของบุคคลที่สาม
นอกจากนี้ยังมีข้อเสนอ API อีกประเภทหนึ่งให้ลองใช้ และมีการลดความเสี่ยงเกี่ยวกับการติดตามโดยไม่เปิดเผยความลับเฉพาะเบราว์เซอร์ ตัวอย่างหนึ่งคืองบประมาณความเป็นส่วนตัว ใน Use Case ต่างๆ เหล่านี้ API ที่ Chrome เสนอในตอนแรกจะนำไปใช้จริงภายใต้เงื่อนไขที่ครอบคลุมของ Privacy Sandbox
Global-Privacy-Control คือส่วนหัวที่มีจุดประสงค์เพื่อสื่อสารกับเว็บไซต์ที่ผู้ใช้ไม่ต้องการให้แชร์ข้อมูลส่วนตัวที่รวบรวมไว้กับเว็บไซต์อื่นๆ เจตนาของวิดีโอนี้คล้ายกับ "ไม่ติดตาม" ซึ่งได้ปิดให้บริการแล้ว
สถานะข้อเสนอ API
ข้อเสนอ API เหล่านี้ส่วนใหญ่ยังไม่ได้นำไปใช้งาน หรือนำไปใช้หลัง Flag เท่านั้น หรือในสภาพแวดล้อมที่จำกัดเพื่อการทดสอบ
ระยะการบ่มเพาะสาธารณะนี้มีความสำคัญ ผู้ให้บริการเบราว์เซอร์และนักพัฒนาซอฟต์แวร์จะรวบรวมการอภิปรายและประสบการณ์เพื่อดูว่า API เหล่านี้มีประโยชน์หรือไม่และทำในสิ่งที่ได้รับการออกแบบมาจริงๆ หรือไม่ นักพัฒนาซอฟต์แวร์ ผู้ให้บริการเบราว์เซอร์ และผู้ดำเนินการในระบบนิเวศอื่นๆ ใช้ระยะนี้ เพื่อปรับปรุงการออกแบบของ API
ที่ที่ดีที่สุดในการติดตาม API ใหม่ๆ ที่เราจะเสนอคือรายการข้อเสนอของกลุ่มความเป็นส่วนตัวใน GitHub
คุณจำเป็นต้องใช้ API เหล่านี้หรือไม่
หากคุณสร้างผลิตภัณฑ์จากคุกกี้ของบุคคลที่สามโดยตรงหรือใช้เทคนิคอย่างเช่น การเก็บลายนิ้วมือ คุณควรมีส่วนร่วมกับ API ใหม่เหล่านี้ ทดลองใช้ API เหล่านั้น และร่วมส่งประสบการณ์ของคุณเองลงในการสนทนาและการออกแบบ API ในกรณีอื่นๆ ทั้งหมด คุณไม่จำเป็นต้องทราบรายละเอียดทั้งหมดเกี่ยวกับ API ใหม่เหล่านี้ในขณะที่เขียน แต่เป็นการทราบถึงสิ่งที่กำลังจะมา