เพื่อป้องกันการเข้าถึงหรือแชร์ลิงก์วิดีโอโดยตรง (direct video links) หนึ่งในเทคนิคเหล่านี้คือการใช้ "Blob URLs" หรือ Binary Large Objects
นี่คือวิธีที่เว็บไซต์ป้องกันลิงก์วิดีโอ
เทคนิคเหล่านี้ช่วยให้เว็บไซต์สามารถควบคุมการเข้าถึงและการกระจายเนื้อหาของพวกเขาได้ดียิ่งขึ้น, และยังช่วยป้องกันการละเมิดลิขสิทธิ์
การใช้ Blob URLs ในร่วมกับ Amazon S3 สำหรับการสตรีมวิดีโอสามารถช่วยเพิ่มการควบคุมและความปลอดภัยสำหรับเนื้อหาของคุณได้
นี่คือขั้นตอนพื้นฐานและเครื่องมือที่อาจจำเป็น
ตัวอย่างของเครื่องมือที่คุณอาจใช้ได้แก่ AWS SDK สำหรับการสื่อสารกับ S3, AWS Lambda หรือ AWS API Gateway สำหรับการสร้าง API, และ JavaScript หรือเฟรมเวิร์กฝั่งไคลเอนต์อื่นๆ สำหรับการจัดการ Blob URLs บนเว็บแอปของคุณ
Amazon S3 มีความสามารถในการป้องกันลิงก์และควบคุมการเข้าถึงไฟล์อย่างหลากหลาย, ซึ่งช่วยให้คุณสามารถป้องกันการเข้าถึงลิงก์ไฟล์โดยตรงจากผู้ที่ไม่ได้รับอนุญาต.
นี่คือหลักการพื้นฐานของการป้องกันลิงก์ใน Amazon S3
เริ่มตั้งแต่ที่มาของ standard นี้ก่อนกันดีกว่า ที่มาของ data tag Base64 เกิดจาก L. Masinter ซึ่งได้ เปิด RFC 2397 (Request for Comments (RFC) คือเอกสารที่เป็นข้อมูลของมาตรฐานต่างๆในอินเตอร์เน็ต ผลิตภัณฑ์ต่างๆ ไม่ว่าจะเป็นเชิงพาณิชย์หรือฟรีแวร์ใดๆก็ตาม ที่ต้องการสื่อสารกับชาวโลกก็จะต้องปฏิบัติตามมาตรฐานนี้) เมื่อเดือน สิงหาคม 1998 หรือ เมื่อประมาณ 20 ปีที่แล้ว
โดยจุดประสงค์ของ Standard นี้คือ เพื่อให้ Browser สามารถมี embed data ได้โดยไม่จำเป็นต้องโหลด Resource แยกต่างหาก เพื่อให้เกิดความเร็ว ในการใช้งานซึ่งจะมี Format ดังนี้ data:[<mediatype>][;base64],<data>
มาถึงตรงนี้แล้ว ก็เริ่มสงสัยว่า เจ้าแรกๆ ที่ Support Protocol นี้ คือใครกันหนอ ให้ลองเดาเลย จาก 4 ค่ายใหญ่ Internet Explorer, Safari, Chrome และ Firefox
ใครที่เดาว่า IE เป็นเจ้าแรกนั้น อาจจะต้องคิดใหม่ เพราะว่า Browser เจ้าแรกที่ทำให้ Support Standard นี้ คือ Firefox 2 ใน ตุลาคม 2006 ถัดมาปีประมาณ ปีครึ่ง Safari 3.1 ก็เริ่ม Support ใน มีนาคม 2008 ถัดมาอีก 1 ปี IE 8 ใน มีนาคม 2009 แต่มีข้อจำกัดเรื่องความยาวของ data รองรับได้แต่ 32 KB หรือเท่ากับ 32768 Bytes และในปีถัดมา Chrome 4 ก็ support ในเดือน มกราคม 2010 เท่านี้ก็เป็น นิมิตรหมายที่ดีที่ ทุก Web หลังจากนี้ หากจะใช้ Standard นี้ จะมี Browser รองรับไว้ส่วนใหญ่แล้ว วงเล็บ โหใช้เวลา 1 รอบนักษัตร กว่าจะเป็นมาตรฐาน เวลา 12 ปีนั้น ช่างเป็นอะไรที่ค่อนข้างนานเลยทีเดียว แต่ว่าใช้ว่า Browser support แล้ว Developer จะเริ่มทำฟีเจอร์ด้านนี้ทันที ก็ต้องรอ Market Product อีกประมาณนึงจนมาถึง ยุคปัจจุบัน
ปัจจุบัน
มี Browser มากมายที่ Support มาตรฐานตัวนี้ และความนิยมการใช้งานฟีเจอร์นี้บน Browser สามารถระบุออกมาเป็น รูปเบื้องล่าง ซึ่งจะเป็น Stat การใช้งานในปัจจุบัน
โดย browser ที่มีคนใช้งานฟีเจอร์นี้มากที่สุด หากเข้าไปในลิงค์ จะพบว่าแชมป์ของ Catergory นี้เป็น Chrome Browser นะครับ 😁
หลักการทำงาน
ถัดมา หลักการทำงานก็ไม่ได้ยุ่งยาก เพราะทุกๆเบราเซอร์ สามารถใช้งานเหมือนกันหมด หากมองเป็นภาพ Abstract (ภาพหยาบๆ แบบไม่ละเอียด) ละก็
ขอเล่าแบบนี้ คือ มันก็จะคล้ายๆ กับการทำงานของ href แหละ ซึ่งเวลาปกติที่ href ทำงาน browser ก็จะเปิด request connection ไปยัง url ที่ set ไว้ เพื่อไปเอาข้อมูลตาม url นั้นออกมา แล้วก็รอจนกว่า Content ที่ได้มา ได้มาครบแล้วยัง ถ้าได้ครบแล้วก็จะแสดงผล ส่วนการทำงานแบบ Data URI จะต่างตรงที่ ข้อมูลมาพร้อมกับ tag html เลย ซึ่งมี format ของข้อมูลมาด้วย เมื่อเข้าหน้าแล้ว browser ก็จะสามารถนำ data ที่อยู่ใน tag นำมาแสดงผลได้ทันทีไม่ต้องไป reqong request ให้เสียเวลา ซึ่งจะช่วยลด Latency time (เวลาหน่วง) ในการ Get File ได้
โดยส่วนตัวแล้วชอบวิธีการนี้มากๆ เพราะประหยัดพลังงานและประหยัดเวลา แต่ทั้งนี้ ทั้งนั้นด้วยความคิดสร้างสรรค์ของชุมชนนักพัฒนา ก็ทำให้มีอีกอย่างนึงที่ใส่เพิ่มเข้าไป เพื่อเป็น Protocol ไว้บอกว่านี้คือ resource นะ
นั่นคือ Blob Protocol ใครรู้จัก Protocol นี้ โปรด อธิบาย ด้วย คำ 3 คำ ..... ..... .....
สำหรับคนที่ยังงงว่าเจ้า Blob คืออะไร ให้สูดลมหายใจเข้าออกสัก 10 วินาที แล้วมาลุยกันต่อ
Blob Protocol ( Blob URLs )
หลังจากที่ได้เกริ่นๆไปว่า อยากเขียนบล๊อคเกี่ยวกับเรื่องนี้ ซึ่งทำให้ต้องท้าวความเกี่ยวกับความเข้าใจของ Base64 Character ก่อน ทั้ง Encoding Decoding และการใช้งาน ซึ่งสามารถหาอ่านได้ที่ตรงนี้ แตะตรงนี้หรือจิ้มเบาๆ ครับ
Blob Protocol หรือ ชื่อ Official คือ Blob URLs
หากเราเริ่มต้นจาก ความหมายของ Blob นั้นละก็ Blob มันย่อมาจาก Binary Large OBject ซึ่งมันก็คือ การระบุว่าข้อมูลที่อยู่ในนี้มันจะเป็นไฟล์ Binary จ๊ะ จริงๆที่ชื่อก็บอกด้วยตัวมันเองแล้วว่ามันจะต้องมีขนาดใหญ่ แต่ไม่ได้ระบุว่า เป็น data ของอะไร ซึ่งมันสามารถเป็นไฟล์ Type ไหนก็ได้ ขอแค่เป็น Library โดยได้มีการนำไปประยุกต์ ใช้กับอะไรหลายๆอย่าง เช่น Database เราสามารถเก็บข้อมูลเป็น type นี้ได้ จนมีคนเห็นความเชื่องช้าของ browser ในการโหลดข้อมูล รวมถึงเล็งเห็นข้อเสียของ เจ้า Data URI ที่มี overhead บน browser จนเกิด RFC ใหม่ขึ้น นั่นก็คือ Blob URLs โดยมาตรฐานนี้ถูกใช้งานบน Browser มาตั้งแต่ปี ....
??? โน้นครับ นายไปเล่นตรงนู้นเลย เอาเป็นว่าใครอยากรู้ก็ google ดูเองน้า หรือ เปิดดูในเว็บที่แปะอยู่กับรูปเบื้องบนดูนะครับ
ที่นี้มาดูเรื่องการทำงานของเจ้า Blob บนเว็บกันบ้าง เจ้า blob เนี่ยสามารถใส่ได้บน attribute type src ของ tag บน html ได้เท่านั้น เช่น <img src="blob:https://www.blobimage.com/logo.png" /> ซึ่งเวลา browser เอาไปทำงานก็จะ มอง source นี้เป็นเหมือน Byte Stream ซึ่งตอนทำงานก็จะต่อท่อไปยัง source ลด ภาระการ request file แบบ HTTP Protocol คล้ายๆกับต่อ socket คุยกันเอง ปล.เนื้อหาตรงส่วนนี้ผมอธิบายโดยใช้ความเข้าใจของตนเองอธิบาย โปรดอย่าเชื่อ 100% หากจะนำไปคุยต่อ โปรดศึกษาข้อมูลเพิ่มเติมนะครับ
แล้ววิธีนี้มันดีกว่า Data URI ยังไง
ขออ้างอิงคำตอบใน stack overflow มานะครับ ตัว Data URI หรือ Base64 นั้นมีปัญหาตรงที่ แต่ละตัวอักษรกินพื้นที่ 2 Bytes ใน Javascript ยิ่งไปกว่านั้นข้อมูลต้นทางจะถูกเพิ่มปริมาณ 33% ตอน Encoding แต่เจ้า Blob นั้นมันเป็น Binary Byte Array ตรงๆ ไม่มี overhead แต่อย่างใด ซึ่งทำให้ การจัดการ Blob นั้นเร็วกว่า และประหยัดกว่า
It is also a better alternative to Data-URI which are strings encoded as Base-64. The problem with Data-URI is that each char takes two bytes in JavaScript. On top of that a 33% is added due to the Base-64 encoding. Blobs are pure binary byte-arrays which does not have any significant overhead as Data-URI does, which makes them faster and smaller to handle.
ที่นี้ปัญหามันไปอยู่ตรงที่ เราจะ Implement Webview ของ Android ที่มีการทำงานเกี่ยวกับ DownloadListener ยังไงให้สามารถ Support Protocol นี้ได้ละ 555 ทิ้ง Bomb ไว้เผื่อมีใครอยากเขียนต่อ สามารถ Direct มาฝากลิงค์ได้นะครับ