Title: How JShelter prevents other parties from sniffing on your local applications?
Date: 2021-06-15 09:00

We recently found a [blog post](https://blog.nem.ec/2020/05/24/ebay-port-scanning/) about
ThreatMetrix Inc. (a part of LexisNexis) scanning locally open ports for about 30,000 web
sites, including eBay. The figure below shows that a browser tries to connect to ports commonly used for remote access to the computer (e.g., RDesktop, VNC, TeamViewer) and other applications.

![A screenshot of the browser being used as a proxy to scan locally open ports]({attach}/images/portscan-1_captured_traffic.png)

The obvious question is, what is the reason for such behaviour? The simple answer is security. See
additional links to [Security Boulevard](https://securityboulevard.com/2020/05/is-ebay-port-scanning-your-pc-probably/), [Avast](https://blog.avast.com/why-is-ebay-port-scanning-my-computer-avast), and [The register](https://www.theregister.com/2020/05/26/ebay_port_scans_your_pc/).

One possibility is that ThreatMetrix creates a [fingerprint](https://arxiv.org/pdf/1905.01051.pdf), 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. However, should you use a new device, the algorithm might decide that
additional authentication steps are required and send you an SMS.

Another option is that ThreatMetrix knows that many fraudulent activities occur on
devices with specific ports open. Recall that the ports being checked concern remote desktop
access. Having a remote desktop port open means that the computer may be used by an adversary that does not sit near the computer but is connected remotely. Consequently, the authentication algorithm might decide that additional proves about the user identity should be checked.

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

### Ethical and legal issues

Although it could be that the underlying intentions are benign and users actually do benefit from
the scanning, the scanning 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 information 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](https://en.wikipedia.org/wiki/2017_Equifax_data_breach)) or the company can start to [sell](https://www.vice.com/en/article/qjdkq7/avast-antivirus-sells-user-browsing-data-investigation) the [information](https://www.pcmag.com/news/the-cost-of-avasts-free-antivirus-companies-can-spy-on-your-clicks) or even [share with others](https://brave.com/rtb-evidence/).

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

[EU ePrivacy Directive](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32002L0058) applies. However, as [WP29 clarified](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp224_en.pdf) (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 login mechanism, 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 several issues that concerned legitimate interests and the necessity of processing, e.g. [C-13/16, point 30 that also points to other related cases](https://curia.europa.eu/juris/liste.jsf?num=C-13/16) or [C-708/18 points 40–45](https://curia.europa.eu/juris/liste.jsf?num=C-708/18). 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 the information that a data controller should reveal
to each data subject before the data processing starts 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](https://blog.avast.com/why-is-ebay-port-scanning-my-computer-avast) [articles](https://www.theregister.com/2020/05/26/ebay_port_scans_your_pc/), it seems that ThreatMetrix and eBay are secretive about data being collected.

Another GDPR issue might be data transfers to third countries. Data transfers of open ports may not be
compatible with GDPR in the light of the [CJEU C-311/18](https://curia.europa.eu/juris/liste.jsf?num=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. So why does a browser leak the information?

Well, the browser employs so called [same origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) (SOP) that in abstract theory should prevent websites from the scans in question. As your local computer is of a different origin from the remote website, your computer should be protected by SOP. Nevertheless, SOP has its limitations. First of all, some [cross-origin resource sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) is beneficial, so the browser cannot block outgoing requests to other origins. Such behaviour opens possibilities for [side-channels](https://www.forcepoint.com/sites/default/files/resources/files/report-attacking-internal-network-en_0.pdf) to be identified. 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 blocklists,
such a port scanning script URL needs to match a rule in a block list. Once information about a
misbehaving script becomes public, a rule can be added to a block list. However, this could take some time. Additional techniques like [DNS de-cloaking](https://blog.lukaszolejnik.com/large-scale-analysis-of-dns-based-tracking-evasion-broad-data-leaks-included/)
need to be applied in this case.

### Network Boundary Shield to the rescue

JShelter contains a Network Boundary Shield (NBS) that blocks outgoing browser requests based on the observed behaviour, i.e. a
page hosted on public internet tries to access local URLs.
NBS just works and cannot be fooled by changes in the URL path, DNS cloaking or other techniques.

![JShelter blocks the scan]({attach}/images/portscan-2_request_blocked.png)

Firefox contains DNS API, so NBS works flawlessly. <del>In Chromium-based browsers, the exact blocking
behaviour depends on how quickly a scanning script can fire the requests and the precise
destination (IP address or a domain name). Depending on the interaction with DNS, NBS can be side-stepped on Chrome. In this case, ThreatMetrix does not try any evasion technique, so
NBS just works in the case of eBay and ThreatMetrix.</del>

Update: In 2025, JShelter was forced to migrate to [Manifest v3](/mv3/) and NBS no longer works in
Chromium-based browsers as they lack the blocking web request API that is crucial to NBS.
