เมื่อแมชชีนเลิร์นนิงเล่าเรื่องผิด

 (jackcook.com)
3 คะแนน โดย GN⁺ 2024-11-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงการความปลอดภัยฮาร์ดแวร์ของ MIT พยายามทำซ้ำ การโจมตี side-channel ที่มีแมชชีนเลิร์นนิงช่วยบนเว็บเบราว์เซอร์ และพบกับกับดักที่ว่า ความแม่นยำของโมเดลที่สูงไม่ได้พิสูจน์สาเหตุที่แท้จริง
  • งานวิจัยเดิมด้านการทำ fingerprint เว็บไซต์มองว่า การแย่งใช้ CPU cache คือสาเหตุ แต่เมื่อเอาการเข้าถึงแคชออกแล้วเปลี่ยนเป็นแค่เพิ่มตัวนับอย่างง่าย กลับได้ความแม่นยำสูงกว่าในหลายสภาพแวดล้อม
  • ทีมวิจัยค่อย ๆ ตัดสมมติฐานเรื่องการปรับสเกลความถี่ CPU, การแย่งคอร์ CPU, และสมมติฐานเรื่องแคชออกไป และยืนยันด้วยการทำ instrumentation ด้วย eBPF ว่ามากกว่า 99% ของช่วงที่หยุดเกิน 100ns คือการจัดการ interrupt
  • แค่สัญญาณ interrupt ของระบบก็เพียงพอที่จะเผยกิจกรรมการโหลดเว็บไซต์ และบน Chrome/Linux ความแม่นยำในการระบุเว็บไซต์เป้าหมายจาก 100 เว็บไซต์อยู่ได้สูงถึง 96.6%
  • หากจะออกแบบมาตรการป้องกัน สิ่งที่ต้องมาก่อนคือการวิเคราะห์เพื่อยืนยัน กลไกจริงของ side-channel ไม่ใช่ดูแค่ว่าโมเดลทำนายถูก

จุดเริ่มต้นของงานวิจัย

  • ในปี 2020 วิชา Secure Hardware Design ของ MIT ได้เริ่มโปรเจกต์ทำซ้ำการโจมตี website fingerprinting โดยอาศัยประสบการณ์ด้านเว็บดีเวลอปเมนต์และแมชชีนเลิร์นนิง
  • Mengjia Yan มองว่างานวิจัย website fingerprinting ล่าสุดที่ใช้แมชชีนเลิร์นนิงโจมตีจุดอ่อนของฮาร์ดแวร์มีบางอย่างไม่สอดคล้อง จึงเสนอให้ทำซ้ำ
  • โปรเจกต์นี้ต่อยอดไปเป็นงานวิจัย There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
    • งานวิจัยนี้ได้อันดับ 1 ของ Intel 2024 Hardware Security Academic Award และได้รับคัดเลือกใน IEEE Micro Top Picks ปี 2023
    • งานศึกษานี้ครอบคลุม 3 แกนหลักคือ การโจมตีผ่านเบราว์เซอร์, การรั่วไหลผ่าน system interrupt, และความผิดพลาดในการตีความผลของแมชชีนเลิร์นนิง

Side-channel และ website fingerprinting

  • การแยก process ช่วยแยกหน่วยความจำและทรัพยากรของแอปพลิเคชัน แต่ในคอมพิวเตอร์จริง ทรัพยากรอย่างการ์ดเครือข่าย, GPU, และ CPU ยังคงถูกแชร์กัน
  • ทรัพยากรที่ใช้ร่วมกันอาจรั่วข้อมูลกิจกรรมของผู้ใช้ออกมาโดยไม่ตั้งใจ
    • หากมีคนที่ใช้เราเตอร์ Wi‑Fi ตัวเดียวกันดูวิดีโอขนาดใหญ่ เวลาดาวน์โหลดของผู้ใช้อีกคนอาจช้าลง
    • การเปลี่ยนแปลงของการใช้พลังงานหรือการแผ่คลื่นแม่เหล็กไฟฟ้าก็อาจกลายเป็น side-channel สำหรับคาดเดาคีย์เข้ารหัสหรือกิจกรรมของผู้ใช้ได้
  • website fingerprinting คือการโจมตีที่เว็บไซต์ของผู้โจมตีในแท็บหนึ่งพยายามระบุว่าเว็บไซต์เหยื่อใดถูกเปิดอยู่ในอีกแท็บหนึ่ง
  • งานวิจัยเดิมของ Shusterman et al. เสนอการโจมตีที่ใช้ CPU cache เพื่อทายว่าเว็บไซต์ใดถูกเปิดอยู่จากตัวเลือก 100 เว็บไซต์
    • ผู้โจมตีสร้างอาร์เรย์ขนาดเท่า CPU cache แล้วเติมค่า 1
    • ระหว่างที่เว็บไซต์เหยื่อกำลังโหลด จะวัดเวลาเข้าถึงอาร์เรย์ทุก ๆ 2ms
    • เก็บค่าที่วัดได้รวม 7,500 ค่าในเวลา 15 วินาที
    • เพราะแต่ละเว็บไซต์มีรูปแบบของสคริปต์ รูปภาพ สไตล์ชีต และการเรนเดอร์ที่คล้ายกันซ้ำ ๆ trace ที่วัดได้จึงใช้เป็นลายนิ้วมือได้
    • รวบรวม trace เว็บไซต์ละ 100 ชุดจาก 100 เว็บไซต์ เป็นชุดข้อมูลติดป้ายกำกับรวม 10,000 ชุดเพื่อนำไปฝึกโมเดลแมชชีนเลิร์นนิง
    • ได้ความแม่นยำสูงสุด 91.4% บนหลายเบราว์เซอร์และหลายระบบปฏิบัติการ

การโจมตีแบบตัวนับที่ตัดแคชออก

  • ในการทำซ้ำช่วงแรก การจำแนก 4 เว็บไซต์ทำได้ง่าย และได้ความแม่นยำ 98% ด้วยตัวจำแนก Random Forest แบบง่าย
  • เมื่อขยายการทดลองเป็น 10 เว็บไซต์ ตอนแรกได้ความแม่นยำ 75% แต่ต่อมาก็ปรับปรุงจนจำแนกได้ทั้ง 10, 50 และ 100 เว็บไซต์
  • การเปลี่ยนแปลงสำคัญคือการตัดการเข้าถึงอาร์เรย์แคชออก แล้วทำให้ฝั่งผู้โจมตีวน value++ ให้เร็วที่สุด
    • หากบันทึกค่าตัวนับตามช่วงเวลา ก็จะได้ trace ที่สะท้อนว่าคอมพิวเตอร์ได้ประมวลผลไปมากน้อยแค่ไหนในช่วงนั้น
    • กิจกรรมอื่นอย่างการย่อขยายหน้าต่างเบราว์เซอร์หรือเปิดแท็บใหม่ก็สะท้อนอยู่ใน trace ของตัวนับด้วย
    • ในงานวิจัยมีการบันทึกค่าทุก 5ms เพื่อเก็บข้อมูลได้มากขึ้นในเวลาคงที่
  • โมเดลที่ฝึกจาก trace ของตัวนับให้ความแม่นยำในการระบุเว็บไซต์สูงกว่าการใช้ trace ความหน่วงของแคชแบบเดิม
  • ผลนี้ทำให้เกิดคำถามว่าการโจมตีเดิมใช้ การแย่งใช้แคช จริงหรือไม่ และนำไปสู่การวิเคราะห์เพื่อหาสาเหตุ

ช่องว่างระหว่างความแม่นยำของโมเดลกับการวิเคราะห์สาเหตุ

  • ในการโจมตี side-channel ที่มีแมชชีนเลิร์นนิงช่วย ความจริงที่ว่าโมเดลสามารถทำนายกิจกรรมของผู้ใช้ได้อย่างสม่ำเสมอ แสดงเพียงว่า มีสัญญาณอยู่จริง
  • ความแม่นยำที่สูงไม่ได้พิสูจน์ว่าสัญญาณนั้นมาจาก side-channel ใด
    • แม้โมเดลของ Shusterman et al. จะทายเว็บไซต์เหยื่อได้ด้วยความแม่นยำ 91.4% ก็ไม่ได้หมายความว่ามันจับการแย่งใช้ CPU cache ได้จริง
    • สิ่งที่โมเดลหาเจอคือความสัมพันธ์ ไม่ใช่คำอธิบายสาเหตุของสัญญาณ
  • การวิเคราะห์สาเหตุที่ผิดอาจทำให้การออกแบบมาตรการป้องกันหลงทาง
    • นักวิจัยออกแบบแนวป้องกันเพื่อทำให้คอมพิวเตอร์ปลอดภัยขึ้นโดยอิงจากงานโจมตีเหล่านี้
    • หากเข้าใจสาเหตุของการโจมตีผิด ก็อาจเสียทั้งเวลาและแรงงานโดยเปล่าประโยชน์

ตรวจสอบสมมติฐาน: ความถี่ คอร์ และ interrupt

  • ทีมวิจัยเปรียบเทียบการโจมตีแบบแคชเดิมกับการโจมตีแบบตัวนับใหม่ในหลายสภาพแวดล้อม
    • ในโจทย์ระบุเว็บไซต์จาก 100 เว็บไซต์ การโจมตีแบบตัวนับให้ความแม่นยำสูงกว่าแทบทุกการตั้งค่าทดลอง
    • บน Safari ของ macOS การโจมตีแบบแคชได้ 72.6% ขณะที่การโจมตีแบบตัวนับได้ 96.6%
    • ในการตั้งค่าพื้นฐาน สามารถระบุคำตอบที่ถูกต้องจาก 100 เว็บไซต์ได้ด้วยความแม่นยำ 95.2%

  • สมมติฐานเรื่องการปรับสเกลความถี่ CPU

    • CPU สมัยใหม่จะเพิ่มหรือลดความถี่ตามภาระงานเพื่อประหยัดพลังงาน
    • จึงตั้งสมมติฐานว่า ระหว่างการโหลดเว็บไซต์เหยื่อ ความถี่ CPU ที่เปลี่ยนไปอาจทำให้ค่าตัวนับเปลี่ยน
    • หลังปิดการปรับสเกลความถี่ใน BIOS แล้วเก็บข้อมูลใหม่และฝึกโมเดลอีกครั้ง
    • ความแม่นยำลดจาก 95.2% เหลือเพียง 94.2% หรือลดลง 1 จุดเปอร์เซ็นต์ จึงยากจะอธิบายความเปลี่ยนแปลงของค่าตัวนับด้วยความถี่ CPU

  • สมมติฐานเรื่องการแย่งคอร์ CPU

    • หากแท็บของผู้โจมตีและเหยื่อรันบนคอร์ CPU เดียวกัน การโหลดแท็บเหยื่ออาจลดเวลาที่ผู้โจมตีใช้รันตัวนับได้
    • ใช้ taskset บน Linux เพื่อตรึงให้แท็บผู้โจมตีและแท็บเหยื่อรันบนคนละคอร์
    • แม้จะปิดการปรับสเกลความถี่ CPU ไว้ด้วย ความแม่นยำก็ยังอยู่ที่ 94.0%
    • จึงยากจะมองว่าการแย่งคอร์ CPU เป็นสาเหตุหลัก

  • สมมติฐานเรื่อง system interrupt

    • สมมติฐานถัดมาคือ system interrupt คือสัญญาณของการโจมตีแบบตัวนับ
    • ระบบปฏิบัติการใช้ interrupt เพื่อสื่อสารกับอุปกรณ์ฮาร์ดแวร์อย่างคีย์บอร์ด เมาส์ จอภาพ และการ์ดเครือข่าย
    • เมื่อ interrupt มาถึงคอร์ CPU โปรแกรมที่กำลังรันอยู่บนคอร์นั้นจะหยุดทันที และตัวจัดการ interrupt จะเริ่มทำงาน
    • ระหว่างโหลดเว็บไซต์เหยื่อ อุปกรณ์ต่าง ๆ เช่น เครือข่ายและกราฟิกจะสร้าง interrupt และหากถูกประมวลผลบนคอร์เดียวกับผู้โจมตี ค่าตัวนับของผู้โจมตีอาจลดลง
    • บน Linux สามารถดูการจัดการ interrupt ได้ด้วย cat /proc/interrupts

Interrupt ที่ย้ายได้และย้ายไม่ได้

  • Linux สามารถ route interrupt ที่ย้ายได้ บางส่วนไปยังคอร์ที่กำหนดได้
    • interrupt ที่มี ID เป็นตัวเลขอยู่ในกลุ่มนี้
    • มักมาจากอุปกรณ์ฮาร์ดแวร์ภายนอก เช่น คีย์บอร์ดหรือการ์ดเครือข่าย
  • interrupt ที่ย้ายไม่ได้ จำนวนมากไม่สามารถแยกไปยังคอร์เฉพาะได้
    • interrupt ที่มี ID เป็นตัวอักษร 3 ตัวอยู่ในกลุ่มนี้
    • เพราะใช้ซิงก์กิจกรรมระหว่างคอร์ CPU จึงต้องถูกจัดการบนทุกคอร์
    • ในสภาพแวดล้อมทดลอง interrupt กลุ่มนี้คิดเป็นกิจกรรมส่วนใหญ่
  • ใช้ irqbalance เพื่อส่ง interrupt ที่ย้ายได้ไปยังคอร์ 1 และใช้ taskset ให้ผู้โจมตีกับเหยื่อรันบนคอร์ 2 และ 3
  • เมื่อความถี่ CPU ถูกตรึงไว้ด้วย ความแม่นยำลดลงเกือบ 6 จุดเปอร์เซ็นต์ ทำให้สมมติฐานเรื่อง interrupt มีน้ำหนักมากขึ้น

สาเหตุจริงที่ยืนยันด้วย eBPF

  • เพราะการทดลองแยกแม้แต่ interrupt ที่ย้ายไม่ได้ออกอย่างสมบูรณ์ทำไม่ได้ด้วยข้อจำกัดของโครงสร้างระบบปฏิบัติการ จึงใช้ eBPF ทำ instrumentation การรัน
  • ผ่าน eBPF มีการบันทึกเวลาอยู่ 2 แบบ
    • ช่วงที่โปรแกรมของผู้โจมตีเริ่มและหยุด
    • ช่วงที่ตัวจัดการ interrupt เริ่มและหยุด
  • เมื่อความถี่ CPU คงที่ หากผู้โจมตีไม่ถูกรบกวน ก็ควรจะรันคำสั่งได้เกือบเท่าเดิมในช่วงเวลาคงที่
  • ใช้ โค้ด eBPF ที่ Jonathan Behrens เขียนไว้เพื่อเปรียบเทียบช่วงที่การรันของผู้โจมตีหยุดกับช่วงที่มีการจัดการ interrupt
  • พบว่ามากกว่า 99% ของช่วงที่การรันของผู้โจมตีหยุดเกิน 100ns คือเวลาที่ใช้จัดการ interrupt
  • กล่าวได้ว่าคอร์ CPU ของผู้โจมตีกำลังทำอย่างใดอย่างหนึ่งระหว่างรันโค้ดนับค่ากับจัดการ interrupt และเมื่อเวลาในการจัดการ interrupt ลดลง ค่าตัวนับจะสูงขึ้น แต่หากเพิ่มขึ้น ค่าตัวนับก็จะลดลง

ผลลัพธ์หลัก 2 ข้อของงานวิจัย

  • ผลลัพธ์ข้อแรกคือ system interrupt รั่วไหลกิจกรรมของผู้ใช้
    • คุณสมบัติด้านความปลอดภัยของ system interrupt ไม่เคยถูกศึกษาในวรรณกรรมเดิม
    • ทีมวิจัยเป็นกลุ่มแรกที่วิเคราะห์ side-channel ที่อาศัย system interrupt
  • ผลลัพธ์ข้อที่สองคือ การวิเคราะห์การโจมตี side-channel ที่มีแมชชีนเลิร์นนิงช่วยต้องทำอย่างระมัดระวัง
    • โมเดลแมชชีนเลิร์นนิงสามารถสร้างการโจมตีที่ทรงพลังได้ แม้จะไม่เข้าใจ side-channel เลยก็ตาม
    • หากไม่ได้ทำ instrumentation กับระบบปฏิบัติการ ก็ไม่อาจสรุปได้ว่าใช้ side-channel แบบใด
  • มาตรการป้องกันการโจมตีแบบแคชเดิมคือการไล่ cache ออกซ้ำ ๆ เพื่อเพิ่ม noise
  • แนวป้องกันที่สร้าง interrupt จำนวนมาก เช่น การส่งคำขอเครือข่ายไปยัง local IP address กลับทำงานได้ดีกว่าทั้งกับการโจมตีแบบแคชและแบบตัวนับ
  • การเปรียบเทียบนี้ช่วยเสริมหลักฐานว่าการโจมตีของ Shusterman et al. ใช้สัญญาณจาก interrupt เป็นหลักมากกว่าแคช

การทดลองเพิ่มเติมและความเป็นไปได้ด้านการป้องกัน

  • งานวิจัย ยังมีผลลัพธ์เพิ่มเติมด้วย
    • เสนอวิธีบรรเทาการโจมตีอย่างสมบูรณ์โดยปรับนาฬิกาเบราว์เซอร์ที่ให้กับ JavaScript
    • ทำการทดลองแยกผู้โจมตีกับเหยื่อไว้ใน virtual machine คนละตัว
    • วิเคราะห์ความถี่และเวลาในการจัดการของ interrupt ที่ย้ายไม่ได้หลายประเภท
  • เบราว์เซอร์ทำให้การโจมตีที่อาศัย timing ความละเอียดสูงยากขึ้นด้วยการลดความละเอียดของ clock ที่ให้กับ JavaScript
    • Chrome ปัดเศษเป็นหน่วย 0.1ms และเพิ่ม noise แบบสุ่ม
    • Firefox และ Safari ปัดเศษเป็นหน่วย 1ms
    • Tor Browser ปัดเศษเป็นหน่วย 100ms ทำให้ความแม่นยำของการโจมตีลดจาก 96.6% บน Chrome เหลือ 49.8%
  • การลดความละเอียดของ clock มี trade-off
    • เอนจินเกมบนเบราว์เซอร์ต้องใช้ตัวจับเวลาความละเอียดสูงสำหรับการเรนเดอร์และแอนิเมชัน
    • ผู้ใช้ Tor Browser ส่วนใหญ่อาจเล่นเกมได้ยาก แต่สำหรับผู้ใช้ที่ให้ความสำคัญกับความปลอดภัย เรื่องนี้อาจไม่ใช่ปัญหา

คำถามวิจัยที่ยังเหลืออยู่

  • system interrupt เชื่อมโยงกับกลไกฮาร์ดแวร์ระดับลึกของคอมพิวเตอร์สมัยใหม่ เช่น Spectre และ Meltdown
  • แนวป้องกันที่แยก interrupt ที่ย้ายไม่ได้ออกจากผู้โจมตียังทำไม่ได้ในปัจจุบัน และก็ยังไม่ชัดเจนว่าต้องออกแบบคอมพิวเตอร์ใหม่อย่างไรจึงจะทำได้
  • ความสัมพันธ์ระหว่างกิจกรรมของเว็บไซต์กับ interrupt ก็ยังเข้าใจได้ไม่เพียงพอ
    • weather.com ทำให้เกิด rescheduling interrupt จำนวนมาก แต่ nytimes.com และ amazon.com ไม่เป็นเช่นนั้น
    • ยังไม่มีการวิเคราะห์ว่ารูปภาพ โฆษณา และสคริปต์เพิ่มเติมส่งผลต่อ trace ของตัวนับอย่างไร
  • การโจมตีอาจรุนแรงขึ้นได้อีก
    • งานวิจัยนี้ใกล้เคียงกับ “บทความวิเคราะห์” มากกว่า “บทความโจมตี”
    • ความแม่นยำ 96.6% ที่ได้บน Chrome/Linux อาจไม่ใช่เพดานสูงสุด แต่อาจเป็นเพียงค่าขั้นต่ำ
    • ยังมีความเป็นไปได้ที่จะนำโมเดลที่ดีกว่าหรือวิธีวิทยาแบบอื่นไปใช้กับงานอย่างการจำแนก 1,000 เว็บไซต์ การตรวจว่ากำลังดูหนังอยู่หรือไม่ การใช้ VPN หรือความถี่ในการเช็ก Robinhood
  • แนวป้องกันฝั่งเบราว์เซอร์ก็ยังต้องนำไปใช้งานจริงในเบราว์เซอร์จริง และตรวจสอบว่ามีความเหมาะสมต่อผู้ใช้ทั่วไปหรือไม่

ผลกระทบของงานวิจัยต่อเส้นทางชีวิตส่วนตัว

  • ก่อนโปรเจกต์นี้ การเรียนต่อบัณฑิตศึกษาไม่ใช่ทางเลือกที่พิจารณาอย่างจริงจัง และหลังจากฝึกงานวิจัย deep learning ที่ NVIDIA ก็เคยคิดจะไปทำงานในบริษัทยักษ์ใหญ่สายเทคหรือสตาร์ตอัป AI
  • หลังโปรเจกต์นี้ ได้สัมผัสว่าการวิจัยสามารถทั้งสนุกและงดงามได้
  • หลังเรียนจบ MIT จึงเรียนต่อหลักสูตร MEng ด้านวิทยาการคอมพิวเตอร์อีก 1 ปี และต่อมาได้รับ Rhodes scholarship ไปศึกษาที่ University of Oxford เป็นเวลา 2 ปี
  • ปีถัดไปมีกำหนดจะเริ่มเรียนปริญญาเอกวิทยาการคอมพิวเตอร์ 6 ปีที่ MIT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-11
ความคิดเห็นบน Hacker News

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

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

  • เป็นบทความที่ยอดเยี่ยม ไม่คิดว่า การโจมตีผ่านช่องทางข้างเคียง จะอธิบายให้เข้าใจง่ายได้ขนาดนี้
    อ่านเหมือนนิยายฆาตกรรมปริศนา ที่รู้ตั้งแต่ต้นว่าคนร้ายคือใคร แต่ค่อย ๆ ตามหาว่า “เขาทำได้อย่างไร”
    กดเก็บเข้ารายการโปรดไว้แล้ว

    • เกือบไม่ได้อ่านเพราะความยาวและส่วนเกริ่นนำ ปกติแล้วผมอยากเห็นประเด็นหลักทันทีมากกว่าพื้นหลัง
      แต่เพราะคอมเมนต์นี้เลยไปอ่าน และมันดีจริง ๆ

  • ท่อนที่ว่า “ปีหน้าผมจะกลับไป MIT เพื่อเริ่มเรียนปริญญาเอกด้านวิทยาการคอมพิวเตอร์แบบ 6 ปี ผมตื่นเต้นไปกว่านี้ไม่ได้แล้ว!” น่าทึ่งมาก
    ทุกอย่างเริ่มจาก ไอเดียโชคดี ของผู้เขียนที่ลองแบบสุ่ม ๆ ว่าจะใช้ตัวนับดู แทนที่จะใช้การโจมตีขับแคชออกที่ซับซ้อนกว่ามากของการโจมตีผ่านช่องทางข้างเคียงเดิม และมันได้ผลเพราะแนวคิดบางอย่างที่ตอนนั้นเขายังไม่รู้
    คนอย่างผมซึ่งน่าจะเป็นหนึ่งในหลายพันคนไม่ได้มีโชคแบบนั้น เลยเลิกคิดจะอยู่ในแวดวงวิชาการค่อนข้างเร็ว แล้วไปทำงานในอุตสาหกรรม มีเส้นทางอาชีพธรรมดา ๆ
    ผมเริ่มเรียน Honours Degree ด้านวิทยาการคอมพิวเตอร์แบบออสเตรเลียที่คล้ายปริญญาโท และราวปี 2010 ซึ่งเป็นช่วงก่อนกระแส AI ปัจจุบันไปมาก ผมอยากเขียน เปเปอร์ด้านปัญญาประดิษฐ์ โดยอิงจากกรณีใช้งานที่เรียนมาในวิชา AI ภาคปกติ
    ผมอยากเริ่มจากวิธีที่โรงไวน์ใช้ AI เพื่อปรับปรุงคุณภาพและการผลิตไวน์ แล้วลองประยุกต์กับการใช้งานที่ “ทั่วไปกว่า” แต่ที่ปรึกษาที่ได้รับมอบหมายไม่มีความสนใจจะช่วยเลย และไม่มีแรงสนับสนุนอื่น ทำให้เดินหน้าต่อได้ยาก
    โดยเฉพาะเมื่อมีข้อเสนองานประจำเงินเดือนค่อนข้างดี และต่อให้เรียนต่อไปก็คงไม่ได้ผลงานมากนัก
    อย่างที่ผู้เขียนบอก งานเดินหน้าได้เพราะมีที่ปรึกษาและความช่วยเหลือรอบตัว ถ้าทำคนเดียวต้องมีแรงผลักดันและพรสวรรค์มหาศาล ซึ่งผมคงขาดทั้งสองอย่าง

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

  • บทความดี
    ขอจับผิดเรื่องหน้าเว็บเล็กน้อยมาก ๆ คือ เส้นแบ่งสไตล์จุดใหญ่เรียงต่อกัน ดูเหมือนตัวบอกตำแหน่งของภาพใน carousel เลยทำให้สับสน

  • บทความยอดเยี่ยม คำอธิบายเข้าถึงง่ายมาก และ เดโมแบบอินเทอร์แอคทีฟ ก็เจ๋งจริง ๆ
    ชอบที่เล่าภูมิหลังด้วยว่าเริ่มมาทำเรื่องนี้ได้อย่างไร

  • น่าสนใจมากและอธิบายได้ดีมาก ถ้างานวิจัยนี้ออกมา 2 ปีแล้ว นักเก็บข้อมูล ที่สนใจก็น่าจะพิจารณาไปแล้ว
    ลืมเรื่องแฮกเกอร์ไปได้เลย นี่คือ exploit สำหรับบริษัทและรัฐบาล
    เว็บไซต์ที่ให้ความสำคัญกับความเป็นส่วนตัวจะเผยแพร่แพ็กเกจที่สุ่มสร้าง interrupt ได้ไหม? ส่วนขยายเบราว์เซอร์จะทำแบบนั้นกับทุกไซต์ได้ไหม?

    • เว็บไซต์ต้องระวังถ้าจะทำแบบนั้น ถ้าเป็นไซต์เดียวที่สุ่มสร้าง interrupt จำนวนมาก ก็อาจยิ่งถูกระบุตัวตนได้ง่ายขึ้น
      มาตรการตอบโต้ของเราที่สุ่มสร้าง interrupt ถูกทำเป็นส่วนขยายเบราว์เซอร์ไว้แล้ว และซอร์สโค้ดอยู่ที่นี่: https://github.com/jackcook/bigger-fish
      แต่คงแนะนำให้ใช้ในชีวิตประจำวันได้ยาก จากที่จำได้ ในการทดสอบ เวลาโหลดหน้าเว็บช้าลงประมาณ 10%
    • ผมใช้ Safari/macOS อยู่ และเดโมเกี่ยวกับการนับหลายตัวไม่ได้เปลี่ยนมากเท่าที่กล่าวอ้าง
      บางตัวเปลี่ยนค่อนข้างมากตอนคอมพิวเตอร์มีการใช้งานหนัก แต่ดูเหมือนว่า Safari อาจมีมาตรการบรรเทาบางอย่างอยู่แล้ว
      ถึงอย่างนั้นเปเปอร์นี้ก็ยอดเยี่ยมจริง ๆ