Policy question: enterprise-internal extension integrating with a fixed HTTP-only intranet system

[Larry Liao]

I maintain an enterprise-internal Chrome extension that assists employees with expense allocation in an existing, authenticated company OA system. I have not submitted it yet; I would like to understand policy applicability before submitting.

Constraint: the OA system only provides HTTP access on a fixed intranet host. Changing its server configuration or adding an HTTPS front end is not possible for this project.

What the extension does:
- Reads and updates fields on the currently open reimbursement form
- Splits an expense group into one detail row per linked invoice
- Preserves shared expense fields and user edits, and checks amounts
- It does not save, submit or approve a workflow on the user's behalf

Technical posture (all verifiable in the manifest/package):
- No manifest permissions at all: no "permissions", no "host_permissions"
- No chrome.* APIs used
- No remote code, no telemetry, no advertising, no developer-operated endpoint
- Content scripts scoped to exactly two origins:
  1) the intranet OA host
  2) an HTTPS invoice-folder service, where a script reads only the currently visible selected invoice rows and posts them back to the allowlisted parent frame via postMessage (one-time nonce handshake)
- A privacy policy and in-product disclosure are planned

The extension is not entirely network-free: it makes same-origin XMLHttpRequest calls to the existing OA server to retrieve field options (brands, stores). Those requests include workflow/field parameters, an optional search term, and a user identifier when the page supplies one; browser-managed session credentials may accompany them. Under the current OA origin they are HTTP.

Questions:
1. Does the "secure handling of user data" requirement make such an item ineligible for store distribution, or can it be satisfied via disclosure plus a privacy policy?
2. If the current design is unacceptable: would removing the extension's own HTTP option requests and instead using the OA page's native selection controls address that specific concern - or would the underlying HTTP-only OA integration still block approval?

I am seeking clarification, not an exemption or prior approval. I can provide more technical detail or a restricted demonstration without exposing employee credentials or real financial records. Thank you.

[Oliver Dunk]

Hi Larry,

Thanks for the question. I don't think our policy explicitly carves out this situation, but I suspect it is fine.

As you mention, we can't provide prior approval and ultimately the determination will be made by the review team. This seems like a reasonable use case to me though and I would expect your item to be approved. I would encourage you to set the visibility appropriately (e.g published to domain or trusted testers) as this provides more context to the team about the target audience for your item.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
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/99d4517e-cf00-4245-ae84-a0b45922ff3dn%40chromium.org.

[Larry Liao]

Hi Oliver,

Thank you - this is genuinely helpful, and I appreciate you taking the time.

The steer on visibility is especially useful. We do not have a Google Workspace domain, so "published to domain" is not available to us; we will use "trusted testers" instead, restricted to the employees who actually need the tool. That also matches how we would describe the target audience in the listing.

Understood that this is not prior approval and that the review team makes the final determination - we will proceed on that basis and make sure the listing and the privacy policy describe the data handling accurately, including the HTTP situation, rather than leaving anything implied.

Thanks again for the clear guidance.

Best regards,
Larry

Oliver Dunk <olive...@google.com> 于2026年9月28日周一 17:12写道：