Add data loss warning to flags #disable-encryption and #disable-machine-id

[Darthagnon]

691 - When these flags are enabled, the following data is deleted without warning:

• Extensions (so if your extensions are no longer on the Chrome Web Store or are rare, they're lost)
• Passwords
• Usernames
• Some settings (unknown which, Supermium just said "Some settings have been reset"; at least search engine is wiped)

The Chrome Password Manager also no longer works after these flags are enabled

The following data is preserved:

• Bookmarks
• History
• Most settings
• Flags
• PWAs
• Extension data (e.g. Tab Session Manager sessions, custom uBlock rules, Violentmonkey userscripts) but it is stored in orphaned folders in Local Extension Settings and IndexedDB, so I don't know if it is automatically purged after a while?

[Darthagnon]

With those flags enabled, passwords are not imported, even though the UI suggests otherwise.

[Darthagnon]

With those flags enabled, the browser also does not save login states for websites - I need to log in on every site with every restart of the browser. The observed behaviour is similar to when Settings >> Privacy and Security >> Site Settings >> On-Device Site Data >> Don't allow sites to save data is enabled

[win32ss]

I will be sure to add warnings on the flags.

[Vangelis66]

AFAIAA, you're NEVER supposed to enable those two flags (or use their cmdline equivalents) midway through an existing used/"dirty" profile...

You have to launch Supermium via chrome.exe --disable-encryption --disable-machine-id on a totally fresh/new profile, then go to chrome://flags and enable the two flags for the first time; once enabled, you can henceforth relaunch Supermium without the two equivalent cmdline flags...

You can then start building your profile via adding extensions, importing bookmarks, etc., so that the new "dirty" profile can be transferable across different machines - remember: if you once launch that profile without "the flags", it'll stop being "portable across devices"...

With those flags enabled, the browser also does not save login states for websites - I need to log in on every site with every restart of the browser.

First try to get rid of ALL the existing relevant cookies for the sites affected (e.g. all github.com set cookies for GH) that were up-till-now encrypted (with current machine's ID), reload the browser, then login anew so that new unencrypted cookies are created and stored...

As for importing accounts (usernames+passwords), I'll do a test between Supermium-122 and Supermium-124 (portable/separate installations, both run with "the flags") and report back soon :stuck_out_tongue_winking_eye: ...

[Vangelis66]

As for importing accounts (usernames+passwords), I'll do a test between Supermium-122 and Supermium-124 (portable/separate installations, both run with "the flags") and report back soon 😜 ...

... Yep, as long as both the starting (Sm-122 in my test case) and arriving (Sm-124 in my test case) profiles have been created from scratch with both flags #disable-encryption + #disable-machine-id permanently enabled from the very start of profiles creation, transferring stored account credentials (aka "passwords") via CSV files works as advertised (both ways in my test case, but I can't vouch for backwards compatibility as Supermium versions grow more distant in major version numbers...) - FWIW, my CSV only contained a humble 12 accounts :wink: ...

[Darthagnon]

I'm wondering if there's some flag conflict going on, as I'm still unable to save passwords and login states, even after clearing cookies, site settings and data and making a new blank test profile.

EDIT: Fresh profile with the flags: passwords, login state not saved

I have tested a portable (using chrlauncher to make it portable) installation of Supermium 124 with a fresh profile, enabling only the flags #disable-encryption and #disable-machine-id, and it fails to import my passwords as CSV. Win10 v1709

It also has a strange graphical bug, though I don't know if this is just v124 or the flags:

[Darthagnon]

#disable-encryption is the problematic one - if that is enabled, passwords and login states are not saved. Tested on a fresh profile in a portable installation of v124 on Win10 1709. #disable-machine-id the only flag enabled, and it works. Note that enabling/disabling either of those flags will wipe the aforementioned data.

Do we need both enabled for it to be portable? From the description, it sounds like they do the same thing, but #disable-encryption breaks usability.

[Darthagnon]

I'm currently testing Supermium made portable by the chrome_plus DLL project (as suggested here), and so far it seems to work much better than using the flags. Login is preserved, passwords are imported and saved.

[Vangelis66]

... My OS is Windows Vista SP2 32-bit, with ALL Microsoft updates until Vista's Extended Support EoL, plus several Windows Server 2008 SP2 updates manually installed (to implement SHA2 support, mainly :wink:); as I've already detailed, on ALL my Supermium ("portable") profiles created with BOTH flags #disable-encryption, #disable-machine-id enabled from the very start, I haven't encountered the issues you've been referencing (inability to import accounts via CSV files, inability to remember logins between browser sessions); TBH, I'm out of any ideas why you're having those issues yourself, sorry I wasn't of much help :stuck_out_tongue_winking_eye: ...

I'm currently testing Supermium made portable by the chrome_plus DLL project (as suggested https://github.com/henrypp/chrlauncher/issues/227), and so far it seems to work much better than using the flags.

... Unfortunately, this DLL requires at minimum Win7 SP1, due to changes made by Microsoft in the order DLLs are being loaded by the main app executable (chrome.exe); so this "portabilisation" method can't be used by XP+Vista users of Supermium :sob: ; FWIW, there's a Russian fork of that version.dll to be found here, that promises XP+ support, but due to the whole Anti-Russia climate prevailing in Western societies (and we all know why), I'm only mentioning this in passing - have NOT tried that "solution" myself BTW...

Kind regards :smile:

[Darthagnon]

Thank you for your help, Vangelis66!

[Vangelis66]

... One last detail, which actually appears to be an important one :wink: ; for those two flags to function as advertised, it may be necessary to specify from the very beginning a custom PATH for Supermium's profile (aka User Data directory) rather than let Supermium place its profile in the designated OS location, i.e. %LocalAppData%\Supermium\User Data\; this is done via the --user-data-dir= cmdline flag...

For reference, I'm quoting below an English (machine) translation of the Supermium section on Ru-Board:

Brief FAQ on portability of versions 121+:

For the Windows version, it is possible to work in a portable mode without losing the profile. But the question of whether you need a portable installation needs to be decided immediately, before or during the first launch. If you run the browser at least once without the needed keys/flags, the profile will fall apart, and vice versa, the profile will fall apart if you want to make it portable during work (it’s too late!).

For a portable version, the presence of --user-data-dir= in the command line parameters is required. Without it, Supermium will use the profile in the system %AppData% instead of the desired profile in its installation folder (standard approach of Chromium browsers). When you first start in portable mode, you must set the portability flags "#disable-encryption" and "#disable-machine-id"; that's all; now the browser won't lose profile content during transfer.

For those who are lazy or have no knowledge, ... You can also use Version.dll.

FWIW, it just so happens that ALL my Supermium profiles are being run as "portable" via using the PAF installer from portableapps.com:

https://portableapps.com/apps/internet/supermium-portable

plus specifying those two flags via chrome://flags; but this is probably somewhat OT for this issue :smile_cat: ...

[XakerTwo]

645

just for info and to promote a bit my suggestion. personally i don't want my profile to be permanently portable nor lose my 10+ years profile data at all so simple warning is not what satisfy me. And asking google looks useless - there a google sync and party^3rd

and these are the settings that are resets (possibly list is not complete)


formally warning already exists

so you must already have a backup before touching anything in flags


[Darthagnon]

The Supermium Installer enables flags, and most are non-destructive... assuming that all flags are dangerous and should not be touched without emergency backups seems to go against using Supermium at all. Isn't the point of this browser to enable flags?

I wonder if there's some bug that expects a custom profile folder, as I had mine in the default location in Appdata, just setting it to portable so that I can make a proper PC backup that I can restore from on another machine.

[win32ss]

I made some changes that would block the resetting of data when using the two flags above, as well as a new proposed flag. The former two to facilitate the transfer of data from a non-portable to portable profile, and the latter for a portable to non-portable profile (as machine IDs and encryption are available with this flag).

[XakerTwo]

nice but looking at the code in commit

• does it work only with command line switches and not with flags?
• am i correct that revert-from-portable just allow re-encryption of any targeted profile and can be (ab)used for adapting profile from other machine skipping portabling(decryption) step? if so - hell awesome

[win32ss]

nice but looking at the code in commit

* does it work only with command line switches and not with flags?

* am i correct that `revert-from-portable` just allow re-encryption of any targeted profile and can be (ab)used for adapting profile from other machine skipping portabling(decryption) step? if so - hell awesome

It also works with flags. The flag values are appended to the command line on initialization.

And yes, revert-from-portable does re-encrypt the targetted profile and could be used for moving profiles without using any portable switches.

[XakerTwo]

nice, then one more request - when this flag is engaged and such state detected SHOW PROMPT(keep/reset) BEFORE RE-ENCRYPTION - there is weak, but security-related case when something may attempt to change your profile (such as lazy viruses or other). Don't do it in unattended maner

... btw - with such solution does it necessary to affect disable-encryption and disable-machine-id flags? just one-time run with this switch as command line argument and the profile will be adapted