Manifest V3: New API chrome.favicon and access to all web resources without credentials

[Marco WA]

Dear Chrome Developers!

I am the developer of a Chrome extension that displays bookmarks with large website icons on the new tab page. 

The extension can also load and display RSS feeds for bookmarked websites. *)

Because the extension downloads icons and feeds directly from bookmarked websites it needs the permission to access all urls ('http://*/' and 'https://*/').

More specifically, the extension currently needs to parse a website's html document to search for the urls of large website icons ('apple touch icons') and RSS feeds in the dom. 

It is my understanding that with manifest v3 the permission to access all urls can no longer be granted during the install process of an extension and that Chrome developers will provide a new api that will provide favicons (chrome.favicon).

Regarding this, I have the following questions and suggestions:

(1a)

I read that it will still be possible to get 'the permission to access all urls'  at once as an optional permission in the future. 

Is this true?

(1b)

Is the process (the UX) of getting that optional permission the same as it is for other optional permissions (like 'clipboardRead' or 'clipboardWrite')?

(2)

In my use case I do not need nor want to access web resources with cookies/credentials. So I use the 'fetch api' to load web resources explicitlly without credentials.

In my opinion the permission to access web resources without credentials raises much less security concerns then the access with credentials.  

So I wonder, if it would be possible to have two separate permissions for that in the future:

[A] 'Access the internet' (without credentials)

[B] 'Read and change all your data on the websites you visit'  (with credentials)

Where permission [B] implies permission [A]. 

Of cource, in my case, it would be great if permission [A] ('Access the internet') could still be granted during the install process of an extension. 

What do you think about this proposal?

(3)

I couldn't find any documents about the new api 'chrome.favicon'. 

(3a)

Will this api provide large website icons (bigger then, for instance, 120x120 pixels)?

Or will this api provide only small favicons (16x16 pixels).

(3b)

Will it be possible to further process the image data of those icons in js (for instance draw a icon on a canvas)?

I look forward to your response.

Thank you very much!

Cheers,

Marco

*)

Favorites for Chrome:

https://chrome.google.com/webstore/detail/favorites-new-tab-page/kjkbcegjfanmgocnecnngfcmmojheiam

[Decklin / Deco]

For further discretion, take a read at the Manifest V3 document. 

Manifest V3 is still very much in the early development phase, so you will not find answers to all your questions, however with the main enquiry of the <all_urls> for URL regex matching, this is not the case with v3. You will still be able to utilise this matching pattern, however the difference with this is that Chrome will allow the user to decide if it will run on all websites, instead of the popup prompt activated at installation time asking the user for the permission - this changes the permission from static, to a dynamic request - meaning it can be accepted or denied without reinstalling the extension.

In regards to what this means for yourself - not much, you will still be able to utilise it for the manifest file.

"Extensions can request different host patterns and scopes in the manifest. They can request specific hosts (https://google.com), host patterns (https://*.google.com, allowing access on all google.com domains and subdomains), or even request permission to all sites ( or *://*/* for all HTTP/HTTPS sites). The latter allows the extension to inject scripts on, intercept network requests from, and read cookies for any domain, including social networks, financial websites, corporate sites, etc. - all without any further indication or permission from the user. 

In some cases, this broad permission can be necessary to the extension's functionality (most content blocking is desired to run on every site, as are accessibility features). In other cases, extensions request this permission even if they don't need it, partially because there is very little penalty for doing so now and partially because requesting permissions after installation results in users being prompted for permissions, which leads to many users uninstalling or disabling the extension".

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/dd9b32f3-daf6-459b-956e-f79a964f662c%40chromium.org.

[Marco WA]

Hi Decklin!

Thank you for your response. 

I read the Manifest V3 document before and have also found the passage that you have quoted. 

And this is really what I am concerned about:

"[...] requesting permissions after installation results in users being prompted for permissions, which leads to many users uninstalling or disabling the extension which leads to many users uninstalling or disabling the extension [...]"

Hence my idea to have two separate permissions.

Because I really do not want to 

"[...] inject scripts on, intercept network requests from, and read cookies for any domain, including social networks, financial websites, corporate sites, etc. [...]"

I only need access to publicly available web resources like the xml document of a rss feed or a html file to look for icon urls. 

I do not want to access these resources with the users credentials. 

I think the current situation to have only one type of permission that gives an extension access to sites with the users credentials -or- to have no access at all is not optimal. 

And I think that is exactly the reason what makes this permission so 'scary'.

In my opinion having two separate permissions would be much better for users and developers alike.

You wrote ...

[...]  this changes the permission from static, to a dynamic request - meaning it can be accepted or denied without reinstalling the extension [...]

 

I think this is no longer true. Users already can revoke the permission to access all urls at any time via the extension menu (behind the extension button) or via Chrome settings. No reinstallation needed.  

And I would not mind if this possibility would be even more prominent in the future. 

So what do you think about the idea of having two separate permissions?

I think reading a users facebook posts is a very different use case than loading publicly available web resources that can be accessed by anybody not logged into facebook. 

Thank you very much!

Cheers,

Marco

On Thursday, June 27, 2019 at 6:26:30 PM UTC+2, Decklin / Deco wrote:

For further discretion, take a read at the Manifest V3 document. 

Manifest V3 is still very much in the early development phase, so you will not find answers to all your questions, however with the main enquiry of the <all_urls> for URL regex matching, this is not the case with v3. You will still be able to utilise this matching pattern, however the difference with this is that Chrome will allow the user to decide if it will run on all websites, instead of the popup prompt activated at installation time asking the user for the permission - this changes the permission from static, to a dynamic request - meaning it can be accepted or denied without reinstalling the extension.

In regards to what this means for yourself - not much, you will still be able to utilise it for the manifest file.

"Extensions can request different host patterns and scopes in the manifest. They can request specific hosts (https://google.com), host patterns (https://*.google.com, allowing access on all google.com domains and subdomains), or even request permission to all sites ( or *://*/* for all HTTP/HTTPS sites). The latter allows the extension to inject scripts on, intercept network requests from, and read cookies for any domain, including social networks, financial websites, corporate sites, etc. - all without any further indication or permission from the user. 

In some cases, this broad permission can be necessary to the extension's functionality (most content blocking is desired to run on every site, as are accessibility features). In other cases, extensions request this permission even if they don't need it, partially because there is very little penalty for doing so now and partially because requesting permissions after installation results in users being prompted for permissions, which leads to many users uninstalling or disabling the extension".

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[李白字一日]

favicon can't be properly shown through new favicon api.

This is my published v3 chrome extension using favicon api.

most of them have beautiful favicons.