When installing the app, the first settings page does not allow to add an API key. This is a problem because it adds a few more not logical steps for people who already have a key.

I think the first settings page should allow to set a key optionally (maybe hide it by default but have the option to do it?)

Seeing this console warning in my gmail:

gmail.js?0d45:2850 Gmail.js: This function has been deprecated and will be removed in an upcoming release! Please migrate to email_source_async!

I'll take a look at updating our usage as part of my work this month.

Wen doing right click on a page and "Scan this page for phishing", the screenshot does not work.

I get the following error message:

Unchecked runtime.lastError: Cannot access contents of url "devtools://devtools/". Extension manifest must request permission to access this host.

Tested with the last commit 179e0f6

1. open a Gmail conversation thread (with multiple emails) -- Share with PhishDetect should appear at top
2. open the top-most email of the thread - a second Share with PhishDetect will appear to the right of the existing Share with PhishDetect

instead, there should continue to only be one Share with PhishDetect, and it shares the most recently opened email.

If suddenly a large bulk of indicators are added at once to a PhishDetect Node, clients might suffer some in performance by having to repeatedly downloading all of them using the /api/indicators/fetch/recent/ route.
Currently that happens every 15 minutes, as defined in INDICATORS_UPDATE_FREQUENCY.
How do we mitigate this issue?

Since malicious urls are often propagated via email it would make sense to have this extension available for the Thunderbird email client, particularly since it is based on FF.

At browser's launch or on demand the extension can scan the browsing history for any detected malicious domains.

In case a domain was added by mistake and then revoked by the Node operator, make sure that the domain is revoked by the browser extension as well.

As it stands, because at least once a day we are doing a full update, the browser extension should be synchronized. However, should we implement some revocation list to be fetched as frequently as the regular (every 15 minutes) updates?

Supporting the integration of ProtonMail webmail would be a great addition. Still to be researched.

I can't find any references to /graphics/*. Are they perhaps referenced by documentation or other pages outside the extension code base? Or can they be removed/moved?

I found a bug in the url management. If my node url ends with /, then the urls have a double //, like //api/reports/add/. In that case, the server returns a 301 redirect to the right url, but somehow in the process, POST requests become GET requests so all the POST queries are failing.

Another thing that would be useful to do, is to have notifications when queries fail, like when reporting a malicious email, so that people are aware that there is an issue.

If I change the url of the node, the API key I give is not saved.

How to reproduce:

• Go in settings
• Update both the node url to a new node and add the API key
• Save
• Then I get the error message "This PhishDetect Node requires users to register a secret token."
• When clicking on it, I see that it saved the url of the node but not the key

I had this issue with the last commit 179e0f6

When clicking on links in the webmail, the open "Safely" in the dialog that opens might be a misguiding label. Perhaps we should change it to "Analyze first" or something similarly neutral.

i saw you already replied to it but wanted to put it here to track any updates:

https://bugs.chromium.org/p/chromium/issues/detail?id=896897
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/veJy9uAwS00
https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/WcZ42Iqon_M
https://discourse.mozilla.org/t/migrating-to-manifest-v3/35784/2
https://docs.google.com/document/d/1sKZFojq_fUusrebKsyNHfRk_9kpbIALFPS1Nvpddfs8/edit

Because PhishDetect Extension removes data-saferedirecturl from links in email bodies (and this is necessary in order to have the dialog open on click), if the user then decides to open the link "Directly" there are some security/privacy properties lost.

It would be useful to either reintegrate the data-saferedirecturl when "Directly" button is clicked, or find an alternative way to provide equivalent privacy properties to the opening of the original link.

The purpose of this issue is to assess and track the feasibility of porting phishdetect-extension to Thunderbird, using the WebExtensions support available in recent versions from the Thunderbird Beta release channel.

The following list summarizes the immediately obvious issues upon loading PhishDetect 5.2.5 as a temporary Add-on in Thunderbird 73.0b1.

The "contextMenus" permission is not supported

This feature must be migrated to the corresponding "menus" permission and API.
https://thunderbird-webextensions.readthedocs.io/en/latest/menus.html

Settings link from browserAction popup is broken

It seems you can't effectively use ordinary relative links to navigate within your UI because Tbird wants to open link-clicks in an external application, but it should be possible to open a new tbird tab to the settings page by calling window.open from a javascript click handler.

Popup buttons do not apply

There shouldn't be any option to scan or report "this page" because most "pages"/tabs in thunderbird are just application UI and not arbitrary web pages. These buttons should be hidden if the extension is running in Tbird, which can be determined by looking for specific APIs (e.g., browser.messages, browser.mailTabs).

Re-implement "Report this email" button

There are no content scripts or markup injection in Tbird. To implement this feature, use the messageDisplayAction API to add a button to the toolbar of message-level actions (ex: reply, reply-all, delete) displayed above a message. When clicked, we can obtain the tab ID and use the messagesRead API to get the raw email content. See attached screenshot for context.

Auto-scan and display warning on phishy emails

Emails can be automatically scanned by listening for an onMessageDisplayed event, which will include a reference to the message and tab, however, it's unclear how to highlight any positively identified phishing emails. Possibly by triggering the messageDisplayAction popup where we can render the warning banner? This needs more exploration, but it might be better to open an issue on Thunderbird requesting support for some kind of warning banner display, as they already have a similar feature baked in for junk emails. (Notice the yellow banner in the screenshot below.)

No link-click interception

As far as I can see there is no way to implement this feature in Tbird as of this writing. We can't inject markup or click handlers, and I see no relevant event callbacks available. Users would have to manually scan links by right-clicking them and selecting the appropriate context menu item. It's probably worth filing this one in bugzilla. I imagine other extensions will also find uses for an API that lets you observe and handle links clicked from displayed messages.

Conclusion

Many, though not all, of these initially obvious issues are addressable with some adjustments, so overall we could already offer a somewhat limited user experience in Tbird, roughly similar to the use of PhishDetect in the browser with an unsupported webmail client. With a bit more API support from Mozilla's side we could probably even get to 100% functionality.

⚠️ It's also possible that I overlooked some features, so let me know if anything is missing!

We need some more accurate description of what is the threat model of the browser extension, what information is collected or not, and what particular threats the extension (and with it, its integration with the configured PhishDetect Node) is trying to resolve.

For example: currently the extension does not perform any detection or prevention of malicious downloads. In the case of phishing attacks using PDFs as lures (which is an increasingly common tactic), the extension does not perform any analysis or is not able to detect any malicious traffic, if the file is being delivered through a legitimate service.

It seems that css files from vex and tailwind are checked into the codebase. Should we instead be loading these from their respective node modules to make them easier to update and minimize our repo surface area?

It might happen that a website was wrongfully blocked. We probably need a link in the warning page allowing the user to continue to the blocked site regardless. There could be security/safety concerns with this, so it needs to be considered carefully.