WorryFree Computers   »   [go: up one dir, main page]

About 14 years ago, Google Earth gave users a rush of excitement by allowing them to  zoom right in on their childhood homes. But that could happen only once they downloaded and installed the application. Earth was released as a native application because rendering the whole world in real time required advanced technologies that weren’t available in the browser. 


As the Web progressed, we wanted Earth to be available on the platform so it could reach as many people as possible and let them experience the entire world at their fingertips. Web apps offer a better user experience because they’re linkable, meaning you can share access to the whole experience with a single click; they’re secure, since users aren’t at risk of viruses that can come with software downloads; and they’re composable, meaning we can embed them in other parts of the web.


In WebAssembly (Wasm), the W3C web standard for bringing native code to the web, the Earth team found a solution to allow Google Earth to move across multiple browsers—something we’ve been working on for a while now. Earth first came to the Web about two years ago using Native Client (NaCl), a Chrome-only solution—at the time. It was the only way to run native code in the browser and offer the performance users expect in modern web applications. But cross-browser compatibility is not as easy as we would like, since not every browser supports new technologies the same way. 


Using WebAssembly, we see more possibilities not just for making apps more accessible across browsers, but smoothing out the online experience, as we’ve seen with Google Earth. You can check out the Earth preview beta to see what the Earth team has achieved and read about their technical implementation here.


How WebAssembly works with threaded applications
If you plan to work in WebAssembly, it’s important to understand some of the specifics, particularly around threading.


Some browsers offer multi-threading support and others don't. In the case of Google Earth, it is constantly streaming data to the browser, decompressing it and making it ready for rendering to the screen. Being able to do this work on a background thread has shown a clear improvement in the performance of Earth in the browser.


The Chromium-based browsers—including Chrome, the forthcoming version of Edge, and Opera—all offer support for WebAssembly (some with multi-threading, others without). Once the new version of Edge based on Chromium ships, apps in WebAssembly will work as well in Edge as they do in Chrome. Firefox offers good support for WebAssembly, but had to disable support for multi-threading due to a SharedArrayBuffer issue. And while Opera is based on Chromium, the current version of Opera only offers single-threaded support of WebAssembly. Safari has a strong implementation of WebAssembly, but it lacks full support for WebGL2. Our deep-dive technical post offers more details about WebAssembly support across the browsers.


Emscripten: The tool that enabled Earth to port to the browser
Taking an application that was originally created for native operating systems and bringing it to the web is no small task. The Emscripten toolchain helps developers compile their C++ into WebAssembly, also also emulates many of the OS interfaces that native applications use. For example, an application may use the POSIX API fopen which tells the OS to open a file. Emscripten sees this call and offers the correct behavior through browser technologies such as local storage.  It does the same thing for turning OpenGL calls into WebGL calls. Along with many other features, it dramatically eases the work of bringing a native app to the web.


Emscripten has been used to port other applications to the web, such as the 35-year-old AutoCAD codebase and more recent applications like Sketchup.


What’s coming next for WebAssembly
There are several features coming to WebAssembly in the future that Earth will use to improve the web experience:


SIMD support: SIMD (single instruction, multiple data) lets a single CPU instruction act on multiple pieces of data. When it’s set up in the right way, SIMD allows for high throughput of data processing. When the first set of SIMD support arrives later this year for WebAssembly, we hope it will dramatically improve Earth’s performance. 


Dynamic linking: This feature will give Earth the chance to optimize load time, and opens the door to embedding Earth in other web pages and online experiences. Currently, all modules that interact have to be compiled at the same time. With dynamic linking, you can break up an application into many modules and ship a very small client, then load all the other parts over time (known as lazy loading).


Better debugging: Today, Wasm supports source maps so that developers can see their source code in the developer tools. That’s a great first step, but we want to also allow developers to inspect variables and see proper stack traces.

Earth has now taken a major step by adopting a cross-browser standard that lets them bring the application to more browsers—with more improvements coming in the future. Consider trying out WebAssembly for yourself and your native code to reach all your users with a consistent, performant experience.



Posted by Thomas Nattestad, Product Manager for Web Assembly, V8 and Web Capabilities

Chrome was built with security in mind from the very beginning. Today we’re launching two new features to help protect users from deceptive websites. The Suspicious Site Reporter Extension will improve security for Chrome users by giving power users an easy way to report suspicious sites to Google Safe Browsing. We’re also launching a new warning to protect users from sites with deceptive URLs.



We designed Chrome to be secure by default, and easy to use by everyone. Google Safe Browsing has helped protect Chrome users from phishing attacks for over 10 years, and now helps protect more than 4 billion devices every day across multiple browsers and apps by showing warnings to people before they visit dangerous sites or download dangerous files. We’re constantly improving Safe Browsing, and now you can help.



Safe Browsing works by automatically analyzing the websites that we know about through Google Search’s web crawlers, and creating lists of sites that are dangerous or deceptive. With the Suspicious Site Reporter extension, you can help Safe Browsing protect web users by reporting suspicious sites. You can install the extension to start seeing an icon when you’re on a potentially suspicious site, and more information about why the site might be suspicious. By clicking the icon, you’re now able to report unsafe sites to Safe Browsing for further evaluation. If the site is added to Safe Browsing’s lists, you’ll not only protect Chrome users, but users of other browsers and across the entire web.


Help us protect web users by reporting dangerous or deceptive sites to Google Safe Browsing through the Suspicious Site Reporter extension.

One way that deceptive sites might try to trick you is by using a confusing URL. For example, it’s easy to confuse “go0gle.com” with “google.com”. In Chrome 75, we’re launching a new warning to direct users away from sites that have confusing URLs.


Starting in the current version of Chrome (75), you’ll see a warning when the page URL might be confused for URLs of sites you’ve visited recently.


This new warning works by comparing the URL of the page you’re currently on to URLs of pages you’ve recently visited. If the URL looks similar, and might cause you to be confused or deceived, we’ll show a warning that helps you get back to safety.



We believe that you shouldn't have to be a security expert to feel safe on the web, and that many Chrome power-users share our mission to make the web more secure for everyone. We’ll continue improving Chrome Security to help make Chrome easy to use safely, and are looking forward to collaborating with the community to further that goal. Install the new extension and start helping protect web users!



Posted by Emily Schechter, Chrome Product Manager

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 ChromeStatus.com. Chrome 76 is beta as of June 13, 2019.

Dark mode

Many operating systems now support inverted color schemes with a system setting referred to as ‘dark theme' or ‘dark mode', depending on the system.


The prefers-color-scheme media query allows a website or web app to adopt the preferred display mode of the user. Use the query in your CSS code like so:


@media (prefers-color-scheme: dark) {
  body {
    color: white;
    background-color: black;
  }
}


What is left out of this is the explanation? For that, read the article titled Hello Darkness, My Old Friend.

Payments API

Over the last few versions of Chrome we've rolled out a number of improvements to the payments APIs. These APIs provide a way to interact with proprietary payment systems without needing to build your own user interactions. Changes in Chrome 75 included replacing hasEnrolledInstrument() with canMakePayment() and removal of languageCode from the billing address. With the detailsPromise option Chrome 75 gives PaymentRequest.show() a means of performing a quick server call before showing payment details to the buyer.

Chrome 76 brings three changes to the payment realm. Now implemented are features that allow a merchant website or web app to respond when a user changes payment instruments. Additionally, the PaymentRequestEvent has a new method called changePaymentMethod() and the PaymentRequest object now supports an event handler called paymentmethodchange. You can use both to notify a merchant when the user changes payment instruments. The former returns a promise that resolves with a new PaymentRequest instance.

Additionally, Chrome now makes it easier to use the payments APIs for self-signed certificates on the local development environment. To do this, launch Chrome from a command line with the —ignore-certificate-errors flag.

For detailed information about these features, read Web Payments Updates.

Improvements for Progressive Web Apps

Install Progressive Web Apps on the desktop with ease

On desktop, there is typically no indication to a user that a Progressive Web App is installable, and if it is, the install flow is hidden within the three dot menu.

In Chrome 76, we're making it easier for users to install Progressive Web Apps on the desktop by adding an install button to the omnibox.


If a site meets the Progressive Web App installability criteria, Chrome shows an install icon in the omnibox. There is no extra work required from developers. Clicking the button prompts the user to install the PWA.

Control the Add to Home Screen mini-infobar

In Chrome 76, we're giving you control over the add to home screen mini-infobar.




Chrome shows the mini-infobar the first time a user visits a site that meets the Progressive Web App installability criteria. Developers want to prevent the mini-infobar from appearing, and provide their own install promotion instead.

To do this, listen for the beforeinstallprompt event, and call preventDefault()
on it. Then, update your UI to notify the user by adding an install button or other element. Depending on your app, there are several different patterns you can use to promote installation of your PWA.

The add to home screen mini-infobar is still a temporary measure. We are experimenting with new UI patterns for giving Progressive Web App users the ability to install, and do this in a way that reduces clutter in the browsing experience.

Updating WebAPKs more frequently

When a PWA is installed on Android, Chrome automatically requests and installs a WebAPK. Chrome periodically checks to see if the manifest has changed, and if a new WebAPK is required. Starting in Chrome 76, Chrome will check the manifest more frequently: checking every day, instead of every three days. If any of the key properties have changed, Chrome will request and install a new WebAPK.

Other features in this release

Animation.updatePlaybackRate

Adds Animation.updatePlaybackRate(), which lets you seamlessly transition the playback rate of an animation such that there is no visible jump in the animation. Current time is preserved at the instance the new playback rate takes effect.

Async clipboard: read and write images

Implements programmatic copying and pasting of images for the Async Clipboard API. This change also updates navigator.clipboard.read() and navigator.clipboard.write() to comply with the specification. Programmatic copying and pasting of images is Chromium's top starred bug.

Escape key is not a user activation

The escape key is no longer treated as a user activation. Browsers prevent calls to abusable APIs (like popup, fullscreen, vibrate, etc.) unless the user activates the page through direct interactions. Not all interactions trigger user activation. For example, clicking on a link or typing in a textbox does, but swiping fingers on a screen or hovering with the mouse cursor does not. Since users never intend to interact with the page through the escape key, it should not trigger user activation.

Fetch Metadata

Introduces a new HTTP request header that sends additional metadata about a request's provenance (is it cross-site, is it triggered from <img>, etc.) to the server to allow it to make security decisions which might mitigate some kinds of attacks based on timing the server's response (XSS leaks and others).

For example, it is unlikely that a bank's "Transfer all money" endpoint would be referenced from an <img> tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than deliver them to the application backend.

form.requestSubmit()

Adds the form.requestSubmit() function, which requests form submission. It includes interactive constraint validation, dispatches a submit event, and takes a reference to the submitter button.

ImageCapture support for focusDistance constraint

The Image Capture API provides a means to set the focusMode to manual which is not useful if you cannot set the focus distance. This change provides an interface for getting focus range values and setting focus distance value.

Implement Animation.pending

Adds the pending attribute to the Web Animations API. A pending animation is one that is waiting on an asynchronous operation that affects the play state. Adding support for this attribute does not affect the rendering or timing of animations, but simply exposes the signal.

IndexedDB transaction explicit commit API call

Adds a commit() function to IDBTransaction objects, which explicitly marks a transaction as not accepting further requests. Currently, IndexedDB only commits a transaction after all associated requests have had their completion event handlers executed, and no new requests have been queued by the event handlers. Developers can use the explicit commit() function to shave a few event loop cycles off of the latency of their transactions.

The primary benefit of explicit commit is that it increases the throughput of read and write requests made on an object store. This is a clear performance benefit in terms of the rate at which operations can be processed. Additionally, the increase in speed is advantageous because it adds stability to IndexedDB by reducing the probability that a disruptive event occurs within the lifetime of a transaction.

JavaScript

DateTimeFormat dateStyle and timeStyle
Adds dateStyle and timeStyle options to functions on Intl.DateTimeFormat, specifically formatToParts() and resolveOptions(). These options provide a compact way to request the appropriate, locale-specific date and time of given length styles.

Locale sensitive BigInt.prototype.toLocaleString and allow Intl.NumberFormat format/formatToParts to take BigInt.
Changes BigInt.prototype.toLocaleString() to locale-sensitive number formatting and changes Intl.NumberFormat.prototype.format() and formatToParts() to accept BigInt as input.

Media capabilities in workers

Enables the Media Capabilities API in all types of workers to help website and web apps pick the best media to stream from a worker. The information can then be used to create the MediaStream from a worker.

Promise.allSettled

Adds Promise.allSettled(), which returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, in other words after it has either resolved or rejected.

Simpler reading methods for Blob interface

Adds three new methods to the Blob interface to perform read operations: text(), arrayBuffer(), and stream().

WebRTC

RTCSctpTransport
Exposes information about the SCTP transport that is used to carry WebRTC data channels such as max-message-size and max channels.

RTCRtpSender.setStreams
Allows changing the association between the track associated with an RTCRtpSender and streams. Stream association causes tracks in the same stream to be synchronized. This is useful, for example, if during a call a user switches from a front-facing camera to a back-facing camera and the application uses RTCRtpSender.replaceTrack(). On the receiving end the new track must be associated with the existing stream and synchronized with its auto track.

RTCRtpTransceiver.setCodecPreferences()
Adds the setCodecPreferences() method, which overrides the default codec preferences used by the user agent. This allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.

white-space: break-spaces

The white-space:break-spaces value allows authors to specify that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module specification's Trimming and Positioning rules) must be broken.

Removals

Remove feature policy: lazyload

The lazyload feature policy was intended to allow developers to selectively control the lazyload attribute on the <iframe> and <img> tags to provide more control over loading delay for embedded contents and images on a per origin basis.

The policy is removed in favor of a newer feature policy for loading, namely loading-frame-default-eager which is more aligned with how the loading attribute will be used. The removal applies to both the Feature-Policy header and the <iframe> allow attribute.

Remove outputs from MediaStreamAudioDestinationNode

According to the specification, the MediaStreamAudioDestinationNode in the Web Audio API should have no outputs. Chrome's implementation has a single output which has been removed.

Remove insecure usage of DeviceMotionEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium's implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

Remove insecure usage of DeviceOrientationEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium’s implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

The Story So Far
As part of an effort to increase user security and privacy, Chrome is planning a number of changes to the extensions platform. We announced some of these changes last October, and have provided additional context on them today. These changes to the platform are being implemented as part of Manifest V3 – the next version of the Chrome Extensions platform.

One of these changes is to move away from the blocking version of the Web Request API towards a new API, called Declarative Net Request. There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers.

In order to improve the security and privacy guarantees of the extensions platform, we are rethinking some of the extension platform's core APIs. That's why we're planning to replace the blocking Web Request API with the Declarative Net Request API.



How Web Request Works

With Web Request, Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails. The extension has a chance to evaluate the request, and then tells Chrome what to do with the request: allow it, block it, or send it with some modifications. As a result, extensions that leverage the Web Request API typically have access to read and manipulate everything a user does on the web.


While this API is used by good actors to implement powerful features like content blockers, it can also be - and has been - abused. Because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user’s credentials, accounts, or personal information. Since January 2018, 42% of malicious extensions use the Web Request API.

In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.

As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses.



Enter Declarative Net Request

The Declarative Net Request API works differently than the Web Request API. Instead of Chrome sending all the information about a request to the listening extensions at the time of the request, extensions register rules that tell Chrome what to do if certain types of requests are seen.


This approach has advantages for both user security and privacy, as well as performance. With a declarative approach, Chrome does not need to expose any sensitive data to the extension. The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken. This enables the extension to perform content blocking without needing access to all of a user’s personal information.

This has significant performance implications. Most importantly, a persistent, long-running process is no longer necessary because rules are registered before requests are made rather than needing to process them at runtime. This also cuts down on the cost of serializing all the request data and shuttling the inter-process messages to the listening extensions. These performance improvements will make extensions significantly more viable on resource-constrained platforms.



Why Not Both?
In addition to the performance concerns raised above, the Chrome team strongly believes that users should not have to expose their emails, photos, social media, or any other sensitive data to an extension if the extension doesn’t actually need that access to perform its function. And historically, when extension developers are given the choice between capability and security, the vast majority of developers choose capability. We've seen this repeatedly on the extensions platform with event pages, optional permissions, and activeTab.



Enterprise
Enterprises, schools, and businesses often require different network and software controls to comply with corporate policies. Additionally, these organizations typically have administrators whose role it is to understand and set up their environments.

Chrome provides enterprise controls through its administrator policies. The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome. System administrators can continue to manage Chrome in enterprise environments for free using OS-provided mechanisms to deploy Chrome policies.



Moving Forward
Declarative Net Request, and the whole of Manifest V3, is still very much in design and development. We are continuing to iterate on it, responding to community feedback and working with developers to help support different use cases.

Since the original announcement of the Declarative Net Request API, we have added significant functionality to the API as a result of these discussions. The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.

We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expressions. Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.

We will continue working with the developer community moving forward. We understand that adopting Manifest V3 will require developers to update their extensions and we will continue to support them through this transition.



Posted by Simeon Vincent, Developer Advocate for Chrome Extensions