Chrome Extension: Rethink Domain Matching for Default-Enabled Sites

[k4sperski]

I ran into a friction point while testing the Chrome extension that suggests the current domain enablement logic might be impacting user adoption.

The Scenario

I was testing Harper's behavior on complex, third-party forms (specifically on emnify.com) where the form is embedded in an iframe from job-boards.eu.greenhouse.io. The content script identified the textarea, but enabledForDomain() returned false because that specific hostname isn't in the default list.

The Impact

Users who would benefit most from Harper: those drafting cover letters, application forms, or support tickets. Such users are the least likely to realise they need to manually enable it. When the UI doesn't appear, they assume the extension is broken. They won't inspect iframe hostnames or dig through settings; they just stop using the tool.

The current list of ~48 hardcoded domains misses significant block of where people actually write. Some examples:

• Job boards: Greenhouse, Lever, Workday
• Customer support widgets: Zendesk, Intercom
• Internal CMS platforms and school portals

Technical Patterns

Existing exact hostname matching creates three main issues:

Subdomain Fragility: Sites like Greenhouse serve content from various subdomains. If an iframe hits an unlisted subdomain, the experience breaks.

Redundant Maintenance: Domain list currently references Reddit three times and Google four times (mail, docs, messages, classroom). Each new subdomain requires a code change and release.

Silent Failure: The content script runs and attaches listeners, but the background worker logic in packages/chrome-plugin/src/background/index.ts returns {}. There is no visual feedback (like a greyed-out icon or a "click to enable" prompt) to explain why Harper is inactive.

Proposed Approaches

1. Suffix Matching: Match against base domains (e.g., greenhouse.io, google.com) instead of exact hostnames. This collapses the list and covers future subdomains automatically.

2. Default to Enabled: The enabledByDefault infrastructure exists but is set to false. Flipping this to true and allowing per-domain opt-out (the Grammarly model) would eliminate the need for a list entirely. I can see the privacy argument for opt-in, but I think opt-out is what users expect from tools like this. Every site where Harper stays silent is a missed opportunity to demonstrate its value!

3. Hybrid Model: Move to "Default Enabled" with a deny-list for problematic domains rather than a restrictive allow-list.

4. Improved Feedback: Regardless of the matching logic, we should surface the state to the user. A subtle UI hint or a change in the toolbar icon would remove the guesswork.

I'm happy to put together a PR for whichever of these directions the team feels is most aligned with the project's goals.

---

I'd love to hear the team's thoughts on this, particularly if there's specific history behind the current opt-in approach that I should consider.

[k4sperski]

Reflecting further on the Greenhouse/Emnify example, there’s a middle-ground approach that might be more surgical than a global opt-out: parent-origin inheritance.

If a user (or the default config) has already trusted a top-level domain like emnify.com, it stands to reason they want Harper’s assistance with the content of that page, regardless of whether that content is served via a third-party iframe like greenhouse.io.

I dug into the source and the good news is the plumbing is almost entirely in place already. The manifest sets all_frames: true, so the content script does inject into third-party iframes. The problem is purely the domain check. Inside the iframe, LintFramework.ts sends window.location.hostname (which resolves to the iframe’s origin, e.g. job-boards.eu.greenhouse.io), and handleLint in background/index.ts calls enabledForDomain() against that hostname. Since it’s not in the list, we get back empty lints.

The fix is small: the onMessage listener on line 65 already receives a sender object with sender.tab.url (the top-level tab’s URL), and the extension already holds the tabs permission needed to read it. Currently sender is discarded (_sender). The change would be:

1. Pass sender through to handleLint.
2. If enabledForDomain(req.domain) returns false, extract the top-level hostname from sender.tab?.url and check that instead.
3. If the parent origin is enabled, inherit the state and proceed.

No changes needed to the content script or LintFramework, since window.location.hostname is still correct for cache keying.

This gives us granular privacy: Harper doesn’t need to be enabled for the entire internet. It only wakes up on unlisted third-party domains when they’re embedded within a trusted context. It also solves the “widget problem” more broadly: embedded support widgets (Zendesk, Intercom) and job boards (Lever, Greenhouse) would just work without needing to anticipate every possible subdomain.

Worth noting: this is a privilege extension for a writing-assistance tool, not a security boundary, so parent-to-iframe trust inheritance doesn’t carry the same risk profile it would for, say, cookie or script access.

One wrinkle: the popup UI (Main.svelte) only shows the top-level domain via chrome.tabs.query, so it would continue to display “Harper is enabled on emnify.com” without surfacing that iframes are inheriting that state. That seems fine as a default, but worth flagging.

Happy to put together a PR for this if the team is interested. It’s a fairly contained change.

[ssvb]

If I understand it correctly, that's not a privacy issue but a compatibility issue. Harper doesn't send your typed text to some remote server on the internet, but checks it locally on your computer.

But unfortunately not every website is fully compatible with Harper and there may be various glitches on unsupported sites. That's a whack-a-mole game. Under the hood the website content is modified by the plugin to add Harper's highlighting and the plugin must do this with a surgical accuracy for every type of content.

LanguageTool made their browser plugin closed source for a reason. Correctly supporting a wide range of distinct websites may be seen as a valuable know-how and a competitive advantage of their product. Harper is younger and is still catching up.

[k4sperski]

@ssvb I agree! Manual curation can quickly become a whack-a-mole, which is why inheritance feels like the right next step.

Instead of adding embedded hosts one by one, Harper can reuse the trust decision the user has already made for the top-level page. If Harper is enabled on domain like emnify.com, an unset embedded iframe on that page can inherit that state.

That fixes the silent failure case for embedded forms without changing Harper’s broader exact host matching approach:

• inheritance only applies when the iframe host is unset
• explicit iframe overrides still take precedence

I’ve put that into a PR here: #3010