#peerio

12 January 2019:

After months of talking with users, reviewing UX, and optimizing code, we’ve got the end in sight for a public release of Peerio for Android and iOS! As a thank you to those users who have been grinding the gears of early alpha versions of the applications, discovering bugs, and working with us to improve the apps, we wanted to dedicate some effort into one of the most requested (and honestly just super cool) feature requests — biometric authentication! 

Touch ID adds exceptional usability to everyday authentication, no PIN or passphrase, just one tap and you’re securely logged in using the unique ridges, curves, and contours of your finger. To support Touch ID, we had to create a separate Cordova plugin, which utilizes Apple Keychain’s ability to save and retrieve arbitrary data in a secure way. Essentially, rather than enter a PIN or passphrase, when you’ve enabled Touch ID in Peerio and login, the iOS API is called and prompts you to verify yourself by presenting your fingerprint before retrieving the saved data (your PIN) from the keychain.

We open sourced the library we wrote for this plugin and made it available on GitHub, so if you’re working with Cordova and interested in incorporating Touch ID, check it out! If you end up using it, we’d love to hear how :)

Touching on Threat Models

Now, while Touch ID adds a huge futuristic level of usability to applications, it’s worth noting a few concerns for those with high-risk threat models. One is that, in Oct. 2014, a USA court ruled that a police officer can demand you to unlock your device with a fingerprint but not an alphanumeric passcode (source). The logic here is that your fingerprint is just like any other physical key, and you can be compelled to produce it by law enforcement or really anyone who physically forces your hand. 

This leads to the second point, that unlike a physical key and lock which can be re-keyed, your fingerprint is forever yours. As romantic as that is, it’s sort of similar to using the same password your whole life, which we all know is bad (right?). To be fair, it’s usually easier for a hacker to steal your password than your fingerprint, but it’s certainly not impossible. 

A third concern that some may have, is that Touch ID requires the use of Apple’s iCloud Keychain. When you enable Touch ID, a random secret key is generated that is used to encrypt your Peerio keypair. This random secret key is itself encrypted and added to your Keychain, while your encrypted Peerio keypair is stored locally on your device (in sqlite). Now, we think Apple’s done some pretty cool things with Touch ID security (as do others) and most of our team feels pretty confident using it in our daily lives, but like all matters of security, you should consider your adversary and their means. In the case of Touch ID, this would mean someone able to compromise your Apple Keychain and obtain your device. 

So... should I use Touch ID or not?

One of the reasons you don’t hear about tons of people who have enabled Touch ID being compromised is because, like Peerio’s passcodes, Touch ID is device specific. In order to get pwned, someone would need to swipe a clean copy of your fingerprint and the device you’ve enabled Touch ID on (at which point you already have bigger problems). On top of that, Apple now requires a device passcode after 48 hours, narrowing the attack window.

It's been an exciting few months for Peerio as we approach our second anniversary this summer. We are preparing to launch mobile clients for Android and iOS, professional plans for our heavy users, and we have a slew of features in the pipeline to improve overall user experience.

As our team continues to grow, we've been accelerating development of a collaborative end-to-end encryption tool to ensure that everyone has access to a simple and secure platform to share private messages and files in the cloud. This has been our mission since Day 1 and it is a source of pride for the entire Peerio team who believe strongly in that mission.

While Peerio clients and most observers understand this mission, there remains some skepticism. Since we pride ourselves on quality control and transparency, we'd like to use this space to address some of those concerns, and a few misinformed theories that have been floated on social media.

Is there a "backdoor"?

No.

Critics who argue that Peerio planned to sell backdoored cryptography to enterprise -- that is to say an intentional bypass in the cryptographic design to decrypt users' communication without their knowledge -- are being purposefully deceitful. Any talk of a backdoor was quickly dismissed as being contrary to the company's values. Independent auditor Cure53 demonstrated that rather clearly in their most recent audit, which was made public last week. What is being considered, as we will elaborate on here, is not creating a backdoor but an optional multi-party authentication system that could actually enhance security and usability for many users.

The highly-trusted Cure53, responsible for auditing platforms like SecureDrop, wrote that Peerio gave "an overall strong and secure impression...With the exception of some smaller glitches Peerio presents itself as prepared to handle and deter a large and diverse array of possible attacks." The audit correctly pointed to issues in development code that was never released to the public and were fixed in advance of the mobile launch. The purpose of such audits is to catch vulnerabilities and ensure fixes to any problems are issued before users have access to the platform. We're proud to have worked with an expert team as thorough as Cure53 to assure our upcoming mobile clients' security.

Concerns that a backdoor would be written into Peerio code is baseless. All versions of Peerio that have been released are secure, as verified by Cure53. In order to ensure the sustainability of Peerio, and subsidize development of the free application for all users, versions of the platform are designed for enterprise clients with specific needs. One client, for instance, may require access to a colleague's Peerio communications in the event of an on-the-job incident, death or other urgent circumstances; another may be subjected to compliance regulations by professional orders that would compel the client to disclose those communications. In either case, Peerio would not have access to the data, but will work with a client to develop a threat model and advise on secure alternative means for account and data recovery.

Many users -- individuals or enterprise -- would find an option for multi-party authentication via trusted contacts useful, whether to respect compliance in certain industries, to retrieve lost passphrases, or even, in some cases, to ensure the well-being of users in high-risk environments.

One real-life example: In discussions with an NGO journalism organization, team members expressed to Peerio a grave concern. If a journalist were kidnapped or went missing, there would need to be a way to access their colleague's account to gather information on their location, among other important details, to relay to the proper authorities. Individual users are free to simply share their Peerio passphrases with others if they wish; similarly, a company can independently create accounts for their users and store passphrases in a database. However, these options create a centralized point of risk.

Rather than entrust a single colleague or database with users' secret keys, Peerio has been seriously considering multi-party authentication. What if a user could designate three or more parties as "trusted contacts" who could collaborate to gain access to the account in emergency scenarios? In the case of the aforementioned NGO, multi-party authentication is more than a philosophical debate between tech bloggers, it is life and death.

Unfair criticism

A series of tweets from a disgruntled former Peerio team member attempted to discredit the work of his former friends and colleagues. In addition to false claims by Nadim Kobeissi about Peerio developing a "backdoor," his criticism has ranged from unfair to downright bizarre. Some of the more serious allegations merit clarification:

Peerio's "CEO repeatedly pressured...to come up with ways to sell backdoored crypto to private clients."

This statement is not only inaccurate and unprovable, but completely in contradiction with the type of work Peerio has been carrying out. Such a strategy would undermine the company's credibility. Again, "backdoored crypto" was never a scenario considered by any team member.

"Peerio's open-source E2E crypto client's a front, owned by oil equity firms, main plan is to sell backdoored crypto to enterprise."

False. No equity, debt or any other Peerio asset is owned by oil equity firms.

Peerio "attempted blackmail to gain exclusive rights over miniLock, by withholding shares."

As per the contract signed by the former employee, miniLock (the file encryption protocol that Peerio is based on) remains Kobeissi's property but "can be used by the Company where relevant." As per the release agreement:

"Mr. Kobeissi hereby grants to Peerio...a non-exclusive, perpetual, irrevocable, worldwide, assignable, royalty-free, full paid-up license to use and fully commercially exploit  the software in connection with its business.”

Of course, there was no "blackmail" and no such evidence has been produced. Weeks of delays were caused by Kobeissi as he sought a legal opinion and ultimately declined to sign the agreement. Despite his lack of cooperation, Kobeissi's shares were mailed within days of his decision. We received confirmation Kobeissi had received the shares on August 27, 2015, and the matter is now settled.

Peerio "attempted to prevent me from disclosing and by threatening to sue, asked me to sign contract that I'd never tweet about Peerio."

Non-disclosure agreements are exceedingly common and no "threat" was ever made. In Peerio's view the Kobeissi matter has concluded, though the company reserves the right to defend itself in court against unquestionably false and defamatory statements about the technology or employees.

It's unfortunate that the Peerio team had to be momentarily distracted by what amounted to an irrational and aggressive attack from a former team member who was consistently at odds with colleagues and exhibited a destructive attitude toward the company. The team remains unwavering in its commitment to working toward the goal of providing simple and secure communications for all.

Peerio 1.2.0 is now available for Chrome, Mac, and Windows clients. Chrome users can expect an automatic update, Windows and Mac users will receive an update notification.

30 Second Sign-Up

With this update new users can now register without an email address or mobile number — reducing Peerio’s signup process to a lightning fast 30-seconds of selecting a username and getting a passphrase.  This change also makes it easier to use Peerio a bit more anonymously. While Peerio is intended to be used as a privacy tool, not an anonymizing one, many users have requested the ability to register without existing contact information in order to use Peerio with limited discoverability, or to create disposable accounts for specific communications.

It’s completely up to you if you want to provide an email address or mobile number. Though doing so does enable certain features, such as contact discovery, new message and contact notifications, as well as allowing our support team to help with certain tasks that require account confirmation.  As always, your input plays a huge role in how we decide what features and controls to add next. As we continue to extend Peerio’s discoverability and privacy options, we’d love to hear your thoughts!

Ahoj!

Peerio 1.2.0 has added support for Czech, thanks to the help of our Czech translation team from Localization Lab! Within a few short months, volunteer translators have brought Peerio to 13 languages, including:

Chinese

Czech

English

French

German

Hungarian

Italian

Japanese

Norwegian (Bokmål)

Portuguese (Brazilian)

Russian

Spanish

Turkish

If your language isn’t on this list, you can help bring Peerio to your community by submitting translations on Transifex! 

Up Next...

Samuel Martin Moro, one of Peerio’s newest team members has already surprised us with a side project expected to be unveiled this week. Linux users, stay tuned.

Anri, Peerio’s mobile lead, has been working around the clock to polish off the mobile clients for a December release. Along the way he’s developed an open JavaScript logging library, and will be documenting his work after a well deserved holiday rest.

Skylar’s work on improving Peerio’s passphrase dictionaries was used in a study of public key usability, with published results expected in the upcoming weeks. A follow up study on password usability is planned for early 2016. 

We've received a few questions and concerns related to the recently announced LogJam, a vulnerability affecting certain TLS (Transport Layer Security) connections. There are plenty of excellent explanations of what LogJam is and how to address it (see here, here, and the original research here), so this will just be a quick and dirty explaination of what LogJam is and why it doesn’t affect Peerio. 

A beginner's guide to LogJam. 

Next time you're entering a password or payment info on a website, check the URL. See that "HTTPS" at the beginning? That connection is using TLS, a cryptographic protocol that most of the internet uses to negotiate secure connections.

LogJam allows a man-in-the-middle attacker to target a vulnerable TLS connection and 'trick' it into using substantially weaker "export-grade" security dating from the 1990s. "Vulnerable connections" here are with any server that supports the 512-bit "DHE_EXPORT" protocol, which at the time of LogJam's publication was 8.4% of the Top 1 Million domains. This downgraded connection can be decrypted with relatively low-level resources, potentially yielding passwords, bank info, credit card numbers, mail server data, etc. — the sorts of things you would normally expect to be sent over a secured connection. 

Why Peerio isn't affected.

To start, Peerio’s end-to-end encryption encrypts user data locally on the user’s device before being sent to our servers over secure TLS connections. This is a bit like sending a safe in an armored transport, where breaking the transport doesn’t break the safe.

That said, breaking the transport is pretty damn tough. Peerio’s security protocols are developed through ongoing discussions between cryptographers and server developers, academic research, peer review, and practical assessments of how this affects users and our own build process. 

We like to think we’re fairly prepared when it comes to security, so it wasn’t surprising to see that Peerio doesn’t support any of the vulnerable SSL/TLS configurations identified in LogJam. Peerio uses TLS with a unique 4096-bit Diffie-Hellman group with server-preferred support for TLS 1.2 with elliptic curve cipher suites and forward secrecy. Peerio’s lowest and least preferred standard uses TLS 1.1 with 2048-bit non-elliptic Diffie-Hellman groups. 

Our implementation of TLS and approach to development is aligned with all the concluding recommendations noted in the original research paper:

"Increase minimum key strengths: As a short-term mitigation, server operators should disable _DHE_EXPORT and configure DHE ciphersuites to use freshly generated groups of at least 1024 bits, or preferably, 2048 bits or larger”

"Avoid fixed-prime groups: In the medium term, employing negotiated Diffie Hellman Groups can help mitigate some of the damage caused by NFS-style precomputeation”

"Transition to elliptic curves: In the long term, transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks.”

"Don't deliberately weaken crypto: Our downgrade attack on export-grade 512-bit Diffie-Hellman groups in TLS illustrates the fragility of cryptographic “front doors”. Although the key sizes originally used in DHE_EXPORT were intended to be tractable only to the NSA, two decades of algorithmic and computational improvements have significantly lowered the bar to attacks on such key sizes.

"Improve communication: ... cryptographers and creators of practical     systems need to communicate better.”

If the above numbers and protocols don't mean much to you, or you just want to hear it from a third party, check out Peerio's assessment from SSL Labs. You can get all sorts of gooey technical specs on Peerio's TLS configuration there.

LogJam is a crypto win.

Even though LogJam demonstrates a fairly serious vulnerability in a widely used encryption protocol, it's a valueable demonstration of the real-world value of supporting strong crypto and how experts in the field handle these sorts of issues.

With LogJam, we see the direct consequences of government policy pushing weaker encryption to the world as a means of improving national security — i.e.  a "front-door" approach offering the NSA easier code to crack. Twenty years later, this weaker encryption is now readily exploitable by criminal, corporate, and international state-level attackers, 

Today, amidst pushes for weaker, front-doored, back-doored, whatever-doored crypto, LogJam serves as a pretty straight forward example of what kinds of consequences can arise from this approach. The researchers' own proof of concept teases agencies pushing "front-doors" and demonstrates potential unintended consequences.

So, here we have a team of researchers who identified a serious vulnerability in a widely used encryption protocol, disclosed their findings privately to affected software vendors to mitigate attack risks before public release, which resulted in all major browsers adopting a 1024-bit minimum standard and major server software developers removing support for the vulnerable export protocol — effectively enhancing online security for the entire general public as well as government and corporate entities and their employees.

We’ve all become a little URL dependent.

We’ve gotten used to our data having a certain omnipresence. We depend on data being available from pretty much anywhere, and we get stressed or frustrated when it’s not. We see this in our increasing reliance on mobile devices, with the growth of wearables, and each time our connections drop at home or at work. Website-based communication tools such as email and chat services have unsurprisingly thrived because of their inherent cross-platform support and ability to be accessed wherever there’s internet. We’ve got muscle memory at this point: open browser, go to website, login, say “Hey,” share cat photo, repeat. This has created a dependence on websites for our services, along with some unfortunate side effects (like this and this).

Meanwhile, growing concerns for online privacy and security have pushed many to seek out new tools to secure their data. Naturally, people look for similar website-based tools that fit within their mobile and browser-based use-habits, and are often satisfied once they see the keyword, "encryption", or better yet, "military-grade encryption".

Websites are no place for end-to-end crypto.

The thing is, the architecture of the web is not well-suited for website-based cryptography and end-to-end encrypted communications. The ability to modify and remotely execute JavaScript code, assumed server-trust, and lacking algorithmic standards between browsers host a wide array of crypto-undermining vulnerabilities, such as side-channel attacks, man-in-the-middle attacks, and interoperability issues between browsers. To top it off, the malleability of this code renders security audits, a pillar of good cryptographic practice, totally useless. 

In other words, if your 'military grade security' tool is accessed only by a URL, it's probably not as secure as you think it is.

The weaknesses of website-based crypto are well documented and understood (see here, here, and here), yet these tools survive because: 

They are convenient

They are accessed similarly to tools we’re familiar with.

Cryptography is hard, and most users won't investigate how a service uses encryption nor understand why certain practices may be better or worse than another.

Unfortunately, convenient security often isn’t good security. Similarly, inconvenient security often results in no security if users won’t bother with tools or good practices. Or worse, inconvenience may lead to less-than-zero security scenarios. 

Making security convenient and accessible.

Making strong security tools accessible means working within the design limitations of technology to effectively address real world use-cases. When things go okay, we take something people do and make it more secure. When things go well, we improve security and the whole experience of doing that task. Here are a few ways we’ve approached this with Peerio.

Mobile support

Almost always on-hand and always connected, mobile devices are a ubiquitous tool of any and all people concerned with 24/7 data-access, and are a necessary platform for any communication tool to support. Mobile devices are also an arena in which URL-based tools and services are already outdated due to native apps being incredibly easy to install, easy to access, and optimized for mobile hardware, screensizes, and touch interfaces. With Peerio’s Android and iOS apps entering alpha testing next week, we’re incredibly excited to start working with users to discover how they use Peerio on-the-go, and refine the mobile apps until encrypted message and file sharing is a pleasurable mobile experience.

Want to take part in this goal? Add ‘testing’ on Peerio to get involved in mobile development and get early access to the mobile apps!

Websites apps

We’re big fans of tools that deliver native clients to their users. In terms of quick access, if you can open an app with one-click and skip the browser and navigating through a sea of tabs, we’re all for it. So we made sure Peerio was available natively for Windows and Mac, and we even have a Linux build coming soon. Still, some folks aren’t too keen on installing new software. Cause, real talk, what good is that local installation going to do when you want to check your messages on your partner’s computer because your computer is all the way in the other room? 

That’s why we designed Peerio as a Chrome Web App.

As a web app, Peerio is able to escape the perils of website based cryptography, while still being readily available in the browser. Add the Peerio app to your Google account, and it will instantly be added to all the other computers you’ve synced your Google account to, including Chromebooks. When you want to access Peerio on a friend or colleague’s computer, you can fall back on muscle-memory. Just open Chrome, go to peerio.com, and click “get Peerio” on the homepage to quickly and unintrusively add Peerio to Chrome. Sign in, do your work, and when you’re done you can remove it from the browser in seconds with a simple right-click and selecting “Remove from Chrome”. 

Portable USB

Still, there may be a few cases where the above options just don’t work, like when working from a location that doesn’t have Chrome installed and that won’t let you install new software, such as libraries, internet cafes, or some offices. With these situations in mind, we designed Peerio’s native clients to be USB portable, able to be installed to and booted from a USB drive without opening any browser or installing anything on the computer. Simply install Peerio to your USB thumbdrive, plug the drive into the device, and you’re good to go

Stronger security, faster access, less tabs... What else?

Realistically, most of us have only a few devices we use regularly: a mobile device, a personal computer (or two), maybe a separate work computer, and occasionally a friend or colleague’s device. By developing for as many platforms as possible and designing apps to be portable, system optimized, easy to install, and opened with a touch, we think we’ve made Peerio even easier to access than URL-based tools in most use-cases, certainly more secure than those tools, while still being easy to use for people of all skill levels.

Last week, we had the privilege of presenting Peerio at the ISC Project's Global Workshop, a conference that brought together infosec tool developers, civil society organizations, human rights activists, and independent media from around theworld to discuss our intersecting concerns, needs, and ambitions.

One of our biggest takeaways? Developers spend too much time on development and too much time in a developer world.

This workshop reflected an unusual degree of depth and breadth of experience for an infosec themed conference, notably:

Diverse skillsets and professions, with developers, journalists and media professionals, lawyers, educators, social researchers, human rights activists, and representatives from tech giants and multinational NPOs.

A global community going far beyond North America and Europe, including attendees from the frontlines of rights movements and political struggles in Syria, Ukraine, Pakistan, Mexico, Egypt, Venezuela, Cambodia, Cuba, Ecuador, Azerbaijan, and Belarus.

Women accounted for about a third of the participants.

All-ages, from those who saw their children born before the internet, and those who were born into the internet.

Listening to these individuals (often non-technical in training) share their experiences and assessments of digital security in their own contexts, revealed a wide range of concerns for the global community. These involved a number of hurdles for tool adoption, such as:

Poor computer literacy and education

Poor usability and unintuitive user interfaces

User’s native language not supported

Lack of cultural understanding and failure to address use-cases

Hardware limitations

Unstable internet connections and/or limited bandwidth

However, these concerns were situated within a more hopeful theme, that access to the internet and the ability to use social media and secure communication tools has proven to be invaluable for public education, protecting communities, delivering and communicating social services, organizing social movements, and breaking geographic or cultural isolation.

Needless-to-say, when someone tells you that they’ve been trusting your tool to hide from abusive spouses, avoid societal persecution, or fight oppressive regimes, you damn well better be paying attention to what they are telling you. Not just about some feature or bug, but about their whole condition. If you haven’t already, this is definitely the time to be as humble and honest as you possibly can about what exactly your product can and cannot do to protect these people.

Developers should spend more time listening (to non-developers)

Many of the issues identified above are not problems many developers or tech-savvy users regularly experience. When we operate in a bubble where those around us feel at home with command line operations, have access to reliable internet access, and work in their native-language, it becomes easy to overlook or undervalue these sorts of concerns. If we want to design tools that are truly accessible, it is crucial that we start actively reaching out and listening to those whose experiences and skills differ the most from ours.

Listen and act

After only two days of listening to the experiences of those at this workshop, we have stepped back and taken some time to identify a few ways that Peerio might be able to address some of these needs.

Localization

We're very pleased to announce that starting next week we will be working with Localization Lab to begin dedicated work on translating Peerio as widely as possible. Localization Lab, a partnership between the Open Technology Fund, Second Muse, and Transifex, is an incredible project working to unite IF tool developers with volunteer translators around the world to ensure these tools are available in their native-language. You can expect to see Peerio's Transifex page relocated to the OTF page in the next week or two, and new language support in Peerio rolling out soon after that. 

Feedback tools and sourcing

Peerio has been framed and built by user feedback. Bugs are often identified and fixed thanks to user reports, UI changes and features-priotization have been based on user-requests, and our long-term roadmap and feature set is strongly composed of user suggestions. 

Drawing from a session on end-user to developer feedback cycles, we've come to the conclusion that working with GitHub may not be for everyone, or maybe some folks would like to report a bit more anonymously, or maybe general users would be more inclided to give feedback if it was just more convenient. As such, we will be looking into integrating feedback mechanisms into Peerio to make it easy for users' to share their thoughts, seek support, and report bugs on the spot.

Additionally, we are excited to be continuing our work with the ISC Project and their partner groups to conduct regionally specific testing to better understand localized use-cases and culturally specific needs.

 Training users

Providing trainings and educating users on tools such as PGP can be a grueling process with limited success, particularly if users do not retain those skills two weeks later. While we have made our attempts to address this issue by designing Peerio to be as intuitive and easy to use as possible, we realize that ‘intuitive’ may not mean much for users that have limited familiarity with computer interfaces to begin with. 

Over the next few months, and in conjunction with our localization and feedback efforts, we will be developing user-manuals and a setup wizard to help guide users through Peerio's features as well as explain what Peerio can and cannot protect against. Our goal will be to provide a package that makes encryption tools accessible for users new to computers entirely, as well as illustrating where potential risks may appear.

 Offline access

Offline access has always been part of Peerio's development plan, and has been stressed as a vital feature for any communities with limited access to internet or unstable connections. We will be aiming to offer support for offline message handling by Fall of 2015. This will allow users to sync their messages when an internet connection is available, store the encrypted data locally, write draft messages that are encrypted offline, and then queue drafted messages to send once a connection is re-established.

 Get involved!

We have big ambitions and always aim to serve the community serving us. There are a number of ways you can get involved:

Localization: Make Peerio accessible in your native-language! Check out Peerio’s Transifex page to get involved. Remember, we’ll be moving to OTFs Transifex hub in the next week or two. So stay posted.

Testing: We have mobile apps for iOS and Android entering alpha testing in the next coupld weeks, and we are always looking for people to test Peerio and give us detailed feedback. No technical experience is required and we welcome organizations looking to test among their team. We want to know if you think the settings buttons are in weird places, if you don’t like the font, if the sounds are hard to hear, anything! Add ‘testing’ on Peerio or send an email to [email protected] with your feedback or to ask about testing opportunities.

It’s only been a couple weeks since our 1.0.3 update, but we’ve made some large strides forward since then. Today, we're releasing Peerio 1.0.4.1 with a big user interface update, a couple new features, and performance improvements all around. Meanwhile, we’re exceeding all expectations on mobile development, and have a little preview along with some exciting timeline updates. Then in a couple weeks, we’ll be taking a trip to Washington D.C. to talk privacy and encryption with the ISC Project. Get all the details below.

User interface

For 1.0.4 we designed a fresh new UI that we’ve been loving in our internal testing.

You’ll notice that unread messages have been given a white backdrop to make them more visible and draw your attention.

We’ve moved account preferences and settings to the bottom of the left sidebar, and added users’ crypto-avatars here to make them more visible and easier to remember.

(1.0.3 top, 1.0.4 bottom)

We used the extra space in the top bar to tidy up the layout of the section tabs and search bar, giving plenty of space to each, and making them more visible and easier to navigate.

Changes to signup

In previous versions of Peerio, we asked users to define their own passphrases which would be used to secure their account. We've found that this approach is problematic: users sometimes forgot their passphrases, and, despite our best attempts, we simply could not be certain that users were picking passphrases that were secure enough to protect their information.

 In this latest update, we're changing that: now, Peerio will suggest a secure passphrase for you. We believe this approach will make it less cumbersome for new users to come up a good passphrase, and generally guarantee a better standard of security for all users.

We're also working on allowing users to revoke previous passphrases and set up new ones. This is a complex feature that we're working on, but we expect to have it ready soon.

Authentication

With 1.0.4 you can now easily check your contacts’ miniLock IDs. Just head over to the contacts tab, select your contact, and you’ll find their miniLock ID below their name. Don’t know what a miniLock ID is? Learn more here.

Better sync across devices

We’ve made some big improvements to cross-device data synchronization. With 1.0.4, if you upload a file on your desktop, the file will also immediately be available on your laptop.

This makes secure file transfers between your computers fast, secure, and easy. Simply load Peerio on your computers, upload a file on one, download it on the other, and you’re done.

Improvements and bug fixes

We made a number of small improvements and bug fixes:

Fixed issue with two-factor authentication sometimes requesting two authentication codes

Improved support for Chinese characters

Removed character limit for inviting contacts (fixed in 1.0.3.1)

Synchronization improvements for message viewing

Some speed improvements

Mobile development

Peerio for mobile has made huge incredible progress in the past two weeks. We’re ahead of all our deadlines and just couldn’t resist sharing a sneak peak of what this is looking like on our end.

Of course, this is only a preview from our development team. You will be able to set a shorter PIN on mobile like your computer, and there will be improvements to load times and a few other small design changes. Still, we’re all teeming with excitement to start testing the alpha version of the apps in-house this week. Yes, apps. Peerio users can expect a simultaneous beta release for Android and iOS by early April, if not sooner.

If you’re interested in alpha testing Peerio for Android or iOS and want to help with usability assessments, bug catching, and other improvements, send a message to [email protected] to get on our testers list!

Peerio goes to Washington DC!

On March 11th, we’ll be presenting Peerio and talking encryption and security with local DC activists, developers, State people, and others in DC. The event is hosted by The ISC Project, an organization that works with developers to train, educate, and provide tools to social organizations, human rights activists, and independent media on matters related to information security. It’s free to attend, and you may be able to score some limited edition Peerio vinyl stickers if you’re there! Check out the details here.

What’s next?

Aside from the big news with mobile, we’ve got a lot lined up for our 1.0.5 release. The 1.0.5 release will focus on usability improvements and refining of existing features. You can see what we’re working on for this by checking out on our GitHub, here.