Keepassdx: Autofill subdomain logic matches every domain with a common TLD country code

[projectgus]

Describe the bug

If an app creates an autofill search for a domain which has a country code component, ie www.example.com.au, then by default KeepassDX will return the first six .com.au domains in the database.

To Reproduce
Steps to reproduce the behavior:

1. Enable KeepassDX autofill service
2. Keep the default Autofill config "Auto search" (enabled), and keep the default "App Settings -> Search -> Subdomain search" setting (disabled)
3. Open a database that contains multiple entries whose URL fields share the same top level country code in the domain. For example 3 entries: https://sitea.com.au, https://siteb.com.au, https://sitec.com.au
4. In a browser app (I used Firefox), navigate to https://www.sitea.com.au/login and select Autofill
5. All .com.au domains are returned as Autofill results. If sitea.com.au is not in the first six results then it won't be shown.

Expected behavior

KeepassDX will match on the URL https://sitea.com.au if it's found in the database, or prompt for a match otherwise.

Keepass Database

• Created with: KeepassXC
• Version: 2.6.1
• Location: Local file
• Size: 133KB
• Contains attachment: No

KeePassDX (please complete the following information):

• Version: 2.8.7 (current master)
• Build: [e.g. Free] Free
• Language: [e.g. French] English

Android (please complete the following information):

• Device: Xiaomi 5S
  Version: LineageOS 17.1 Unofficial (Android 10)

Workaround

It is possible to workaround by either disabling Auto Search or enabling the option "Subdomain search: Search web domains with subdomain constraints" in the App Settings -> Search settings. To be honest I don't think many users would guess that's what the "Subdomain search" option does when enabled, I only found this out by looking at the source code.

Additional context

The "no subdomain constraints" search seems to be designed for domains with one top-level element only (ie xyz.com not xyz.co.uk):
https://github.com/Kunzisoft/KeePassDX/blob/c5cbba597182a47079088180de8bdef1cff1c23d/app/src/main/java/com/kunzisoft/keepass/utils/UriUtil.kt#L105

---

I would be happy to try and make a patch for this if it's helpful.

Suggest that a good "subdomain flexible search" algorithm would be to iteratively strip off the first domain element. ie if the search domain is www.example.com.au then first search for www.example.com.au, then append any results for example.com.au, etc.

Ideally this auto search wouldn't include any URLs where only the TLD matches, because having any "auto search" results at all prevents a manual search from being done in the UI.

Thanks for all your work on KeePassDX, apart from this one niggle with AutoFill it's been a joy to use.

[J-Jamet]

Thanks for the feedback. Yes you are right, there is a bug with some domains, if you want to patch it, it is with pleasure. :)

[J-Jamet]

I think we have to go through an external list. (as suggested by @hokonch - Thanks ;))
If the mozilla libraries are not recognized as reliable by F-Droid, we can use a text file in an asset. (K2A uses this method https://github.com/PhilippC/keepass2android/blob/master/src/keepass2android/Assets/publicsuffix.txt However, it will need to be manually updated)

[J-Jamet]

We can use this Maven source https://github.com/whois-server-list/public-suffix-list. I don't think there is a problem with it since it is public. (Under WTFPL license)
@hokonch Can you tell where you saw the libraries not accepted by F-Droid?

(Mozilla repo: https://github.com/mozilla-mobile/android-components/blob/master/components/lib/publicsuffixlist/README.md)

[projectgus]

There's also one in the Apache HTTP client source, which appears to in be Maven central.
https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/util/PublicSuffixMatcher.html

... but I think the whois-server-list one looks perfect.

Can you tell where you saw the libraries not accepted by F-Droid?

I think the specific problem is the Mozilla Maven repo is not whitelisted by F-Droid, due to possible non-FOSS components. Some details here: https://github.com/mozilla-mobile/fenix/issues/162#issuecomment-502348681

[hokonch]

@hokonch Can you tell where you saw the libraries not accepted by F-Droid?

The update of the Password Store on F-Droid was blocked for a while due to using Mozilla maven repository.
android-password-store/Android-Password-Store#648
The app is available on F-Droid now because its source code includes code of the library updated through GitHub Actions.
android-password-store/Android-Password-Store#762

[J-Jamet]

Thanks gentlemen for the links.
Indeed, using libraries from Mozilla repo is a bad idea.
Apache HTTP client lib : 342KB - Oct 2020 would import all HTTP content that is not needed but the package size is not so heavy so it's all good, and it will probably be updated more frequently.
(compared to whois-server-list : 84KB - Mar 2016)

[J-Jamet]

I tested several implementations:

• Apache HTTP: Unfortunately, some classes conflict with native android classes. So I cannot import the library correctly.
• Whois-server-list: Too old, not updated.
• Guava: Library too big for the use we have (7Mo)
• Mozilla-components: Repo not whitelisted

So I manually retrieve the code from Mozilla components that I added to KeePassDX. It will however need to be updated in the future, but it is the most modern code, which runs with coroutines in the background.