מפגש הפסגה של מפתחי 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 שעות עם אלפי בוטים, אלפי נקודות השוואה ומערכות שמובילות למיליוני דפי אינטרנט לא תקינים במנוע שלנו כדי להבטיח שהם לא ייפלו. אנחנו יודעים שהנייד איטי באופן משמעותי, וזה דבר שאנחנו משקיעים מאמצים רבים כדי לשפר אותו.

אז מה חדש?

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

אנחנו רוצים לדעת מה יש לך לומר!

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

Slides: מצמוץ

אבטחה

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

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

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

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

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

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

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

  • TLS: לרוב ה-Intent והמטרות זהים ל-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 ואת הספר של Ilya Graigorik, High Performance Browser Networking). הצמדת מפתח ציבורי נועדה לתת למפעילי אתרים אמצעים להגביל את רשויות האישורים שיכולות להנפיק אישורים לאתרים שלהם.

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

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

Overclocking SSL, אדם לאנגלי (Google)

לבסוף, שני באגים שקורים בתדירות הגבוהה ביותר:

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

חטיפות דסקית

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

Slides: יש לכם SSL?

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

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

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

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

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

חטיפות דסקית

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

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