Manifest V3: Accessibility concerns and suggestions regarding permissions

[mat...@gmail.com]

A lot of the changes in v3 seem great. However, Thomas clearly describes some important accessibility concerns [0] - that some extensions need to run on all URLs, automatically, in order to help their users access those pages.

As Devlin mentioned, the draft Manifest v3 document acknowledges this need, and states that users will be able to enable an extension for all URLs in the browser's settings [1]. However this is likely to exclude some users: those who are not technically literate, or who have access needs that could prevent them from being able to reach, or understand, that option [0].

As Thomas' post covers several issues, with the conversation leaning towards content blockers, I thought it would be OK to start a thread specifically relating to accessibility concerns and suggestions.


// Suggestions

These could work in concert. Only the last one would maintain the current Manifest v2 level of accessibility support out-of-the-box.

  A. In order to make the "all URLs" option more understandable, extensions should provide the reason why they need the access, to be displayed in the browser's UI (e.g. next to the "enable for all URLs" button or checkbox).

  B(1). Provide an API, like runtime.openOptionsPage(), to allow the extension to send the user directly to the extension's "browser-side" settings, to make the journey to the "all URLs" option easier. Also provide an API to allow an extension to check if it has that permission, like extension.isAllowedFileSchemeAccess(). Then, if it doesn't, a splash page (created by the extension developer) could be used to inform users why they may wish to enable it, and direct them to it.

        There's a possibility this may encourage extensions to follow this pattern unnecessarily, but I'm not sure that would happen in practice - developers would have to put effort in to use the APIs. Plus the user would have to feel there's value in enabling the option, or they wouldn't enable it.

  B(2). Alternatively, you could allow an extension to request the <all_urls> optional permission (i.e. strictly not at install time), but restrict this to only one attempt to do so, and only after the user has activated the extension x times, perhaps across y domains - which indicates the user has some level of interest in using it. The reason for the request would be included in the browser's permissions pop-up.

        Whilst supporting <all_urls> as an optional permission appears to've been discounted in the v3 document, perhaps it's more viable with the above limits? In order to make this approach work, an API to check for the permission before attempting to ask for it would need to be added, as with B(1) above.

  C. Have the browser detect that the user is choosing to activate the extension's features (via UI or keyboard command) on several/many pages, and have the browser itself offer to enable the extension for all URLs.

  D. Allow extensions in the "accessibility" category to request the "all URLs" permission on install - i.e. the install confirmation pop-up would state the extension's reason for needing that access (if the extension requires it) and proceeding with the install would enable that option.

Are there any other approaches that could be used? I hope the above might contribute to a discussion as to how accessibility extensions can continue to be fully supported under the new approach.


// Background info on the Landmarks extension

[ I'm including this as it may provide use-case info for Chromium developers. ]

Like some other accessibility extensions, the Landmarks extension [2] (which I maintain) needs to run on all pages, automatically. Specifically in order to:

  * Scan for landmarks when the user visits a new page (or a new view within a single-page app), and put a badge on the browserAction icon, to let users know if there are any landmark regions on the page - and therefore if it’s going to work for them to use the keyboard navigation commands. If the DevTools panel is open (or the sidebar, on Firefox or Opera) then it needs to be updated with any landmarks found.

  * Set up a mutation observer to detect changes to the page that may add/remove landmarks, so the information presented to the user (i.e. browserAction badge, DevTools panel if it's open and sidebar on Firefox and Opera) is always up-to-date.

As this extension is intended for people who use the keyboard only, I do have some concerns about the barriers raised by the process of traversing through the UI to get to the forthcoming "all URLs" option (I just tried it on the current version of Chrome and I found it non-trivial, as there is weak visual focus indication on some elements such as the Settings/Extensions hamburger menu and the search box), which was one of the factors behind suggestion B above.

best regards,


Matthew

[0] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/NgUi_TysRPI
[1] https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#heading=h.oenw1ekaaubz
[2] http://matatk.agrip.org.uk/landmarks/

[Devlin Cronin]

Hi Matthew,

Thank you for the feedback!

I think many of the suggestions you mentioned are actually available with the current design.  With runtime host permissions, we will continue to allow host permissions to be specified as optional within the manifest.  These permissions can then be requested using the permissions API, which works by presenting the user an option to approve more permissions in response to a user action.  This enables the extension to have its own "flow" for approving greater permissions, so that it can better explain the purpose of those permissions.  (We are very aware that Chrome could never provide enough context for all cases, so want to ensure extensions can still properly educate the user.)  This seems to be very much inline with your suggestion B(2).  You can also use the permissions API to request host permissions that were listed as "required", but later withheld by the user.

You can also query which permissions the extension currently has using the permissions.getAll() method.  This seems to solve the second part of B(1) ("an API to allow an extension to check if it has that permission").

Re C, that is something we are currently discussing, as well as other avenues to make these features more discoverable.

You can experiment with this today - <all_urls> is fully supported as an optional permission, and runtime host permissions are available in the latest versions of Chrome (tweakable by going to chrome://extensions and clicking on "Details" for an extension).  We are continually changing and refining the current experience, so running on Dev or Canary is probably best to explore these.

Does that help address some of your concerns?

Cheers,

- Devlin

[Vasco Gomes]

Hi there,

I think that the current Chrome system of dealing with this is perfect. 

The user can right click on a extension and very easy change if the extension runs on Active-tab, some sites or all URLs.

In my opinion the system works really well and it's perfectly running.

With this in mind I don't think that Manifest V3 needs to change this. 

The current deployed system is running good and users can fine tune each extension settings.

If Manifest V3 also change this, it will cripple a huge amount of extensions that will lay on the Chrome Web Store as zombie extensions. In the end users will give bad ratings and will be frustrated. In the end that will direct impact not only the Developers but the Chrome itself.

Making the users click on more buttons and accept more popups will turn to be just annoying. 

The current deployed system on Chrome with right click and fine tune the settings is perfect. And I have to congratulate who build it. I thing this is the way that this issue should be dealt and I don't think manifest V3 needs to change this.

I think that manifest V3 should tackle any issue always in a higher level making sure not to break extensions or cripple current extensions functionality. 

HTML and the Web was made for when something fail, fail beautifully. I think this was the key point for the web survival for so many years and Manifest V3 should make this as the primary point of development.

Greetings.

[cad...@gmail.com]

I'm going to talk here about the elephant in the room: The false argument that for the safety of people it is important to restrict the ability of action of extensions with version 3 of the manifesto.

For several years, users and even developers have been asking Google for a manual check of extensions in the Chrome web store so that malicious extensions are not published in the Chrome Store.

A full manual check of any new extensions submitted by a developer who has less than 2 years of seniority and less than 5 major revisions of its extensions would prevent the abuses that are seen today in the Chrome Store.

Also if an extension to more than 50,000 users a new full manual check would take place and another to 100,000 and 150,000 users etc etc.

Manual verification of extensions is the only effective way to protect users and allow them to use powerful and versatile extensions.

The only disadvantage of having manual reviews of extensions would be that developers should wait longer before their extensions are available to the general public, but it is a compromise that all serious developers would gladly accept.

Private extensions would not have to have a manual review only the public ones.

The longer an extension is, the more active the developer would be, the less likely the developer would be subject to manual reviews during subsequent updates of its extension as mutual trust would develop over time between Google and the developer.

Also selling an extension with its users should be impossible for the author and this to prevent abuse. In fact if it is sold the new acquirer should create a new entry in the Chrome Store and if it is a new developer it would be subject to more frequent manual verification.

The manual checks are very effective the Mozilla AMO was very safe and had very few malicious extensions when the checks were manual and from the moment the mandatory manual checks were removed the malicious extentions abound almost as much as in the Chrome Store unfortunately.

I am aware that my post is not directly related to version 3 of the manifest but it directly affects the reason why Google says that it wants to cut / remove power APIs ie user security.

Personally I believe Google does not want to hire people to do manual verification because its profit margins would decrease what proves that the real and main objective of Google is not the safety of people or to make advanced technology but that its Profit margins remain as high as possible.

Google unfortunately favors having a lot of crappy extensions instead of privileging the quality and safety of people because it attracts more people to have "big numbers" that is why he does not seem to know anything about doing manual extension checks because the number of extensions in the Chrome Store would decrease and so would Google's profits.

So removing features in the extension APIs to stay safe amounts to eating 1 x a week to have less chance of suffering from food poisoning instead of adding food inspectors so that food quality is assured, it's stupid and shows that the real goal is to save money on the backs of users and not to increase their security.

[mat...@gmail.com]

Thanks for your reply Devlin. I do have some concerns still (as below) but It’s encouraging to hear that there are some options open, and more being considered. Sorry I missed permissions.getAll() - I had assumed something like that may exist, and searched for it, but didn’t find it.

With any approach that adds more steps - particularly for people who may struggle to perceive, operate or understand those extra steps - users can be excluded. So I am concerned that some people will be unable to independently work through the permissions-granting process in v3, and will thus be unable to use some accessibility extensions as effectively, or even at all. [There’s a bit more discussion of this below.]

It’s great to hear that you and your team are considering options like suggestion C above, and other approaches too. I would again put forward suggestion D for consideration - possibly with extra requirements on the part of the accessibility extension, maybe even such as manual review (as has been suggested since). Perhaps whilst the accessibility extension is awaiting review, it would use the optional permissions v3 approach, but after being approved, it could be allowed to request <all_urls> during the single install step, as with v2?

I checked out the new UI and have some thoughts and suggestions, below, in case they are of help. I am looking forward to following further developments.

best regards,


Matthew


// A bit more background discussion on supporting independence

I’m wondering how ChromeVox, High Contrast and the other Google accessibility extensions may handle this - I’m guessing like suggestion C(1) as you describe. Of course there’s an assumption that people have some other assistive technology outside of the browser that would help them install these extensions and then configure the permissions later on, because that’s to be done in the browser’s UI, which is not modifiable by such extensions.

However it would be good to not have to rely on other assistive technologies for any further configuration after install - such “assistive technologies” may in fact be other people who are supporting the person trying to install the accessibility extension, for example, and thus may not always be available, plus we should do everything we can to support independence.


// Thoughts on the UI in Chrome Canary

Here are some thoughts, barriers I noticed and suggestions…

1. It’s quite a journey to get to the permissions settings for keyboard-only users (imagine this being multiplied for someone who is also using a screen-reader, who can’t necessarily get a visual overview of the pages they’re traversing, or someone using a single-switch input device). All of that navigation constitutes extra time and effort required compared to the v2 approach.

2. The main Extensions page UI doesn’t give strong clues that permissions can be changed, and “Details” is not very indicative of this, so users would really have to go exploring in order to find it.

3. The permissions section should probably be the first one on the extension details page - it seems to me that it’s more important to most users than the extension’s version or size (which are both good to know, and I find interesting personally).

4. When an existing extension such as Google’s High Contrast one, or Landmarks, is coded with a requirement of <all_urls>, but the user has set the permissions to “On click”, this is indicated by a light circular border around the icon in the toolbar, and a tooltip on mouse hover. How about adding to this UI a shortcut, provided by Chrome, directly to the permissions-granting bit of the extension details page? (That would be a bit like suggestion B in my first post.)

5. The permissions phrase “On Click” isn’t necessarily clear, nor accurate, as I noticed that using a keyboard command also caused the Landmarks extension to start working (though the action associated with the keyboard command didn’t then occur, after the extension was enabled). How about “When I use it” or something like that?

6. The “Permissions” and “Allow in incognito” headings on the extension details page are not very prominent - perhaps changing the styling, and marking them up semantically as HTML headings, would help draw attention to them. Actually the extension’s name isn’t marked up as a heading either, but seems like it should be, as it’s very prominent.

7. Presenting the choices of permissions as a group of radio buttons, as is done in newer builds, certainly is much clearer and more user-friendly.

8. The “Learn more” info (“i”) link next to “Permissions” in Chromium, Dev and Canary, has an aria-label attribute, but doesn’t indicate what the user will be learning more about. Visually there is proximity to tell the user that “learn more” relates to permissions, but links must indicate where they go within their own text/label in order to be accessible. (Some screen-reader users will navigate the page via a list of links, for example; voice-only users need clear link text, too.) I realise it’s beta, but noticed it, so thought I'd mention it :-).