[Bug] Sync and Password settings require device security, not available in all devices

[JackDSRS]

Describe the bug

I have DDG running successfully and well in two Samsung devices. Sync works fine between them. I have DDG running under the BlueStacks emulator, but when I try to set up either Sync or Password Autofill, it requires a device lock security enabled. At this time, there is no known method to set up PIN, Pattern, or Password protection under BlueStacks.

Entering the Sync code from the Samsung's to share their DDG with BlueStacks does not work, as it still requires the device lock.

I had this same problem under Android Studio and Genesys emulations.

There are other users experiencing similar issues with DDG and actual Android devices, due to manufacturer security specs not matching something or another that the browser wants.

There are many available FOSS and open-source 2FA methods for providing the same level of authentication. It seems like incorporating a 2FA authorization method should provide a similar level of security and security method. MEGA.nz uses 2FA, as do many, many other companies.

Another alternative is for the BlueStacks DDG browser to send an authorization code from the device providing the QR code (in my case, the Samsung phone).

And yes, many, many, many people have been hounding BlueStacks to enable PIN protection specifically because of DDG, banking apps and more.

My current workaround is to clear cache, clear data, and re-import bookmarks exported from Samsungs. There is no work around for exporting password autofill capability.

How to Reproduce

Run DDG on BlueStacks and attempt to enable either Sync or Password Autofill. You're prompted to set security on your device. It does not open anything else. When I tried entering the sharing code (text alternative to the QR code), it just gives the same prompt.

Expected behavior

To at least be able to sync my bookmarks.

Environment

- DDG App Version: 5.276.0
- Device: BlueStacks Emulator App Player 5.22.104.1008, Android 11
- OS: Android 11, rel date 8 Sep 2020, API 30, 
Build ID: TP1A.220624.014, 
Build Time: Tue Jun 21 19:06:33 PDT 2022, 
Fingerprint: samsung/b0qxxx/b0q:11/TP1A.220624.014/S908EXXS2BWA2:user/release-keys
Board: taro
Hardware: qcom
Boot Loader: unknown
CPU Model: 12th Gen Intel(R) Core(TM) i7-12700
Cores: 4
Actual RAM: 8 GB
Physical Available RAM: 7966 MB
ABI: x86_64
Internal Storage Overview 
Used :27.84 GB
Free :98.03 GB
Total :125.87 GB

[github-actions]

Thank you for opening an Issue in our Repository.
The issue has been forwarded to the team and we'll follow up as soon as we have time to investigate.
As stated in our Contribution Guidelines, requests for feedback should be addressed via the Feedback section in the Android app.

[CDRussell]

Thanks for the detailed report, @JackDSRS. The short answer is: yes, you're right about the problems you describe but the BlueStacks scenario is particularly annoying/tricky to handle.

• You're correct in stating that BlueStacks doesn't support setting up a PIN/Pattern/Password, and this blocks the functionality of using Passwords storage and Sync since we require device-level auth for both.
• You're also correct that this can affect real Android devices too; I've seen at least one example of a badly configured ZTE where they misreport their biometric/credential capabilities which causes us to think the device can't authenticate even when it has a working PIN etc... set up.
• The "Set up in Settings" button doing nothing is a bug on our side. The root cause is that we launch an Android biometric enrollment screen that immediately closes on BlueStacks because there is no biometric hardware available. As a further confusion, we assume that won't happen and dismiss the screen you were on which results in you being sent out of the screen you were in and being no further forwards.

The BlueStacks case is particularly tricky because the emulator reports itself as a real device typically (e.g., Samsung Galaxy S21 Ultra) but has zero authentication hardware; no fingerprint sensor, no face unlock and crucially no support for PIN/Password/Pattern enrollment through the standard Android APIs. (A real S21 Ultra would have some or all of these available). This means the standard Android capability checks return an "no hardware available" error for everything.

I don't have an immediate solution here. We're looking into improvements to our device authentication detection and requirements generally that might help with the real-world devices that are tricky (e.g., that ZTE we saw before), but the BlueStacks scenario is harder to work around.

[JackDSRS]

Thank you for the detailed reply. The MEmu emulator actually requires a PIN lock, and DDG works fine in it (but there's more reasons to not use MEmu, than there is to try to slug it out with BlueStacks).

My BlueStacks virtual device is rooted, and I was able to manually inject a CA Cert, but it was for an app's WiFi certification (although you get prompted for what purpose you're entering the cert (one of 3 choices).

I can also reach the security settings interface under BlueStacks, very specifically to enable PIN/Pattern/Password/Swipe/Fingerprint but trying to change it to a simple PIN or anything else just refuses to enable any type of security. It redefaults back to None, regardless of what you try.

Every now and then I try different tweaks to see if I can get it to budge, but just the two above steps took a lot of trial and error.

Pseudo-app based PIN locks have no effect on the actual security functionality of the device, so I've already gone through a dozen or more of those just in testing.

However, I do have a fixed DNS, and my devices (real and virtual) are easily detected by the same apps using LAN and FTP (X-plore and MiX). In addition, I've been testing a Github ADB Explorer to see if it was a faster transfer than just using the normal USB cord, and it suddenly picked up the emulator via ADB without me entering anything.

I also use fixed assigned IP's for the primary devices I connect to my WiFi. Because of this, at least Rapidgator, PayPal, and a number of other apps and software use IP recognition.

So it's possible that ADB or IP interconnections might provide some future solution. Or someone can thwap some sense into BlueStacks.

Oh, and KeyPass has numerous OS builds, all sharing the same type of offline password database encryption. So by synching the devices to a single desktop-cloud-device encrypted database, the password storing functionality is less critical, but it is sorely missed.

• You're correct in stating that BlueStacks doesn't support setting up a PIN/Pattern/Password, and this blocks the functionality of using Passwords storage and Sync since we require device-level auth for both.
• You're also correct that this can affect real Android devices too; I've seen at least one example of a badly configured ZTE where they misreport their biometric/credential capabilities which causes us to think the device can't authenticate even when it has a working PIN etc... set up.
• The "Set up in Settings" button doing nothing is a bug on our side. The root cause is that we launch an Android biometric enrollment screen that immediately closes on BlueStacks because there is no biometric hardware available. As a further confusion, we assume that won't happen and dismiss the screen you were on which results in you being sent out of the screen you were in and being no further forwards.

The BlueStacks case is particularly tricky because the emulator reports itself as a real device typically (e.g., Samsung Galaxy S21 Ultra) but has zero authentication hardware; no fingerprint sensor, no face unlock and crucially no support for PIN/Password/Pattern enrollment through the standard Android APIs. (A real S21 Ultra would have some or all of these available). This means the standard Android capability checks return an "no hardware available" error for everything.

I don't have an immediate solution here. We're looking into improvements to our device authentication detection and requirements generally that might help with the real-world devices that are tricky (e.g., that ZTE we saw before), but the BlueStacks scenario is harder to work around.