New version of Joplin contacting Google servers on startup

I use Joplin because its privacy focussed. I trust Joplin would not directly transmit my note contents to remote servers without my knowledge unless venerability has been exploited in my OS or Joplin. Without its focus on privacy, Joplin will lose its unique value to me and many others. The people arguing that Joplin should not prioritise privacy because it only serves a small user base, are making a seemingly sound, but destructive argument. While people who use Joplin because they like its editor can use Evernote with slight annoyance, people who want privacy will have very few to no options. Just because you do not want privacy now, does not mean you won't want it later on.
Should Joplin focus on 'what the userbase wants?' with guesstimates of what percentage of user want something or maintain what it has to offer more uniquely than other projects?
Privacy is not just a bonus, its a matter of ethics as far as software development is concerned. Should you allow Google to collect risky amounts of data as it might threaten our freedom in the long run, irrespective of whether people care or not? Just because people do not care, does not mean they should not care, does not mean that their demands, no matter the percentage demanding, should not be considered valid and worth catering to? For example, ramps for disabled need to built, despite the percentage of people benefitting from them is very small. Should not the people who care be ready with options for when the public becomes more cognizant of the importance of privacy?
However, the more important point is whether these calls to Google Servers are a privacy risk or not, and if they are, to what magnitude. The privacy risk level corresponds to the sensitivity of information that can be deduced with the help of data collected. Here it is important to know what data is being sent and can the user verify what data is being sent by looking at the code? What is the potential maximum amount of data being sent if the data being sent cannot be verified from the code? Can it included note content or not? As for trusting the devs, in this line of buisness, paranoria is not always unjustified. What is the possibility of underhand deal to quitely siphon off data of your privacy focussed app. Not saying anything like that is going on, but is there any way to properly put this beyond the realm of possibility without an analysis of what data is sent and to whom? The data of those seemingly looking for privacy is of great value. Having said this, I will like to state that I highly value all the work that has been done with Joplin and I respect and admire the dev(s?) and contributors very much I stated that possibility not to throw shade on wonderful people but to achieve clarity about what people might be worried about so that an adequate solution might be found.
Beyond just the reality of privacy, there is also the mental comfort level. Many people are paranoid, as they are not able to calculate the actual risk posed to them by Google data collection. They just want to feel safe. Sometimes feeling safe can also be very important. So, if it is assessed that Google server calls are not a substantial privacy risk, that assessment needs ideally to be available either in form of a pinned post or
a section in the privacy policy. This will give people a ready reference each time they feel challenged on privacy aspects of Joplin. All this panic over Google server calls might just be down to lack of knowledge about how software works. People like me feel helpless in a software infused world, with no concrete idea what reasonable limits of something might be.

5 Likes

I don't hear people making this argument at all. The original complaint is that Joplin is making a call to a Google server. This may have something to do with secrecy, but it has nothing to do with keeping the user's data private. The argument is simply that if you need that level of control over what your software does to external servers, then you need to be using some other kind of protection.

I think this is very true. It's fine to care about server calls to Google. It's not fine to equate this with the devs being irresponsible/deceitful and sharing user data.

2 Likes

Did we read the same thread?
However, I do agree, that if the data being sent to Google is of low value, than its unreasonable to expect devs and contributors to go extraordinary lengths to stop it from happening.
Relying on third party firewall tools is a good idea to help maintain privacy in general.

1 Like

Where did you get the impression that Joplin's focus on privacy has changed? In fact, Laurent basically said the opposite, with what I think a very sensible compromise:

1 Like

That was exactly the point. No data is sent to Google servers. A GET request is made to download a dictionary. As with all requests, certain information is most likely logged on the server (IP address, user agent string, URI).

In my tests (on Linux) I just turned off spellchecking and no requests were made.

I think that the default settings should be changed.
On the other hand I also get Laurent's statement.

I even removed the spellchecker icons from my UI on my macOS machines. But I am most likely not a good reference point anyway, because I use multiple security layers.

1 Like

A post was split to a new topic: Security Layers

This is my view too. I'm not worried about the metadata that Google will capture in a single GET request. I think the talk about what other secret information could be transmitted in SSL is a bit overblown. The software making the request is open-source. It wouldn't be too hard to open up the requests if someone really wanted to.

For me, Joplin is about keeping my data private, rather than my existence. I'm sure Google already knows a lot about me just from ads. Adding the single data-point that I use an Electron app isn't much more. If the text of my notes was being uploaded for spell-checking, that would be diffierent.

6 Likes

I host LanguageTool myself GitHub - Erikvl87/docker-languagetool: Dockerfile for LanguageTool server - configurable

Is there a way to use it in Joplin so that the user does not ned to rely on external stuff given the user hosts her own language tools?

This came up on Hacker News yesterday and it seems relevant to the discussion here: GDPR penalty for passing on of IP address to Google by using Google Fonts | Hacker News

(I don't read German so this is based on comments on HN) A company has been fined for GDPR violation because it used Google fonts on its website and it caused client's browsers send a GET request to Google servers thus leaking IP addresses.

I think this Google translation of a news article is quite good: LG München: Einbindung von Google Fonts ohne Einwilligung (look at 5., 6. and 7.)

As @roman_r_m already said a German website used Google Fonts and has to pay 100€ in compensation to a user. Its important to note that there was no opt-in option. Google Fonts where loaded automatically and therefore the IP address was transmitted automatically. GDPR allows providers to claim a "legitimate interest" to transmit certain data, but it is easy to use local fonts on a web server. So there is not legitimate interest to use Google Fonts. Therefore the company has to pay compensation to the user.

Its the first instance so an appeal to a higher court is likely. Moreover it is just one district court. Only time and more lawsuits will tell if using Google Fonts is a GDPR violation. The court decision deals only with Google Fonts, not with YouTube embeds, Adobe Fonts, Hunspell or any other form of external services. So this decision does not have a direct impact on Joplin.

But it shows where we are headed in Germany/EU (and other regions that introduced similar legislation) IP addresses are personal data, therefore protected by the GDPR. So "simple" GET request are a GDPR violation, certain exceptions might apply.

I personally think you cannot compare Google Fonts and Googles Electron CDN, because you cannot add every dictionary to a Joplin release. But perhaps users have to opt-in before Joplin makes a connection to a Google server could be required.

(I am not a lawyer, so I am just guessing based on my experience with german courts in the past.)

I wonder if that applies to open source software though. It's under MIT license and no guarantee of any kind is provided - that's what the user agree on when they download the app. So if the author of such apps can be fined then it means the MIT license means nothing, and you can be fined and sued left and right for any little thing.

Likewise if you run curl https://google.com should the author of curl be fined because it turns out that Google is keeping the ip in their log? You might say you ran this command yourself, but with Joplin it's the same, you downloaded and ran the app yourself, we aren't forcing you. And while doing so you've accepted the MIT license.

1 Like

You're right Laurent, only thing is when open source (or any kind of software) isn't GDPR compliant then businesses cant procure it. At least not use it in a compliant way.

Mileage may vary of course, but sometimes these things become knock-out criteria in tenders.

But maybe Joplin isnt meant to be procured by businesses.

Side note:

  • Something being free doesnt mean it dont needs to be checked against the same requirements a business has during normal procurement.
  • When we would procure Joplin Cloud for my organisation all the checks apply, because of the procurement of a service.
1 Like

This very plausible, wonderful explanation can be demystified rapidly. Either you think that Bruce Schneier is a nut, and his blog is useless (that is why Senators invite him to report in Congress I assume), ... in this case your statement on paranoia and panic is a useful call to reason. Or Bruce (not to mention the enlightenment we got from the Snowden files) has many serious points to make. In this case your call to reason is simply ... completely useless. Everybody choose for herself.

As far as I can tell, nobody said so (or I missed it). I said (and others did to) there is a problem (small or large) which I'd like a) other users to know about and b) the devs to consider one way or the other. This is the way improving the design, the concept or the code (sometimes) work through this forum. Different opinion - sure ! Talking about paranoia, panic, and all the rest without sound knowledge of the underlying risks is ... useless,

1 Like

Why just Google? Couldn't anything that causes the user to contact any third-party for a resource fall foul of this?

Obviously. Any third party connection is a potential problem. (But the German court only dealt with a very specific Google fonts case, you cannot generalise it)

But Laurent‘s comment is quite important. Joplin is open source. I am not sure if the GDPR applies. That’s a really interesting question.

Back to the topic of Hunspell: Perhaps it is desirable for Joplin to follow the same rules that apply to companies with regard to the GDPR. At least in the long run. If external request become a bigger problem in the future some solutions may pop up which Joplin can follow.

Actually I just looked again at one of the translations above (by Google Translate :slight_smile: ) and it has an opinion that starts:


Attorney Plutte's comment: What does the decision mean?

  1. The Munich judgment only applies to the popular Google Fonts service as an example. The principles established by the court apply to all web services originating in the USA. This does not just mean alternative offers such as Adobe Fonts or MyFonts , but literally every US service that is dynamically integrated into a website. (My emphasis)

EDIT: Removed some rubbish I wrote...

Why is there a correlation between software being open source and a legal framework?

Anybody is free to develop software, open or closed. GDPR just means a data-controller (the business/organisation responsible for the personal data processed) needs specific agreements with its data-processors (business providing a service to the data-controller), among other things information security related.

If a EU business chooses to:

  • Use Joplin personal with third party sync, the service provider offering sync must be procured with proper data-processing-agreements (DPA).
  • Use Joplin Cloud, Laurents business provides the sync service and storage. Business must have a DPA with Laurent.
  • Use a hoster for their 'private Joplin Cloud' with Joplin Server same thing.
  • Use Joplin Server on premise, all other things GDPR apply for that business, but there doesnt need to be a DPA.

So there is no legal obligation to develop things left or right.
But if Joplin is going B2B with EU customers, then these checks will show up.

I encounter many 'handy apps' that become unprocurable, maybe no business to sign a DPA, or they themselves use subprocessors without proper DPA's.

Compared with Linux. You cant procure it from Linus Torvalds. But lots of businesses offer hosting etc.

Joel, did you just compare Laurent Cozic with Linus Torvalds?
Yes, but only as a compliment. :grin:

2 Likes

Joel, what you have written sounds completely plausible to me. However, let me add that there are three different concerns that are talked about in this thread:

  1. The original concern that there is a connection to some Google server when Joplin is started. As this is a generic request for some spellcheck dictionary, the only information that is transmitted is that some computer with some IP requests a to download a dictionary. It is not related to any content of your Joplin.
  2. The recent case in Germany, where it was ruled that a website that you visit is not allowed to automatically do something that transmits your IP address to third-party servers (e.g. to download fonts from google). Due to GDPR, the user must be able to consent (or reject) this.
  3. The topic Joel mentioned: If you sync your Joplin somewhere, the content of your notes need to be stored on some server (that's how sync works). Due to GDPR, if the content of your notes contains any personal information about your customers or similar, you need to have a contract with the server provider that basically states that the data is handled in a certain way (security etc).
1 Like