Google-მა Chrome 153 სტაბილურ არხში 8 სექტემბერს გამოუშვა დესკტოპისთვის, Android-ისა და iOS-ისთვის. ეს პირველი ვერსიაა, რომელიც Google-ის მიერ მარტში გამოცხადებული ორკვირიანი გამოშვების ციკლით გამოვიდა, და იმავე დღეს გამოქვეყნებული გამოშვების შენიშვნები აჩვენებს, როგორ გამოიყურება «ორკვირიანი» Chrome პრაქტიკაში: ორი ახალი HTML-ელემენტი კამერასა და მიკროფონზე წვდომისთვის, მეხსიერების თვალსაზრისით უსაფრთხო XML-პარსერი Rust-ზე, რამდენიმე დამატება CSS-სა და JavaScript-ში და მოძველებული ფუნქციების სია, რომელიც ჩუმად ხურავს Privacy Sandbox-ის უმეტეს ნაწილს.
Chrome 154 22 სექტემბერს გამოვა, იუწყება 9to5Google, რომელიც ასევე გადმოსცემს, როგორ ხსნის Google დაჩქარებულ რიტმს: შესწორებები მომხმარებლებამდე უფრო სწრაფად აღწევს, ხოლო მცირე გამოშვება აადვილებს რეგრესიის აღმოჩენას, თუ ის მაინც გაიპარება.
კამერა და მიკროფონი HTML-ელემენტები ხდება
დეველოპერებისთვის მთავარი სიახლე ე. წ. შესაძლებლობის ელემენტების (capability elements) წყვილია. <camera> ელემენტი ვიდეოს ჩაწერას ითხოვს, <microphone> ელემენტი — აუდიოს ჩაწერას. რეიჩელ ენდრიუს პოსტში «New in Chrome 153» ისინი აღწერილია როგორც «declarative, user-activated HTML controls» — დეკლარაციული, მომხმარებლის მიერ გააქტიურებადი HTML-კონტროლები: ღილაკს ბრაუზერი თავად ხატავს, მომხმარებელმა მასზე უნდა დააჭიროს და მხოლოდ ამის შემდეგ ჩნდება ნებართვის მოთხოვნა ან იწყება ნაკადი.
ისინი <usermedia> ელემენტს ეფუძნება, რომელიც ივნისში Chrome 151-ში გამოვიდა. იმ ადრინდელ პოსტში მარი ვიანამ და მინ ლემ ლოგიკა ახსნეს. ბრაუზერის მიერ კონტროლირებულ ღილაკზე დაჭერა არის «a trusted signal of intent» — განზრახვის სანდო სიგნალი, და ეს მნიშვნელოვანია, რადგან სწორედ ის ნებართვის მოთხოვნები, რომლებსაც სკრიპტი მომხმარებლის აშკარა მოქმედების გარეშე უშვებს, ბრაუზერები სულ უფრო ხშირად ბლოკავენ ან მალავენ. ელემენტს აღდგენის გზაც აქვს: თუ მომხმარებელმა კამერაზე წვდომა თვეების წინ უარყო, ელემენტზე შეხება «triggers a specialized recovery flow that lets you re-enable your camera or microphone instantly on the page, without navigating complex browser settings» — უშვებს აღდგენის სპეციალურ სცენარს, რომელიც კამერის ან მიკროფონის ხელახლა ჩართვის საშუალებას პირდაპირ გვერდზე, ბრაუზერის რთულ პარამეტრებში ხეტიალის გარეშე იძლევა.
სტილიზაციის წესები განზრახ მკაცრია, რომ ღილაკის შენიღბვა შეუძლებელი იყოს: <usermedia>-ს პოსტში ჩამოთვლილია ტექსტის მინიმალური კონტრასტი 3:1, გამჭვირვალობისა და უარყოფითი მინდვრების აკრძალვა, ხოლო ტრანსფორმაციები შემოიფარგლება 2D-გადაადგილებითა და პროპორციული მასშტაბირებით. ახალი ერთშესაძლებლობიანი ელემენტები ინარჩუნებს, ბეტა-პოსტის სიტყვებით, «identical security model, strict styling constraints, and built-in permission recovery path as the <usermedia> MVP» — იმავე უსაფრთხოების მოდელს, სტილიზაციის მკაცრ შეზღუდვებსა და ნებართვის აღდგენის ჩაშენებულ გზას, რაც <usermedia> MVP-ს აქვს.
მეხსიერების თვალსაზრისით უსაფრთხო XML-ის დამუშავება
Chrome 153 რამდენიმე გავრცელებული სცენარისთვის XML-ის დამუშავებას Rust-ზე დაწერილ იმპლემენტაციაზე გადააქვს. გამოშვების შენიშვნებში დასახელებულია DOMParser, XMLHttpRequest-ის responseXML თვისება, ასევე დამოუკიდებელი და გარე SVG-გამოსახულებები. XSLT-სცენარებს ეს ცვლილება არ ეხება. Google-ის გაცხადებული მიზანი, ბეტა-პოსტის მიხედვით, არის «eliminate potential memory corruption bugs while maintaining full compatibility with existing web specifications» — მეხსიერების დაზიანების პოტენციური შეცდომების აღმოფხვრა არსებულ ვებ-სპეციფიკაციებთან სრული თავსებადობის შენარჩუნებით.
საიტის მფლობელისთვის პრაქტიკული მნიშვნელობა SVG-ს აქვს. SVG-ფაილებად მიწოდებული ლოგოები, ხატულები და ილუსტრაციები ახლა ახალ პარსერში გადის. Google ამბობს, რომ თავსებადობა შენარჩუნებულია და არაფრის გაკეთება არ არის საჭირო, მაგრამ თუ განახლების შემდეგ რომელიმე SVG-რესურსი სხვანაირად გამოისახება, პირველ რიგში სწორედ ეს ცვლილება უნდა შეამოწმოთ.
დამატებები CSS-სა და JavaScript-ში
CSS-ის ორი ცვლილება გადახვევას ეხება. overflow თვისება ახლა გადახვევის მნიშვნელობას clip-თან ერთად იღებს, ასე რომ overflow: scroll clip ერთ ღერძზე გადახვევის კონტეინერს ქმნის, ხოლო მეორე ღერძი ადგილზე ჩამოჭრილი რჩება. გამოშვების შენიშვნებში აღნიშნულია, რომ ეს position: sticky-ს თითოეული ღერძისთვის სხვადასხვა წინაპარი გადახვევის კონტეინერით შეზღუდვის საშუალებას იძლევა. ახალი scroll-axis-lock თვისება დეველოპერს საშუალებას აძლევს, ბრაუზერს უთხრას, რომ გადახვევის ჟესტი ერთ ღერძზე არ მიაბას, როცა დიაგონალური გადახვევაა სასურველი.
JavaScript TC39-ის ორ წინადადებას იძენს. Iterator.prototype.join() იტერატორის გამონატანს სტრიქონად აერთიანებს Array.prototype.join()-ის მსგავსად. Joint Iteration ამატებს Iterator.zip()-სა და Iterator.zipKeyed()-ს, რომლებიც რამდენიმე იტერირებად ობიექტს სინქრონულად გადიან და მასივებს ან გასაღებიან ობიექტებს აბრუნებენ; რეჟიმებია «shortest» ნაგულისხმევად, «longest» არასავალდებულო შევსებით და «strict», რომელიც სიგრძეების განსხვავებისას TypeError-ს აგდებს.
გარდა ამისა, Chrome 153 Media Source Extensions-ის მეშვეობით Immersive Audio Model and Formats კონტეინერს — ღია, როიალტისგან თავისუფალ სივრცითი აუდიოს ფორმატს — დეკოდირებს, WebTransport-კავშირებს მომხმარებლის HTTP-ჰედერების გადაცემა შეუძლია, ხოლო Long Animation Frames API ახლა ვებ-ვორკერებიდანაც აგზავნის მონაცემებს.
Privacy Sandbox მოძველებულთა სიაში ხვდება
Chrome 153-ის შენიშვნებში ნათქვამია, რომ Protected Audience API, Shared Storage API, Attribution Reporting API, Related Website Sets და document.requestStorageAccessFor თითოეული «planned for deprecation and removal» — მოძველებულად გამოცხადებისა და წაშლისთვისაა დაგეგმილი. Related Website Sets-ის შემთხვევაში მიზეზად დასახელებულია ის, რომ მექანიზმი მესამე მხარის cookie-ების გარეშე ბრაუზერისთვის იყო შექმნილი, Chrome-მა კი მათი შენარჩუნება გადაწყვიტა. 20 აგვისტოს ბეტა-პოსტში Related Website Sets და requestStorageAccessFor უკვე წასაშლელთა შორის იყო ჩამოთვლილი.
აქ მოულოდნელი არაფერია. 2025 წლის 17 ოქტომბერს ენტონი ჩავესმა, Google-ის ვიცე-პრეზიდენტმა Privacy Sandbox-ის მიმართულებით, განაცხადა, რომ Google Privacy Sandbox-ის ათ ტექნოლოგიას ხურავს, მათ შორის Topics-ს, Protected Audience-ს, Attribution Reporting-ს, Private Aggregation-ს Shared Storage-თან ერთად და Related Website Sets-ს, და მიზეზად დაასახელა «ecosystem feedback about their expected value and in light of their low levels of adoption» — ეკოსისტემის გამოხმაურება მათ მოსალოდნელ ღირებულებაზე და დანერგვის დაბალი დონე. ის პოსტი ჰპირდებოდა, რომ დეტალები «follow Chrome and Android processes for phasing out these technologies» — ამ ტექნოლოგიების ეტაპობრივი გაუქმების Chrome-ისა და Android-ის პროცესებს მიჰყვება. Chrome 153 სწორედ ის მომენტია, როცა ეს პროცესები გამოშვების შენიშვნებში ხილული ხდება.
რას ნიშნავს ეს თქვენი ბიზნესისთვის
თუ თქვენი საიტი კამერას ან მიკროფონს იყენებს, ახალი ელემენტების ადრეული დანერგვა ღირს. პიროვნების შემოწმება, ვირტუალური მორგება, სცენარი «დაასკანერეთ დოკუმენტი» — თითოეული მათგანი დღეს JavaScript-გამოძახებითა და ნებართვის მოთხოვნით იწყება, რომელსაც ბევრი მომხმარებელი რეფლექსურად უარყოფს. ბრაუზერის მიერ დახატული ღილაკი, რომელზეც მომხმარებელი თავად აჭერს, ადრე უარყოფილი ნებართვის აღდგენის ჩაშენებული გზით, ზუსტად იმ მომენტზე მუშაობს, სადაც ასეთი სცენარები ადამიანებს კარგავს. Chrome დღეს ერთადერთი ბრაუზერია, რომელსაც ეს ფუნქცია აქვს, ამიტომ ეს პროგრესული გაუმჯობესება უნდა იყოს: არსებული getUserMedia გზა სათადარიგოდ შეინარჩუნეთ.
თუ თქვენს სარეკლამო სტეკს ან ანალიტიკას ოდესმე რომელიმე Privacy Sandbox API ჰქონდა ინტეგრირებული, დროა ეს კოდი წაშალოთ. Attribution Reporting-ის, Protected Audience-ისა და Shared Storage-ის ინტეგრაციებს ძირითადად ad-tech-მომწოდებლები აკეთებდნენ და არა უშუალოდ საიტების მფლობელები, მაგრამ ტეგები და თანხმობის კონფიგურაციები, რომლებიც მათზე მიუთითებს, ჯერ კიდევ არსებობს. ჰკითხეთ თქვენს მომწოდებელს, რა მოხდება, როცა ეს API-ები გაქრება, და დარწმუნდით, რომ თქვენი კონვერსიების გაზომვა შეუმჩნევლად რომელიმე მათგანზე არ არის დამოკიდებული. მესამე მხარის cookie-ები რჩება, რაც ნიშნავს, რომ გაზომვის ის სქემა, რომელიც Sandbox-მდე გქონდათ, სწორედ ის არის, რაც რჩება.
Related Website Sets კონკრეტულ ჯგუფს ეხებოდა: კომპანიებს, რომლებსაც რამდენიმე დომენი აქვთ საერთო ავტორიზაციით ან კალათით. თუ თქვენ ნაკრები იმისთვის გამოაცხადეთ, რომ cookie-ები თქვენი ბრენდის დომენებს შორის გადადიოდეს, ეს მექანიზმი უქმდება. თავად Storage Access API რჩება; მიდის მხოლოდ ნაკრებზე დაფუძნებული მოკლე გზა და requestStorageAccessFor. ნებისმიერი დომენთაშორისი ავტორიზაცია ან შეკვეთის გაფორმება ახლავე შეამოწმეთ და არა მაშინ, როცა ამის შესახებ კლიენტი შეგატყობინებთ.
ამ გამოშვებაში არაფერი უნდა აფუჭებდეს ჩვეულებრივ მარკეტინგულ საიტს. XML-ისა და SVG-ის ცვლილება შეუმჩნეველი უნდა იყოს, CSS-ის დამატებები ნებაყოფლობით ირთვება, ხოლო JavaScript-მეთოდები ახალია და არა შეცვლილი. ჩვევა, რომელსაც ვურჩევთ და ყოველ საიტში, რომელსაც მხარდაჭერას ვუწევთ, ვნერგავთ, გასული კვირიდან არ შეცვლილა: ერთი ბრაუზერის პროფილი Beta არხზე და ორ კვირაში ერთხელ თქვენი ფორმების, შეკვეთის გაფორმებისა და კამერის ნებისმიერი სცენარის გავლა. Chrome 154 Beta უკვე გამოსულია; სტაბილური ის 22 სექტემბერს გახდება.
ჩვენი შეფასებით, Chrome 153 მოკრძალებული გამოშვებაა ერთი მნიშვნელოვანი სიგნალით. ფუნქციები ეტაპობრივია, მაგრამ მოძველებულთა სია ადასტურებს: ბრაუზერმა მესამე მხარის cookie-ების საკუთარი სარეკლამო API-ებით ჩანაცვლების მცდელობა შეწყვიტა. ბიზნესისთვის ეს აცილებს ცვლადს, რომელიც ექვსი წელი ვებ-ანალიტიკისა და რეკლამის გეგმებზე ეკიდა. დაგეგმეთ cookie-ებზე, თანხმობასა და პირველი მხარის მონაცემებზე დაყრდნობით, ხოლო ყველაფერს, რასაც Privacy Sandbox-ის იარლიყი აქვს, მოძველებულად მიიჩნიეთ.
