Improve the flow of host permission granting about scratchaddons

[Samq64]

Alternatively the more options button could just open the browser's permission page. Toggle descriptions could be useful though.

[WorldLanguages]

With this implementation, we may even decide to make all permissions optional and show them to the user during onboarding, even on browsers that grant us required host permissions during installation. That means Scratch Addons, whether used on Chrome or Firefox, would have the same flow of allowing site access.

Making all host permissions optional is planned by the Chrome extensions team, and we won't have a choice. The final design is yet to be seen, but I'm pretty sure Chrome wants to go away from granting host permissions when installing.

[WorldLanguages]

I don't think it will ever be necessary to ask for a scratchaddons.com host permission (we can always use a Scratch iframe if needed and configure CORS properly in our own website) but if we want, we could assume it is for the purpose of this UI and avoid any requests to it if it's disabled. Probably not a good idea?

Having separate permissions for scratch.mit.edu, api and clouddata makes very little sense as well. Remember that the scratch.mit.edu website can already access the other two, so the first permission implies the two others. If users want to disable all website addons but continue to use Scratch Messaging, we can provide something more intuitive instead, such as an extension pause button or disable toggle (there's more discussion in other issues).

I can only see the UI making sense if we add toggles for more sites, such as running editor addons on ScratchLab, CSFirst, etc.

[DNin01]

I don't think it will ever be necessary to ask for a scratchaddons.com host permission (we can always use a Scratch iframe if needed and configure CORS properly in our own website) but if we want, we could assume it is for the purpose of this UI and avoid any requests to it if it's disabled. Probably not a good idea?

Then the only benefit to requesting permission to scratchaddons.com would be that the user would understand why we are able to access it. (One would expect that we need that permission at first, right? But actually, we can just access it through a content script on a Scratch page we have access to.)

On the other hand, in general, it makes sense to request as few permissions as possible, so not asking for this permission would be one less impediment to getting started with Scratch Addons.

Having separate permissions for scratch.mit.edu, api and clouddata makes very little sense as well. Remember that the scratch.mit.edu website can already access the other two, so the first permission implies the two others.

For users that don't know everything about Chrome's extension permissions system, that seems like a reasonable assumption. I don't think anyone would be surprised if we could access those Scratch endpoints using a single host permission to scratch.mit.edu.

[WorldLanguages]

To clarify, requesting the api and clouddata permissions directly is handy, as we can reach those subdomains from the background context with a normal fetch. But in theory, we could also access those two by making the requests from a scratch.mit.edu tab or background iframe.

[WorldLanguages]

Then the only benefit to requesting permission to scratchaddons.com would be that the user would understand why we are able to access it.

I'm not the average user, but of course extensions can access public information where CORS headers are correctly configured. Some addons already do this with ScratchDB and Ocular.

[DNin01]

Then the only benefit to requesting permission to scratchaddons.com would be that the user would understand why we are able to access it.

I'm not the average user, but of course extensions can access public information where CORS headers are correctly configured. Some addons already do this with ScratchDB and Ocular.

Can that be done even from within extension pages without host permissions? I've never actually looked to see if an extension can make any fetch it wants or only fetches to sites that it has been granted a host permission to.

Either way, I'd bet if any requests were blocked by CORS, a host permission would be required.

[DNin01]

So, extension pages can fetch anything, but I tried a bunch of Scratch URLs and the only one I was able to fetch from was an embeddable project page; all the others were blocked due to CORS. But other websites can access them... It's probably because extension pages' scheme is chrome-extension: but the requests we're trying to make are to https: pages.

And of course, fetches to any site that the extension has permission to access will succeed, regardless of the CORS configuration.

[WorldLanguages]

But other websites can access them

No...?
Also, you want to distinguish between 1) making a request, 2) making a request with credentials/cookies, and 3) being able to read the response.