On this page:
- Project Strobe
- What are the available, relevant permissions options
- How would switching to activeTab affect AST
Project Strobe
On October 15th 2019, Google implemented a new policy around the use of web extension permissions in response to a project to restore trust in browser extensions' use of user data. Below are some relevant links to that project.
- https://www.blog.google/technology/safety-security/project-strobe/
- https://blog.chromium.org/2019/07/project-strobe-updates.html
- https://developer.chrome.com/webstore/user_data
In response to this policy change, Level Access reviewed our usage of the all_urls permission in Access Assistant (AST) and our other extensions, including Continuum Explorer (EX). Our usage does fall into acceptable use per Google's policy, but did require us to add an extra validation step by users and documentation about our use:
- We now disclose our use of the permission in the Chrome Store.
- We reviewed our existing Privacy Policy and added a link directly to it within the AST and EX interface.
- The deployment of AST and EX will be to a limited group of people trained on its usage
- The all_urls permission grants access to more data, but that data is only read when the user directs takes action, i.e. by running an accessibility test. That data is only sent back to our servers upon user action, also. When a user performs an action that requires use of this permission, they will receive a notification, such as in the screenshot below, and be required to allow usage of the permission.
Since the policy went into effect, we have submitted AST and EX for review and undergone a manual compliance review by Google. AST and EX were deemed to be in compliance and was published to the Chrome Store.
This document describes these extensions usage of the all_urls permission and describes the impact on the user experience should this usage be removed.
What are the available, relevant permission options?
activeTab
The activeTab permission grants an extension temporary access to the currently-active tab when the user invokes the extension. If the extension is compromised, the attacker would need to wait for the user to invoke the extension before obtaining access, and that access would only last until the tab is navigated or closed.
While the activeTab permission is enabled for a tab, an extension can:
- Call executeScript or tabs.insertCSS on that tab.
- Get the URL, title, and favicon for that tab via an API that returns a Tab object.
- Intercept network requests in the tab to the tab's main frame origin using the webRequest The extension temporarily gets host permissions for the tab's main frame origin.
(ref: https://developer.chrome.com/extensions/permission_warnings)
all_urls
The all_urls permission grants an extension the same access as activeTab but across all open tabs in the browser. This permission is optionally used by AST and EX, which means users will be required to allow usage of the permission in any of the scenarios described below that require their use.
What functionality leverages the all_urls permission?
Seamless testing across pages
AST allows users to seamless navigate between tabs, windows, and popup windows while maintaining a connection to the currently-active tab. This allows users to run accessibility tests on any screen without relaunching AST.
Tab switching
Many users test assets based on a script, enter defects into bug tracking systems, or track notes as they complete their work. This is often accomplished by having multiple tabs/windows open during a test: the page being tested, a Sharepoint document of the test script, a Jira window to track defects, etc.
Testing of cross-domain iframe content
Sites often pull in content from other domains using embedded iframes. Social media feeds and corporate blogs are just a couple examples.
How would switching to activeTab affect AST?
Seamless testing across pages
activeTab would limit users to testing a single page on the active tab at the time AST was launched. Navigating or closing the tab would sever the connection to AST.
Impact: AST or EX would need to relaunched for every single page tested.
A use case would be testing a sample of 25 pages for a site. Every time you go to the next page in your list, you will need to relaunch AST, re-navigate back to the report, and capture the module to run the automatic tests. Repeat this for every page to be tested. If you are doing any manual testing, you would have to repeat this again for every page when you go back to do manual testing, unless you complete all testing of every page before moving to the next one. This dramatically increases the workload to do even basic testing.
Tab switching
Any time a user navigates to another tab, the activeTab connection to AST is severed. To resume testing after navigating back to the page being tested, users would be required to relaunch AST. This behavior was observed in our preliminary investigation of using activeTab.
Impact: Users would only be able to use their browser for the single purpose of testing a page.
You are testing a page and evaluating the instances that are flagged for review by AST. In another tab, you have the W3C WCAG 2.0 specification open as a reference. Whenever you need to check the reference to better understand one of the flagged instances, you will lose your connection, forcing you to close AST, relaunch it, navigate back to the report, find the module associated with the page, and find the instance you were evaluating in order to pass or fail it.
Testing of cross-domain iframe content
The all_urls permission grants AST access to all domains while activeTab would restrict it to the domain of the activeTab when AST was launched.
Impact: activeTab would prevent testing of any iframe content not on that same domain.
A loan calculator is used on multiple sections of the site, and it is hosted on a different domain than the rest of the site. This calculator is loaded in an iframe on each page where it is used. AST will be unable to capture the iframe to test the accessibility of that loan calculator.