Frequently Asked Questions.

Learn More About Risks Identified by Privacy Edge

How are fingerprinters found?

Privacy Edge intercepts calls to commonly used browser functions that are typically used to generate unique fingerprints. Each method call by itself doesn’t constitute that a script is a fingerprinter. If a specific script calls enough methods in a single page load we can infer a weighting of the likelihood that the script is using the excessive data points to generate a fingerprint or obtain granular telemetry. This is an effective approach because many fingerprinting scripts don’t look alike and many are obfuscated and hard to read. Their behavior however is similar – they all have similar functions.

How are fingerprinters combated?

Given our research of inspecting several million webpages, we are able to determine the most commonly used browser functions called by fingerprinters. Privacy Edge intercepts calls to a handful of these methods and returns fake data. This fake data is then used by the 3rd-party script to generate a unique fingerprint. As the data isn’t legitimate, the fingerprint created isn’t a true identifier of the user visiting your web page.

If you are using a legitimate fingerprinting library as part of bot protection, that library can be trusted in Privacy Edge. Once trusted, it won’t be subject to combating.

How is malware discovered?

We inspect your site’s pages daily and run each 3rd party request through a recently updated malware filter list – In addition, we proactively run 3rd-party requests through the same filter in real-time as users are browsing your site. To improve on the signal matching we run questionable 3rd parties through AlphaMountain for additional signal detection. Lokker Intelligence can automatically place a domain into your “blocked” list if it is flagged as Malware by either AlphaMountain or through filter matching.

How are you matching a tracker?

We use 3 commonly used community-maintained privacy and tracking lists that are used by many third-party ad blockers and privacy-based web browser extensions. These lists allow LOKKER to match the third-party request as being a known tracker or not. The lists are updated daily.

What is session replay?

Session replay is a reconstructed presentation of how a user experiences a website or mobile application. It captures things like clicks, mouse movements, form inputs and page scrolls. Then it creates a walk-through style video that shows you what the user did while on your website or app. Think of it as a “session playback” or “user experience replay.”

Is all session replay bad?

Some session replay tools have privacy-related tooling that allows you to explicitly mask areas of the page that would typically contain or ask for PII. This instructs their session playback to not capture these PII elements in plain text or in view of the recording. If your session replay software isn’t configured with these privacy guidelines then you run the risk of propagating person identifiable information to your software provider.

How are you matching session replay?

We have constructed a LOKKER managed and owned filter list of commonly used session replay software. All 3rd-party requests on your site are passed through the filter matching component.

What is Bad SSL?

Some modern browsers are able to preemptively check the certificate validity of a web resource before deciding to make a request. Privacy Edge reports on any third parties with a certificate issue. The request could be initiated by a 3rd-party script that has a valid certificate, Privacy Edge reports on both the initiator and the target resource against which the bad SSL was found.

What PII do you store?

We do not store PII, rather we store the understanding of the likelihood that a match of PII was found. For example, we would know that potentially an SSN was found but we wouldn’t store the SSN. We can tell if the PII was found in a query parameter, post body, or a header.

Do you touch PII?

Privacy Edge intercepts all third-party requests that could contain PII. It does this by passing request parameters, post bodies, and headers to the Google DLP service. This relay happens server-side and Privacy Edge is only looking for the likelihood of a signal match. We do not store at rest any request parameters, post bodies, or query parameters. We also do not log such information. We act purely as a relay to a PII checking service.

💡 If requested, LOKKER can provide you with a web service code that can act as the relay to your Google DLP account. Once installed, you would tell us the publicly accessible URL and our Privacy Edge JavaScript library can relay checks to your endpoint.

How do you check for PII?

Privacy Edge intercepts requests initiated by changes to the DOM and compares the domain making the request against your Privacy category rules. If the rules signal a check is needed, then the request’s parameters, headers and any posted data is checked for PII. We utilize Google DLP to perform the check, which gives us an indication of the likelihood of matches against a predefined list or typical PII attributes. Privacy Edge intercepts AJAX and Fetch requests and is able to intercept and check PII on any requests initiated by DOM manipulation. This includes the inclusion of images, css, video, audio, links, forms, iframes, or embeds.

Are you accepting our Cookie Consent before recording the cookies set in the browser?

No – Privacy Edge does not click on any buttons and it doesn’t submit any forms when it records the cookies set when viewing a web page. The cookies we report on are added to the browser without accepting or configuring any options available in cookie consent notices.

Learn How Privacy Edge Identifies and Combats Threats

What is the Guardian?

The Guardian is a standard JavaScript library that enforces your Privacy rules in real time. It’s capable of checking for PII loss, Fingerprinting and matching of requests as being either Malware, Tracker or Session Replay. If your configuration stipulates certain domains should be blocked then Guardian will block any third party requests that match. Guardian can also combat fingerprinting by spoofing data that adversely affect the quality of any fingerprint.

Within Privacy Edge you can establish levels of trust. These trust models are then adhered to by Guardian.

What is best practice in terms of Guardian installation?

Guardian low level proxies browser methods so that it can intercept and combat bad privacy behavior. To obtain the best results, it needs to be loaded as early as possible in the head of your HTML documents. Before all other scripts.

Can we use the same JavaScript library included across all sites regardless of domain?

No. The underlying logic of the library remains the same regardless of site it is deployed on but there is site-specific rules that instruct its behavior. We bundle these two elements together into a single library and request. This is done to reduce the overall latency of loading Privacy Edge and ensure that we can be loaded into the browser as soon as possible. In each of your site’s global settings area, there is a code snippet that should be used on each respective site. The only variable in each is a unique id that references your specific site. That can be parameterized if you want to introduce Privacy Edge into your website’s CI/CD process.

Are you able to protect our customers on pages behind a login?

Yes – To enable real-time protection for website users you will need to install Privacy Edge’s JavaScript library into the header element of all HTML pages on your site.

What is Lokker Intelligence?

Lokker is continuously bringing market intelligence into our rules to automatically block known malware or malicious JavaScript. At present we can automatically block Malware, PII, and resources that are being served from known risky geographies. Lokker Intelligence takes a proactive approach and moves third parties into your “blocked” category. This means if we were to see one of those privacy risks in our automated inspections we would automatically flag those items as resources that should be blocked in real-time by the Privacy Edge JavaScript library. The only Privacy category not subject to Lokker Intelligence by default is the “Trusted” Category.

Privacy Edge Technical Details

What cloud hosting platform do you use?

Privacy Edge is primarily delivered using services provided by Google Cloud Platform.

Can we host your software in our cloud provider?

Not at the moment. We have developed our software using GCP as our cloud provider. In the product road map, there might come a time when we’re able to deploy our stack to your cloud provider of choice.

Can we host your software on-premise?

No not at the moment.

What failover and resilience is present?

Privacy Edge makes use of GCP and Cloudflare to provide scalable and resilient services. The only component that affects end users of your website is the delivery of Privacy Edge’s JavaScript library. This script is distributed to your sites through a highly available Geographical Cloudflare cache. The cache will continue to serve the JavaScript and rules regardless of the uptime state of the rest of our stack. This means your customers will always be protected

What latency can we expect from using your software on our site?

The only latency that affects end users is that of the operational functions of the Privacy Edge JavaScript library. We host the library on the edge through Cloudflare workers. This typically loads within 200 ms if not already present in the user’s browser cache. Once present in the user’s browser cache the JavaScript.

How long do you store our privacy reports?

We present the last 31 days of reports to you through Privacy Edge. We however store the prior reports for 1 year.

What telemetry do you capture?

Privacy Edge’s JavaScript library does record telemetry so that we can alert you of any privacy risks identified, combated, or blocked.

The common telemetry elements are:

  • What was the Privacy Event – [ Malware, Tracker, Fingerprinter, PII Discovered]
  • What URL triggered the Privacy Event
  • Which script was the initiator
  • The call stack of script URLs that lead to the final triggering event
  • If applicable, the DOM Element used to initiate the request
    • img, form, button, style, etc.