Blob URLs คืออะไร

เพื่อป้องกันการเข้าถึงหรือแชร์ลิงก์วิดีโอโดยตรง (direct video links) หนึ่งในเทคนิคเหล่านี้คือการใช้ "Blob URLs" หรือ Binary Large Objects

นี่คือวิธีที่เว็บไซต์ป้องกันลิงก์วิดีโอ

1. Blob URLs: Blob URL ถูกสร้างขึ้นโดยเว็บไซต์และมีชีวิตอยู่เฉพาะในเซสชั่นเบราว์เซอร์นั้นๆ พวกมันไม่ใช่ลิงก์ถาวรและไม่สามารถใช้ได้นอกเซสชั่นหรือเบราว์เซอร์นั้นๆ
2. การเข้ารหัส (Encryption): วิดีโอบางส่วนอาจถูกเข้ารหัสเพื่อป้องกันการดาวน์โหลดหรือแชร์โดยไม่ได้รับอนุญาตจากผู้เผยแพร่
3. การตรวจสอบสิทธิ์ (Token Authentication): บางครั้งลิงก์วิดีโอจะมีโทเค็นหรือคีย์ที่ต้องใช้เพื่อเข้าถึงเนื้อหา, โดยโทเค็นเหล่านี้มักจะมีอายุการใช้งานจำกัด
4. การจำกัดการเข้าถึงตามต้นทาง (Referrer Restrictions): บางเว็บไซต์จะตรวจสอบว่าคำขอเข้าถึงวิดีโอมาจากไหน, หากคำขอมาจากเว็บไซต์อื่นที่ไม่ได้รับอนุญาต, วิดีโอจะไม่ถูกแสดง

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

การใช้ Blob URLs ในร่วมกับ Amazon S3 สำหรับการสตรีมวิดีโอสามารถช่วยเพิ่มการควบคุมและความปลอดภัยสำหรับเนื้อหาของคุณได้

นี่คือขั้นตอนพื้นฐานและเครื่องมือที่อาจจำเป็น

1. เก็บไฟล์วิดีโอใน Amazon S3: อัปโหลดไฟล์วิดีโอของคุณลงในบักเก็ต S3
2. การตั้งค่าการเข้าถึง S3: ปรับการตั้งค่าการเข้าถึงใน S3 เพื่อจำกัดการเข้าถึงไฟล์. คุณสามารถใช้บทบาท IAM, นโยบายบักเก็ต, หรือระบบการจัดการคีย์สำหรับการเข้ารหัส
3. สร้าง API สำหรับการรับส่งวิดีโอ: ใช้ AWS Lambda หรือบริการการคำนวณแบบ serverless อื่นๆ เพื่อสร้าง API ที่สามารถขอข้อมูลไฟล์จาก S3 และส่งคืนเป็น Blob URLs
4. การใช้งานสตรีมมิ่งผ่านเว็บแอปพลิเคชัน: บนเว็บแอปพลิเคชันของคุณ, ใช้ JavaScript หรือเฟรมเวิร์กเว็บอื่นๆ เพื่อร้องขอวิดีโอจาก API ที่คุณสร้างขึ้น. จากนั้น, แปลงข้อมูลที่ได้รับเป็น Blob URL และใช้มันเพื่อสตรีมวิดีโอในเว็บแอปของคุณ
5. การจัดการความปลอดภัยเพิ่มเติม: ใช้โทเค็นการเข้าถึงที่มีอายุจำกัด, HTTPS สำหรับการส่งข้อมูลทั้งหมด, และการตรวจสอบสิทธิ์เพื่อเพิ่มความปลอดภัย
6. ใช้งานผ่านเว็บเพลเยอร์: ผู้ใช้ของคุณจะเข้าถึงวิดีโอผ่านเว็บเพลเยอร์ที่มีการสตรีม Blob URL ที่ถูกสร้างขึ้นจาก S3

ตัวอย่างของเครื่องมือที่คุณอาจใช้ได้แก่ AWS SDK สำหรับการสื่อสารกับ S3, AWS Lambda หรือ AWS API Gateway สำหรับการสร้าง API, และ JavaScript หรือเฟรมเวิร์กฝั่งไคลเอนต์อื่นๆ สำหรับการจัดการ Blob URLs บนเว็บแอปของคุณ

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

นี่คือหลักการพื้นฐานของการป้องกันลิงก์ใน Amazon S3

1. นโยบายการเข้าถึงบักเก็ต (Bucket Access Policies): คุณสามารถตั้งค่านโยบายบักเก็ตเพื่อควบคุมผู้ใช้หรือบริการที่สามารถเข้าถึงไฟล์ในบักเก็ตได้
2. การใช้งาน IAM Roles: คุณสามารถสร้างบทบาท IAM เพื่อกำหนดสิทธิ์การเข้าถึง S3 สำหรับผู้ใช้หรือบริการต่างๆ ใน AWS
3. การเข้ารหัสไฟล์ (File Encryption): S3 รองรับการเข้ารหัสไฟล์ทั้งในขณะเก็บข้อมูลและในขณะส่งข้อมูล, ช่วยป้องกันการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต
4. Pre-Signed URLs: สำหรับการแชร์ไฟล์อย่างปลอดภัย, S3 สามารถสร้าง Pre-Signed URLs ที่มีอายุการใช้งานจำกัด. ลิงก์เหล่านี้ให้การเข้าถึงไฟล์ชั่วคราวและสามารถหมดอายุได้หลังจากเวลาที่กำหนด
5. การจำกัดตามต้นทาง (Origin Restrictions): คุณสามารถตั้งค่าให้ไฟล์ใน S3 สามารถเข้าถึงได้เฉพาะจากต้นทางหรือโดเมนที่ระบุ
6. การตรวจสอบสิทธิ์ (Authentication Checks): การใช้งานระบบการตรวจสอบสิทธิ์สามารถช่วยป้องกันการเข้าถึงไม่เหมาะสม

จุดเริ่มต้นของการใช้ Base64 URI ในเบาวเซอร์ เอ้อร์ เอ้อร์ และ Blob Protocol (Blob URLs)

เริ่มตั้งแต่ที่มาของ 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 มาฝากลิงค์ได้นะครับ