מפגש הפסגה של מפתחי Chrome – פתיחת סיכום של פלטפורמת האינטרנט

מאת גרג סיימון ואריק סיידל

Blink הוא מנוע העיבוד בקוד פתוח של Chrome. צוות Blink מפתח את האינטרנט ומטפל בבעיות שבהן נתקלים המפתחים.

התחלנו מספר שיפורים מאחורי הקלעים מאז ההשקה באפריל.

הדבר הראשון שעשינו היה למחוק חצי מהמקור שלנו, דבר שלא היינו צריכים בהכרח. עדיין לא סיימנו! ואנחנו לא עושים זאת באופן עיוור: הסרת הקוד מבוססת על נתונים סטטיסטיים מצטברים שדווחו באופן אנונימי ממשתמשי Chrome שהביעו הסכמה לדיווח.

אנחנו מפרסמים API חדש למפתחים כל 6 שבועות: זהה ללוח הזמנים למשלוח של Chrome.

אחד השינויים הגדולים שעשינו כשהחללנו מ-Blink היה הוספה של מערכת Intent: בכל פעם לפני שאנחנו נשנה את פלטפורמת האינטרנט, אנחנו שולחים הודעה ציבורית אל Blink dev שבה אנחנו מכריזים על כוונתנו להוסיף או להסיר תכונה. ואז אנחנו מתחילים, ואנחנו מקודדים את זה! ביום המחרת, לאחר שהתבצעה בדיקה של התכונה, היא כבר זמינה בגרסאות build של Canary. התכונה הזו מושבתת כברירת מחדל, אבל אפשר להפעיל אותה באמצעות about:flags.

לאחר מכן, ברשימת הדיוור הציבורית שלנו, אנחנו מכריזים על כוונת משלוח.

באתר chromestatus.com אתה יכול לראות את התכונות שעבדנו עליהן, את התכונות שהשקנו ואת התכונות שאנחנו מתכננים להוציא משימוש. אפשר גם לעיין בבלוג Chromium Releases, שכולל קישורים לבאגים וגם במרכז השליטה של מכשירי המעקב.

שינוי גדול נוסף הוא שאנחנו מסירים קידומות של WebKit. הכוונה היא לא להשתמש בתחיליות Blink, אלא להשתמש בדגלים בזמן ריצה (ולא רק בדגלים בזמן הידור).

Android WebView הוא אתגר גדול – אבל HTML5Test מראה שהתנאים משתפרים. אנחנו הרבה יותר קרובים למחשב שולחני כי יש קבוצה אחת של ממשקי API לפלטפורמות אינטרנט בכל מקום (Web Audio הוא דוגמה מצוינת לכך!)

אבל איך פועלת מכונת הנקניקיות? כל שינוי שאנחנו מבצעים ב-Blink עובר מיד יותר מ-30,000 בדיקות, שלא לדבר על כל הבדיקות של Chromium שפועלות לאחר מכן. אנחנו משתמשים בשריף במשך 24 שעות, באמצעות אלפי בוטים, אלפי נקודות השוואה ומערכות שזורקות מיליוני דפי אינטרנט שבורים למנוע שלנו כדי להבטיח שהוא לא ייפול. אנחנו יודעים שמכשירים ניידים איטיים משמעותית, ואנחנו משקיעים מאמצים רבים כדי לשפר את השירות הזה.

אז מה חדש?

  • רכיבי אינטרנט: כדאי לראות את ההרצאה של אריק בידלמן!
  • אנימציות באינטרנט: אנימציות מורכבות, מסונכרנות עם ביצועים גבוהים, שמשתמשות ב-GPU ככל האפשר
  • פריסה חלקית: אפשר לחשב רק את מה שצריך.
  • רשת CSS
  • תמונות רספונסיביות: srcset או srcN או ?
  • קביעת גודל אוטומטי מהירה יותר של טקסט וגופנים עקביים בתת-פיקסלים
  • Skia, מערכת הגרפיקה המשמשת את Blink, עוברת מ-GDI ל-DirectWrite ב-Windows

חשוב לנו לשמוע מה דעתך.

אם אתם מרגישים C++ בדם ואתם רוצים לכתוב לנו C++, כל הקוד שלנו פתוח. אין צורך לספר לנו לאף אחד או לשלוח לנו דברי שטנה. תוכל פשוט לפרסם תיקון או לדווח על באג!

Slides: הבהוב

אבטחה

מאת פריזה טבריז

כיום יותר אנשים מחוברים לאינטרנט מאי פעם – ומיותר מקומות.

יש לנו חיבור באמצעות מחשבים ניידים, טלפונים וטאבלטים, ובקרוב סביר להניח שבקרוב גם מספיק תהיה לנו אביזרים ומכשירים אישיים. אנחנו ניגשים לאינטרנט מרשתות לא מהימנות ולפעמים אפילו מרשתות עוינות. מכיוון שחלק גדול מהחיים שלנו עובר לאינטרנט, יש חשיבות רבה להגן על הנתונים שלנו ועל הנתונים של המשתמשים שלנו.

מעל לכל, כמפתחים, עלינו להבין את הצורך והמעשיות של SSL.

מה זה SSL? זהו פרוטוקול שנקרא Secure Sockets Layer, והוא פרוטוקול קריפטוגרפי שמיועד לספק אבטחת תקשורת באינטרנט. כך מובטחת שמירה על פרטיות, באמצעות הצפנה ותקינות, למניעת מעקב לא רצוי או גרימת נזק בחיבור לאינטרנט. ל-SSL יש חסרונות, אבל זוהי הדרך העיקרית – ולמעשה הדרך היחידה – להבטיח אבטחת תקשורת נתונים כלשהי באינטרנט.

לפי הבהוב SSL, לפני שנה היו לנו פחות מ-15% מהאימוץ של SSL; עכשיו אנחנו משתמשים ביותר מ-50%.

שני ראשי תיבות:

  • TLS (אבטחת שכבת התעבורה): לרוב ה-Intents והמטרות זהות ל-SSL. ליתר דיוק, השם של SSL 3.1 שונה ל-TLS, ו-TLS הוא השם הסטנדרטי של IETF. אבל הם ניתנים להחלפה!

  • HTTPS: זהו HTTP ב-SSL, כלומר שכבות של יכולות האבטחה של SSL ו-HTTP סטנדרטי. ראשית, לחיצת היד של השרת-הלקוח, באמצעות קריפטוגרפיה של מפתח ציבורי/פרטי כדי ליצור מפתח משותף - משמש את החלק השני של פרוטוקול SSL להצפנת התקשורת.

רישות באינטרנט עשויה להרגיש בטוחה, מיידית ומהירה. אנחנו מרגישים שאנחנו פונים ישירות לאתר. אבל למעשה, אין זה חיבור ישיר. התקשורת שלנו עוברת דרך נתב Wi-Fi, ספק אינטרנט ושרתי Proxy מתווכים אחרים שעשויים להיות מתווכים בין המכשיר שלכם לאתר. בלי HTTPS, כל התכתובות יהיו בטקסט פשוט.

הבעיה היא שלעיתים נדירות משתמשים מקלידים כתובת URL מלאה שמציינת HTTPS – או שהם לוחצים על קישור באמצעות HTTP. גרוע מכך, יש אפשרות לטעון התקפה מסוג (wo)man-in-the-middle ולהחליף את HTTPS ב-HTTP. בדיוק בשביל זה קיימת כלי בשם SSLstrip שהושק בשנת 2009. Firesheep, משנת 2010, האזין עכשיו לרשתות Wi-Fi פתוחות עבור קובצי cookie שנשלחים באופן ברור: כלומר, אפשר היה להאזין לצ'אט או להתחבר לחשבון Facebook של מישהו.

אבל SSL הוא (יחסית) זול, מהיר וקל לפריסה (עיין בספר של ssllabs.com ושל איליה גריגוריק, High Performance Browser Networking). מטרת הצמדת מפתח ציבורי היא לספק למפעילי אתרים אמצעים להגביל את רשויות האישורים שיכולות להנפיק אישורים לאתרים שלהם בפועל.

"בינואר השנה (2010), Gmail עבר להשתמש ב-HTTPS עבור הכל כברירת מחדל. לשם כך, לא היינו צריכים לפרוס מכונות נוספות או חומרה מיוחדת. במכונות החזיתיות של הייצור שלנו, ה-SSL מהווה פחות מ-1% מעומס המעבד (CPU), פחות מ-10KB של זיכרון לכל חיבור ופחות מ-2% מתקורת הרשת...

אם מפסיקים לקרוא עכשיו, צריך לזכור רק דבר אחד: SSL כבר לא יקר יותר מבחינת חישוב".

חריגה של SSL, אדם לאנגלי (Google)

לסיום, כמה באגים שאנחנו נתקלים בהם בדרך כלל:

  • תוכן מעורב: אתרים המשתמשים ב-HTTP וגם ב-HTTPS. המשתמש מתעצבן כי הוא צריך ללחוץ על לחצן הרשאה כדי לטעון תוכן. (למעשה, Chrome ו-Firefox חוסמים תוכן מעורב ממסגרות iframe). צריך לוודא שכל המשאבים בדף HTTPS נטענים באמצעות HTTPS. כדי לעשות את זה צריך להשתמש בכתובות URL יחסיות או יחסיות של סכימה, לדוגמה <style src="//foo.com/style.css">
  • קובצי cookie לא מאובטחים: נשלחים באופן ברור דרך חיבור HTTP. כדי להימנע מכך, אפשר להגדיר את המאפיין המאובטח בכותרות של קובצי cookie. תוכלו גם להשתמש בכותרת חדשה מסוג "Strict Transport Security" כדי לדרוש אבטחה ב-SSL Transport Security (HSTS).

חטיפות דסקית

  • אם חשוב לכם לשמור על הפרטיות והשלמות של נתוני המשתמשים, עליכם להשתמש ב-SSL. הוא מהיר יותר, קל יותר וזול יותר מתמיד.
  • יש להימנע משגיאות הטמעה נפוצות, כמו באגים בתוכן מעורב או אי-הגדרה של הביטים הנכונים של כותרת ה-HTTP.
  • מומלץ להשתמש בכתובות URL יחסיות או בסכמה של כתובות URL יחסיות.
  • הנה כמה מהדברים המגניבים החדשים, כמו HSTS והצמדת אישורים

Slides: יש לך SSL?

ממשקי API של מדיה לאינטרנט למכשירים מרובים

מאת סם דוטון ויאן לינדן

יחד עם ההתפתחות של מכשירים ופלטפורמות חדשים באינטרנט, אנחנו רואים צמיחה עצומה באודיו, בווידאו ובתקשורת בזמן אמת. המדיה באינטרנט משנה את האופן שבו אנחנו צורכים מדיה מכל הסוגים.

מחקר שממשלת בריטניה העלה כי 53% מהמבוגרים מבצעים פעולות במקביל במדיה במהלך צפייה בטלוויזיה: משתמשים במכשירים ניידים כדי לשתף ולצרוך מדיה. במדינות רבות יש ירידה בצפייה בטלוויזיה ובשיעור הצפייה באינטרנט. בסין, לדוגמה, בשנת 2012, רק 30% ממשקי הבית בבייג'ינג צפו בטלוויזיה, ירידה מ-70% ב-2009. על פי המיטב של W3C לשנת 2013, 'בשנה האחרונה הוכפלה הצפייה בסרטונים במכשירים ניידים. השנה בארה"ב, משך השימוש הממוצע ביום במדיה הדיגיטלית יעבור את הצפייה בטלוויזיה. הצפייה כבר אינה פעולה פסיבית. בארה"ב, 87% מצרכני הבידור אומרים שהם משתמשים במכשיר אחד לפחות במסך השני בזמן הצפייה בטלוויזיה.' על פי Cisco, 'video ...' יהיה בטווח של 80 עד 90 אחוזים מתנועת הצרכנים העולמית עד 2017'. שווה ערך לכמעט מיליון דקות של סרטונים בכל שנייה.

אז מה אנחנו מציעים למפתחי אינטרנט? סביבה עסקית של ממשקי API של מדיה לאינטרנט הפתוח: טכנולוגיות סטנדרטיות עם יכולת פעולה הדדית שפועלות בפלטפורמות מרובות.

חטיפות דסקית

  • WebRTC מספק תקשורת בזמן אמת בדפדפן, ועכשיו הוא נתמך באופן נרחב בניידים ובמחשבים. בסך הכול יש כבר יותר מ-1.2 מיליארד נקודות קצה של WebRTC.
  • Web Audio מספק כלים מתוחכמים לסינתזת אודיו ולעיבוד אודיו.
  • Web MIDI, המשולב ב-Web Audio, מאפשר אינטראקציה עם מכשירי MIDI.
  • רכיבי האודיו והווידאו נתמכים עכשיו ביותר מ-85% מהדפדפנים בנייד ובמחשב.
  • ניתן להשתמש בתוספים של מקור מדיה לסטרימינג דינמי ולהזזת מועד הצפייה.
  • EME מאפשר הפעלה של תוכן מוגן.
  • תמלילים, כתוביות ואלמנט הרצועה מאפשרים להציג כתוביות, כתוביות מתוזמנות, מטא-נתונים מתוזמנים, קישורי עומק וחיפוש עמוק.

Slides: ממשקי API של מדיה לאינטרנט מרובה מכשירים