DEV Community: notachraf

Create your OWN intrusive javascript blocker script 🛑

notachraf — Tue, 26 Dec 2023 10:48:58 +0000

Recently, one of the comments on my previous article about sharing a state between windows asked me how can one go about not sharing informations about the screen to websites.

Well you can disable javascript, but nobody want that...

Another way is to make them not able to access it , but how ?

Well the solution is to use a concept I wanted to talk about : Proxies !
Stick around to find out how we're gonna do this using JS and a user script injector ( like TamperMonkey for Chrome )

Disclaimer
This is in no way a reliable way to assert that no website will be able to access screen information.
Using this on a website may break the website if the property hidden are crucial to the normal behavior of the website
This is educational content only.

Proxies

Proxies are basically a way to intercept write/read instruction to a Javascript Object.

Imagine a Person object, that has a name

type Person {
    name: string
}

const person: Person = {
    name: "Achraf",
}

Without a proxy, trying to get the name will of course just give back the name

But using a proxy will help us intercept this get instruction, and modify it however we want

Okay that sounds exactly like something we'd want !

Simple example

We'll try to make a simple anonymizer for an object that has a name

const authorAnonym = new Proxy(author, {
    get(originalObject, propertyName){
        if (propertyName === "name"){
            return "*******"
        }
        return originalObject[propertyName]
    }
})

console.log("Original Name", author.name);
console.log("Proxied Name", authorAnonym.name);

Btw you can override more than just the get method but also set, has, etc. More Info Here

Okay that's good, but for our original purpose ( hide window properties) this wont work, as even if we create a anonimizedWindow the website will just use the original window

And....you're right. We can't use a proxy to replace the window as the window object is not replaceable , but that's okay, we'll replace other information, like the screen

Let's start writing our Script

We can start easy by overriding some information like the position of the tab on the monitor

window.screenX = 0
window.screenY = 0 
window.devicePixelRatio = 0

Now let's make default screen properties we want to override, like for example availWidth and availHeight which are the enough to give away our monitor size

const overridenProperties: Partial<Screen> = {
    availHeight: 0,
    availWidth: 0,
    pixelDepth: 10,
}

const screenProxy = new Proxy(window.screen, {
    get(screen, propertyName){
        return overridenProperties[propertyName] ?? screen[propertyName]
    }
})

window.screen = screenProxy

and with that, we are basically done, let's test it on a small test website that displays information in a div

Here on the left is the website without the tamperMonkey script running and on the right with the script running !

The whole sourcecode can be found here

This was tested on Chrome only, maybe it doesn't work on mozilla, if you have, please share it in the comments !

Conclusion

Proxies are a great way to intercept read/write operation on an object, they are used for multiple reasons ( mocking dependencies, singleton pattern, caching, etc. )
If you have ideas on how to use them or personal anecdotes involving proxies, feel free to share them !

Subscribe to my Newsletter ( for free ! )

Hope you had fun reading this article , if you liked it , you can share it to your friends, you can also subscribe to my new newsletter ( first exclusive post dropping 2nd of January, don't miss it ! )
It's right here

The Degenerate Engineer | Achraf | Substack

making dumb stuff, writing about it, sometimes about tech, sometimes not. Click to read The Degenerate Engineer, by Achraf, a Substack publication. Launched 3 days ago.

notachraf.substack.com

Sharing a state between windows without a server

notachraf — Sat, 23 Dec 2023 14:47:52 +0000

Recently, there was a gif trending on social networks displaying an amazing piece of art made by Bjorn Staal.

I wanted to recreate it, but lacking the 3D skills for the sphere, particles, and physics, I aimed to understand how to make a window react to the position of another window.

Essentially, sharing a state between multiple windows, which I find to be one of the coolest aspects of Bjorn’s project!
Unable to find a good article or tutorial on the topic, I decided to share my findings with you.

Let’s attempt to create a simplified Proof of Concept (POC) based on Bjorn’s work!

The first thing I did was to list all the ways I know for sharing information between multiple clients:

Duh: A server

Obviously, having a server (either with polling or websockets) would simplify the problem. However, since Bjorn achieved his result without using a server, this was out of the question.

Local Storage

Local Storage is essentially a browser key-value store, commonly used for persisting information between browser sessions. While typically used for storing Auth Tokens or Redirect URLs, it can store anything serializable. You can learn more about it here.

I recently discovered some fun APIs of Local Storage, including the storage event, which fires whenever the Local Storage is changed by another session of the same website.

Wanna Discover new APIs ?
Subscribe to my Newsletter ( for free ! )

We can leverage this by storing the state of each window in the local storage. Whenever a window changes its state, other windows will be updated via the storage event.

This was my initial idea, and it seems to be the solution Bjorn chose, as he shared his LocalStorage manager code along with an example of using it with threeJs here.

But once I found out that there was code solving this problem, I wanted to see if there was another way… and spoiler alert: Yes, there is!

Shared Workers

Behind this flashy terminology is a fascinating concept — the concept of WebWorkers.

In simple terms, a worker is essentially a second script running on another thread. While they don’t have access to the DOM as they exist outside the HTML Document, they can still communicate with your main script.
They are mostly used to offload the main script by handling background jobs, such as pre-fetching information or handling less critical tasks like streaming logs and polling.

Shared workers are a special kind of WebWorkers that can communicate with multiple instances of the same script, making them interesting for our use case! Okay, let’s dive right into the code!

Setting up the worker

As mentioned, workers are a “second script” with their own entry points. Depending on your setup (TypeScript, bundler, development server), you may need to tweak your tsconfig, add directives, or use specific import syntax.

I can’t cover all the possible ways to use a web worker , but you can find the informations on MDN or the internet.
If needed, I’d happily do a prequel to this article detailing all the ways to set them up!

In my case, I’m using Vite and TypeScript, so I need a worker.ts file and installing the @types/sharedworker as a dev dependency. We can create our connection in our main script using this syntax:

new SharedWorker(new URL("worker.ts", import.meta.url));

Basically, we need to:

Identify each window
Keep track of all window states
Alert other windows to redraw once a window changes its state

Our state will be quite simple:

type WindowState = {
      screenX: number; // window.screenX
      screenY: number; // window.screenY
      width: number; // window.innerWidth
      height: number; // window.innerHeight
};

The most crucial information is, of course, window.screenX and window.screenY as they tell us where the window is relative to the top-left corner of your monitor.

We’ll have two types of messages:

Each window, whenever it changes its state, will publish a windowStateChangedmessage with its new state.
The worker will send updates to all other windows to alert them that one of them has changed. The worker will send a syncmessage with the state of all windows.

We can start with a plain worker looking a bit like this:

    // worker.ts 
    let windows: { windowState: WindowState; id: number; port: MessagePort }[] = [];

    onconnect = ({ ports }) => {
      const port = ports[0];

      port.onmessage = function (event: MessageEvent<WorkerMessage>) {
        console.log("We'll do something");
      };
    };

And our basic connection to the SharedWorker will look something like this. I have some basic functions that will generate an id, and calculate the current window state, also I did some typing on the kind of Message that we can use called WorkerMessage:

    // main.ts
    import { WorkerMessage } from "./types";
    import {
      generateId,
      getCurrentWindowState,
    } from "./windowState";

    const sharedWorker = new SharedWorker(new URL("worker.ts", import.meta.url));
    let currentWindow = getCurrentWindowState();
    let id = generateId();

Once we start the application, we should alert the worker that there is a new window, so we send immediately a message:

    // main.ts 
    sharedWorker.port.postMessage({
      action: "windowStateChanged",
      payload: {
        id,
        newWindow: currentWindow,
      },
    } satisfies WorkerMessage);

We can listen to this message on our worker side and change the onmessage accordingly. Basically, once the worker receives the windowStateChanged message, either it's a new window, and we append it to the state, or it's an old one that changed. Then we should alert everybody that the state has changed:

    // worker.ts
    port.onmessage = function (event: MessageEvent<WorkerMessage>) {
      const msg = event.data;
      switch (msg.action) {
        case "windowStateChanged": {
          const { id, newWindow } = msg.payload;
          const oldWindowIndex = windows.findIndex((w) => w.id === id);
          if (oldWindowIndex !== -1) {
            // old one changed
            windows[oldWindowIndex].windowState = newWindow;
          } else {
            // new window 
            windows.push({ id, windowState: newWindow, port });
          }
          windows.forEach((w) =>
            // send sync here 
          );
          break;
        }
      }
    };

To send the sync, I actually need a bit of a hack, because the “port” property cannot be serialized, so I stringify it and parse it back. Because I’m lazy and I don’t just map the windows to a more serializable array:

    w.port.postMessage({
      action: "sync",
      payload: { allWindows: JSON.parse(JSON.stringify(windows)) },
    } satisfies WorkerMessage);

Now it’s time to draw stuff!

The Fun Part : Drawing !

Of course, we won’t be doing complicated 3D spheres : we’ll just draw a circle in the center of each window and a line linking between the spheres!

I’ll be using the basic 2D Context of the HTML Canvas to draw, but you can use whatever you want. To draw a circle, it’s pretty simple:

    const drawCenterCircle = (ctx: CanvasRenderingContext2D, center: Coordinates) => {
      const { x, y } = center;
      ctx.strokeStyle = "#eeeeee";
      ctx.lineWidth = 10;
      ctx.beginPath();
      ctx.arc(x, y, 100, 0, Math.PI * 2, false);
      ctx.stroke();
      ctx.closePath();
    };

And to draw the lines, we need to do a bit of math (I promise, it’s not a lot 🤓) by converting the relative position of the center of another window to coordinates on our current window.
Basically, we are changing bases. I do this using this bit of math. First, we will change the base to have coordinates on the monitor and offset that by the current window screenX/screenY

    const baseChange = ({
      currentWindowOffset,
      targetWindowOffset,
      targetPosition,
    }: {
      currentWindowOffset: Coordinates;
      targetWindowOffset: Coordinates;
      targetPosition: Coordinates;
    }) => {
      const monitorCoordinate = {
        x: targetPosition.x + targetWindowOffset.x,
        y: targetPosition.y + targetWindowOffset.y,
      };

      const currentWindowCoordinate = {
        x: monitorCoordinate.x - currentWindowOffset.x,
        y: monitorCoordinate.y - currentWindowOffset.y,
      };

      return currentWindowCoordinate;
    };

And as you know, now we have two points on the same relative coordinates system, we can now draw the line !

    const drawConnectingLine = ({
      ctx,
      hostWindow,
      targetWindow,
    }: {
      ctx: CanvasRenderingContext2D;
      hostWindow: WindowState;
      targetWindow: WindowState;
    }) => {
      ctx.strokeStyle = "#ff0000";
      ctx.lineCap = "round";
      const currentWindowOffset: Coordinates = {
        x: hostWindow.screenX,
        y: hostWindow.screenY,
      };
      const targetWindowOffset: Coordinates = {
        x: targetWindow.screenX,
        y: targetWindow.screenY,
      };

      const origin = getWindowCenter(hostWindow);
      const target = getWindowCenter(targetWindow);

      const targetWithBaseChange = baseChange({
        currentWindowOffset,
        targetWindowOffset,
        targetPosition: target,
      });

      ctx.strokeStyle = "#ff0000";
      ctx.lineCap = "round";
      ctx.beginPath();
      ctx.moveTo(origin.x, origin.y);
      ctx.lineTo(targetWithBaseChange.x, targetWithBaseChange.y);
      ctx.stroke();
      ctx.closePath();
    };

And now, we just need to react to state changes.

    // main.ts
    sharedWorker.port.onmessage = (event: MessageEvent<WorkerMessage>) => {
        const msg = event.data;
        switch (msg.action) {
          case "sync": {
            const windows = msg.payload.allWindows;
            ctx.reset();
            drawMainCircle(ctx, center);
            windows
              .forEach(({ windowState: targetWindow }) => {
                drawConnectingLine({
                  ctx,
                  hostWindow: currentWindow,
                  targetWindow,
                });
              });
          }
        }
    };

And as a final step, we just need to periodically check if our window changed and send a message if that’s the case

      setInterval(() => {
        const newWindow = getCurrentWindowState();
        if (
          didWindowChange({
            newWindow,
            oldWindow: currentWindow,
          })
        ) {
          sharedWorker.port.postMessage({
            action: "windowStateChanged",
            payload: {
              id,
              newWindow,
            },
          } satisfies WorkerMessage);
          currentWindow = newWindow;
        }
      }, 100);

You can find the whole code for this on this repository. I actually made it a bit more abstract as I did a lot of experiments with it, but the gist of it is the same.

And if you run it on multiple windows, hopefully, you can get the same thing as this!

Thanks for reading !

If you found this article helpful, intersting or just fun, you can share it to your friends/coworkers/community
You can also subscribe to my newsletter It's free !

The Degenerate Engineer | Achraf | Substack

caffeine fueled braindead engineer talking about basically 60% Tech / 30% Human interactions / 10% internet lore. Click to read The Degenerate Engineer, by Achraf, a Substack publication with hundreds of subscribers.

notachraf.substack.com

Edit:

Some of you proposed another solution to this problem, namely using BroadcastChannel API and I wanted to give them a shoutout, mainly @framemuse and @axiol
Actually @axiol did a full write up of the solution using the BroadcastChannel API that you can find here: https://github.com/Axiol/linked-windows-broadcast-api

Huge thanks to them to help everyone else learn something new (starting from me)

SOP : Of CORS it works like that !

notachraf — Tue, 11 Jul 2023 19:21:58 +0000

Most of web developers encounter at one point or another some errors about CORS in the console, of course, we look it up on Google, other devs tell us to just put a line in our backend, and then it's all good from there .... Or is it ?

What really happens when we add that magical StackOverflow one liner response.header("Access-Control-Allow-Origin", "*"); in our server

And how does it affect our security ?

If we try to understand CORS, we find soon enough that we also need to understand SOP. And in this article we'll try to understand how both of them work !

TL;DR

SOP and CORS are web security mechanisms that prevent unauthorised access to resources from different origins.

Origin : Web content's origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it. Two objects have the same origin only when the scheme, hostname, and port all match.

SOP : Same Origin Policy : SOP restricts web resources from being accessed across different origins
CORS : Cross Origin Ressources Sharing : Allows web resources to be accessed across different origins with appropriate permissions.

Definitions

Some definitions are a bit necessary, for this article, they are perfectible and not precise, but they do the job for the scope of this introductory article :

Web Resource : A web resource is basically any resource that is the target of a web request.
Origin : An origin is defined by the scheme, hostname, and port of a URL. If two URLs have the same scheme, hostname, and port, they are considered to be from the same origin. For example, comparing "**<https://ovrsea.com:443>**" to other urls

Same-Origin Policy (SOP)

The Same-Origin Policy is a web security mechanism implemented on the browser side that restricts access to web resources ( by resources, we mean anything that is the target of a HTTP Request, the nature of which is not more defined ) from being accessed across different origins.

The purpose of SOP is to prevent malicious scripts from accessing sensitive resources by restricting them to only access resources from the same origin. This is because web browsers have the unfortunate* tendency to send cookies and other informations to their corresponding origin on each request, which is quiet handy for all legit use cases, but can become problematic if a malicious person try to use this fact.

For example, imagine a malicious website "**<https://evilWebsite.com>**" that integrates malicious calls to "**<https://bank.com**>" to steal money from unsuspecting users. If there was no security mechanism, the malicious website will be able to request access for the cookies of the user and read them, and therefore he’ll be able to make the request to the bank to steal money.

But because of the Same-Origin Policy, the malicious website cannot directly access the user's banking information since they have different origins.

However, SOP only prevents the malicious origin from reading the answer, not making it. So, the malicious website can still make the request to the bank domain on behalf of the user, but it cannot read the response due to SOP.

That would need a different kind of protection to Cross Site Request Forgery , which may be the subject of a next article 👀.

In this exemple, the attacker makes the request to bank.com/pay?to=evil&amount=5000 and assuming it doesn't need any kind of authentification or verification more than the cookies, the request will succeed. Hopefully, most banks and websites will actually have CSRF protection and Multi Factor Authentication.

One common misconception is to believe that the SOP prohibits all cross-origin requests. If that were the case, content delivery networks (CDNs) and even the web would be worthless since it would be impossible to use images from other origins, or using javascript packages.

<img href="https://gravatar.com/my-avatar.com" />

<script src="https://unpkg.com/htmx.org@1.9.2"></script>

This is actually permitted in browsers with SOP !

Moreover, the SOP does not prohibit origins from contacting one another or sending and receiving requests (such as submitting forms), they only prohibit reading the results. SOP allows embedding resources ( like images, javascript scripts, or more full html pages ) but again, they don't permit the reading if the request originated from another origin !

But even with this set of rules, it is still too strict for some legitimate usage, like for our case, our frontend https://ovrsea.com will be able to make the HTTP Request to https://api.ovrsea.com but will not be able to read the answer (as they are not on the same origin ) , which is no good for us. But thankfully, there is a way to allow us to relax the rules of SOP: by using CORS !

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing is a web security mechanism that allows web resources to be accessed across different origins with appropriate permissions. CORS is based on adding HTTP headers to web requests and responses that allow browsers to determine if a web resource can be accessed from a different origin.

CORS works by adding HTTP headers ( the famous Access-Control-Allow-Origin ) to responses that indicate which cross origin is allowed to access a particular resource.

For example, if a web page from "**<https://ovrsea.com>**"wants to access an API from **“<https://api.ovrsea.com>"**,
the API should tell the browser
"hey dude it's cool , ovrsea.com is a safe site for me, you can send him my data",
To do that technically the server of the api will set the header to allow for https://ovrsea.com :
Access-Control-Allow-Origin: '<https://ovrsea.com>'

So now, we understand a bit more about what happens when we set "Access-Control-Allow-Origin": "*" : it means that everybody is able to request the origin and read from it ! So if that’s not your intended purpose, you better restrict it !

By the way, if you ever wondered about the utility of the OPTIONS method request you see before making the actual request in your network inspector , well it’s because of CORS. It’s a preflight request that precedes the actual request, to ask the other origin if it’s okay to proceed with the actual request, or if it should be aborted. It’s made this way so that the server can decide on an origin based on whether or not to allow resource sharing.

There is also other headers that may be interesting to use that are more detailed here !

Conclusion

SOP will restrict how we can share resources by limiting the readability of the resources, and CORS will relax those restriction to allow us to access them if they are explicitly allowed to !

But those protections and mechanisms are only implemented on the browser side, this doesn’t block requests made by other means like curl, wget, and any other request made by non browsers , so it shouldn’t be used as a way to restrict access to a backend, this should be done by other tools and mechanisms !