پلک زدن
توسط گرگ سیمون و اریک سیدل
Blink موتور رندر منبع باز کروم است. تیم Blink در حال توسعه وب و رسیدگی به مشکلاتی است که توسعه دهندگان با آن مواجه می شوند.
از زمان عرضه در آوریل، تعدادی بهبود در پشت صحنه شروع شده است.
اولین کاری که انجام دادیم این بود که نیمی از منبع خود را حذف کردیم که لزوماً به آن نیاز نداشتیم. ما هنوز تمام نشده ایم! و ما این کار را کورکورانه انجام نمی‌دهیم: حذف کد بر اساس آمار مجموع گزارش شده ناشناس از کاربران Chrome است که گزارش را انتخاب می‌کنند.
ما هر شش هفته یک API برنامه‌نویس جدید منتشر می‌کنیم: همان برنامه ارسال Chrome.
یکی از تغییرات بزرگی که هنگام خروج از Blink ایجاد کردیم، اضافه کردن یک سیستم هدف بود: هر بار قبل از اینکه بخواهیم پلتفرم وب را تغییر دهیم، یک اعلامیه عمومی برای توسعه دهنده Blink ارسال می کنیم که قصد خود را برای افزودن یا حذف یک ویژگی اعلام می کند. سپس ما خاموش می شویم و آن را کد می کنیم! و پس از آن روز بعد از بررسی این ویژگی، در حال حاضر در ساخت‌های Canary ما ارسال می‌شود. این ویژگی به طور پیش‌فرض خاموش است، اما می‌توانید آن را با استفاده از about:flags روشن کنید.
سپس، در لیست پستی عمومی خود ، قصد ارسال را اعلام می کنیم.
در chromestatus.com می‌توانید ویژگی‌هایی را که روی آنها کار کرده‌ایم، ویژگی‌هایی که ارسال کرده‌ایم، و آن‌هایی که قصد داریم از آنها استفاده کنیم را ببینید. همچنین می‌توانید وبلاگ Chromium Releases را بررسی کنید، که دارای پیوندهایی به اشکالات و داشبورد ردیاب ما است.
تغییر بزرگ دیگر این است که ما پیشوندهای WebKit را حذف می کنیم. هدف استفاده از پیشوندهای Blink نیست، بلکه داشتن پرچم‌های زمان اجرا (و نه فقط پرچم‌های زمان کامپایل) است.
Android WebView یک چالش بزرگ بوده است – اما HTML5Test نشان می دهد که همه چیز در حال بهتر شدن است. ما از نظر داشتن یک مجموعه از APIهای پلتفرم وب در همه جا به دسکتاپ نزدیکتر هستیم (صدای وب یک مثال عالی از این است!)
اما دستگاه سوسیس چگونه کار می کند؟ هر تغییری که در Blink ایجاد می‌کنیم، بلافاصله از طریق بیش از 30000 آزمایش انجام می‌شود، نه اینکه به تمام آزمایش‌های Chromium که بعداً اجرا می‌شوند اشاره کنیم. ما از کلانتر 24 ساعته، با هزاران ربات، هزاران معیار، و سیستم‌هایی استفاده می‌کنیم که میلیون‌ها صفحه وب شکسته را به سمت موتور ما پرتاب می‌کنند تا مطمئن شویم که خراب نمی‌شود. ما می دانیم که موبایل به طور قابل توجهی کندتر است، و این چیزی است که ما سخت برای بهبود آن کار می کنیم.
خوب چه خبر؟
- اجزای وب : سخنرانی اریک بیدلمن را بررسی کنید!
- انیمیشن‌های وب: انیمیشن‌های پیچیده، همگام‌سازی‌شده و با کارایی بالا که تا جایی که ممکن است از GPU استفاده می‌کنند
- طرح بندی جزئی: فقط آنچه را که نیاز دارید محاسبه کنید!
- شبکه CSS
- تصاویر واکنش گرا:
srcset یا srcN یا ? - اندازه خودکار سریعتر متن و فونت های زیر پیکسلی ثابت
- Skia، سیستم گرافیکی مورد استفاده Blink، در حال حرکت از GDI به DirectWrite در ویندوز است
ما می خواهیم بدانیم شما چه می گویید!
اگر C++ را در خون خود احساس می کنید و می خواهید با ما C++ بنویسید، تمام کدهای ما باز است. شما مجبور نیستید به کسی بگویید یا به ما بشارت دهید. شما فقط می توانید به سادگی یک پچ ارسال کنید یا یک باگ را ثبت کنید !
اسلایدها: چشمک زدن
امنیت
توسط پریسا تبریز
امروزه افراد بیشتری نسبت به قبل به وب متصل هستند - و از مکان های بیشتری.
ما با لپ‌تاپ‌ها، تلفن‌ها و تبلت‌های خود و احتمالاً به زودی با دستگاه‌ها و لوازم جانبی شخصی خود در ارتباط هستیم. ما از طریق شبکه های غیرقابل اعتماد و گاهی اوقات حتی متخاصم به اینترنت دسترسی داریم. با توجه به اینکه بخش اعظم زندگی ما به صورت آنلاین در حال انجام است، ضروری است که اقداماتی را برای محافظت از داده های خود و داده های کاربران خود انجام دهیم.
مهمتر از همه، به عنوان توسعه دهندگان باید ضرورت و کاربردی بودن SSL را درک کنیم.
SSL چیست؟ این مخفف عبارت Secure Sockets Layer است و یک پروتکل رمزنگاری است که برای تامین امنیت ارتباط از طریق اینترنت طراحی شده است. حریم خصوصی را از طریق رمزگذاری و یکپارچگی تضمین می کند تا از جاسوسی یا دستکاری در اتصال اینترنت شما جلوگیری کند. SSL دارای اشکالاتی است، اما راه پیشرو – و در واقع تنها راه – برای تضمین هر نوع امنیت ارتباطات داده در اینترنت است.
با توجه به SSL Pulse ، یک سال پیش ما تقریباً کمتر از 15٪ از SSL را پذیرفتیم. ما اکنون بیش از 50 درصد پذیرش داریم.
دو مخفف:
TLS: برای اکثر مقاصد و مقاصد مشابه SSL است. به طور دقیق، SSL 3.1 به TLS تغییر نام داد و TLS نام استاندارد IETF است. اما آنها قابل تعویض هستند!
HTTPS: این HTTP بیش از SSL است، فقط لایه بندی قابلیت های امنیتی SSL و HTTP استاندارد. ابتدا دست دادن مشتری و سرور، با استفاده از رمزنگاری کلید عمومی/خصوصی برای ایجاد یک کلید مشترک - که توسط بخش دوم پروتکل SSL برای رمزگذاری ارتباطات استفاده می شود.
شبکه در اینترنت ممکن است احساس امنیت، فوری و سریع داشته باشد. به نظر می رسد که ما مستقیماً با وب سایت صحبت می کنیم. اما در واقعیت، این یک ارتباط مستقیم نیست. ارتباطات ما از طریق یک روتر وای فای، یک ISP، و احتمالاً سایر پروکسی های واسطه بین دستگاه شما و وب سایت انجام می شود. بدون HTTPS، تمام ارتباطات ما به صورت متن ساده است.
مشکل اینجاست که کاربران به ندرت یک URL کامل را که HTTPS را مشخص می کند تایپ می کنند - یا با استفاده از HTTP روی پیوند کلیک می کنند. بدتر از آن، این امکان وجود دارد که یک حمله (wo)man-in-the-middle را انجام دهید و HTTP را با HTTP جایگزین کنید. ابزاری به نام SSLstrip که در سال 2009 معرفی شد این کار را انجام می دهد. Firesheep، از سال 2010، فقط به شبکه‌های وای‌فای باز شده برای ارسال کوکی‌ها به صورت واضح گوش می‌داد: این بدان معناست که می‌توانید در چت به آن گوش دهید یا به حساب فیسبوک شخصی وارد شوید.
اما SSL (نسبتا) ارزان، سریع و آسان برای استقرار است (به ssllabs.com و کتاب ایلیا گریگوریک با کارایی بالا در مرورگر شبکه سازی مراجعه کنید). پین کردن کلید عمومی به این منظور طراحی شده است که به اپراتورهای وب سایت ابزاری را برای محدود کردن اینکه مقامات گواهی می توانند واقعاً برای سایت های خود گواهی صادر کنند، طراحی شده است.
"در ژانویه امسال (2010)، Gmail به طور پیش‌فرض به استفاده از HTTPS برای همه چیز تغییر داد. برای انجام این کار، ما مجبور شدیم هیچ ماشین اضافی و سخت‌افزار خاصی را مستقر نکنیم. در ماشین‌های فرانت‌اند تولید ما، SSL کمتر از 1٪ از بار CPU، کمتر از 10 کیلوبایت حافظه در هر اتصال، و کمتر از 2 درصد از سربار شبکه…
اگر اکنون خواندن را متوقف کنید، فقط باید یک چیز را به خاطر بسپارید: SSL دیگر از نظر محاسباتی گران نیست.
– اورکلاک SSL ، آدام لنگلی (گوگل)
در نهایت، چند باگ که بیشتر می بینیم:
- محتوای ترکیبی: سایت هایی که از HTTP و همچنین HTTPS استفاده می کنند. کاربر شما عصبانی می شود زیرا باید روی دکمه مجوز برای بارگذاری محتوا کلیک کند. (Chrome و Firefox در واقع محتوای ترکیبی را از iframes می‌بندند.) با استفاده از URLهای نسبی یا مرتبط با طرح، به عنوان مثال
<style src="//foo.com/style.css">مطمئن شوید که تمام منابع شما در یک صفحه HTTPS توسط HTTPS بارگیری می‌شوند.<style src="//foo.com/style.css"> - کوکی های ناامن: از طریق یک اتصال HTTP به صورت پاک ارسال می شود. با تنظیم ویژگی امن در هدرهای کوکی از این امر جلوگیری کنید. همچنین می توانید از یک سربرگ جدید "Strict Transport Security" برای نیاز به امنیت حمل و نقل SSL (HSTS) استفاده کنید.
غذای آماده
- اگر به حفظ حریم خصوصی و یکپارچگی داده های کاربران خود اهمیت می دهید، باید از SSL استفاده کنید. این سریع تر، آسان تر و ارزان تر از همیشه است.
- از پیچیدگی‌های رایج پیاده‌سازی، مانند اشکالات محتوای مختلط یا تنظیم نکردن بیت‌های هدر HTTP مناسب اجتناب کنید.
- از URL های نسبی یا طرحی استفاده کنید.
- برخی از موارد جالب جدید مانند HSTS و پین کردن گواهی را بررسی کنید
اسلایدها: SSL دارید؟
APIهای رسانه برای وب چند دستگاهی
توسط سام داتون و جان لیندن
همراه با گسترش دستگاه‌ها و پلتفرم‌های جدید در وب، ما شاهد رشد عظیمی در ارتباطات صوتی، تصویری و بلادرنگ هستیم. رسانه های آنلاین در حال تغییر روشی است که ما از انواع رسانه ها مصرف می کنیم.
یک مطالعه دولت بریتانیا نشان داد که 53 درصد از بزرگسالان هنگام تماشای تلویزیون "چند کار رسانه ای" انجام می دهند: استفاده از دستگاه های تلفن همراه برای اشتراک گذاری و مصرف رسانه. در بسیاری از کشورها تماشای تلویزیون کاهش یافته و تماشای آنلاین افزایش یافته است. برای مثال، در چین، در سال 2012، تنها 30 درصد از خانوارها در پکن تلویزیون تماشا می‌کردند که در مقایسه با 70 درصد در سال 2009 کاهش یافته بود. طبق نکات برجسته W3C در سال 2013 ، «در سال گذشته تماشای ویدیو در دستگاه‌های تلفن همراه دو برابر شده است . امسال در ایالات متحده، میانگین زمان صرف شده با رسانه های دیجیتال در روز از تماشای تلویزیون پیشی خواهد گرفت . مشاهده دیگر یک عمل منفعلانه نیست. در ایالات متحده، 87٪ از مصرف کنندگان سرگرمی می گویند که از حداقل یک دستگاه صفحه دوم هنگام تماشای تلویزیون استفاده می کنند. طبق گفته سیسکو ، «ویدئو ... تا سال 2017 بین 80 تا 90 درصد از ترافیک مصرف کنندگان جهانی خواهد بود». این معادل نزدیک به یک میلیون دقیقه ویدیو در هر ثانیه است.
پس چه چیزی برای توسعه دهندگان وب داریم؟ اکوسیستمی از API های رسانه برای وب باز: فناوری های استاندارد شده و قابل همکاری که در چندین پلت فرم کار می کنند.
غذای آماده
- WebRTC ارتباط بیدرنگ را در مرورگر فراهم می کند و اکنون به طور گسترده در موبایل و دسکتاپ پشتیبانی می شود. در مجموع در حال حاضر بیش از 1.2 میلیارد نقطه پایانی WebRTC وجود دارد.
- Web Audio ابزارهای پیچیده ای را برای سنتز و پردازش صدا فراهم می کند.
- Web MIDI که با Web Audio یکپارچه شده است، امکان تعامل با دستگاه های MIDI را فراهم می کند.
- عناصر صوتی و تصویری اکنون در بیش از 85 درصد مرورگرهای موبایل و دسکتاپ پشتیبانی می‌شوند.
- برنامه های افزودنی منبع رسانه را می توان برای پخش جریانی تطبیقی و تغییر زمان استفاده کرد.
- EME پخش محتوای محافظت شده را فعال می کند.
- رونوشت‌ها، زیرنویس‌ها و عنصر آهنگ ، زیرنویس‌ها، زیرنویس‌ها، ابرداده‌های زمان‌بندی‌شده، پیوند عمیق و جستجوی عمیق را فعال می‌کنند.
اسلایدها: APIهای رسانه برای وب چند دستگاهی