Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--disable-encryption not working anymore #36

Open
crazy-max opened this issue Mar 23, 2020 · 26 comments
Open

--disable-encryption not working anymore #36

crazy-max opened this issue Mar 23, 2020 · 26 comments
Labels
bug Something isn't working

Comments

@crazy-max
Copy link

@crazy-max crazy-max commented Mar 23, 2020

Hi,

There is currently an issue with the patch to disable encryption to allow portability (ungoogled-software/ungoogled-chromium#591) on Windows. Looks like this regression occurs between Chromium 76.0.3809.132 to Chromium 77.0.3865.75 (see brave/brave-core#3385 (comment) and portapps/brave-portable#33). Do you have any idea about this @tangalbert919 @Eloston? I would like to fix this on Brave and ungoogled-chromium but hard to find something relevant. I have this output when I open ungoogled-chromium (80.0.3987.149) if --disable-encryption is enabled:

[1896:2800:0323/163555.011:ERROR:os_crypt_win.cc(102)] Failed to decrypt: Clé non valide pour l’utilisation dans l’état spécifié. (0x8009000B)

Thanks

@tangalbert919
Copy link
Contributor

@tangalbert919 tangalbert919 commented Mar 8, 2021

This issue should be closed if it is already fixed @Eloston.

@Eloston
Copy link
Member

@Eloston Eloston commented Apr 3, 2021

Is this fixed? This issue is over a year old. I'm also struggling to recall the details of this feature, so I'm not sure how to properly test if it is still working.

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Apr 6, 2021

No, this issue still exists. Please refer to the details in #1239.

@ghost
Copy link

@ghost ghost commented Aug 30, 2021

This has yet to be fixed in ungoogled-chromium 92.0.4515.159 @Eloston
image

@kleuter
Copy link

@kleuter kleuter commented Feb 8, 2022

This problem basically leads to non-working portable version: once I disable encryption - no cookies are saved because machine id is disabled

Related links:
ungoogled-software/ungoogled-chromium#538
portapps/ungoogled-chromium-portable#1

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Feb 8, 2022

@kleuter I cannot reproduce your problem. To me, the original issue described by OP has actually been resolved in recent builds for quite a while. I have set ---disable-encryption and --disable-machine-id and my browser is perfectly portable. Successfully tested by me and a few other folks I came across at another forum.

Please note that by default, ungoogled-chromium clears cookies and website data when exiting. I would suggest that you disable such option in chrome://settings and try again.

Also, since version 98 the Cookies file has moved location. If you have some sort of junk-cleaning scripts or software applications, make sure they don't accidentally delete the Cookies file in the new location.

@kleuter
Copy link

@kleuter kleuter commented Feb 8, 2022

Not true, try running your 'portable' app on another machine.
https://portapps.io/app/ungoogled-chromium-portable/#known-issues

@leo-liar
Copy link

@leo-liar leo-liar commented Feb 8, 2022

Doesn't have to even be on an different machine ... Unfortunately when using these flags even if deleting all cookies on exit is disabled the cookies, etc. are still lost after closing and restarting the browser.

Still happens on the most recent version of ungoogled-chromium on Windows 10.

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Feb 8, 2022

@leo-liar I don't know what you meant by "most recent version". If you are referring to the same portapps build that @kleuter mentioned, then it is not the most recent as it only offers chromium 97. winchrome offers up to chromium 98.

@kleuter As I mentioned, I and a few other folks already tested across different machines. I configured my browser using the build from winchrome on a Win11 machine and then moved it to another Win10 laptop. Extensions and cookies are intact. As a user of portable applications for 10+ years, I know perfectly what "portable" means. Also, I'm only here to offer my advice, so being sarcastic against me doesn't help yourself at all.

General principle: Main stream git repo does not maintain -- hence is not responsible for -- 3rd-party builds. portapps is a 3rd-party build. Therefore, if you wanted to report any issue in this git repo, you could (and should) have tried some other builds to see if it is a universal issue, or even better, built your own executable.

@leo-liar
Copy link

@leo-liar leo-liar commented Feb 8, 2022

I was referring to these to builds: (both used in Win 10 and 8.1 x64)

Both show the aforementioned bug of deleting all cookies despite configured to not to do so, if (and only if) both disable encryption/machine-id flags are set.

It's true that apps, extensions and settings are portable but cookies are not -- as several other users already pointed out in some of the referenced issues.

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Feb 8, 2022

@leo-liar Thanks for the info. Then I won't be able to help here, because I and my online acquaintances are using the exact same build your are using (the 2nd link you posted) and we cannot reproduce this issue. ungoogled-chromium is my daily driver, if this issue of deleting cookies exists for me, I would be mad.

The only possibility I can think of is that there is some scripts/applications which accidentally delete the cookies file, because in 98 it changes location (to be inside the [Profile]\Network folder, rather than the root [Profile] folder). Other than that, sorry I cannot help further.

@leo-liar
Copy link

@leo-liar leo-liar commented Feb 8, 2022

Ah, it's good to know that you do not have this issue while using the most recent version. I was under the impression that this bug occured in all recent (Windows) versions of ungoogled-chromium.

I don't think any script/application is messing with my profile folder. As I specify the actual profile folder via command line switch I'm not to worried about (upcoming) changes to it's default location either.

I'll try to create a fresh profile and test if this bug still occurs. #58 got me thinking that this might be related to having a rather old profile which has been kept over several versions of ungoogled-chromium (some of which may hae been buggy in regards to the aforementioned flags).

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Feb 8, 2022

Just to clarify - I'm not saying the location of the [profile] folder (could be [user-data-dir]\Default, or [user-data-dir]\Profile 1, [user-data-dir]\Profile 2... based on your use case) is changed. I'm saying the Cookies file has moved. For example, prior to 97, it likely resided as [user-data-dir]\Default\Cookies, but after 98 it is [user-data-dir]\Default\Network\Cookies. If there is a script that deletes the Network folder as a whole, then the Cookies file inside it is deleted as a result. I do write my own (super aggressive) script to clean the junks of Chrome, so such minor internal file shifting sometimes causes me trouble.

And yes please try a new profile. That's a good first-step for trouble-shooting.

@leo-liar
Copy link

@leo-liar leo-liar commented Feb 13, 2022

After creating a new profile and testing around (and observing that you were right - cookies and log-in states weren't deleted upon browser exit with a fresh profile) in the end it was just enough for me to delete the Local State file from my original profile folder and cookies, etc. are suddenly surviving a browser exit/restart now!

Aftwerwards I just had to reenable some flags that were configured via chrome://flags/ menu (instead of via command line) but no other settings were lost.

(Apparently there is now a different key here "os_crypt":{"encrypted_key":"%BASE_64_KEY%"} in Local State but no other relevant changes. And I haven't tested actually moving this profile to another computer yet.)

@jiangzhenjerry
Copy link

@jiangzhenjerry jiangzhenjerry commented Feb 13, 2022

@leo-liar I'm glad that you tested and that it turned out to work for you too. Cheers.

@tangalbert919 @Eloston I suggest to close this issue for now.

@leo-liar
Copy link

@leo-liar leo-liar commented Feb 19, 2022

Just for completeness:
I tested using my profile on another computer which worked as well. That means that full portability (at least while using the --disable-encryption and --disable-machine-id flags and disabling cookie deletion in the settings) can be achieved.

Though it may be necessary to delete the Local State file if the used profile is already older (i.e. from a previous ungoogled-chromium version).

@kleuter
Copy link

@kleuter kleuter commented Mar 7, 2022

Ok, --disable-encryption and --disable-machine-id flags work IF used from the command line. When used from chrome:flags - all cookies are deleted

@kleuter
Copy link

@kleuter kleuter commented Mar 7, 2022

Caused by the "Disable encryption" flag. All works fine with only the "Disable machine ID" flag

@Hashnoob
Copy link

@Hashnoob Hashnoob commented Apr 29, 2022

So I tried passing --disable-encryption and --disable-machine-id flags in all sorts of ways and configurations moving between systems to test checking the database files. Nothing works.

Is there any progress on the issue I would love a truly portable chrome.

@leo-liar
Copy link

@leo-liar leo-liar commented Apr 29, 2022

Did you pass the flags via command line or via shortcut?
And did you remove any previous existing Local State file?
And within the browser settings, are cookies, etc. to be kept on browser exit?

@Hashnoob
Copy link

@Hashnoob Hashnoob commented Apr 30, 2022

Command line.
Yes.
Yes.

A simple test where you run:

chrome.exe --user-data-dir=profile --disable-encryption --disable-machine-id

Then check the "Login Data" database look in the logins table and check the password element column for saved passwords they will still be encrypted.

@alidan
Copy link

@alidan alidan commented May 1, 2022

i'm trying to move to a new windows install, chrome is the last thing I need to backup, and then this issues of tieing everything to a machine was brought up.

so here is my issue, I have 0 idea what chrome has backed up on their servers, however I have extensions that I consider required to even use chrome, imagezoomer being one of the main ones, along with a number of scripts and settings. show of taking several hundred screenshots and rebuilding if chrome doesn't restore everything, I was hoping dragging and dropping files would work, but apparently that doesn't work with chrome because of the encryption.

is there any way to use ungoogled chromium to get these files ported or am I 100% at the whims of what googled decided to backup on their end?

@leo-liar
Copy link

@leo-liar leo-liar commented May 3, 2022

@Hashnoob
Have you tried this with a separate, newly created portable install?

Regarding the enrypted table values: I'm not sure that using said flags leads to unencrypted login information being stored. I think that the used encryption (maybe just some basic encoding?) will be independent of OS user accounts (and hardware) thus making it portable.

I've just checked this myself - USER column entries (in the Login Data sqlite file) are cleartext but passwords are blobs. The profile is still portable though.

@IDKZAL
Copy link

@IDKZAL IDKZAL commented Jun 12, 2022

Will this be ever fixed? :/
Don't want to switch to Firefox x)

@alidan
Copy link

@alidan alidan commented Jun 12, 2022

For me the only thing that was hard keeping me on chrome just works on firefox too, it was just never submitted to easily be installed on it, so for me i'm trying to get a portable version of firefox going because next time I want to move from one os to another I don't want to have to sit here for 2 months wondering how to deal with chromes bs.

@teeminus
Copy link
Contributor

@teeminus teeminus commented Jun 12, 2022

I don't know if this has been mentioned before as I did not read the complete discussion, but have you tried deleting your chromium settings folder from the disk before using the flag? Maybe there is an encrypted file present from a previous run which then failed to decrypt as no decryption key is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

10 participants