Clarification on MV3 transition to 'configuration driven logic'

[Haydn Appleby]

Hello Community and Simeon,

We are seeking some clarification on the subject of replacing 'remotely hosted code' with 'configuration driven logic' in our extension.

We are dependent on running remotely hosted code and are investigating its replacement by JSON configurations. The question is: is browser automation (like the simplest version of UI.Vision RPA or Selenium IDE) considered as a misuse of configuration-driven approach?

A key feature of our extension is taking control of certain pages to automate a task. To achieve this, we write a custom script specific to some domain (very similar to Selenium or Puppeteer E2E tests). I’ve attached a third-party example JSON config at the bottom. Requirements are:

- Active rotation cycle. New scripts are being added and fixed on a daily basis. If we bundle then inside the extension, we are not likely to be able to release fixes in good time.

- Flexibility of automation scripts. To provide the best UX for our users, we have to introduce some conditional logic, wait for certain events on a page, trigger appropriate actions etc.

We would really appreciate it if you could clarify what are the limits of configuration-driven approach? Or give some idea on when there may be some more concrete statement on this question from the MV3 team?

Many thanks for you assistance,

Haydn Appleby

Example of what a JSON configuration could look like...

{

  "Name": "<domain name>",

  "CreationDate": "2020-10-8",

  "Commands": [

    {

      "Command": "open",

      "Target": "<url>",

      "Value": ""

    },

    {

      "Command": "clickAndWait",

      "Target": "css=#mainContent > div.athenaBasket_basket.athenaBasket_basket-grid > div.athenaBasket_foot.athenaBasket_foot-ie > div",

      "Value": ""

    },

    {

      "Command": "click",

      "Target": "id=discountcode",

      "Value": ""

    },

    {

      "Command": "click",

      "Target": "xpath=//*[@id=\"mainContent\"]/div[2]/div[3]/div/div/div/div[2]/div/div[2]/div",

      "Value": ""

    },

    {

      "Command": "clickAndWait",

      "Target": "css=#mainContent > div.athenaBasket_basket.athenaBasket_basket-grid > div.athenaBasket_foot.athenaBasket_foot-ie > div",

      "Value": ""

    },

    {

      "Command": "click",

      "Target": "id=discountcode",

      "Value": ""

    },

    {

      "Command": "type",

      "Target": "id=discountcode",

      "Value": "4WXO4-AATG-8S14"

    },

    {

      "Command": "clickAndWait",

      "Target": "id=add-discount-code",

      "Value": ""

    }

  ]

}

[Kevin Yang]

We are facing a similar dilemma as we are also building a browser automation platform where users can choose to write custom JS functions that are remotely hosted.

I imagine if your JSON configurations become sufficiently complex, they are just as dangerous as RHC. I'm intrigued to see how the ChromeExt team will support UserScripts. I imagine the same technique will apply to automation extensions where the explicit intent is to run RHC.

[Todd Schiller]

We don't support custom JS, but do support things like Mustache templates, element selectors, etc. shared within a team. 

We were surprised by this language in the Developer Program Policies that was just released: "The extension may reference and load data and other information sources that are external to the extension, but these external resources must not contain any logic." 

A reasonable interpretation of the policy would be, the external resources can configure an included behavior, but not add new behaviors. In the selector example, "selecting and element" is the behavior, so any configuration maintains the same behavior. A draconian interpretation of the word "logic" would prohibit selectors because they can vary which element is selected

So far we've been passing the review process answering "No" for "Are you using remote code?" Is it OK to assume that we'll also be compliant under Manifest v3? Or is the standard for that attestation somehow different for Manifest v3?

Thanks for the clarification!

Todd

[Darbid Darbid]

I too am interested in some clarification here as well.  My extension has/is 

1. unlisted in the store
2. is used by people I work with if they want (less than 100)
3. permission for 1 intRAnet url only. The public do not and will never have access to it. 
4.  is used to automate that intRAnet site.  
5. uses a native host meaning users must install with admin rights (Windows registry changes needed) the extra Native Host code. 
6. the native host allows users to send javascript to the intRAnet page to automate it.
7. the extension uses the script tag injection method for the javascript
8. my extension does not source or connect to any other urls.
9. If a change is made to the intRAnet site I can update the native host almost instantly where as if the JS was in the extension on average it would take 7 days min.

I have survived all checks so far from Google Chrome in V2. I suppose it depends on who I get that manually looks at it on the time it takes. One general theme to the process is it takes a lot longer than I would expect.

I understand if an extension itself goes off and gets JS from some URL that this would be a problem as the user has limited control over this, however, where the user in a second step to jumping through all the installation and permission steps of the chrome extension, installs a native host (which at least for Windows requires admin rights for the UAC) this should be treated differently.

[hrg...@gmail.com]

On Monday, February 8, 2021 at 5:43:18 AM UTC-3 maild...@gmail.com wrote:

uses a native host meaning users must install with admin rights (Windows registry changes needed)

. . . .

installs a native host (which at least for Windows requires admin rights for the UAC) this should be treated differently.

 

The installation of a native messaging host DOES NOT require any special permissions. The necessary registry key can be inserted by any process without elevation under HKEY_CURRENT_USER.

[Darbid Darbid]

Yep agreed, a standard PC box can write to HKCU without UAC elevation and to be even clearer the native host.exe and its manifest can live anywhere in the file system which also does not need UAC. 

However my statement is that "My extension has/is......5. uses a native host meaning users must install with admin rights (Windows registry changes needed) the extra Native Host code." is true as the only people (ie. users of a PC) that have access to the native host installer need to have admin rights to write to the registry. Further you may be able to stumble upon my extension, it is unlisted, but you have absolutely zero chance of ever getting my native host. My extension is useless without the native host.

A more general statement which you may feel more comfortable with is that a person has to go to the extra step of initiating a process (does not have to install in the form of an MSI) to copy a native host and manifest as well as initiate changes to the HKCU registry and that an extension itself cannot do this.

[Charlie Ortiz]

We have a similar implementation in our extension working in MV2. Any news on if this is going to be allowed in V3?

[ilyaigpetrov]

We are also interested if we can use at least CSS-selectors retrieved from a remote server.

[ilyaigpetrov]

Simeon and the Google team, could you, please, clarify WebStore polices regarding remote css-selectors or similar remote configuration. This topic was created a year ago and is still relevant.