Homepage    |    Wiki    |    GitHub    |    Twitter

New version of Joplin contacting Google servers on startup

I just updated to Joplin 2.6.1.0 from 2.1.7. Now everytime I start Joplin it attempts to contact a server:

redirector.gvt1.com

According to this article: What are these suspicious Google GVT1.com URLs?

The GVT in the gvt1.com domain stands for Google Video Transcoding, and is used as a cache server for content and downloads used by Google services and applications.

I use Joplin as a secure note taking application. Obviously I would prefer not to contact Google every time I open Joplin. Why is Joplin contacting Google servers when it is launched? What information is being sent to Google and what Google services and content are being downloaded?

Finally, what are the privacy and security implications of this? None of the previous version of Joplin exhibited this behavior.

3 Likes

What operating system?

The version where i noticed the behavior is Linux, specifically:

KDE Neon 5.23.5 which is based on Ubuntu 20.04 LTS (focal fossa)

I have run probably 20+ version of Joplin on this platform and never saw (or expected to see) this network activity until I upgraded to Joplin version 2.6.1.0 just today.

As always, I upgraded with the recommended script:

wget -O - https://raw.githubusercontent.com/laurent22/joplin/dev/Joplin_install_and_update.sh | bash

I also launched a new profile with all defaults to troubleshoot and verify that every time Joplin starts is tries to contact those google servers:

.joplin/Joplin.AppImage --profile ~/test

I was surprised to see this network activity because according to the privacy policy:

The Joplin applications, including the Android, iOS, Windows, macOS and Linux applications, do not send any data to any service without your authorisation.

1 Like

It is nice (to have) to find an article which indicates ... that probably ... Electron ... (or sth else) ... does ... most likely (or not) ... only download ... not upload (or not) .... sth and not sth else.

But I think a security conscious (and critical) application like Joplin has to give its users the option to turn any access to third party servers off. If the culprit is really a dictionary access of Electron, fine - give me a way to disable this. If it's a gihub backup server, let me disable it. If this cannot be done, then make that very clear, list ALL servers, their use, and access on the Joplin homepage.
This way users can think about what data they entrust to Joplin BEFORE such concerns come up upon the next Joplin update.

I have recently complaint on this board about other sites which a new Joplin version all of a sudden wanted to connect to ... with no explanation, ... out of the blue after update. I think not enough care is given to such changes.

2 Likes

We probably don't but I wonder if we do have a security expert in our community. The scope of the security tasks (described above) could certainly amount to a GSoC project but with no clear mentorship, the result might be just as unclear.

So far, I haven't seen a large interest in security documentation and analysis from the community, however, just in case it wasn't representative, it could be useful to see if there's, indeed, enough demand to possibly chip in for a professional security audit or GSoC spec/mentorship.

For the information, here's the result of previous informal security audit:

However, it doesn't say anything about contacting remote servers.

For linking sake, here's a fairly recent, similar discussion

1 Like

Isn't that a bit unfair though? We have a privacy policy where we list all the external requests that Joplin makes, and we offer ways to disable them. We frequently spend a lot of time discussing how to best implement these options. By the way, all of these are purely to support features, there's no tracking.

In that particular case, we need to do this:

  • Update the privacy policy and mention that request
  • Create a GitHub issue to investigate if that request can be disabled

I'll probably do all that myself as always, because some people like to get on their high horse when it comes to privacy stuff, but when it comes to actually research the issue and do something about it there's no-one around.

10 Likes

I bet you anything that some of these "privacy conscious" people for whom Joplin is such a "critical application" that they demand a "security expert" to be hired never spent a penny in donations or funding Joplin.

Sorry if I sound cynical but honestly, there are too many Karens around these days! (With apologies to people whose actual name is Karen) :wink:

6 Likes

No need. I never saw this request because I never enabled spellchecker.

From an Electron perspective there is no way to disable it (except not using the spellchecker), but we can point it to a different server. The spellchecker needs a dictionary after all. The question is who wants to host dictionaries that are downloaded a gazillion times and generate massive traffic?

3 Likes

Actually, if you're on macOS, it won't download that file and use instead the OS built-in dictionary.

We could create an issue anyway and link to it from the privacy policy, like we're doing for the mobile network check. That way we can provide more info, as well as mention what you just wrote. Then if someone wants to improve this at some point they have all the details.

4 Likes

There is still a need to deal with the issue. I have never use the spellchecker either. The leak happens regardless of if the user has enabled the spellchecker or not. I tested with a new default profile. The spell checking is not enabled by default (Tools->Options->General->Enable Spell Checking in Markdown Editor) however the Google servers are still being contacted every time Joplin is started.

There is no notice given unless the user checks the traffic being generated by Joplin in a application firewall log. This makes the issue even more problematic because most users will be unaware that Joplin is contacting Google servers on startup, especially with the current privacy policy that states the Joplin does not do this.

I agree with laurent, at a minimum and as a stop gap measure the privacy policy wording would need to be updated to bring Joplin back in compliance with the policy.

As a more medium term solution, perhaps the code can be updated so that these dictionaries are only downloaded or updated when the user specifically activates the spell checking feature from the settings above. This would be more of an opt-in action. Also, a description can be added to this setting page under this checkbox that explains the privacy implications of activating this feature and so the user is given fair warning.

I do think this is an issue that deserves our attention as one of the appeals of Joplin is a private and secure notetaking app. In fact, it is listed as one of the only two recommended digital notebooks on Privacy Guides: Notebooks | Privacy Guides.

A privacy orientated notetaking app that sends information to Google every time it is started has real privacy implications.

As I was saying, I don't see these requests. I've just tried with dev HEAD. I will try again in the evening.

But I agree that the policy doc has to be updated. But I only replied to the other item Laurent mentioned.

Update:

Ok, I'm on macOS. In this case we have to open an issue.... A framework should not be sending out requests by default, unless there's a global option for this.

I agree, especially considering that Joplin can be used as a very capable stand alone offline note taking app without using any of the syncing capabilities. In this use case, there would be no expectation that Joplin will be leaking data to Google by default.

Now I understand why your first questions was to ask which platform. Do we know which platforms are affected? It sounds like Linux is effected while macOS is not. What about Windows, ios and Android? Have any users of these platforms observed or reported the leak?

Also, can we assume that this issue started when Electron was upgraded? Electron was upgraded from v10 to v14 in v2.5.1, did it happen here?

Indeed 'some' as you say. :wink:

My 'privacy consciousness' stems from being responsible for dataprotection and information security policies for a school. As a consumer I ungoogle and unmeta as much as possible.

Hence my Joplin Cloud subscription to support this app.

I do agree that 'demanding' a security expert isnt in the spirit of this community tho.

I agree that demands on community based open source project are ineffective and issues should be approached constructively however earlier comments with pejoratives and discussions of donations are a bit off topic for the purpose of this thread.

There is a specific data leak to Google servers in the default Joplin application on at least one platform (Linux) that appears to have been introduced by an upstream project (Electron version 14?).

The effect causes a conflict with the privacy policy and remove the user's ability opt-out (or even better, to opt-in) to this data collection.

Let's focus on understanding the scope of the issue and what can be done to mitigate and come up with solutions.

In this spirit, I did some preliminary testing with the Android app (v2.6.9) and I do not see any pings to Google servers. On a fresh install of Joplin on this platform I do not see any external data activity when Joplin is launched which is what I would expect.

Does anyone have an ios or Windows devices to test?

FYI it isn't 'Electrum' it is 'Electron' which is the framework the desktop apps are built on - therefore if it is an Electron specific issue then it won't be found on the mobile (react-native) or CLI applications.

Incidentally I've been faffing around with wireshark and a few other tools on Windows trying to see if I can see these network requests to the server listed in the first message and I can't see anything however I've never actually attempted to analyser network traffic this way round (i.e. monitoring traffic for a specific application vs tracing packets made to a very specific local IP) so if anyone has a more foolproof method then I'm all ears.

1 Like

Thanks, updated.

Good to know, also I completely forgot about the CLI version, isn't Joplin amazing?

So then it depends on how Electron handles this dictionary issue.

So with this understanding, is there an opportunity to make this dictionary download an opt-in feature for the users that need it rather than doing so by default?

From the change log it looks like the spell check feature in Joplin was implemented long before the more recent Electron upgrade that is causing this issue. This is assuming that upgrading Electron introduced the issue. I know that when I upgraded from 2.1.7 to 2.6.1.0 I saw the activity right away whereas I never saw it in any previous versions.

How was it done in the past?

The specific documentation around the spellchecker in electron is here if you want to review.

Thanks for the link. Two things come to mind:

Electron has built-in support for Chromium's spellchecker since Electron 8

So I do not see any data leak with Joplin version 2.1.7 and according to the Joplin log, we were using Electron version 10. So the issue was not present in earlier version of Electron.

Idea #1:

According to this:

By default Electron will download hunspell dictionaries from the Chromium CDN. If you want to override this behavior you can use this API to point the dictionary downloader at your own hosted version of the hunspell dictionaries.

If the files present in hunspell_dictionaries.zip are available at https://example.com/dictionaries/language-code.bdic then you should call this api with ses.setSpellCheckerDictionaryDownloadURL('https://example.com/dictionaries/')

So would a solution be to call this api with a dummy URL by default and to call the api again with either an alternate URL or the google one once the user has activated this feature? This would at least allow the user informed consent.

Idea #2

Here is another potential solution, according to this page:

For Electron 9 and higher the spellchecker is enabled by default. For Electron 8 you need to enable it in webPreferences .

const myWindow = new BrowserWindow({  webPreferences: {    spellcheck: true  }})

So could Joplin set spellcheck: false by default then set spellcheck: true, after the user activates the spell check from Joplin's settings: Tools->Options->General->Enable Spell Checking. This would also allow for the feature to be opt-in.

I don't know if these solutions are possible from a coding point of view but if the second one is it seems like a potentially simple and promising fix.

1 Like

Most unsolicited outgoing connections in Windows are for GitHub (update off, with plugins but also without).

My “method” (No foolproof sorry :grin:) for advanced users there is a nice open source firewall with packets log here on Windows.

So far I haven’t seen http://redirector.gvt1.com (spellchecker on)

1 Like