Content blocker detection and content obfuscation system
Abstract
Systems, tools and methods for obfuscating content requested by users. The system receives requests for content from a browser running on a client device. The system may be configured to determine if content blocking software and/or functionality is running/enabled on the user's browser. When content blocking has been detected, the system may execute one or more obfuscation processes on the requested content. The obfuscation processes may be configured to replace, modify and/or encrypt one or more content elements, including advertisements, within the requested content. The obfuscated content may then be sent to the client device to be rendered in the browser. The obfuscating of the content allows the advertisements to be rendered/displayed to the user in the browser without triggering the content blocker.
Claims
exact text as granted — not AI-modifiedWhat is claimed is:
1 . A content obfuscation system, wherein the system comprises:
an obfuscation server, wherein the obfuscation server comprises:
a memory;
one or more processors;
one or more network devices; and
one or more datastores; and
wherein the obfuscation server is configured to detect a content blocker operating on a browser, wherein the detection comprises:
receiving, from the browser, a first request for a webpage;
determining, based on the first request, a unique ID for the browser;
generating, in the datastore, a blocker status record for the unique ID, wherein the blocker status record comprises a content blocker state;
retrieving, from a webserver, an original webpage corresponding to the first request;
generating a modified webpage by appending a canary path to the original webpage;
returning, to the browser, the modified webpage;
receiving, a next request from the browser;
determining, for the next request, a request type; and
determining, based on the request type, the content blocker state for the browser.
2 . The system of claim 1 , wherein the request type of the next request is a canary path request and the content blocker state is determined to be false based on the next request being a canary path request.
3 . The system of claim 1 , wherein the request type of the next request is not a canary path request and the content blocker state is determined to be true based on the next request not being a canary path request.
4 . The system of claim 1 , wherein the obfuscation server is further configured to:
receive, from the browser, a current request; retrieve, from the datastore, a current blocker status record for the browser, wherein the retrieving comprises using the unique ID of the browser to query the datastore; generating, based on the current request, a current request type and the blocker content state of the current blocker status record, an obfuscated webpage, wherein the generating comprises performing one or more obfuscation processes; and return, to the browser, the obfuscated webpage.
5 . The system of claim 4 , wherein the one or more obfuscation processes comprise:
replacing one or more content elements with server side rendered elements; or modifying the one or more content elements by encrypting the elements or a path of the element.
6 . The system of claim 5 , wherein determining the current request type further comprises a content evasion instruction (CEI) determination, and wherein the CEI determination comprises:
checking if a request path of the current request is a valid hexadecimal string; decoding an encrypted payload; and matching the decoded payload with JSON representation of a CEI instruction set.
7 . The system of claim 6 , wherein the unique ID of the browser is based on JA3 and/or JA4 fingerprinting of a TLS handshake.
8 . A content obfuscation system, wherein the system comprises:
an obfuscation server, wherein the obfuscation server comprises;
one or more processors;
a memory;
a datastore, wherein the datastore comprises one or more blocker status records, wherein each blocker status record comprises a content blocker state, and wherein each blocker status record corresponds to a unique ID of a browser;
a content obfuscator module, wherein the content obfuscator module is configured to:
update, in the datastore, the one or more blocker status records based on one or more received requests, wherein the updating comprises:
identifying, for each of the one or more received requests, a current unique ID;
determining, for each of the one or more requests, a current request type; and
setting, for each of the one or more requests, a current blocker state in a current blocker status record corresponding to the current unique ID based on the determined current request type and a previous blocker state of the current blocker status record; and
receive, by a fetch handling module, a first request for a first webpage from a browser operating on a client device;
retrieve, from a webserver, a first original webpage corresponding to the first request for the first webpage;
determine, based on the received first request, a first unique ID;
generate, in the datastore, a blocker status record for the first unique ID;
modify, by append a canary object, the first original webpage;
return, to the browser, the modified first original webpage;
receive, by the fetch handling module, a second request, wherein the second request is a request for a webpage;
retrieve, from the webserver, a second original webpage corresponding to the second request;
retrieve, from the datastore, a first content blocker state of the blocker status record corresponding to the first unique ID;
generate, based on the first content blocker state, a modified second original webpage, wherein the generating comprises performing one or more obfuscation processes; and
return, to the browser, the modified second original webpage.
9 . The system of claim 8 , wherein the one or more obfuscation processes comprise:
replacing one or more content elements with server side rendered elements; or modifying the one or more content elements by encrypting the elements or a path of the element.
10 . The system of claim 9 , wherein the fetch handling module is further configured to classify each request from the browser into one or more types of requests.
11 . The system of claim 10 , wherein the one or more types of requests comprise:
a canary path request, wherein the canary path request corresponds to an appended canary object; a static resource request; and a content evasion instruction (CEI), wherein the CEI is encrypted.
12 . The system of claim 11 , wherein the classifying comprises an CEI instruction request determination, and wherein the CEI instruction request determination comprises:
checking if a request path is a valid hexadecimal string; decoding an encrypted payload; and matching the decoded payload with JSON representation of an CEI instruction set.
13 . The system of claim 12 , wherein the system further comprises a canary module configured to:
receive, from the fetch handling module, a first canary path request; and update a blocker status record corresponding to a unique ID associated with the first canary path request based on a current content blocker state of the blocker status record.
14 . The system of claim 13 , wherein the unique ID of the browser is based on JA3 and/or JA4 fingerprinting of a TLS handshake.
15 . A content obfuscation method, wherein the method is configured to:
detect, at an obfuscation server, a content blocker operating on a browser of a client device, wherein the detection comprises:
receiving, from the browser, a first request for a webpage;
determining, based on the first request, a unique ID for the browser, wherein the unique ID of the browser is based on JA3 and/or JA4 fingerprinting of a TLS handshake;
generating, in the datastore, a blocker status record for the unique ID, wherein the blocker status record comprises a content blocker state;
retrieving, from a webserver, an original webpage corresponding to the first request;
generating a modified webpage by appending a canary path to the original webpage;
returning, to the browser, the modified webpage;
receiving, a next request from the browser;
determining, for the next request, a request type; and
determining, based on the request type, the content blocker state for the browser.
16 . The method of claim 15 , wherein the request type of the next request is a canary path request and the content blocker state is determined to be false based on the next request being a canary path request.
17 . The method of claim 15 , wherein the request type of the next request is not a canary path request and the content blocker state is determined to be true based on the next request not being a canary path request.
18 . The method of claim 15 , wherein the obfuscation server is further configured to:
receive, from the browser, a current request; retrieve, from the datastore, a current blocker status record for the browser, wherein the retrieving comprises using the unique ID of the browser to query the datastore; generating, based on the current request, a current request type and the blocker content state of the current blocker status record, an obfuscated webpage, wherein the generating comprises performing one or more obfuscation processes; and return, to the browser, the obfuscated webpage.
19 . The method of claim 18 , wherein the one or more obfuscation processes comprise:
replacing one or more content elements with server side rendered elements; or modifying the one or more content elements by encrypting the elements or a path of the element.
20 . The method of claim 19 , wherein determining the current request type further comprises a content evasion instruction (CEI) determination, and wherein the CEI determination comprises:
checking if a request path of the current request is a valid hexadecimal string; decoding an encrypted payload; and matching the decoded payload with JSON representation of a CEI instruction set.Join the waitlist — get patent alerts
Track US2026023806A1 — get alerts on status changes and closely related new filings.
We store only your email — no account needed. See our privacy policy.