[go: up one dir, main page]

The Payment Request API is a web standard to make it easier for web developers to build low-friction and secure payment flows. The browser facilitates the flow between a merchant website and “payment handlers”. A payment handler can be built-in to the browser, a native app installed on the user’s mobile device, or a Progressive Web App. Today, developers can use the Payment Request API to access several payment methods, including “basic-card” in Chrome on all platforms, Google Pay in Chrome on Android, and Apple Pay in Safari. The Chrome team continues to work with other browser vendors and digital wallet developers to make more payment handlers available with this new standard.

Shipping the Payment Request API over the last two years helped us better understand the challenges in building payment flows on the web. We learned that UX is critical for building user trust with a payment app, and new technology such as tokenization has made great strides in protecting users from online fraud by never exposing a user’s credit card number to a website. Unfortunately, Chrome’s built-in payment handler for “basic-card” falls short on both regards. As we considered solutions, we realized that the best way to enable more seamless and secure payments on the web is to enable an interoperable ecosystem, where digital wallets can bring their best experience to the web. This means shifting focus to the Payment Handler API, which is an emerging W3C standard that allows 3rd party payment handlers, which can be either native mobile apps or progressive web apps, to integrate with the browser to handle Payment Requests. This enables users to complete one-click payments anywhere on the web using their wallet of choice.

This shift in focus means that we will eventually sunset Chrome’s built-in “basic-card” payment handler. We will start by removing “basic-card” support from iOS Chrome, where this feature has the least usage. This change is coming in M81. In its place, we are investigating how to enable native apps on iOS to integrate with Payment Request API in Chrome. The “basic-card” payment method remains a W3C standard and developers can build compatible payment handlers using the Payment Handler API by setting method to “basic-card” when registering a payment handler with the browser.

This M81 change will deactivate Payment Request API on iOS Chrome because “basic-card” is the only supported payment method and because payment handlers are unavailable due to the lack of Payment Handler API support in WKWebView. If you’re a developer that uses Payment Request API, please make sure you use feature detection and provide a suitable fallback to ensure iOS users continue to have a working alternative. This is also needed to ensure your website works as expected in browsers that don’t yet support Payment Request API.



If you have feedback on Chrome’s web payments implementations, you can reach us at paymentrequest@chromium.org. If you have feedback on the web payment API specifications, find us at the W3C Web Payments Working Group.


 Posted by Danyao Wang, Web Payments Engineer
Labels: , , ,

The Application Cache (AppCache) specification has been deprecated since December 2016 and in Chrome starting in version 79. In Chrome 70, AppCache was removed from insecure contexts. We plan to remove AppCache in Chrome 82. Prior to AppCache's removal in Chrome 82, we're announcing a security fix that introduces the concept of a manifest scope.

Beginning in Chrome 80 in January, 2020, the scope of the AppCache manifest will be restricted to the path it is served from. Previously, a manifest served from any location within a site's origin could override everything within that origin. For example, a manifest served from www.example.com/foo/bar/ would previously allow overriding any URLs within www.example.com. Now it will only allow overriding URLs beginning with www.example.com/foo/bar/, the scope of the manifest.

Does This Affect My Website?
To see if this affects your website, go to chrome://appcache-internals/ and compare the path of the manifest to the paths under File URL. Note that this change only affects "Intercept" and "Fallback" properties. (See the image below.)


You should also test your site using the command line feature flag. To do so:
  1. Launch Chrome 80 using the following command:

    google-chrome --enable-features="AppCacheManifestScopeChecks"
  2. Open chrome://appcache-internals/, find your manifest and remove it.
  3. Open your site so a new AppCache instance is created.
  4. Open chrome://appcache-internals/, verify your manifest appears as expected and parser version is set to 1.
  5. Go offline, then access your site so it's served from AppCache. Verify all pages load as expected.
Mitigations
The replacement technology for AppCache is the Cache API, which requires a service worker. For a shorter term mitigation, add the following HTTP response header to your manifest responses:


X-AppCache-Allowed: /

This header is new in Chrome 80 and will be supported until Chrome 82, which is our announced AppCache removal milestone. Please be aware that AppCache, like all Chrome features, makes use of the disk cache to fetch server responses, so any long-lived disk cache entries for a manifest must be cleared in order to pick up a server X-AppCache-Allowed header change.
Posted by jmedley
Labels: ,

Note: The timeline has been updated, please see our October 2021 post for more details.

The web platform has made substantial progress since the launch of Chrome Apps in 2013. As community members, we continue to work with other browsers and invest to bring rich new capabilities to the platform, as seen in the announcements made at the Chrome Developer Summit last November.

The progress of modern browsers puts the Web in a good position to answer the vast majority of use cases - evident in the success of companies like Figma and our own products like Google Earth. We are confident that the Web can deliver first class experiences on an open platform.

With this continued progress, we are expanding upon our earlier announcement and will begin phasing out support for Chrome Apps across all operating systems as follows:

  • March 2020: Chrome Web Store will stop accepting new Chrome Apps. Developers will be able to update existing Chrome Apps through June 2022.
  • June 2020: End support for Chrome Apps on Windows, Mac, and Linux. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through December 2020.
  • December 2020: End support for Chrome Apps on Windows, Mac, and Linux.
  • June 2021: End support for NaCl, PNaCl, and PPAPI APIs.
  • June 2021: End support for Chrome Apps on Chrome OS. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through June 2022.
  • June 2022: End support for Chrome Apps on Chrome OS for all customers.

This change does not impact support for Chrome Extensions. Google will continue to support and invest in Chrome Extensions on all existing platforms. Fostering a robust ecosystem of extensions is critical to Chrome's mission and we are committed to providing a useful extension platform for customizing the browsing experience for all users.

For additional details (e.g., timelines, recommendations, a FAQ, etc.) please visit our Chrome Apps migration site. This page will be kept up to date as we progress together through this process.

On behalf of the Chrome team, we thank the community of developers for building great experiences using Chrome Apps and look forward to seeing similar experiences that leverage open Web standards (e.g., PWAs) across all modern browsers.

Posted by Anthony Laforge, Technical Director, Chrome Platform Team

Labels: , ,


In August, we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. Our goal for this open source initiative is to make the web more private and secure for users, while also supporting publishers. Today, we’d like to give you an update on our plans and ask for your help in increasing the privacy of web browsing.

After initial dialogue with the web community, we are confident that with continued iteration and feedback, privacy-preserving and open-standard mechanisms like the Privacy Sandbox can sustain a healthy, ad-supported web in a way that will render third-party cookies obsolete. Once these approaches have addressed the needs of users, publishers, and advertisers, and we have developed the tools to mitigate workarounds, we plan to phase out support for third-party cookies in Chrome. Our intention is to do this within two years. But we cannot get there alone, and that’s why we need the ecosystem to engage on these proposals. We plan to start the first origin trials by the end of this year, starting with conversion measurement and following with personalization.

Users are demanding greater privacy--including transparency, choice and control over how their data is used--and it’s clear the web ecosystem needs to evolve to meet these increasing demands. Some browsers have reacted to these concerns by blocking third-party cookies, but we believe this has unintended consequences that can negatively impact both users and the web ecosystem. By undermining the business model of many ad-supported websites, blunt approaches to cookies encourage the use of opaque techniques such as fingerprinting (an invasive workaround to replace cookies), which can actually reduce user privacy and control. We believe that we as a community can, and must, do better.

Fortunately, we have received positive feedback in forums like the W3C that the mechanisms underlying the Privacy Sandbox represent key use-cases and go in the right direction. This feedback, and related proposals from other standards participants, gives us confidence that solutions in this space can work. And our experience working with the standards community to create alternatives and phase out Flash and NPAPI has proven that we can come together to solve complex challenges.

We’ll also continue our work to make current web technologies more secure and private. As we previously announced, Chrome will limit insecure cross-site tracking starting in February, by treating cookies that don’t include a SameSite label as first-party only, and require cookies labeled for third-party use to be accessed over HTTPS. This will make third-party cookies more secure and give users more precise browser cookie controls. At the same time, we’re developing techniques to detect and mitigate covert tracking and workarounds by launching new anti-fingerprinting measures to discourage these kinds of deceptive and intrusive techniques, and we hope to launch these measures later this year.

We are working actively across the ecosystem so that browsers, publishers, developers, and advertisers have the opportunity to experiment with these new mechanisms, test whether they work well in various situations, and develop supporting implementations, including ad selection and measurement, denial of service (DoS) prevention, anti-spam/fraud, and federated authentication.

We are looking to build a more trustworthy and sustainable web together, and to do that we need your continued engagement. We encourage you to give feedback on the web standards community proposals via GitHub and make sure they address your needs. And if they don’t, file issues through GitHub or email the W3C group. If you rely on the web for your business, please ensure your technology vendors engage in this process and share your feedback with the trade groups that represent your interests.

We will continue to keep everyone posted on the progress of efforts to increase the privacy of web browsing.

Posted by Justin Schuh - Director, Chrome Engineering





















Labels: , ,

Notifications on the web enable users to receive important updates even when they are not interacting with a website. Notifications are an essential capability for a wide range of applications including messaging, calendars, email clients, ride sharing, social media and delivery services. Unfortunately, notifications are also a common complaint as many websites request the notification permission on first visit rather than at contextually relevant moments in the user’s journey. Unsolicited permission requests interrupt the user’s workflow and result in a bad user experience. To protect notifications as a useful service for users, Chrome 80 will show, under certain conditions, a new, quieter notification permission UI that reduces the interruptiveness of notification permission requests. In Chrome 80, users will be able to opt-in to the new UI manually in Settings. In addition, the quieter UI will be automatically enabled for users under two conditions: first, for users who typically block notification permission requests and second, on sites with very low opt in rates. The automated enrollment will be enabled gradually after the Chrome 80 release while we gather user and developer feedback. Later in 2020 we plan to enable additional enforcement against abusive websites using web notifications for ads, malware or deceptive purposes. This enforcement will be described in detail in a future blog post.


Quiet UI overview
Quieter UI (Desktop and Mobile)
The quieter UI is available in both Desktop and Mobile. The first time the UI is presented to the user, it will be accompanied by a dismissable in-product help dialog that explains the new feature.
Enrollment & opt out
Users can be enrolled in the quieter UI in three ways.
Manual enrollment (and opt-out)


Manually enroll on Desktop or Mobile via Notifications Settings
Users can enroll for quieter prompts manually, or disable it completely. To enroll, the toggle ‘Sites can ask to send notifications’ must be enabled in Settings > Site Settings > Notifications, then the checkbox ‘Use quieter messaging’ must be checked.
Automatic enrollment for users who infrequently accept notifications
Users who repeatedly deny notifications across websites will be automatically enrolled in the quieter notifications UI.
Automatic enrollment on sites with low permission acceptance rates
Sites with very low acceptance rates will be automatically enrolled in quieter prompts. They will be unenrolled once acceptance rates improve, for example, if the developer of the site improves the notification permission request user experience. Per-site information about notification permission acceptance rates will be made available via the Chrome User Experience Report in Q1 2020 and automatic enrollment is based on Chrome usage statistics. 
Developer recommendations
First, we recommend that web developers test their site’s permission request flow with the quieter notification permission UI, by enabling it manually in chrome://settings/content/notifications. At the time of writing, the feature is being rolled out gradually to Canary, Dev, and Beta channels, and can be force-enabled in chrome://flags/#quiet-notification-prompts in Chrome 80 and later. Second, we recommend that developers follow best practices for requesting the notification permission from users. Websites that ask users to sign up for web notifications when they first arrive often have very low accept rates. Instead, we recommend that websites wait until users understand the context and see benefit in receiving notifications before prompting for the permission. Some websites display a pre-prompt in the content area before triggering the native permission prompt. This approach is also not recommended if it interrupts the user journey: sites that request the permission at contextually relevant moments enjoy lower bounce and higher conversion rates. For help with user permission UX, you can refer to this 5 minute video on improving your user permission acceptance rates, and read about best practices when requesting permissions.

 Posted by PJ McLachlan, Product Manager
Labels: , , ,