# Chromium Blog News and developments from the open source browser project This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## JetStream 3: A modern benchmark for high-performance, compute-intensive Web applications DevFeed: [JetStream 3: A modern benchmark for high-performance, compute-intensive Web applications]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2026-03-31T18:25:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [jetstream](), [Benchmark](), [benchmarking](), [Web](), [web applications]() Tags: [benchmark](), [benchmarking](), [browser](), [jetstream](), [none](), [the-fast-and-the-curious](), [web](), [web-applications]() ### AI overview This article introduces JetStream 3, a benchmark for high-performance, compute-intensive Web applications. It explains the benchmark's methodology, the reasons for updating JetStream 2, and the collaborative governance involving major browser-engine contributors. ### Source excerpt We're incredibly excited to announce the release of JetStream 3, built in close collaboration with Apple, Mozilla, and other partners in the web ecosystem! While we've covered the high-level details of this release in our shared announcement blog post, we wanted to take a moment here to dive a little deeper. In this post, we'll pull back the curtain on the benchmark itself, explore the methodology behind our choices, and share the motivations driving these major updates. Why Do We Benchmark, Anyway? Before we get into the "what," it helps to talk about the "why." Why do browser engineers care so much about benchmarks? At its core, benchmarking serves as a critical safety net for catching performance regressions before they ever reach users. But beyond that, benchmarks act as a powerful motivation function--a sort of "gamification" for browser engineers. Having a clear target helps us prioritize our efforts and decide exactly which optimizations deserve our focus. It also drives healthy competitiveness between different browser engines, which ultimately lifts the entire web ecosystem. Of course, the ultimate goal isn't just to make a number on a chart go up; it's to meaningfully improve user experience and real-world performance. Driven by Open Governance Just like Speedometer 3, JetStream 3 is the result of a massive collaborative effort across all major browser engines, including Apple, Mozilla, and Google. We adopted a strict consensus model for this release. This means we only added new workloads when everyone agreed they were valuable and representative. This open governance model has led to an incredibly productive collaboration with buy-in from multiple parties, ensuring the benchmark serves the best interests of the overall Web ecosystem. Ripe for an Update The last major release, JetStream 2, came out in 2019. In the technology space--and especially on the Web--six years is an eternity. There's a well-known concept in economics called Goodhart's Law, which stat ## Android Sets New Record for Mobile Web Performance DevFeed: [Android Sets New Record for Mobile Web Performance]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2026-03-25T17:01:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [web applications]() Tags: [android](), [benchmarks](), [browser](), [chrome](), [latency](), [mobile](), [none](), [performance](), [the-fast-and-the-curious](), [user-experience](), [web]() ### AI overview Android reports record mobile web-browsing performance on flagship devices, citing Speedometer and LoadLine benchmarks. The article explains that responsiveness and page-load speed are central to the Android web experience. ### Source excerpt A core part of the Android experience is the web. Whether you are browsing in Chrome or using one of the >90% of Android apps that utilize WebView, the speed of the web defines the speed of your phone. Today, we are proud to celebrate a major milestone: Android is now the fastest mobile platform for web browsing. Through deep vertical integration across hardware, the Android OS, and the Chrome engine, the latest flagship Android devices are setting new performance records, outperforming all other mobile competitors in the key web performance benchmarks Speedometer and LoadLine and providing a level of responsiveness previously unseen on mobile. Android flagship phones reach new high-scores in web performance benchmarks (Chrome 146, March 2026) Why web performance matters Web performance isn't just about high scores--it's about how your device feels every day. On Android, web content and its performance is central to the user experience. Whether searching for information, catching up on the latest news, or online-shopping, Android users spend a significant portion of their daily screen time interacting with web content. Chrome is one of the most popular Android apps in the US and worldwide. Furthermore, this usage increases sharply on tablets and foldables, where productivity use cases are key. While the web is clearly important, a great web experience necessitates a fast browser and device: Modern websites are highly complex, with more than 200 million active sites serving everything from blog posts with dynamic ad auctions to desktop-class productivity tools. This complexity makes for a demanding workload that can stress even powerful devices. To ensure a high-quality user experience, we focus on two critical pillars when evaluating web performance: responsiveness and page load speed. Speedometer: Measuring web responsiveness Speedometer is the collaborative industry standard used by all major browser engine developers to measure web app responsiveness. It simulates ## Bringing Chrome to ARM64 Linux Devices DevFeed: [Bringing Chrome to ARM64 Linux Devices]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2026-03-12T20:01:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Linux](), [Google](), [Extension](), [Chromium](), [Security](), [Artificial Intelligence](), [Malware](), [passwords](), [DGX Spark](), [data](), [real-time]() Tags: [ai](), [arm](), [chrome](), [chromium](), [data](), [dgx-spark](), [extensions](), [google](), [linux](), [malware](), [none](), [passwords](), [real-time](), [security]() ### AI overview Google announces the launch of Chrome for ARM64 Linux devices in Q2 2026, extending Chrome's availability across Arm-powered platforms. The release brings Google ecosystem integration, cross-device synchronization, extensions, translation, security protections, password management, and support for DGX Spark users. ### Source excerpt We're excited to announce that Google will launch Chrome for ARM64 Linux devices in Q2 2026, following the successful expansion of Chrome to Arm-powered macOS devices in 2020 and Arm-powered Windows devices in 2024. Launching Chrome for ARM64 Linux devices allows more users to enjoy the seamless integration of Google's most helpful services into their browser. This move addresses the growing demand for a browsing experience that combines the benefits of the open-source Chromium project with the Google ecosystem of apps and features. This release represents a significant undertaking to ensure that ARM64 Linux users receive the same secure, stable, and rich Chrome experience found on other platforms. Get the best of the Google ecosystem With Chrome, you are able to leverage the full power of the Google ecosystem, providing a more cohesive and feature-rich environment designed for convenience and cross-device continuity. By signing into a Google Account, your bookmarks, browsing history, and open tabs follow you across devices. You can easily access the best extensions the Chrome Web Store has to offer, without needing to use specialized tools or alter developer settings. And you can effortlessly translate webpages with a single click. Use the browser that is secure by design Chrome also offers the added benefit of Google's strongest security protections. Enabling Enhanced Protection in Safe Browsing offers real-time protection against phishing and malware by leveraging AI alongside Google's list of known threats. With the Google Pay integration you can easily and securely manage your payments, using Chrome autofill for an added level of convenience. And the Google Password Manager lets you securely store, generate, and sync complex passwords across all your devices, eliminating the need to memorize multiple logins. It goes beyond simple storage by actively monitoring your credentials for data breaches and providing "Password Checkup" alerts if any of your accounts are ## Reducing notification overload for a quieter browsing experience in Chrome DevFeed: [Reducing notification overload for a quieter browsing experience in Chrome]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-10-10T17:04:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Authorization](), [Android](), [Web](), [experiments]() Tags: [android](), [chrome](), [experiments](), [feature](), [launch](), [none](), [privacy](), [product](), [reduce](), [safety](), [testing]() ### AI overview Chrome is launching an automatic notification-permission revocation feature for sites with very low user engagement and high notification volume. The feature will roll out on Android and desktop, exclude installed web apps, notify users when permissions are removed, and allow permissions or auto-revocation to be restored or disabled. Testing reduced notification overload with little change in total clicks, while lower-volume sites saw increased clicks. ### Source excerpt We're constantly working to improve your browsing experience. To help you cut through the noise and reduce notification overload, we're launching a new feature to automatically remove notification permission for sites you haven't interacted with recently. Today, Chrome's Safety Check already does this for other permissions such as camera and location. The feature will be launched in Chrome on Android and desktop. Data indicates that users frequently receive a high volume of notifications, resulting in minimal engagement and high disruption. Less than 1% of all notifications receive any interaction from users. But notifications can be genuinely valuable and helpful. Therefore, this feature will only revoke permissions for sites when there is very low user engagement and a high volume of notifications being sent. This feature does not revoke notifications for any installed web apps. Chrome will inform you when notification permissions are removed. If you prefer to keep getting notifications from a particular website, you can easily re-grant the permission at any time through Safety Check or alternatively by visiting the site and enabling notifications again. You can also choose to turn off the auto-revocation feature entirely. We've already been testing this feature. Our test results show a significant reduction in notification overload with only a minimal change in total notification clicks. Our experiments also indicate that websites that send a lower volume of notifications are actually seeing an increase in clicks. This launch is part of our ongoing commitment to user safety, privacy, and control. We believe this change will lead to a cleaner, more focused browsing experience, and we'll continue to invest in ways to help you manage your online interactions and reduce distractions, so you can make the most of your time online. Posted by Archit Agarwal, Product Manager, Chrome ## Introducing Skia Graphite: Chrome's rasterization backend for the future DevFeed: [Introducing Skia Graphite: Chrome's rasterization backend for the future]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-07-08T17:46:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [GPU](), [Interaction to Next Paint](), [browser](), [OpenGL](), [shaders](), [Web](), [glsl]() Tags: [chrome](), [gpu](), [graphics](), [graphics-apis](), [interaction-to-next-paint](), [multithreading](), [none](), [performance](), [render](), [screen](), [shaders](), [the-fast-and-the-curious](), [vulkan](), [web]() ### AI overview The article introduces Skia Graphite, a new GPU rasterization backend for Chrome on Apple Silicon Macs. Graphite uses fewer code paths, supports modern graphics APIs such as Metal, Vulkan, and D3D12, and is multithreaded by default. It improved Motionmark 1.3 scores by almost 15% on a MacBook Pro M3 and improved several real-world performance metrics. ### Source excerpt Today's The Fast and the Curious post covers the launch of Skia's new rasterization backend, Graphite, in Chrome on Apple Silicon Macs. Graphite is instrumental in helping Chrome achieve exceptional scores on Motionmark 1.3 and is key to unlocking a ton of future improvements in Chrome Graphics. A brief history of Skia in Chrome In Chrome, Skia is used to render paint commands from Blink and the browser UI into pixels on your screen, a process called rasterization. Skia has powered Chrome Graphics since the very beginning. Skia eventually ran into performance issues as the web evolved and became more complex, which led Chrome and Skia to invest in a GPU accelerated rasterization backend called Ganesh. Over the years, Ganesh matured into a solid highly performant rasterization backend and GPU rasterization launched on all platforms in Chrome on top of GL (via ANGLE on Windows D3D9/11). However, Ganesh always had a GL-centric design with too many specialized code paths and the team was hitting a wall when trying to implement optimizations that took advantage of modern graphics APIs in a principled manner. This set the stage for the team to rethink GPU rasterization from the ground up in the form of a new rasterization backend, Graphite. Graphite was developed from the start to be principled by having fewer and more comprehensible code paths. This forward looking design helps take advantage of modern graphics APIs like Metal, Vulkan and D3D12 and paradigms like compute based path rasterization, and is multithreaded by default. Results With Graphite in Chrome, we increased our Motionmark 1.3 scores by almost 15% on a Macbook Pro M3. At the same time, we improved real world metrics like INP (interaction to next paint time), LCP (time to largest contentful paint), graphics smoothness (percent dropped frames), GPU process malloc memory usage, and others. This all means substantially smoother interactions, less stutter when scrolling, and less time waiting for sites to show ## Chrome achieves highest score ever on Speedometer 3.1, saving users millions of hours DevFeed: [Chrome achieves highest score ever on Speedometer 3.1, saving users millions of hours]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-06-05T17:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Benchmark](), [web applications](), [Latency](), [Optimization]() Tags: [2025](), [apple](), [benchmark](), [benchmarks](), [browser](), [chrome](), [css](), [html](), [javascript](), [json](), [macos](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [web-performance]() ### AI overview Chrome reports a 22% improvement on the Speedometer 3.1 benchmark since August 2024, achieving its highest score to date. The article explains that the work optimized rendering paths and components involved in web application responsiveness, including HTML parsing, JavaScript and JSON processing, DOM interaction, CSS layout, pixel rendering, and internal data structures. ### Source excerpt Update (6/10/2025): This blog was updated to reflect that testing was done using the Speedometer 3.1 benchmark, and resulted in a 22% performance improvement. The previous version incorrectly noted that the performance improvement was 10% and that the benchmark was Speedometer 3. Performance has always been one of the core pillars of Chrome and it's something we've never stopped investing in. Publicly available and open benchmarks, which we create in open collaboration with other browsers, are useful tools for tracking our overall progress, understanding new areas of improvement, and validating potential optimizations. In today's The Fast and the Curious post, we'd like to go through Chrome's recent work that enabled it to achieve the highest score ever on the Speedometer benchmark. For Speedometer, these optimizations have resulted in a 22% improvement since August 2024. That 22% improvement leads to better browser experiences, higher conversions for businesses, and deeper enjoyment of what the web has to offer. If each Chrome user used Chrome for just 10 minutes a day, these improvements collectively save 116 million hours or roughly 166 lifetimes worth of waiting around for websites to load and do things. Speedometer 3.1 score measured on Apple Macbook Pro M4 with MacOS 15 Speedometer is a benchmark created in open collaboration with other browsers and measures web application responsiveness through workloads that cover a large variety of different areas of the Blink rendering engine used in Chrome: HTML parsing JavaScript and JSON processing JavaScript and Document Object Model (DOM) interaction DOM manipulations (element insertion and removal) Text size computation (font shaping) Cascading Style Sheet (CSS) application and layout calculation Pixel rendering In essence, Speedometer tests critical components of the entire rendering pipeline. For a deeper dive into these individual parts, we recommend the presentation Life of a Script at Chrome University. Achievi ## Fighting Unwanted Notifications with Machine Learning in Chrome DevFeed: [Fighting Unwanted Notifications with Machine Learning in Chrome]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-05-08T16:59:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Machine learning](), [Android](), [online privacy](), [Security](), [synthetic-data](), [Open Source Models & Datasets](), [Language models](), [data]() Tags: [android](), [chrome](), [gemini](), [google](), [large-language-model](), [machine-learning](), [none](), [notifications](), [on-device](), [privacy](), [security](), [synthetic-data]() ### AI overview Chrome is introducing warnings for potentially deceptive or spammy notifications on Android. A local on-device machine learning model analyzes notification text, flags likely unwanted messages, and lets users unsubscribe, view the content, or allow future notifications. Notification contents remain on the device to protect privacy, and the model was trained with synthetic data generated by the Gemini large language model. ### Source excerpt Notifications in Chrome are a useful feature to keep up with updates from your favorite sites. However, we know that some notifications may be spammy or even deceptive. We've received reports of notifications diverting you to download suspicious software, tricking you into sharing personal information or asking you to make purchases on potentially fraudulent online store fronts. To defend against these threats, Chrome is launching warnings of unwanted notifications on Android. This new feature uses on-device machine learning to detect and warn you about potentially deceptive or spammy notifications, giving you an extra level of control over the information displayed on your device. When a notification is flagged by Chrome, you'll see the name of the site sending the notification, a message warning that the contents of the notification are potentially deceptive or spammy, and the option to either unsubscribe from the site or see the flagged content. An example of a notification flagged as possibly spam. If you choose to see the notification you will still see the option to unsubscribe or you can choose to always allow notifications from that site and not see warnings in the future. What you see when viewing a flagged notification. How It Works Chrome uses a local, on-device machine learning model to analyze notification content. This model identifies notifications that are likely to be unwanted. The model is trained on the textual contents of the notification, like the title, body, and action button texts. Notifications are end to end encrypted. The analysis of each message is done on-device and notification contents are not sent to Google, to protect user privacy. Due to the sensitive nature of notifications content, the model was trained using synthetic data generated by the Gemini large language model (LLM). The training data was evaluated against real notifications Chrome security team collected by subscribing to a variety of websites that were then classified by ## Announcing Supporters of Chromium-based Browsers DevFeed: [Announcing Supporters of Chromium-based Browsers]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-01-09T17:01:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [Chromium](), [linux foundation](), [Open Source](), [Google]() Tags: [announce](), [chromium](), [linux-foundation](), [none](), [open-source]() ### AI overview Google announced a partnership with the Linux Foundation and the launch of Supporters of Chromium-based Browsers, a fund intended to support open-source contributions and developers working on the Chromium ecosystem. ### Source excerpt Since Google announced the Chromium project in 2008, we have been excited to build on the great foundations of open-source web browsers and contribute to the continued development of a rich web platform. Today, Chromium is used by hundreds of different projects globally, including big browsers like Chrome, home electronics from LG, application frameworks like Electron and even custom applications like Bloomberg terminals and SpaceX capsule control software. In 2024, Google made over 100,000 commits to Chromium, accounting for ~94 percent of contributions. While we have no intention of reducing this investment, we continue to welcome others stepping up to invest more. Google also continues to invest heavily in the shared infrastructure of the Open Source project to "keep the lights on", including having thousands of servers endlessly running millions of tests, responding to hundreds of incoming bugs per day, ensuring the important ones get fixed, and constantly investing in code health to keep the whole project maintainable. This work represents hundreds of millions of US dollars in annual investment just for maintenance costs before any new feature, innovation or other business priorities can be addressed. Sustainable funding of critical open source infrastructure remains a hot industry-wide topic of discussion and over the years we've heard from many companies and developers about how critical the Chromium project is to their work. They've also shared how they would like to support the continued health of the project, beyond direct engineering support. Today Google is pleased to announce our partnership with The Linux Foundation and the launch of the Supporters of Chromium-based Browsers. The goal of this initiative is to foster a sustainable environment of open-source contributions towards the health of the Chromium ecosystem and financially support a community of developers who want to contribute to the project, encouraging widespread support and continued techno ## Making Chrome QUICer DevFeed: [Making Chrome QUICer]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-12-17T18:09:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [web applications]() Tags: [cache](), [chrome](), [cpu](), [dns](), [features](), [google](), [http](), [latency](), [memory](), [metrics](), [none](), [performance](), [server](), [tls](), [youtube]() ### AI overview Chrome's HTTP/3 performance work adds ORIGIN frame support for connection coalescing and Preferred Address support to reduce round-trip time. The article explains how avoiding unnecessary connections can reduce DNS, handshake, TLS, CPU, memory, and latency costs. ### Source excerpt In October 2020, Chrome enabled HTTP/3 by default. HTTP/3 (RFC 9114) runs over IETF QUIC (RFC9000). Default-enabling HTTP/3 in Chrome resulted in improved performance compared not only HTTP/1 and HTTP/2, but also Google QUIC. Benefits included reduced Google search latency and fewer rebuffers for YouTube. The journey to optimizing performance did not end when HTTP/3 was default enabled. Recent advancements include the implementation of the HTTP/3 ORIGIN frame (RFC 9412) and Server's Preferred Address (RFC 9000 Section 9.6). The former enhances connection coalescing, while the latter reduces a connection's round trip time (RTT). Both features have been enabled by default in M131, which was released to Stable on 11/19. ORIGIN Frame When a connection is established for a specific hostname, the server's certificate typically contains numerous other hostnames for which the server is authoritative. However, a client cannot immediately send requests for those other hostnames on that connection without first performing a DNS lookup for the other hostname and verifying that the IP address of the connection matches the resolved address. This additional DNS resolution introduces latency and significantly reduces the likelihood of connection pooling due to potential IP mismatches. The metrics from Chrome indicate that nearly 20% of HTTP/3 connections would be unnecessary if not for this IP mismatch. Creating a new connection, even with QUIC 0-RTT, is expensive in terms of latency, memory, and CPU usage. This is because: DNS resolution adds latency unless cached locally in Chrome's DNS cache. Both client and server must send multiple packets to complete a QUIC handshake. TLS necessitates CPU-intensive asymmetric cryptography on both ends. The congestion controller begins in its default state, potentially leading to under or over-sending. 0-RTT might fail. Non-safe requests aren't sent via 0-RTT. More connections consume more memory. Additionally, features like HTTP priorities (R ## How Chrome doubled its Speedometer scores on Android DevFeed: [How Chrome doubled its Speedometer scores on Android]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-12-04T14:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Android](), [Benchmark](), [V8](), [JavaScript](), [web browser](), [CSS](), [HTML]() Tags: [android](), [benchmark](), [chrome](), [css](), [html](), [javascript](), [none](), [performance](), [the-fast-and-the-curious](), [v8]() ### AI overview The article explains how Chrome more than doubled Speedometer 2.1 scores on many Android devices since Chrome M112. It attributes the gains to build optimizations, V8 and Blink improvements, and closer coordination with Android operating-system scheduling and SoC partners. ### Source excerpt Today's The Fast and the Curious post covers how Chrome achieved best-in-class Speedometer scores on mobile devices, resulting in faster and smoother web experiences for Android users. Chrome has always been about speed. Whether it's loading pages quickly, running complex web apps smoothly, or delivering a seamless browsing experience, performance is at the heart of our browser. And we're always looking for ways to make Chrome even faster. Over the last two years, we have been hard at work on a number of performance improvements for Android devices. We're excited to share some of the progress we've made. Speedometer on Android One of the key metrics we use to track Chrome's performance is the Speedometer benchmark. This benchmark is developed in collaboration with other major web browser engines and measures how quickly Chrome can complete interactions with web pages, including parsing/rendering HTML or CSS and running JavaScript. Since the release of Chrome M112, we've seen a significant increase in Speedometer 2.1 scores on Android devices [1]. In fact, on many devices, scores more than doubled, with the newest Snapdragon® 8 Elite Mobile Platform setting new records for Speedometer performance on mobile devices! These huge accomplishments are a testament to the work not only of the Chrome and Android teams, but also our silicon and SoC partners. Since Chrome M112, Speedometer 2.1 scores have more than doubled on many Android devices. [1] How Did We Do It? The improvements resulted from several changes, including: Build optimizations: We've made a number of changes to the way Chrome is built, which has resulted in faster code execution tuned to modern premium Android devices and SoCs. V8 and Blink improvements: Many improvements to the JavaScript engine (V8) and the rendering engine (Blink) have further boosted performance. Scheduling, OS and SoCs: We worked closely with Android partners to optimize the way Chrome interacts with the operating system and its thread ## Seamlessly use your passwords and addresses in Chrome across all devices DevFeed: [Seamlessly use your passwords and addresses in Chrome across all devices]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-08-20T16:01:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [browser](), [passwords](), [Google](), [data](), [Android](), [iOS]() Tags: [android](), [browser](), [chrome](), [data](), [google](), [ios](), [none](), [passwords]() ### AI overview Chrome is transitioning from its legacy sync model to an identity-based experience. After signing in, users will be able to access saved passwords, addresses, and other Google Account data across devices, with the updated model already available on iOS and planned for Android and Desktop. ### Source excerpt Last October, we introduced a new identity model on iOS (Chrome 118) and are excited to bring it to Android devices and Desktop soon. This model aligns closely with how you already use other Google apps and services. When we first launched Chrome sync back in 2009, powered by the Google Account, our goal then, as it is today, was simple: help users access their bookmarks, passwords, tabs and more, across devices. At the time, this was best achieved by a sync model: synchronizing device data with your account and therefore requiring both sign-in and enabling sync. Over the years, the digital world has changed and user expectations have evolved significantly. Cloud services emerged in 2010, and over the past 15 years, the concept of having a digital identity became more prevalent, especially through smartphones and mobile apps. Today, users increasingly expect to just sign in to get access to their stuff and sign out to keep it safe. Given this evolution of technology and user norms, we're continuing to make progress on transforming our legacy sync model into one that more seamlessly meets the expectation users have today. From the point of signing in to Chrome you'll get access to your saved passwords, addresses, and other data from your Google Account. Where relevant, we'll offer you the choice to sign into Chrome for a customized browsing experience on any device. For example, you can sign in and start to plan a trip on your phone during your commute, and then seamlessly finish it up on any device. Send tabs between your devices, find your bookmarks and use autogenerated passwords with ease. As always, you have control - we strive to provide an excellent browser experience regardless of whether you choose to sign in or not. Additionally, saving your history and open tabs to your account remains a separate opt-in after signing into Chrome. Stay tuned for updates on this change - already on iOS and coming to Android and Desktop soon. Posted by Claire Charron, Chrome ## Building a faster, smarter, Chromebook experience with the best of Google technologies DevFeed: [Building a faster, smarter, Chromebook experience with the best of Google technologies]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-06-12T18:55:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Google AI](), [Android](), [Linux](), [Kernel](), [Frameworks](), [Google]() Tags: [ai](), [android](), [chromebook](), [developers](), [devices](), [gemini](), [google](), [google-ai](), [innovation](), [kernel](), [linux](), [none](), [security](), [software](), [tech-stack](), [updates]() ### AI overview ChromeOS plans to incorporate substantial portions of the Android stack, including the Android Linux kernel and Android frameworks, to deliver Google AI features and other innovations faster. The change is intended to simplify engineering and improve interoperability among Chromebooks, phones, and accessories while preserving ChromeOS security, user experience, and management capabilities. ### Source excerpt ChromeOS will soon be developed on large portions of the Android stack to bring Google AI, innovations, and features faster to users. Over the last 13 years, we've evolved ChromeOS to deliver a secure, fast, and feature-rich Chromebook experience for millions of students and teachers, families, gamers, and businesses all over the world. With our recent announcements around new features powered by Google AI and Gemini, Chromebooks now give us the opportunity to put powerful tools in the hands of more people to help with everyday tasks. To continue rolling out new Google AI features to users at a faster and even larger scale, we'll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks, as part of the foundation of ChromeOS. We already have a strong history of collaboration, with Android apps available on ChromeOS and the start of unifying our Bluetooth stacks as of ChromeOS 122. Bringing the Android-based tech stack into ChromeOS will allow us to accelerate the pace of AI innovation at the core of ChromeOS, simplify engineering efforts, and help different devices like phones and accessories work better together with Chromebooks. At the same time, we will continue to deliver the unmatched security, consistent look and feel, and extensive management capabilities that ChromeOS users, enterprises, and schools love. These improvements in the tech stack are starting now but won't be ready for consumers for quite some time. When they are, we'll provide a seamless transition to the updated experience. In the meantime, we continue to be extremely excited about our continued progress on ChromeOS without any change to our regular software updates and new innovations. Chromebooks will continue to deliver a great experience for our millions of customers, users, developers and partners worldwide. We've never been more excited about the future of ChromeOS. Posted by Prajakta Gudadhe, Senior Director, Engineering, ChromeOS & Alexander Kusche ## How Chrome achieved the highest score ever on Speedometer 3 DevFeed: [How Chrome achieved the highest score ever on Speedometer 3]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-06-06T16:15:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [web applications]() Tags: [apple](), [benchmark](), [benchmarking](), [browser](), [chrome](), [dedupe](), [google](), [intel](), [memory](), [microsoft](), [mozilla](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [web-applications]() ### AI overview Chrome describes workload-focused optimizations that increased its Speedometer 3 score by 72% since May 2022. The work targets browser operations including string parsing, stylesheet deduplication, path drawing, form creation, selector handling, DOM parsing, and font rendering. ### Source excerpt Today's The Fast and the Curious post explores how Chrome achieved the highest score on the new Speedometer 3.0, an upgraded browser benchmarking tool to optimize the performance of Web applications. Try out Chrome today! Speedometer 3.0 is a recently published benchmark for measuring browser performance that was created as an industry collaboration between companies like Google, Apple, Mozilla, Intel, and Microsoft. This benchmark helped us identify areas in which we could optimize Chrome to deliver a faster browser experience to all our users. Here's a closer look at how we further optimized Chrome to achieve the highest score ever Speedometer 3, by carefully tracking its recent performance over time as the updated benchmark was being developed. Since the inception of Speedometer 3 in May 2022, we've driven a 72% increase in Chrome's Speedometer score - translating into performance gains for our users: Optimizing workloads By looking at the workloads in Speedometer and in which functions Chrome was spending the most time, we were able to make targeted optimizations to those functions that each drove an increase in Chrome's score. For example, the SpaceSplitString function is used heavily to turn space-separated strings such as those in "class='foo bar' " into a list representation. In this function we removed some unnecessary bound checks. When we detect that there are duplicated stylesheets, we dedupe them and reference a single stylesheet instance. We made an optimization to reduce the cost of drawing paths and arcs by tuning memory allocations. When creating form editors we detected some unnecessary processing that occurs when form elements are created. Within querySelector, we were able to detect what selector was commonly used and create a hot-path for that. We previously shared how we optimized innerHTML using specialized fast paths for parsing, an implementation that also made its way into WebKit. Some workloads in Speedometer 3 use DOMParser so we extended ## Introducing Shared Memory Versioning to improve slow interactions DevFeed: [Introducing Shared Memory Versioning to improve slow interactions]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-06-03T17:24:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [real user monitoring](), [Processes]() Tags: [browser](), [chrome](), [javascript](), [memory](), [metrics](), [none](), [performance](), [privacy](), [process](), [the-fast-and-the-curious](), [traces](), [web-platform]() ### AI overview The article describes Chrome's use of field data and anonymized Perfetto traces to investigate slow web interactions. It identifies redundant synchronous cookie reads from the network service as a source of contention and introduces shared memory versioning as the stated improvement. ### Source excerpt On the Chrome team, we believe it's not sufficient to be fast most of the time, we have to be fast all of the time. Today's The Fast and the Curious post explores how we contributed to Core Web Vitals by surveying the field data of Chrome responding to user interactions across all websites, ultimately improving performance of the web. As billions of people turn to the web to get things done every day, the browser becomes more responsible for hosting a multitude of apps at once, resource contention becomes a challenge. The multi-process Chrome browser contends for multiple resources: CPU and memory of course, but also its own queues of work between its internal services (in this article, the network service). This is why we've been focused on identifying and fixing slow interactions from Chrome users' field data, which is the authoritative source when it comes to real user experiences. We gather this field data by recording anonymized Perfetto traces on Chrome Canary, and report them using a privacy-preserving filter. When looking at field data of slow interactions, one particular cause caught our attention: recurring synchronous calls to fetch the current site's cookies from the network service. Let's dive into some history. Cookies under an evolving web Cookies have been part of the web platform since the very beginning. They are commonly created like this: document.cookie = "user=Alice;color=blue" And later retrieved like this: // Assuming a `getCookie` helper method: getCookie("user", document.cookie) Its implementation was simple in single-process browsers, which kept the cookie jar in memory. Over time, browsers became multi-process, and the process hosting the cookie jar became responsible for answering more and more queries. Because the Web Spec requires Javascript to fetch cookies synchronously, however, answering each document.cookie query is a blocking operation. The operation itself is very fast, so this approach was generally fine, but under heavy load s ## Manifest V2 phase-out begins DevFeed: [Manifest V2 phase-out begins]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-05-30T16:45:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Extension](), [Chrome](), [migration](), [Security](), [Security & Privacy](), [Document Object Model (DOM)](), [uBlock Origin Filters]() Tags: [chrome](), [collaboration](), [community](), [extension](), [extensions](), [feature](), [manifest](), [migration](), [none](), [performance](), [security](), [security-privacy](), [update]() ### AI overview Chrome has begun disabling extensions that still use Manifest V2. The article describes the transition to Manifest V3, which is intended to improve extension security, privacy, performance, and trustworthiness while preserving existing functionality. It highlights community-driven improvements, including user scripts, offscreen documents for DOM APIs, larger declarativeNetRequest rulesets, faster review of safe rule updates, and version rollback. More than 85% of actively maintained Chrome Web Store extensions were reported to use Manifest V3. ### Source excerpt Update (10/10/2024): We've started disabling extensions still using Manifest V2 in Chrome stable. Read more details in the MV2 support timeline documentation. In November 2023, we shared a timeline for the phasing out of Manifest V2 extensions in Chrome. Based on the progress and feedback we've seen from the community, we're now ready to roll out these changes as scheduled. We've always been clear that the goal of Manifest V3 is to protect existing functionality while improving the security, privacy, performance and trustworthiness of the extension ecosystem as a whole. We appreciate the collaboration and feedback from the community that has allowed us - and continues to allow us - to constantly improve the extensions platform. Addressing community feedback We understand migrations of this magnitude can be challenging, which is why we've listened to developer feedback and spent years refining Manifest V3 to support the innovation happening across the extensions community. This included adding support for user scripts and introducing offscreen documents to allow extensions to use DOM APIs from a background context. Based on input from the extension community, we also increased the number of rulesets for declarativeNetRequest, allowing extensions to bundle up to 330,000 static rules and dynamically add a further 30,000. You can find more detail in our content filtering guide. This month, we made the transition even easier for extensions using declarativeNetRequest with the launch of review skipping for safe rule updates. If the only changes are for safe modifications to an extension's static rule list for declarativeNetRequest, Chrome will approve the update in minutes. Coupled with the launch of version roll back last month, developers now have greater control over how their updates are deployed. Ecosystem progress After we addressed the top issues and feature gaps blocking migration last year, we saw an acceleration of extensions migrating successfully to Manifest V ## Multi-tasking with Minimized Custom Tabs DevFeed: [Multi-tasking with Minimized Custom Tabs]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-05-29T16:08:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [picture-in-picture](), [browsers](), [App]() Tags: [browser](), [chrome](), [developers](), [feature](), [latest-release](), [none](), [picture-in-picture](), [web]() ### AI overview Chrome introduces Minimized Custom Tabs, allowing users to minimize a Custom Tab into a floating picture-in-picture window and switch between native app and web content. The feature is applied automatically to developers using Chrome Custom Tabs starting with Chrome version M124. ### Source excerpt In the latest release of Chrome, we're introducing Minimized Custom Tabs, a feature that allows users to effortlessly transition between native app and web content. With a simple tap on the down button in the Chrome Custom Tabs toolbar, users can minimize a Custom Tab into a compact, floating picture-in-picture window. This seamless integration enables multi-tasking across surfaces, enhancing the in-app web browsing experience. By tapping on the floating window, users can easily maximize the tab, restoring it to its original size. How to get started Because this change happens at the browser level, developers who use Chrome Custom Tabs will see this change automatically applied starting with Chrome version M124. End users will see the Minimize icon in the Chrome Custom Tab toolbar. Please note that this is a change in Chrome, and we hope other browsers will adopt similar functionality. Posted by Victor Gallet, Senior Product Manager ## Chrome enables Kyber post-quantum key exchange by default for TLS 1.3 and QUIC DevFeed: [Chrome enables Kyber post-quantum key exchange by default for TLS 1.3 and QUIC]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-05-23T17:19:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [Post-quantum cryptography](), [Chrome](), [chrome security](), [Google](), [TLS (Transport Layer Security)](), [Security]() Tags: [chrome](), [chrome-security](), [google](), [none](), [post-quantum-cryptography](), [quic](), [security](), [tls]() ### AI overview Google announces that Chrome 124 enables the latest Kyber draft specification by default for TLS 1.3 and QUIC on desktop platforms. The rollout exposed existing TLS middlebox bugs, and Chrome provides a temporary enterprise opt-out policy while fixes are deployed. ### Source excerpt Google and many other organizations, such as NIST, IETF, and NSA, believe that migrating to post-quantum cryptography is important due to the large risk posed by a cryptographically-relevant quantum computer (CRQC). In August, we posted about how Chrome Security is working to protect users from the risk of future quantum computers by leveraging a new form of hybrid post-quantum cryptographic key exchange, Kyber (ML-KEM)1. We're happy to announce that we have enabled the latest Kyber draft specification by default for TLS 1.3 and QUIC on all desktop Chrome platforms as of Chrome 124.2 This rollout revealed a number of previously-existing bugs in several TLS middlebox products. To assist with the deployment of fixes, Chrome is offering a temporary enterprise policy to opt-out. Launching opportunistic quantum-resistant key exchange is part of Google's broader strategy to prioritize deploying post-quantum cryptography in systems today that are at risk if an adversary has access to a quantum computer in the future. We believe that it's important to inform standards with real-world experience, by implementing drafts and iterating based on feedback from implementers and early adopters. This iterative approach was a key part of developing QUIC and TLS 1.3. It's part of why we're launching this draft version of Kyber, and it informs our future plans for post-quantum cryptography. Chrome's post-quantum strategy prioritizes quantum-resistant key exchange in HTTPS, and increased agility in certificates from the Web PKI. While PKI agility may appear somewhat unrelated, its absence has contributed to significant delays in past cryptographic transitions and will continue to do so until we find a viable solution in this space. A more agile Web PKI is required to enable a secure and reliable transition to post-quantum cryptography on the web. To understand this, let's take a look at HTTPS and the current state of post-quantum cryptography. In the context of HTTPS, cryptography is pr ## How Machine Learning improved the Chrome address bar on Windows, Mac and ChromeOS DevFeed: [How Machine Learning improved the Chrome address bar on Windows, Mac and ChromeOS]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-04-29T16:02:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Google AI](), [Training AI Models]() Tags: [chrome](), [machine-learning](), [none](), [search](), [software-engineering](), [windows]() ### AI overview Chrome M124 integrates machine-learning models into the desktop omnibox to make web-page suggestions more precise and relevant. The article describes replacing inflexible hand-tuned scoring formulas with an ML-trained scoring model for a feature used at very large scale. ### Source excerpt Used billions of times each day, the Chrome address bar (which we call the "omnibox") is a powerful tool to make searching the web easier, whether you're trying to quickly find your tabs or bookmarks, return to a web page you previously visited, or find information. With the latest release of Chrome (M124), we're integrating machine learning models to power the Chrome omnibox on desktop, so that web page suggestions are more precise and relevant to you. In the future, these models will also help improve the relevance scoring of search suggestions. Here's a closer look at some of the important insights that help our team build this integration and where we hope the new model takes us. How we got here As the engineering lead for the team responsible for the omnibox, every launch feels special, but this one is truly near and dear to my heart. When I first started working on the Chrome omnibox, I asked around for ideas on how we could make it better for users. The number one answer I heard was, "improve the scoring system." The issue wasn't that the scoring was bad. In fact, the omnibox often feels magical in its ability to surface the URL or query you want! The issue was that it was inflexible. A set of hand-built and hand-tuned formulas did the job well, but were difficult to improve or to adapt to new scenarios. As a result, the scoring system went largely untouched for a long time. For most of that time, an ML-trained scoring model was the obvious path forward. But it took many false starts to finally get here. Our inability to tackle this challenge for so long was due to the difficulty of replacing the core mechanism of a feature used literally billions of times every day. Software engineering projects are sometimes described as "building the plane while flying it." This project felt more like "replacing all the seats in every plane in the world while they're all flying." The scale was enormous and the changes are felt directly by every user. This ambitious underta ## Fighting cookie theft using device bound sessions DevFeed: [Fighting cookie theft using device bound sessions]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-04-02T16:06:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Docro Hijacker](), [Malware](), [Authentication](), [Chrome](), [Web](), [Social engineering](), [API](), [GitHub]() Tags: [api](), [authentication](), [browser](), [chrome](), [github](), [malware](), [none](), [on-device](), [open](), [privacy](), [social-engineering](), [web]() ### AI overview The article explains how cookie-stealing malware extracts authentication cookies from browsers, allowing attackers to bypass protections such as two-factor authentication. It presents Device Bound Session Credentials (DBSC), an open web capability that binds authentication sessions to a device so stolen cookies become less useful and on-device detection and cleanup become more effective. ### Source excerpt Cookies - small files created by sites you visit - are fundamental to the modern web. They make your online experience easier by saving browsing information, so that sites can do things like keep you signed in and remember your site preferences. Due to their powerful utility, cookies are also a lucrative target for attackers. Many users across the web are victimized by cookie theft malware that gives attackers access to their web accounts. Operators of Malware-as-a-Service (MaaS) frequently use social engineering to spread cookie theft malware. These operators even convince users to bypass multiple warnings in order to land the malware on their device. The malware then typically exfiltrates all authentication cookies from browsers on the device to remote servers, enabling the attackers to curate and sell the compromised accounts. Cookie theft like this happens after login, so it bypasses two-factor authentication and any other login-time reputation checks. It's also difficult to mitigate via anti-virus software since the stolen cookies continue to work even after the malware is detected and removed. And because of the way cookies and operating systems interact, primarily on desktop operating systems, Chrome and other browsers cannot protect them against malware that has the same level of access as the browser itself. To address this problem, we're prototyping a new web capability called Device Bound Session Credentials (DBSC) that will help keep users more secure against cookie theft. The project is being developed in the open at github.com/WICG/dbsc with the goal of becoming an open web standard. By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value. We think this will substantially reduce the success rate of cookie theft malware. Attackers would be forced to act locally on the device, which makes on-device detection and cleanup more effective, both for anti-vi ## Speedometer 3: Building a benchmark that represents the web DevFeed: [Speedometer 3: Building a benchmark that represents the web]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-03-11T16:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Benchmark](), [benchmarking](), [Latency](), [web applications](), [browsers](), [WebKit](), [V8]() Tags: [benchmark](), [benchmarking](), [benchmarks](), [browsers](), [collaboration](), [governance](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [user-experience](), [web](), [web-applications](), [web-performance](), [workflows]() ### AI overview This article announces Speedometer 3.0, an updated browser benchmark designed to represent modern web applications. Developed through collaboration among major browser-engine teams, it improves score calculation and detail while adding more diverse workloads to guide browser performance optimization and better reflect user experiences. ### Source excerpt Today's The Fast and the Curious post covers the release of Speedometer 3.0 an upgraded browser benchmarking tool to optimize the performance of Web applications. In collaboration with major web browser engines, Blink/V8, Gecko/SpiderMonkey, and WebKit/JavaScriptCore, we're excited to release Speedometer 3.0. Benchmarks, like Speedometer, are tools that can help browser vendors find opportunities to improve performance. Ideally, they simulate functionality that users encounter on typical websites, to ensure browsers can optimize areas that are beneficial to users. Let's dig into the new changes in Speedometer 3.0. Applying a multi-stakeholder governance model Since its initial release in 2014 by the WebKit team, browser vendors have successfully used Speedometer to optimize their engines and improve user experiences on the web. Speedometer 2.0, a result of a collaboration between Apple and Chrome, followed in 2018, and it included an updated set of workloads that were more representative of the modern web at that time. The web has changed a lot since 2018, and so has Speedometer in its latest release, Speedometer 3. This work has been based on a joint multi-stakeholder governance model to share work, and build a collaborative understanding of performance on the web to help drive browser performance in ways that help users. The goal of this collaborative project is to create a shared understanding of web performance so that improvements can be made to enhance the user experience. Together, we were able to to improve how Speedometer captures and calculates scores, show more detailed results and introduce an even wider variety of workloads. This cross-browser collaboration introduced more diverse perspectives that enabled clearer insights into a broader set of web users and workflows, ensuring the newest version of Speedometer will help make the web better for everyone, regardless of which browser they use. Why is building workloads challenging? Building a reliable ben ## Optimizing Safe Browsing checks in Chrome DevFeed: [Optimizing Safe Browsing checks in Chrome]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-02-13T17:00:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Security](), [Latency](), [real-time](), [Social engineering](), [ai and ml](), [Google]() Tags: [ai](), [ai-and-ml](), [chrome](), [google](), [latency](), [none](), [phishing](), [real-time](), [security](), [social-engineering](), [user-experience]() ### AI overview The article announces changes to Chrome's Google Safe Browsing checks. Starting with Chrome 122, real-time server-side checks will run asynchronously so pages can load without waiting, reducing latency and improving browsing experience while preserving warnings for dangerous sites. The change also enables experimentation with AI and ML algorithms to detect phishing and social engineering attacks. ### Source excerpt Balancing security and usability is always top of mind for us as we strive to stay on top of the constantly evolving threat landscape while building products that are delightful to use. To that end, we'd like to announce a few recent changes to how Chrome works with Google Safe Browsing to keep you safe online while optimizing for smooth and uninterrupted web browsing. Asynchronous checks Today, Safe Browsing checks are on the blocking path of page loads in Chrome, meaning that users cannot see pages until checks are completed. While this works fine for local-first checks such as those made using Safe Browsing API v4, it can add latency for checks made directly with the Safe Browsing server. Starting in Chrome 122, we will begin to introduce an asynchronous mechanism which will allow sites to load even while real-time checks with Safe Browsing servers are in progress. We expect this to reduce page load time and improve user experience as real-time server-side checks will no longer block page load, although if a site is found to be dangerous after the page loads then a warning will still be shown. In addition to the performance boost, this change will let us improve the quality of protection over time. By taking the remote lookup outside of the blocking path of the page load, we're now able to experiment with and deploy novel AI and ML based algorithms to detect and block more phishing and social engineering attacks. It was previously challenging to perform such experimentation because of the potential to delay page loads. In terms of potential risks, we evaluated the following and concluded that sufficient mitigations are in place: Phishing and social engineering attacks: With the move to asynchronous checks, such sites may start to load while server-side Safe Browsing checks are in progress. We have studied the timing data and concluded that it is extremely unlikely a user would have significantly interacted with (e.g. typed in a password) such a site by the time a ## Chromium Issue Tracker migration is complete DevFeed: [Chromium Issue Tracker migration is complete]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-02-05T16:42:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [Chromium](), [GitHub Issues](), [migration](), [Google](), [Tooling](), [Open Source](), [Documentation](), [Git]() Tags: [chromium](), [documentation](), [ecosystem](), [git](), [google](), [issue-tracker](), [migration](), [none](), [open-source](), [tooling]() ### AI overview Chromium has completed its migration from Monorail to the Chromium Issue Tracker, powered by Google Issue Tracker. Existing Monorail links will redirect to the migrated issues, and feedback will help improve the new tracker experience. ### Source excerpt We are thrilled to share that Chromium issue tracking has migrated! Access the Issue Tracker, and supporting documentation. Why was this done Issue tracking moved from Monorail to the Chromium Issue Tracker (powered by the Google Issue Tracker) to provide a feature-rich and well-supported issue tracker for Chromium's ecosystem. Chromium joins other open source projects (Git, Gerrit) on this tooling. What happens moving forward Existing Monorail issue links will redirect to the migrated issues in the new issue tracker. We will prioritize feedback to continue to improve the issue tracker experience. Help & Feedback You can reach out at any time to issue-tracker-support@chromium.org with questions or concerns. ## Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST DevFeed: [Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-02-02T17:02:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [Chromium](), [issue tracker](), [migration](), [Google](), [Open Source](), [Documentation]() Tags: [bugs](), [chromium](), [documentation](), [google](), [issue-tracker](), [migration](), [none](), [open-source](), [tooling]() ### AI overview Chromium is migrating all issues, including their history and stars, from Monorail to the Google-powered Chromium Issue Tracker. The migration is scheduled for February 2-4, 2024, with existing issue links redirecting afterward and documentation for common workflows to be added later. ### Source excerpt As we shared last year, Chromium is moving to a different issue tracker to provide a well-supported user experience for the long term. Migration is beginning today (February 2, 2024) at 5pm PST. We expect migration will be completed by the end of day (PST) February 4, 2024. What's happening We will migrate all Chromium issues, including issue history and stars, from Monorail to a different tool: Chromium Issue Tracker, powered by the Google Issue Tracker. This tooling change will provide a feature-rich and well-supported issue tracker for Chromium's ecosystem. Chromium will join other open source projects (Git, Gerrit) on this tooling. Existing transparency levels to bugs will be maintained. Post-Migration We will publish another post once the migration is complete. Once the migration completes, existing Monorail issue links will redirect to the migrated issues in the new issue tracker. We will prioritize feedback to continue to improve the issue tracker experience. Documentation on new and common workflows will be added to chromium.org once the migration is complete. Help & Feedback You can reach out at any time to issue-tracker-support@chromium.org with questions or concerns. ## A new way to seamlessly browse across devices with Chrome on iOS DevFeed: [A new way to seamlessly browse across devices with Chrome on iOS]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2023-11-08T17:59:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [iOS](), [Google](), [passwords](), [data]() Tags: [chrome](), [data](), [devices](), [google](), [ios](), [passwords]() ### AI overview Chrome is introducing changes on iOS that let users sign in to save bookmarks, reading lists, passwords, payment information, addresses, and settings to their Google Account without first setting up Chrome sync. Users can separately opt in to synchronize tabs and browsing history, while local device data remains distinct from account data. Signing in to Chrome remains optional. ### Source excerpt Whether you're browsing the web on your PC at home or on the go with your phone, we designed Chrome to be simple to use and work great on all platforms. For example, tools like Chrome sync have made it possible for you to access your bookmarks and passwords when switching between all your devices. In the coming weeks we're making changes to Chrome on iOS to help you get to your most important stuff right away. Instead of having to set up Chrome sync on your device, you can now simply sign in to Chrome to save new things in your Google Account and access what's already there. This may feel familiar to you, as it's how many Google apps on iOS already work today. Once you're signed in to Chrome, you'll be able to save your important stuff to your account, including bookmarks, reading lists, passwords, payment info, addresses and settings. And, you can separately opt in to synchronizing your tabs and browsing history from Chrome on iOS to your Google Account, which can help you pick up browsing where you left off on another device. These updates are also designed to help you manage your data. When you sign in to Chrome, the browsing data that's already on your device will be kept separate as local data on your device. You'll be able to easily distinguish local from account data in settings. And, if you want any local data to be available on your other devices, you can simply go to settings and save it to your account. Signing in to Chrome on iOS remains entirely optional. If you don't sign in, you can still save your bookmarks, passwords and more, but they will be available only on the device where you saved them. You can also continue to sign in to Google web services like Gmail without signing in to Chrome. We're hoping these changes make it even easier for you to get the best of Chrome while offering you all the flexibility you need. Posted by Nico Jersch, Chrome Product Manager [Next page]()