CiviCRM Community Forums (archive)

Hi all,

Recently, when demoing a product which includes civiCRM to a client, we noticed that their access to civiMail functions in IE was a little impeded. Messages about one script timing out when we tried to upload an HTML file.

Having a look later on, the root of this problem seemed to be the spell checking function. This is part of CKEditor, which is used in (I think) all instances of civiCRM since 3.1 or so? Prior to that I seem to recall that it might default to whatever you were running in Joomla or Drupal. CKEditor's spellcheck function sends all text in fields that it is used for to a third party server - svc.spellchecker.net, and there's kind of graphic configuration to change this.

Some people might have a bit of a problem with their data going through some other server, as this script is likely used in any rich text fields, not just the mailing.

to fix this, the documentation for CKEditor seems to recommend disabling the automatic startup of this plugin, or using another configuration option. However, the 2nd configuration option only seemed to function in Safari or Firefox (as it relies on the spell check built into both those browsers).

Alternatively, you can disable this plugin entirely by finding:

packages/ckeditor/ckeditor.js

and adding the line:

config.removePlugins = 'scayt';

Thought this might be worth posting, as I didn't see another topic that mentioned this. There's a few others that touch on other aspects of configuring CKEditor, but not this in particular. Hope this saves someone a bit of time or effort!

Andrew / Pat - We did some research on this and it seems that neither IE nor Chrome include native spell-checking functionality. If we turn-off the ckEditor / tinyMCE spell-checking "by default" - this means that a significant number of our users would not have spell-check at all. This is the first time we've heard about the privacy issues for spell-check web services - so I'm a bit reluctant to force users who want spell-checking in CiviCRM to have to modify a core file.

Can you provide links / more info to verify the privacy implications for this?

Would also be great if other folks could chime in here.

Disabled auto spellcheck

config.scayt_autoStartup = false;

IMO this might be better rather than completely removing the plugin.

Kurund

I set up a custom config.js under my custom path as described, but it doesn't seem to change anything. Am I putting it in the right place: under <path_to_custom_php>/packages/ckeditor/config.js ?

I tried clearing browser cache, drupal cache, civicrm_cache.

The jira issue above says

"If you are modifying config.js you should first have configured a Custom PHP Path under Global Settings > Directories, and place your modified version in the custom path."

and the help text on site preferences says similar.

Folks,

Coming back to the issue of privacy itself, my understanding (and I am an Australian, so it could be upside-down!) is that privacy relates to information which identifies an individual. So the key question is does the information being sent to the third-party site identify an individual, and secondly does it reveal any information about that individual?

Another factor to consider is that if the information is being sent in an email, then the information is about to be made public domain (subject to whatever email security one has in place). That factor mitigates against privacy concerns.

A third factor is the API and design of the service. I did a quick search and couldn't see anything on this. Perhaps a way forward is to understand what spellchecker.net does with this information, rather than cutting off the feature. For instance, "spell check as you type" suggests the API is dealing with words rather than sentences,

Ken

@demeritcowboy,

Could you clarify what is this 'legal liability' issue? I have recently been thinking through our Privacy Policy and looking at the Australian National Privacy Principles. In that context, I just can't see a concrete privacy issue with the spell checker.

Where is the spell-checker used? I just did a quick audit of the places where a HTML editor is used. Most of the uses are clearly not private: CiviEvent information and registration pages; CiviContribute contribution pages; mail forwarding. No privacy issue here, unless I'm consciously abusing someone's privacy.

Some uses could concern private information: inserting a token in a CiviMail; or sending an email direct to a contact. With the former there is no privacy issue, as the spell-checker only sees the token, not the value that CiviMail inserts during sending. With the latter, we finally arrive at a case where there might be a valid concern.

But at this point I'm about to send an email. Emails occupy a low point on the privacy scale. I'm not sure we earn points for avoiding a spell-checker to protect information, and then send it out in an (unencrypted) email.

An analogy might be useful. If I host CiviCRM with a hosting company, all my data is in the hands of a third-party. I'm sure most of us do that, and a good proportion of us have never read the privacy policy of our host.

Ken

Could you clarify what is this 'legal liability' issue? I have recently been thinking through our Privacy Policy and looking at the Australian National Privacy Principles. In that context, I just can't see a concrete privacy issue with the spell checker.

I don't see either a clear cut abuse, but any information you send to an external provider is something you are likely to have to explain in case of an audit on privacy. As the added value of sending data to an external spell checker isn't obvious (at least if you use a decent browser), I'd rather not send it, so I won't have to go through the details of what is send, to which extend it potentially contains data about the members (or not), what kind of data, if the contacts are properly informed, if bla bla bla.

Much easier to explain that we don't transmit any data to any spell checker.

X+