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