Privacy issue with recommended Chrome extension

[ea167]

Hello wonderful NodeJS Team,

On the page https://nodejs.org/en/docs/guides/debugging-getting-started/#chrome-devtools-55
you recommend the Chrome extension "NiM".

Please note that this extension requires to share our email addresses to use the extension (as well as the permission "Read and change all your data on the websites you visit"). This requirement was added recently.

I doubt this is GDPR compliant, and the author does not provide a clear justification of why they require such a private information.

IMHO NodeJS should not recommend extensions with such practices.

[fhemberger]

Hi Eric,

thanks for pointing this out. Indeed, the user's email address is sent back every second to Google Analytics: background.js#L112-L113

This is indeed illegal under European GDPR laws.

[june07]

As the author of NiM I would like to provide some feedback.

@ea167 "This requirement was added recently" is not actually true. Please see my blog post written approximately a year ago about this: http://june07.com/foff/.

Along with being highly rated at the Chrome Web Store, NiM has had the support of many in the Node.js community, including Paul Irish of the Chrome DevTools team https://twitter.com/june07t/status/861664828909264896, and Wes Bos https://twitter.com/wesbos/status/839871332280057857, among others.

As far as data (email addresses) being sent to Google Analytics, I'm unsure of how that is illegal?! And I would love to be pointed in the right direction so as to change anything that in fact needs to be changed to conform to any compliance issues.

I've written NiM out of my love for the Node.js language/community and continue to dedicate my time to the project. MUCH more positive feedback has been received compared to negative and I would very much like the link to NiM be re-enstated such that other Node.js developers can also benefit from using NiM as so many others have.

-Respectfully

[thom4parisot]

GDPR is about providing a choice of consent about data collection.

Collecting a data without asking a user its permission breaks this statement.

One way to make it compliant would be to provide a user option (unchecked by default) and to let the user opt in, with a clear indication of what is the information used for (to be sold, to be processed, to send e-mails, etc.).

[june07]

Following some help from several sources including checking some of the larger Chome Extensions and how they are doing things, I think we are compliant. I'm certainly not a lawyer.

https://termsfeed.com/blog/legal-agreements-chrome-extensions/

https://app.termly.io/document/privacy-policy/04164179-f943-4e87-ac8b-5afd0367dc6c#infocollect

So it's clear, that change was just made and I circled it in green to highlight here.

[june07]

@fhemberger Would be great to get some feedback on this.

For the record, I've compared NiM's Chrome web store page with that of 10 different companies, all of whom have items in Google's Chrome web store, FOUR (EBay, Paypal, Walmart, and LinkedIn, of whom are among "10 Global Companies Using Node.js in Production" according to Google. And none of which I would think the Node.js community would have a problem "recommend"ing if that is what it means to add a link on the https://nodejs.org/en/docs/guides/debugging-getting-started/ page.

I have compiled current pictures of all 10 companies’ chrome web store pages, as well as the privacy policy pages for each of the 5 which actually have them referenced, and uploaded them to Google photos (see link below). As far as the other 5, there are a number of valid reasons why they may not have privacy policy links, just as NiM did not, but I don’t want to digress.

https://photos.app.goo.gl/y4TN5dT1JeNbED2KA

I can say with strong conviction that data collected by NiM is minuscule by every measure when compared to that collected by these larger companies. Further, no data has ever been used for ill purposes and will not ever deviate from that found in our new privacy policy (link again: https://app.termly.io/document/privacy-policy/04164179-f943-4e87-ac8b-5afd0367dc6c#infocollect) And again, @ea167’s statement that “this requirement was added recently.” is simply NOT the case as can be determined by reading the GitHub project history.
THIS is where/when the extra permissions were added on Feb 9, 2017, close to 2 years ago. As the removal was partly predicated on that statement, I bring it up again.

I do regret not having a privacy policy in place sooner. To my defense, unlike these larger organizations, I don’t really have spare man/woman power to go around. That said, the focus for me has been on trying to make NiM great for the betterment of like-minded Node.js developers. I should point out that I make zero monetary gain from NiM, and it is a side project for me.

So, if they weren’t before, I believe that all of the bases are now covered. I would like to get the Chrome web store link for NiM back and would be more than happy to submit a PR for such.

Please advise...

-Respectfully to all

[eyedean]

I guess it wouldn't hurt to mention here too that this issue is back -- see #1923 (comment).

Shall we reopen this issue?

[ChALkeR]

@fhemberger what do you think should be done here?

[fhemberger]

Honestly I'm a bit disappointed this issue is back. I thought we came to an understanding here, @june07. And it can't be the job of the website team to continuously check for violations of privacy regulations of third-party tools listed on the website. (as listing could also be interpreted as endorsement of those tools.)

In this case I'm in favor of removing this extension permanently from the nodejs.org website. Thoughts, @nodejs/website?

[june07]

Frederic/All, No changes have been made surrounding this issue as it was resolved way back then. If you look at the code you will see that no changes to any of those parts of the code have been changed and nor would they.

…

On Wed, Jun 12, 2019 at 3:36 AM Frederic Hemberger ***@***.***> wrote: Honestly I'm a bit disappointed this issue is back. I thought we came to an understanding here, @june07 <https://github.com/june07>. And it can't be the job of the website team to continuously check for violations of privacy regulations of third-party tools listed on the website, as this could be interpreted as endorsement of those tools. In this case I'm in favor of removing this extension *permanently* from the nodejs.org website. Thoughts, @nodejs/website <https://github.com/orgs/nodejs/teams/website>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1908?email_source=notifications&email_token=ACWT35W3JN4MUNYQIDVNTWLP2DGR3A5CNFSM4GFQXBZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXP7LFQ#issuecomment-501216662>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWT35WKPKNT5QGAN3LWSN3P2DGR3ANCNFSM4GFQXBZQ> .

[sam-github]

I am having difficulty getting up to speed on this issue.

I just installed NiM, it clearly says the extension will have the right to "Know your email address", it doesn't say it will have the right to report it, though this seems to be a technical limitation of the Chrome extension permissions requesting system -- Chrome only knows the extension "knows" the email address, it can't possibly know what the extension does with it.

If the description is expanded and I read far down enough the page, I find:

Further to better serve and understand my user base the following permission is asked
"Know your email address"

This is a fairly vague statement, it doesn't say what is done with the email address to understand the user base.

With such a delicate issue as removing an extension from our docs, I think the history should be more clear so a fair decision can be made. As-is, its too dispersed across multiple threads. Questions I'm left with:

• "I thought we came to an understanding here" - I don't see a sign of any coming to an understanding in this thread
• GDPR violation: its not clear to me that it does violate GDPR
• The chrome extension seems to be clear in at least that it requests permission to know the user's email address, though I didn't see where it was written what it does with that address

[june07]

@sam-github speaking to your bullets

• Per my last comment in the other thread:

And with the help of those on the node teams, including even bringing this to a TSC meeting, I thought I took every applicable action/step to make things compliant

My thoughts further being validated when NiM was finally reinstated.

• It was my understanding that any GDPR violations were fixed (back then) by the above. And again, nothing new has been added to the code to violate GDPR.
• I agree. And by design I think that Google has it's own fail-safe checks in place to ensure compliance to GDPR. By the simple fact that we are talking about a Chrome Extension, that in of itself guarantees some things. Notices are made at the Chrome store. You get a nice popup when you install the extension.

[sam-github]

I think that Google has it's own fail-safe checks in place to ensure compliance to GDPR

I don't believe that is the case. Google has checks to ensure the user knows that the extension has access to the user's email address, since personal data is known by the extension, it is up to the extension to manage (or not) the data in compliance with any particular law. Its also not clear to me that compliance with GDPR is a requirement to be mentioned in the nodejs docs.

A clear statement (both here and in the extension description) about what is done with the email address would help. As I said, there is no such statement in this thread or in the description on the chrome extension page.

Also, there are suggestions in this thread that NiM has changed its handling of the email. In fact, that is the reason this has come up again. @fhemberger, could you provide some references here that demonstrate the "violations of privacy regulations" that you believe are occurring?

[eyedean]

Thanks for your response, Will, and quick turnaround, Node team.

As an independent developer who does not live in the EU, it's less about GDPR and the lawful aspect of it to me. It's more about the real "privacy" and "why" does it need my email address, and not a UUID (which is in fact provided by Google Analytics by default), to be sent to the author's personal servers in an encrypted manner. Also the length that the author has gone to justify GDPR compliance and setting up the encryption and all makes me believe it's actually the user's "email" that is needed.

I assume by now and after 3 years of running, the author must have an extensive and valuable list of the email addresses probably millions of active Node.js developers in the world. It's interesting that Node team themselves don't have such a valuable list and/or any "business interests" the way it's described in the extensions's ToS.

I can even go further and say that with this script requesting access to all the tabs it already has access to any tab the user has open on their browser, including the source code of whomever runs this extension, making it very easily possible to spoof any sensitive material like AWS_KEY: "..." and sending it to the personal server of the author. I am not saying it's the intent at all. I am just saying it's only one click away and it will take months for Node team to discover that and stop "promoting" that. (PS. It's interesting that the first line of the ToS pointed out by the author already says they collect password and payment stuffs! ;D)

I am sorry but the code is currently actively sending unnecessary personal stuffs, like user's email address to the personal server of the author at https://analytics.june07.com and we have seen the deleted code coming back at the author's discretion at any time. It's making it much harder, at least for me, to establish any trust here.

~ ~ ~

The point I am making is the extension is very helpful and very dangerous. While I respect all the hard work of the author, I believe Node users deserve to at least clearly (not in the details of ToS) know that their email address and other personal information is going to be shared with the author who is not affiliated with the Node team. Just knowing that is what I wish happens, at least.

[cjihrig]

Alternative tool that collects no information at all (because I don't care), but may not be as pretty (because it just launches dev tools): https://github.com/cjihrig/node-v8-inspector

[june07]

@eyedean

Of course. I made looking into it a priority first thing this morning.

I understand your concerns and if you read through the history of this you'll find I address some of them. To be clear, we are talking about issues that were discussed months ago both in this forum as well as via several TSC meetings. But...

I think it's a bit unfair to go down the laundry list of possible attack vectors with NiM as the focus, when those things are in no way unique to NiM but shared by many tools. The documentation page already has a section "Security Implications"... maybe some additional information can be there about?!

• Further should Visual Studio Code be removed because of the possible extension high jacking tactics that can be done there? I wrote a VSCode extension that can integrate with Chrome DevTools and unlike the browser environment, VSCode extensions run full Node.js and don't operate within the constraints of the browser sandbox.
• I'm not a Gitpod user but it seems like a server side tool which clearly requires user info to register It has a paid solution, "business interests" clearly.
• )

It may be a bit naive to think that the "Node team themselves don't have such a valuable list and/or any "business interests"" as the signup form for NodeSchool demonstrates
The fact is that every piece of technology is a "business" and it really boils down to the intentions of those behind those businesses and trust. And I can say that with NiM, that is me, and I've tried and will continue trying to do well by the trust that users give me by using NiM.

To stay focused on the issue of GDPR compliance, it's my understanding that no faults exist in that regard. I'd be more than happy to add even more notices where appropriate and deemed required.

Already in place:

• Chrome forces you to opt in before installing the extension.
• The code is open source
• I've even writing blogs about this issue which are open for anyone to read

@fhemberger have things changed with regard to how this is going to be treated moving forward?

[srl295]

Website folks: just a suggestion, would it make sense to put a disclaimer on the supported tools list? Something along the lines of, 'please evaluate the security implications and privacy policies of any such tools you install'. The Security section already discusses the general security implications of debugging tools.

[eyedean]

@srl295 That would just help to reduce the liabilities of Node, in case of a catastrophe.

The perception that people have around Open Source tools (Node.js included) is either it's free (as in freedom) and backed by self-interest/reputation-building/sponsors/donators, or their business model is very obvious to the users. (e.g. selling enterprise support, education, dual licensing, etc.)

For none of the packages I install via npm -i, I expect them to make money out of me in a non-trivial non-obvious manner, hidden in their ToS. Such chrome extensions fall into the same mental category to me.

All being said, whatever Node team decides, I respect. I just wouldn't feel great if I need to tell any fellow Node developer, who trusts Node docs, that "Hey, BTW, that chrome extensions is taking your email address and other stuffs and sends them to someone's personal server for their own business interests." And they would be literally shocked, I bet!

Thanks.

[srl295]

@eyedean if it makes someone pause and look at the fine print, that could be good. I hear what you're saying, however, node can't continuously privacy audit the contents of all linked sites, so I think the expectation has to be set correctly.

[ChALkeR]

As previously stated, I would prefer just avoiding recommending any browser extensions whatsoever. At least directly. That is a general position, it doesn't have anything to do with this specific extension in particular.

Browser extensions differ significantly from e.g. node modules or even vscode extensions (mentioned above) in a number of ways, and security implications of adding each new one to users setup is not limited to the possibility of the extension to be malicious or become malicious in the future.

[june07]

I've added a huge notice to the GitHub page and to the extension's web store page to help facilitate people not being "shocked" as @eyedean so eloquently put it, although I disagree with that statement in its entirety. Further I think it takes away from the project when the facilities in place were sufficient both from a common sense standpoint and from a legal one and from what was established previously when this issue arose. If that wasn't the case, I doubt @fhemberger and his team would have reinstated NiM?!

I would beg anyone to just look at the reviews of NiM and the utility of the tool before casting stones. It's grown from ~30k to ~35k users since it was removed from Node's site late last year and increased in it's rating to 4.49 out of 5. The Node community has shown more favor to NiM than not. No one is forced to use it. That entire doc page is about choice.

I don't think demonizing browser extensions is not the right course of action.

Further I think that if one simply looked at the facts, we wouldn't be having this discussion yet again. I'll say again, no changes affecting GDPR compliance have been made since NiM was reinstated nor would/will they be. A quick review of the history https://github.com/june07/nim shows as much. All I've done is add features to NiM, and to be honest analytics is on the low end of priorities, along with being something I'm growing fearful of even touching anymore because of this backlash.

We are beating a dead horse at this point. But I DO CARE and I'm trying to convey that fact to all involved. I feel that NiM fills a void that needed/needs filling, and it does it well. Further, it adds a lot above and beyond what is built in to debugging with Chrome or Chromium browser alone, as has been validated by the Chrome team themselves and NiM users.

Unless some new/unknown GDPR compliance issue is being made, can we please put this to rest (and preferably not by shooting NiM in the head). I think the nodejs team should stand behind the decision they made when they reinstated NiM in the first place. A lot of work went into both making the needed changes, AND in adding i18n to the node documentation.

Sweet dreams to all. It's 11:14 here in the Bay Area and the heat is finally gone. I hope I didn't offend anyone. And I wish everyone the best.

[bdharrington7]

Forgive my lack of knowledge around publishing chrome extensions, but as an aside, why is recording the email addresses of your users needed (as opposed to a uuid)?

If I were in your shoes I might consider it a liability. Given that data breaches are pretty much a daily occurrence now, not only do devs need to be good at developing software, but extra care needs to be taken to avoid opening security holes, whether your day to day includes security-related tasks or not.

[sam-github]

@june07 Your usage policy is pretty clear from https://app.termly.io/document/privacy-policy/04164179-f943-4e87-ac8b-5afd0367dc6c

We may use your information for other Business Purposes

You argue at length that this policy is reasonable and that most users of NiM are aware of it, and OK with it. That may be true, but I don't think its in the node project's interest to try to evaluate whether that is true or not.

People are welcome to find and use NiM if they wish, its not necessary to the node debug experience, and its not necessary for our debug guide to link to it. I think we should do as @ChALkeR suggests.

[WaleedAshraf]

I'd also go @ChALkeR suggestion.

I think doing analytics shouldn't be that important? Why not just remove it?
Second, as @eyedean said, it's going to some personal server, that doesn't look right.
Also, I don't know why not use UUID

[Trott]

I'd also go @ChALkeR suggestion.

I think doing analytics shouldn't be that important? Why not just remove it?
Second, as @eyedean said, it's going to some personal server, that doesn't look right.
Also, I don't know why not use UUID

I think it sends a mixed message to ask those questions if you agree with @ChALkeR. @ChALkeR's suggestion (which I also agree with FWIW) is to remove browser extensions from the list no matter what they are. Asking all those questions implies that if they are addressed, then listing it is OK. That's not @ChALkeR's suggestion. If we're not going to list browser extensions no matter what, then those questions are irrelevant and, more importantly, potentially frustrating to anyone who wants it listed, almost like the goalposts are being moved.

Person A: "OK, it switched to a UUID. Let's list it!"
Person B: "Sorry, we're still not listing it because it's a browser extension."
Person A: (╯°□°)╯︵ ┻━┻

[WaleedAshraf]

@Trott you are right. I have made it confusing. Updated my comment.

[june07]

@Trott it does feel like a moving goal post.

And I don't agree with the idea of exclusion based on the fact of being a Chrome extension.

Again demonizing Chrome Extensions specifically I don't quite follow. Speaking directly to this aversion to development with Chrome extension tools, these are a few that I'm sure more than a few have found to be useful:

• Postman Interceptor
• AngularJS Batarang
• React Developer Tools
• Vue.js devtools

?!

I'm not ignorant to the power of extensions and thus the possible abuse scenarios, but again, with great power comes great responsibility. The entire NPM ecosystem is powerful, and some would say dangerous, and as such we all respect that power and yet put it to good use.

I'm still waiting for @fhemberger to chime in to give some direction because he is who I largely interacted when this ticket was opened Nov 20, 2018. I think he would agree that I was patient during the process, I made numerous changes all at the request of others, and the PR to reinstate NiM wasn't merged until Feb 19th, 2019.

My own analytics server (why it's "suspicious"... I'm still at odds with?! Because it's my own domain and not a "name brand" one?) wasn't even one of the issues raised at the time, but I was sure to be thorough and do the work to ensure GDPR compliance was satisfied by including encryption code for any PII found in the NiM source. Initially I thought adding encryption code might take too much time, but ultimately found it to be pretty straight forward. This is all recorded in the Git history. Changes to PII handling/notices/etc were stable and untouched long before Feb 19.

Similarly to when this issue was first opened, inaccurate/incomplete information is being disseminated about NiM and certainly with regard to the timeline.

first @ea167 "This requirement was added recently", which was not the case (see the history).
second @eyedean admittedly being "new to the community" opening nodejs/node#28184, and NiM Chrome Extension is collecting user's email address #28185, even with the aforementioned changes in place and using phrases such as

• "look suspicious",
• "probably a great portion of the users are not aware" (which is not true because what user overlooks or misunderstands this?!:
  ...
  AND I've struggled with this from pretty early on)
• "I wouldn't trust this extension" (which is fair because it's his OPINION, and honestly I don't trust ANY code I didn't write or at least read, but I feel that in the context it's being used, it's unfair and maybe self serving)

Again, no changes have been made surrounding privacy issues since Feb 19, when it was clear enough at the time to all involved (including but not limited to @fhemberger @ChALkeR) that the PR was merged and the issue put to rest. Nothing was/is hidden. Nothing is a mystery or covert or "suspicious". Problem was solved. Everyone was happy.

One thing that has been bothering me is how quick certain individuals are ready to just blanket remove a resource from the documentation, at the occasional complaint from a few. I thought the Node.js community was concerned with inclusion and diversity, technical innovation, and contributions from a BROAD selection of contributors, and actively promote inclusive conduct. Let's keep that in mind as they are not my words but the words and ideals of the Node.js Foundation.

Maybe lets start asking what we can add to the Debugging Guide vs exclude.

And now, I bid you peace. The Warriors lost, but that's okay cause they're leaving Oakland anyway. Life moves on.

[Trott]

And I don't agree with the idea of exclusion based on the fact of being a Chrome extension.

For what it's worth, I just think we should avoid listing products/projects at all because it leads to exactly these sorts of problems. Some people think Project X doesn't meet whatever threshold is required in their mind, but other people think it's unfair to exclude Project X when Project Y is included. Additionally, there's the whole issue of ordering--whatever gets listed first will generate more interest than subsequent items. And there's the whole "recommendation is not endorsement, but everyone thinks it is" problem. Oh, and the potential we-have-to-update-the-list-all-the-time-as-things-come-and-go (but we don't update the guides much).

In general, I'd much prefer we link to someone else's curated "awesome" list and let them deal with these issues. Yeah, from time to time, we'll have to update the link to a new "awesome" list when the old one grows stale and unmaintained. But that's relatively easy.

All this is my opinion only, though, and as you have no doubt noticed, opinions vary on this. I also have the (unpopular, I think) opinion that most or all of the guides should be removed from the website. Those are more suited to blog posts hosted elsewhere. People will find them via search engines, and we don't have to deal with keeping them up to date (which we are spotty-at-best at). By having lots of unmaintained content, we damage the site's credibility. But again, a lot of people do not share my view on this and believe the guides to be of significant value as well as appropriate for the website.

[eyedean]

Again demonizing Chrome Extensions specifically I don't quite follow. Speaking directly to this aversion to development with Chrome extension tools, these are a few that I'm sure more than a few have found to be useful:

* [Postman Interceptor](https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcmcojjgiloacoafjmpfk)

* [AngularJS Batarang](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi/internal?hl=en)

* [React Developer Tools](https://chrome.google.com/webstore/detail/postman-interceptor/aicmkgpgakddgnaphhhpliifpcfhicfo?hl=en)

* [Vue.js devtools](https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd)

This is the manifest.json of all the 4 chrome extensions that you mentioned, where all the required permissions are listed:

• angularjs-batarang: manifest.json
• postmanInterceptor: manifest.json
• react-devtools: manifest.json
• vue-devtools: manifest.json

Can you please show us where, in any of these, user's identity (email address) is a requested permission?

None of these extensions are having "business interests" by collecting the emails of their users. I bet there are many recruiters and marketing firms that can pay a lot for such a list of all the active developers (to the minute, with their exact working hours, usage time, and what they are doing!) on a technology like Node.js in any company's email address (e.g. <developerName>@{netflix,trello,paypal,linkedin,walmart,uber,medium,groupon,ebay,nasa,amazon,digitalocean,oracle,intel,nokia,synamtec,target}.com -- list from this blog post.)

What bothers me the most here is, instead of hearing "Hey, this is my business model, and unlike all the other Chrome Extensions and NPM package, I'd like to make money this way," the effort is put on distracting people with words like "new to community", "diversity and inclusion", "innovation", and so on.

As I mentioned in my first post, you can remove (and clearly tell why did you need the email address as many people asked, instead of UUID) and I would become the biggest advocate of this Chrome Extension. Until then, I'd encourage you to stay focused on what matters, rather than personally judging and targeting the other members of the community!

[ChALkeR]

I'm not ignorant to the power of extensions and thus the possible abuse scenarios, but again, with great power comes great responsibility.

Sigh. Ok, long post incoming.

That's not the only problem with extensions.

Browser is the most trusted sandbox for the overwhelming majority of users -- they trust that when they click on a random link from a funny cat video, the advertisement on the linked site won't steal their banking details from the adjacent tab.

Now, each new extension erodes that trust. Even if the extension itself is not malicious and even if we trust that the developer won't make it malicious in the future (and the developer won't get hacked and won't translate the ownership to some business that would install spyware). Because new extensions increase the attack area.

That means that in a browser, the users should be protected not only from outright malicious extensions -- that's not the greatest problem. Extension installs are rare and follow trust to specific extensions, so no extension should normally be both popular enough to affect a significant number of users and be malicious at the same time (exceptions happen).

Website visits are frequent. User doesn't know what each website they visit does in background, and user doesn't even care in most cases -- and the reason why users have the privilege of not bothering with that is exactly because of the browser being the greatest sandbox, and it guarantees the visit to be safe, unless the user does something stupid (like download and install a binary -- but they get warnings while doing that). So, we should always assume that some websites are malicious, there is no way around that.

Now, there is a long history of not only malicious, but also vulnerable extensions:

• Evernote Chrome extension vulnerability allowed attackers to steal 4.6M users' data
• Adblock Plus Filters Can Be Exploited to Run Malicious Code
• Abusing Firefox Extensions -- a lot of those. E.g. Skype allowed automatic arbitrary number of calls to arbitrary phone numbers and skypenames, from any page.
• Severe vulnerabilities uncovered in popular password managers.
• LastPass remote code execution in trusted context
• Hola -- a stand-alone one, it's not just an extension per se, and it's hard to say that that was not a design decision, but it had (or potentially still has) RCE.
• ... many more, I just picked several ones

Extensions might be vulnerable in a way that allows malicious websites that the user visits to affect the extension that the user installed and attack it, abusing the privileges granted to the extension and extracting its data. Even if the extension is not "malicious" and the author is trusted by millions.

---

My point is: we don't have the power or time to review the extensions for being not only trusted to do nothing bad by themselves (which is also a question sometimes), but also for their security.

I would prefer if we wouldn't recommend any.

[tniessen]

I am fine with either not recommending any or putting up a disclaimer.

Regarding GDPR: From my perspective as an EU citizen (IANAL), the GDPR is covered by federal laws and if an extension violates the GDPR, the author can be sued, no matter whether they are EU citizens themselves or not. And even if they don't violate the GDPR, they still have to adhere to laws with difficult and cumbersome consequences (e.g., Article 15 and Article 17 of the GDPR) which might not be worth the marginal gain from obtaining user data. In this particular case, if email addresses are stored even after a user uninstalls the extension, that might violate Article 89 of the GDPR. Anyway, that is ultimately not our problem, so I am fine with either not recommending any extensions or adding a disclaimer.

[sam-github]

PR: #2259

[sam-github]

@Trott Truly a bit off topic, but wrt

I also have the (unpopular, I think) opinion that most or all of the guides should be removed from the website.

I can't comment on the popularity of the guides, maybe the website group has access logs? I personally look for the debugging guide every time I forget how to run the debugger!

[june07]

@Trott I would tend to agree with you, if this PR is merged.

The rules ("goalpost") SHOULD be the same for every organization and in that vein, let us remove every link to Inspector Clients including:

• Chrome DevTools (Google)
• Visual Studio Code (Microsoft)
• Visual Studio (Microsoft)
• JetBrains WebStorm (Jetbrains)
• Gitpod

[ChALkeR]

@june07 The first four don't seem to be browser extensions? The threat model is very different for those.

The last one is something that I am not familiar with. Does that link directly promote installation of browser extensions? If yes, I am all for removing that too.

Now, "Don't be a browser extension" is not sufficient to get into the list, obviously, even if we agree on not allowing browser extensions to the list. The question whether some of the other external links should be removed for other reasons is interesting, and I do not have an opinion on that at the moment.