Switchboard uses modern, hosted, cloud infrastructure for all its services and storage.
Switchboard has undergone a SOC 2 Type 1 audit. A report is available to customers upon request. We are in our SOC 2 Type 2 observation window and will complete our audit in the coming months. If you would like to be notified when our SOC 2 Type 2 audit is completed, please email us at firstname.lastname@example.org.
If your company requires ISO 27001, HIPAA, or other compliance standards, we would love to hear more. Please email us at email@example.com.
Yes. A report is available to customers upon request.
All traffic between your client and our infrastructure is encrypted in flight. All data stored in our infrastructure is encrypted at rest. We use state-of-the-art algorithms and key management and regularly audit our configurations.
Switchboard designs its systems according to the Principle of Least Privilege. Switchboard uses state-of-the-art tools to lock down its systems. Only in response to specific incidents or customer-support requests, only for a limited scope and duration, and only after a strict approval procedure, may an incident responder access internal infrastructure.
We believe that trust is hard to earn and easy to lose, and we encourage customers to trust, but verify. We're happy to walk customers through our policies and access controls.
No, and we never will. Switchboard is an old-fashioned company that asks our customers to pay us in return for providing the value of a useful service.
Not yet. If you're interested in this feature, please email us at firstname.lastname@example.org.
Thank you for taking the time and effort to help us improve security. Please email your report to email@example.com.
Switchboard requires all users to authenticate themselves using either OAuth 2.0 or email address and password.
You can invite full members to your workspace specifically by email address, you can whitelist email domains so that anyone with a validated address can join as a full member, and you can additionally invite specific people as limited members to individual rooms.
Full members of your workspace can join all public rooms. Private rooms can only be joined by invitation.
Limited members can only join the rooms that they've been specifically invited to.
One-time guests can join a room only: (i) specifically by confirmation from a room member or limited member already in the room; (ii) for the duration in which a room member or limited member is in the room.
When a person is removed from a workspace, they can no longer browse or join any rooms in the workspace. Any content that they've uploaded to rooms remains until deleted by another user. However, the removed person can no longer access any content in the workspace.
When a person is removed from a private room, or a limited guest is removed from a room, the person can no longer see or join the room. Content they've added to the room remains, and they can no longer access it.
Any workspace member, limited room member, or one-time guest can view rooms' documents. They can also view and edit notes and other content. One-time guests can only view chat messages that were sent after they joined the room.
Access to documents and other content is only allowed from inside a room, so the room access model (see above) gates access to content.
Immediately after deletion in the UI, the deleted content is no longer accessible from within the room. The content's underlying storage is eventually permanently deleted. We are in the process of complying with GDPR, CCPA, and other relevant regulations. If you have further questions about this, please email us at firstname.lastname@example.org.
When you archive a room in Switchboard, the room becomes inaccessible to all users. All content in the room is preserved securely in the event the the room needs to be unarchived in the future. Note: viewing a list of archived rooms and the ability to unarchive rooms is currently not implemented but is on our roadmap.
To delete a workspace from Switchboard, email our support team at email@example.com. Once we process your request, your workspace and all associated data will be removed.
Interfacing directly with the multitude of calendar APIs and services is extremely complex and error prone. So to provide an optimal user experience and cost-effective service, Switchboard works with a third-party vendor to manage calendar access. Like Switchboard's other service vendors, our calendar service adheres to as strict or stricter security, privacy, and compliance standards as Switchboard itself.
When your calendar data is in flight through Switchboard infrastructure, it is protected by all the security and privacy controls described here. Additionally, Switchboard does not store any calendar event data in its infrastructure.
No. Within your Switchboard workspace, your calendar data is private to you.
Outside of Switchboard, you of course may add invitees to events or otherwise share your calendar.
When you disconnect your calendar from all linked Switchboard workspaces, we immediately remove any access tokens related to your calendar account. At that time, all calendar data is queued for deletion and processed within 3 days. The same process is used in the event that your account is deleted as part of a workspace deletion.
Initially, everyone else present in the room can see the browser. You can choose to hide the browser from everyone other than yourself.
This answer is complex to describe in text, but much more natural to use in the flow of working within a room.
For sites like Wikipedia, news outlets, simple single-player games etc., everyone present in a room can view and control the content. (Unless the content was hidden by the browser owner.) This means that for everyone in the room, there is only one scroll position, focus of input events, state of the DOM, etc. If anyone in the room scrolls the browser, for example, then everyone else in the room sees the scroll position update in real time. These sites comprise the vast, vast majority of content on the web.
However, many of the modern web apps you frequently use are "multiplayer". That is to say, multiple users can view and control the same underlying resource at the same time; for example, a Notion page or Google doc. When multiple users are viewing or editing the same resource concurrently, the app UI shows presence indicators for the other users like avatars, pointers, carets, and so forth.
Switchboard handles multiplayer apps specially. When you want to control a multiplayer browser that you didn't add to the canvas yourself, you will get your own view and control of the shared resource (again, think of a Notion page or Google doc). Then anyone else viewing the shared resource will see your presence indicators in the UI, and you are free to edit, scroll around, etc in the shared resource without affecting the views of others.
No. When you leave a room, your running browser instances are destroyed. If you later rejoin the room, the browser instances are launched again by default. Only the URL and a small amount of associated metadata are stored on Switchboard infrastructure while you're not in the room.
Your client connects to the browser instance running in Switchboard's infrastructure. Your client captures input events targeted at the browser on canvas and forwards them to the cloud browser instance. All traffic is encrypted in flight. When the forwarded input events enter Switchboard's infrastructure, they are protected by all the security and privacy controls described here. In particular, they are never recorded by Switchboard. This is very similar to how a secure remote-desktop system works.
No, Switchboard never stores any data you enter into browsers.
No. Switchboard automatically hides your entire browser whenever a password input field is focused.
It's still possible to accidentally reveal sensitive information to other people present in a room --- just like in a Slack channel or any other communication tool --- so use judgment in whom you invite to rooms, and common sense in what you share.
No, cookies and other browser state are never persisted in Switchboard's infrastructure. Browser instances are ephemeral and are destroyed when you leave a room or remove the browser from canvas.
Your browser profile is only persisted on your local machine, encrypted at rest, in IndexedDB storage for the switchboard.app domain. You fully control your encrypted browser profile; you can delete it whenever you like.
Your browser profile is only synced to browsers running in the cloud on your behalf, when they're created by you. And your browser profile is only ever decrypted by those ephemeral browser instances.
No. When you log into a website within a browser, it will usually generate a token that's synced back to your local machine. The token disappears when the browser instance is destroyed. But the next time you create a browser in a Switchboard room, the token will be synced from your local machine to that new browser instance, and you won't be required to log in.
Of course. In your local web browser, delete IndexedDB databases for the switchboard.app domain.
Switchboard applies the principle of Defense in Depth to isolate your browsers. Browsers' web content run in hardened web runtimes and virtual machines within operating-system sandboxes. Browsers are further isolated in "containers", using additional kernel protections. And on average, two browser instances will run on separate cloud VMs that are further isolated from each other by additional hardware protections.
In no case do browser instances for different users ever share data, other than through user actions taken through the web apps themselves (such as collaborating on a Notion page, for example).
At any time, anyone in a room can present their view of the canvas to other people in the room. This means that others in the room will see the presenter's view of the presenter's multiplayer browsers. However, the people being presented to (i) cannot control the canvas or browsers; (ii) cannot not see browsers that the presenter has hidden.
At any time, anyone in a room can follow another person to see their view of the room. This is like a 1:1 Present Mode initiated by the follower instead of the presenter. The same restrictions apply as for Present Mode.
A presentee or follower is not allowed to control a presenter or followee's view of the canvas. Another person in a room might follow you without your knowledge; you might find this surprising in some cases.