We are in the process of rolling out Wordtune as a sanctioned writing aid for our technical documentation and internal communications teams. However, our initial pilot has been plagued by reliability issues specifically when users are connected to our corporate VPN, which is mandatory for accessing internal applications. The symptom is consistent: the Wordtune extension icon grays out and becomes unresponsive within web applications like our internally hosted Confluence, Google Workspace (via our SSO gateway), and even in Microsoft Word Online. It functions normally on standard public internet sites.
Our security posture is fairly standard for a mid-sized tech company. We use a split-tunnel VPN (Zscaler ZPA), where only traffic destined for our internal CIDR blocks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is routed through the tunnel; all other traffic egresses directly from the user's endpoint. We also have a next-generation firewall with TLS inspection enabled for outbound traffic, and we enforce a strict allowlist for external APIs via our proxy PAC file.
I have conducted a preliminary analysis and isolated the failure points:
* **Extension Context:** The browser extension appears to fail its initial handshake or license check when the page's origin is an internal domain (e.g., `wiki.internal.company.com`). Using the browser's developer tools, I see WebSocket connection timeouts to `*.wordtune.com` domains, resulting in a 502 error.
* **API Endpoints:** A packet capture (with non-sensitive data) indicates that requests to ` https://api.wordtune.com/api/v1/status` are being blocked, not at the firewall level (no RST packet), but timing out after the TCP handshake. This suggests an issue at the proxy or application layer.
* **PAC File Bypass:** Manually configuring the browser to bypass the proxy for `*.wordtune.com` addresses resolves the issue entirely, but this is not a scalable solution.
My hypothesis is that this is a combination of:
1. The VPN/proxy's TLS inspection breaking the certificate chain or modifying headers in a way the Wordtune API rejects.
2. The extension's content scripts running in an "internal" page context being subject to stricter CSP (Content Security Policy) headers from our internal apps, which may block the required `connect-src` to external APIs.
Has anyone successfully deployed Wordtune in a similarly locked-down enterprise environment? I am particularly interested in:
* The exact API endpoints and domains that must be allowlisted at the proxy/firewall for core functionality (writing suggestions, paraphrasing, summarization). Are CDN domains static or dynamic?
* Any required CSP directives that must be added to internal application headers to permit the extension to function.
* Whether the desktop application version suffers from the same VPN-related connectivity issues, or if it uses a different network path.
A structured configuration snippet of a successful allowlist rule or CSP header would be immensely valuable for our network security team to review. For example:
```json
// Hypothetical PAC file rule
if (shExpMatch(host, "*.wordtune.com") ||
shExpMatch(host, "*.ai21.com")) {
return "DIRECT";
}
```
Our goal is to establish a reliable, supported configuration without compromising our security controls.
Data over dogma
So your security posture is "fairly standard" but you've got TLS inspection and a proxy allowlist for external APIs. That's your culprit right there, not the VPN routing.
Wordtune's extension needs to phone home to its own API endpoints. If your proxy is blocking or intercepting those calls, it'll just die silently. Check your logs for connection attempts to anything from wordtune.com or ai21.com, then watch them get dropped.
Funny how these "sanctioned" tools never work with the security stack that's also "sanctioned."
Prove it
Exactly. The "sanctioned" tool's vendors will cheerfully take your money and then point the finger at your "sanctioned" security team when it breaks. They never seem to have a deployable agent or a proper list of required endpoints that works with inspection.
I'd bet a coffee the magic "allowlist" solution will involve opening up half the vendor's AWS frontend, not just a clean API domain. Good luck getting that past your infosec folks.
—EB
The split-tunnel configuration you described is critical information. Because traffic to public endpoints like Wordtune's APIs is *not* routed through your VPN tunnel, the failure must occur after that egress point.
Your preliminary analysis about the extension context is correct. The service worker, which handles background API calls, likely fails because its requests are being intercepted or blocked by your outbound firewall/TLS inspection. The key is to trace the exact call chain. The browser extension's service worker will make requests to domains that may not be obvious from the extension's manifest, such as CDN endpoints or third-party analytics services that the vendor's JavaScript bundle dynamically calls.
I'd suggest using the browser's developer tools on an affected machine, specifically the Network tab in the background page context for the extension. You need to capture the failing requests and their response codes. A 403 or a certificate error would confirm it's a proxy/SSL inspection issue, while a timeout might indicate DNS resolution problems within your corporate environment.
You're right that the network tab is the first place to look, but focusing solely on the service worker might be incomplete. The extension's content scripts running on the internal app's page could be making direct fetch calls that also get blocked. The CSP headers on your internal Confluence or SSO gateway could be rejecting the connection before it even leaves the browser.
I'd also check for WebSocket connections in those network traces. Some of these AI writing tools use persistent sockets for real-time suggestions, and those can be silently dropped by some proxy configurations even if HTTP POST requests appear to succeed.
sub-100ms or bust
Yeah, the split-tunnel detail is crucial. Since public traffic isn't routed through your VPN, the issue is almost certainly happening at the outbound firewall with TLS inspection.
You mentioned a proxy PAC file for an API allowlist. That's the next step. Can you share what domains you've already tried adding? The usual suspects are `*.wordtune.com` and `*.ai21.com`, but I've seen some of these tools also call out to `*.segment.io` or `*.intercom.io` for analytics. If those secondary calls get blocked, the whole extension can hang.
Also, could the PAC file be applying different rules based on the source URL? If your internal Confluence is on `wiki.internal.corp`, traffic originating from there might hit a stricter proxy profile than traffic from `docs.google.com`.
Data is the new oil - but it's usually crude.
You've diagnosed it correctly. The fact it works on public sites but fails inside your internal web apps points directly to the security wrappers around those apps, not the general egress path.
> I have conducted a preliminary analysis and isolated the failure points
Good. Now test your hypothesis about the service worker with a browser's network tab, but filter for websocket connections and fetch/XHR requests to ` https://cws.ai21.com`. That's their primary inference endpoint and if your proxy's TLS inspection is using an internal CA that's not trusted by the extension's service worker context, the connection will be refused. You'll see a net::ERR_CERT_AUTHORITY_INVALID.
The CSP headers on your Confluence instance are the other likely killer. If they block `connect-src` to external domains, the extension's content script can't even try to call home. You need to see the browser console for those errors, not just the network tab.
Your infosec team will hate this, but the fix is a targeted proxy bypass rule for the extension's specific API domains, not a wildcard allowlist. Push back on the vendor for a complete, static list of FQDNs, not AWS wildcards. If they can't provide that, they haven't done their homework for enterprise deployment.
Good point about the CSP headers! I was only looking at the network tab, but the console does show a bunch of `connect-src` violations for our Confluence instance.
> the fix is a targeted proxy bypass rule for the extension's specific API domains, not a wildcard allowlist
This sounds right, but how do you even find *all* the domains? I tried filtering for `ai21.com` and `wordtune.com` but there were still some blocked calls to a `*.cloudfront.net` address. Is it just a matter of whitelisting every domain that shows up as blocked in the console, or is there a smarter way? 😅
Our security team will ask for a definitive list before they'll make any changes.
Containers are magic, but I want to know how the magic works.