Disallow opener navigation downloads from cross origin popups
If a popup navigates its opener to a URL which results in a download, the download will be blocked and the navigation cancelled, if the popup is cross-origin to its opener. This resolves a long standing security issue.
Remove PaymentAddress's languageCode property
PaymentAddress.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 the 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.
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.
Removal is expected in Chrome 74.
To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:
- They are superseded by newer APIs.
- They are updated to reflect changes to specifications to bring alignment and consistency with other browsers.
- They are early experiments that never came to fruition in other browsers and thus can increase the burden of support for web developers.
Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.
Chrome currently has a process for deprecations and removals of API's, essentially:
- Announce on the blink-dev mailing list.
- Set warnings and give time scales in the Chrome DevTools Console when usage is detected on the page.
- Wait, monitor, and then remove the feature as usage drops.
You can find a list of all deprecated features on chromestatus.com using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.