Chrome डेवलपर सम्मेलन - वेब प्लैटफ़ॉर्म की खास जानकारी खोलें

ग्रेग साइमन और एरिक सेडेल

Blink, Chrome का ओपन सोर्स रेंडरिंग इंजन है. Blink की टीम वेब को बेहतर बना रही है और डेवलपर को मिलने वाली समस्याओं को हल कर रही है.

हमने अप्रैल में लॉन्च किया गया था. इसलिए, पर्दे के पीछे की गतिविधियों में कई सुधार किए गए हैं.

सबसे पहले हमने अपने आधे स्रोत को मिटा दिया, जिसकी हमें ज़रूरत नहीं थी. हमारा काम अब भी पूरा नहीं हुआ है! हम बिना सोचे-समझे यह काम नहीं कर रहे हैं: कोड हटाने की प्रक्रिया, Chrome के उन उपयोगकर्ताओं से मिले कुल आंकड़ों पर आधारित होती है जिनकी पहचान छिपाकर रिपोर्ट की जाती है. ये आंकड़े, रिपोर्टिंग के लिए ऑप्ट-इन करते हैं.

हम हर छह हफ़्ते में एक नया डेवलपर एपीआई पब्लिश करते हैं: यह Chrome के शिपिंग शेड्यूल की तरह ही होता है.

Blink से लिंक करने के दौरान, हमने एक बड़ा बदलाव यह किया: इंटेंट सिस्टम को जोड़ने से पहले, हम हर बार Blink डेवलपर को एक सार्वजनिक सूचना भेजते हैं. इसमें, किसी सुविधा को जोड़ने या हटाने के हमारे इंटेंट के बारे में बताया जाता है. इसके बाद, हम काम शुरू करते हैं और कोड में बदलाव करते हैं! सुविधा की जांच के अगले दिन ही, उसे हमारे कैनरी बिल्ड में भेज दिया जाता है. यह सुविधा डिफ़ॉल्ट रूप से बंद होती है, लेकिन आप about:flags का इस्तेमाल करके इसे चालू कर सकते हैं.

इसके बाद, ईमेल पाने वाले लोगों की सार्वजनिक सूची में, हम प्रॉडक्ट शिप करने के इरादे के बारे में बताते हैं.

chromestatus.com पर जाकर, आप उन सुविधाओं की जानकारी देख सकते हैं जिन पर हमने काम किया है. साथ ही, वे सुविधाएं भी देखी जा सकती हैं जिन्हें हमने शिप किया है और जिन्हें बंद करने वाले हैं. आप Chromium रिलीज़ ब्लॉग भी देख सकते हैं. इसमें गड़बड़ियों और हमारे ट्रैकर डैशबोर्ड के लिंक हैं.

एक और बड़ा बदलाव यह है कि हम WebKit प्रीफ़िक्स हटा रहे हैं. इसका मकसद ब्लिंक प्रीफ़िक्स का इस्तेमाल करना नहीं है, बल्कि रन-टाइम फ़्लैग का इस्तेमाल करना है (न कि सिर्फ़ कंपाइल-टाइम फ़्लैग).

Android वेबव्यू एक बड़ी चुनौती है – लेकिन HTML5Test दिखाता है कि चीज़ें बेहतर हो रही हैं. हम हर जगह वेब प्लैटफ़ॉर्म एपीआई का एक सेट होने के मामले में डेस्कटॉप के काफ़ी करीब हैं (वेब ऑडियो इसका एक बेहतरीन उदाहरण है!)

लेकिन सॉसेज मशीन कैसे काम करती है? Blink में हम जो भी बदलाव करते हैं उसे तुरंत 30,000 से ज़्यादा टेस्ट के ज़रिए पूरा किया जाता है. ध्यान दें कि बाद में अतिरिक्त 'Chromium' टेस्ट किए जाते हैं. हम 24 घंटे पुलिस का इस्तेमाल करते हैं, जिसमें हज़ारों बॉट, हज़ारों मानदंड, और ऐसे सिस्टम होते हैं जो लाखों टूटे हुए वेब पेजों को हमारे इंजन पर डालते हैं, ताकि यह पक्का किया जा सके कि वह कहीं गिर न जाए. हम जानते हैं कि मोबाइल काफ़ी धीमा हो गया है और हम इसे बेहतर बनाने की पूरी कोशिश कर रहे हैं.

तो नया क्या है?

  • वेब कॉम्पोनेंट: एरिक बाइडलमैन के बारे में जानकारी देखें!
  • वेब ऐनिमेशन: मुश्किल, सिंक किए गए, और अच्छी परफ़ॉर्मेंस वाले ऐसे ऐनिमेशन जो जहां भी हो सके जीपीयू का इस्तेमाल करते हैं
  • आंशिक लेआउट: सिर्फ़ अपनी ज़रूरत के हिसाब से लेआउट बनाएं!
  • सीएसएस ग्रिड
  • रिस्पॉन्सिव इमेज: srcset या srcN या ?
  • टेक्स्ट का अपने-आप साइज़ ज़्यादा होने की सुविधा और एक जैसे सब-पिक्सल फ़ॉन्ट
  • Skia एक ग्राफ़िक सिस्टम है, जिसका इस्तेमाल Blink करता है. यह Windows पर GDI से DirectWrite की सुविधा पर जा रहा है

हम जानना चाहते हैं कि इस बारे में आपका क्या कहना है!

अगर आपको लग रहा है कि आपके खून में C++ है और आपको हमारे साथ C++ लिखना है, तो आपके लिए सभी कोड उपलब्ध हैं. आपको किसी को बताने या हमें प्रचार करने की ज़रूरत नहीं है. आप बस पैच पोस्ट कर सकते हैं या गड़बड़ी की शिकायत कर सकते हैं!

स्लाइड: ब्लिंक

सुरक्षा

परिसा तबरीज़

आज ज़्यादा लोग वेब से पहले पहले के मुकाबले और ज़्यादा जगहों से जुड़े हुए हैं.

हम अपने लैपटॉप, फ़ोन और टैबलेट से जुड़े हुए हैं और शायद जल्द ही व्यक्तिगत डिवाइस और ऐक्सेसरी के साथ भी. हम इंटरनेट को गैर-भरोसेमंद और कभी-कभी नुकसान पहुंचाने वाले नेटवर्क से भी ऐक्सेस करते हैं. आज-कल कई लोग ऑनलाइन प्लैटफ़ॉर्म पर जाते हैं, इसलिए ज़रूरी है कि हम अपने डेटा और लोगों की डेटा शामिल है.

इन सबसे ऊपर, डेवलपर के तौर पर हमें एसएसएल की ज़रूरत और व्यावहारिकता को समझना ज़रूरी है.

एसएसएल क्या है? इसका मतलब है सिक्योर सॉकेट लेयर. यह एक क्रिप्टोग्राफ़िक प्रोटोकॉल है, जिसे इंटरनेट पर कम्यूनिकेशन से जुड़ी सुरक्षा देने के लिए डिज़ाइन किया गया है. यह एन्क्रिप्शन और इंटिग्रिटी की मदद से निजता की गारंटी देता है, ताकि आपके इंटरनेट कनेक्शन के साथ छेड़खानी या छेड़छाड़ को रोका जा सके. एसएसएल में कुछ खामियां हैं, लेकिन यह इंटरनेट पर किसी भी तरह के डेटा कम्यूनिकेशन की सुरक्षा पक्का करने का सबसे पहला तरीका है.

एसएसएल पल्स के मुताबिक, एक साल पहले हमारे पास एसएसएल टेक्नोलॉजी को इस्तेमाल करने वालों की संख्या का करीब 15% से कम हिस्सा था; आज 50% से भी ज़्यादा लोग हमारी सेवाओं का इस्तेमाल कर रहे हैं.

दो संक्षिप्त रूप:

  • TLS: एसएसएल जैसे ज़्यादातर इंटेंट और मकसद के लिए. इसका मतलब है कि एसएसएल 3.1 का नाम बदलकर TLS हो गया है और TLS का नाम आईईटीएफ़ स्टैंडर्ड है. हालांकि, इन्हें बदला जा सकता है!

  • एचटीटीपीएस: यह एसएसएल पर एचटीटीपी है, जो एसएसएल और स्टैंडर्ड एचटीटीपी की सुरक्षा क्षमताओं की लेयर है. सबसे पहले, सार्वजनिक/निजी पासकोड क्रिप्टोग्राफ़ी का इस्तेमाल करके, क्लाइंट-सर्वर हैंडशेक की मदद से एक शेयर की गई कुंजी बनाएं. इस कुंजी का इस्तेमाल एसएसएल प्रोटोकॉल का दूसरा हिस्सा, बातचीत को एन्क्रिप्ट (सुरक्षित) करने के लिए करता है.

इंटरनेट पर नेटवर्किंग सुरक्षित, तुरंत, और तेज़ लग सकती है. ऐसा लगता है कि हम सीधे वेबसाइट से बात कर रहे हैं. हालांकि, असल में यह कोई सीधा संबंध नहीं होता. हमारी जानकारी वाई-फ़ाई राऊटर, इंटरनेट सेवा देने वाली कंपनी (आईएसपी), और आपके डिवाइस और वेबसाइट के बीच संभावित रूप से अन्य मध्यस्थ प्रॉक्सी के ज़रिए भेजी जाती है. एचटीटीपीएस के बिना, हमारी सभी बातचीत सादे टेक्स्ट में होती हैं.

समस्या यह है कि उपयोगकर्ता शायद ही कभी एचटीटीपीएस का इस्तेमाल करके पूरा यूआरएल टाइप करते हैं – या वे एचटीटीपी का इस्तेमाल करके किसी लिंक पर क्लिक करते हैं. इससे भी बदतर बात यह है कि बीच में (महिला) मैन इन द मिडल अटैक को माउंट करना और एचटीटीपीएस को एचटीटीपी से बदलना मुमकिन है. साल 2009 में पेश किया गया, SSLstrip नाम का एक टूल यही काम करता है. साल 2010 में, Firesheep ने ऐसे वाई-फ़ाई नेटवर्क के बारे में सुना जो साफ़ तौर पर कुकी भेजे जाते थे. इसका मतलब था कि आपके पास चैट में कॉन्टेंट सुनने या किसी के Facebook खाते में लॉग इन करने का विकल्प था.

लेकिन SSL (तुलनात्मक रूप से) सस्ता, तेज़ और डिप्लॉय करने में आसान है (ssllabs.com और इल्या ग्रिगोरिक की किताब High Performance Browser नेटवर्किंग देखें). सार्वजनिक पासकोड पिन करने की सुविधा से, वेबसाइट ऑपरेटर को यह तय करने में मदद मिलती है कि सर्टिफ़िकेट देने वाली कौनसी संस्था उनकी साइटों के लिए सर्टिफ़िकेट जारी कर सकती है.

"इस साल जनवरी 2010 में, Gmail ने हर काम के लिए डिफ़ॉल्ट रूप से एचटीटीपीएस का इस्तेमाल करना शुरू कर दिया था. ऐसा करने के लिए, हमें किसी भी अतिरिक्त मशीन और किसी खास हार्डवेयर को डिप्लॉय नहीं किया गया. हमारी प्रोडक्शन फ़्रंटएंड मशीनों में, एसएसएल < सीपीयू लोड का 1%, < हर कनेक्शन के लिए 10 केबी मेमोरी, और < नेटवर्क ओवरहेड का 2%...

अगर आपने अभी पढ़ना बंद कर दिया है, तो आपको सिर्फ़ एक बात याद रखनी होगी: एसएसएल की गणना करने के लिए, अब आपको कम्प्यूटेशनल रूप से इतना ज़्यादा खर्च नहीं करना पड़ेगा.”

ओवरक्लॉकिंग एसएसएल, एडम लैंगली (Google)

आखिर में, कुछ गड़बड़ियां आम तौर पर देखी जाती हैं:

  • मिला-जुला कॉन्टेंट: ऐसी साइटें जो एचटीटीपी के साथ-साथ एचटीटीपीएस का इस्तेमाल करती हैं. इससे आपका उपयोगकर्ता परेशान हो जाएगा, क्योंकि उसे कॉन्टेंट लोड करने के लिए 'अनुमति दें' बटन पर क्लिक करना होगा. (Chrome और Firefox असल में iframe से मिला-जुला कॉन्टेंट बार में दिखाते हैं.) पक्का करें कि एचटीटीपीएस पेज पर मौजूद आपके सभी रिसॉर्स, एचटीटीपीएस से लोड किए गए हों. इसके लिए, रिलेटिव या स्कीम-रिलेटिव यूआरएल का इस्तेमाल करें, जैसे कि <style src="//foo.com/style.css">
  • असुरक्षित कुकी: किसी एचटीटीपी कनेक्शन के ज़रिए, सुरक्षित तरीके से भेजी जाती हैं. कुकी हेडर पर सुरक्षित एट्रिब्यूट सेट करके इससे बचें. आपके पास नए "स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी" के इस्तेमाल का भी विकल्प है एसएसएल टेक्नोलॉजी का इस्तेमाल करने वाला हेडर ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस).

सीखने वाली अहम बातें

  • अगर आपको उपयोगकर्ताओं की निजता और सुरक्षा की चिंता है तो आपको एसएसएल का इस्तेमाल करना होगा. यह पहले से तेज़, आसान, और सस्ता है.
  • आम तौर पर लागू होने वाली गड़बड़ियों से बचें, जैसे कि मिले-जुले कॉन्टेंट से जुड़ी गड़बड़ियां या सही एचटीटीपी हेडर बिट सेट न करना.
  • रिलेटिव या स्कीम से मिलते-जुलते यूआरएल का इस्तेमाल करें.
  • कुछ नई मज़ेदार चीज़ें देखें. जैसे, एचएसटीएस और सर्टिफ़िकेट पिन करने की सुविधा

Slides: क्या आपके पास एसएसएल है?

कई डिवाइस वाले वेब के लिए मीडिया एपीआई

सैम डटन और जान लिंडन

वेब पर नए डिवाइसों और प्लैटफ़ॉर्म की संख्या बढ़ने के साथ-साथ, हम ऑडियो, वीडियो, और रीयल टाइम कम्यूनिकेशन में भी काफ़ी बढ़ोतरी देख रहे हैं. ऑनलाइन मीडिया, हर तरह के मीडिया का इस्तेमाल करने के हमारे तरीके को बदल रहा है.

यूनाइटेड किंगडम की सरकार की एक स्टडी में पता चला है कि 53% वयस्क लोग 'मीडिया मल्टी-टास्क' करते हैं टीवी देखते समय: मोबाइल डिवाइस पर मीडिया शेयर करने और इस्तेमाल करने के दौरान. कई देशों में टीवी देखने की सुविधा कम है और ऑनलाइन देखने की संख्या बढ़ रही है. उदाहरण के लिए, चीन में साल 2012 में बीजिंग में सिर्फ़ 30% परिवारों ने टीवी देखा. यह संख्या 2009 के मुकाबले 70% कम है. W3C हाइलाइट 2013 के मुताबिक, 'पिछले साल मोबाइल डिवाइस पर वीडियो देखने की संख्या दोगुनी हो गई है. इस साल अमेरिका में, हर दिन डिजिटल मीडिया पर बिताया गया औसत समय, टीवी देखने के मुकाबले ज़्यादा हो गया. अब कॉन्टेंट देखना कोई पैसिव कार्रवाई नहीं है. अमेरिका में, 87% मनोरंजन उपभोक्ताओं का कहना है कि वे टेलीविज़न देखते समय, कम से कम एक सेकंड-स्क्रीन डिवाइस का इस्तेमाल करते हैं.' Cisco के मुताबिक, 'वीडियो ... साल 2017 तक, दुनिया भर के उपभोक्ताओं से मिलने वाले ट्रैफ़िक का 80 से 90 प्रतिशत के दायरे में रहेगा'. इसका असर, हर सेकंड करीब दस लाख मिनट के वीडियो के बराबर होता है.

आइए जानते हैं कि हमारे पास वेब डेवलपर के लिए क्या है? ओपन वेब के लिए मीडिया एपीआई का नेटवर्क: स्टैंडर्ड और इंटरऑपरेबल टेक्नोलॉजी, जो कई प्लैटफ़ॉर्म पर काम करती हैं.

सीखने वाली अहम बातें

  • WebRTC ब्राउज़र में रीयलटाइम में बातचीत करता है. यह अब मोबाइल और डेस्कटॉप पर बड़े पैमाने पर काम करता है. कुल मिलाकर, पहले से ही 1.2 अरब WebRTC एंडपॉइंट हैं.
  • वेब ऑडियो, ऑडियो सिंथेसिस और प्रोसेसिंग के लिए बेहतरीन टूल उपलब्ध कराता है.
  • वेब ऑडियो के साथ इंटिग्रेट किया गया वेब MIDI, एमआईडीआई डिवाइसों के साथ इंटरैक्ट करने की अनुमति देता है.
  • ऑडियो और वीडियो एलिमेंट, अब 85% से ज़्यादा मोबाइल और डेस्कटॉप ब्राउज़र पर काम करते हैं.
  • मीडिया सोर्स एक्सटेंशन का इस्तेमाल, अडैप्टिव स्ट्रीमिंग और टाइम शिफ़्टिंग के लिए किया जा सकता है.
  • ईएमई, सुरक्षित कॉन्टेंट को चलाने की सुविधा देता है.
  • ट्रांसक्रिप्ट, कैप्शन, और ट्रैक एलिमेंट की मदद से सबटाइटल, कैप्शन, तय समय वाला मेटाडेटा, डीप लिंकिंग, और डीप सर्च जैसी सुविधाएं चालू हो जाती हैं.

Slides: कई डिवाइसों वाले वेब के लिए Media API