Is the Shadow DOM enough to prevent the moz-extension path from being exposed?

Add-ons Development
#1

Hello Community,

This is my first AddOn, so forgive me if I ask very basic questions :wink:

I’m currently working on an extension that adds some extra GUI elements to a webpage. I created a Content Script that listens for “key input” events. The functional part is nearly done, so I’ve checked the security best practices page to ensure my extension is safe.

Situation
My extension loads images into the webpage. The images are served by the extension as web_accessible_resources —yeah, those moz-extension://{hash} URLs! Because of this, my extension could potentially contribute to a strong browser fingerprint, which I want to avoid.

Problem
I don’t want to use an iframe to wrap around my elements—it seems very inefficient and would make styling harder. Instead, I’ve placed my elements inside a Shadow DOM in closed mode. Is this a sufficiently safe solution, or is using an iframe the only secure option I have?

1 Like
#2

I don’t think iframe would help, since it’s “src” attribute would still use the addon URL.
There is a solution, but so far only for chrome, the use_dynamic_url option.
See also:

Using shadow root in a closed mode should be enough tough.

Note - it’s great that you are thinking about security this much, but it’s very likely your users already have many other unprotected addons and APIs (like canvas), that guarantees 100% uniqueness for tracking :smiley:.

So don’t spend too much time on it :slight_smile:.

1 Like
#3

That sounds disappointing. I don’t want to accept that my extension isn’t up to a high standard of privacy. :disappointed:

In the long run, I want my extension to become “Recommended” like yours or obsolete. :smile: To achieve the “Recommended” status, I need to adhere to Mozilla’s security best practices.

I think it’s dumb, but I asked ChatGPT about this topic. It said that a Shadow DOM in closed mode isn’t enough because you can still track what’s inside a Shadow DOM by monitoring network resources.

#4

But how can a page monitor network? It can intercept fetch requests with the service worker but I don’t think it applies to other origin requests.

We will need a real security expert here :slight_smile:.
Or make an experiment.

ChatGPT is great though for this kind of questions since it knows everything, it’s just not always right. Especially for the edge cases, and addons alone are already a pretty special case (compared to the all web-development docs and codes it seen and learned).

#5

Thanks!

I might be overthinking this too much. :smile: But seriously, I’m really interested in the perspective of a security expert. Should I wait until an expert reviews this, or is there another way to reach one?

#6

Wait, @dotproto will show up sooner or later and save the day :slight_smile:.

1 Like
#7

Ha, I appreciate the confidence @juraj.masiar, but I don’t know if I’ll live up to it :wink:

TBH there’s no perfect solution here. To my knowledge it’s essentially impossible to meaningfully modify a page’s DOM without leaving some trace that a clever website author can’t use to get some additional fingerprinting information.

As @Watermann suggested, even if the src URLs on elements don’t reveal that the user has a specific extension installed, the per-session extension ID used in the URL can help fingerprint users. But even if the ID were randomized every time runtime.getURL() was called, the patterns of when extensions inject content and shape of the DOM tree they inject can add entropy to a user fingerprint.

Closed root shadow DOM trees and iframes are your best options available to minimize what the page can see of your extension. I suspect that shadow DOM would be more efficient, but I haven’t done a side by side performance test to validate that assumption.

1 Like
#8

Thanks :slight_smile: So I’ll go with the Shadow DOM implementation.

Is there any way someone can review my extension? About best practices and so on!

#9

Unfortunately I don’t have the bandwidth to do that that, @Watermann. Not sure about other folks.