NWJS phones home to Google - once again...

[Reaktive]

When I open the NWJS v0.22.0 with an empty .html file it tries to connect to Google (172.217.28.46). I've seen similar issues in previous versions but it seems that the problem is back.

Why is it a problem? The users that have a firewall installed may think that we are leaking some data when connecting to an external service that isn't related with our apps at all. Plus, I don't want to ping to Google simply because I don't like it!

Can we fix this without loosing connection to other external services?

EDIT: I've just realized that if I block that request I can't have access to any external resource, not even if it's located in an localhost server.

Thank you

[Christywl]

@Reaktive , how should I check this issue? Could you please provide a sample?

[Reaktive]

Well, you can check this out following these steps:

1. install a firewall software (I'm using Comodo Firewall)
2. download NWJS v0.22.0 SDK (running on Windows 7 64bit)
3. setup the manifest with the basic settings
4. create an empty HTML file as the main file (make sure that nothing is trying to connect with Google)
5. execute NWJS
6. the firewall will popup an alert telling you NWJS is trying to connect to 172.217.28.46

If you look at the WHOIS of that IP you'll find that it belongs to Google and if you open that IP in your browser it will take you to Google too.

I can give you a screenshot of my firewall alert but I guess that's pointless.. it's just an alert showing the IP and asking me if I want to allow that connection (if I choose to deny it, the firewall will block all my outgoing connections, but that's another case and it's related to the firewall behaviour).

[Reaktive]

There's an open issue related to this, but with a different IP..

https://github.com/nwjs/nw.js/issues/5343

That workaround won't work for me because I need to get external resources.

[Christywl]

Here is my result(Windows 10 64bit/nwjs-sdk-v0.22.0), I don't see the IP that nwjs is trying to connect:

package.json:
{
    "name": "test",
    "main": "index.html"
}

index.html is a empty file.

[Reaktive]

@Christywl that alert is asking you to allow the console to execute nwjs, once you allow that it should show another alert about NWJS trying to connect to Google.

You might want to set the firewall in "paranoid mode" or similar.. or it could allow some connections without asking.

After blocking too many times the IP I've said before now it's trying to connect to a different IP which leads to Google too ( 64.233.190.101 ).

Thank you!

[Reaktive]

@Christywl by the way, I can see you have checked the option that says something like "Remember my answer" at the bottom of the alert. That will create a rule in the firewall which will bypass alerts like that one. You should uncheck that option so you can do more tests.

Just to make sure you can see the upcoming alerts you should change the folder where NWJS is located. Maybe changing the folder's name is enough.

[Christywl]

Now I can reproduce this issue, it will open Google when I input the IP in the browser. Thanks for your detailed info.

[Reaktive]

@Christywl thank you for the feedback!

[ScriptKi77y]

I did some testing and it seems that upon the applications initializing, a query to http://clients2.google.com/time/1/current ... is created. Looks like it's a time synchronization function. Server responds back with something like: {"current_time_millis":1494189974246,"server_nonce":9.167813530900677E213}

I see I am not the only one experiencing this.

I can only get it to create this request when I modify the epoch time stamp value in the "Local State" file under "network_time > network_time_mapping > local" in the application cache folder.

[rogerwang]

I just disabled the network time query reported by @ScriptKi77y in git. Let's see whether there are any other queries with the next nightly build.

[rogerwang]

Will reopen if there are still queries to Google.

[jonwwilkes]

@rogerwang Can you confirm that the network time query is responsible for the following connections I reported on the other bug:

• 192.168.136:-11121 -> clients1.google.com 74.125.138.101:443
• clients4.google.com
• 74.125.21.101:443

[mcgi5sr2]

This is an issue for me again - v0.32.0-beta1 @rogerwang I pass --disable-sync --disable-background-networking --disable-component-update and it still dials out to accounts.google.com. I really need a resolution to this asap. Let me know if I can assist in anyway

[rogerwang]

Try --disable-gcm

On July 24, 2018 7:05:51 PM GMT+08:00, mcgi5sr2 [email protected] wrote:

This is an issue for me again - v0.32.0-beta1 @rogerwang I pass --disable-sync --disable-background-networking --disable-component-update and it still dials out to accounts.google.com. I really need a resolution to this asap. Let me know if I can assist in anyway

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nwjs/nw.js/issues/5865#issuecomment-407367871

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rogerwang]

Forget it. It's disabled by default.

On July 24, 2018 7:05:51 PM GMT+08:00, mcgi5sr2 [email protected] wrote:

This is an issue for me again - v0.32.0-beta1 @rogerwang I pass --disable-sync --disable-background-networking --disable-component-update and it still dials out to accounts.google.com. I really need a resolution to this asap. Let me know if I can assist in anyway

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nwjs/nw.js/issues/5865#issuecomment-407367871

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[GnorTech]

Fixed in the latest nightly build: https://dl.nwjs.io/live-build/nw32/07-27-2018/70081ef-b9056bc-704b564-9a0fb5b/v0.32.1/

[indexofrefraction]

2019-02-19, NWJS 0.36.2 is connecting to:

62.2.17.60, 62.2.24.162, 62.2.17.61 on UDP port 53 accounts.google.com on UDP port 443

there should be an option to suppress ANY network connection attempts specially accounts.google.com is a no-go!

[indexofrefraction]

nwjs.app/Contents/MacOS/nwjs --disable-sync --disable-background-networking --disable-component-update seems to work on macos, but how do i add this permanently to macos and windows?

[rogerwang]

@indexofrefraction thanks for reporting. Will see this. btw, you can add those to package.json: http://docs.nwjs.io/en/latest/References/Manifest%20Format/#chromium-args

[indexofrefraction]

@rogerwang: thanks, i can confirm that adding "chromium-args":"--disable-sync --disable-background-networking --disable-component-update" does work and prevents the unwanted connections

[Reaktive]

Guys, I don't know if you're aware of this.. but it keeps happening on new versions with a different IP.

[OrvGull]

I just wanted to note that this can be verified with Microsoft Message Analyzer:

Start a Local Trace (Message Analyzer must be running with admin rights) Click "Add Columns" In the right column click "Global Properties" Double-click "ProcessName" Right-click the new ProcessName column, choose "Group" Drill down to the nw.js app you're testing Right-click "Destination", choose "Group By Multiple Values".

It's not 100% perfect, it does sometimes misclassify things under the wrong process -- possibly due to race conditions involving local port numbers, I'm not sure.

[Reaktive]

Any news on this? I'd like to know how can I help to fix the issue (every time that's necessary).

I'd like to give a clean offline experience, as many other NWJS devs do.

As a firewall user, I find the alert box exactly like that.. like an ALERT (which I have to close every time I open or refresh NWJS).

If my app's users get this ALERT, I'd be worried about an "unknown" app trying to connect with an "unknown" IP.

Thanks!

[onlykey]

Seeing the same thing @indexofrefraction reported. A wireshark capture shows a DNS query to accounts.google.com and a response of an IPv6 address: Then this IPv6 address is used for gquic: Has there been any progress fixing this?

[indexofrefraction]

Hi,

here "silencing" nwjs seems to work when calling nwjs from the command line : nwjs.app/Contents/MacOS/nwjs --disable-sync --disable-background-networking --disable-component-update but it does not work (anymore) when using the manifest like this : "chromium-args":"--disable-sync --disable-background-networking --disable-component-update"

when altering the string to an array it seems to work again :

"chromium-args": [
	"--disable-sync",
	"--disable-background-networking",
	"--disable-component-update"
]

it would be nice to get a confirmation of this by other users...

[indexofrefraction]

and we are back to square one... the trick above worked for some time

but with nwjs 80.0.3987.149 we get connections again to:

62.2.17.60, 62.2.24.162, 62.2.17.61 and www.gstatic.com

[indexofrefraction]

ok, i checked it :

direct use of switches from the command line works fine!

nwjs.app/Contents/MacOS/nwjs --disable-webgl

setting chromium-args by manifest doesnt seem to work anymore!

"chromium-args": "--disable-webgl" or 
"chromium-args": [ "--disable-webgl" ]

[Porkepix]

We can still see calls to Google from project that rely on nw.js while having no needs of Google resources at all, see this screenshot from streamlink-twitch-gui for example

[jonwwilkes]

The only way I was able to solve this is to give a chrome arg for a proxy to 127.0.0.1 so that all these requests just get sent back to loopback. I tried using the IPv6 null addy but that arg apparently didn't accept ipv6 addys. (Maybe it does now.)

Of course I'm lucky because my application relies solely on the node.js part to do network-related activities.

Anyone know if Electron suffers these same problems?

[Reaktive]

The only way I was able to solve this is to give a chrome arg for a proxy to 127.0.0.1 so that all these requests just get sent back to loopback. I tried using the IPv6 null addy but that arg apparently didn't accept ipv6 addys. (Maybe it does now.)

Of course I'm lucky because my application relies solely on the node.js part to do network-related activities.

Anyone know if Electron suffers these same problems?

@jonwwilkes Your solution does work for Google's connections (and for an app that won't require external connections) but it keeps calling to IANA like it's been told in #6909