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

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

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

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

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

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

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

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

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

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

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

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

אז מה חדש?

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

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

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

שקפים: Blink

אבטחה

מאת Parisa Tabriz

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

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

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

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

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

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

  • TLS: לרוב, זהו אותו הדבר כמו SSL. ליתר דיוק, השם של SSL 3.1 השתנה ל-TLS, ו-TLS הוא השם של התקן IETF. אבל אפשר להחליף ביניהם!

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

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

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

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

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

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

Overclocking SSL, ‏ Adam Langley‏ (Google)

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

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

חטיפות דסקית

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

שקפים: יש לכם SSL?

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

מאת Sam Dutton ו-Jan Linden

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

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

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

חטיפות דסקית

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

Slides: Media APIs for the multi-device Web