- How can I try Caliopen?
- We are not ready yet to open Caliopen for testing. Invitations for beta testing will be sent out as soon as we have an advanced enough prototype.
- What about pricing?
- Caliopen won't be a centralized service but a bundle of free software that will hopefully be used by a lot of public and private players. Some of them might offer paid services based on Caliopen, but Caliopen might be used within your company, your NGO or integrated to your ISP offer under various business models.
The only business model prohibited by the charter we aim to set up is a business model based on using users personal data.
- Why should I use it as I have nothing to hide?
- Even if you think you have nothing to hide (which is probably wrong), people you're writing to might have other priorities or other views on their privacy. By protecting yourself, you not only protect your privacy but also theirs.
- Will I have a @caliopen.org email adress?
- No, it's probably the only domain you will have no chance to get an email with. "Caliopen.org" domain will remain property of the project, even more when services based on Caliopen are launched.
You will have to choose which service based on Caliopen you want to use, and the proposed domain will be one of your choice criteria.
- I'm not a tech addict, how can I help?
- Even if you're not able to help with development, you can help us by promoting the project around, proofreading our documentation, translating it in other languages. As simple as it can be, asking us questions helps us explain our vision and our goals.
Feel free to join us on IRC chat (http://webchat.freenode.net , channel "#caliopen") or by email (email@example.com).
- I'm tech savvy, where can I have answers to my technical questions?
- Caliopen is on Github (https://github.com/CaliOpen), but you can also find us on IRC (@Freenode/#caliopen) or by email (firstname.lastname@example.org).
- What kind of help can I give (fixing issues, suggesting new features, ...)?
- We're open to any suggestion and help is always welcome. Don't hesitate to get in directly on Github, or to come and share ideas via IRC or email.
- Is Caliopen a service? An app to install?
- Caliopen is a software suite allowing to deploy a secure messaging solution.
Intrinsically, Caliopen doesn't aim to be used individually (selfhosting, local installation,...) but on systems allowing to manage hundreds of thousand users accounts.
Chosen technologies are not adapted to a local use (even if it is possible), because a messaging infrastructure is easier to deploy on a big user base (scalability, antispam and filters management,...). Moreover, the targeted public is not technically aware of this usage.
Therefore, we hope lots of organizations will use Caliopen to widely offer secure open messaging services.
- Will Caliopen be available via a mobile app?
- For now, we focus on Caliopen's web interface development, but we plan to provide a mobile app in the future. The need for an app is clear: it will let users add text messages within their conversation, and retrieve some messages in a mobile environment. Yet, users have to keep in mind that privacy level will be lower while using a mobile app, which will impact Caliopen usage.
- Can I pay a company to install Caliopen and manage it for me? After all, I pay a hosting company to manage my emails.
- This will probably be one business model, amongst others, used by Caliopen providers.
- Will I be able to host Caliopen on my own servers?
- If you have a powerful enough infrastructure, you might, but Caliopen is not aimed to be installed by individuals.
- Will I be able to communicate with people not using a Caliopen service?
- Of course, this was and still is a priority. When an external messaging system interact with Caliopen, it uses standard protocols (SMTP, XMPP,...), which Caliopen uses too. But, unless this external messaging system is configured to provide the best security level, this messages won't appear with a high privacy level in theCaliopen interface.
- Will I be able to use Caliopen with Outlook or Gmail?
- No, unless you're patient enough to let Microsoft or Gmail adopt Caliopen.
- Will I be able to use or redirect other email addresses to my Caliopen account, and will I be able to reply from Caliopen with these external accounts (like adding an account to "send email as" in Gmail)?
- The main motto of Caliopen is to let users centralize all their private conversations into an single interface. You will, of course, be able to redirect your old email address to your Caliopen account (and probably you'll be able to reply through Caliopen using your old address. As a free software, Caliopen will probably evolve to offer that feature). However, you have to keep in mind that in this situation, the privacy level of your conversation will be really low, as Caliopen cannot identify security thread between the sender and the first account used as a relay.
To increase the privacy level of your communication, it will be necessary to ask your contacts to use your Caliopen adress.
- Will Caliopen use be transparent for my contacts?
- Technically, yes: Caliopen is based on standard protocols, it only uses the best security features of the system it is interacting with. Socially, probably not: when you will receive an email from a less secure system, Caliopen will inform you about the low privacy level of this conversation (and will give these particular messages a lower priority in your inbox)
You will probably soon want to convince your more important contacts to switch to a more secure provider, maybe one using Caliopen.
- Caliopen, what is it, do I need to create one more account?
- Your privacy is in danger precisely because you created and used a lot of platforms to communicate... Using Caliopen will let you centralize all your accounts into one secure system that will let you have all your messages in the same place, being aware of each's level of privacy.
- How can I use Caliopen to protect my family / my children?
- One of the most common misunderstanding in IT security is that one can't protect himself without protecting others. Having the highest security level, encyptring messages and data, using different passwords, is useless if people you communicate with are not protected. Protecting you and your relatives is useless if others are using low security level systems. Of course, you can use Caliopen to make your online communication secure, but it we be really secure only whe, seeing the low security level of the messages sent by your contacts, you become a prescriber and convince your contact to use secure systems.
- What is behind the idea of confidentiality level?
- In Caliopen, every element has its own "confidentiality level" which tells the user what is the security level for any contact or message or conversation...
Each terminal declared by the user is graded according to its use (e.g. strictly personal, at home or as a public access within the enterprise), its type (a phone is necessarily less secure than a desktop PC, as it is much easier to loose). When used for the first time, a non declared terminal receives a note of zero.
Incoming messages are rated whether they are or not encrypted, and also according to the type of encryption key. The type of transport (secured or not) influences the rating as well as confidentiality level associated to the related contact if it is known. The algorithm that rates a conversation is more complex, but takes into account all described elements.
For a user's contact, the confidentiality level is equal to the global confidentiality level of this contact's account: this global confidentiality level is the only public element of a CaliOpen account.
Finally, every CaliOpen instance should eventually get assigned a confidentiality level, depending on the way it is configured, or local legislation (a CaliOpen instance hosted in a country submitted to the Patriot Act would be given a lower grade than an other instance, hosted in a country more respectfulof private life), etc
This is the fundamental notion in CaliOpen: only by knowing at every moment the confidentiality level of an element is the user incitated to increase it - if possible -. This allows the user to make informed choices (e. g. to read a confidential message on an unsecure terminal is a very bad idea, which will lower the user's grade).
- In which ways is the human factor taken into account in CaliOpen? (in a device usage context)
- There is clear evidence that Caliopen cannot evaluate, on its own, the level of confidentiality for a given terminal, except when some tangible elements are given (e.g. SSL configuration of the browser). When the user is connecting for the first time on his/her account with a device he/she never used, the level of confidentiality is considered as null.
The user then has the ability to associate this terminal with his/her account and to describe how it is used (mobile or not, personal or familial, regularly or not...). Thanks to these elements, Caliopen will be able to grade the confidentiality level of the device and, for example, authorize or not reading of the most confidential messages (the user will still be able to override the interdiction though he/she might lose confidentiality points on his/her account).
So, in any case, the user is the final point for decisions: finally all the evaluations given by Caliopen depend on one single element: the user.
- Why is it an association?
- Offering a security solution relying on a third party (self-hosting is not well suited for a messaging service infrastructure, it will often be third-party that will offer a Caliopen service) implies that trust from the user should not be given blindly.
The simple fact of using Caliopen is on itself not enough: like all free software (free as in speech), Caliopen may be modified at will by the one who installs it, and nothing enforces that it cannot be used by organizations for which privacy is only a currency.
To address this problem, we imagined a "Caliopen label" that can only be granted by a selfless, volunteer organization that cares for the users' interest. This, in regard of the French law, is an association which, once the software will be completed in a final version, should publish a "charter of use" that volunteering users of Caliopen must commit to respecting.
As a return, they will receive the label (and will be able to display it) plus a cryptographic certificate allowing them to join a virtual private network assembling all the actors of the Caliopen environment (this will enable, along with a higher security level compared to standard protocols, to exchange, not only message between the users of Caliopen' services, but also the level of confidentiality for a given user if he/she is using "another" Caliopen.) This label (and its associated certificate) may be revoked - along with the associated features - and represents a strong commitment from those who will have chosen to commit to it.
The charter of the future association will define certain things like: commitment to follow security upgrades, ability to design a business model stable enough to guarantee the durability of the users' data (and the ability to give them back to another member of the association in case of failure), respect of users' privacy and consideration that the hosted data is owned fully and completely by the user. The charter may include other obligations.
Finally, the association will have to maintain the project (fix bugs, deploy security updates, develop the software regarding computer security's state of the art).
- What about SPAM?
- As every messaging system, CaliOpen will include anti-spam tools. Nevertheless, instead of a binary ("this is spam", "this is not"), our tools will implement the same logic as for the confidentiality level: the "importance level".
When, for example, a message is neither signed nor encrypted, sent by someone that is not part of your contact nor of a senders white list (government, known online resellers..), in short a message that will likely have no interest for you, it will be attributed a very low "importance level". On the contrary, an encrypted message from a contact for whom you 'll have set a high importance level (a family member, someone from your company, ...) will be given a very high importance level.
A low/high slider, in CaliOpen main tab, allows you to define at which importance level you wish your conversation displayed. Thus spam, as all the unwanted messages, is not classified in a specific folder: they are simply displayed only if you lower the value of the slider. Conversely, whenever you're on a vacation, or want your "right to be offline" respected), you can only display messages with a lower importance than a maximum you can specify at any moment.
As a principle, CaliOpen won't use external black lists (as Spamcop or RBL) that send metadata to third parties (we know how crucial metadata are).
- What kind of communication is possible with CaliOpen?
- CaliOpen user interface is meant to display any type of private correspondance. Even though, for the time being, the project is only planning on supporting the most common ones (email, chat, Twitter/Facebook/Linkedin private messages and so on), we are allready planning to be able to introduce other types of communication (SMS, video, WebRTC...).
- How do you manage outgoing mails encryption, private key managment and the receiver's public keyring?
- CaliOpen user doesn't have to possess keys, but will be strongly incited to, through the UI, so that he can access a saticfying confidentiality level. His private key is then stored on its terminal: CaliOpen doesn't own it.
When creating a contact (or when it's imported from a third party tool), Caliopen will try to find, through different protocols (DNS register or SKS) the public keys associated with the provided email address, and propose their inclusion in the keyring associated with the user's account on the Caliopen server. The goal here is to ease the user's life as much as possible while allowing, through a centralized keyrings management, to efficiently manage a key revocation by a contact.
When a user wants to send a message, once the redaction is complete, CaliOpen will propose - as a default - the safest available protocol as a function of the recipient, the availability or not of associated public keys, the security level of the protocol used, the configuration of the distant server and whether the recipient is instantly available for the conversation. If, for example, the receiver is online, connected to an XMPP/TLS server and a cryptography tool (such as OTR) is available, CaliOpen will by default invite the user to send his message through the corresponding protocol.
- Will it be possible to use "classical" softwares like Thunderbird on a CaliOpen infrastructure? (related with the label system for organizing mails, already in use with Gmail but very difficult to manage with TB).
- Yes, but only on degraded mode: it is intended to add an IMAP service to CaliOpen so that it can be used with any compatible software to access one's mail but this protocol is hardly usable for any other thing than e-mail and cannot allow the management of the "level of confidentiality" so its use will necessarily be limited. The default rule will be (even if the user can change this preference) the following: most confidential contents will not be available via this mean.
On the other hand, Caliopen classifies messages in terms of contacts instead of subjects (which is the way classical e-mail clients sort messages). To allow backward compatibility with this type of tools, CaliOpen will re-create, on the fly, the necessary information (e.g. by transforming its labels into IMAP "folders") so that it can work but not with its nominal efficiency.
- How "out of web browser" access to the mailbox will be provided?
- At first, still for confidentiality reasons, it will only be feasible in degraded mode through third party tools, through the IMAP protocol. We are however considering developping a thick client in the future, which will be loaded on a terminal instead of being only accessible online. This is a must do objective, but out of reach as of now (such clients are harder to mainain, due to platform differences, and so require a greater workload).
- Is sorting message by "recipient" instead of "by thread" hardcoded in the system (and as such not customizable)? Will it be possible to sort by "Subject:" instead of by "To:"?
- Short answer : no. There is a very simple reason. Caliopen does not process only electronic mail. A conversation thread can span e-mails, chat messages, private message sent through a third party service (Twitter, Facebook...). These kind of conversation have no "subject". This information simply does not exist.
However, what will be possible, is to order through Caliopen labels: any message, any discussion, any contact may be associated with one or several labels in a manual or automatic way (a message from your company will be labeled "work" if the associated contact is himself labeled to "work"). In Caliopen main interface, clicking on a label opens a tab presenting only messages and discussions related to this label. More complex filters may be created very easily by associating several of those labels.
- Can I keep my own email address from my own domain (email@example.com) and keep all related redirects? (firstname.lastname@example.org, email@example.com ....)
- In order to keep them, you just have to install Caliopen on your domain (or to go through a provider allowing this service): if Caliopen manages your Mail eXchanger, you will be able to create (or use) all the adresses @mydomain you wish, not only through SMTP but also through XMPP and all Caliopen provided services in the most secured way.
- May I use Caliopen instead of a manual Postfix/Dovecot install?
- Yes, and it will be much easier : deploying a state of the art email infrastructure is not an obvious task (TLS, DNSSEC, DANE, key management, encryption...). Caliopen makes the whole process easier, so that organisations and individuals want to manage their own system instead of using external ones. This in turns promotes decentralization of private data instead of current centralization at the hand of the main actors.