Project

General

Profile

Actions

Bug #1094

closed

Autofill not working

Added by Dariusz Czarnowski 8 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Next Release
Start date:
10/11/2023
Due date:
% Done:

0%

Estimated time:

Description

Hello. Google autocomplete has not been working for some time now. It works in other browsers (Cromite) and applications.


Files

Screenshot_20231011_121152.jpg (540 KB) Screenshot_20231011_121152.jpg Dariusz Czarnowski, 10/11/2023 03:12 AM
Allow Screenshots.png (186 KB) Allow Screenshots.png Soren Stoutner, 10/11/2023 11:06 AM
google-autocompletion.png (144 KB) google-autocompletion.png ask low, 10/15/2023 03:50 AM
Actions #2

Updated by Soren Stoutner 8 months ago

Can you give me an example of how autocomplete should work but isn't?

Actions #3

Updated by Soren Stoutner 8 months ago

  • Status changed from New to Feedback
Actions #4

Updated by Dariusz Czarnowski 8 months ago

1. Holds in the form field
2. Select autocomplete from the menu
3. Nothing is happening

Previously it worked without any problems.

Actions #5

Updated by Soren Stoutner 8 months ago

What setting do you have for Allow Screenshots?

Actions #6

Updated by Dariusz Czarnowski 8 months ago

Same as in the picture - allowed. I didn't change anything in the settings.

Actions #7

Updated by Soren Stoutner 8 months ago

It looks like Google made autofill difficult in recent versions of Android.

https://stackoverflow.com/questions/63076140/how-to-use-android-autofill-api

I am inclined not to spend much effort trying to get autofill functioning, as it expressly works against the idea of having a secure and private browser.

Actions #8

Updated by ask low 8 months ago

What do you mean not working ?

Actions #9

Updated by Dariusz Czarnowski 8 months ago

Maybe I expressed myself wrong. I mean the native password manager.

Actions #10

Updated by Soren Stoutner 8 months ago

  • Priority changed from 3.x to Next Release

I am going to take a bit of time during the next release cycle to see how hard this would be to implement. Some things on the internet indicate it might be as simple as assigning each WebView an autofill ID, but other people say they have problems with getting that to work.

Actions #11

Updated by Soren Stoutner 8 months ago

In the little bit of testing I have done, I haven't gotten autofill to work with any WebView based browser. I also haven't gotten the Android OS autofill to work with any other browser, including Chrome or Firefox. They appear to only want to work with their own, built-in autofill. However, I might be missing some setting I need to get this to work. For privacy and security reasons, I tend to have autofill turned off in so many places at so many levels that finding them all and turning them back on is a bit of work.

Actions #12

Updated by ask low 8 months ago

I use Bitwarden. And most of the times, the AutoFill overlay button doesn't seem to appear quickly. I have to fiddle with it a little bit, by entering into home (keeping PB in background), accessing PB again, then the textbox where I wanna fill in, then the bitwarden AutoFill button appears (where it guides me into the app & then site autofilling completion).

Actions #13

Updated by ask low 8 months ago

Offtopic

I'm actually shocked that some PB users even use untrustworthy proprietary Password Managers. Very strange (being a privacy Browser user & a privacy advocate). I even consider switching to KeePass model, but I'm happy with Bitwarden & Proton Pass I have currently.

Actions #14

Updated by Soren Stoutner 8 months ago

  • Status changed from Feedback to Closed

I am going to close this as a duplicate of Bug #736: AutoFill not working when targeting recent versions of Android and look at dealing with this problem there.

Actions #15

Updated by Soren Stoutner 8 months ago

After thinking deeply about this for several days, I have decided that it is a really good thing that autofill no longer works with Privacy Browser's WebViews. See Bug #723: Connects to content-autofill.googleapis.com when tapping on an input field for a discussion about how a malicious or malfunctioning autofill provider can use the integration to exfiltrate a user's browsing history.

I wrote a lengthy blog post on the subject at:

https://www.stoutner.com/privacy-browser-and-password-managers/

Actions #16

Updated by ask low 8 months ago

Practicing a good opsec is necessary. But it shouldn't become a hazzle to remember and maintain. After reading your blog post, I've found some points very unintriguing.

1. Select unique passwords for each site that are several words long. Length gives you all the security you need.
2. Have the password describe some aspect of the website that is easy for you to remember.

1. More length simply does not mean more secure. There's almost zero chance your pass would be bruteforced, as no intruder will be willing to spend his time and expenses. He would use other social engineering techniques to get your credentials. If a pass got compromised, you need to recreate and remember another phrase, which takes a lot of neuroplasticity training. But, in the case of a random generated pass, you can easily replace with another.

2. The problem with this approach is human error. We always make mistakes from time to time. We forget things even if we try to remember something we just made up the earlier day. There's more chance of account deadlocks in the case of no recovery methods. Even if you setup a recovery method, that involves securing a long recovery phrase, which needs a reliable storage method, such as pass manager.

Regarding copy pasting from pass manager to browser, I oppose that too. Android's way is lot more secure. And most pass managers also implement the time based clipboard deletion.

Actions #17

Updated by Soren Stoutner 8 months ago

1. The point is the length, not random characters that are hard to type, give security (entropy). Adding an extra word that is easy to remember adds a lot more entropy than adding a bunch of characters that are difficult to type and remember. This is what is demonstrated by the XKCD comic at the top of the post. If you get into the math you will find it is always true.

2. Human error is why you write the passwords down somewhere secure. But when you do need to reference your written passwords, just looking at it for a second is enough to remind you what it is. Then you can type it in the website. This removes the need to lower your security by electronically connecting your password manager to your browser in some way.

I have developed this method over the course of many, many years and based on that experience can vouch that it is not too much of a hassle. In my IT work I have also observed how hundreds and hundreds of other people handle their password security. What I have learned is that most of what people consider "best practices" are not best practices. Hence, the purpose of the blog post.

Actions #18

Updated by ask low 8 months ago

If you're always forced to type your password, your strategy will make sense. But in the case of password manager assisted filling, there's simply no need.

Moreover, I think you're believing that the autofill mechanisms are very insecure, which I don't think so.

On Android, you can actually disable Google App & simply avoid content-autofill.googleapis.com(#723). Neither LineageOS, nor any AOSP fork, has anything to do with this. That guy simply added Google Play Services back into Lineage, which caused these requests.

On desktop browsers, there's a chance of form filling credential requests without you knowing if your vault extension is open. Fortunately, most pass vaults are designed in a way with some form of lock mechanism. And forms are filled only when that website domain is saved as url for a pass entry in your vault. Try self hosting NextPass or Bitwarden & you would know how secure they are.

A pass manager in the form of an extension and it's autofilling are way more secure & efficient than you manually remembering & typing. Some exceptions are in-browser autofills like Google Password Manager (which you shouldn't)

And storing them in a cloud would only make sense when it's encrypted through AES-256 or better hash alg. Even if the cloud databases are stolen, there's no chance of unlocking those encrypted vaults. That's how the services like Proton, Tutanota, etc are operated (And you sure know about how strict EU governments are in terms of GDPR).

One best way to sync your local database across your devices, is [Syncthing](https://syncthing.net). Syncthing+Keepass is a deadly combination !

Actions #19

Updated by Soren Stoutner 8 months ago

I feel pretty strongly about this subject, and I think the privacy and security arguments against integration of password managers are sound. For those reasons, it is unlikely that I will ever integrate a password manager with Privacy Browser. (This is the same reason why Privacy Browser will never allow any extensions.)

Actions #20

Updated by ask low 8 months ago

I too feel complicated about this topic. Although I believe password managers continue to exist as privacy friendly opsec tools for those like me. We just need to choose a proper ones like Bitwarden, ProtonPass, or any self hosted ones like Keepass, NextPass, etc. & keep our pass db's safe.

I do respect your decision to not allow password mangers to autofill (Bitwarden works flawlessly despite it's lacking).

Actions #21

Updated by Soren Stoutner 8 months ago

  • Subject changed from Autocomplete not working to Autofill not working
Actions

Also available in: Atom PDF