So after some digging into NoScript's settings, I found some settings for something called "Cross-tab identity leak protection". Googling this led to a tor project issue Targeted Deanonymization via the Cache Side Channel. This seems to be a recently-added feature of NoScript intended to protect against a new de-anonymization attack. However, the attack seems to be of concern only for a somewhat niche threat model.
The attack relies on a cache-timing side channel, and the ability to share a resource with only a specific user on websites like Twitter, Google etc. to uniquely identify a target. From the website of said attack:
The attack builds on a leaky resource attack by using CPU cache side channels instead of cross-site leaks. In this way, the range of attack scenarios (i.e., affected browsers and resource-sharing services) is considerably larger.
The attack consists of two phases, setup and execution. In the setup phase, the attacker uploads a resource to a resource-sharing service, and then binds it to the victim’s identity. There are two approaches to perform this binding. In the sharing-based approach, the attacker privately shares the resource with the target (e.g., by using the victim’s email address or user ID with the service). In the blocking-based approach, the attacker makes the resource public, and then blocks the target from viewing any resources owned by the attacker. Next, the attacker embeds this resource into an attacker-controlled webpage.
In the execution phase, the attacker causes the target to visit the attack page (steps 1 and 2). As the target’s browser renders the page, it makes a cross-site request for the embedded resource to the sharing service (steps 3 and 4), passing the user’s authentication cookies. The response of the sharing website to this request depends on the target’s identity. With the sharing-based approach, the response to this cross-site request contains the shared resource if the user is the target, and an error otherwise (step 5). With the blocking-based approach, the opposite happens – the response contains an error for the blocked target, and the shared resource for other users.
In the final step of the attack, the attacker needs to discover whether the shared resource was loaded. The Same-Origin policy prevents the attacker from directly reading out the cross-origin response. However, by using a browser-based CPU cache side channel, the attacker is able to learn if the resource has been loaded or not. Specifically, the attacker page uses JavaScript to measure the contention to the CPU cache (step 6) – depending on whether the resource is being loaded or not, the contention to access the CPU cache will have distinct patterns.
