Đừng tự làm lấy …

• Nguyên tắc Don't Roll Your Own ... không chỉ áp dụng cho mã hóa mà còn cho cả web UI, và không nên thay thế một cách không cần thiết những chức năng mà trình duyệt vốn đã cung cấp ổn định
• Việc thay thế các hành vi mặc định như cuộn tự làm, xử lý liên kết, chọn văn bản, sao chép·dán sẽ phá vỡ phản hồi nhập liệu quen thuộc, khiến người dùng phải lại chú ý đến cách thao tác
• Giống như các liên kết file·issue trên GitHub, khi JavaScript chặn điều hướng liên kết, đôi khi mở trong tab mới còn nhanh hơn chờ nó được xử lý ở tab hiện tại
• Trường mật khẩu mặc định và <input type="date"> phối hợp với tự động điền, trình quản lý mật khẩu, công cụ trợ năng và bàn phím di động, nên nếu thay bằng UI giả thì chức năng có thể bị hỏng
• Bố cục và các điều khiển biểu mẫu thay đổi vài tháng một lần khiến người dùng phải dành thời gian học lại thay vì làm việc, vì vậy nên giữ các hành vi mặc định ổn định của trình duyệt

---

Áp dụng nguyên tắc “đừng tự làm lấy” cho web UI

• Không tự triển khai mã hóa là nguyên tắc nói rằng trong phần mềm vận hành bảo vệ dữ liệu nhạy cảm, không nên phụ thuộc vào các triển khai riêng chưa được kiểm chứng
• Điều đó không có nghĩa là không ai được viết mã mã hóa, mà gần hơn với ý rằng nên dùng các gói và công cụ đã được rà soát, kiểm chứng bất cứ khi nào có thể
• Khoảng 20 năm trước, thực sự từng tồn tại các bản tự triển khai RC4 với những vấn đề như vector khởi tạo không phù hợp, keystream có thể dự đoán, hoặc làm lộ một phần bản rõ
• Hiện nay các trang thương mại điện tử lớn hay ngân hàng nhìn chung không dùng mã hóa tự làm cho dịch vụ web, và trong các lĩnh vực bị quản lý như thanh toán, y tế hay xử lý dữ liệu cá nhân, vi phạm yêu cầu mã hóa mạnh có thể dẫn đến các khoản phạt lớn
• Thiết kế website không giống mã hóa, nhưng nếu tái triển khai những chức năng mà trình duyệt đã xử lý tốt và người dùng dựa vào hằng ngày thì trải nghiệm người dùng có thể tệ đi

Vấn đề phát sinh khi thay thế chức năng mặc định của trình duyệt

• Nếu tự triển khai cuộn trang, phản hồi quen thuộc với chuột, touchpad và bàn phím có thể bị phá vỡ
• Khi ghi đè hành vi cuộn mặc định, trang có thể di chuyển quá chậm hoặc quá nhanh, và cuộn bằng bàn phím cũng có thể không hoạt động
• Khi những thao tác người dùng vốn dùng một cách vô thức bị đổi thành hành vi lạ, họ sẽ phải lại chú ý đến chính việc điều khiển trang
• Những chức năng tiêu biểu không nên tự triển khai gồm điều hướng liên kết, chọn văn bản, menu ngữ cảnh, sao chép·dán, trường mật khẩu và bộ chọn ngày
• Khi thêm các tính năng giao diện người dùng vào website phục vụ công việc nghiêm túc, cần thận trọng quyết định nên thêm tính năng hào nhoáng hay giao cho hành vi mặc định của trình duyệt

Điều hướng liên kết và trường hợp của GitHub

• Trình duyệt web vốn đã xử lý tốt việc đi theo liên kết, và điều hướng liên kết là một chức năng cốt lõi của trình duyệt
• Nếu cảm thấy cần phải can thiệp vào hành vi liên kết bình thường, nên xem lại liệu mục tiêu muốn đạt có thật sự quan trọng đến mức đáng phá vỡ điều hướng liên kết thông thường hay không
• Trên GitHub, khi nhấp vào liên kết file hoặc liên kết issue, một chức năng lớn được triển khai bằng JavaScript sẽ thay thế việc xử lý cú nhấp
• Trong Firefox hoặc Chrome, có thể xác nhận hành vi này bằng cách mở công cụ phát triển bằng F12, rồi trong Event Listener Breakpoints ở tab Debugger hoặc Sources, chọn click trong mục Mouse và sau đó nhấp vào liên kết GitHub
• Trên GitHub, đôi khi mở liên kết trong tab mới còn nhanh hơn chờ quá trình điều hướng bằng JavaScript của tab hiện tại xử lý xong

Nhập mật khẩu và bộ chọn ngày

• Trường nhập mật khẩu của trình duyệt có thể cung cấp các chức năng lưu mật khẩu, tự động điền và tạo mật khẩu mạnh cho tài khoản mới
• Trường mật khẩu mặc định sẽ cảnh báo khi mật khẩu được gửi qua kết nối HTTP không an toàn, đồng thời cũng phối hợp với trình quản lý mật khẩu, tự động điền, bàn phím di động và công cụ trợ năng
• Nếu thay bằng trường mật khẩu giả, các chức năng này có thể bị hỏng; còn nếu tự che ký tự trong trường văn bản thuần, trình duyệt·hệ điều hành·công cụ hỗ trợ có thể xử lý mật khẩu như văn bản hiển thị thông thường
• <input type="date"> không trực tiếp hỗ trợ chọn khoảng ngày, nhưng nếu cung cấp hai trường nhập ngày bắt đầu và ngày kết thúc thì vẫn có thể giữ bộ chọn ngày mặc định của trình duyệt
• Bộ chọn ngày tùy biến khác nhau theo từng cách triển khai: có khi phải phóng ra chế độ xem năm, có khi phải bấm nút lùi năm hàng chục lần để chọn năm sinh, hoặc có khi bị chặn nhập ngày trực tiếp
• Nếu cần widget lịch cho các trình duyệt hỗ trợ bộ chọn ngày mặc định chưa tốt, tốt hơn là thêm nó như một widget bổ trợ thao tác trên cùng trường <input type="date"> thay vì thay thế trường này

Cái giá của việc thay đổi UI quá thường xuyên

• Việc tùy tiện thay đổi các điều khiển biểu mẫu gần như luôn giải quyết vấn đề cũ đồng thời tạo ra vấn đề mới
• Nếu thay đổi bố cục và giao diện website vài tháng một lần, một số người dùng có thể thích nghi, nhưng người dùng lớn tuổi sẽ phải gánh áp lực như học một công cụ mới mỗi lần
• Khi nhiều website liên tục thay đổi giao diện, người dùng sẽ phải dành đáng kể thời gian để học lại những thứ quen thuộc mà không thu được lợi ích chức năng rõ ràng
• Giống như việc một bản phân phối Linux cứ vài tháng lại thiết kế lại toàn bộ các lệnh cốt lõi và tùy chọn dòng lệnh, hay cách bố trí nút trên máy giặt thay đổi mỗi sáng, việc xáo trộn UI lặp đi lặp lại tạo ra trải nghiệm khó chịu
• Web UI là công cụ người dùng dùng để hoàn thành công việc, vì vậy tốt hơn là không thay thế không cần thiết các hành vi quen thuộc và ổn định mà trình duyệt đã cung cấp

[kirinonakar]

Có lẽ không có nhiều quốc gia như nước ta có quá nhiều chương trình mã hóa và bảo mật tự phát triển như vậy.

[GN⁺]

Ý kiến trên Lobste.rs

• Tôi đồng ý rằng không nên tự triển khai cuộn trang. Không thể làm tốt bằng native, và trường hợp ngoại lệ hiếm hoi có thể chấp nhận được chắc chỉ là những tình huống đã có thông lệ ánh xạ cuộn thành phóng to/thu nhỏ như bản đồ

  Tôi phản đối mạnh việc biến chuyện không tự triển khai điều hướng liên kết thành một quy tắc. Với các site nội dung thông thường thì tôi sẽ không khuyến khích định tuyến phía client (CSR), nhưng với một số ứng dụng thì ngược lại có thể nên tích cực khuyến khích, còn các dịch vụ như GitHub thì nằm đâu đó ở giữa

  Tuy vậy vẫn luôn phải dùng phần tử `` thực để các chức năng native của trình duyệt hoạt động. Những ứng dụng như webmail thì dùng CSR là hợp lý, và GitHub cũng từng được cải thiện khi áp dụng nhẹ nhàng như trước đây, nhưng cách tiếp cận frontend gần đây của họ khá tệ

  Vấn đề là CSR quá thường xuyên được triển khai cẩu thả và không được làm đủ vững để chịu được điều kiện mạng kém. Trình duyệt vốn mạnh ở các tình huống như vậy, còn những tối ưu như chỉ báo tải tab hay bfcache cũng có thể bị CSR cản trở

  Việc tự triển khai chọn văn bản thì chỉ có thể xem là ngoại lệ trong các trường hợp cực kỳ đặc thù như ứng dụng ghi chú trên di động dùng ngón tay như bút highlight. Thậm chí tôi còn muốn nói thêm là đừng dùng cả ::selection. Chỉ cần thêm ::selection{} vào stylesheet mà vùng được chọn lại không nhìn thấy được là một thiết kế tệ

  Tôi không đồng ý với việc cấm tự triển khai menu ngữ cảnh. Với các ứng dụng như client email, trình quản lý tệp hay trình xử lý văn bản thì cần các mục riêng của ứng dụng, mà trình duyệt lại không cung cấp cách mở rộng nên menu tùy biến hoàn toàn hiện giờ là một lựa chọn thực dụng. May là trên Firefox có thể dùng Shift+chuột phải để buộc mở menu native

  Việc cấm tự triển khai sao chép/dán thì tùy cách hiểu mà tôi có thể đồng ý hoặc phản đối, nên cần nói rõ hơn

  Tôi hầu như không nhớ đã từng thấy ai tự triển khai trường mật khẩu ngoài các bản demo kỹ thuật. Việc thêm nút hiện/ẩn để đổi `` từ password sang text thì theo tôi không tính vào đây

  Tôi cũng không đồng ý với ý rằng không nên tự làm bộ chọn ngày. Tôi muốn khuyến khích dùng control native, nhưng các giới hạn và sự thiếu nhất quán của nó quá lớn, và 10 năm qua gần như chẳng thấy ai mặn mà sửa chữa. Không thể bổ sung thông tin vào bộ chọn, còn thao tác chọn ngày từ rất lâu trước đây như ngày sinh thì trên một số nền tảng là ác mộng. Ví dụ: Safari's date-picker is the cause of 1/3 of our customer support issues

  Bộ chọn ngày tùy biến có rất nhiều vấn đề về khả năng truy cập, nhưng với người dùng thông thường thì nhiều khi lại tốt hơn, và cũng có nhiều trường hợp không thể dùng control native vì cần tính năng mà nó không có. Với chọn một ngày đơn lẻ thì trên trình duyệt tôi dùng có thể nhập trực tiếp nên tôi thích native hơn, nhưng với nhiều người dùng thì native không đủ tốt. Còn phạm vi ngày tháng mà làm bằng `` thì rất có thể sẽ tệ hơn nhiều đối với đa số người dùng

  • Khi nói về nhu cầu cân nhắc khả năng truy cập hoặc đối lập những người được hưởng lợi từ đó với “người bình thường”, cách diễn đạt này dễ khiến một số độc giả cảm thấy bị gạt ra ngoài. Có vẻ bạn thực sự quan tâm khá nhiều tới trải nghiệm và nhu cầu của người dùng công cụ hỗ trợ tiếp cận, nên tôi càng muốn nhắc điểm này

  • Tự mình dùng thử bộ chọn ngày của Safari rồi mới thấy nó hạn chế đến mức nào. Nhưng tôi vẫn luôn thắc mắc vì sao các website lại thay bộ chọn ngày native bằng widget lịch

    Liệu có thể đặt widget lịch bên cạnh widget native được không? Đúng là sẽ khiến UI trông như có hai cách nhập, nên có thể gây rối, nhưng nếu gắn nhãn hợp lý để một cái là bộ chọn ngày nâng cao thì có lẽ vẫn có cách giải quyết. Như vậy sẽ không làm mất đi nhóm người dùng thấy bộ chọn ngày native là tiện, đồng thời vẫn giúp được những ai thấy bộ chọn ngày của trình duyệt chưa đủ

    Tôi hiểu các webapp như công cụ soạn thảo tài liệu hay vẽ sơ đồ cần menu ngữ cảnh, nhưng khi bấm chuột phải mà menu thông thường của trình duyệt biến mất thì vẫn khó chịu. Vì vậy trong Firefox tôi thường để dom.event.contextmenu.enabled = false. Khi đó menu của Firefox hiện phía trên, menu của webapp hiện phía sau, nhưng menu native vẫn dùng được nên đây là một cách lách khá ổn. Nếu có thể thì nên dùng thanh menu của webapp, còn menu ngữ cảnh native của trình duyệt thì đừng đụng vào sẽ tốt hơn. Mẹo Shift+chuột phải cũng là một giải pháp hay

  • Những người cần control có khả năng truy cập cũng là người bình thường

  • Gần như mọi ngân hàng ở Peru đều có thể thấy ví dụ tự triển khai trường mật khẩu

    Tôi muốn dùng bộ chọn ngày native, nhưng phía những người triển khai có vẻ không mấy quan tâm đến việc cải thiện nó. Trên Firefox đang có issue liên quan đến UI chọn giờ/đồng hồ, và tiến độ rất chậm: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• Với biểu mẫu web thì đây là nhận xét rất đúng. Dựa vào trình duyệt là cách đơn giản nhất, nhanh nhất và gần như luôn nhất quán nhất

  Nhưng với mã mật mã học thì khác. Viết mã mật mã đúng không hề dễ, nhưng cũng không phải bất khả thi. Trong một số tình huống, số lựa chọn quá ít nên tự làm có thể là phương án tốt nhất

  Điều có vấn đề ở đây là giới chính thống bảo mật thường có xu hướng khẳng định rằng muốn viết mã mật mã mới thì phải thuộc về nhóm nội bộ của họ. Nếu bạn không có bằng tiến sĩ mật mã học hay từng thực tập dưới trướng DJB hoặc Dan Boneh thì không được viết mã mật mã, kiểu vậy. Họ bảo viết “để học” thì được, nhưng không được đem cái đã học áp dụng vào thực tế. Thậm chí đôi khi họ còn khó đánh giá năng lực thực sự của người ngoài nhóm. Điều thú vị là phần giao nhau giữa nhóm chính thống bảo mật này và các nhà mật mã học thực sự viết bài báo có vẻ rất nhỏ

  Giờ chuyện đó còn bị mở rộng thành đừng viết gì bằng ngôn ngữ không an toàn bộ nhớ nữa. Dù 70% lỗ hổng nghiêm trọng là như vậy đi nữa, thì nguyên nhân thật sự là gì? Theo tôi phần lớn vấn đề đến từ việc dùng malloc() hay new tường minh cho từng đối tượng nhỏ không nằm trên stack, hoặc xử lý chuỗi kết thúc bằng null. Nếu dùng arena và slice thì các vấn đề đó đã ít hơn nhiều. Tất nhiên trong một số kịch bản rủi ro cao thì phải loại bỏ hoàn toàn một lớp lỗi nhất định, và khi đó an toàn bộ nhớ là ưu tiên hàng đầu

  Vậy tiếp theo là đừng viết bất cứ thứ gì xử lý đầu vào không đáng tin cậy sao? Hay là đừng phát minh lại bánh xe dù tất cả bánh xe hiện có đều là hình vuông? Dù vậy, nếu tránh làm JavaScript phình to và dùng biểu mẫu mà trình duyệt cung cấp, thì có lẽ tôi cũng không quá phản đối chuyện tự làm framework web của riêng mình

  • Tôi cho rằng tội tổ tông của C nằm ở chỗ khi truyền mảng thì thông tin cận trên bị mất và sụp xuống chỉ còn con trỏ

  • Từ trước tới nay tôi vẫn hiểu “đừng tự viết mật mã” không phải là mệnh đề tuyệt đối mà là một cảnh báo rất mạnh. Đúng là không cần bằng tiến sĩ vẫn có thể triển khai an toàn, nhưng vẫn đòi hỏi học hỏi cực kỳ nhiều

    Nếu chỉ ở mức triển khai cẩn thận theo đặc tả thì có thể đỡ hơn nhiều. Nhưng phần lớn phần mềm muốn có triển khai mật mã nhanh, và khi đó độ phức tạp tăng vọt. Lỗ hổng Monocypher được dẫn link cũng là ví dụ điển hình. Tự nhiên bạn phải hiểu tương đương phân thức kép liên hệ với Edwards point và Montgomery ladder như thế nào

    Những thứ như bằng tiến sĩ giúp người khác tin rằng bạn biết mình đang làm gì. Kiểm toán cũng là một con đường khác. Có vẻ Monocypher đã được hai tiến sĩ của Cure53 kiểm toán. Vấn đề là đa số lập trình viên không đủ sẵn sàng để tự đánh giá một thư viện mật mã có an toàn hay không, nên họ phải dựa vào các tín hiệu phi kỹ thuật như bằng cấp hoặc bằng cấp của người kiểm toán. Sẽ tốt hơn nếu có cách trực tiếp hơn, nhưng bằng cấp hiện vẫn hoạt động khá ổn

  • Việc có thể tự viết mật mã là hiển nhiên. Nếu không thể thì đã chẳng có thư viện mật mã nào tồn tại. Mấu chốt không phải là có làm được hay không, mà là trong môi trường vận hành nơi bạn băm mật khẩu người dùng và bảo vệ dữ liệu cá nhân, liệu tôi hay bạn có thể tin vào mã mật mã do chính tay mình viết ra hay không. Tôi thì không tin

  • Ở chỗ làm cũ, mã cũ có dùng MD5 để kiểm tra giấy phép, và vì phải xác minh trong môi trường không thể chạy đống C++ cũ đó nên tôi đã phải triển khai lại MD5. Tôi có tìm thư viện sẵn có nhưng không cái nào hỗ trợ thay đổi IV

  • Tôi không đủ can đảm để tự làm mật mã, nhưng việc ngành bảo mật giờ còn bảo đừng tự làm cả xác thực nữa thì có vẻ hơi quá đà

• Sẽ tốt biết mấy nếu trình duyệt cung cấp trường chọn nhiều mục dùng được mà không cần phải tự làm

  • Có đấy, nhưng dở tệ

• Cách dùng `` riêng cho ngày bắt đầu và ngày kết thúc thì với phạm vi ngày tháng vừa rườm rà vừa không trực quan. Nó buộc phải tách một khái niệm vốn là một thành phần duy nhất thành hai khung nhìn riêng biệt trông chẳng mấy liên quan tới nhau

  Việc không có phạm vi ngày tháng chỉ là một trong nhiều vấn đề của ``. Ví dụ, không thể loại trừ một số ngày nhất định nên gần như mọi trường hợp cung cấp dịch vụ đặt chỗ đều không thể dùng ngay từ điểm xuất phát

  Tôi nghi ngờ việc chấp nhận cái giá nhỏ là hai ô nhập để có cùng cách nhập ngày ở mọi nơi có thực sự là quan điểm chủ đạo không. Người dùng trung bình ghét các ô nhập, và thứ còn tệ hơn một ô nhập là hai ô nhập. Lập luận về sự quen thuộc cũng không thuyết phục lắm. Theo kinh nghiệm của tôi, nhập ngày native trên web là khá hiếm

  • Tôi đã thấy khá nhiều website gắn hai widget lịch tùy biến hoạt động chẳng ra gì cho ngày bắt đầu và ngày kết thúc của phạm vi ngày tháng. Đúng là đã tệ còn tệ thêm

  • Tôi cũng không đồng ý với phần về phạm vi ngày tháng. Tôi thường dùng phạm vi ngày tháng như một ví dụ cho thấy thứ về mặt khái niệm là một control đơn lẻ nhưng trên thực tế có thể phức tạp đến mức nào. Khẩu hiệu “luôn dùng control native” đôi khi lại làm trải nghiệm người dùng tệ đi, trong khi đáng ra có thể cung cấp control tốt hơn và phù hợp hơn với bài toán

    Một tính năng hữu ích của control ngày/phạm vi ngày mà native không làm được là hiển thị giá. Khi tìm vé máy bay hay khách sạn, việc thấy ngay trong bộ chọn ngày ngày nào rẻ hơn hay đắt hơn là cực kỳ hữu ích. Nếu là control native thì phải bấm nhiều hơn rất nhiều hoặc xem bảng riêng mới thấy thông tin đó, còn control tùy biến thì có thể gắn metadata như vậy cho từng ngày

    Ví dụ kinh điển là nhập ngày sinh. Bộ chọn ngày thường mặc định hiển thị tháng hiện tại, vốn gần như chẳng liên quan gì đến ngày cần chọn nên là tệ nhất. Ở đây có thể dùng control tùy biến, nhưng nhiều khi tổ hợp textbox lại tốt hơn. Không hẳn là control tự làm hoàn toàn mà là kết hợp các control native, nhưng ý chính là không tồn tại một bộ chọn ngày “vạn năng” xử lý tốt mọi trường hợp

• Chuyện này là từ vài năm trước nên tôi phải kiểm tra lại, nhưng đã từng có một lý do đáng buồn khiến chúng tôi bắt buộc phải tự triển khai thay vì dùng html5 date picker. UI của `` trên một số trình duyệt thật sự kinh khủng

  Tự triển khai menu ngữ cảnh thì hiếm, nhưng khi cần thì cực kỳ hữu ích. Ví dụ, nếu làm trình chỉnh sửa sơ đồ trong trang web thì tôi muốn có menu ngữ cảnh tùy biến để khi bấm vào một nút của sơ đồ có thể thực hiện các thao tác hữu ích. Dồn mọi tương tác vào UI chuột trái, chẳng hạn cứ phải chuyển qua lại giữa bảng thao tác và nút, là không ổn

  Tôi rất đồng ý với các mục còn lại trong danh sách

• Tôi không biết nên hiểu ví dụ về mật mã học cùng với vấn đề hành vi cuộn như thế nào. Chúng có cảm giác là hai lĩnh vực rất khác nhau

  Tôi đồng ý với nhận xét chung rằng website đang làm quá nhiều thứ. Chỉ là hành vi đó sẽ thay đổi tùy theo mục tiêu của người dùng và của website

  Có lẽ một thiết lập kiểu prefers-user-scroll tương tự prefers-reduced-motion có thể là một giải pháp trung gian chăng?

  • Không có trường hợp sử dụng chính đáng nào cho scrolljacking để triển khai vùng cuộn dọc. Loại mã đó ngay từ đầu đã không nên được viết ra

    Tuy vậy, điều này chỉ giới hạn ở vùng cuộn dọc. Với trường hợp ánh xạ cuộn sang hành vi không phải cuộn thì vẫn có những trường hợp sử dụng nhất định; dù vẫn rất nhiều vấn đề, ta cũng có thể bàn đến việc ánh xạ dọc sang ngang trong hệ chữ viết dọc. Ngoài ra có thể còn một hai trường hợp hợp lý khác, nhưng cách triển khai thực tế thường vẫn sai

• Tôi rất đồng ý với cấm tự triển khai cuộn trang. Ở KotlinConf tôi từng nghe một bài nói thú vị về độ khó của việc triển khai cuộn trong Compose Multiplatform for Web

  Một trong các vấn đề là trình duyệt web gửi ít sự kiện cuộn hơn ứng dụng native, khiến thuật toán tính hướng cuộn bị hỏng. Họ dùng cách vẽ một parabol đi qua mọi điểm rồi lấy độ dốc tại điểm cuối, nhưng nếu số điểm quá ít thì hướng cuộn có thể bị suy ra ngược lại

  Khi port từ nền tảng khác sang hoặc tự triển khai lại kiểu tương tác này, rất dễ bắt đầu từ những giả định sai hoặc quên mất những hành vi “kỳ lạ” mà trình duyệt vốn đã cung cấp sẵn

  • Tôi tò mò không biết trong ứng dụng gốc, các sự kiện cuộn đó được dùng vào việc gì mà lại phải sao chép sang cả bối cảnh web. Tôi hơi nghi ngờ kiểu dùng cuộn làm đầu vào điều khiển cho thứ khác

• Lời khuyên “hãy dựa vào nền tảng” là đúng, nhưng việc theo kịp nền tảng liên tục là khó. Có những thứ như enterkeyhint hay inputmode, mình đại khái biết là có tồn tại nhưng lại quên mất hiệu quả của chúng

  Tuần này nhóm chúng tôi đã phát hành [0] để hỗ trợ việc đó. Nó cung cấp các best practice triển khai dưới dạng skill. Tài liệu cũng khá dễ đọc với con người. Ví dụ: [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

• Giọng điệu của bài viết bị lệch. Sẽ hiệu quả hơn nhiều nếu giải thích để mọi người hiểu rõ khi nào và vì sao không cần phát minh lại bánh xe

  Bài viết giải thích lý do khá tốt, nhưng cách diễn đạt độc đoán kiểu “đừng tự làm” khiến nó kém đi

  Khẩu hiệu “đừng tự viết mật mã” cuối cùng cũng nghe như giáo điều. Chuyên gia nào mới là người biết dùng khẩu hiệu đó, và ai bổ nhiệm họ? Trước khi nói vậy họ đã tự đọc mã chưa? Nhìn những lỗ hổng như Heartbleed chẳng phải có thể thấy rằng thực chất đó là những sai lầm rất sơ đẳng sao?

  • Họ là những người đã dành cả đời cho mật mã học. Không phải ai bổ nhiệm cả, mà họ có được vị thế nhờ công bố nghiên cứu hữu ích và trải qua kiểm chứng từ những người hiểu lĩnh vực đó

    Thuật toán được công khai, được xem xét, bị tấn công công khai, được cải tiến rồi được chuẩn hóa. Đây không phải là thứ diễn ra sau cánh cửa đóng kín. Bài báo đều công khai và mã nguồn cũng công khai. Lúc nào bạn cũng có thể xem. Chuyện bạn chưa xem không có nghĩa là không ai xem. Người ta có xem và có cố phá nó. Lý do chúng ta dùng là vì nó đã đứng vững trước tấn công

    Nếu giải pháp bạn rút ra từ Heartbleed là tự tay viết lại OpenSSL, thì tôi dám chắc trong OpenSSL bạn tự viết sẽ có năm mươi Heartbleed cho mỗi một Heartbleed của OpenSSL thật. Khác biệt nằm ở chỗ OpenSSL thật được những người hiểu biết xem xét, kiểm thử, kiểm toán, tấn công rồi sửa chữa. Còn bản của bạn thì chỉ âm thầm sai ở đó mà thôi

  • Điều cốt lõi không phải là tồn tại một chuyên gia hoàn hảo có thể gọi AES mà không bao giờ sơ suất. Mà là nếu dùng wrapper phổ biến hoạt động an toàn thì ngay cả khi có bug, nó cũng được phát hiện và sửa ở một nơi duy nhất

    Kể cả khi xuất hiện tấn công kênh kề mới thì cũng có thể ứng phó ở một nơi. Còn đồ tự làm sẽ không có được những cải tiến đó trừ khi bạn dành toàn thời gian để liên tục theo dõi các kiểu tấn công mới

• Cái này gần giống một bài than phiền về những người dùng công cụ web quá tệ. Nếu bài viết bàn luôn cả các trường hợp tự triển khai là hợp lý thì đã thú vị hơn. Khi đó người đọc mới học được điều hữu ích, thay vì mô hình ngây ngô kiểu “tuyệt đối đừng bao giờ tự làm”

  Thành thạo nghĩa là có cả kiến thức và kỹ năng để tự làm, đồng thời có cả sự khôn ngoan để biết khi nào không nên làm thế

  Dù vậy tôi vẫn đồng cảm với sự bức xúc này. Tôi cũng từng có nhiều bức xúc tương tự. Vấn đề là chưa có nhiều nỗ lực ghi chép thật kỹ và thật toàn diện các tương tác web đến mức lập trình viên web có thể dễ dàng tham khảo. Có một vấn đề nghiêm trọng là tri thức cận kề nghề lập trình không được tài liệu hóa đầy đủ và truyền lại cho thế hệ sau, nên cùng một vấn đề cứ bị phát hiện lại mãi. Thông thường trong ngành sẽ có những nhóm hành vi và tương tác tiêu chuẩn trở thành kẻ chiến thắng, nhưng chẳng ai ghi chúng lại