JavaScript Restrictor
Browser extension that improves privacy and security
How JavaScript restrictor prevents other parties from sniffing on your local applications?

We recently found a blog post about ThreatMetrix Inc. (a part of LexisNexis) scanning locally open ports for about 30,000 web sites, including eBay. See the figure below that shows that a browser tries to connect to ports that are commonly used for remote access to the computer (e.g. RDesktop, VNC, TeamViewer), and other applications.

A screenshot of the browser beeing used as a proxy to scan locally open ports

The obvious question is what is the reason for such a behaviour? The simple answer is security. See additional links to Security Boulevard, Avast, and The register.

One possibility is that ThreatMetrix creates a fingerprint and locally running applications are a part of the fingerprint. Consequently, the authentication algorithm stores attributes about your device(s) and compare them during each log in with the previous values. Seeing that you are logging in using a previously seen device, the algorithm can let you in with just a password without additional proves. Should you use a new device, the algorithm might decide that additional steps for authentication are required and for example send you an SMS.

Another option is that ThreatMetrix knows that a lot of fraudulent activities are taking place on devices having a specific ports open. Recall that the ports being checked concern remote desktop access. Having a remote desktop port open means that it is possible that the computer is a proxy for an adversary that does not sit near the computer but is connected remotely. Consequently, the authentication algorithm might decide that additional proves about the users identity should be checked.

We do not know what is the real reason for ThreatMetrix. It might be one of the above, both, or a similar reason.

Ethical and legal issues

Although it could be that the underlaying intentions are benign and users actually do benefit from the scanning, it raises some ethical issues.

Very often security and privacy are interconnected. But sometimes one might increase security by revealing something private. In this case ThreatMetrix learns informations about the running device that is not obvious to the device owner (a user or a company). Typically, the owner of the device does not even know that such information can leak. If the information stays with ThreatMetrix, then the benefits could appear to be greater than the disadvantages. However, adversaries could stole information from ThreatMetrix (see for example the Ecquifax breach) or the company can start to sell the information or even share with others.

So is the scanning and data collecting legal? As we are based in EU, we will dig into the EU perspective, you might want to consult your local laws if you are outside EU. Moreover as we are not lawyers you might want to consult one even in the EU.

EU ePrivacy Directive applies. However, as WP29 clarified (use case 7.5) user-centric security can be viewed as strictly necessary to provide the service. So it seems likely that port scanning for security reasons would trigger the ePrivacy exception and user consent is not necessary.

As the port scanning is a part of the log in mechanism. Date about open ports are personal data without doubts. So GDPR also applies. GDPR also list security as a possible legitimate interest of a data controller (e.g. eBay), see recital 49. Nevertheless, if such a scan is proportionate is an open question; it is possible that the legitimate interests of data controllers (such as eBay) are overriden by the interests or fundamental rights and freedoms of the data subject (you), see Article(6)(1)(f).

The Court of Justice of EU (CJEU) decided sevaral issues that concerned data minimisation, e.g. C-13/16, point 30 or C-708/18 points 40–45. It might be possible that it is strictly necessary for eBay to perform local port scanning.

Nevertheless, Article 12-14 of GDPR lists requirements on information that a data controller should reveal to each data subject before the data processing stars or in a reasonable time afterwards. Hence, each controller employing ThreatMetrix should reveal, for example in the privacy policy, what categories of data it is using and for which purposes. From the linked articles, it seems that ThreatMetrix and eBay are secretive about data being collected.

Another GDPR issue might be data transfers to third countries. It is possible that data transfers of open ports are not compatible with GDPR in the light of the CJEU C-311/18 decision if the information leaves EEA.

Why is not my browser protecting me from remote servers accessing local information?

OK, so even though the scanning could be legal, one can disagree that others should be allowed to sniff on local applications. Why does a browser leak the information?

Well the browser employs so called same origin policy (SOP) that in abstract theory should prevent web sites from the scans in question. As your local computer is a different origin to the remote web site, your computer should be shielded. Nevertheless, SOP has its limitations. First of all some cross-origin resource sharing is beneficial so the browser cannot block outgoing requests to other origins. Side-channels do exist. So even though the web page cannot communicate with applications on your computer (or in your network) without the cooperation of these applications, it can observe the behaviour, and make some conclusions based on the observed errors, timing, etc.

An (ad) blocker can prevent you from the activity. As the blockers typically leverage block lists, such a port scanning script URL needs to match a rule in a block list. Once an information about a mis-behaving script becomes public, a rule can be added to a block list. However, this could make some time. Additional techniques like DNS de-cloaking need to be applied in this case.

Network Boundary Shield to the rescue

JSR contains a Network Boundary Shield (NBS) that blocks based on the observed behaviour, i.e. a page hosted on publick internet tries to access local URLs. Consequently, for JSR, it does not matter what is the URL of the script, if there is DNS cloaking employed, or some other techniques. NBS just works.

JSR blocks the scan

Firefox contains DNS API so NBS works flawlessly. In Chromium-based browsers, the exact blocking behaviour depends on how quickly a scanning script can fire the requests and what is the precise destination specification. Depending on the interaction with DNS, NBS can be side-stepped on Chrome. However, it works in the case of eBay and ThreatMetrix.