Portability under Windows OS

[caada]

I use Chrome as a portable application under WIndows OS. In the past Chrome was partially portable. If chrome browser was moved to another system, extensions were kept. Although, some settings were reset, it was good enough.

Version 55 of the ungoogled chrome was portable. However, after version 60 or so Chrome became unportable. When chrome is carried to another system, chrome deletes the extensions. I think google is checking file "Secure Preferences" for system changes, but I am not sure.

There are a few chrome based browsers that are portable such as Opera, maybe that would give an idea what needs to be changed.

I like ungoogled chrome, but because of portability, I am stuck at version 55. I am not able to use the latest builds.

If someone can look at what needs to be done, I will be happy.

Thanks.

[Eloston]

Hmm, this is interesting.

Is Brave Browser portable?

[caada]

I downloaded the Brave browser yesterday. I made it portable. I changed the settings and modified the extensions. I copied to 3 computers. And settings and extensions are preserved. So, yes Brave is portable as far as I tested.

Based on my research, people are saying related file is pref_hash_store_impl.cc and functions are GenerateDeviceId
GetDeterministicMachineSpecificId
LookupAccountNameW

[Eloston]

Thanks for testing, and the technical details. I may be able to propose a patch later once my current tasks are complete, but I don't have a machine to make a Windows build with right now.

Feel free to submit a PR before then.

[octopuserectus]

I think you can achieve portability by using this launcher, it keeps everything in one folder: https://github.com/henrypp/chrlauncher
I am not sure though, but I think it worked fine when I transfered the folder to another system some time ago.

[caada]

"chrlauncher"

is not portable accross systems. chrome is checking for system change lately.

Thanks for the suggestion.

[mehrdadn]

I just realized my issue (#538) is essentially a duplicate of this one. I believe the patch I suggested there should solve this problem.

[Eloston]

@mehrdadn Thanks for your solution. Did you have this problem on a non-Windows platform?

Also, do you have an idea why Google decided to have this feature? If there's a technical reason for this feature, then it may be problematic to enable it by default.

[mehrdadn]

I believe it's performed only on Windows (but I don't know for sure) and the rationale is to prevent external programs from messing with preferences. I think that wasn't common in other platforms, hence why it occurs only on Windows.

[Eloston]

@mehrdadn Based on the symbol names of your solution, it seems your solution is modifying code related to the preferences store. I believe the preferences store is one component of a profile (i.e. the Preferences file and potentially several other files). I suspect there may be separate logic to determine if the profile is being used on a different machine.

Furthermore, if a hash is used to ensure validity of the store, then it's possible that not all syntax or semantic errors are caught after hash validation passes successfully. This can be a problem if the stored preferences gets corrupted (and also if someone makes a mistake modifying preferences. But, I believe it's important to maintain integrity over ease of tweaking for most users. At most, I will allow a flag to toggle hash validation.)

[mehrdadn]

I think it's just the preferences file that's checked for tampering (there's a file called "Secure Preferences"). But even if other things are checked for migrating profiles between machines, note that migrating profiles between machines is not the real issue here—the problem here is that even on the exact same account and machine, you can't migrate a Chrome profile to ungoogled-chromium. I think it'd directly benefit this project to make that migration easy; the ability to migrate to other machines, if affected, would only be a side benefit.

And yes, it's true that not all errors are caught, but errors are not introduced in the first place unless an external entity is messing with the profile. Given that normal Chrome doesn't allow tampering on Windows, programs don't do that anymore either, so the only time this would occur for a user is if he tried to modify his preferences by hand himself in ungoogled-chromium... in which case I think the user would know what he's doing and the potential for the resulting damage. Though even then, Google's solution of just wiping their settings/extensions/etc. isn't exactly helpful... it inflicts a ton more damage than the user himself did.

But in any case, I think a flag would suffice anyway if you think it needs to be behind one, though it probably wouldn't help make it too easy to migrate to ungoogled-chromium.

[Eloston]

note that migrating profiles between machines is not the real issue here

In this issue, that seems to be the real issue... is there an alternative interpretation I'm missing here?

the problem here is that even on the exact same account and machine, you can't migrate a Chrome profile to ungoogled-chromium

I didn't realize that was also a side effect of this problem from reading your issue report. Thanks for clarifying.

And yes, it's true that not all errors are caught, but errors are not introduced in the first place unless an external entity is messing with the profile

I just realized that the files mentioned here and in your report are the same... it's possible that the logic is more unified and the metric gathering more extensive than I originally thought.

But, if the "pref hash store" also includes a hash of the preference contents, then my earlier point still stands with corruption, i.e. errors introduced by hardware and/or software glitches.

[mehrdadn]

Oh, the alternative interpretation was migrating from Chrome to ungoogled-chromium.

And again, yes, it does "catch" corruption caused by software/hardware glitches, and it "fixes" it by just obliterating almost everything. You can judge whether that's a cure better or worse than the disease; personally I think it's the latter, since I've literally not found this helpful even once...

[Eloston]

And again, yes, it does "catch" corruption caused by software/hardware glitches, and it "fixes" it by just obliterating almost everything. You can judge whether that's a cure better or worse than the disease

I will reserve decisions and further comments on this issue until I learn how the hashing works, what exactly it needs to function, and how it relates to hashes generated by other Chromium variants (e.g. Chrome, Opera, Brave, regular Chromium).

[Eloston]

I think we can reference these changes to solve this issue:

• Add brave disable-machine-id and disable-encryption-win switches brave/brave-core#795
• Please disable auto-resetting of settings when migrating profiles #538 (comment)
  • I'm planning on investigating the CWS change to see what it affects.

If I have time, I'll look into it.

[caada]

If someone can build chrome windows version with --disable-machine-id and --disable-encryption switches, I can test portability.

Thanks keeping an eye on this issue.

[Eloston]

Unfortunately, Windows support is broken and no one's working on it right now (#475). I could test this on Linux once it gets added.

[crazy-max]

@Eloston I can implement the changes I made on brave-core here if you like ?