Is BlockSite Block Websites & Stay Focused safe?
Block Site is medium risk. BlockSite injects a script into every http(s) page's JS context before page scripts run. It overwrites fetch and XHR.send to capture every response, even with no blocking rule. Captured URLs/bodies are checked against a remote rule list.…
Who publishes itBlockSite LP - no other listings under this identity, 1 shared hostname
BlockSite LP - no other listings under this identity, 1 shared hostname
What this publisher told the store about itself, and the other listings that told it the same thing.
Shared hosts - 1 hostname
Hostnames hardcoded in this extension that few other listings call. That can mean one operator behind both, and it can equally mean a small shared vendor, so it is context rather than a conclusion. Hosts that many listings call are left out: they are services, not connections.
AI-generated. Findings may contain errors. Those marked Verified have been manually reviewed.
Publishers can request a review.
Findings
BlockSite Reads the Full Response Body of Every Network Request
BlockSite injects a script into every http(s) page's JS context before page scripts run.
It overwrites fetch and XHR.send to capture every response, even with no blocking rule.
Captured URLs/bodies are checked against a remote rule list.
You open any website while BlockSite is installed.
BlockSite injects a script into the page's own JS context that overrides fetch and XHR.send to read the full body of every response the page receives.
This runs on every http(s) page, whether or not BlockSite has a blocking rule configured for that specific site.
The XHR interceptor that reads and broadcasts every response body
// Installed by overwriting XMLHttpRequest.prototype.send, once per request instance.
// Runs inside the PAGE's own JavaScript context (injected via a <script> tag),
// not the extension's isolated content-script world.
function patchedSend() {
this.addEventListener('load', function () {
let responseBody = null;
try {
responseBody = this.responseText; // the full response body, read unconditionally
} catch (e) {}
// Broadcast the captured body + request URL as a page-level DOM event
const captureEvent = new CustomEvent('active-content-block', {
detail: { way: 'xhr', event: responseBody, url: this.__requestUrl }
});
self.dispatchEvent(captureEvent);
});
originalSend.apply(this, arguments);
// A 1-second no-op timeout follows in the shipped build; it has no
// observable effect on the capture itself.
}{
"sid": "a6cf643b7"
}| Field | Value | Why it matters | |
|---|---|---|---|
Full response body text | (illustrative) {"account":{"email":"jane@example.com","plan":"pro"}} | The complete text of every response an XHR or fetch call on the page receives, API responses, account data, or anything else the site loads. | |
Request and page URL | https://mail.example.com/api/v3/inbox?page=1 | The exact address of the page you're on and the specific API endpoint being called. | |
Obfuscated rule list | chrome.storage.local key 'cDXLl' (encoded) | A remotely-updatable list of URL and content patterns BlockSite uses to decide what to do with a captured response. | |
Rule refresh interval | 21600000 ms (6 hours) | How often BlockSite checks BlockSite's own server for an updated rule list. |
We confirmed the XHR response-body capture is unconditional — it fires on a page with no matching BlockSite rule — by dispatching a plain request on such a page and observing the capture event with the full response body. The fetch-response capture path only activates once a rule's URL pattern matches the page. The rule source is BlockSite's own backend, and the rule engine we read also handles video-ad-detection ('VAST') rule types, so this mechanism can plausibly power a legitimate content-filtering feature rather than exist solely to collect page data. What we flag is the scope and design: full-body network interception across every website, remotely retargetable by BlockSite at any time, with the on-disk configuration deliberately obscured from casual inspection. We did not trace whether a matched capture is ever transmitted off the device beyond the internal chrome.runtime.sendMessage call to BlockSite's own service worker.
Listens for BlockSite's internal capture event and issues a normal same-origin fetch to show the interceptor runs even on a page with no matching BlockSite rule.
// blocksite-response-capture-check.js
// Run in the DevTools console of ANY http(s) page while BlockSite is installed,
// including a page with no BlockSite blocking rule for it.
self.addEventListener('active-content-block', (e) => {
console.log('[BLOCKSITE-INTERCEPT] captured response:', e.detail);
});
// Trigger any request the page would normally make. A same-origin fetch works.
fetch(location.origin + '/', { method: 'GET' }).catch(() => {});
- 1Install BlockSite, open any http(s) page (no rule needed).
- 2Open DevTools, Console.
- 3Paste and run this script.
- 4Reload or trigger a request.
- 5The response body/URL log, confirming BlockSite read it.
BlockSite Collects All Open Tab URLs on Install
The moment BlockSite finishes installing, it reads every open tab's URL and sends them to statistics.blocksite.co, no prompt.
The request fires from the install handler, no interaction.
Only HTTP/HTTPS URLs, but any open page is captured.
You install BlockSite from the Chrome Web Store.
The extension immediately reads all open tab URLs in your current window and POSTs them to statistics.blocksite.co.
No user interaction is needed beyond installation. The collection happens before you have opened BlockSite's settings or accepted any prompt.
| Content-Type | application/json |
{
"urls": [
"https://www.google.com/account/about/?hl=en-US",
"https://www.facebook.com/"
],
"platform": "extension",
"timestamp": 1780652280218,
"eventType": "install"
}| Field | Value | Why it matters | |
|---|---|---|---|
All open tab URLs | https://www.google.com/account/about/?hl=en-US | Every HTTP or HTTPS page you have open in your current window at the moment of installation. | |
Platform identifier | extension | Hardcoded string identifying this as the browser extension client. | |
Install timestamp | 1780652280218 | Millisecond-precision timestamp of when installation occurred. | |
Event type | install | Hardcoded label classifying this as an install-time event. |
The install handler that collects and transmits tab URLs
// Fires from chrome.runtime.onInstalled handler
async function sendInstallEvent() {
// One-shot guard: skip if already sent
const alreadyFired = await storage.get(STORAGE_KEYS.IS_INSTALL_EVENT_FIRED);
if (alreadyFired) return;
try {
chrome.tabs.query({ currentWindow: true }, (tabs) => {
// Collect all HTTP/HTTPS tab URLs
const urls = tabs
.map(tab => tab.url)
.filter(url => url.indexOf('http') === 0);
if (urls.length) {
fetch(STATISTICS_SERVICE + '/event/createOnInstallEvent', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
urls,
platform: 'extension',
timestamp: Date.now(),
eventType: 'install'
})
// No Authorization header
});
}
});
} catch (e) {
logger.error('failed to send install event', e);
}
// Mark as sent so it never fires again
await storage.set(STORAGE_KEYS.IS_INSTALL_EVENT_FIRED, true);
}- statistics.blocksite.co
BlockSite's own analytics backend. Receives the install-time tab URL payload with no authentication. Owned and operated by BlockSite (Artium Technologies Ltd.).