The iOS app (shown), web app, and OS X app show the same organization by how snippet groups are shared and owned. But sharing is managed exclusively at the Web site.
Now, central storage of snippets is mandatory. The new ecosystem stores everything on Smile’s servers, uses the web app as a view into storage and administration, and treats apps as synchronized end points. This invites more scrutiny of Smile’s security and encryption. The company’s cofounder, Greg Scown, answered a number of questions via email that weren’t on the firm’s website as I wrote this, but the company plans to provide more detail.
Smile fundamentally maintains that its users shouldn’t put anything that’s generally useful to another party if it were stolen, such as social-security numbers and passwords. That’s impossible to enforce, of course, and snippets used inside a company—even the full set of responses a company uses for customer service—could reveal sensitive information alone or when viewed as a set.
All the apps and the website use the most recent secure version of TLS (version 1.2) for encrypted sessions, such as over https. However, the apps and website don’t use certificate pinning, in which the digital certificates used to validate identity are restricted to be accepted only if issued by a small number of outside parties. Pinning prevents subverting operating systems through malware that can install root certificates that would produce valid-looking documents that a pinned app would reject, but a non-pinned one would accept. It’s seen by security experts as a best practice for iOS apps by Apple and for apps in general.
Scown says Smile stores snippets at rest in unencrypted form on database servers operated by Compose.io, an IBM company. The company evaluated using solutions in which data is always encrypted except during the moments its needed for syncing or updating, and found the other security elements—such as how passwords were restricted—were lacking in its evaluation.
There’s a difference between unencrypted and insecure, and it’s not de facto unsafe that Smile has made this choice. An attacker has to defeat multiple lines of defense to obtain the raw data—like two-factor authentication—and the raw data in snippets isn’t likely to be as valuable (and thus it’s much less likely to be a target) than, say, information stored by a password-syncing company like AgileBits or LastPass. Data encrypted “at rest” is yet another bar an attacker has to pass, but it’s not insuperable, either.
However, I believe Smile’s approach is naive given the current security climate. Other firms operating sync, backup, and hosting services that have native and web clients can let subscribers create a private passphrase that’s used for a per-account encryption key, so that data is always encrypted in storage. These systems can support various methods to allow shared access to the same resource, as well.
Sign up for Computerworld eNewsletters.