Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 23 2019

Google Summer of Code 2019 (Statistics Part 1)

May 22 2019

Google and Binomial Partner to Open-Source Basis Universal Texture Format

May 21 2019

OpenTelemetry: The Merger of OpenCensus and OpenTracing

May 16 2019

Google fosters the open source hardware community

May 09 2019


Google I/O 2019: What's new with Chrome and the Web

The web celebrated its 30th anniversary this year, and what an amazing three decades they have been. We’ve seen the platform go from powering simple hypertext documents, to one that enables rich, immersive, and dynamic experiences that are at the forefront of design.

Looking forward, the world’s needs continue to evolve, and that motivates us to continue our participation with the global web community to adapt and improve the platform to meet the needs of the future. Our efforts are focused on making the web faster and more powerful, while keeping our users’ trust and safety front and center.

Vision for an Instant Web

Speed matters on the web. We’ve found that users are highly sensitive to loading speed and this can have a direct impact on the business.

So we’ve been working hard to make the browser faster and lighter so developers can do more with their experience. By focusing on startup bottlenecks, we were able to improve the loading speed on Chrome’s startup by 50% on low-end devices; and 10% across devices. We also improved scrolling performance by 18% and through V8, JavaScript memory usage reduced by up to 20% for real world apps.

Apart from making the browser more efficient, we’ve also been adding more features to the platform to take the burden away from developers. And we’d like to share a few of these here:

  • To deliver a great image loading experience without needing developers to build their own JavaScript solutions, we’re bringing lazy loading for images and iframes directly into the browser. All developers have to do is add a simple HTML attribute and Chrome will take care of the rest.
  • For fast sites, Chrome’s eager clearing of the page, when a user wants to navigate to another page, can be detrimental to the experience. To avoid this flash of a white “loading page”, we’re rolling out a new experiment called Paint Holding to improve navigation on the web. You can see it in action for the Awwwards website here: 

Speaking of navigations, Portals , is a new technology that we believe will fundamentally change the way users traverse the web. Portals are similar to iframes and allow content to be embedded directly in a page, but unlike standard iframes, they can be ‘activated’ to become the top-level page, enabling instant transitions across the web. Advanced experiences can even hold pieces of the original page’s UI privately and securely, so that you can provide seamless overlays that still hold our ideals of the origin model.

At I/O, we shared our vision of how developers would be able to use Portals and associated APIs to support pre-fetching, enhanced transitions and the exchange of contextual information between sites. And now that Portals API is available behind a flag in Chrome Canary, we’re excited to see what developers will build with this new primitive.

Another technology that we’re particularly excited about is Web Packaging , a bold new contract between web developers and web servers. With Web Packaging, the model for loading pages changes from the browser requesting the page from the origin’s server to it being able to load from anywhere — even potentially other peer devices.

This gives the browser the flexibility to preload content and load pages instantly while doing so in a privacy preserving way. Signed Exchanges , the first phase of this vision is now available in Chrome for developers to use.

These are some of the things that we’re doing to make the web more instant, but its success is predicated on developers making their experiences fast and maintaining that performance. So we’ve added a bunch of tools to help.

In 2017, we launched the Chrome UX report to give developers a better sense of how their users truly experience their webpages by providing them real world metrics. The report is now includes a data set of nearly 6 million origins and is powering more of our tools, including the latest Speed Report in the Google Search Console . The report is currently in beta and you can register here to join the program and share your feedback.

To give developers an even wider array of real world metrics, the Firebase team have broadened their Performance Monitoring tool to also cover web apps.

And to stay on the rails for performance, we’ve seen many top sites implement ‘performance budgets’ within their build environments, and that is why we’ve built performance budgets directly into Lighthouse , so that you can get alerted to performance regressions before they hit your production site.

Creating a more powerful web

Our vision is to allow you to do absolutely anything that you want your users to do, on the web. So we’ve been working hard over the last year to close the capability gap by focusing on the features that get your experiences closer to your users.

Working closely with the community to address the most pressing and critical needs, we’re bringing many of these features to fruition at a great pace. Some of the capabilities that we’re most excited about include File system access, Unlimited Quota and the SMS based authentication feature that is particularly important for developers working in markets where “one-time passwords” are an important part of the authentication process.

And while we continue our momentum here, we’ve already launched the Web Share Target API allowing your apps to be integrated into the native system sharing, and opened up Shape Detection APIs that enable experiences like the Web Perception toolkit that we launched at I/O today. The toolkit allows developers to integrate with the mobile camera and enable people to use their website more effectively.

With mobile gaining many such strong capabilities, we also wanted to enable developers who build quality web experiences to get more reach. So we’ve launched Trusted Web Activities, that allow developers to integrate their web content into Android apps. And businesses like OYO Rooms, India’s biggest affordable hotels network, are already using Trusted Web Activities to power a lite version of their experience, a common pattern that we’re seeing amongst partners in some markets.

But the thing that we’re most excited about is the progress that we’ve made on desktop capabilities, with technologies like Web Assembly and individual media and productivity APIs unlocking many new use cases. Hulu and Google’s Duo are great examples of what’s possible on the web today. And we’re excited to have our friends at Slack join in and fully committed to roll out an offline-enabled web-powered version of their desktop app later this year.

PWAs on desktop came to ChromeOS last year, to enable web apps that need full window support and common desktop app capabilities. And now we’re excited to have extended support to Windows, Mac, and Linux.

We’re excited to see the momentum for PWAs on desktop and we wanted to ensure that we do our part to ensure that users can identify high quality PWAs and install them easily, so we’ve improved discoverability by bringing a new “Install” button directly into Chrome’s UI, within the Omnibox. This is one step to support developers building amazing experiences to get more engagement with their loyal users and we hope to continue doing more here.

In this landscape of massive device fragmentation, we wanted to see if it is possible for us to build an experience that could work across all devices, from the lowest-end feature phones to the large screen desktops. So we built a fun game - Proxx, that uses preact for UI, Comlink to be able to use workers and do more off the main thread. And yes, it works across all devices and performs well even on the most constrained ones. And because it's on the web, you can play it right here; but maybe after you're done reading. :)

Over the next year we will continue to open up even more of the capabilities that enable the next generation of games, productivity, media and social apps to come to the web, all whilst ensuring that the core principles of user safety and trust are preserved.

Bringing transparency, choice and control

User experience is extremely important to us and their safety and privacy remains at the heart of it. At I/O, we shared important upcoming changes to how Chrome will handle cookies in order to enable choice over tracking, and that enhance web security and privacy generally. And later this year, we will preview new features in Chrome that give users transparency and control over how they are tracked on the web.

We believe these changes will help improve user privacy and security on the web — but we know that it will take time. So we’re committed to working with the web ecosystem to understand how Chrome can continue to support these positive use cases and to build a better web.

Improving your developer experience

As the scope of the web platform increases and the demand from users to have ever faster, safer and more capable experiences at their fingertips it should be easier, not harder to build high-quality sites.

We built to bring our measurement tools, aka, Lighthouse and guidance all in one place. We’ve improved the site that now provides over 200 easy to follow guides for performance, safety, accessibility, resilience, and more. And at I/O, we announced our intent to build guidance for the tools that you use, starting with React.

And we’re adding the same level of personalization to Lighthouse, to give developers reports and improvement tips for the framework that they use. We’ve built in guidance for Wordpress and will be adding more over the rest of 2019 and beyond.

The web has come a long way over the last 30 years and we’re excited to be working with the developer community and other browsers with a shared mission to bring universal access to information and services to more people than ever.

Posted by Ben Galbraith and Dion Almaer

May 07 2019


Improving privacy and security on the web

In 2008, we launched Chrome with the goal of building a speedy, simple, secure and stable web for everyone, everywhere. Ten years later, user experience is still at the core of everything we do.
We’ve received consistent feedback from our users about the importance of transparency, choice and control when it comes to data privacy on the web. That’s why today, at Google I/O, we announced our plans to update how cookies are handled by Chrome.

Cookies and privacy

Cookies play an important part of the web experience today — they are used to keep you logged into email, save shipping addresses on a retail site, and remember your preferences on the websites you’ve visited. And they can also be used to track your browsing activity across the web to serve personalized content and ads.

Unfortunately, to browsers, all of these different types of cookies look the same, which makes it difficult to tell how each cookie is being used — limiting the usefulness of cookie controls. For instance, when you clear all of your cookies, you’re logged out of all sites and your online preferences are reset. Because of this, blunt solutions that block all cookies can significantly degrade the simple web experience that you know today, while heuristic-based approaches—where the browser guesses at a cookie's purpose—make the web unpredictable for developers.

Improving cookie controls in Chrome

We announced at I/O that we will be updating Chrome to provide users with more transparency about how sites are using cookies, as well as simpler controls for cross-site cookies. We will preview these new features later this year.

We are making a number of upcoming changes to Chrome to enable these features, starting with modifying how cookies work so that developers need to explicitly specify which cookies are allowed to work across websites — and could be used to track users. The mechanism we use builds on the web's SameSite cookie attribute, and you can find the technical details on

In the coming months, Chrome will require developers to use this mechanism to access their cookies across sites. This change will enable users to clear all such cookies while leaving single domain cookies unaffected, preserving user logins and settings. It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used.

This change also has a significant security benefit for users, protecting cookies from cross-site injection and data disclosure attacks like Spectre and CSRF by default. We also announced our plan to eventually limit cross-site cookies to HTTPS connections, providing additional important privacy protections for our users.

Developers can start to test their sites and see how these changes will affect behavior in the latest developer build of Chrome.

Protections against fingerprinting

Making changes to how the browser treats cookies requires us to consider the broader web ecosystem. Blunt approaches to cookie blocking have been tried, and in response we have seen some user-tracking efforts move underground, employing harder-to-detect methods that subvert cookie controls. These methods, known as ‘fingerprinting,’ rely on various techniques to examine what makes a given user’s browser unique.

Because fingerprinting is neither transparent nor under the user’s control, it results in tracking that doesn’t respect user choice. This is why Chrome plans to more aggressively restrict fingerprinting across the web. One way in which we’ll be doing this is reducing the ways in which browsers can be passively fingerprinted, so that we can detect and intervene against active fingerprinting efforts as they happen.

Continuing to build a better web

We believe these changes will help improve user privacy and security on the web — but we know that it will take time. We also recognize that both cross-site cookies and fingerprinting have uses other than tracking. We’re committed to working with the web ecosystem to understand how Chrome can continue to support these positive use cases and to build a better web.

We launched Chrome ten years ago with the objective of building a better web and improving the user experience. While our browser has evolved since 2008, our objective remains the same.

Ben Galbraith - Director, Chrome Product Management
Justin Schuh - Director, Chrome Engineering 

May 06 2019

Summer is here! Welcome to our 2019 GSoC Students!

May 02 2019


Chrome 75 Beta: low latency canvas contexts, sharing files, and numeric separators

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on Chrome 75 is beta as of May 2, 2019.

Hint for low latency canvas contexts

The canvas.getContext() method now supports a desynchronized hint, which provides a low-latency alternative to the now deprecated NaCl/PPAPI solution which used native OpenGL rendering. The new solution requires either 2d or webgl context types.

To use it, pass desynchronized: true in the options parameter of canvas.getContext() and specify CanvasRenderingContext2D, a WebGL2RenderingContext, or a 65WebGL2ComputeRenderingContext as the context type. For example:

const canvas = document.querySelector("canvas");
const context_type = '2d'; // 'webgl' or 'webgl2'
canvas.getContext(context_type, {desynchronized: true, alpha: false });

For more information and links to sample code, read Low latency rendering with the desynchronized hint on our developer's site.

Web share now supports files

Files are now supported by the Web Share API. Over the last few years, we've been working to bring native sharing capabilities to the web. The Web Share API allows web apps to invoke the same share dialog box that a native app user would see. The code looks something like this:

if (navigator.canShare && navigator.canShare({ files: filesArray })) {
files: filesArray,
title: 'Vacation Pictures',
text: 'Barb\nHere are the pictures from our vacation.\n\nJoe', })
.then(() => console.log('Share was successful.'))
.catch((error) => console.log('Sharing failed', error));
} else {
console.log('Your systems doesn't support sharing files.');

If you're already used the sharing APIs, most of this looks familiar. As highlighted above, the new feature brings a new method and a new shareData property. For details read Share files with Web Share.

Numeric separators

Numeric literals now allow underscores (_, U+005F) as separators to make them more readable. For example, 1_000_000_000 will be interpreted by mathematical operations as equivalent to 1000000000.

There are a few things you should be aware of. Underscores can only appear between digits, and consecutive underscores are not allowed. So literals such as 3._14, _2.71 or 1.6__2 are illegal.

Other features in this release

Allow to take optional detailsPromise

The detailsPromise argument is a way to signal that the browser should show a spinner or equivalent and wait on allowing user interaction until an update. Some users may not know the total or the number of line items at the time of attempting to open the payment sheet with show().

Animation improvements

Animation() constructor

The new Animation()33 constructor gives developers more control over the created animation by using the exact KeyframeEffect object (see below). Currently developers must use the Element.animate() method, which returns an Animation object that is internally constructed.

AnimationEffect and KeyframeEffect

AnimationEffect and KeyframeEffect allow a developer interactive control over the following parts of their Animation:
  • The Animation target (the element being animated).
  • The Animation timing properties (duration, delay, etc.).377

AppCache: Cross-origin resource size padding

For quota accounting purposes, the size of cross-origin AppCache resources are now padded. Cross-origin resources are resources whose origin differs from the manifest's origin. The padding size will be a random number between 0 and about 14MB. Quota accounting purposes include the size reported by the Quota API and quota enforcement. An origin's storage API calls are blocked when the origin exceeds its quota.

CSP: `script-src-attr`, `script-src-elem`, `style-src-attr`, `style-src-elem` directives

These four new directives provide the functionality of the script/style directive but with more granularity, applying to elements or attributes.


This is a hint a website may provide to a user agent to display a video content within the element's playback area.

MediaStreamTrack.getCapabilities() support for audio device-related constrainable properties.

MediaStreamTrack.getCapabilities() now returns the device-related capabilities of the source associated to a MediaStreamTrackucifically sample size, sample rate, latency, and channel count/

There is also a variant InputDeviceInfo.getCapabilities(), available in the results of MediaDevices.enumerateDevices(). These devices are used as sources for MediaStreamTrack, and getCapabilities() in this case returns the same values as MediaStreamTrack.getCapabilities() for sampleSize, channelCount, and latency.

noreferrer attribute for

Allows a web page to use without leaking referrer information by leaving the referrer header out of page navigations.

Web RTC improvements


This interface provides information about active transports. Specifically, this interface allows an application access to information about the Datagram Transport Layer Security (DTLS) transport over which RTP and RTCP packets are sent and received by RTCRtpSender and RTCRtpReceiver objects, as well as other data such as SCTP packets sent and received by data channels.


This interface provides information about the state of the ICE transports used by RTCPeerConnection to send and receive media to another endpoint.

Service workers appear in Chrome's Task Manager

Service workers now appear in Chrome's Task Manager.


The new stale-while-revalidate response directive is used by the Cache-Control header to define an extra window of time during which a user agent can use a stale asset during asynchronous revalidation. The revalidation of such assets bypasses the service worker. op0This change improves subsequent page load latencies by keeping stale assets out of the critical path.

Web Authentication API: FIDO CTAP2 PIN support

This feature extends Chrome's implementation of the Web Authentication API to support local user authorization of security key operations via a user-defined PIN for keys that implement the FIDO CTAP2 protocol. Web sites using web authentication can request or require such authorization via the API's user verification mechanisms.


Allow waitUntil() and respondWith() inside microtasks during event dispatch

To conform to the specification, ExtendableEvent.waitUntil() and FetchEvent.respondWith() can now be called during the microtask checkpoint at the end of event dispatch. Previously, this would throw an InvalidStateError.

Feature Removal

Remove overflow: -webkit-paged-x and overflow: -webkit-paged-y

These are old webkit-specific properties that allowed developers to fragment content over columns inside a scrollable region. They are now removed.

Practically speaking these aren't used. Most developers use them accidentally, and typically when they are they force a new formatting context similar to setting overflow: hidden.

May 01 2019

Season of Docs announces participating organizations

April 26 2019

Google Open Source Peer Bonus winners are here!

April 23 2019


Data Saver is now Lite mode

Since we introduced Data Saver in Chrome, we’ve reduced users’ data usage by up to 60 percent. But now, the feature is expanding to provide more benefits in addition to data savings. Pages will now load faster, in some cases considerably faster, and use less memory. This is why starting today, we will be renaming Data Saver to Lite mode .

Lite mode will continue to reduce data use by using Google servers to compress the pages you visit before downloading them. Using the NetworkInformation API , Lite mode tells web servers that you are interested in receiving a version of the site that uses less data if one is available.

Lite mode also helps improve page loads. If Chrome predicts that a page will take longer than 5 seconds for the first text or image to show on screen, it will load a Lite version of the page instead. Lite pages are highly optimized to load considerably faster. A whitepaper will be published in the coming months that will explain this in more detail.

And of course, Lite mode will continue to respect your privacy. When Chrome optimizes an HTTPS page, only the URL is shared with Google and other information such as cookies, login information, and personalized page content is not shared with Google. We never break secure connections between Chrome and a website.

Lite mode is available only on Chrome for Android. The Chrome Data Saver desktop extension will be deprecated in M74.

To enable Lite mode, select Settings > Lite mode and toggle the setting to On. If you already have Data Saver enabled, then Lite mode will automatically be enabled.

Posted by Ben Greenstein, Technical Lead for Lite Mode and Nancy Gao, Product Manager on Chrome

April 09 2019

Bringing the best of open source to Google Cloud customers

April 02 2019

Season of Docs now accepting organization applications

March 28 2019

Open sourcing Science Journal iOS

March 26 2019

Celebrating the Apache Software Foundation's 20th anniversary

March 25 2019


Debugging Websites in Chrome for iOS

Debugging web pages displayed in Chrome for iOS has always required building the project from source because the release version of WKWebView does not support Safari Remote Debugging. To help bridge the gap of missing developer support, we added the chrome://inspect page in M73 to locally view JavaScript logs. While building Chrome for iOS from source is still the best way to fully debug web pages, we hope that this tool will make it easier to troubleshoot some problems.


When building Chrome for iOS from source, Safari Web Inspector can be used to debug a web page rendered in Chrome. However, this takes a non-trivial amount of effort which includes setting up a Chromium checkout, installing a current version of Xcode, and waiting for the build to complete. Additionally, a Mac with enough disk space to hold the code and tools is required. This barrier to debugging has led to bugs being filed for specific website failures on Chrome for iOS.

These bugs can be difficult to diagnose as they are generally based on a single failure case. Chrome developers most likely don’t know the website application well enough to fully understand what is causing the bug. Often, the reporter has even spent time to build a dedicated test page to more precisely understand the issue. The lack of debugging tools require developers to come up with alternative methods in order to debug their websites. Of course, nothing is wrong with filing bugs, and we certainly don’t want to discourage it, but we do want to improve the web developer experience.

In-app JavaScript Console

Enable JavaScript log collection by navigating to chrome://inspect in Chrome for iOS and leaving that tab open to collect logs. In another tab, reproduce the case for which you are interested. Then switch back to the chrome://inspect tab to view the collected logs.  (Log collection will stop if the chrome://inspect page closes or navigates and logs will be lost as they are not persisted.)

Posted by Mike Dougherty, Chrome Engineer on iOS
Accepting student applications for Google Summer of Code 2019

March 22 2019


Chrome 74 beta: reducing unwanted motion, private class fields, and feature policy API

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Android WebView, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 74 on Chrome 74 is beta as of March 22, 2019.

CSS prefers-reduced-motion media query

Some users have reported getting motion sick when viewing parallax scrolling, zooming, and other motion effects. To address this, many operating systems like Android depicted in the screenshot below provide an accessibility option to reduce motion whenever possible.

Chrome now provides a media query, prefers-reduced-motion (part of Media Queries Level 5), that allows websites to honor these options when they are available.

Here's a short example to give you a taste of how it works. Imagine I have a sign-up button that draws attention to itself with a slight motion. The new query lets me shut off the motion for just the button.

@media (prefers-reduced-motion: reduce) {
button {
animation: none;

For all the details and options, read Move Ya! Or maybe, don't, if the user prefers-reduced-motion!.

Private class fields

Chrome 72 introduced ECMAScript's new public class fields. Class fields simplify class syntax by avoiding the need for constructor functions just to define instance properties. Starting in Chrome 74, you can mark a field as private and no consumer of the class can ever access its value.

To mark a field as private, prepend it with a pound sign (#). As with public class fields, your properties do not need to be in a constructor.

class IncreasingCounter {
#count = 0;
get value() {
console.log('Getting the current value!');
return this.#count;
increment() {

Unlike public fields, private fields are not accessible outside of the class body. To read more about private class fields as well as the existing public class fields, read Public and private class fields. See Specification Compliance in this article for more on CSS changes.

JavaScript API for feature policy

Feature policies, which were introduced in Chrome 60, allow websites to selectively enable, disable, and modify the behavior of APIs and other web features. This is done either through the Feature-Policy header or through the allow attribute on an iframe.

In Chrome 74, feature policies are enhanced with the addition of a JavaScript API, available from document.featurePolicy and frame.featurePolicy. The new API encompasses three functions:
  • allowedFeatures() returns a list of features allowed by the current domain. 
  • allowsFeature() returns a boolean indicating whether a specific feature is allowed by either the current domain or by the specified domain. 
  • getAllowlistForFeature() returns a list of domains used on the current page that allow a specified feature.
For examples of these methods and for information about feature policy in general, read Introduction to Feature Policy.

Other features in this release

sampleRate option for the AudioContext constructor

Sets the "sampleRate" to a particular value for an AudioContext that will be created. This allows developers to set an arbitrary sample rate for audio processing in Web Audio API that is separate from the hardware rate. Use this to reduce complexity (by using a lower sample rate) or make the sample rate consistent across all devices by using a fixed rate and letting WebAudio resample appropriately for the hardware rate.


Chrome now supports the Intl.Locale class, which allows the following:
  • Parsing and manipulating the language, region, and script of a locale
  • Reading or writing the Unicode extension tags in a locale
  • Storing user locale preferences for this API in a serializable, standard format (rather than using a combination of language and the options object).

    Signed exchange reporting for distributors

    Signed Exchange Reporting for distributors extends Network Error Logging to enable the distributors of signed exchanges to investigate signed exchange loading errors such as certificate verification errors.

    TextEncoder encodeInto() method

    Chrome now supports TextEncoder.prototype.encodeInto(), which allows an encoded string to be written directly "into" a supplied pre-allocated buffer, offering a performant alternative to using encode() to produce a buffer, and copying its contents into an existing buffer.

    Service worker: client.postMessage() is buffered until the document is ready.

    To prevent messages from being delivered before the destination is readyclient.postMessage() does not dispatch the message until one of the following has occurred on the destination:
    • DOMContentLoaded event is fired.
    • onmessage is set.
    • startMessages() is called.

      Specification compliance

      CSS transition events

      The CSS Transitions specification requires that transition events are sent when a transition is enqueued, starts, ends, or is canceled as transitionruntransitionstart, transitionend, and transitioncancel respectively. These events mirror the CSS animation events which allow developers to observe CSS animations. Chrome now follows the specification.

      RTCIceCandidate and RTCIceCandidateInit

      RTCIceCandidate and RTCIceCandidateInit now comply with the specification. The RTCIceCandidate interface describes an ICE candidate in WebRTC. It is available in Chrome, but it is not spec compliant as it is missing some fields. There are also some deviations from the specification in terms of nullable and read-only attributes and errors thrown by the constructor.

      XHR falls back to UTF-8 when invalid encoding is specified

      When an invalid encoding is specified for an XMLHttpRequest (via overrideMimeType() or the response's MIME type), UTF-8 is used in conformance with the specification. Previously Latin-1 was used.

      Note: This applies to desktop Chrome only.

      Deprecations and removals

      Remove PaymentAddress's languageCode property

      The PaymentAddress's languageCode property has been removed from the Payment Request API. This property is the browser's best guess for the language of the text in the shipping, billing, delivery, or pickup address in Payment Request API. The languageCode property is marked at risk in the specification and has already been removed from Firefox and Safari. Usage in Chrome is small enough for safe removal.

      Don't allow popups during page unload

      Pages may not use the API to open a new page during its unload event. The popup blocker already prohibited this, but now it is prohibited whether or not the popup blocker is enabled. For now, enterprises can use the AllowPopupsDuringPageUnload policy flag to allow popups during unload. We expect to remove this flag in Chrome 82.

      Note: This was originally targeted at Chrome 72, but was actually removed to Chrome 74.

      Deprecate drive-by downloads in sandboxed iframes

      Chrome will soon prevent downloads in sandboxed iframes that lack a user gesture, though this restriction could be lifted via an allow-downloads-without-user-activation keyword in the sandbox attribute list. This allows content providers to restrict malicious or abusive downloads.
      Downloads can bring security vulnerabilities to a system. Even though additional security checks are done in Chrome and the operating system, we feel blocking downloads in sandboxed iframes also fits the general thought behind the sandbox. Apart from security concerns, it would be a more pleasant user experience for a click to trigger a download on the same page, compared with downloads starting automatically when a user lands on a new page, or started non-spontaneously after the click.

      March 20 2019

      Reflecting on Google Code-in 2018

      March 13 2019

      iOS Accessibility Scanner Framework
      Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
      Could not load more posts
      Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
      Just a second, loading more posts...
      You've reached the end.

      Don't be the product, buy the product!