Lamplight, integrations and security

We’ve recently launched our integration with Mailchimp, allowing you to synchronise your contacts with Mailchimp, send campaigns through Mailchimp, and have them appear back in Lamplight, linked to the recipients.  You get the email templates, deliverability, and reporting functionality of Mailchimp, integrated with the ‘overall picture’ view you get in Lamplight.  It’s being used by a number of our customers already.

There’s a downside.  You’re trusting Mailchimp with the names and email addresses of your contacts.  That’s a judgement you need to make; for many of our customers that’s fine; for others it may not be.  Of course it’s the same judgement you make with us.

We occasionally get asked about other integrations – can we do reports on Google Maps?  Can we publish work records to Facebook events?

This is obviously attractive.  Why build a geographic reporting system from scratch when Google have done it so well?  Why not save me some double typing and let Lamplight post things to Facebook?



There are different kinds of integration.  Essentially these can be divided between server-to-server integrations and client-side integrations.  With Mailchimp, our servers talk directly to Mailchimp’s servers.  We can control what we tell Mailchimp, and what messages we accept from them.

But client-side integrations are different.  Something like a Facebook ‘like’ button, or a Google Map within Lamplight, effectively give access permission to Facebook or Google or whoever to Lamplight as if they were you.  Those maps or buttons contain javascript programs that ‘like’ or ‘map’ – but in principle they could also scrape all your data, send it back to base, and then delete it.  And we could have no control over that, because as far as Lamplight’s concerned, it’d be you doing it.

We don’t actually think those companies would do that.  But in principle they could.  And that’s a good enough reason for us not to.


A related issue is knowing where your data is.  With Mailchimp, it’s very explicit that you’re sending names and email address to them.  You have to opt-in and set it all up, and it’s obvious that’s what’s happening.

But there may be more subtle data sharing going on with client-side integrations.  A geographic reporting feature using Google Maps would require that you share the data you’re reporting (client addresses and self-confidence ratings?) with Google – and that may not be obvious to you.

Even more subtle are new features within web browsers.  One really neat one that’s arrived relatively recently is voice recognition – you’ll see the little microphone in Google’s search bar that lets you say your search terms.  When this came out we thought it’d be awesome to be able to dictate your work records instead of all that typing.  But it turns out that the voice recognition happens remotely – the audio is sent to Google servers where it’s converted into text and sent back.  So adding this to Lamplight would have meant that any data you spoke into Lamplight would also be being shared with Google.  Again, we don’t actually think they would misuse it, but we don’t trust them with your data to be adding it to Lamplight, however neat it would be.

To conclude

We think the best approach to security issues is excessive paranoia.  Server-to-server integrations allow us complete control over what is shared with external services.  And that sharing is explicit, and opted-in to by you: if you don’t turn it on and set it up, nothing happens.

But we are completely powerless over client-side integrations: in principle it’s equivalent to sending your username and password to that external service.  And the data sharing that necessarily happens with client-side integrations may be subtle.