Blink
Greg Simon i Eric Seidel
Blink to mechanizm renderowania o otwartym kodzie źródłowym używany w Chrome. Zespół Blink rozwija sieć i rozwiązuje problemy, z którymi spotykają się deweloperzy.
Od czasu wprowadzenia tej funkcji w kwietniu wprowadziliśmy wiele ulepszeń.
Najpierw usunęliśmy połowę źródła, którego nie potrzebowaliśmy. To jeszcze nie koniec. Nie robimy tego w ciemno: usuwanie kodu odbywa się na podstawie anonimowych statystyk pochodzących od użytkowników Chrome, którzy wyrazili zgodę na zgłaszanie.
Co 6 tygodni publikujemy nowy interfejs API dla deweloperów: w tym samym harmonogramie co Chrome.
Jedną z większych zmian, którą wprowadziliśmy po odgałęzieniu się od Blinka, było dodanie systemu intencji: za każdym razem, gdy chcemy wprowadzić zmianę w platformie internetowej, wysyłamy publiczny komunikat do Blink dev, w którym informujemy o zamiarze dodania lub usunięcia funkcji. Potem kodujemy. Następnego dnia po przesłaniu funkcji jest ona już dostępna w wersjach Canary. Ta funkcja jest domyślnie wyłączona, ale możesz ją włączyć, korzystając z about:flags.
Następnie na naszej publicznej liście mailingowej ogłaszamy zamiar wysyłki.
Na stronie chromestatus.com możesz sprawdzić funkcje, nad którymi pracujemy, funkcje, które już udostępniliśmy, oraz te, które planujemy wycofać. Możesz też zajrzeć na blog o wersjach Chromium, gdzie znajdziesz linki do błędów i panelu śledzenia.
Kolejną dużą zmianą jest usunięcie prefiksów WebKit. Nie chodzi o używanie prefiksów Blink, ale o flagi czasu wykonywania (a nie tylko flagi czasu kompilacji).
Komponent WebView na Androidzie stanowił duże wyzwanie, ale HTML5Test pokazuje, że sytuacja się poprawia. W przypadku interfejsów API platformy internetowej jesteśmy znacznie bliżej desktopu (Web Audio to świetny przykład).
Jak działa maszyna do produkcji kiełbasy? Każda zmiana wprowadzona w Blink jest natychmiast sprawdzana za pomocą ponad 30 tys. testów, nie wspominając już o dodatkowych testach Chromium przeprowadzanych później. Używamy 24-godzinnego nadzoru z tysiącami botów, tysiącami punktów odniesienia i systemami, które wysyłają do naszego silnika miliony uszkodzonych stron internetowych, aby upewnić się, że nie ulegnie on awarii. Wiemy, że na urządzeniach mobilnych strona ładuje się znacznie wolniej, dlatego ciężko pracujemy nad rozwiązaniem tego problemu.
Co nowego?
- Komponenty sieciowe: obejrzyj wystąpienie Erica Bidelmana.
- Animacje w internecie: złożone, zsynchronizowane, wydajne animacje, które w miarę możliwości korzystają z GPU.
- Układ częściowy: obliczaj tylko to, czego potrzebujesz.
- Siatka CSS
- Obrazy elastyczne:
srcset lub srcN lub ? - Szybsze automatyczne dostosowywanie rozmiaru tekstu i spójność czcionek na poziomie poniżej piksela
- Skia, system graficzny używany przez Blink, przechodzi z GDI na DirectWrite w systemie Windows
Chcemy poznać Twoją opinię.
Jeśli C++ jest w Twojej krwi i chcesz z nami pisać w tym języku, cały nasz kod jest otwarty. Nie musisz nikomu o tym mówić ani nas o tym informować. Możesz po prostu opublikować poprawkę lub zgłosić błąd.
Prezentacje: Blink
Bezpieczeństwo
przez Parisa Tabriza
Obecnie więcej osób niż kiedykolwiek wcześniej korzysta z internetu, a dostęp do niego mają z większej liczby miejsc.
Jesteśmy połączeni z naszych laptopów, telefonów i tabletów, a wkrótce także z urządzeń osobistych i akcesoriów. Dostęp do internetu mamy z niepewnych, a czasem nawet wrogich sieci. Ponieważ coraz więcej aspektów naszego życia przenosi się do internetu, musimy podejmować działania na rzecz ochrony naszych danych i danych naszych użytkowników.
Jako deweloperzy musimy przede wszystkim zrozumieć, dlaczego protokół SSL jest niezbędny i praktyczny.
Co to jest SSL? Jest to skrót od Secure Sockets Layer. Jest to protokół kryptograficzny zaprojektowany w celu zapewnienia bezpieczeństwa komunikacji w internecie. Zapewnia prywatność dzięki szyfrowaniu i integralności, aby zapobiec szpiegowaniu lub modyfikowaniu połączenia internetowego. Protokół SSL ma swoje wady, ale jest najlepszym, a w istocie jedynym sposobem na zapewnienie bezpieczeństwa komunikacji danych w internecie.
Według SSL Pulse rok temu stosowanie protokołu SSL wynosiło około 15%. Obecnie jest to ponad 50%.
2 skróty:
TLS: w większości przypadków taki sam jak SSL. Dokładnie rzecz biorąc, protokół SSL 3.1 został przemianowany na TLS, a TLS jest nazwą standardu IETF. Ale są one zamienne.
HTTPS: to HTTP przez SSL, czyli nakładanie funkcji bezpieczeństwa SSL i standardowego HTTP. Najpierw odbywa się wymiana kluczy między klientem a serwerem, która wykorzystuje szyfrowanie kluczem publicznym/prywatnym do utworzenia klucza wspólnego. Druga część protokołu SSL wykorzystuje ten klucz do szyfrowania komunikacji.
Nawiązywanie kontaktów w internecie może wydawać się bezpieczne, szybkie i wygodne. Mam wrażenie, że rozmawiamy bezpośrednio ze stroną internetową. W rzeczywistości nie ma bezpośredniego połączenia. Nasze komunikaty przechodzą przez router Wi-Fi, dostawcę usług internetowych i potencjalnie inne pośrednie serwery proxy między Twoim urządzeniem a stroną internetową. Bez HTTPS cała nasza komunikacja jest w postaci zwykłego tekstu.
Problem w tym, że użytkownicy rzadko wpisują pełny adres URL z protokołem HTTPS lub klikają link z protokołem HTTP. Co gorsza, można przeprowadzić atak typu „człowiek w środku” i zastąpić HTTPS protokołem HTTP. W 2009 r. pojawiło się narzędzie SSLstrip, które właśnie to robi. Firesheep z 2010 r. po prostu nasłuchiwał otwartych sieci Wi-Fi w celu wykrycia ciasteczek wysyłanych w pełnym szyfrowaniu. Oznaczało to, że można było podsłuchiwać czaty lub logować się na czyjeś konto na Facebooku.
Jednak SSL jest (względnie) tani, szybki i łatwy do wdrożenia (sprawdź ssllabs.com i książkę Ilya Grigorik High Performance Browser Networking). Pinning publicznego klucza ma na celu umożliwienie operatorom witryn ograniczenie liczby urzędów certyfikacji, które mogą wystawiać certyfikaty dla ich witryn.
„W styczniu tego roku (2010 r.) Gmail domyślnie zaczął używać protokołu HTTPS. Aby to zrobić, nie musieliśmy wdrażać żadnych dodatkowych maszyn ani specjalnego sprzętu. Na naszych produkcyjnych maszynach front-end SSL odpowiada za mniej niż 1% obciążenia procesora, mniej niż 10 KB pamięci na połączenie i mniej niż 2% narzutu sieciowego.
Jeśli chcesz już przestać czytać, musisz zapamiętać tylko jedną rzecz: SSL nie jest już tak kosztowne pod względem przetwarzania”.
– Overclocking SSL, Adam Langley (Google)
Na koniec kilka najczęstszych błędów:
- Treści mieszane: witryny, które korzystają zarówno z protokołu HTTP, jak i HTTPS. Użytkownik może się zirytować, że musi kliknąć przycisk uprawnień, aby wczytać treści. (Chrome i Firefox blokują zawartość mieszaną w elementach iframe). Upewnij się, że wszystkie zasoby na stronie HTTPS są wczytywane przez HTTPS, używając względnych lub względnych adresów URL, np.
<style src="//foo.com/style.css"> - Niebezpieczne pliki cookie: wysyłane w pełnej postaci przez połączenie HTTP. Aby tego uniknąć, ustaw atrybut secure w nagłówkach plików cookie. Możesz też użyć nowego nagłówka „Strict Transport Security”, aby wymagać protokołu SSL Transport Layer Security (HSTS).
Wnioski
- Jeśli zależy Ci na ochronie prywatności i integralności danych użytkowników, musisz używać protokołu SSL. Jest szybszy, prostszy i tańszy niż kiedykolwiek wcześniej.
- Unikaj typowych błędów implementacji, takich jak błędy związane z mieszanymi treściami lub nieprawidłowym ustawieniem odpowiednich bitów nagłówka HTTP.
- Używaj adresów URL bezwzględnych lub zależnych od schematu.
- Poznaj kilka nowych, ciekawych funkcji, takich jak HSTS i pinowanie certyfikatów
Slajdy: Masz certyfikat SSL?
Interfejsy Media API na potrzeby internetu na wielu urządzeniach
Sam Dutton i Jan Linden
Wraz z rozwojem nowych urządzeń i platform internetowych obserwujemy ogromny wzrost liczby treści audio, wideo i komunikacji w czasie rzeczywistym. Internetowe media zmieniają sposób, w jaki korzystamy z mediów.
Badanie przeprowadzone przez brytyjski rząd wykazało, że 53% dorosłych oglądających telewizję jednocześnie korzysta z urządzeń mobilnych do udostępniania i oglądania multimediów. W wielu krajach oglądalność telewizji spada, a oglądalność online rośnie. Na przykład w 2012 r. w Chinach tylko 30% gospodarstw domowych w Pekinie oglądało telewizję, podczas gdy w 2009 r. było to 70%. Według W3C Highlights 2013 „w ciągu ostatniego roku oglądanie filmów na urządzeniach mobilnych podwoiło się”. W tym roku w Stanach Zjednoczonych średni czas korzystania z mediów cyfrowych dziennie przekroczy czas oglądania telewizji. Oglądanie nie jest już czynnością bierną. W Stanach Zjednoczonych 87% konsumentów korzystających z rozrywki deklaruje, że podczas oglądania telewizji używa co najmniej jednego drugiego ekranu. Według Cisco „do 2017 r. filmy będą stanowić od 80 do 90% globalnego ruchu generowanego przez konsumentów”. Oznacza to prawie milion minut filmów w każdej sekundzie.
Co mamy dla programistów stron internetowych? Ekosystem interfejsów API multimediów dla otwartej sieci: ustandaryzowane, interoperacyjne technologie, które działają na wielu platformach.
Wnioski
- WebRTC umożliwia komunikację w czasie rzeczywistym w przeglądarce i jest obecnie szeroko obsługiwany na urządzeniach mobilnych i komputerach. Łącznie jest już ponad 1,2 mld punktów końcowych WebRTC.
- Web Audio zawiera zaawansowane narzędzia do syntezy i przetwarzania dźwięku.
- Web MIDI, zintegrowany z Web Audio, umożliwia interakcję z urządzeniami MIDI.
- Elementy audio i wideo są teraz obsługiwane w ponad 85% przeglądarek mobilnych i na komputery.
- Rozszerzenia źródła multimediów można używać do adaptacyjnego przesyłania strumieniowego i przesuwania w czasie.
- EME umożliwia odtwarzanie treści chronionych.
- Transkrypcje, napisy i element utworu umożliwiają tworzenie napisów, metadanych z czasem, precyzyjnych linków i precyzyjnych wyszukiwań.
Prezentacje: interfejsy Media API na potrzeby przeglądarek na wiele urządzeń.