MV3 remote code: read-only SQL from our own hosted UI to the extension's bundled SQLite?

[Nico]

Hi everyone,

Chrome Web Store support pointed us here, as they can't pre-approve designs. Is the following within the MV3 remote code requirements?

Our extension keeps all user data local in a bundled SQLite (WebAssembly) database, running in a worker of the offscreen document and stored in OPFS. We want to serve the UI from our own website, which embeds an extension page (web_accessible_resources, our origin only) as an iframe and talks to it over a MessagePort. All chrome.* APIs, the database and all requests to the third-party service our users work with stay in the extension. Data is only rendered in the browser, never sent to our servers.

To show grids and charts over millions of rows, the page would send read-only SQL (SELECTs with joins, CTEs, aggregates) and the extension returns the rows. Read-only is enforced in the extension: one statement per request, an SQLite authorizer that only allows reads (no writes, ATTACH, PRAGMA writes, temp tables or transactions), sqlite3_stmt_readonly() as a second check, and only our origin can send requests. All writes and every action in the user's third-party account go only through fixed, named operations bundled in the extension.

1. Is this acceptable, or does the bundled SQLite engine count as "an interpreter to run complex commands fetched from a remote source", even though the statements can't change data or trigger actions?
2. If not, would a structured query description (columns, filters, sort) that bundled code validates against allowlists and turns into SQL be fine?

Thanks!

[Patrick Kettner]

Hi Nico,

To be clear, no one can preaprove a design. At least in any way that matters. It doesnt matter what anyone says, reviewers will review the code you submit. That being said, I am happy to share my thoughts on the implementation and their likely outcome.

1. No, I do not believe we would find what you describe to be acceptable. The issue isnt that SQLite is bundled, but that a remote origin is sending the extension arbitrary statements to execute

2. Probably fine. If the page sends a structured description (columns, filters, sort, paging) and bundled code validates every piece against an allowlist before building the SQL itself, then the remote side is only supplying parameters and all of the logic ships in the extension.

Patrick

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1d749d85-2a98-4a40-a17e-8e5c0268bc82n%40chromium.org.

[Nico]

Thanks, Patrick.

I understand nobody can pre-approve a design without the full review. The rebuild is a lot of work, so we'd like to rule out architectures that are clearly not allowed before we start.

As you said, bundled SQLite isn't the issue; it has been approved in our extension for a long time. Today our UI (the main HTML page) lives inside the extension and queries that database directly.

We would move only that UI to our own website. It still needs to read the database that lives inside the extension, so the extension would offer a read-only endpoint: our website would send SQL queries, the extension runs them against that database and returns the results. Read-only is enforced by SQLite itself, which rejects any statement that is not a read. The endpoint is reachable only from our own domain.

You described the issue as a remote origin sending arbitrary statements to execute. Does that also apply to read-only queries that can only return data?

[Patrick Kettner]

> You described the issue as a remote origin sending arbitrary statements to execute. Does that also apply to read-only queries that can only return data?

Yes. we can't guarentee that it will only ever get read only queries, or that read only queries don't impact the extension's behavior.