อย่าทำขึ้นเอง …
(susam.net)- หลักการ Don't Roll Your Own ... ใช้ได้ไม่เฉพาะกับงานเข้ารหัสลับ แต่รวมถึงเว็บ UI ด้วย โดยไม่ควรแทนที่ความสามารถที่เบราว์เซอร์มีให้อย่างเสถียรอยู่แล้วโดยไม่จำเป็น
- การ แทนที่พฤติกรรมพื้นฐาน เช่น การเลื่อนเอง การจัดการลิงก์ การเลือกข้อความ การคัดลอก·วาง อาจทำลายการตอบสนองต่ออินพุตที่ผู้ใช้คุ้นเคย และทำให้ผู้ใช้ต้องกลับมาใส่ใจกับวิธีควบคุมอีกครั้ง
- หาก JavaScript ดักการนำทางลิงก์ เหมือนลิงก์ไฟล์·อีชูของ GitHub บางครั้งการเปิดในแท็บใหม่กลับเร็วกว่า การรอให้ประมวลผลในแท็บปัจจุบัน
- ช่อง รหัสผ่าน มาตรฐานและ
<input type="date">ทำงานร่วมกับการเติมข้อมูลอัตโนมัติ ตัวจัดการรหัสผ่าน เครื่องมือการช่วยการเข้าถึง และคีย์บอร์ดมือถือ ดังนั้นหากเปลี่ยนเป็น UI ปลอม ฟังก์ชันเหล่านี้อาจเสียได้ - เลย์เอาต์และตัวควบคุมฟอร์มที่เปลี่ยนทุกไม่กี่เดือนทำให้ผู้ใช้ต้องเสียเวลาไปกับการเรียนรู้ใหม่มากกว่าการทำงาน และควรรักษาพฤติกรรมมาตรฐานของเบราว์เซอร์ที่เสถียรไว้
การประยุกต์หลักการ “อย่าทำขึ้นเอง” กับเว็บ UI
- หลัก ห้ามทำระบบเข้ารหัสลับเอง หมายถึงไม่ควรพึ่งพาการพัฒนาเฉพาะภายในที่ยังไม่ผ่านการพิสูจน์ ในซอฟต์แวร์ปฏิบัติการที่ต้องปกป้องข้อมูลสำคัญ
- ไม่ได้หมายความว่าไม่มีใครควรเขียนโค้ดเข้ารหัสลับเลย แต่ใกล้เคียงกับการบอกว่า ควรใช้ แพ็กเกจและเครื่องมือที่ผ่านการตรวจสอบและยืนยันแล้ว ให้มากที่สุด
- เมื่อราว 20 ปีก่อน เคยมีการทำ RC4 เองที่มีปัญหาจริง เช่น initialization vector ที่ไม่เหมาะสม คีย์สตรีมที่คาดเดาได้ หรือการรั่วไหลของข้อความต้นฉบับบางส่วน
- ปัจจุบันเว็บไซต์อีคอมเมิร์ซหรือธนาคารรายใหญ่โดยทั่วไปไม่ได้ใช้การเข้ารหัสลับที่ทำเองกับเว็บเซอร์วิส และในพื้นที่ที่มีข้อกำกับดูแล เช่น การชำระเงิน การแพทย์ หรือการจัดการข้อมูลส่วนบุคคล การฝ่าฝืนข้อกำหนดด้านการเข้ารหัสลับที่เข้มงวดอาจนำไปสู่ค่าปรับจำนวนมาก
- การออกแบบเว็บไซต์ไม่เหมือนกับการเข้ารหัสลับ แต่การนำสิ่งที่เบราว์เซอร์จัดการได้ดีอยู่แล้วและผู้ใช้พึ่งพาทุกวันมาทำใหม่ อาจทำให้ประสบการณ์ผู้ใช้แย่ลงได้
ปัญหาที่เกิดขึ้นเมื่อแทนที่ความสามารถพื้นฐานของเบราว์เซอร์
- หากทำ การเลื่อนหน้า เอง การตอบสนองต่อเมาส์ ทัชแพด และคีย์บอร์ดที่ผู้ใช้คุ้นเคยอาจพังได้
- เมื่อเขียนทับพฤติกรรมการเลื่อนมาตรฐาน หน้าอาจเลื่อนช้าเกินไปหรือเร็วเกินไป และการเลื่อนด้วยคีย์บอร์ดอาจใช้งานไม่ได้
- หากพฤติกรรมที่ผู้ใช้ใช้อย่างไม่รู้ตัวถูกเปลี่ยนเป็นสิ่งที่ไม่คุ้นเคย ผู้ใช้ก็ต้องกลับมาใส่ใจกับการควบคุมหน้าเว็บเอง
- ความสามารถตัวอย่างที่ไม่ควรทำเอง ได้แก่ การนำทางลิงก์ การเลือกข้อความ เมนูคลิกขวา การคัดลอก·วาง ช่องรหัสผ่าน และตัวเลือกวันที่
- เมื่อใส่ฟังก์ชันส่วนติดต่อผู้ใช้ลงในเว็บไซต์สำหรับงานจริงจัง ควรตัดสินใจอย่างระมัดระวังว่าจะเพิ่มลูกเล่นหรือปล่อยให้เป็นพฤติกรรมมาตรฐานของเบราว์เซอร์
การนำทางลิงก์และกรณีของ GitHub
- เว็บเบราว์เซอร์จัดการการตามลิงก์ได้ดีอยู่แล้ว และการนำทางลิงก์เป็นความสามารถหลักของเบราว์เซอร์
- หากรู้สึกว่าจำเป็นต้องรบกวนพฤติกรรมลิงก์ตามปกติ ก็ควรทบทวนอีกครั้งว่าเป้าหมายที่ต้องการนั้นสำคัญพอจะทำลาย การนำทางลิงก์ แบบทั่วไปหรือไม่
- บน GitHub เมื่อคลิกลิงก์ไฟล์หรือลิงก์อีชู ฟังก์ชันขนาดใหญ่ที่ทำด้วย JavaScript จะเข้ามาจัดการการคลิกแทน
- ใน Firefox หรือ Chrome สามารถกด
F12เพื่อเปิดเครื่องมือนักพัฒนา แล้วเลือกclickในMouseของEvent Listener Breakpointsภายใต้แท็บDebuggerหรือSourcesจากนั้นคลิกลิงก์บน GitHub เพื่อดูพฤติกรรมนี้ได้ - บางครั้งบน GitHub การเปิดลิงก์ในแท็บใหม่เร็วกว่า การรอให้ JavaScript จัดการการนำทางในแท็บปัจจุบัน
การป้อนรหัสผ่านและตัวเลือกวันที่
- ช่องป้อนรหัสผ่าน ของเบราว์เซอร์สามารถรองรับการบันทึกรหัสผ่าน การกรอกอัตโนมัติ และการสร้างรหัสผ่านที่แข็งแรงสำหรับบัญชีใหม่
- ช่องรหัสผ่านมาตรฐานยังเตือนเมื่อมีการส่งรหัสผ่านผ่านการเชื่อมต่อ HTTP ที่ไม่ปลอดภัย และทำงานร่วมกับตัวจัดการรหัสผ่าน การเติมข้อมูลอัตโนมัติ คีย์บอร์ดมือถือ และเครื่องมือการช่วยการเข้าถึง
- หากแทนที่ด้วยช่องรหัสผ่านปลอม ฟังก์ชันเหล่านี้อาจเสียได้ และถ้ามาสก์ช่องข้อความธรรมดาเอง เบราว์เซอร์ ระบบปฏิบัติการ และเครื่องมือช่วยเหลืออาจจัดการรหัสผ่านนั้นราวกับเป็นข้อความธรรมดาที่มองเห็นได้
- แม้
<input type="date">จะยังไม่รองรับการเลือกช่วงวันที่โดยตรง แต่หากมีช่องวันเริ่มต้นและวันสิ้นสุด 2 ช่อง ก็ยังสามารถคงตัวเลือกวันที่มาตรฐานของเบราว์เซอร์ไว้ได้ - ตัวเลือกวันที่แบบกำหนดเอง แตกต่างกันไปตามแต่ละการพัฒนา บางแบบต้องซูมออกไปดูระดับปี บางแบบต้องกดปีย้อนหลังหลายสิบครั้งเพื่อเลือกปีเกิด หรืออาจป้องกันไม่ให้พิมพ์วันที่เอง
- หากต้องมีวิดเจ็ตปฏิทินสำหรับเบราว์เซอร์ที่รองรับตัวเลือกวันที่มาตรฐานได้ไม่ดี ควรเพิ่มเป็นวิดเจ็ตเสริมที่ทำงานกับฟิลด์เดิม แทนที่จะใช้แทน
<input type="date">
ต้นทุนของการเปลี่ยน UI บ่อยเกินไป
- การเปลี่ยนตัวควบคุมฟอร์มอย่างไม่ระวังมักแก้ปัญหาเดิมได้ พร้อมกับสร้างปัญหาใหม่เพิ่มเข้ามาแทบทุกครั้ง
- หากเปลี่ยนเลย์เอาต์และอินเทอร์เฟซของเว็บไซต์ทุกไม่กี่เดือน แม้ผู้ใช้บางส่วนจะปรับตัวได้ แต่ผู้ใช้สูงอายุอาจต้องเผชิญภาระเหมือนต้องเรียนรู้เครื่องมือใหม่ทุกครั้ง
- เมื่อหลายเว็บไซต์เปลี่ยนอินเทอร์เฟซอยู่เรื่อย ๆ ผู้ใช้ก็ต้องเสียเวลาอย่างมากไปกับการเรียนรู้สิ่งที่เคยคุ้นใหม่อีกครั้ง โดยแทบไม่ได้ประโยชน์เชิงหน้าที่เพิ่มขึ้น
- การจัดวาง UI ใหม่ซ้ำ ๆ เป็นประสบการณ์ที่น่าหงุดหงิด คล้ายกับสถานการณ์ที่ Linux distribution ออกแบบคำสั่งหลักและตัวเลือกบรรทัดคำสั่งใหม่ทั้งหมดทุกไม่กี่เดือน หรือปุ่มบนเครื่องซักผ้าเปลี่ยนตำแหน่งทุกเช้า
- เว็บ UI เป็นเครื่องมือที่ผู้ใช้ใช้เพื่อทำงานให้เสร็จ จึงควรหลีกเลี่ยงการแทนที่พฤติกรรมที่คุ้นเคยและเสถียร ซึ่งเบราว์เซอร์มีให้อยู่แล้วโดยไม่จำเป็น
2 ความคิดเห็น
ดูเหมือนว่าจะไม่มีประเทศไหนที่มีระบบเข้ารหัสและโปรแกรมความปลอดภัยที่พัฒนาขึ้นเองมากเท่าประเทศเราแล้วนะครับ
ความคิดเห็นจาก Lobste.rs
เห็นด้วยว่าไม่ควรทำ การเลื่อนหน้า ขึ้นมาเอง เพราะทำได้ไม่ดีเท่าของเนทีฟอยู่แล้ว และกรณีที่พอจะยกเว้นได้ก็คงมีแค่กรณีที่การเลื่อนถูกแมปเป็นการซูมตามธรรมเนียม เช่น แผนที่
แต่คัดค้านอย่างมากกับการยกเรื่องห้ามทำลิงก์นำทางเองให้เป็น กฎ ถ้าเป็นเว็บไซต์คอนเทนต์ทั่วไปก็คงไม่แนะนำ client-side routing (CSR) แต่สำหรับบางแอปกลับอาจแนะนำอย่างจริงจังได้ และบริการอย่าง GitHub ก็อยู่กึ่งกลางระหว่างสองแบบ
อย่างไรก็ตาม ควรใช้ element `` จริงเสมอเพื่อให้ฟีเจอร์เนทีฟของเบราว์เซอร์ทำงานได้ แอปอย่างเว็บเมลไคลเอนต์เหมาะกับการใช้ CSR และ GitHub เองก็เคยดีขึ้นตอนใช้อย่างเบา ๆ ในอดีต แต่แนวทางฝั่งฟรอนต์เอนด์ช่วงหลังค่อนข้างแย่ลงมาก
ปัญหาคือ CSR มักถูกทำแบบลวก ๆ บ่อยเกินไป และไม่ทำให้ทนทานต่อสภาพเครือข่ายที่แย่ ในขณะที่เบราว์เซอร์แข็งแรงกับสถานการณ์แบบนี้กว่า และการปรับแต่งอย่างตัวบอกสถานะการโหลดแท็บหรือ bfcache ก็อาจถูก CSR ขัดขวางได้
การทำการเลือกข้อความขึ้นมาเองพอจะยกเว้นได้แค่กรณีพิเศษมาก ๆ อย่างแอปจดคำอธิบายประกอบบนมือถือที่ใช้นิ้วเหมือนปากกาไฮไลต์ อันที่จริงอยากเสริมด้วยว่าอย่าใช้
::selectionเลยด้วยซ้ำ การที่แค่เติม::selection{}ลงในสไตล์ชีตก็ทำให้มองไม่เห็นพื้นที่ที่ถูกเลือกได้ ถือเป็นการออกแบบที่แย่ไม่เห็นด้วยกับการห้ามทำเมนูคลิกขวาเอง แอปอย่างไคลเอนต์อีเมล ตัวจัดการไฟล์ หรือโปรแกรมประมวลผลคำ จำเป็นต้องมีรายการคำสั่งของตัวเอง และเพราะเบราว์เซอร์ไม่มีวิธีให้ขยายเมนูเดิมได้ เมนูคัสตอมเต็มรูปแบบจึงเป็น ทางเลือกที่ใช้งานได้จริง ในตอนนี้ โชคดีที่บน Firefox สามารถกด Shift+คลิกขวาเพื่อบังคับเปิดเมนูเนทีฟได้
ส่วนการห้ามทำคัดลอก/วางเอง จะเห็นด้วยหรือไม่เห็นด้วยก็ขึ้นอยู่กับการตีความ จึงควรอธิบายให้ชัดกว่านี้
แทบจำไม่ได้เลยว่าเคยเห็นกรณีทำช่องรหัสผ่านขึ้นมาเองนอกเหนือจากเดโมทางเทคนิค การมีปุ่มแสดง/ซ่อนแล้วเปลี่ยน `` จาก
passwordเป็นtextไม่น่าจะนับว่าเข้าข่ายนี้และก็ไม่เห็นด้วยกับการบอกว่าอย่าทำตัวเลือกวันที่เอง อยากแนะนำให้ใช้คอนโทรลเนทีฟ แต่ข้อจำกัดและความไม่สอดคล้องมีมาก และช่วง 10 ปีที่ผ่านมาก็แทบไม่มีใครสนใจแก้ไข คุณไม่สามารถใส่ข้อมูลเพิ่มเติมลงในตัวเลือกได้ และการเลือกวันที่เก่า ๆ เช่น วันเกิด บนบางแพลตฟอร์มนั้นแย่มาก ตัวอย่าง: Safari's date-picker is the cause of 1/3 of our customer support issues
ตัวเลือกวันที่แบบคัสตอมมีปัญหาเรื่องการเข้าถึงเยอะ แต่บ่อยครั้งก็ยังดีกว่าสำหรับผู้ใช้ทั่วไป และหลายครั้งก็ใช้คอนโทรลเนทีฟไม่ได้เพราะต้องการความสามารถที่ไม่มีอยู่ในนั้น สำหรับการเลือกวันธรรมดา ผมชอบแบบเนทีฟเพราะในเบราว์เซอร์ที่ผมใช้สามารถพิมพ์ตรงได้ แต่สำหรับผู้ใช้จำนวนมาก แบบเนทีฟยังไม่ดีพอ ช่วงวันที่ถ้าทำด้วย `` สองตัว มีโอกาสสูงว่าจะทำให้ประสบการณ์แย่ลงมากสำหรับคนส่วนใหญ่
คำพูดที่ตั้งผู้ที่ต้องคำนึงถึงการเข้าถึงหรือผู้ที่ได้ประโยชน์จากมันให้ตรงข้ามกับ “คนทั่วไป” มักทำให้ผู้อ่านบางส่วนรู้สึกถูกกันออกไป ดูเหมือนคุณจะใส่ใจประสบการณ์และความต้องการของคนที่ใช้เครื่องมือช่วยการเข้าถึงอยู่พอสมควร เลยอยากทักเรื่องนี้เป็นพิเศษ
พอลองใช้ตัวเลือกวันที่ของ Safari เองแล้วก็เข้าใจว่ามันจำกัดแค่ไหน แต่ก็สงสัยมาตลอดว่าทำไมเว็บไซต์ต่าง ๆ ถึงแทนที่ตัวเลือกวันที่เนทีฟด้วย วิดเจ็ตปฏิทิน
มันเอาวิดเจ็ตปฏิทินไปวางคู่กับวิดเจ็ตเนทีฟไม่ได้หรือ? จริงอยู่ที่อาจทำให้ UI ดูเหมือนมีวิธีป้อนข้อมูลสองแบบจนสับสนได้ แต่ถ้าติดป้ายกำกับให้เหมาะสมแล้วระบุว่าอันหนึ่งเป็นตัวเลือกวันที่แบบขั้นสูง ก็น่าจะหาทางแก้ได้ แบบนั้นคนที่ใช้ตัวเลือกวันที่เนทีฟได้สะดวกก็ไม่เสียประโยชน์ ส่วนคนที่ตัวเลือกวันที่ของเบราว์เซอร์ไม่พอก็ยังได้รับความช่วยเหลือ
เข้าใจว่าเว็บแอปอย่างเครื่องมือเขียนเอกสารหรือโปรแกรมวาดไดอะแกรมต้องการเมนูคลิกขวา แต่พอคลิกขวาแล้วเมนูทั่วไปของเบราว์เซอร์หายไปก็ยังรำคาญอยู่ดี เพราะงั้นใน Firefox ผมมักตั้ง
dom.event.contextmenu.enabled = falseไว้ แบบนั้นเมนูของ Firefox จะขึ้นด้านบนและเมนูของเว็บแอปจะตามมาทีหลัง แต่เมนูเนทีฟยังทำงานได้ จึงเป็นทางเลี่ยงที่ใช้ได้ ถ้าเป็นไปได้ควรใช้แถบเมนูของเว็บแอปและไม่ไปยุ่งกับเมนูคลิกขวาเนทีฟของเบราว์เซอร์จะดีกว่า ส่วนทริก Shift+คลิกขวาก็เป็นทางออกที่ดีคนที่ต้องใช้คอนโทรลที่เข้าถึงได้ก็เป็น คนปกติ เหมือนกัน
เคยเห็นการทำช่องรหัสผ่านขึ้นมาเองแทบทุกธนาคารในเปรู
ส่วนตัวเลือกวันที่นั้นอยากใช้แบบเนทีฟ แต่ดูเหมือนฝั่งผู้พัฒนาจะไม่ค่อยสนใจปรับปรุง Firefox มี issue เรื่อง UI สำหรับเลือกเวลา/นาฬิกา และความคืบหน้าก็ช้ามาก: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime
สำหรับเว็บฟอร์มถือว่าเป็นข้อสังเกตที่ดี การพึ่งเบราว์เซอร์เป็นวิธีที่ง่ายที่สุด เร็วที่สุด และแทบจะสม่ำเสมอที่สุดเสมอ
แต่ฝั่ง โค้ดเข้ารหัสลับ นั้นต่างออกไป การเขียนโค้ดคริปโตให้ถูกต้องไม่ใช่เรื่องง่าย แต่ก็ ไม่ใช่ว่าเป็นไปไม่ได้ ในบางสถานการณ์ตัวเลือกมีน้อยมากจนการทำเองอาจเป็นทางที่ดีที่สุด
ปัญหาของ สายฮาร์ดคอร์ด้านความปลอดภัย ในที่นี้คือมักตั้งต้นว่าถ้าจะเขียนโค้ดคริปโตใหม่ คุณต้องเป็นคนในกลุ่มวงในของพวกเขาเท่านั้น ถ้าไม่มีปริญญาเอกด้านคริปโตหรือไม่เคยฝึกงานกับ DJB หรือ Dan Boneh ก็เหมือนถูกบอกว่าห้ามแตะโค้ดคริปโต ทำเล่น “เพื่อการเรียนรู้” ได้ แต่พอจะเอาความรู้นั้นไปใช้จริงกลับไม่ได้ บางครั้งพวกเขายังดูไม่ค่อยสามารถประเมินความสามารถจริงของคนนอกกลุ่มได้ด้วย ที่น่าสนใจคือดูเหมือนคนกลุ่มนี้กับนักวิชาการด้านคริปโตตัวจริงที่ตีพิมพ์งานวิจัยจะทับซ้อนกันน้อยมาก
ตอนนี้ยังขยายไปถึงขั้นบอกว่าอย่าเขียนอะไรด้วยภาษาที่ไม่ memory-safe เลย แม้ว่าช่องโหว่ร้ายแรง 70% จะมาจากเรื่องนั้น แต่สาเหตุจริงคืออะไร? ผมเดาว่าปัญหาส่วนใหญ่คงมาจากการใช้
malloc()หรือnewแบบระบุชัดกับออบเจ็กต์เล็ก ๆ ทุกตัวที่ไม่ได้อยู่บนสแตก หรือจากการจัดการสตริงแบบ null-terminated ถ้าใช้ arena กับ slice ปัญหาแบบนั้นก็น่าจะน้อยกว่ามาก แน่นอนว่าในบางสถานการณ์ความเสี่ยงสูง เราจำเป็นต้องกำจัดบั๊กบางประเภทออกไปให้สิ้นเชิง และตอนนั้น memory safety ก็ต้องมาก่อนถัดไปจะเป็นการบอกว่าอย่าเขียนอะไรที่ต้องจัดการ input ที่ไม่น่าเชื่อถือเลยหรือ? หรือจะห้ามประดิษฐ์ล้อใหม่ทั้งที่ล้อที่มีอยู่ทั้งหมดเป็นสี่เหลี่ยม? ถึงอย่างนั้น ถ้าคุณหลีกเลี่ยงความเทอะทะของ JavaScript และใช้ฟอร์มที่เบราว์เซอร์มีให้ ผมก็คงไม่ถือสาหรอกถ้าจะไปทำเว็บเฟรมเวิร์กของตัวเอง
ผมว่าบาปดั้งเดิมของ C อยู่ที่เวลาส่งอาร์เรย์แล้ว ข้อมูลขอบเขต หายไปและยุบเหลือแค่พอยน์เตอร์
ผมเข้าใจคำว่า “อย่าทำคริปโตเอง” ว่าเป็นคำเตือนแรง ๆ ไม่ใช่คำประกาศสัมบูรณ์ จริงอยู่ว่าไม่ต้องมีปริญญาเอกก็อิมพลีเมนต์ได้อย่างปลอดภัย แต่ก็ยังต้องเรียนรู้อีกมหาศาล
ถ้าแค่ทำตามสเปกอย่างระมัดระวังก็อาจต้องรู้น้อยกว่านั้นมาก แต่ซอฟต์แวร์ส่วนใหญ่อยากได้คริปโตที่ทำงานเร็ว และพอเป็นแบบนั้นความซับซ้อนก็พุ่งขึ้นมาก ช่องโหว่ Monocypher ที่ลิงก์ไว้ก็เป็นตัวอย่างที่ดี อยู่ ๆ ก็ต้องเข้าใจว่า birational equivalence เชื่อมกับ Edwards point และ Montgomery ladder อย่างไร
คุณสมบัติอย่างปริญญาเอกช่วยให้คนอื่นเชื่อมั่นว่าคุณรู้ว่ากำลังทำอะไร การตรวจสอบโดยผู้สอบบัญชีก็เป็นอีกเส้นทางหนึ่ง ดูเหมือน Monocypher จะผ่านการตรวจสอบโดยคนจาก Cure53 ที่มีปริญญาเอกสองคน ปัญหาคือโปรแกรมเมอร์ส่วนใหญ่ยังไม่พร้อมจะตัดสินได้ว่าไลบรารีคริปโตปลอดภัยหรือไม่ จึงต้องพึ่งสัญญาณที่ไม่ใช่เชิงเทคนิค เช่น คุณวุฒิหรือคุณวุฒิของผู้ตรวจสอบ ถ้ามีวิธีที่ตรงกว่านี้ก็คงดี แต่คุณวุฒิก็ทำงานได้ค่อนข้างดี
การเขียนคริปโตเอง “ทำได้” นั้นแน่นอนอยู่แล้ว ถ้ามันทำไม่ได้ก็คงไม่มีไลบรารีคริปโต ประเด็นไม่ใช่ว่าทำได้ไหม แต่คือเราจะเชื่อถือคริปโตที่คุณหรือผมเขียนเองด้วยมือใน สภาพแวดล้อมการใช้งานจริง ที่ใช้แฮชรหัสผ่านผู้ใช้และปกป้องข้อมูลส่วนตัวได้หรือไม่ สำหรับผม คำตอบคือไม่
ที่ทำงานเก่าของผมมีโค้ดเก่าที่ใช้ MD5 ตรวจสอบไลเซนส์ และต้องตรวจสอบในสภาพแวดล้อมที่รัน C++ เก่า ๆ นั้นไม่ได้ จึงจำเป็นต้อง อิมพลีเมนต์ MD5 ใหม่ เอง เคยหาไลบรารีที่มีอยู่แล้ว แต่ไม่มีตัวไหนรองรับการเปลี่ยน IV
ผมไม่กล้าพอจะทำคริปโตเอง แต่ก็รู้สึกว่าอุตสาหกรรมความปลอดภัยตอนนี้เริ่มเลยเถิดไปถึงขั้นบอกว่าอย่าทำแม้แต่การยืนยันตัวตนเองด้วย
คงดีถ้าเบราว์เซอร์มี ฟิลด์เลือกหลายค่า ที่ใช้งานได้จริงโดยไม่ต้องทำเอง
การใช้ `` สองตัวเพื่อรับวันเริ่มต้นกับวันสิ้นสุดนั้นทั้งยุ่งยากและไม่ค่อยเป็นธรรมชาติสำหรับช่วงวันที่ มันบังคับให้แยกสิ่งที่ตามแนวคิดเป็นของชิ้นเดียว ออกเป็นสองมุมมองแยกที่ดูไม่เกี่ยวกันทางสายตา
การไม่มีช่วงวันที่เป็นแค่หนึ่งในหลายปัญหาของ `` ตัวอย่างเช่นคุณไม่สามารถยกเว้นบางวันได้ ทำให้แทบใช้ไม่ได้ตั้งแต่ต้นในเกือบทุกกรณีที่เป็นบริการจอง
ผมไม่แน่ใจว่าจุดยืนที่ว่าเราควรยอมจ่ายต้นทุนเล็กน้อยด้วยการใช้ input สองช่อง เพื่อให้ใช้วันที่แบบเดียวกันได้ทุกที่จะเป็นความเห็นของคนส่วนใหญ่หรือเปล่า ผู้ใช้ทั่วไปไม่ชอบฟิลด์อยู่แล้ว และอะไรที่แย่กว่าหนึ่งฟิลด์ก็คือสองฟิลด์ ส่วนเหตุผลเรื่องความคุ้นเคยก็ดูไม่น่าโน้มน้าวนัก จากประสบการณ์ของผม date input แบบเนทีฟบนเว็บนั้นพบได้น้อย
ผมเคยเห็นหลายเว็บไซต์ที่เอา วิดเจ็ตปฏิทินคัสตอม ที่ทำงานไม่ถูกต้องมาติดสองตัวสำหรับวันเริ่มและวันสิ้นสุดของช่วงวันที่ ซ้ำร้ายเข้าไปอีก
ผมก็ไม่เห็นด้วยกับส่วนเรื่องช่วงวันที่เหมือนกัน ช่วงวันที่เป็นคอนโทรลเดียวในเชิงแนวคิด แต่ก็มักถูกใช้เป็นตัวอย่างว่าของที่ดูเหมือนง่ายนั้นซับซ้อนได้แค่ไหน คำขวัญว่า “ใช้คอนโทรลเนทีฟเสมอ” อาจทำให้ประสบการณ์ผู้ใช้แย่ลงแทน เมื่อคุณสามารถให้คอนโทรลที่ดีกว่าและเหมาะกับปัญหามากกว่าได้
ฟีเจอร์ที่มีประโยชน์ของคอนโทรลวันที่/ช่วงวันที่ที่คอนโทรลเนทีฟทำไม่ได้คือ การแสดงราคา เวลาเลือกตั๋วเครื่องบินหรือโรงแรม การเห็นเลยว่าวันไหนถูกหรือแพงกว่ากันในตัวเลือกวันที่นั้นมีประโยชน์มาก ถ้าเป็นคอนโทรลเนทีฟ คุณอาจต้องคลิกเพิ่มอีกเยอะหรือไปดูตารางแยก แต่คอนโทรลคัสตอมสามารถใส่ metadata พวกนั้นไว้กับแต่ละวันได้
อีกตัวอย่างคลาสสิกคือการกรอกวันเกิด ตัวเลือกวันที่มักแสดงเดือนปัจจุบันเป็นค่าเริ่มต้น ซึ่งแทบไม่เกี่ยวอะไรกับวันที่ที่ต้องการเลยจึงแย่มาก กรณีนี้อาจใช้คอนโทรลคัสตอม หรือบ่อยครั้งชุดของกล่องข้อความอาจดีกว่า มันไม่ใช่คอนโทรลที่ทำเองทั้งหมดเสียทีเดียว แต่เป็นการผสมคอนโทรลเนทีฟ และประเด็นคือไม่มีตัวเลือกวันที่แบบ “อันเดียวใช้ได้ทุกอย่าง” ที่รับมือทุกกรณีได้ดี
เป็นเรื่องเมื่อหลายปีก่อนเลยต้องกลับไปเช็กอีกที แต่มีเหตุผลน่าเศร้าที่ทำให้ต้องทำเองแทน html5 date picker บางเบราว์เซอร์มี UI ของ `` ที่แย่มากจริง ๆ
การทำเมนูคลิกขวาเองพบไม่บ่อย แต่เวลาจำเป็นก็มีประโยชน์มาก ตัวอย่างเช่นถ้าทำโปรแกรมแก้ไขไดอะแกรมในหน้าเว็บ ผมอยากให้มี เมนูคลิกขวาแบบคัสตอม เพื่อกดที่โหนดในไดอะแกรมแล้วทำคำสั่งที่มีประโยชน์ได้ การโยนทุกปฏิสัมพันธ์ไปไว้ใน UI แบบคลิกซ้าย เช่น ต้องสลับไปคลิกพาเลตคำสั่งกับคลิกโหนดไปมา อย่างเดียวนั้นไม่ดี
สำหรับรายการที่เหลือในลิสต์ ผมเห็นด้วยอย่างมาก
ผมไม่แน่ใจว่าจะตีความตัวอย่างเรื่องคริปโตกับปัญหาพฤติกรรมการเลื่อนให้อยู่ด้วยกันอย่างไร มันให้ความรู้สึกว่าเป็นคนละโดเมนกันมาก
แต่ก็เห็นด้วยกับข้อสรุปกว้าง ๆ ว่าเว็บไซต์พยายามทำอะไรเยอะเกินไป เพียงแต่ว่าพฤติกรรมที่เหมาะสมก็ควรขึ้นกับเป้าหมายของผู้ใช้และของเว็บไซต์
บางทีการมีค่าตั้งอย่าง
prefers-user-scrollคล้าย prefers-reduced-motion อาจเป็นทางออกตรงกลางได้ไหม?ไม่มี use case ที่สมเหตุสมผลสำหรับการใช้ scrolljacking เพื่อทำพื้นที่เลื่อนแนวตั้ง โค้ดแบบนั้นไม่ควรถูกเขียนขึ้นมาตั้งแต่แรก
อย่างไรก็ดี คำพูดนี้จำกัดอยู่แค่พื้นที่เลื่อนแนวตั้งเท่านั้น ถ้าเป็นการแมปการเลื่อนไปเป็นพฤติกรรมที่ไม่ใช่การเลื่อนก็มี use case อยู่ และถึงจะยังมีปัญหามาก แต่กรณีระบบอักษรแนวตั้งที่แมปการเลื่อนแนวตั้งไปเป็นแนวนอนก็พอคุยกันได้ นอกจากนี้อาจมี use case ที่ชอบธรรมอีกสักหนึ่งหรือสองแบบ แต่ในโลกจริงวิธีที่อิมพลีเมนต์กันก็มักยังผิดอยู่ดี
เห็นด้วยอย่างมากกับ การห้ามทำการเลื่อนหน้าขึ้นมาเอง ผมเคยฟังบรรยายที่น่าสนใจใน KotlinConf ว่าด้วยความยากของการทำการเลื่อนใน Compose Multiplatform for Web
ปัญหาอย่างหนึ่งคือเว็บเบราว์เซอร์ส่ง scroll event น้อยกว่าแอปเนทีฟ ทำให้อัลกอริทึมคำนวณทิศทางการเลื่อนล้มเหลว วิธีนั้นคือวาดพาราโบลาผ่านทุกจุดแล้วใช้ความชันที่จุดสุดท้าย แต่ถ้ามีจุดน้อยเกินไป ทิศทางการเลื่อนอาจกลับด้านได้
เวลาพอร์ตจากแพลตฟอร์มอื่นหรืออิมพลีเมนต์ปฏิสัมพันธ์แบบนี้ขึ้นมาใหม่ มักเริ่มจากสมมติฐานที่ผิด หรือเผลอลืมพฤติกรรม “ประหลาด” ที่เบราว์เซอร์มีให้เป็นค่าเริ่มต้น
คำแนะนำแบบ “พึ่งพาแพลตฟอร์ม” นั้นถูกต้อง แต่การ ตามแพลตฟอร์มให้ทันตลอด เป็นเรื่องยาก มีหลายอย่างอย่าง
enterkeyhintหรือinputmodeที่เหมือนจะพอรู้ว่ามีอยู่ แต่ก็มักลืมไปว่ามันช่วยอะไรได้บ้างสัปดาห์นี้ทีมของเราเพิ่งปล่อย [0] เพื่อช่วยเรื่องนี้ โดยให้ best practice ของการอิมพลีเมนต์ในรูปแบบสกิล และเอกสารก็อ่านโดยมนุษย์ได้ค่อนข้างดี ตัวอย่าง: [1]
[0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…
น้ำเสียงของบทความเพี้ยนไปนิด ทางที่ได้ผลกว่ามากคืออธิบายให้คนเข้าใจอย่างเพียงพอว่าเมื่อไรและเพราะอะไรพวกเขา ไม่จำเป็นต้องประดิษฐ์ล้อใหม่
บทความอธิบายเหตุผลได้ดี แต่แย่ลงเพราะใช้สำนวนแบบเด็ดขาดว่า “อย่าทำเอง”
แม้แต่คำขวัญ “อย่าทำคริปโตเอง” เองก็สุดท้ายให้ความรู้สึกเหมือนหลักคำสอน ใครกันคือผู้เชี่ยวชาญที่ใช้มันได้ และใครเป็นคนแต่งตั้งพวกเขา? ก่อนพูดแบบนั้นพวกเขาเคยเปิดดูโค้ดเองจริงไหม? พอดูช่องโหว่อย่าง Heartbleed ก็ไม่ใช่ว่าที่จริงมันเป็นแค่ความผิดพลาดพื้นฐานมาก ๆ หรอกหรือ?
พวกเขาคือคนที่อุทิศชีวิตให้กับวิชาคริปโต ไม่มีใครแต่งตั้ง แต่พวกเขาได้ความน่าเชื่อถือมาจากการเผยแพร่งานวิจัยที่มีประโยชน์และผ่านการตรวจสอบจากคนที่รู้เรื่องในสาขานั้น
อัลกอริทึมถูกเปิดเผย ถูกตรวจสอบ ถูกโจมตีในที่สาธารณะ ถูกปรับปรุง และถูกทำให้เป็นมาตรฐาน มันไม่ใช่เรื่องที่ทำกันหลังประตูปิด งานวิจัยก็เปิดเผย โค้ดก็เปิดเผย คุณเข้าไปดูได้ทุกเมื่อ การที่คุณไม่ได้ดูไม่ได้แปลว่าไม่มีใครดู คนเขาดูและพยายามเจาะมันอยู่ เราใช้มันก็เพราะมัน ทนการโจมตีมาแล้ว
ถ้าทางออกที่คุณได้จากการเห็น Heartbleed คือไปอิมพลีเมนต์ OpenSSL ใหม่เอง ผมรับประกันได้เลยว่า OpenSSL ที่คุณทำจะมี Heartbleed อยู่ห้าสิบจุดต่อทุกหนึ่งจุดใน OpenSSL จริง ความต่างคือ OpenSSL จริงมีคนที่รู้เรื่องคอยตรวจสอบ ทดสอบ ตรวจประเมิน โจมตี และแก้ไข ของคุณจะยังผิดอยู่เงียบ ๆ แบบไม่เปิดเผยเท่านั้น
ประเด็นสำคัญไม่ใช่ว่ามีผู้เชี่ยวชาญที่สมบูรณ์แบบซึ่งเรียก AES ได้อย่างไร้ความเสี่ยง แต่คือถ้าใช้แรปเปอร์ยอดนิยมที่ทำงานได้ปลอดภัย ต่อให้มีบั๊กก็สามารถถูกพบและแก้ได้ที่จุดเดียว
ต่อให้มีการค้นพบ side-channel attack แบบใหม่ ก็รับมือได้จากจุดเดียว ของที่คุณทำเองจะไม่ได้รับการปรับปรุงแบบนั้น เว้นแต่คุณจะทุ่มเวลาเต็มตัวไปคอยตามการโจมตีใหม่ ๆ อยู่ตลอด
นี่ดูเหมือนเป็นการบ่นคนที่ใช้เครื่องมือเว็บได้แย่มากกว่า ถ้าพูดถึง use case ที่การทำเองนั้นสมเหตุสมผลด้วยก็น่าจะน่าสนใจกว่านี้ แบบนั้นผู้อ่านจะได้เรียนรู้อะไรที่มีประโยชน์ แทนที่จะได้โมเดลแบบเด็ก ๆ ว่า “ห้ามทำเองเด็ดขาด”
ความชำนาญคือการมีทั้งความรู้และทักษะในการทำขึ้นมาเอง และมีปัญญารู้ว่าเมื่อไรไม่ควรทำแบบนั้น
ถึงอย่างนั้นผมก็เข้าใจความไม่พอใจนะ ผมเองก็เคยหงุดหงิดคล้าย ๆ กัน ปัญหาคือที่ผ่านมาแทบไม่มีความพยายามจะบันทึกปฏิสัมพันธ์บนเว็บให้ละเอียดและครอบคลุมพอที่นักพัฒนาเว็บจะอ้างอิงได้ง่าย มีปัญหาร้ายแรงว่าความรู้ที่อยู่ข้างเคียงการเขียนโปรแกรมไม่ได้ถูกบันทึกและส่งต่อไปยังคนรุ่นถัดไปอย่างเหมาะสม ทำให้เราต้องกลับไปค้นพบปัญหาเดิมซ้ำแล้วซ้ำอีก ปกติแล้วในอุตสาหกรรม ชุดพฤติกรรมและปฏิสัมพันธ์มาตรฐานบางอย่างจะกลายเป็นผู้ชนะ แต่ก็ไม่มีใครเขียนมันเก็บไว้