Blink
Tác giả: Greg Simon và Eric Seidel
Blink là công cụ kết xuất nguồn mở của Chrome. Nhóm Blink đang phát triển web và giải quyết các vấn đề mà nhà phát triển gặp phải.
Chúng tôi đã thực hiện một số cải tiến ở hậu trường kể từ khi ra mắt tính năng này vào tháng 4.
Việc đầu tiên chúng tôi làm là xoá một nửa nguồn không cần thiết. Chúng ta vẫn chưa hoàn tất! Chúng tôi không làm việc này một cách mù quáng: việc xoá mã được thực hiện dựa trên số liệu thống kê tổng hợp được báo cáo ẩn danh của những người dùng Chrome chọn sử dụng tính năng báo cáo.
Chúng tôi phát hành một API mới dành cho nhà phát triển mỗi 6 tuần, giống như lịch phát hành của Chrome.
Một thay đổi lớn mà chúng tôi thực hiện khi tách khỏi Blink là thêm hệ thống ý định: mỗi khi thay đổi nền tảng web, chúng tôi sẽ gửi thông báo công khai cho nhà phát triển Blink về ý định thêm hoặc xoá một tính năng. Sau đó, chúng ta sẽ bắt đầu lập trình! Và ngay ngày hôm sau khi tính năng được kiểm tra, tính năng đó đã có trong các bản dựng Canary của chúng tôi. Tính năng này tắt theo mặc định, nhưng bạn có thể bật bằng about:flags.
Sau đó, trên danh sách gửi thư công khai, chúng tôi sẽ thông báo ý định vận chuyển.
Tại chromestatus.com, bạn có thể xem các tính năng mà chúng tôi đã làm việc, các tính năng mà chúng tôi đã phát hành và những tính năng mà chúng tôi dự định ngừng sử dụng. Bạn cũng có thể xem blog Phát hành Chromium. Blog này có các đường liên kết đến lỗi và trang tổng quan của công cụ theo dõi.
Một thay đổi lớn khác là chúng tôi sẽ xoá các tiền tố WebKit. Ý định không phải là sử dụng tiền tố Blink, mà là có các cờ thời gian chạy (chứ không chỉ các cờ thời gian biên dịch).
Android WebView là một thách thức lớn – nhưng HTML5Test cho thấy mọi thứ đang trở nên tốt hơn. Chúng ta đã tiến gần hơn nhiều đến máy tính để bàn về việc có một bộ API nền tảng web ở mọi nơi (Web Audio là một ví dụ tuyệt vời về điều này!)
Nhưng máy làm xúc xích hoạt động như thế nào? Mọi thay đổi mà chúng tôi thực hiện đối với Blink đều được chạy ngay qua hơn 30.000 lượt kiểm thử, chưa kể đến tất cả các lượt kiểm thử Chromium chạy thêm sau đó. Chúng tôi sử dụng hệ thống giám sát 24/7 với hàng nghìn bot, hàng nghìn điểm chuẩn và hệ thống gửi hàng triệu trang web bị hỏng đến công cụ của chúng tôi để đảm bảo công cụ này không gặp sự cố. Chúng tôi biết rằng phiên bản dành cho thiết bị di động có tốc độ chậm hơn đáng kể. Đây là vấn đề mà chúng tôi đang nỗ lực cải thiện.
Vậy có gì mới?
- Thành phần web: hãy xem bài nói chuyện của Eric Bidelman!
- Ảnh động trên web: ảnh động phức tạp, đồng bộ, hiệu suất cao sử dụng GPU bất cứ khi nào có thể
- Bố cục một phần: chỉ tính toán những gì bạn cần!
- Lưới CSS
- Hình ảnh thích ứng:
srcset hoặc srcN hoặc ? - Tự động định cỡ văn bản nhanh hơn và phông chữ phụ pixel nhất quán
- Skia, hệ thống đồ hoạ mà Blink sử dụng, đang chuyển từ GDI sang DirectWrite trên Windows
Chúng tôi muốn biết ý kiến của bạn!
Nếu bạn yêu thích C++ và muốn cùng chúng tôi viết mã C++, thì tất cả mã của chúng tôi đều mở. Bạn không cần phải nói với bất kỳ ai hoặc thuyết phục chúng tôi. Bạn chỉ cần đăng bản vá hoặc gửi lỗi!
Trang trình bày: Blink
Bảo mật
Tác giả: Parisa Tabriz
Ngày nay, có nhiều người kết nối với web hơn bao giờ hết và từ nhiều nơi hơn.
Chúng ta kết nối với máy tính xách tay, điện thoại và máy tính bảng, và có thể sớm kết nối với các thiết bị và phụ kiện cá nhân. Chúng ta truy cập Internet từ các mạng không đáng tin cậy và đôi khi thậm chí là mạng thù địch. Cuộc sống của chúng ta ngày càng chuyển sang môi trường trực tuyến, vì vậy, chúng ta cần phải thực hiện các bước để bảo vệ dữ liệu của mình và dữ liệu của người dùng.
Trên hết, với tư cách là nhà phát triển, chúng ta cần hiểu rõ sự cần thiết và tính thực tiễn của SSL.
SSL là gì? Đây là tên viết tắt của Secure Sockets Layer (Lớp cổng bảo mật) và là một giao thức mật mã được thiết kế để cung cấp bảo mật thông tin liên lạc qua Internet. Tính năng này đảm bảo quyền riêng tư thông qua việc mã hoá và đảm bảo tính toàn vẹn để ngăn chặn hành vi xem trộm hoặc can thiệp vào kết nối Internet của bạn. SSL có những điểm yếu, nhưng đây là phương pháp hàng đầu – và thực sự là phương pháp duy nhất – để đảm bảo mọi loại bảo mật truyền dữ liệu trên Internet.
Theo SSL Pulse, một năm trước, chúng tôi chỉ có khoảng 15% số trang web sử dụng SSL; hiện tại, con số này đã tăng lên hơn 50%.
Hai từ viết tắt:
TLS: đối với hầu hết các ý định và mục đích giống như SSL. Chính xác là SSL 3.1 được đổi tên thành TLS và TLS là tên tiêu chuẩn IETF. Nhưng bạn có thể thay thế cho nhau!
HTTPS: đây là HTTP qua SSL, chỉ là lớp phủ các tính năng bảo mật của SSL và HTTP tiêu chuẩn. Trước tiên, quá trình bắt tay máy khách – máy chủ, sử dụng phương thức mã hoá khoá công khai/riêng tư để tạo khoá dùng chung – được phần thứ hai của giao thức SSL sử dụng để mã hoá thông tin liên lạc.
Việc kết nối mạng trên Internet có thể mang lại cảm giác an toàn, tức thì và nhanh chóng. Cảm giác như chúng ta đang nói chuyện trực tiếp với trang web. Nhưng trên thực tế, đó không phải là mối liên kết trực tiếp. Thông tin liên lạc của chúng tôi đi qua một bộ định tuyến wifi, một ISP và có thể là các proxy trung gian khác giữa thiết bị của bạn và trang web. Nếu không có HTTPS, tất cả thông tin giao tiếp của chúng ta đều ở dạng văn bản thuần tuý.
Vấn đề là người dùng hiếm khi nhập một URL đầy đủ chỉ định HTTPS – hoặc họ nhấp vào một đường liên kết sử dụng HTTP. Tệ hơn nữa, kẻ tấn công có thể thực hiện cuộc tấn công giả mạo và thay thế HTTPS bằng HTTP. Một công cụ có tên SSLstrip được giới thiệu vào năm 2009 đã thực hiện việc đó. Firesheep, từ năm 2010, chỉ nghe các mạng wifi đã mở để tìm cookie được gửi ở dạng thô: tức là bạn có thể nghe cuộc trò chuyện hoặc đăng nhập vào tài khoản Facebook của người khác.
Tuy nhiên, SSL (tương đối) rẻ, nhanh và dễ triển khai (hãy xem ssllabs.com và cuốn sách High Performance Browser Networking (Mạng trình duyệt hiệu suất cao) của Ilya Grigorik). Tính năng Ghim khoá công khai được thiết kế để giúp các nhà điều hành trang web hạn chế những tổ chức phát hành chứng chỉ thực sự có thể cấp chứng chỉ cho trang web của họ.
"Vào tháng 1 năm nay (2010), Gmail đã chuyển sang sử dụng HTTPS cho mọi thứ theo mặc định. Để làm được điều này, chúng tôi không cần triển khai thêm máy móc và phần cứng đặc biệt nào. Trên các máy đầu cuối sản xuất của chúng tôi, SSL chiếm < 1% tải CPU, < 10 KB bộ nhớ cho mỗi kết nối và < 2% hao tổn mạng…
Nếu dừng đọc ngay bây giờ, bạn chỉ cần nhớ một điều: SSL không còn tốn kém về mặt tính toán nữa”.
– Tăng tốc SSL, Adam Langley (Google)
Cuối cùng, một số lỗi thường gặp nhất:
- Nội dung hỗn hợp: trang web sử dụng cả HTTP và HTTPS. Người dùng sẽ khó chịu vì họ phải nhấp vào nút cấp quyền để tải nội dung. (Chrome và Firefox thực sự chặn nội dung hỗn hợp khỏi iframe.) Đảm bảo rằng tất cả tài nguyên trên trang HTTPS đều được tải bằng HTTPS, bằng cách sử dụng URL tương đối hoặc tương đối theo lược đồ, ví dụ:
<style src="//foo.com/style.css"> - Cookie không an toàn: được gửi ở dạng thô qua kết nối HTTP. Bạn có thể tránh điều này bằng cách đặt thuộc tính bảo mật trên tiêu đề cookie. Bạn cũng có thể sử dụng tiêu đề "Bảo mật truyền tải nghiêm ngặt" mới để yêu cầu Bảo mật truyền tải SSL (HSTS).
Cướp lại bóng
- Nếu quan tâm đến quyền riêng tư và tính toàn vẹn của dữ liệu người dùng, bạn cần sử dụng SSL. Nhanh hơn, dễ dàng hơn và rẻ hơn bao giờ hết.
- Tránh các lỗi triển khai thường gặp, chẳng hạn như lỗi nội dung hỗn hợp hoặc không đặt đúng bit tiêu đề HTTP.
- Sử dụng URL tương đối hoặc URL tương đối theo giao thức.
- Hãy xem một số tính năng mới thú vị, chẳng hạn như HSTS và ghim chứng chỉ
Trang trình bày: Bạn có SSL không?
API nội dung nghe nhìn cho Web đa thiết bị
Tác giả: Sam Dutton và Jan Linden
Cùng với sự gia tăng của các thiết bị và nền tảng mới trên web, chúng tôi nhận thấy sự phát triển mạnh mẽ của nội dung âm thanh, video và giao tiếp theo thời gian thực. Nội dung nghe nhìn trực tuyến đang thay đổi cách chúng ta tiếp nhận mọi loại nội dung nghe nhìn.
Một nghiên cứu của chính phủ Vương quốc Anh cho thấy 53% người lớn "làm nhiều việc cùng lúc với nội dung nghe nhìn" trong khi xem TV: sử dụng thiết bị di động để chia sẻ và thưởng thức nội dung nghe nhìn. Ở nhiều quốc gia, số người xem truyền hình truyền thống đang giảm và số người xem trực tuyến đang tăng. Ví dụ: ở Trung Quốc, vào năm 2012, chỉ 30% hộ gia đình ở Bắc Kinh xem TV, giảm từ 70% vào năm 2009. Theo Thông tin nổi bật của W3C năm 2013, "Trong năm qua, số người xem video trên thiết bị di động đã tăng gấp đôi". Năm nay tại Hoa Kỳ, thời gian trung bình dành cho phương tiện truyền thông kỹ thuật số mỗi ngày sẽ vượt qua thời gian xem truyền hình. Việc xem không còn là một hành động thụ động. Tại Hoa Kỳ, 87% người tiêu dùng nội dung giải trí cho biết họ sử dụng ít nhất một thiết bị màn hình thứ hai trong khi xem truyền hình." Theo Cisco, "video ... sẽ chiếm khoảng 80 đến 90% lưu lượng truy cập của người tiêu dùng trên toàn cầu vào năm 2017". Tức là gần một triệu phút video mỗi giây.
Vậy chúng tôi có gì dành cho nhà phát triển web? Hệ sinh thái API nội dung nghe nhìn cho Web mở: các công nghệ chuẩn hoá, có khả năng tương tác và hoạt động trên nhiều nền tảng.
Cướp lại bóng
- WebRTC cung cấp tính năng giao tiếp theo thời gian thực trong trình duyệt và hiện được hỗ trợ rộng rãi trên thiết bị di động và máy tính. Tổng cộng đã có hơn 1,2 tỷ điểm cuối WebRTC.
- Web Audio cung cấp các công cụ phức tạp để tổng hợp và xử lý âm thanh.
- Web MIDI, được tích hợp với Web Audio, cho phép tương tác với các thiết bị MIDI.
- Các phần tử âm thanh và video hiện được hỗ trợ trên hơn 85% trình duyệt dành cho thiết bị di động và máy tính.
- Bạn có thể sử dụng Tiện ích nguồn nội dung nghe nhìn để truyền trực tuyến thích ứng và chuyển đổi thời gian.
- EME cho phép phát nội dung được bảo vệ.
- Bản chép lời, phụ đề và thành phần kênh hỗ trợ phụ đề, siêu dữ liệu theo thời gian, liên kết sâu và tìm kiếm sâu.
Bài trình bày: API đa phương tiện cho web nhiều thiết bị