Qubes landing/welcome page for Firefox (& Chromium?) in Fedora and Debian templates

[mfc]

This is a ticket to create a Qubes landing page for Firefox (and Chromium?) in Fedora and Debian templates. From #1790 it sounds like the team would prefer this to no-customized-landing-page browsers.

[andrewdavidwong]

Just to clarify (for others and for myself, in case I forget later): "branded browser" in this context means something like the Whonix welcome page in Tor Browser. It doesn't mean "use the Google brand Chrome browser instead of the open source Chromium browser" (which is a possible way to interpret the phrase "branded browser").

[andrewdavidwong]

Just to clarify (for others and for myself, in case I forget later): "branded browser" in this context means something like the Whonix welcome page in Tor Browser. It doesn't mean "use the Google brand Chrome browser instead of the open source Chromium browser" (which is a possible way to interpret the phrase "branded browser").

[unman]

@mfc @andrewdavidwong Where an issue applies to both Debian and Fedora, it seems odd to tag it with both. Doesn't it make more sense to only tag where the issue relates only to that distro?

[unman]

@mfc @andrewdavidwong Where an issue applies to both Debian and Fedora, it seems odd to tag it with both. Doesn't it make more sense to only tag where the issue relates only to that distro?

[andrewdavidwong]

I think it's useful to tag both. For example, if I want to find all the issues that affect Debian, I can select the C: Debian tag in the filter. If we start doing it the other way, how would I easily find all the issues that affect Debian?

[andrewdavidwong]

I think it's useful to tag both. For example, if I want to find all the issues that affect Debian, I can select the C: Debian tag in the filter. If we start doing it the other way, how would I easily find all the issues that affect Debian?

[marmarek]

I think it makes sense to tag both in case when separate solution/implementation is needed there. If a single solution (the same) would work for all of them, better to not tag with distribution, rather more generic C: templates (if anything).
Or maybe even better to create separate issues for Fedora and Debian in such a case? But we already have a lot of open issues...

As for filtering - I think more useful is to search not for issues affecting Debian template (because in practice this means all the issues not-other-template-specific, like dom0 issues), but issues requiring Debian-specific solution. If someone want to help and know how to do things Debian-way (or Fedora-way for that matter), it would be much more useful.

[marmarek]

I think it makes sense to tag both in case when separate solution/implementation is needed there. If a single solution (the same) would work for all of them, better to not tag with distribution, rather more generic C: templates (if anything).
Or maybe even better to create separate issues for Fedora and Debian in such a case? But we already have a lot of open issues...

As for filtering - I think more useful is to search not for issues affecting Debian template (because in practice this means all the issues not-other-template-specific, like dom0 issues), but issues requiring Debian-specific solution. If someone want to help and know how to do things Debian-way (or Fedora-way for that matter), it would be much more useful.

[andrewdavidwong]

Ok, so if I understand correctly, this issue should have the Debian and Fedora labels removed and the Templates label added.

[andrewdavidwong]

Ok, so if I understand correctly, this issue should have the Debian and Fedora labels removed and the Templates label added.

[andrewdavidwong]

This seems like a bad idea to me. The last thing I want in my sensitive VMs is for a web page (even a static, offline, pre-included one) to automatically load when I first start the browser. This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

I'd much prefer to have the default about:blank.

[andrewdavidwong]

This seems like a bad idea to me. The last thing I want in my sensitive VMs is for a web page (even a static, offline, pre-included one) to automatically load when I first start the browser. This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

I'd much prefer to have the default about:blank.

[mfc]

This seems like a bad idea to me. [...] This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

it is already being done in whonix-ws qubes, see previously referenced #1790. so are you suggesting that #1790 should be re-opened?

either we go for a cohesive Qubes UX/branding ("this is an OS, not a collection of OSes") or we say that security concerns prevent us from providing that cohesive branding. from marek's response on #1790 he didn't raise any security concerns with the practice.

[mfc]

This seems like a bad idea to me. [...] This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

it is already being done in whonix-ws qubes, see previously referenced #1790. so are you suggesting that #1790 should be re-opened?

either we go for a cohesive Qubes UX/branding ("this is an OS, not a collection of OSes") or we say that security concerns prevent us from providing that cohesive branding. from marek's response on #1790 he didn't raise any security concerns with the practice.

[andrewdavidwong]

it is already being done in whonix-ws qubes, see previously referenced #1790. so are you suggesting that #1790 should be re-opened?

No, because #1790 isn't about that. It's up to the Whonix project to make a decision about whether to have a landing page (which they have already done).

either we go for a cohesive Qubes UX/branding ("this is an OS, not a collection of OSes")

But it's both. That's one of the best features of Qubes.

or we say that security concerns prevent us from providing that cohesive branding. from marek's response on #1790 he didn't raise any security concerns with the practice.

Hm, I suppose it's fine as long as we're careful to sanitize the images, just like we (hopefully) do with the Qubes wallpapers. Indeed, the wallpapers are a much bigger concern, since they're in dom0, not "just" TemplateVMs. I suppose one could argue that rendering a web page still presents a larger attack surface than having a wallpaper in dom0, but it should be fine if it's just simple, self-contained HTML and CSS. I'll make a mockup and see what you all think.

[andrewdavidwong]

it is already being done in whonix-ws qubes, see previously referenced #1790. so are you suggesting that #1790 should be re-opened?

No, because #1790 isn't about that. It's up to the Whonix project to make a decision about whether to have a landing page (which they have already done).

either we go for a cohesive Qubes UX/branding ("this is an OS, not a collection of OSes")

But it's both. That's one of the best features of Qubes.

or we say that security concerns prevent us from providing that cohesive branding. from marek's response on #1790 he didn't raise any security concerns with the practice.

Hm, I suppose it's fine as long as we're careful to sanitize the images, just like we (hopefully) do with the Qubes wallpapers. Indeed, the wallpapers are a much bigger concern, since they're in dom0, not "just" TemplateVMs. I suppose one could argue that rendering a web page still presents a larger attack surface than having a wallpaper in dom0, but it should be fine if it's just simple, self-contained HTML and CSS. I'll make a mockup and see what you all think.

[andrewdavidwong]

Here's a Qubes start page, inspired by Whonix's nice, simple design: https://github.com/andrewdavidwong/qubes-start-page

If there are no problems with it, @marmarek, feel free to use this (or any variation) as the default start page in any template (except Whonix, of course), but please sanitize the image first.

[andrewdavidwong]

Here's a Qubes start page, inspired by Whonix's nice, simple design: https://github.com/andrewdavidwong/qubes-start-page

If there are no problems with it, @marmarek, feel free to use this (or any variation) as the default start page in any template (except Whonix, of course), but please sanitize the image first.

[jpouellet]

Branding the browser seems to stand in violation of a previously stated policy (quoting from the dev FAQ):

Q: What is Qubes’ attitude toward changing guest distros?

We try to respect each distro’s culture, where possibe. See the discussion on issue #1014 for an example.

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy. I don't have an opinion either way, I'm just pointing out that it seems inconsistent.

[jpouellet]

Branding the browser seems to stand in violation of a previously stated policy (quoting from the dev FAQ):

Q: What is Qubes’ attitude toward changing guest distros?

We try to respect each distro’s culture, where possibe. See the discussion on issue #1014 for an example.

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy. I don't have an opinion either way, I'm just pointing out that it seems inconsistent.

[jpouellet]

@andrewdavidwong wrote:

This seems like a bad idea to me. The last thing I want in my sensitive VMs is for a web page (even a static, offline, pre-included one) to automatically load when I first start the browser. This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

I think we can agree that a local static page maintained in a qubes-official repo seems like an improvement from an attack-surface perspective over loading https://start.fedoraproject.org/ (or anything else) remotely.

In the case of a static page, do I understand correctly that the attack vector you are worried about is someone submitting a patch containing a maliciously crafted image, and the merger not sanitizing it? If that is a legitimate concern, then I think the solution should be a general mechanism to ensure images are always sanitized before being merged, rather than an argument against browser branding. There are already many other potentially untrusted images in the repos.

[jpouellet]

@andrewdavidwong wrote:

This seems like a bad idea to me. The last thing I want in my sensitive VMs is for a web page (even a static, offline, pre-included one) to automatically load when I first start the browser. This increases the attack surface, since now an attacker who wants to mass-compromise Qubes templates can attempt to substitute, say, a malicious Qubes logo image that will exploit a hypothetical browser bug.

I think we can agree that a local static page maintained in a qubes-official repo seems like an improvement from an attack-surface perspective over loading https://start.fedoraproject.org/ (or anything else) remotely.

In the case of a static page, do I understand correctly that the attack vector you are worried about is someone submitting a patch containing a maliciously crafted image, and the merger not sanitizing it? If that is a legitimate concern, then I think the solution should be a general mechanism to ensure images are always sanitized before being merged, rather than an argument against browser branding. There are already many other potentially untrusted images in the repos.

[andrewdavidwong]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

...ensure images are always sanitized before being merged...

Already addressed above.

[andrewdavidwong]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

...ensure images are always sanitized before being merged...

Already addressed above.

[jpouellet]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

Unnecessary deviation from a specific decision made upstream (in Fedora, not Firefox), not related to functionality? Perhaps I just misunderstood the spirit of the policy...

To be clear, I don't think the proposed change here is problematic. It's more a question of clarifying where the line in the sand is drawn with respect to deviating from upstream choices in templates.

[jpouellet]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

Unnecessary deviation from a specific decision made upstream (in Fedora, not Firefox), not related to functionality? Perhaps I just misunderstood the spirit of the policy...

To be clear, I don't think the proposed change here is problematic. It's more a question of clarifying where the line in the sand is drawn with respect to deviating from upstream choices in templates.

[jpouellet]

For example, there's also the fedora-added browser extension to add Fedora to the user agent string, which I remember being installed by default (but for whatever reason can't seem to find right now).

If we do not care for Fedora-added browser modifications, that seems like a target for potential removal too...

[jpouellet]

For example, there's also the fedora-added browser extension to add Fedora to the user agent string, which I remember being installed by default (but for whatever reason can't seem to find right now).

If we do not care for Fedora-added browser modifications, that seems like a target for potential removal too...

[marmarek]

The policy is there mostly to ease maintenance, on several levels:

• less modifications means easier migration to new upstream distribution releases
• upstream documentation matching the distribution running in Qubes VM
• less likely to introduce Qubes-specific issues
• each officially supported distribution (ideally) should offer the same set of Qubes-specific features - a change in one supported distribution should be followed also in others (including some new in the future)

While setting default welcome page may not apply to all the above points, but still may apply to some. I think the gain does not worth it.

BTW For more sensitive VMs (like banking) it's a good idea to set firewall rules allowing access only to the banking site. This will (among other things) mitigate the risk mentioned in #2006 (comment).

[marmarek]

The policy is there mostly to ease maintenance, on several levels:

• less modifications means easier migration to new upstream distribution releases
• upstream documentation matching the distribution running in Qubes VM
• less likely to introduce Qubes-specific issues
• each officially supported distribution (ideally) should offer the same set of Qubes-specific features - a change in one supported distribution should be followed also in others (including some new in the future)

While setting default welcome page may not apply to all the above points, but still may apply to some. I think the gain does not worth it.

BTW For more sensitive VMs (like banking) it's a good idea to set firewall rules allowing access only to the banking site. This will (among other things) mitigate the risk mentioned in #2006 (comment).

[andrewdavidwong]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

Unnecessary deviation from a specific decision made upstream (in Fedora, not Firefox), not related to functionality? Perhaps I just misunderstood the spirit of the policy...

The policy is not that we refrain from all "unnecessary deviations from a specific decision made upstream (in Fedora, not Firefox), not related to functionality." Rather, the policy is that "we try to respect each distro’s culture, where possible." The default browser home page is intended to be changed by downstream users of the browser. This is why it is easily configurable from a readily accessible menu. It is fully expected that distros will change the home page (as Fedora does) and that actual end users will also change it (as the vast majority do). Making a change that is both intended and expected by an upstream provider does not constitute a lack of respect for the upstream provider's culture. Therefore, since Qubes is a downstream user of both Fedora (and, indirectly, Firefox), it would not constitute a lack of respect for Fedora's (or, for that matter, Firefox's) culture to change the default browser home page. Thus, it would not constitute a violation of our stated policy.

The policy is there mostly to ease maintenance, on several levels: [...]

Updated: QubesOS/qubes-doc@6d4d8d3

While setting default welcome page may not apply to all the above points, but still may apply to some. I think the gain does not worth it.

Ok, closing.

[andrewdavidwong]

I think if we are going to have such a policy we should either justify violations of it, or not claim to have the policy.

I don't see why this would be a violation of that policy. Please explain why you think it would be.

Unnecessary deviation from a specific decision made upstream (in Fedora, not Firefox), not related to functionality? Perhaps I just misunderstood the spirit of the policy...

The policy is not that we refrain from all "unnecessary deviations from a specific decision made upstream (in Fedora, not Firefox), not related to functionality." Rather, the policy is that "we try to respect each distro’s culture, where possible." The default browser home page is intended to be changed by downstream users of the browser. This is why it is easily configurable from a readily accessible menu. It is fully expected that distros will change the home page (as Fedora does) and that actual end users will also change it (as the vast majority do). Making a change that is both intended and expected by an upstream provider does not constitute a lack of respect for the upstream provider's culture. Therefore, since Qubes is a downstream user of both Fedora (and, indirectly, Firefox), it would not constitute a lack of respect for Fedora's (or, for that matter, Firefox's) culture to change the default browser home page. Thus, it would not constitute a violation of our stated policy.

The policy is there mostly to ease maintenance, on several levels: [...]

Updated: QubesOS/qubes-doc@6d4d8d3

While setting default welcome page may not apply to all the above points, but still may apply to some. I think the gain does not worth it.

Ok, closing.