Remove links to 3rd-party tools with Privacy issues.

[june07]

Keeping with the spirit of the most recent privacy concerns raised, this PR is being opened to address additional privacy issues:

Gathering information about users is a real concern some of our consumers have.

1. Chrome DevTools 55+

Ignoring the obvious (like this #1 Google search result article), the Chrome DevTools has analytics baked into the code:
https://github.com/ChromeDevTools/devtools-frontend/blob/aa1532c2f8bdc37c9886255644ed90ad01c61c77/front_end/audits/lighthouse/template.html#L52-L56

Further upon startup following the instructions from the link:

Clone the repo
Go to repo root and run: npm start
This launches Chrome Canary and starts the dev server with 1 command

This is all of the content that is pulled from Google servers and more (survey.g.doubleclick.net, youtube.com, google-analytics.com, googleads.g.doubleclick.net...)

And the following test was verified on a freshly installed VM so I'm certain this behavior is the default. Because DevTools is so tightly integrated with Chrome the browser, privacy concerns related to DevTools should be considered at parity with that of Chrome itself... that is to say A HUGE ISSUE.

2. Visual Studio Code 1.10+, and Visual Studio 2017

Wide open issues on GitHub about telemetry data being collected by default, possible VSCode extension issues, etc.

microsoft/vscode#47284
microsoft/vscode#34503
microsoft/vscode#31891

3. JetBrains WebStorm 2017.1+ and other JetBrains IDEs

Whilst just installing Jetbrains, I'm faced with the following notice which basically tells me that my personal data is going to be used including my "email address". In fact I can't continue without accepting the terms.

4. Gitpod

Whilst just now trying to use Gitpod, I'm faced with another notice, requiring none other than my "email address".

Outside of node-inspect which is part of the Node project, chrome-remote-interface remains because no obvious privacy concerns were visible to me. However I will bring attention to this issue which I found rather timely/untimely, and I would caution the author of going down the extension route as it relates to the Node ecosystem.

The overarching theme here is that privacy issues remain with these other links, and as such they ought to be removed immediately and without delay.

[benjamingr]

This is just a link to a mirror from the Chromium repo which is what's being tested against the Node inspector. If we remove this we need another alternative "blessed" frontend and to run tests against it.

I think we should keep this in the docs for now since the two interconnected parts (v8 and the devtools frontend) are part of the same open source project (chromium) and v8 is a hard dependency of Node.

As an alternative - we might want to ship this.

[benjamingr]

This can be edited to recommend Chromium based and not Chrome though.

[benjamingr]

I agree it is not our place to recommend these tools so +1 on removing them.

[thom4parisot]

As an alternative, VSCodium is VSCode without the trackers.

[benjamingr]

Yes though why is it our place to recommend an IDE anyway?

[thom4parisot]

I don't know, but I thought the scope was about third-party privacy issues, not about not recommending tools.

[benjamingr]

I would keep DevTools and remove Visual Studio Code here

[tniessen]

@june07 I understand your frustration.

I agree it is not our place to recommend these tools so +1 on removing them.

@benjamingr The page does not explicitely recommend these third-party tools. It is a guide and as such provides basic information about the most popular debugging tools (which some would consider "industry standard"). I think our users / readers would benefit more from a disclaimer on said page than from us removing all of these resources and references.

[MylesBorins]

@june07 I believe that the decision in the last PR was specifically about removing all 3rd chrome extensions... for me the decision was not primarily about privacy but about the risks of installing chrome extensions themselves.

As such I think that perhaps removing gitpod, a third party extension to github, might warrant a discussion... but removing chrome devtools, visual studio, and jetbrains seems out of scope of the initial decision. (I recognize that I have a conflict of interest regarding google products).

Would it maybe make sense to split these up in to 2 different PRs so we can discuss the merits of the two types of cases separately?

[june07]

@MylesBorins thank you for mentioning this:

(I recognize that I have a conflict of interest regarding google products).

Splitting the PR would be to imply that the issue at hand is different for these other tools, which it is not. Regardless of the size/power of organizations behind said tools, the same Privacy concerns as raised only days ago should apply. And in fact should be more paramount now and here. Curious @MylesBorins to know why does removing gitpod “...warrant a discussion” to you?

The fact is that all of these tools are collecting user data and on a grand scale. Further due to their enormous reach into ecosystems outside of Node, the risk to user privacy is orders of magnitude greater. Unlike smaller tooling vendors where analytics/data collection stops when interacting with the specific tool stops, Google and Microsoft are able to continue probing the end user (developers) across products and outside of the scope of Node debugging. Key data points gained from their tooling sources (like DevTools and VSCode) while a developer writes code can easily be linked to other data points from the same developer long after works is done for the day and the debugger been ended. I could go on and on explaining this but we all know it.

The question is are we going to stick to these same principles now by merging this PR? The evidence is strait-forward, the PR has been generated, I don't understand why approvals are absent. Or does somehow different rules apply to you if your name is of a certain origin, or your wallet is bigger, or you're just more powerful...

I don’t see a benefit in splitting this PR and instead only see that doing so will serve to dilute the problem.

[MylesBorins]

@june07 I want to make it very clear that I only approved of the removal of NiM because I thought it was not a good idea to include any chrome extensions. The collection of personal data was not part of my decision making model nor did I claim it to be in the issue. AFAIK that was the reason why a majority of folks erred on the side of removing it.

Or does somehow different rules apply to you if your name is of a certain origin, or your wallet is bigger, or you're just more powerful...

I don't believe that making claims like this are operating in good faith and TBH makes me take pause at continuing to engage in this issue at all. I've done my best to outline the decision making model and suggested splitting up the PR so that we could discuss removing things on two separate merits. 1) removing extensions which could have elevated permissions and 2) removing tools that collect personal data.

[Trott]

I'm in favor of any of the following:

1. Removing all the listings just because we shouldn't be in the business of picking winners among competing projects.
2. Replacing the listings with one or more links to external guides to these things.
3. Adding a disclaimer about how listing something in this guide does not constitute endorsement.

I am opposed to doing anything to this list on the supposed grounds of privacy. That's not why NiM was removed.

So, as such, I'd be in favor of removing some or all of the things removed in this PR, but I'm opposed to this PR because I do not want to give any air to the idea that NiM was removed over privacy concerns, even if it was privacy concerns that initiated the conversation that eventually resulted in its removal.

[june07]

As has b een explained multiple times, it's not why NiM was removed
it was privacy concerns that initiated the conversation that eventually resulted in its removal.

Feels like

(╯°□°)╯︵ ┻━┻

Regardless, as clearly titled, this PR is about

3rd-party tools with Privacy issues

which happen to make up the healthy majority of concerns raised about the 3 letter project you both mentioned.

The same one that exists and existed as an extension (since inception 3 years ago), an unchanging truth.
A fact that has never stopped it's growth, nor it's being mentioned favorably by:

, nor it's inclusion in the docs. And the one that still proves to be useful to many as it's growth has been a testament to.

But again, this PR isn't about that tool. I read okay and there is no confusion about the title
Remove recommendations of Chrome Extensions. I refer to the tool because you both mentioned it by name. It is about the train of thought, concerns, and logic that happened to be used in railroading that other tool.

Again, to be clear, this PR is about "Privacy issues". @ea167 @fhemberger @eyedean @cjihrig @sam-github If those concerns were true to heart and not contrived, this PR should be of concern to those same individuals and ultimately to the Node community that they represent. This PR is about those same issues. @MylesBorins My intent is to continue operating in good faith as I have. If expressing my opinion, or questioning things that I don't understand counts as anything other, I'm sorry, and I do hope you continue being a part of the dialog. As an agent of Google, I'm sure you can offer incites that others cant. For example, why

it was not a good idea to include any chrome extensions

when the whole extension API/ecosystem was in fact built by Google. And as I have pointed out, many developer extensions exist, very popular ones in fact. Seems Google just launched a new extension, so is your opinion in line with Google's or your own? And further the question previously posed:

why does removing gitpod “...warrant a discussion” to you?

The PR doesn't need splitting because the issue is a singular one at this point. That of Privacy. That's been on the forefront of the discussions, let's keep it there, and focus on how the same concerns previously raised are entirely relevant to the tools at hand.

[MylesBorins]

@june07 to be very clear, I am not acting in this thread as "an agent of google". I am acting as a maintainer of the nodejs.org project, who is the group that makes decisions within this repo. My opinions regarding plugins do not reflect those of Google's and tbh you bringing that up as a discussion point makes me slightly uncomfortable engaging in this dialogue.

I'm going to choose to not participate in this thread because I don't believe that I can do so in an unbiased fashion and that I'm likely to quickly get defensive.

[othiym23]

Hello, there! Member of @nodejs/moderation here!

I appreciate that there are some legitimate grounds for dissatisfaction here, and that there may be some distrust and raw feelings at play. That said, the language is starting to feel pretty charged and it seems to me that there’s a certain amount of doubling down on tightly held positions that is veering into a counterproductive kind of engagement. Can everyone take a step back and breathe a little? I think it’s worth discussing @richtrott’s three bullet points further.

(I take no position on the merits of this PR; I’m only interested in helping to keep the conversation moving and constructive.)

[tniessen]

@Trott

1. Removing all the listings just because we shouldn't be in the business of picking winners among competing projects.

I still don't think this would benefit our users. From my perspective, we maintain this list because we believe that these tools are objectively good and the most popular across the Node.js community, each probably having millions of users.

2. Replacing the listings with one or more links to external guides to these things.

This seems to rephrase the issue instead of solving it: Which links do we include? How do we decide whether a link should be added or removed? Websites can collect personal data as well, privacy issues remain.

3. Adding a disclaimer about how listing something in this guide does not constitute endorsement.

This still seems like the most reasonable choice to me.

---

@june07

I understand that you might think it is unfair that these projects are treated differently than your own project. As long as we don't have a fixed set of rules to go by, the only option appears to be to base our decisions on a certain amount of trust towards the tools. This is subjective of course, and based on previous comments I understand that someone might prefer not to be part of the discussion. We are not trying to argue against you, we are trying to achieve what we consider to be best for everyone. Anyway, here is my analysis of the problem (but IANAL):

I disagree that collecting personal data is a privacy issue by itself. Not properly informing users about it, that is a privacy issue. So assuming what your project did was actually a GDPR violation, then it was a privacy issue. Under the same assumption, it might even have been unlawful and a criminal offense in some countries.

We tend to trust corporations with personal data since we believe they are bound by laws and regulations, and that any small mistake would have vast consequences. If one of these had sent email addresses back to their servers without mentioning that to the user, they couldn't simply pretend nothing had happened and they couldn't just change the description. Privacy violations by corporations usually result in lawsuits and financial losses, and that's why we tend to assume that safeguards are in place to prevent that from happening. The fact that you "fixed" the potential privacy issue only after we had to step in indicates that such safeguards do not exist in a sufficient manner for your tool. And sure, you can still be sued for violating people's privacy, but that's not our goal, we are not looking for legal disputes.

[june07]

@tniessen And my disappointment continues to grow. But I'm still taking a breather at @othiym23 suggestion. Everyone have a great weekend.

[june07]

@tniessen

The fact that you "fixed" the potential privacy issue only after we had to step in indicates that such safeguards do not exist in a sufficient manner for your tool.

This logic is broken. The fact that any potential privacy issue was addressed and resolved in short order, in part demonstrates the virtues of OSS and the communities (when working together) that lay the foundation for it. To imply that the NiM project or I am alone in that regard (of being notified by others of potential issues) shows a lack of good sense or judgement on your part. And to disseminate that broken way of thinking to others even more so. The Internet is littered with examples of 3rd parties stepping in [Fortune 100 companies] to bring attention to potential privacy issues.

Further, in today's litigious society, I could be sued for just about anything but I choose not to let it paralyze me and instead I operate with integrity. The fact you felt the need to say this is telling:

And sure, you can still be sued for violating people's privacy, but that's not our goal, we are not looking for legal disputes.

I think that there's actually a problem with this herd mentality and naive way of thinking:

We tend to trust corporations with personal data since we believe they are bound by laws and regulations, and that any small mistake would have vast consequences. If one of these had sent email addresses back to their servers without mentioning that to the user, they couldn't simply pretend nothing had happened and they couldn't just change the description.

1. Google

1. Google, plagued by data and privacy issues, still rakes it in
2. Goodbye, Chrome: Google’s web browser has become spy software
3. Google Confirms Creepy New Privacy Problem

2. Microsoft

1. Microsoft menaced with GDPR mega-fines in Europe for 'large scale and covert' gathering of people's info via Office

These "corporations" that "we tend to trust" do it all the time, period. To suggest otherwise is misguided to say the least.

Finally, I hate that it seems like I'm picking on Google and Microsoft because I've always been of the opinion that if you don't like something, don't use it. I choose both to use and to not use products from each of these companies.

The primary reason I'm pushing this PR is because I also believe in acting in a fair manner and on a level playing field, specifically as we're speaking about the tooling of Node, and of course considering the treatment my own tool has seen by the Node organization as of late. It seems to me that either many of the views expressed previously with regard to privacy and other tools be deemed invalid or we apply that same logic to EVERY other tool listed in the docs, and as such, approve this PR to remove said links.

[XhmikosR]

@Trott @cjihrig @MylesBorins isn't this obsolete?

[Trott]

@Trott @cjihrig @MylesBorins isn't this obsolete?

I'm going to close it, but it can be re-opened if OP (or anyone else) wants to rebase to get rid of the conflicts, etc.