Reinstate link to NiM in debug documentation.

[june07]

As no response has been received to #1908 since nearly a week, I am opening this issue.

@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

https://chrome.google.com/webstore/detail/nodejs-v8-inspector-manag/gnhhdgbaldcilmgcpfddgdbkhjohddkj

[MylesBorins]

/cc @nodejs/tsc

[MylesBorins]

As this has to do with potential legal stuff it may need to be surfaced to the foundation for guidance... but lets see if we can reach consensus within the TSC first

[june07]

Thank you again, Myles, for nudging this.

[mcollina]

I'm fine in having that link in.

[june07]

Not sure my messages were going thru on https://www.youtube.com/c/nodejs+foundation/live. I will submit a PR for the change.

[ChALkeR]

I would prefer not recommending any browser extensions, for security reasons.

[gabrielschulhof]

Perhaps we should keep it generic and mention that the Chrome Web store provides additional tools that help with debugging. We can even add a link with a keyword search that would bring up NiM, but would also bring up other extensions that satisfy the keywords. Nevertheless, if NiM were the first of many such helpers and would be closely associated with the keywords it would, at least for the beginning, be the first search result. We can then maybe tune the keywords to keep a sufficient distance between making a specific recommendation while allowing other tools to show up as they are being developed, and being too generic.

[ChALkeR]

@gabrielschulhof that seems ok to me, but imo we shouldn't actively promote the usage of browser extensions for this task. A note that those exist (without explicitly calling people to install those, and without linking to any specific one) would be fine enough in my opinion.

[june07]

I sort of get the hand waving and wide eyes about "browser extensions" and "security reasons" by some but in all fairness, as developers, I think we are held to a slightly higher level of sophistication as it relates to understanding how to stay safe. Using that same safety paradigm, should we pull all references to any Inspector Clients from the debugging-getting-started page?! After all, we are all aware of the NPM "security" issues of late, and I am safe to say that a full-on executable has much more ability to wreak havoc on a system vs a Javascript sandboxed web application. NiM wasn't even listed as a primary option but rather a sub-option to Chrome DevTools, a very suitable place for it. Of course, we shouldn't remove listings to other Inspector Clients. If anything, more should be added if they are deemed as helpful as NiM has proven to be (see the rating/feedback). Many have asked or commented on the fact that they wished they had found NiM sooner!

This conversation seems to be diverging from the initial issue (privacy policy). The issue was resolved over two weeks ago. And now it would be great to reinstate the URL.

[june07]

@nodejs/tsc has delegated the issue back to the web working group. Apparently that was the wrong place to surface this issue. Can someone from the wwg chime in please. @fhemberger

[mhdawson]

This was discussed in the TSC meeting this week: Consensus was that it is not the time to escalate to TSC and let website team lead the discussion, reach a discussion.

[MylesBorins]

Reopening as I don't think that this issue needs to be closed

[ChALkeR]

Yes, I believe that closing it was probably accidential.

[fhemberger]

(First of all sorry for the delay in my answer. It was Christmas time after all and I've been busy like the rest of you, I guess.)

I'm still strongly opposed to add this extension back to the list of recommendations in its current form.

For the record again, the email address of the user (taken from the Google account used to install the extension on Chrome) is sent every second to Google Analytics.

There is no need to collect personal data for the extension to work, and this can be considered a violation of the GDPR.

To sum up the arguments you brought up against this so far:

• "We added a visible link to our privacy policy, which the user accepts with downloading and using out extension." – That's a good thing, although the privacy policy mixes use of your website and the app. And it doesn't inform the user about the email collection.

• "We want to collect the data to maybe contact the users in the future" – as @oncletom already stated before, GDPR is about being given consent by the user. So if you want to collect data not required for using this extension, it has to be explicitly opt-in.

  If you just wanted to have statistical data about the daily usage of your extension, there'd be other options (like using a hash which can't be used to personally identify the user).

• "Other companies are doing things much worse." – sorry, but I won't even discuss this statement.

Now, if those changes are made I'd be willing to reconsider my position.

---

At the same time, we're already discussing more broadly in #1932, #1963, #1964 and #1965 what kind of third party content should be collected on the Node.js website at all (also making sure that it doesn't mean this content is promoted/endorsed by the Node.js Foundation in any way).

/cc'ing @Trott (who rose two of the issues mentioned above) and @amiller-gh (as this is also relevant for @nodejs/website-redesign).

[june07]

So in the name of (... Greyskull?!), I've removed the emails from Google Analytics. My initial thought was to encrypt the data but ultimately the extra work isn't worth it to me. I don't profit from this and honestly, it's just not worth it to spend any more of my time on it.

Please see the PR I merged into my own code base. AS WELL, I've pushed an updated version to the Chrome Web Store that tracks the change.

That should kill all the friendly birds with just one stone! Cheers.

[fhemberger]

Waiting for the PR to land, closing this.

[eyedean]

Well, it seems like the "Sending Email to Google Analytics" which was removed in December apparently, is back as of 29 days ago and it's currently in master: https://github.com/june07/NiM/blob/master/background.js#L151

We should probably edit the docs and mention that this is still happening and it's a recurring issue that apparently comes back!

@fhemberger shall we reopen this issue? (I just discovered this problem in nodejs/node#28185 a few hours ago on my own, and @joyeecheung guided me to here.)

PS. A friendly note to the author of the plugin: Your great work is much appreciated. But as I suggested in my own ticket, maybe replacing the email address with a randomly generated UUID, stored in the client-side for your tracking consistency, can make everyone feel better. :)

[fhemberger]

Thanks for reopening, let's discuss matters over there.

[june07]

Please note that encryption was added per the GDPR requirement of google and was accepted as a solution to the complaint way back when this issue arose the first time. No changes have been made specific/surrounding this issue since then. Please note that. This is in no way some attempt to sneak anything past anyone. I'm still going thru the code but I saw this and wanted to address it asap.

…

On Wed, Jun 12, 2019 at 3:25 AM Frederic Hemberger ***@***.***> wrote: Thanks for reopening, let's discuss matters over there. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1923?email_source=notifications&email_token=ACWT35VSVL35QNAVZ5KRNBTP2DFHXA5CNFSM4GH47CE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXP6QOY#issuecomment-501213243>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWT35SBV7TXMVLCXBQJXZDP2DFHXANCNFSM4GH47CEQ> .

[june07]

Again, just as last time someone raised a concern about this code issue, it is/was nothing NEW. 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. The extensive GitHub history shows every action I've taken including adding notices, encryption, and removing things. The steps I took back then were validated when after MUCH time (and I can only assume --inspect ion of the code changes) NiM was reinstated. I think I said it before, but there are no nefarious things going on. I really hope the solution this time is not simply chopping the head off and instead if there is still a VALID issue, that it be addressed and I am willing to make MORE changes to move in the direction of the greatest good. If the solutions that were good enough back then are no longer good enough, or there is some problem with the encryption scheme I implemented... please let me know. #1908 nodejs/node#28185

…

On Wed, Jun 12, 2019 at 8:47 AM 667 ***@***.***> wrote: Please note that encryption was added per the GDPR requirement of google and was accepted as a solution to the complaint way back when this issue arose the first time. No changes have been made specific/surrounding this issue since then. Please note that. This is in no way some attempt to sneak anything past anyone. I'm still going thru the code but I saw this and wanted to address it asap. On Wed, Jun 12, 2019 at 3:25 AM Frederic Hemberger < ***@***.***> wrote: > Thanks for reopening, let's discuss matters over there. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#1923?email_source=notifications&email_token=ACWT35VSVL35QNAVZ5KRNBTP2DFHXA5CNFSM4GH47CE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXP6QOY#issuecomment-501213243>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACWT35SBV7TXMVLCXBQJXZDP2DFHXANCNFSM4GH47CEQ> > . >

[eyedean]

Let's centralize our conversation in #1908. Thanks.