Comment on page
Behind the scenes: how Olive Helps uses your data
Sensors are a core part of what makes Olive Helps work. Sensors are built into the Olive Helps desktop application and are what allow Olive Helps to understand and communicate with you in order to deliver the value when it’s needed instead of when you seek it out. A simple example of a Sensor is the clipboard Sensor, which can be used to detect when content has been copied to your clipboard. If you added a Loop to Olive Helps that verifies phone numbers, then the act of copying a phone number could trigger the Loop to tell you if that phone number is valid.
There are Sensors to watch the clipboard, typing, windows being opened, text on-screen, etc. All of which can be combined to give a holistic view of what you are doing, so that Olive can help.
You’re probably wondering “is Olive Helps a key logger that ships everything you type to the cloud?” In short, the answer is: no. Olive Helps does not store, log, or send any keystrokes. All the sensed data (ex. keystrokes) is not intrinsically sent to our API. Sensed data is only held in memory long enough for it to be passed to the locally installed Loops that you've approved to access data via that sensor. In the “phone number verification Loop” example above, the phone number copied to the clipboard is passed to that Loop.
Please note: there are some Loops that need to send some of their data to an API for their task.
Using the above example: if the Loop detects a phone number, then it would likely need to send that phone number to the API to verify it. Some Loops may run off of embedded datasets and some Loops will need to send data to an API to get an answer. Loops that need to use an API will need to clearly state this when being submitted to the Loop Library and this will be clearly stated for you to see in the Library, as well. Furthermore, we will enforce that they only communicate with the APIs listed and will monitor how often an API is called.
Metrics/metadata about sensed data will also be sent to Olive’s HIPAA cloud. For example, Olive Helps might collect things like how many words a person types or time spent in specific applications. These are meant to understand how people work and how Olive Helps can add more value over time -- they are not meant to record everything that someone types, for example.
Now that we've covered that Olive Helps doesn't act as a key logger and doesn't directly use any of the sensed data, we need to discuss the important security features built into Olive Helps that ensure transparency and control when using Loops. As a reminder, Loops are the "apps" or "plugins" that run inside the Olive Helps application.
Each Loop is run inside of an isolated, secure runtime that runs locally on the your computer. This Loop sandboxing means that an installed Loop can't access any sensors, read any files, make any network calls, know who the user is, etc unless it has been granted access to do so. You can think of this like your experiences with a smart phone.
Please note: if the app (or Loop in our case) doesn't state that it needs access to your network, the OS will not allow that app to make API calls.
Olive Helps uses this same familiar paradigm, but has enhanced it further. For example, in the smart-phone world an app can request network access, then make API calls to any API anywhere in the world. With Olive Helps, a Loop must declare that it needs network access and exactly which domains it will use. Any attempt to make calls to any other domains would be blocked by Olive Helps.
The Loop permissions mentioned above, such as "I need network access to myapi.domain.com" are configured by the Loop developer as they are building the Loop. When they submit their Loop to the Loop Library, those permissions are attached to that Loop. Olive reviews every Loop that is submitted and validates that the permissions configured are appropriate and not too broad for what the Loop is trying to accomplish. If the Loop and its permissions are approved, the Loop will be published to the Loop Library with the permissions required for that Loop clearly shown like this:
Loop permissions shown in the Loop Library for the "Provider Directory, powered by Ribbon Health" Loop
As an individual user of Olive Helps, the features noted above give you the power to avoid any sensors that you don't feel comfortable using or can't/shouldn't use for any reason. The keyboard sensor is one of the more sensitive ones, so we'll use that in our example here. So, if you want to avoid ever using the keyboard sensor no matter what Loop it was, it's as simple as reviewing the Loop Permissions before deciding to install any given Loop. If you see "Keyboard" shown in the list of permissions, avoid installing that Loop.
As an organization, you have even more control over the use of a sensor. If your organization decides to never allow the use of the keyboard sensor, your organization's admin has a few controls in place to make sure that never happens.
- 1.Set Loop availability: The first step is to adjust your Loop availability settings. Go into the Loop Library admin section to "only show Loops that have been specifically built for your organization or Loops that you have specifically approved". This means that no one at your organization will be able to install a Loop unless you've explicitly approved it (a Loop that you've built yourself, a Loop you've partnered with Olive to build specifically for you, or another Loop in the Library that you've decided to approve for use). You can also adjust the Loop visibility if you don't even want people to see them.
- 2.Review and approve Loops: Since you have your Loop availability set to "approved only", you now have the ability to review the permissions for every Loop that your organization is considering. If you've decided the keyboard sensor is always off limits, then simply never approve a Loop that has that permission shown in the Library.
Each Loop can take advantage of the built-in Olive Helps Sensors. It's worth noting that although the term "sensor" might imply something that only senses/reads what is happening on a computer, in some cases a sensor is used to send/write data. For example, you’ll notice that the File System Sensor can sense changes to files, but can also be used to write files. This is part of our sandboxing strategy. Everything that a Loop wants to do (read a file, make a network request, etc) can only be done through one of the Olive Helps sensors.
Query or listen for the currently active browser URL and currently selected text on a web page.
Query clipboard content, listen for clipboard changes, and write to the clipboard.
Query cursor position and listen for cursor position changes.
Get file information, list directory contents, listen for changes in a directory/file, and read/write/delete files.
For reading/writing to files, the Loop can choose to use built-in Olive Helps encryption or not depending on the needs of that Loop. We recommend always using the encrypted read/write, but there are some cases where that doesn’t make sense -- for example, if the Loop needs to create a report that is put into the user’s home folder or shared drive for consumption outside of Helps, it would need to be put there unencrypted.
Listen for key presses (characters or hot keys) and listen for keyboard utterances (string of keypresses before a pause).
Make a standard HTTPS request or establish a Secure Web Sockets connection.
Get a list of the current running processes and listen for start/stop of processes.
Listen for terms typed into the Olive Helps search bars.
Read, write, and delete encrypted data in the OS’s keychain/credential-store.
Access the Olive Helps user. Access to the user’s email address, Olive user ID, and temporary JWT as part of an OAuth-like flow.
Query or listen for the currently focused window or all the open windows.
Along with the sensor metrics mentioned above, The Olive Helps desktop app captures usage data / telemetry for analysis by Olive to continue improving. Whenever a Loop is triggered by a Sensor, when a user interacts with Olive Helps, etc, these events will be sent to Olive’s HIPAA cloud with the user context.
User telemetry will be stored in Olive’s cloud to track overall utilization across users and across Loops. Just like everything else that Olive Helps does, this will be encrypted at rest and in flight and will be handled with the same level of security and controls as any other data we process.