Chromium Blog: October 2018

Chrome 71 Beta: relative time formats and more

Thursday, October 25, 2018

ChromeStatus.com International Relative Time FormatIntl.RelativeTimeFormat()const rtf = new Intl.RelativeTimeFormat('en'); rtf.format(3.14, 'second'); // → 'in 3.14 seconds' rtf.format(-15, 'minute'); // → '15 minutes ago'formatToParts()Read our article Other features in this release Add FullscreenOptionsElement.requestFullscreen()customized on AndroidnavigationUI"auto""show""hide""auto" Add 'persistent-storage' property to the Permission API"persistent-storage"a new permissionnavigator.storage.persisted()navigator.permissions.query({name:"persistent-storage"}) Async touchpad pinch zoom eventsAsync touchpad pinch zoom events COLR/CPAL font supportChrome now supportsCOLR/CPAL fontsTwemoji CSS gradient color stop double-position syntaxCSS Image Values and Replaced Content Module Level 4linear-gradient(45deg, black 25%, black 50%, white 50%, white 75%)linear-gradient(45deg, black 25% 50%, white 50% 75%) Implement 'left' and 'right' values for 'text-underline-position' support for 'left' and 'right' values'text-underline-position''text-underline-position' JavaScript Modules: Credentials mode defaults to "same-origin"is changing"omit""same-origin" TextEncoderStream and TextDecoderStream APIssupports streamsresponse.body.text()ReadableStreamResponse.BodyResponse.Body.pipeThrough(new TextDecoderStream()) Unprefixed Fullscreen APIThis update MediaElement and MediaStream nodes defined only for AudioContextChrome now only allowsMediaElementAudioSourceNodeMediaStreamAudioSourceNodeMediaStreamAudioDestinationNodeAudioContextOfflineAudioContextOfflineAudioContext Interoperability improvements Call capture event listeners in capturing phase at shadow hostsChrome now callscomplete discussion Improve :host, :host-context, and ::slotted specificityChrome now calculates:host():host-context()::slotted()Shadow DOM v1 spec Deprecations and Removals Remove SpeechSynthesis.speak without user activationspeechSynthesis.speak()now fires an error Remove importScripts() of new scripts after service worker installation.importScripts()After this changeuse importScripts() in two cases

Before installation finishes (from the initial execution of the service worker until it reaches the `installed` state).

After installation finishes, only for scripts that were already imported in the previous phase.

Remove prefixed versions of several APIs

WebKitAnimationEvent - Use the AnimationEvent.

WebKitTransitionEvent - Use the TransitionEvent.

Remove URL.createObjectURL for MediaStreamURL.createObjectURL()has been removedMediaStreamsrcObject Remove document.origin document.originhas been removedself.origin

Trustworthy Chrome Extensions, by default

Monday, October 1, 2018

li { line-height: 1.38 !important; } Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.
The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.
We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.
Today we’re announcing some upcoming changes and plans for the future:
User controls for host permissions Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.

While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.

Changes to the extensions review process Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.

New code readability requirements Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.
Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.
Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.
Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

Removal of whitespace, newlines, code comments, and block delimiters

Shortening of variable and function names

Collapsing the number of JavaScript files

If you have an extension in the store with obfuscated code, please review our updated content policies as well as our recommended minification techniques for Google Developers, and submit a new compliant version before January 1st, 2019.

Required 2-Step Verification

In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.

For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.

Looking ahead: Manifest v3

In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.

Some key goals of manifest v3 include:

More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
Additional, easier mechanisms for users to control the permissions granted to extensions
Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.
We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.
Posted by James Wagner, Chrome Extensions Product Manager

Chromium Blog

Chrome 71 Beta: relative time formats and more

Trustworthy Chrome Extensions, by default

Labels

Archive

Feed