Using Chromium in Kicksecure.

Installation[edit]

One option might be to install using flatpak from flathub. Special instructions are also required in this case.

Install org.chromium.Chromium via flatpak.

1. Add a Flatpak repository.

===

Kicksecure

Already enabled by default. (system-wide). No additional stepss needed to enable the Flathub repository.

===

Kicksecure-Qubes Template (kicksecure-17)

Already enabled by default. (system-wide). No additional stepss needed to enable the Flathub repository.

Kicksecure-Qubes App Qube (kicksecure)

The user needs to Enable the Flathub Repository . Must be enabled per-user.

2. Install the flatpak org.chromium.Chromium package.

===

Kicksecure ^[1]

flatpak install flathub org.chromium.Chromium

===

Kicksecure-Qubes Template (kicksecure-17) ^[2]

Note: Advanced users that uninstalled the qubes-core-agent-passwordless-sudo package should see forum thread Warning: Flatpak system operation Deploy not allowed for user.

http_proxy=http://127.0.0.1:8082 https_proxy=$http_proxy flatpak install flathub org.chromium.Chromium

Kicksecure-Qubes App Qube (kicksecure) ^[3]

flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

flatpak --user install flathub org.chromium.Chromium

3. Done.

The procedure of installing org.chromium.Chromium is complete.

4. Upgrades notice.

Note: this procedure will not keep the software up-to-date. How to update installation installed by flatpak is also documented on the Operating System Software and Updates wiki page.

Usage[edit]

flatpak run org.chromium.Chromium

^[4]

Update[edit]

Kicksecure: flatpak update
Kicksecure for Qubes Template: http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 flatpak update

Qubes Specific[edit]

flatpak installed applications do not show up in Qubes start menu

Related[edit]

Footnotes[edit]

↑
Kicksecure:
- system-wide (requires administrative ("root") rights) (compatible with noexec): flatpak install flathub {{{package}}}
- per-user (no administrative rights required) (probably not compatible with noexec): flatpak --user install flathub {{{package}}}
What is better? System-wide or per-user?
- <>usability:</> Flathub is enabled by default system-wide but not per-user.
- multi-user: On a multi-user system (probably if multiple human users use the same computer, which is rare nowadays), system-wide might be preferable as this saves disk space.
- At preset: Does not make any difference.
- Future-proof: Per-user might be more future-proof. It would be compatible with future Kicksecure security improvements Dev/boot_modes (strong user account isolation). However, noexec for the home folder is to be considered later, at which point this documentation needs to be updated once that has been implemented.
↑ Kicksecure-Qubes Template: flatpak cannot be used with the --user option. This is because in case of using a Qubes Template, the flatpak needs to be installed system-wide into the /var/lib/flatpak folder. This is due to Qubes Persistence. If the --user option was used, the flatpak would only be available in the Template's home folder but not in any App Qube based on that Template, because App Qubes have their own independent home folder.
↑ Kicksecure-Qubes App Qube: flatpak should be used with the --user option. This is because in case of using an App Qube, the flatpak needs to be installed per-user only into the ~/.local/share/flatpak folder and not system-wide. This is due to Qubes Persistence. If the --user option was not used, the flatpak would only be available in the App Qube's non-persistent /var/lib/flatpak folder located in the root image.
↑ flatpak run org.chromium.Chromium --password-store=basic

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

[1] Kicksecure:
system-wide (requires administrative ("root") rights) (compatible with noexec): flatpak install flathub {{{package}}}

per-user (no administrative rights required) (probably not compatible with noexec): flatpak --user install flathub {{{package}}}
What is better? System-wide or per-user?
<>usability:</> Flathub is enabled by default system-wide but not per-user.

multi-user: On a multi-user system (probably if multiple human users use the same computer, which is rare nowadays), system-wide might be preferable as this saves disk space.

At preset: Does not make any difference.

Future-proof: Per-user might be more future-proof. It would be compatible with future Kicksecure security improvements Dev/boot_modes (strong user account isolation). However, noexec for the home folder is to be considered later, at which point this documentation needs to be updated once that has been implemented.

[2] system-wide (requires administrative ("root") rights) (compatible with noexec): flatpak install flathub {{{package}}}

[3] r-user (no administrative rights required) (probably not compatible with noexec): flatpak --user install flathub {{{package}}}

[4] <>usability:</> Flathub is enabled by default system-wide but not per-user.

[5] ulti-user: On a multi-user system (probably if multiple human users use the same computer, which is rare nowadays), system-wide might be preferable as this saves disk space.

[6] At preset: Does not make any difference.

[7] Future-proof: Per-user might be more future-proof. It would be compatible with future Kicksecure security improvements Dev/boot_modes (strong user account isolation). However, noexec for the home folder is to be considered later, at which point this documentation needs to be updated once that has been implemented.

[2] Kicksecure-Qubes Template: flatpak cannot be used with the --user option. This is because in case of using a Qubes Template, the flatpak needs to be installed system-wide into the /var/lib/flatpak folder. This is due to Qubes Persistence. If the --user option was used, the flatpak would only be available in the Template's home folder but not in any App Qube based on that Template, because App Qubes have their own independent home folder.

[3] Kicksecure-Qubes App Qube: flatpak should be used with the --user option. This is because in case of using an App Qube, the flatpak needs to be installed per-user only into the ~/.local/share/flatpak folder and not system-wide. This is due to Qubes Persistence. If the --user option was not used, the flatpak would only be available in the App Qube's non-persistent /var/lib/flatpak folder located in the root image.

[4] tpak run org.chromium.Chromium --password-store=basic

[1]

[2]

[3]

[4]

Chromium

Contents

Installation[edit]

A : Kicksecure

B : Kicksecure-Qubes Template

C : Kicksecure-Qubes App Qube

A : Kicksecure

B : Kicksecure-Qubes Template

C : Kicksecure-Qubes App Qube

Usage[edit]

Update[edit]

Qubes Specific[edit]

Related[edit]

Footnotes[edit]

Navigation menu

Chromium

Installation[edit]

A : Kicksecure

B : Kicksecure-Qubes Template

C : Kicksecure-Qubes App Qube

A : Kicksecure

B : Kicksecure-Qubes Template

C : Kicksecure-Qubes App Qube

Usage[edit]

Update[edit]

Qubes Specific[edit]

Related[edit]

Footnotes[edit]

Navigation menu

Search