2024342 - Ensure tool call respect the principals when fetching a URL

Status: NEW

(Core :: Machine Learning: General, task, P2)

Description

[Greg Tatum [:gregtatum]]

I got this feedback from Simon on matching the URL of the tab.

This is sketchy because it does not compare the "principal" which would include origin attributes like containers.

  static getTabWithURL(url) {
    for (const win of lazy.BrowserWindowTracker.orderedWindows) {
      if (!lazy.AIWindow.isAIWindowActive(win) || win.closed || !win.gBrowser) {
        continue;
      }

      for (const tab of win.gBrowser.tabs) {
        if (tab?.linkedBrowser?.currentURI?.spec === url) {
          return tab;
        }
      }
    }

    return null;
  }

Then in some logic checking in https://phabricator.services.mozilla.com/D284944:

Gijs mentioned:

Doing this based on URL schemes from the URL rather than the principal for the page leads to both false positives and false negatives. (note: URL from https://searchfox.org/firefox-main/rev/3c918058f580ec2cd39d80c9f77ccd06982c0029/browser/components/aiwindow/models/ChatUtils.sys.mjs#55 )

For instance, web-based about:blank would be considered "internal" according to this logic (when it can be web/attacker-controlled) and a blob URI whose principal was privileged (so a blob generated by Firefox instead of web content) would be untrusted. (both of these cases inherit principal info from the thing that constructed them).

This should get the content principal of the relevant tab, and be very cautious about how it checks those. See e.g. https://firefox-source-docs.mozilla.org/content-security/index.html and https://firefox-source-docs.mozilla.org/dom/scriptSecurity/index.html .

I didn't change the status quo for the tabs, but we should figure out how we want to handle URLs and principals in the MVP and apply it consistently.

Comment 1

[Simon Friedberger [:simonf]]

There are two things discussed in this bug:

1. Detecting if something is untrusted content. I don't think we need this right now and because we are not giving exceptions to anything we are on the safe side. We might want to relax our flag setting in the future if people want to use AI on about:preferences or something like that but that was specifically not part of the MVP last time I checked.
2. Comparing URLs to find the right tab. This is mostly fine because users have no way to describe a tab other than by its URL and the mention UI also doesn't distinguish between e.g. containers. The only case where the selected tab is implicit and maybe incorrect is the "current open tab". For example, if I have two containers for "example.com" and I am in my "Work" container and ask a question about content, it might accidentally use my "Personal" tab.

Neither of these is necessary for the MVP.