TabId is unreliable

Problem

With browser.ssi, we use TabId (tabs.Tab.id) to verify whether the tab app matches with authorization states.

Example

// In web extension app
await browser.ssi.searchCredentials(
    tabId, // number
    criteria, // object
    dialogOption, // optional object
)

In browser.ssi, use the TabId to get the tab object, and from the tab object, get the browsingContext and window object, which are used during the authorization process, including getting the origin URL, showing the dialog and so on.

However, browser.ssi must rely on the extension app passing in the TabId to get the tab context, which creates some problems.

First problem

One of the problems is that the TabId is not something that cannot be guessed like UUID but just an integer, so it can be faked. For example, an tab app the user requests is working with TabId 1, but third party extension can pass through TabId 2 which is valid for the another tab app. This allows for spoofing and can be a security vulnerability.

Second problem

Another problem is that it is not possible for browser.ssi to distinguish between events that occur inside the browser and requests from tab apps. This becomes a problem when you want to bypass the authorization API because there is no tab context after catching an event from inside the browser.

// In background script in web extension

// Listening to internal browser events
browser.ssi.nostr.onPrimaryChanged.addListener(async () => {
  // Callback after internal browser event emits.
  const credentials = await browser.ssi.searchCredentials(
    -1, // This is a problem. Set to -1 because tab context doesn't exist, but Allowing this can make fakery in other situations.
    criteria,
    dialogOption
  );

  ...
});

Possible Solution

To solve the first problem is that the TabId would be something like a UUID so that it cannot be guessed. It needs to change browser standards - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/Tab.

The solution for the second problem is that browser.ssi, built-in API, can capture the tab context self-sufficiently without needing to pass a TabId from the extension app.

If the second one is possible, the first one can be solved that way too.

Edited by T2