Bug 1266569 - Chrome extension installed without consent
Chrome extension installed without consent
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: fedora-user-agent-chrome (Show other bugs)
rawhide
All Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Tomas Popela
Fedora Extras Quality Assurance
: FutureFeature, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-25 12:29 EDT by Justin Martin
Modified: 2017-04-17 11:25 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-29 14:41:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Justin Martin 2015-09-25 12:29:12 EDT
Description of problem:
fedora-user-agent-chrome serves no purpose except to advertise the distribution in Chrome's request headers. I didn't consent to having this installed, and it presents both a security issue and a stability issue, as it's advertising the distribution I'm running to remote hosts, and it's modifying request headers that users might need to not be modified (if they're setting their own user agent to test things/bypass restrictions).

Version-Release number of selected component (if applicable):
0.0.0.1, 1.fc22

How reproducible:
Automatically installs

Steps to Reproduce:
1. Install Google Chrome
2. Update system
3. Look at installed Chrome extensions

Actual results:
Unwanted extension is auto-installed without consent

Expected results:
Request user consent to modify their headers to send Fedora branding
Comment 1 Rex Dieter 2015-09-25 13:10:38 EDT
If not clear, fedora-user-agent-chrome is installed by default as part of Fedora Workstation product.

The reporter here apparently does not agree with that decision.

Not sure how best to triage this... trying fedora-productimg-workstation
Comment 2 Rex Dieter 2015-09-25 13:11:07 EDT
changing component for real this time (hopefully)
Comment 3 Ben Williams 2015-09-25 19:04:58 EDT
This to me should have been an opt-in instead of a opt-out
and should of been in the releasenotes.  To me this is against our own Freedom foundation.
Comment 4 Corey Sheldon 2015-09-25 19:14:45 EDT
As a chrome user myself, I even find this alarming on several fronts:

1) Non-interactive install,   not  even (that I can see) in the docs
 1a) no opt-out  mechanism  shown or  even in a 'toast msg' 

2) This  auto loading of a  extension CAN effect  other  extensions which even for a  seasoned  chrome user / developer type is  not  readily  apparent that its that, except in the  beta/unstable versions (which is not the default for most users) this is HIGHLY volatile to both chrome/ium (if installing  both red/blue versions) and  overwrites core  files in ~/.config/google-chrome

3) Not sure I see the need for a  Fedora  specific  labeling in the  headers in the UA that would matter to  the  chrome/ium dev teams, this sounds like a  SIG  centric  measure which I can appreciate the desire /need to know what  % of  Fedora WS users are  using  specific browsers / versions but  that SHOULD NOT be  sent outside  Fedora itself and surely  not  non-interactively or  non-anon (which is btw the  default opt in policy at  chrome install (paraphrased) `[?] allow  google to collect stats, logs to better chrome experience...
Comment 5 Christian Fredrik Kalager Schaller 2015-09-28 11:08:04 EDT
This was put in there based on a wish by the Workstation working group to be able to use major 3rd party sites like Wikipedia to better measure development/growth of our userbase. In Firefox the OS label is part of the browser itself, but for Chrome we needed this extension to make Chrome/Chromium include the string. Without the extension most sites would just register Fedora users as generic Linux users. So remember that this is not a question of a situation where you have 'no information' by default. It is a situation where your browser do by default provide a certain set of information, one of them being what OS you are using. We we did here is replace 'Linux' with 'Fedora Linux'. So while I think it is a fair opinion to not like user agents, I don't agree that adding the word Fedora is a game changing thing.

Also while a bit of an academic difference the extension is not so much auto-installed as it is pre-installed.

Regarding the issue of consent, well any pre-packaged distribution is a collection of software that you consent to installing as a whole. There might be many pieces you don't need/care about, but an operating system is at the end of the day a package deal. 

We did discuss the potential security impact with various security specialists, but at the end of the day it was concluded that the security impact was negligible. Adding the Fedora word to the string doesn't really make it any less or more anonymous.

So I am very tempted to close this as 'not a bug' as it works as designed.
Comment 6 Rex Dieter 2015-09-28 11:21:01 EDT
I asked the original poster to comment more from irc, but it looks like it never landed here.  From further discussion about how they'd like to see this resolved...

The issue they had (apparently) was that extensions have an API to prompt user to enable (or not) that isn't being used here (yet).  Their wish was for the extension to be opt-in using that api.

So, triaging this back to fedora-user-agent-chrome as RFE
Comment 7 Christian Fredrik Kalager Schaller 2015-09-28 11:54:07 EDT
Well as said I think we should close this as notabug, the official solution here from the browser vendors themselves is to use private/icognito browsing mode.
Comment 8 Justin Martin 2015-09-28 12:32:31 EDT
Hey. OP here. Sorry for not following up on the request to post additional info here. Work has been hectic.

There's a couple of issues I would like to see addressed.

The first is that the extension was installed well after my initial install of F22. I use extensions extensively, and I had never seen the extension installed prior to the day I created this ticket. I have been using F22 for some time now. I believe that something triggered to cause the package that installs this extension to re-execute its post-install triggers, or something to that effect. My suggestion here would be to ensure that the post-install triggers for this package only execute if the system installation time is in the past day or so.

The second issue is that I was not informed whatsoever that this extension was being installed. Most extensions these days do a "first use notification" of some sort. It would be simple to have the extension open a tab indicating that the extension is installed, if that tab has not previously been displayed. This would give users the opportunity to see that they're sending branding information to the world, at which point they can remove the extension if it's not acceptable to them.

I do not necessarily object to the existence of this extension, but I do object to the fact that I did not have an opportunity to opt out of its installation, and I was not notified when it was installed. These are both likely to damage trust with other users like me who are cool with their distribution making sensible decisions for them, but want to be notified when those decisions are made automatically.
Comment 9 Christian Fredrik Kalager Schaller 2015-09-28 14:16:20 EDT
Hi Justin,
Getting this extension in place took a lot of time due to Chrome changing policies for how extensions work, so maybe it was a Chrome version issue that caused the extension to appear so late for you (just making a wild guess here).

The general issue here is that adding notifications for a lot of stuff ends up being just 'noise' at some point, so we need to have a relatively high bar for explicitly adding a notification for something happening on the system. And while there isn't of course a hard and fast rule for when something is important enough to justify a notification I don't feel this issue qualifies.

I mean the user agent string already contains a ton of branding stuff already, regardless of this extension. Even without this tiny addition you would still be advertising that you are using Chrome, what version of chrome you are using, that you are on Linux, that you are using X11, what CPU platform you are on and more.
So I have a hard time feeling I am unduly burdening you as a user by expecting that you don't have a issue with 'Fedora' being in that mix. I realize that is a subjective evaluation of it of course, but that is my take on this situation.
Comment 10 Justin Martin 2015-09-28 14:28:59 EDT
I do understand where you're coming from. And I agree that having a lot of noise just creates problems instead of solving them. But at the same time, this package is installing an extension into my browser which is modifying request headers. Given that it has the permission to do this, I don't think it's unreasonable to be concerned that it might present a security/stability issue in the future.

Looking at the implementation of the extension install, you are fetching the extension from a third-party website (github), under your own user. It is not at all impossible that someone could compromise github or your github user in the future, and replace the tarball (https://github.com/tpopela/fedora-user-agent-chrome/archive/v0.0.0.1/fedora-user-agent-chrome-0.0.0.1.tar.gz) with something that executes malicious code in *any* tab. It could read authentication headers at the very least. It could also request additional permissions (which uninformed users might just accept) and do all sorts of dirty stuff such as stealing passwords/sessions.

The very, very minor benefit of being able to track installs of Fedora using the user agent header is not nearly sufficient to justify this level of security vulnerability. This is especially problematic because the user did not opt into this behaviour, and they did not get notified that it was in place.

I'm sorry if this sounds callous, but ultimately the responsibility to figure out a reasonable means of allow the user to opt into this/be notified about this lies with you, not me. As it stands, this extension is presenting a clear and severe consent/security/stability issue, and I think it never should've been introduced in the first place, given that it does nothing for the user. It only benefits third parties.
Comment 11 Justin Martin 2015-09-28 15:01:15 EDT
Correction, sorry. I think instead of getting the package from github it gets it from Google's web store, specifically from https://chrome.google.com/webstore/detail/fedora-user-agent/hojggiaghnldpcknpbciehjcaoafceil. The same issue presents, which is that your account there could be compromised and that could compromise the security/stability of users who are forced into installing the extension.
Comment 12 Jiri Eischmann 2015-09-29 10:57:51 EDT
The difference between downloading something from GitHub and from Chrome Store is that even if our account is compromised the attacker can't exploit it like that, the malicious code would still have to get through Google tests and be approved by them.
Any account could be potentially compromised. Using this argument, we couldn't trust any software, even the one that comes from Fedora. Yes, Fedora has mechanisms to prevent malicious software from getting from compromised accounts of developers to users, but so does Google.
Comment 13 Christian Fredrik Kalager Schaller 2015-09-29 14:26:18 EDT
Ok, closing this as I think the answer is that it works as designed and I haven't seen a argument so far convincing me that this is a situation worse or more dangerous than the general level of 'danger' posed by running any software, including Fedora itself.
Comment 14 Justin Martin 2015-09-29 14:31:19 EDT
The issue of consent remains. The user is taken completely unaware by the installation of this extension, and I don't think it's unreasonable to be concerned by that. The extension is purely installed for the benefit of a third party. It provides zero value to the user.

A solution needs to be determined for how to inform the user that Fedora is changing the behaviour of one of their applications to suit the Fedora project's desires.
Comment 15 Rex Dieter 2015-09-29 14:41:24 EDT
Christian's view (and general consensus of workstation workgroup) is that the status quo is "good enough(tm)", and no changes are planned.
 
Whether you agree or not, re-opening the bug does not change that (using WONTFIX resolution to hopefully make that clearer).
Comment 16 Justin Martin 2015-09-29 14:47:26 EDT
Alright, as long as you're acknowledging that you're intentionally bypassing user consent to further your own interests. Personally, I think that's a breach of user trust and sets a bad precedent. Not much different from manufacturers bundling crapware on their systems. It's a shame that this is acceptable policy.
Comment 17 Christian Fredrik Kalager Schaller 2015-09-30 10:10:15 EDT
I think what we acknowledge is that we disagree with you what is within the range of things we as an operating system provider can change on the system without asking for user consent. Branding Fedora in many ways has been done by the project for years, including custom background images for the desktop, Fedora logos patched into various places like the GNOME about dialog and so on. So while I recognize that you are not happy about this done in the context of the browser user string, we just have to respectfully disagree on this point.
Comment 18 Corey Sheldon 2015-09-30 10:47:47 EDT
Per C#12, that  IS NOT A reasonable  assumption as  much of the  extensions require no yes I said NO validation up front.  Also  google  (short of complaints ) leaves it to the  developer /provider to maintain security of app /extension:


Justin,

Throw the following flags and relaunch:  If comment 6 is  to be believed  those WILL throw a  warning AND  FORCE a manual re-enablement: 



chrome://flags/#extension-content-verification && chrome://flags/#extension-active-script-permission
Comment 19 Tomas Popela 2015-10-02 02:37:29 EDT
I'm not opposed any change to fedora-user-agent-chrome, but there needs to be consensus about it.
Comment 20 kitkat31337 2016-03-18 15:40:35 EDT
I simply went ahead and reported this over to google as an abusive extension.  Broadcasting information about exactly what distro of fedora I am on to the internet without my consent is simply inexcusable.  If you really want to get information on your user base... YOU ASK THEM.  If they decline, it is their right.  That doesn't mean to come in behind the sheets and put a sticker on their back so you can find them anyways.
Comment 21 kitkat31337 2016-03-18 15:48:18 EDT
Just to clarify.  I have no issue with the premise and the functionality of the extension.  But more with the way it was pushed out and forced on users.  I personally don't want that information in my browser headers and removed it.  I reported it because of the way it was underhandedly installed.
Comment 22 Andrew Toskin 2016-05-20 04:09:45 EDT
Stating the name of the operating system in the user agent string is absolutely normal behavior for a web browser. Users of Chrome on other OSes, or users of virtually any other browser on Fedora, would normally have to implement some configurations and/or extensions to *remove* this information. And people who are really concerned about what their browser's user agent string can say about them might want to consider switching to Tor or something anyway.

I think the really weird issue here is that this is being implemented as an *extension* in the first place, instead of just built into Google Chrome's vanilla release. Users of Microsoft Windows don't need an extension for "Windows" to appear in the user agent string.
Comment 23 Tomas Popela 2016-05-20 04:27:43 EDT
(In reply to terrycloth from comment #22)
> I think the really weird issue here is that this is being implemented as an
> *extension* in the first place, instead of just built into Google Chrome's
> vanilla release. Users of Microsoft Windows don't need an extension for
> "Windows" to appear in the user agent string.

Extension was suggested by the Chromium developers as including the distribution name in the User-Agent string was a no-go for them (it possibly could lead to some sites breakage) in upstream.
Comment 24 Stephen Gallagher 2016-05-20 08:18:09 EDT
Also, as I understand the situation, this extension also works with Google Chrome as well (not just Chromium), which we of course do not have privilege to edit.
Comment 25 Allan Lewis 2016-05-20 08:24:15 EDT
I can confirm that the extension is also installed in Google Chrome.
Comment 26 Jens Petersen 2016-09-26 02:09:53 EDT
So presumably it is not viable/easy to patch chromium to do this in Fedora without an extension?
Comment 27 Tomas Popela 2016-09-26 03:55:18 EDT
(In reply to Jens Petersen from comment #26)
> So presumably it is not viable/easy to patch chromium to do this in Fedora
> without an extension?

It is easy, but we can't do the same for Google Chrome..
Comment 28 Jonathan Garbee 2017-02-24 17:19:37 EST
This functionality should be changed to where *Google Chrome* is not touched. Adding an extension to the Chromium from your repositories is fine. Nothing wrong with package maintainers modifying or adding extras there. However *Google Chrome* which is received only from Google is a 3rd party maintaining that binary. Fedora has **nothing** to do with that transaction for the application. So why force yourselves into the mix? This is brute-force installing an extension into a 3rd party piece of software that you don't maintain. It is enough to make me not ever use Fedora simply on the foundation that I don't approve of this measure being taken to put yourselves into software I receive directly from 3rd parties.

> Also while a bit of an academic difference the extension is not so much auto-installed as it is pre-installed.

This is backwards. It is *auto-installed* since I need to go get the external software in the first place before Fedora can force itself into the package. This extension in *NO WAY* comes pre-installed with a clean Chrome binary from Google. It is force-installed software that the user did not ask for nor specifically provide permission for.

Looking over the comments on the web store as well for this extension, most people are venting frustration over the forced install as well. So clearly the action is unwanted by users.

Recommended Solution: Simply modify the UA string in the Chromium build provided in the repositories. Then do *not* in any way modify 3rd party Chrome or Chromium binaries received from other sources.
Comment 29 Jonathan Garbee 2017-02-24 17:41:24 EST
Testing again just now, this force install is so broad that even if I go get a developer build from https://download-chromium.appspot.com it is installed on that with every new profile load. This is absurd. If I need a clean browser for *testing* purposes, it isn't possible to get without jumping through uninstalling this extension that was never asked for.

Please keep to only touching the software your project is maintaining and leave the software others maintain out of it.
Comment 30 Christian Fredrik Kalager Schaller 2017-03-02 08:33:18 EST
(In reply to Jonathan Garbee from comment #28)
> This functionality should be changed to where *Google Chrome* is not
> touched. Adding an extension to the Chromium from your repositories is fine.
> Nothing wrong with package maintainers modifying or adding extras there.
> However *Google Chrome* which is received only from Google is a 3rd party
> maintaining that binary. Fedora has **nothing** to do with that transaction
> for the application. So why force yourselves into the mix? This is
> brute-force installing an extension into a 3rd party piece of software that
> you don't maintain. It is enough to make me not ever use Fedora simply on
> the foundation that I don't approve of this measure being taken to put
> yourselves into software I receive directly from 3rd parties.
> 
> > Also while a bit of an academic difference the extension is not so much auto-installed as it is pre-installed.
> 
> This is backwards. It is *auto-installed* since I need to go get the
> external software in the first place before Fedora can force itself into the
> package. This extension in *NO WAY* comes pre-installed with a clean Chrome
> binary from Google. It is force-installed software that the user did not ask
> for nor specifically provide permission for.

It is pre-installed with Fedora. Chrome just finds it on disk upon installation.

If you want to uninstall it, just do  'rpm -e fedora-user-agent-chrome-0.0.0.4-1.fc25.noarch' and you will never have to see it again :)
Comment 31 Christian Fredrik Kalager Schaller 2017-03-02 08:45:35 EST
Sorry, I was a inaccurate. Chrome finds the pre-installed instructions to enable this extension. Anyway, just remove the RPM and you should be set to go.

Longer term though we are hoping to work with Google to patch Chrome so that we can stop using this extension.
Comment 32 Jonathan Garbee 2017-03-13 10:21:56 EDT
What would an appropriate "patch to Chrome" do here?

As far as I see this, Fedora is pre-installing an extension against users wishes. With no visual option to opt-out of this from happening. I am highly encouraged to go to the Chromium project and ask that a way is found to expand the "malicious extension" prevention measures to apply to Linux and that we add a clause (if not already covered) to prevent future problems like this from occurring. Even on the reviews of the extension itself, your own users are simply asking for choice instead of it being forced upon them. This shows badly for both Fedora for doing it in the first place and Chrome/Chromium for allowing it to happen.

> Anyway, just remove the RPM and you should be set to go.

Or just not use Fedora at all since the project feels the need to inject itself into 3rd party software that it has nothing to do with. If this is happening here with something fairly minor, how do I know it isn't going to happen elsewhere with other more important software in a way I can't notice? It's a fundamental violation of trust.
Comment 33 Christian Fredrik Kalager Schaller 2017-03-13 10:52:24 EDT
A patch to Chrome would extract the operating system information from your operating system and including it in the user agent string. Basically automatically do what the extension does through hardcoding.
Comment 34 Stephen Gallagher 2017-03-13 10:53:08 EDT
(In reply to Christian Fredrik Kalager Schaller from comment #33)
> A patch to Chrome would extract the operating system information from your
> operating system and including it in the user agent string. Basically
> automatically do what the extension does through hardcoding.

Which, for the record, it already does on non-Linux systems.
Comment 35 Matthew Miller 2017-03-13 11:43:02 EDT
I'm sensitive to the privacy concern here, but in looking at https://panopticlick.eff.org/ and trying several different browsers and options, I don't think that we're really significantly reducing privacy with this, in that even *without*, without additional privacy protections, Chrome is pretty leaky with information that can be used to uniquely identify you. Specifically, my browser has a unique fingerprint both with and without this useragent string.

On the other hand, having meaningful metrics about Fedora use in the wild (without installing anything that does individual tracking of any sort) is *hugely* valuable to the project overall, and I think Christian and the Workstation WG make a good case that this can help with that.

I would be very supportive of anyone who would like to work on a privacy-focused Fedora spin, something like Tails, for people who want this. I think that's the right approach.
Comment 36 Jonathan Garbee 2017-03-13 18:48:52 EDT
I'm not commenting on the privacy concerns. As far as I see it, that's a non-issue except for a minority of users as simply adding "Fedora" isn't really giving 3rd parties any incredibly useful information here.

My main concern is on the lack of respect for user transactions with external 3rd parties. Me installing *Google Chrome* from Google's repositories is my interaction with them. Fedora should have no say in what gets auto-installed into that package. Nor the Chromium builds from appspot.

Here is the problem I see with the proposed Chromium patch... By asking Chromium to do this heuristic internally, it is then the responsibility upstream to handle deciding at run-time what the UA string should be based on possibly moving data from the system. And other OSes of course will want to be including and if they change the detection Chromium then needs an update for something that shouldn't be its concern.

Could Fedora's auto-installer package simply ask the user, visually, at install time/first run if they want to opt-in to having the extension installed by default on their Chromium-based things? That way users have the option to say no, and then never have this problem without needing to remove a package that isn't clear is even installed.

I don't feel it is Chromium's responsibility to detect and update the UA string for the various number of Linux distros around. Distro's can change their distributed UA with simple patches before you do builds internally for your packages. That takes care of the Chromium that is maintained by your teams. That is perfectly reasonable to do and doesn't require an extension. Then those of us that use *Google Chrome* or Chromium builds from elsewhere, aren't then affected at all by the auto-installed extension infesting every build available.

Note You need to log in before you can comment on or make changes to this bug.