mirror of
https://github.com/bitwarden/browser
synced 2026-01-27 06:43:41 +00:00
cb21aa9ff9
* Initial changes to look at phishing indexeddb service and removal of obsolete compression code
* Convert background update to rxjs format and trigger via subject. Update test cases
* Added addUrls function to use instead of saveUrls so appending daily does not clear all urls
* Added debug logs to phishing-indexeddb service
* Added a fallback url when downloading phishing url list
* Remove obsolete comments
* Fix testUrl default, false scenario and test cases
* Add default return on isPhishingWebAddress
* Added log statement
* Change hostname to href in hasUrl check
* Save fallback response
* Fix matching subpaths in links. Update test cases
* Fix meta data updates storing last checked instead of last updated
* Update QA phishing url to be normalized
* Filter web addresses
* Return previous meta to keep subscription alive
* Change indexeddb lookup from loading all to cursor search
* fix(phishing): improve performance and fix URL matching in phishing detection
Problem:
The cursor-based search takes ~25 seconds to scan the entire phishing database.
For non-phishing URLs (99% of cases), this full scan runs to completion every time.
Before these fixes, opening a new tab triggered this sequence:
1. chrome://newtab/ fires a phishing check
2. Sequential concatMap blocks while cursor scans all 500k+ URLs (~25 sec)
3. User pastes actual URL and hits enter
4. That URL's check waits in queue behind the chrome:// check
5. Total delay: ~50+ seconds for a simple "open tab, paste link" workflow
Even for legitimate phishing checks, the cursor search could take up to 25 seconds
per URL when the fast hasUrl lookup misses due to trailing slash mismatches.
Changes:
phishing-data.service.ts:
- Add protocol filter to early-return for non-http(s) URLs, avoiding
expensive IndexedDB operations for chrome://, about:, file:// URLs
- Add trailing slash normalization for hasUrl lookup - browsers add
trailing slashes but DB entries may not have them, causing O(1) lookups
to miss and fall back to O(n) cursor search unnecessarily
- Add debug logging for hasUrl checks and timing metrics for cursor-based
search to aid performance debugging
phishing-detection.service.ts:
- Replace concatMap with mergeMap for parallel tab processing - each tab
check now runs independently instead of sequentially
- Add concurrency limit of 5 to prevent overwhelming IndexedDB while still
allowing parallel execution
Result:
- New tabs are instant (no IndexedDB calls for non-web URLs)
- One slow phishing check doesn't block other tabs
- Common URL patterns hit the fast O(1) path instead of O(n) cursor scan
* performance debug logs
* disable custom match because too slow
* spec fix
---------
Co-authored-by: Alex <adewitt@bitwarden.com>
(cherry picked from commit 60c28dd182)
Bitwarden Client Applications
This repository houses all Bitwarden client applications except the mobile applications (iOS | android).
Please refer to the Clients section of the Contributing Documentation for build instructions, recommended tooling, code style tips, and lots of other great information to get you started.
Related projects:
- bitwarden/server: The core infrastructure backend (API, database, Docker, etc).
- bitwarden/ios: Bitwarden iOS Password Manager & Authenticator apps.
- bitwarden/android: Bitwarden Android Password Manager & Authenticator apps.
- bitwarden/directory-connector: A tool for syncing a directory (AD, LDAP, Azure, G Suite, Okta) to an organization.
We're Hiring!
Interested in contributing in a big way? Consider joining our team! We're hiring for many positions. Please take a look at our Careers page to see what opportunities are currently open as well as what it's like to work at Bitwarden.
Contribute
Code contributions are welcome! Please commit any pull requests against the main branch. Learn more about how to contribute by reading the Contributing Guidelines. Check out the Contributing Documentation for how to get started with your first contribution.
Security audits and feedback are welcome. Please open an issue or email us privately if the report is sensitive in nature. You can read our security policy in the SECURITY.md file.