WARC-Identified-Payload-Type: application/atom+xml

text:
Session Blog 2021-09-28T07:35:41.720Z Next.js using Feed for Node.js Send Messages, Not Metadata! All rights reserved 2021, OPTF <![CDATA[Session Release Roundup #13: It’s all about the UX]]> 1ZJ4fyKOz8rXYocniqYXFj 2021-09-15T22:00:00.000Z It’s been quite a while since we’ve done one of these, so we’ve got a lot to catch up on. Normally when we bring these to you we have a single big ticket item that dominates the column inches. Not so this time, instead we have a theme — we’ve been tirelessly tippy-tapping away over the past several months at a whole suite of quality of life improvements for our lovely Session users.

From the new look Android conversation screen to new translations to just plain performance boosts, we’ve got a lot to cover, so read on for a rundown of all the latest and greatest changes!

Just a touch-up thanks!

  • Closed Group improvements (Android, iOS, Desktop)

This is a pretty broad one, encompassing quite a few tweaks and improvements to make closed groups run silky smooth. For more details on the specifics you can always check out our dev updates.

  • Performance improvements (Android, iOS, Desktop)

I promise it gets more specific down further, but I don’t want to bore you with all the details of how we’ve improved Session’s performance when the important thing is that we’ve done it. If you haven’t used Session in a while, give it a go, you’re sure to notice the difference.

  • Update and add new translations (Android, iOS, Desktop)

We’re all about making sure that Session is as accessible as possible. Privacy is a human right, and that doesn’t just apply to the English speaking world. Whenever we can we’re adding new translations of Session and improving the ones we already had. In terms of new translations we have Japanese, Hindi, Croatian, Swedish and Thai — plus a whole heap of updates to existing translations.

  • Improving the way Session handles when things go wrong (Android, iOS, Desktop)

We’re not going to lie to you, Session isn’t perfect. Onion routing is hard and things tend to go wrong sometimes. So we’ve made a few changes to make sure Session knows what to do when that happens — logging, retrying, and giving better error messaging if it can’t resolve the issue automatically.

  • Conversation screen UI overhaul (Android)

A fresh new coat of paint for the screen you spend the most time looking at. Easy on the eyes and easy to understand. Brings Android in line with the makeover that iOS got last time.

  • ONS Resolution (Android, Desktop)

ONS is here and it’s ready to change the Session game. You can now add your friends with their ONS names instead of having to copy and paste their long Session ID. It’s the efficient life for me, and hopefully for you too. Of course if you’re on iOS you might be having some deja vu right now. Don’t worry that’s perfectly natural, you’ve had this for a little while now, Android and Desktop are just joining the party!

  • Group notification settings QoL changes (iOS, Android)

  • Group notification settings for specific groups (Desktop)

You now have the ability to only be notified when tagged in a group chat, to reduce notification overload. We love our Session groups, but sometimes when they’re popping off it can be too much. If you’re on Desktop it’s even more specific — you can change the notification preferences for individual groups.

  • Path Display (Desktop)

Plenty of people have told us they love the path display feature on our mobile clients, so we brought it to Desktop too. For those of you not in the know, the path display shows the locations (just the country) of the Service Nodes that your messages are hopping between.

  • Audio message play speed controls (Desktop)

Look, we get it: you’re busy. There’s just not enough time in the day — and we’re here to help. Now you can get all of your daily listening down in record time, and the bonus of making everyone sound like a chipmunk — who says efficiency can’t be fun?

It’s the big one

If you’ve been following along at home you may already know this, but for everyone else we have some big news  — voice and video calls are coming. We’ve been working at this over the past couple of months and we’re very pleased to have made big progress already. After an extensive process of determining how to go about making the world’s first onion routed voice/video call system we settled on using webRTC over Lokinet, and it’s been a whirlwind from there.

As it stands we’ve knocked down two big milestones: successful voice/video calls through Session over clearnet, and the big one: successful onion-routed voice/video calls through Lokinet. From here we have to bring the two together, which is a task that probably sounds a lot easier than it is. Not to worry though, we don’t back down from a challenge and I have a pretty good feeling that the next time you hear from us in roundup form we’ll be telling you about our exciting new feature.

Of course we’re not a one track mind here at Oxen, and we wouldn’t want you to think that’s all we’ve got coming down the pipeline. We’re also on that eternal grindset — smashing bugs, improving performance and ensuring your privacy.

Phew, that was a lot. Take a minute to catch your breath and try out some of the new bells and whistles — but not too long because we’ll be back with more before you know it!

Thank you!

Without you dear reader, and others like you, we wouldn’t be able to do any of the things we do. It’s comments and suggestions from users like you that help us build the app you want to use, so keep the feedback coming, and we’ll keep grinding away to make Session the best private messenger we can. As always, thank you for your feedback and your support!

— The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[Why are phone numbers a privacy problem?]]> 58a3G4iFuNnUOki0Go8Dnu 2021-09-13T22:00:00.000Z Phone numbers are not private. Using your phone number can put your privacy at risk. If you’ve spent much time around the privacy movement, you’ve probably heard countless people lament the privacy shortcomings of phone numbers. It’s a huge problem, and phone numbers remain the achilles heel of plenty of privacy-focused apps such as Signal and Telegram. Avoiding phone numbers was one of our core design goals from the very beginning, and anonymous sign-up is one of Session’s most-loved features. But because the opinion that phone numbers are a major problem is so widespread, sometimes people don’t stop to explain it.

For a long time, phone numbers were just a piece of contact information. You might trade numbers with friends in the schoolyard to call them later that night, or a hospital so they can call you up with your test results. There was an obvious connection between the utility of a phone number and the people who asked for it. But nowadays phone numbers aren’t just contact information (they’re still that too, though), they’re also identifying information. Somehow phone numbers have become a pseudo-social security number that’s used to verify your identity for pretty much any online service that requires an account. While this makes phone numbers an obvious security threat, it also incentivises a bunch of behaviour that makes phone numbers a privacy nightmare.

Bonded for life: When was the last time you changed your phone number?

Phone numbers are critical to the way we move about the world these days. Pretty much every service that lets you make an account—including essential services like banking and health—use your phone number for verification that you’re the real human that you’re claiming to be. This ever-increasing dependence on phone numbers makes it a logistical nightmare to try and change your phone number, and because of this...people just never change it.

Even as a privacy-conscious person, it has been years since I updated my phone number. Changing my digits wouldn’t just mean that I have to sit down and spend hours tracking down and change my on-file phone number at my doctor’s clinic, gym, work, and a million other places — it would also mean that hundreds of contacts from years of professional and personal number-sharing would (effectively) lose my phone number. Even worse, if my old number ended up getting recycled, then my personal messages could end up in someone else’s inbox.

Because of all this, people end up changing phone numbers less often than they change their actual, physical address. This is a big problem — over the years, you’ve probably entered your phone number into long-forgotten websites, petitions, and apps, and now your phone number is buried deep in all corners of the internet.

Match made in heaven: Databases linking you to your phone number

Because phone numbers are semi-permanent pieces of information about you, it makes it really easy to create up-to-date databases which link your real identity with your phone number. In lots of countries, you can’t even get a phone number without being on a government operated registry. And to make matters worse, this linkage can follow you across every platform where you provide your phone number.

That means that even if you sign up to a platform like Twitter with a fake name and a pseudonymous handle, as soon as you verify the account using your phone number it’s simple for Twitter, the authorities, or even other people to work out who’s really operating that account.

Some experts have even suggested that having someone’s phone number is more useful than their social security number if you want to dig up information about them. That’s because phone numbers are in the middle of the Wild West of information exchange. Your phone number is affiliated with hundreds of databases, and a lot of the time phone numbers flow freely along information pipelines.

Digging up the past: Phone numbers and metadata

Because of all this, phone numbers are one of the most valuable pieces of metadata that services can store. Using nothing but phone numbers, apps that might seem private become extremely vulnerable. This is especially the case for messaging apps like WhatsApp, which boast about their end-to-end encryption, but fail to mention how their account system leaves its users vulnerable.

Unfortunately, it is this precise vulnerability which exposed former Treasury Department official Natalie Edwards — a whistleblower who worked with Buzzfeed to disclose information about suspicious banking transactions evidencing Russian interference with American politics. Now, Edwards is serving a six month prison sentence for exposing this corruption.

Metadata collected and provided by WhatsApp proved pivotal in the arrest and conviction of Edwards, with hundreds of messages between Edwards and a Buzzfeed reporter successfully connecting Edwards to the leak. The time and frequency of the messages were strong evidence — because the phone numbers of both Edwards and the reporter used on their WhatsApp accounts were easily linked to their real identities, even if the message contents were encrypted.

Edwards’ story is unfortunate, and their work is commendable, but unfortunately the deliberate positioning of WhatsApp as a ‘private messenger’ led them to believe that a fundamentally flawed application was safe for them to use. This is just one such example, but there are undoubtedly many cases where the traces left behind by phone numbers have jeopardised the privacy and safety of people around the world.

Ditching those digits: Moving on from phone numbers

The privacy problems which phone numbers introduce are extremely well documented, but lots of major platforms are still hesitant to move on from the phone number standard. They are convenient, well-explored, and just plain valuable. But having said that, it’s time for us to break up with phone numbers — at least for the purpose of being a digital identifier.

With Session, we’ve chosen to use public key encryption instead, which is an inherently ephemeral solution that gives users a whole lot more privacy. As more projects build platforms which don’t require a phone number, it’ll become easier and easier to write off apps that won’t give up on phone numbers. It’s time to leave them behind — things were never meant to be like this.

<![CDATA[On the recent Australian surveillance legislation]]> 24A0GmHvlbH12WfwI02nCX 2021-09-08T22:00:00.000Z Regulators are increasingly acting with open hostility towards encryption, security, and privacy. The latest chapter in this sorry story took  place in our own backyard when Australia’s government passed a new bill granting the Australian Federal Police (AFP) and the Australian Criminal Intelligence Commission (ACIC) new surveillance capabilities. Because Session is built in Australia, we’ve always kept a close watch on emerging regulation in Australia as well as the other Five Eyes countries. Unfortunately, this isn’t the first time Australia has rushed an anti-encryption bill into law, with the infamous Assistance and Access Act speed-running through Australia’s parliament in 2018.

Because surveillance capacities are being expanded and strengthened all over the world, Session’s design takes this into account. After all, the people using Session are often vulnerable people living and working in the most highly surveilled places in the world.

So where the bloody hell are you?

Choosing to build Session in Australia is something that has always raised eyebrows for people who are privy to the Five Eyes intelligence alliance. Why wouldn’t Session be based in Russia, Switzerland, or...just anywhere with a less hostile regulatory environment, really. type: embedded-entry-inline id: 3iTWYQJxxvJq1VM3QsNSQIThe answer is simple: running away from regulators is not a sustainable future for private tech. No, the solution is to build technology which is actually resistant to surveillance and other encroachments on people’s personal privacy.

Local regulatory environments are always evolving and changing, and it’s not viable for development teams to pick up and move to the latest privacy haven every time their local laws change. An (unfortunate) recent example of this is ProtonMail. type: embedded-entry-inline id: 5pr3ElihOzdEEF0RFrVG8YWhile ProtonMail is widely trusted by the privacy community—I use it myself—and they’ve done awesome work spreading private, encrypted services to lots of people, there was a view ProtonMail could operate with impunity because they were based in Switzerland. So strong was this belief, that being Swiss was a core part of ProtonMail’s branding.

But the Swiss is safe mantra copped a body blow when it was revealed Swiss authorities compelled ProtonMail to share the IP address and device information about activists in France. This information reportedly resulted in the arrest of a climate activist, and now ProtonMail has deleted the claim they ‘don’t log your IP’ from their website

While credit has to be given to Proton for remaining relatively transparent about this incident, it serves as an excellent illustration of the problem with placing too much importance on where a company is domiciled. While it’s an important aspect to consider, the technological design should always be a part of the evaluation as well. No matter how friendly government authorities might seem, when push comes to shove companies must always comply with their local laws. In this case, because of the way email technology and ProtonMail are designed, the Proton team simply had no legal alternative.

What this means for Session

The Session team has always been prepared to face regulatory hostility. Before a single line of Session code was written, we were pondering how to make sure the app itself would always remain a safe, secure place for people to communicate.

Decentralisation is at the heart of Session’s design. While it’s true that Session’s main development team is based in Australia, its infrastructure is spread all across the world. Over 1,500 community operated servers are currently routing Session messages for over 150,000 users. The network is growing all the time, as more and more people commit to upholding the privacy of Session’s users by running their own server. The team hasn’t got any way of accessing these servers, and we will never have the capacity to gain access.

Session is designed to minimise the amount of data required to deliver a message from one person to another. That data is also spread across many, many servers operated by many different people in different jurisdictions all over the world.

The whole point of Session is to keep its users safe — no matter where in the world they are.

The beating heart of privacy

Before we finish off this article, it’s important to criticise this legislation and its consequences — not necessarily for Session, but for all Australians. In Australia, this is the second major piece of legislation we have seen in the last few years which greatly inhibits the privacy of Australian citizens as well as jeopardising the future of several Aussie tech companies.

The right to privacy is enshrined in the UN’s Universal Declaration of Human Rights (UDHR). Australia sat on the Drafting Committee for this milestone human rights document and was one of 48 countries which voted for its adoption.

“No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.”

Article 12 of the UDHR

Due to the grossly insufficient safeguards contained within the recently passed Identify and Disrupt Bill, Australia is failing to uphold its commitment to protect the privacy of its citizens.

The contemporary issue of privacy rights is deeply entangled with the concept of digital privacy and security. For Australians to enjoy the right to privacy as described in the UDHR, guarantees around the privacy of digital information is absolutely necessary. Because the Identify and Disrupt Bill doesn’t mandate any judicial oversight (by requiring a warrant), it’s also a possible concern that (as a consequence of weakening of the right to privacy) the act could lead to the contravention of other rights — such as people’s implied right to freedom of political communication, which is provided for in the Constitution of Australia.

In the future, the government should consider more carefully the rights of its people, as well as the recommendations made to them by the relevant human rights experts, before rushing amendments through its parliament.

Looking forward

As disappointing as attitudes towards privacy and encryption are, it is not entirely unexpected. We hope that, as the world moves forward, everyone will have the ability to navigate the digital world peacefully and privately. That’s the future Session is contributing to, and rest assured that the Session team is extremely dedicated to that vision. But for the time being, the most popular technology is centralised, and this kind of regulation punches a huge hole in centralised tech’s ability to remain private — even for platforms with the best intentions. That’s why engineered solutions like Session’s decentralised infrastructure are so important for the future of technology — without it, no service (regardless of where it’s based) can guarantee your privacy.

If you’ve got any questions for us, feel free to get in touch with us using the Session open group (on Session, of course).

<![CDATA[Deleting messages and time-to-live: This message will self-destruct in…]]> 30pUJLbm457I65c6FmKhz2 2021-09-05T22:00:00.000Z Digital conversations are fundamentally different to real-world conversations. When you have a conversation over text, you’re creating a record. The record you create will persist long into the future, and there are a lot more details etched into that record that you’re probably not thinking about every time you send a ‘how’s it going’ or a ‘let’s catch up soon’.

Those details—like when a message is sent, who it’s sent to, and what’s in the message—can quickly paint a high fidelity picture about your life, especially when you consider just how many different conversations you’re having over text every single day. Chats and channels with our friends, family, and work colleagues are flooding our notification centre at all hours of the day. Each ding and buzz signals another entry into your digital record. Messaging apps can go to great lengths—using complicated encryption and networking protocols—to keep the info about you and your messages between you and your friends and family, but as long as that record exists in your DMs, there isn’t a 100% guarantee that info can’t (or won’t) be leaked.

Most people are carrying enormous records around with them in their pockets all the time, records of conversations from years, maybe even decades ago. My most active group chats can rack up tens of thousands of posts a year, and I’m in a bunch of them. Sometimes this can be seen as a good thing, letting us look back at old messages and reminisce about the good ol’ days, but there is another, darker side to the coin.

As long as that record exists, you’re effectively stuck trusting everyone you’ve messaged to keep that information private FOREVER! To be clear, I’m not saying you need to be wary of any Days of Our Lives style backstabs where your friends post your entire chat history online for all to see (although I’m also not saying you shouldn’t be worried), but there are lots of different ways that record could be compromised — by hacks, legal authorities, or a voluntary leak.

Message hoarders: Messaging apps that never forget

Every time you send a message using a messaging app, you actually send a message to that company’s servers, and they then forward that message onto your recipient. This is just a practical necessity for any (non peer-to-peer) messaging solution, there isn’t anything suspicious or nefarious about it, although if your messages are stored long-term—which is a common practice for things like cloud back-ups—then it could leave you vulnerable in case those servers are ever compromised for any reason.

In the case of messengers like Signal and Session, you can rest easy knowing that any messages stored on server are encrypted, and can’t be read by the company at all. In the case of Session, there is also something called time-to-live, which goes an extra step further.

Session is decentralised, so its servers are owned and operated by lots of different people all over the world. This leads to lots of awesome privacy benefits, and prevents the formation of large data honeypots that might catch the eye of hackers — but it also leads to some added complexity over centralised solutions, like Signal.

Session servers will only ever store your message for two weeks — known as the message’s time-to-live (TTL). This means that even if a server was somehow compromised, only information about the newest messages (which would remain encrypted) could be seen, not entire chat histories. This also means that if your recovery phrase is compromised, an attacker wouldn’t be able to restore your entire conversation history upon backup. The obvious downside of this is that when you are restoring using your recovery phrase, you can’t (currently) retrieve old messages. That sacrifice is made to help ensure message privacy remains intact at all times — remember that every time you’re able to load all your old messages onto a new device or login, that’s because they’re permanently stored in a data centre in a faraway place.

Ticking time bomb: Self-deleting messages

Self-deleting messages have become one of the most popular features in private messaging apps. Some apps, like Wickr, even have this feature turned on by default. This makes all conversations completely ephemeral, and makes that permanent text record a little more temporary — so conversations end up feeling more like in-person, face-to-face conversations.

Session’s disappearing messages live inside the conversation settings for each of your contacts. This means that you can switch on disappearing messages for one conversation, but keep a record in another (perhaps less sensitive) conversation. When you’ve got disappearing messages enabled, they will automatically delete from both devices once they’ve been seen by the members of the chat.

If you want to, you can also delete all of your locally stored messages by going into your app settings and tapping Clear Conversation History. This will delete all the messages stored on your device in case it’s compromised. If you want to completely erase all of your contacts as well as your Session ID, you can also hit the big red button in your settings that says Clear Data — once you hit this button, it’ll be like nothing was ever there. Keep in mind that this won’t delete messages your chat partners have stored on their devices.

Final words: Don’t store data you don’t need

If you’ve got data sitting around on your phone or desktop, don’t be afraid to take the Marie Kondo method and start discarding and decluttering those hard drives. Data that’s (properly) deleted can’t be leaked, so it’s a good habit to clear out your backlogs every now and then.

Avoid using applications and services that are clingy with your data. Depending on jurisdictions, some companies may be compelled to store data for a certain amount of time, or delete it after a certain amount of time — or both! Do your research, and don’t be afraid to keep notes about the digital record you are leaving behind when you use your tech.

<![CDATA[Contact discovery: Finding friends without foes]]> DTOXL0hQw9163Vf7Dluxk 2021-08-08T22:00:00.000Z Messaging platforms aren’t useful if there’s nobody there to read your message. That holds true for every single piece of communication technology, whether it’s smoke signals, telephones, or Session. The social network rules all.  The more people you know using an app, the more likely you are to use it. This is a well established fact in the tech world, and everyone is tweaking and designing their apps and services to try and hitch their wagon to the fabled network effect.

Generally, the network effect is spoken about in positive terms —the network effect can help you grow, the network effect is key to user retention, the network effect is how unicorns are born—but there is another, darker side of the network effect coin. The network effect helps concentrate more and more value into apps as they grow. More users, more value. But there’s a tipping point where an app becomes so large, so massive, that it creates a gravitational pull which prevents users from leaving. This is one of the biggest reasons people don’t move across to privacy-focused alternatives — they’d be leaving behind all the people they want to interact with, and that’s too much of a sacrifice. Everyone knows someone who still uses WhatsApp because ‘everyone is on it’. It’s the flip side of the network effect that ends up stopping better versions of established services falling flat on their face. When it’s working for you, the network effect can make your app grow faster than any advertisement, endorsement, or innovation. When it’s working against you, the network effect can banish your app to the shadowy depths of the app store.

The early days: Pseudonymous chat rooms

As the internet started becoming a tool for direct communication in the 1990s, it was IRC chat rooms, AOL instant messenger, and email that sprung into life. People would trade details with others they knew in real life, or just chat with anonymous internet strangers. In chat rooms, people were known by internet handles that were disconnected from their real identities. You weren’t Jane Smith from Skaneateles, New York, you were type: embedded-entry-inline id: 3SRM8j3E68QQpcDcu1zzu7

At the time, the internet was a much smaller place. It was full of some people you knew in real life, and a lot of people who you’d never know outside of cyberspace. Most of the time, people’s real-life social circle was wider than their pool of ‘online’ friends, you might have a few friends you’d login and chat with on MSN messenger, but that person you met at a party one time wasn’t sliding into your DMs. People had their real-life identity, and their online identity. It worked well for a while, but as the internet became a core part of our personal and professional lives, people’s real-life and online identities were funnelled into the same pot.

The social network: Public posting and online sharing

As Facebook, Twitter, and Instagram became social media goliaths, the real/online merger became unavoidable. People signed up to Facebook with their real names. Posted pictures of themselves on Instagram. If you didn’t, how would people find you?

As sharing your real identity online became more normal, hiding it became more suspicious. Signing up to sites with your name and a picture became completely commonplace. That type: embedded-entry-inline id: 3SRM8j3E68QQpcDcu1zzu7 email became type: embedded-entry-inline id: jSTBDtgADVMPTyclDC26P. The real/online convergence made it easy to make online connections with every single person in your social circle. Add someone you met once, or even just a friend of a friend. LinkedIn replaced the rolodex. Phone books were replaced with ‘DMs open’.

On Facebook, you could look people up by name, check who your friends were friends with, and it suggested ‘people you may know’. Finding your friends was easy, and it was the key to the success of the platform. As people’s Facebook friend counts ballooned into the thousands, Facebook’s power grew. People were locked in. By the time the 2010s rolled around, a new online etiquette had become well established: identify yourself when you’re chatting, interacting, and existing in online spaces.

Although high discoverability propelled Facebook to the top of the social media mountain, eventually people started taking note of the privacy issues associated with making it so easy to find other users. Facebook and other social media sites soon started rolling out privacy settings that allowed people to control who could find them, who could see their posts, and what content they saw. These kinds of settings proved super popular, and nowadays the average person has at least some of the privacy settings enabled on their social media accounts.

Of course, this chills the network effect that made Facebook and other services like it so popular in the first place — and new players joining the game have to play using hamstrung discoverability.

The phone number: Tapping into contacts

The age-old phone number has become the diamond standard for identification on social media applications. Most apps use phone numbers to confirm your identity, secure your account, prevent fraudulent accounts, and help you find people you know. That’s a whole lot of identity for one string of numbers. As more and more apps require you to sign up with your name and phone number, countless databases around the world end up linking your real-world identity with your phone number. This is why you’re bombarded with permission requests for your phone contacts every time you download a new app, and it’s often how apps suggest friends or people you might know.

Your phone number is recorded by things like Twitter, government services, event and location check-ins, and even supposedly private messengers. But using a low-velocity piece of identifying information like a phone number for contact discovery has a whole bunch of negative privacy implications.

There is nothing private or anonymous about a phone number. Nowadays, countries around the world are going to great lengths to make sure phone numbers are closely linked to people’s identities. This reduces digital privacy, and makes it much harder to navigate the online world with any anonymity. Registries and telecommunication regulations are becoming super common all around the world. In June 2021, the Senate of the Republic of Mexico passed a decree which requires citizens surrender  bevy of personal information in order to activate a phone number.

Similar registries are being created all over the world by both public and private institutions, and working out which phone number belongs to who is trivial for most big tech companies or governments.

Research published in 2021 showed crawling attacks are not only possible, but viable against major messengers which rely on phone numbers for contact discovery. The study completed an analysis of phone numbers linked to WhatsApp, Signal, and Telegram. Using minimal resources, the researchers were able to check all 505 million phone numbers in the United States for Signal registration. They were also able to cross-reference these registrations with the other services (WhatsApp and Telegram) to check for other personal information like profile pictures, ‘About’ text, and statuses.

To make matters worse, once you have created this database of Signal users, you can continually re-query the phone number list in order to check if new numbers are registering, as well as an approximate time period they would have created an account.

All this is a really long way of explaining that phone numbers are a familiar, comfortable, and terribly non-private way of getting in touch with your friends. If you’re looking for something private, and it asks for your phone number…well, that’s a pretty clear sign it’s not private.

The Session ID: A cryptographic contact solution

For an app to be private, it needs to have private contact discovery. Phone numbers are a catastrophe. Using people’s real names is obviously not a winning strategy either. Using pseudonyms can help, and gives people the ability to choose whether they want to de-anonymise themselves for simpler discovery (by using their real name, for example, as their handle).

However, we can go a step further than simple pseudonyms. Session uses Session IDs for contact discovery. Session IDs are the public half of a public/private key pair. This can be created any time, any where, all on the device running the app. Public key cryptography is also the basis of Session’s end-to-end encryption system. Using someone else’s Session ID (public key), you can encrypt and send messages that only they can decrypt. Specifically, Session uses the Ed25119 signature scheme, which can be easily executed by any modern phone or computer — so nobody can control when you’re able to create a Session ID. When you’re using a Session ID, you can’t be censored, SIM swapped, or tampered with in any way.

This also means that, if you want to change your Session ID, you can make a new one (instantly) whenever you want. If your ID is compromised for any reason, you can delete it and move on to a brand new one without any association with either your old Session ID or your real identity. This gives Session IDs a huge advantage for high-risk users like journalists, activists, and other human rights defenders — who are being targeted more and more with each passing day.

The way forward

Of course, Session IDs tick all the boxes in terms of security and privacy, but they don’t have the same contact discovery sparkle that using names or phone numbers has. As the world becomes more and more tech literate, this might not be as big of a problem. But on the other hand, as people grow up with more and more polished tech, tolerance for things like Session IDs might become lower. However, we’ve built a system to allow people to look each other up using simple nicknames instead of long Session IDs — all while maintaining all the privacy and security benefits anyone could ask for. Phew. That was a long explanation. But it goes to show how much thought is put into every aspect of modern messenger design. The threats people face in the digital world can be extremely complex, so often the solutions are, too.

<![CDATA[Communication Cooperative: A messaging app that can't sell out]]> vcgEEqEmglPZXGMa1XMYE 2021-07-25T22:00:00.000Z By the people, for the people. That’s the basic idea of a cooperative (or co-op for short). Co-ops are like businesses, but with extra assurance they’ll honestly and earnestly serve the people who actually use a service. Co-ops are all about getting out what you put in. Every cog in the machine benefits according to how much they actually contribute. No fat cat CEOs filling their pockets thanks to exploited and overworked employees.

Normal tech companies don’t operate like co-ops at all. They’re traditional companies that provide a service in order to make a profit and please investors. Most tech startups rock up on the scene with innocent intentions and big promises. But even though they start out with starry-eyed ambitions to build a better future for tech, most successful startups are doomed to become tech villains. This is because of the way tech companies are normally set up — for profit. In the end, who do tech companies really serve? Investors, of course. Of course, this won’t stop companies from trying to convince you they’re on your side using tactics like privacy washing, but there is no hiding who is really numero uno in the hearts and minds of global corporations.

Apps starting with W: The sellout cycle

The private messenger arena has crowned its fair share of new champions over the years. When it first arrived on the scene, WhatsApp brought end-to-end encryption to a mass audience in a way no other application had ever done before. WhatsApp became a more private, specialised alternative to social media platforms like Facebook. But…then Facebook bought WhatsApp. WhatsApp isn’t a Facebook alternative, WhatsApp is Facebook. Facebook’s new US$ 19 billion acquisition was a body blow for privacy enthusiasts. Lots of people immediately ditched WhatsApp, but the company kept promising it would remain independent from its new megacorporation overlord.

Just a handful of years later, another wave of users fled from WhatsApp as it made key privacy policy changes that allowed for more data sharing with (you guessed it) Facebook. Of course, when Facebook spent so much money on WhatsApp — and more importantly, its users — it was inevitable they’d benefit from it eventually. Publicly, the ship sailed on its own for a while. But WhatsApp founder Brian Acton’s accounts of his time at the company after Facebook stepped in show the powers that be always planned to fully absorb WhatsApp into the data-harvesting, user-exploiting, privacy-smashing tech-blob known as Facebook.

Now, the same is happening to Wickr. Although Wickr never reached the heights of WhatsApp — and now, it probably never will — it was a widely used and trusted messaging app. Now, Wickr has been bought by Amazon.

type: embedded-entry-inline id: 3ld2oFvS10ZIlYH2qJNJS2Expect the same old line about how this doesn’t mean Wickr is going to change. And expect the same old outcome where Amazon’s business interests are more important than the interests of Wickr’s users. It’s not personal. It’s just business.

We need to build a better system. For-profit companies will always look out for themselves first. When it comes to basic needs like communication, we need stronger guarantees that people won’t be exploited by the tech they use to converse and connect. After leaving WhatsApp, Brain Acton helped create Signal, this time using the Signal Technology Foundation — a registered not-for-profit. This is a step in the right direction, but how can we make the tech itself, the very infrastructure of a messaging app, or even the actual app, more open and equitable? Not just an oath, a charter, or a constitution promising to work in the interest of your users. Well, the option we chose: write it straight into the code. Designing a system that gives users the power to choose for themselves.

Session as a cooperative

We designed Session from the ground up to be run by the people, for the people. Not only is the governing foundation behind session, the OPTF, a registered Australian not-for-profit, we’ve gone a step further.

In the past, we’ve talked about Session being decentralised and what that means in the context of private messaging. From a technical perspective, decentralisation hardens Session against censorship and surveillance. But there’s another way of thinking of what decentralisation means — it effectively makes Session a co-op.

All of Session’s servers are owned and operated by the community. By people like you. People who care about privacy. People who prize encryption. People who use Session. These people will never turn their backs on the values Session is built on. You will never wake up to news that a mega corporation has bought Session. Session is not for sale. Ever.

The more Session grows and succeeds, the more the people who use, own, and operate Session — which is people like you — will benefit. It’s totally reasonable, understandable, and predictable to see tech companies sell out in the end. And that’s exactly why we haven’t set up that way.

Creating tech for good

Models like Session’s should be a huge part of the future of public interest technology. Session’s design, infrastructure, and implementation give the highest possible confidence that the tech itself is acting in your best interest.

There have been lots of privacy saviours who have come onto the scene over the last decade. The reality is, all this chopping and changing ends up costing people. People who are slow to respond to the changing tides — like an application getting sold off to a big tech giant — end up being left behind. On top of that, it creates a whole lot more overhead for people who want to preserve their privacy. Staying up to date with news, learning about new applications when the old one sells out — all of this contributes to the feeling that privacy is just too hard

It’s time to change for good.

Code is the regulation of the future. The old saying is ‘get it in writing’ if you want to make sure a company, business, or person remains accountable to you. Don’t get it in writing — get it in code.

<![CDATA[Privacy propaganda: The war on encryption]]> 1YMxVgKMztC8jEh4FOdGA0 2021-06-22T22:00:00.000Z Encryption doesn’t mean encryption. Encryption is a code word that stands for freedom of speech, the free press, and the preservation of the human rights we all hold dear. Encryption is a weapon that’s pointed directly at the biggest, most concentrated powers in the world; encryption makes those in power accountable and helps protect vulnerable people from exploitation. Recently, we’ve seen the powers that be take a few wild swings at encryption and attempt to depict it as a mystical and nefarious evil wizard technology used exclusively faceless hooded figures. Anyone who knows anything about encryption knows this isn’t true: encryption is actually used every single day by basically everyone and anyone who owns a computer.

Even though encryption is a perfectly commonplace technology that’s used by every bank, business, or school in the world, that’s not what most regulators and lawmakers are really worried about. Nope, it’s end-to-end encryption (E2EE) which is in the crosshairs. End-to-end encryption can be used in lots of different ways, but it’s most famous for helping keep messaging apps private and secure. For lots of people, that’s not just useful — it’s essential. Nieman Lab’s guide to help journalists protect their sources highlights the importance of using encrypted communications (as a minimum) and keeping an awareness of the  “digital data trails” that can be used to identify sources.

Recognise that encryption defends press freedom through support for the privacy of confidential digital communications with sources and whistleblowers.

Nieman Lab, ‘Here are 12 principles journalists should follow to make sure they’re protecting their sources

Encryption goes mainstream: the birth of a public enemy

Edward Snowden and President Barack Obama both spoke at the 2014 SXSW conference, each highlighting different sides of the encryption coin. On the surface, President Obama treaded carefully when pushed on the encryption issue. President Obama warned “you can’t take an absolutist stance on this [encryption]” and that a balanced approach was necessary. He  urged technologists to innovate in order to solve the debate over backdoors versus true security, but therein lies the issue: there is no compromise. President Obama hoped for a version of encryption that was super secure yet breakable when you really, really needed to break it.

There are very real reasons why we want to make sure the government cannot just willy-nilly go into everyone’s iPhones

President Barack Obama at SXSW 2014

Solutions that use end-to-end encryption don’t allow for that ‘really, really need it’ situation, but they also protect perfectly against the ‘willy-nilly’ situation. With this in mind, it makes sense that Edward Snowden supports end-to-end encryption — it was ‘willy-nilly’ violations of citizen privacy which he originally worked to expose.

However, if end-to-end encryption can’t be broken on a technical level, maybe it has another weakness that can be exploited — a public image issue. It’s often the case that highly technical things are only understood and used by highly technical people. This means most people don’t really understand how encryption works, why it’s so important, or why they might want to use it. In his SXSW address, Snowden stressed how important it was not only to use encryption, but to explain it.

We need to think about encryption not as this arcane black art but as a basic protection

Edward Snowden at SXSW 2014

Since Snowden spoke in 2014, we’ve seen an effort to depict encryption not only as an arcane art, but cause for suspicion for anyone using it.

Once upon a time, in a place not so far away…

This article was prompted by some of the things we see and hear right here in Australia. Australia has a well documented history with anti-encryption legislation, most famously with the Assistance and Access Bill which sparked a lot of fear and anxiety in the tech community when it passed Australian parliament back in 2018. This time, a different piece of legislation is under the microscope, dubbed the Identify and Disrupt Bill, this proposed amendment to Australia’s surveillance laws would give law enforcement and intelligence agencies wide ranging powers including “modifying, adding, copying or deleting data”.

The Australian Criminal Intelligence Commission (ACIC) made a submission to the parliament about the proposed amendment, and in their submission they made some…rather sensational claims. Their submission had us raising our eyebrows so much we decided the time had well and truly come to call out this trend of hostility towards encryption.

…there is no legitimate reason for a law-abiding member of the community to own or use an encrypted communication platform.

Australian Criminal Intelligence Commission submission to the review of the Surveillance Legislation Amendment (Identify and Disrupt) Bill 2020

Supposedly avoiding state surveillance like the NSA’s illegal program which spied on regular citizens, opting-out of surveillance capitalism, and the work of journalists, activists, and human rights defenders isn’t legit. The narrative being pushed is that encryption is a magic lock-box with mysterious powers that only evil-doers can make use of. The rhetoric is that people should be afraid of encryption and the existential threat it poses to our community. The justification for these wide ranging powers is, naturally, to fight against the threat of crime and terrorism. Just causes — obviously — but we’ve heard all this before.

Back in November 2018, Home Affairs Minister Peter Dutton warned of the potential for terror attacks during the upcoming Christmas period — saying the Assistance and Access Bill was an “urgent” and “vital piece of legislation” and encouraged its expedited passage through parliament. The bill was passed, and just a few months later it was used to conduct a police raid on Australia’s national broadcaster which were criticised as a threat to democracy and an attack on press freedom

With the raids on the ABC so fresh in public memory, it erodes a lot of trust that the government and its agencies will use the surveillance powers given to them discerningly and sparingly. While the conversation is centred around the prevention of heinous and organised crime, the legislation itself doesn’t make any mention of the specific offences which justify the powers being used. Maybe the legislation will be used to prevent and prosecute organised crime…maybe it will be used to intimidate journalists? And it’s not just us saying that, Senator Lidia Thorpe has her concerns over the laws, “no one’s safe under these new laws,” she said, adding it has “far-reaching implications for grassroots activists, and people standing up for their rights,” while Angelene Falk, the Australian Information Commissioner and Privacy Commissioner, recommended the bill be amended to narrow its scope and provide more oversight in its use.

On balance, the use of encryption, just like the use of good locks on doors, has the net effect of preventing a lot more crime than it might assist.

Matt Blaze, cryptographer

Of course, this conversation is happening all around the world — not just in Australia. Just a few years ago, Brazil banned WhatsApp in a disagreement over their encryption policy. And in 2019, Peter Dutton teamed up with US Attorney General William Barr and United Kingdom Home Secretary Priti Patel in a letter urging Facebook to ditch end-to-end encryption. A few months later, a new Personal Data Protection Bill was tabled in the Indian Parliament. The bill was supposed to address public order and national security concerns (sound familiar?), but sparked concerns it would turn India into an “Orwellian State”. In all corners of the world, there are examples of this rhetoric being used to topple privacy.

Protecting privacy

We’ve been down this road before, and it’s clear that access to end-to-end encryption is a basic requirement to preserve the privacy of people in our new digital age. Losing widespread access to end-to-end encryption would reduce civil liberties, infringe upon human rights, and usher in a new age of mass surveillance (if you don’t think we’re there yet).

It’s pivotal we don’t allow public opinion to shift towards encryption, and by extension privacy and anonymity online, being ‘too dangerous’ for the masses. Privacy is not cause for suspicion. Privacy is not a crime. The classic slogan ‘if you have nothing to hide, you have nothing to fear’ has proven not to be true again and again. Doing the right thing is not an invitation for rampant surveillance. Your privacy isn’t a necessary sacrifice for you to become an upstanding citizen, and the idea that it is is incredibly dangerous to the principles that guide our community.

Session is well and truly ready for this fight, it’s built right into our DNA. We’re open-source, we’re decentralised, and we’re going to fight tooth and nail to protect everyone’s privacy. Having open-source, auditable, and verifiable code helps build trust your tech is actually doing what it says it’s doing, without any nasties built in; decentralisation increases censorship resistance and makes it harder to monitor the network. Being open-source and decentralised goes a long way to protecting against the issues being faced by privacy-positive technology. With that being said, not every tech project is built like Session. Oxen’s mission is to bring hardened privacy to the regular old apps we use every day. At the moment, a lot of those apps are in a fragile place when it comes to privacy. At this moment in history, there are two paths we can take. One path means working protects and preserves privacy. The other makes privacy a blood sacrifice that lets our technology prosper. While we’re already neck-deep in the battle for privacy, we don’t want to see other projects swallowed whole by the anti-encryption agenda.

It’s up to all of us to stand up for privacy. Not just for Session. Not just for ourselves. Our entire future depends on it.

<![CDATA[Privacy washing: Creating a clean image for dirty tech]]> 3Qobp3GD4bVrRx1xiUK5p8 2021-06-10T22:00:00.000Z Data is an asset. It’s used to place ads, sell products, and refine services. Without data, the internet as we know it just doesn’t exist. Data has played its part in creating the tech we use every day. It’s development rocket fuel, allowing for insights that accelerate technical and marketing progress.

The more data you have, the bigger your sword in the tech arena. The empires of Google, Amazon, and Facebook are built on piles of data. No data, no Google. No Amazon. No Facebook. By now, pretty much everyone knows this. The ones that are paying attention, at least. Although what’s really meant by data collection is a bit of an abstract concept, most people have a vague idea that all these companies have your data, and that they’re probably doing something with it. The spectre of ‘big data’ is well and truly haunting us — everyone has their own story about an ad for something they never looked up, talked about, or dreamt about.

No, Mark Zuckerberg definitely has not planted a mind-reading microchip into you to service Facebook ads. And no, they don’t have Hari Seldon style future-predicting capabilities.

We know where you are. We know where you’ve been. We can more or less know what you’re thinking about.

Eric Schmidt, former Google CEO

The reality is that enormous amounts of individually innocuous data points create a complex profile about you. That profile can be cross-referenced with all the other people you know, and all the other people like you, and the people they know, and so on. It’s a tangled web, but it’s damn good at catching flies.

High on data: How big tech talks to its investors

The advertising business is a growing behemoth. The landlords of the internet are collecting rent on their data riches, and it’s all through advertising. Selling advertising space isn’t just part of the business model — it is the business model. In the first quarter of 2021, 96% of Facebook’s revenue came from advertising. This isn’t a one-off, either, it’s an ongoing trend.

This isn’t a trend that is changing either, Facebook is completely comfortable with the revenue dominance of their advertising sector. The commentary from CFO David Wehner in Facebook’s 2021 Q1 financial report is all about celebrating the triumph of Facebook’s advertising sector.

We are pleased with the strength of our advertising revenue growth in the first quarter of 2021

The first remark of Facebook CFO David Wehner’s Q1 outlook commentary

The strength Mr Wehner is talking about comes by the way of a 12 per cent year-on-year increase in the amount of ads being delivered, and a 30 per cent year-on-year increase in the average price per ad. The business is ads, and business is booming. What all these numbers really mean is that Facebook is still constantly improving their ability to leverage data for profit. Of course, for Facebook stakeholders, investors, board members, and stockholders — this is excellent news. What we end up with is financial reports from tech companies gagging over how their ad delivery is excellent and advertising revenue is growing (just like it always does). They don’t have much else to talk about, because, well…otherwise it’s a horror show of money sinks and discontinued projects.

Over at Google, the story is much the same. The How We Make Money portion of Alphabet Inc’s 2020 Annual Report is, well, fairly focused on advertising. We took the liberty of highlighting every mention of advertising, ads, and advertisers in the section and, well:

In the space of 400 words, ads are mentioned over 30 times. Google itself nets just 5 mentions. It’s just assumed that advertising constitutes the majority of revenue, and then the discussion is completely dominated by how advertising generates revenue. Apart from a throwaway line at the end of the section, which plays up Google’s other initiatives — a lot of which are totally worthwhile ventures, but looking at the long, long list of projects that are 6 feet under in the Google Graveyard, we probably shouldn’t bank on those projects transforming the revenue model of Alphabet Inc.

The message from big tech companies to investors is clear: advertising is where we make the big bucks. Advertising is, of course, backed up by the mind-bogglingly enormous data troves. Data about you and me. Data about people in every corner of the world.

High on power: How big tech talks to the world

Of course, this data-driven business model has copped some serious heat. Amnesty International’s Surveillance Giants report frames data collection and ad-based business as straight up surveillance. The report details the dangers and threats this model poses to human rights all around the world. And as the OPTF’s Ground Safe report reveals, the people in the most danger — like journalists and activists — lack the skills to protect themselves from surveillance.

In a letter responding to the report, Facebook said that their business model isn’t really about collecting data.

As you correctly note, we do not sell data; we sell ads.

Facebook response to Amnesty International’s Surveillance Giants report

What a filthy technicality! Really, the question is: what’s the difference? Without the data, the ads aren’t effective. What vendors are paying for is an amalgamation of the data Facebook has and their ability to deliver effective and impactful advertisements using that data. This…really isn’t better. Of course, governments and activist groups around the world are catching on, and regulators have placed data magnates in their crosshairs. Things like Europe’s GDPR and California’s CCPA are the first big shots at big tech, and more of the same in other jurisdictions will go a long way to reigning in unruly tech companies.

An important part of this regulation is bringing privacy into the public discourse. The more people recognise data privacy as an issue, the more emboldened people will be to stand up for their rights. As much as the ‘Will you accept our cookies’ pop-ups might feel tedious, and most people probably accept them without paying too much attention — at the very least, most people are now aware that pretty much every website they visit is tracking them in some way or another.

High on privacy: how big tech talks to you

Accept-our-cookie pop-ups are symbolic of a wider issue in the battle for privacy. The thing is, the average web-surfer probably blindly accepts cookies on their favourite websites whether it’s squeaky clean or full of invasive trackers. Even though people place super high value on privacy, they don’t necessarily have the tech literacy to decipher what that means in terms of which services they should use and which ones they shouldn’t.

In a 2020 survey conducted by the Office of the Australian Information Commissioner (OAIC), almost 70 per cent of people said protecting their personal information was a major concern in their life. That’s an overwhelming thumbs-up for privacy, and it’s a trend that is spreading across the globe.

Concerns regarding data privacy are driven by a belief that many companies routinely use personal information for purposes that make Australians uncomfortable.

Australian Information Commissioner and Privacy Commissioner, Angelene Falk

And that’s the crux of the issue, really. For most people, privacy isn’t a thing, it’s a feeling. Privacy is feeling comfortable. It’s feeling safe. Confident. The reason people want privacy is because of those feelings.

But the average person probably doesn’t feel all that unsafe when they unlock their Android phone, they don’t get a shiver up their spine when they open a WhatsApp message. So where is this dissonance coming from? From tech companies themselves, of course. Tech companies have realised the value and importance of privacy. They know that their users need to feel private — otherwise they’re gonna run.

This is where privacy washing comes in. Tech companies like Google are giving you a head pat to distract you from the fact they just punched you in the arm.

The Google Safety Center is home to a bevy of feel-good imagery, loaded phrases, and tech buzzwords to make you feel all warm and fuzzy about Google’s data collection activities.

The reality is, the privacy toggles that Google offers you don’t represent real control. If you use Google, you’re throwing your data sovereignty out the window. Google knows that, but as long as you feel like you’re in control, they’re in the clear. Google definitely made some noise about their new privacy-conscious image and practices, but the jig is well and truly up.

Just a few months after announcing their new privacy-empowered settings, it was revealed Google executives and engineers deliberately concealed privacy settings on Android devices.

Google pressured phone manufacturers into keeping privacy settings hidden, because the settings were popular with users.

Kim Lyons in The Verge

Google doesn’t really want you to take control of your privacy. Neither does Facebook, or any company whose business model relies on collecting data and selling ads. That’d be bad for business. And what will they pad their financial reports with if the advertising model runs dry?

Of course, plenty of people won’t buy the line that Google or Facebook are truly private — most people believe these companies are collecting information about them. But related products, like WhatsApp, can slip under the radar more easily. In fact, a huge part of WhatsApp’s success is due to its perceived privacy and security. WhatsApp, a Facebook product, continually reassures its users that it’s truly private.

type: embedded-entry-inline id: 4iqezbdRDgumAhfcFcurSdOf course, being able to read message contents is only one aspect of privacy — and in 2021, being able to read message contents would make WhatsApp a complete failure of a private messenger. WhatsApp knows this, and it deliberately oversimplifies privacy to make users feel comfortable with what they’re doing.

In reality, their privacy policy is a huge red flag, and serious privacy enthusiasts haven’t recommended the app for a long, long time. All this makes WhatsApp perhaps one of the grossest examples of privacy washing that exists. They’ve forged a path for future services and companies to sell themselves as private, secure, and safe — without really being any of those things.

type: embedded-entry-inline id: 4BjsQtdANHz3sgGW9PVHAwThis kind of marketing works, it’s effective, and it will only become more effective as the data privacy becomes a more mainstream concern.

It is up to products and companies that truly respect privacy, like Session, DuckDuckGo, and Proton to call out privacy vultures who try to benefit from the awareness they raise about digital rights.

The kind of damage these tactics could do to the wider push for digital rights cannot be understated. Real supporters of privacy must publicly stand against data profiteers wearing pro-privacy masks. Otherwise we will start seeing more and more people accepting the lie that large tech corporations are looking out for them — and the end result will be much the same as it is now. Human rights under threat. People under threat. Privacy under threat.

<![CDATA[Session on scale: Open group extravaganza]]> 6gw4RrXgXinnqn1XasXCp9 2021-05-20T22:00:00.000Z Open groups are the only way to have hyper-large scale conversations on Session. While closed groups are perfect for smaller conversations with your family, friends, or work colleagues, if you’re got a bustling community, a large business, or just…a lot of friends — you need an open group.

We’ve been running an open group for the Session community for a while now, but we’ve decided to take open groups to the next level. Introducing the superpowered open groups 2.0 — a complete overhaul of the way open groups work.

New open groups have been live for over a week now, and they’re going to take over completely from old open groups pretty soon — more on that later.

What’s new in v2 open groups?

The new v2 open groups are a huge improvement in terms of functionality and features.

Now, open groups can contain rooms within a single server. This makes it much easier for open group operators to run multiple chat rooms, allowing big, disparate communities to stay connected easily using open groups.

New open groups are also much more performant than the old ones, especially if users are in multiple rooms being run on the same server. Our v2 open group implementation is also a lot easier to work with for both operators and developers. Some of the common hurdles that operators were running into should be smoothed over now, so if you’ve ever tried to set up an open group before but ran into roadblocks — now is the perfect time to try again. Read our guide on how to set up an open group server.

We’ve already set up some v2 open groups for people to try out as well. In your Session app, tap on the green ‘+’ icon to bring up the new chat menu, and then tap the globe icon to join an open group.

We’ve set up some default open groups for discussing Session, Lokinet, Oxen, and crypto. This gives you some starter communities to join, and is especially useful for people who are new to Session and haven’t got many contacts to speak with yet!

Cya later v1 open groups

Due to the arrival of the new and improved v2 open groups, we’re going to be phasing out v1 open groups. Due to low use of v1 open groups, we’re forging ahead with only v2 open groups — which are better in every way. All of this means that v1 open groups will be discontinued as of today.

New open groups are not backwards compatible or interoperable with old open groups, so if you’re currently running a v1 open group, people will no longer be able to chat using this server, and you will need to create a new v2 open group server to replace it.

Upgrades on top of upgrades: v2 file server

Open groups servers aren’t the only thing getting a pamper, the file server (which facilitates the file-sending feature on Session) is also getting a big upgrade.

We’ve completely re-written the code for the file server so that it is easier to manage and upgrade in the future. However, upgrading to the v2 file server may cause some temporary unreliability with file-sending — this will likely only last about a day, and you will get an in-app warning message when the switch occurs.

Time to build a community

Open groups are the meeting grounds for big communities on Session, and with v2 open groups there has never been a better time to move your community over to Session. Session is getting slicker, speedier, and more stable with every day that passes.

Of course, if you start up your own open group — we’d love to hear from you! We’re excited to see what bustling and positive communities can find a place to live and chat on Session.

<![CDATA[Session Release Roundup #12: Open Groups Overhaul]]> 3cwC9n8kKH8KCIQIUFRNuA 2021-05-13T22:00:00.000Z Open Groups V2: Electric Boogaloo

I know it’s been a little while since we last chatted, but I think you’re going to enjoy what I’ve got for you today. We’ve been sequestered away grinding out lines of code at breakneck speed and the resultant improvements have arrived.

We’re rolling out V2 Open groups with this release, and we’re excited to see you all jump in and discover the joys of our new and improved Open group system. V2 Open groups offer significant performance boosts, as well as stability improvements for all.

Our new open groups also have the ability to support sub groups within the same server, and make the process of hosting a server much easier for everyone. On the development side the new Open groups will help to make the implementation of new features easier in future.

Due to this upgrade we will be shutting down V1 Open groups in the near future, keep an eye on our socials for the exact date, this is just a heads up to make sure that everyone has the time to migrate.

Just by the way, our highly anticipated audit was completed recently and the results are available here. The audit raised relatively few issues, most of which have been fixed already. You can check out our response detailing all of the audit-related fixes here.

  • New and improved open groups! Open groups are now suggested to you, and all new groups are faster and more reliable (iOS, Android, Desktop)

The headliner of this release — V2 Open groups are here. This change introduces sub-groups within open groups and streamlines the setup process, along with some performance boosts.

  • Made performance and reliability upgrades to closed groups (iOS, Android, Desktop)

Closed groups have been fiddled with behind the scenes to optimise and streamline the code, but you don’t care about that — you just want to know what that means for you, and I’m happy to tell you: closed groups are faster and more reliable than ever. These changes will, however, only take effect for newly created closed groups.

  • Laid the foundation for faster and more reliable file transfers (iOS, Android, Desktop)

No more waiting around for your files to send, we’re speeding up the process so you can fire off memes at rapid speed.

  • Longer TTL for undelivered messages (iOS, Android)

Not around to open Session for a couple of days? No problem, the Service Node network now stores messages for longer, so undelivered messages will still be there if you’re away from Session for a while.

  • Improved Russian translation and added a Slovak translation (iOS)

We’re always working on making Session more accessible to our international communities, and this round of releases is no exception. We’ve got improvements to our Russian translation thanks to community member Dmitry, and a shiny new Slovak translation thanks to community member Vlado.

  • You can now set a screen lock timeout of less than 60 seconds (Android)

Session now has the ability to lock itself up quicker than ever. You asked and we heard, 60 seconds is enough time to download and set up Session, so it’s definitely enough time for a nefarious trickster to grab your phone and look at your messages.

  • Encrypt attachments locally (Desktop)

All attachments are now encrypted while stored on your computer, so you can be sure that your files are safe from prying eyes even when they’re not in transit.

  • General performance improvements (iOS, Android, Desktop)

Just a little bit of under-the-hood tinkering to make sure that Session is delivering the most streamlined and reliable experience possible.

  • Fixed bug causing bad performance in longer conversations (iOS)

Now there’s no need to worry about your main conversations slowing down as they drag on — you can chat for as long as you like without that pesky lag.

  • Fixed an issue causing timestamps to display incorrectly (iOS)

This one is pretty straightforward. Timestamps shouldn’t lie to you. Now they don’t.

New month, new look for Android

The future is looking bright for Session, and we’re looking forward to sharing our upcoming improvements and fixes with you. We’ve got further improvements to open and closed groups coming down the pipeline, an overhaul of  the Android conversation screen, and a bunch of bug fixes and general performance improvements on the way too — stay tuned for more on that front.

Thank you!

We’re just chuffed with how Session has been progressing over the last few months. We’ve made huge strides in performance and reliability across all platforms — and we could never have done it without you! To everyone reading these update notes, sending in feedback, and talking to their mates on Session — thank you so, so much.

See you next time!

— The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[WhatsApp privacy policy teardown: This is where it ends]]> 78EFNIG3Ph4ubl3JqcO5tg 2021-05-06T22:00:00.000Z Accepting the new WhatsApp privacy policy by May 15 is mandatory. This is the final nail in the coffin of the world’s most popular ‘private’ messenger. The Facebook-owned platform has often found itself reassuring everyone they can’t read messages sent using WhatsApp. Although there are technically ways Facebook might be able to read WhatsApp messages  — they don’t need to. WhatsApp can learn lots about you using nothing but metadata. That’s why the latest privacy policy changes are so concerning.

WhatsApp’s decision to disable your account if you don’t agree to their upcoming privacy policy changes has gotten a lot of people up in arms, but if you’re wondering what about the WhatsApp privacy policy itself, we’ve got all the details you need.

WhatsApp privacy policy explained

Everything in this article is drawn from WhatsApp’s English privacy policy as published here. WhatsApp maintains it can’t see your private messages, hear your calls, doesn’t store logs for messages or calls, and doesn’t share your contacts or location data with Facebook.

But WhatsApp is changing their policy for a whole bunch of important things like data processing, integration with businesses, and integration with other Facebook products.

The term ‘Services’ is often used throughout the policy to describe not only WhatsApp, but also the wider family of Facebook applications and services. The policy itself doesn’t give a specific definition for what it means by Services. We checked out the About Our Services section of WhatsApp’s Terms of Service to get some extra insight into what is covered by Services. Specifically, whether that is limited to WhatsApp as a service, or extends to other Facebook services as well. It has this tidbit:

As part of the Facebook Companies, WhatsApp receives information from, and shares information with, the Facebook Companies as described in WhatsApp’s Privacy Policy, including to provide integrations which enable you to connect your WhatsApp experience with other Facebook Company Products; to ensure security, safety, and integrity across the Facebook Company Products; and to improve your ads and products experience across the Facebook Company Products. Learn more about the Facebook Companies and their terms and policies here.

Excerpt from ‘WhatsApp Terms of Service’ (accessed May 7 2021).

Sharing and receiving information to serve ads and sell products? Doesn’t sound super privacy preserving. But who exactly are these Facebook companies — according to this (Warning: link to Facebook) Facebook help article, it includes all this.

The Facebook Products include Facebook (including the Facebook mobile app and in-app browser), Messenger, Instagram (including apps such as Boomerang), Portal-branded devices, Oculus Products (when using a Facebook account), Facebook Shops, Spark AR Studio, Audience Network, NPE Team apps and any other features, apps, technologies, software, products or services offered by Facebook Inc. or Facebook Ireland Limited under our Data Policy. The Facebook Products also include Facebook Business tools.

Excerpt from ‘What are the Facebook Products‘ on Facebook Help Centre (accessed May 7 2021).

No surprises here: it’s ugly. Okay, so WhatsApp is definitely a part of Facebook’s weird data harvesting cabal — but what information does WhatsApp even have to share? Message contents are end-to-end encrypted after all. Let’s take a closer look at the kind of information WhatsApp has (and can share).

First, there is the information you give WhatsApp directly — things like phone numbers in your contact book, your payment details, and your account information, like your phone number and your name. WhatsApp does have your (encrypted) messages, but they delete them once they’ve been delivered — so only you and the people you talk to actually store messages. But there’s a catch — businesses on WhatsApp are free to store and repurpose messages you send them however they want to. This means targeting ads towards you, creating a profile of you, or anything else they see fit. On the surface, this seems reasonable. But here’s the sneaky part: businesses can elect to use Facebook to store these (unencrypted) messages — meaning Facebook would get access to all your message contents, and be able to do whatever they want with them.

Some businesses will be able to choose WhatsApp’s parent company, Facebook, to securely store messages and respond to customers.

Excerpt from ‘Privacy and security for business messages‘ on WhatsApp FAQ (accessed May 7 2021).

They claim Facebook won’t automatically use this information to advertise to you, but that can change at any time. On top of this, the WhatsApp privacy policy allows for information sharing with third-party service providers and businesses.

We work with third-party service providers and other Facebook Companies to help us operate, provide, improve, understand, customize, support, and market our Services.

Excerpt from ‘WhatsApp Privacy Policy‘ (accessed may 7 2021).

In case you don’t remember, misuse of third-party service data and information access by the app ‘This is Your Digital Life’ led to the Cambridge Analytica catastrophe, so this doesn’t inspire a lot of confidence.

There is also information that WhatsApp collects in the background. This list is LONG. It includes data about your location, the kind of device you’re using, your operating system, battery level, phone signal, what version of the app you’re using, browser information, what mobile network or ISP you’re using, language, time zone, IP address, and identifiers. Identifiers are used to connect your WhatsApp account with other Facebook accounts you might own based on all the information they collect.

WhatsApp also automatically collects and logs information about your usage habits, like when you are online, how long you spend online, when you message people, and how often you message them. This is more than enough to start profiling you, especially when you consider that it can be shared or cross-referenced with other user information that Facebook has.

Time to steer clear of WhatsApp

Hardcore privacy enthusiasts stopped recommending WhatsApp a long time ago. In the end, Facebook is a company built around profiting from data, so it’s hard to trust what WhatsApp is doing.

Of course, end-to-end encryption is an important part of both security and privacy, but don’t let E2EE buzzwords convince you that an app is impenetrable, has no vulnerabilities, or can’t be used to collect information about you. Unfortunately, the equation is much more complicated than that.

For now — don’t recommend using WhatsApp if privacy is a serious concern of yours.

<![CDATA[Session code audit: Technical report published by Quarkslab]]> 1xUgIFHX7uVhAqRAYvmyGM 2021-04-28T22:00:00.000Z Completing a Session code audit has been in the works for a long time, and now it’s finally here. An audit of Session’s Android, iOS, and Desktop versions has been completed by the cybersecurity research company Quarkslab. For those who have been waiting for an  audit to try Session, recommend Session, or just wanted some extra assurance around the app: today’s the day.

The audit itself is quite long and complex, and it’ll be difficult to read if you’re not technically minded. But the major takeaway is this: Session’s cryptographically sound.

Quarkslab only raised a few issues with Session, most of which have already been patched. A couple of low impact issues remain, but they were mostly related to deliberate design choices — we will explain those below.

Why does having a Session code audit matter?

Writing code is hard — even for the experts. It’s a long, error prone process. As skilled and experienced as our engineering team might be, writing foolproof code for a hardcore private messenger like Session is a painstaking, precise process which demands current and detailed knowledge of the use and limitations of different libraries, hardware and devices, operating systems, and more. And mistakes can open Session up to attacks from all kinds of different adversaries.

A code audit gives you (and us) peace of mind. The security and integrity of the Session code has been verified by a trusted third party, and we can now more safely say that Session’s codebase is sound. The security audit includes analysis of Session’s actual code, as well as considerations about the functionality and design of the app and how that relates to its security.

Other than that, the audit is about trust. Session is designed to reduce the amount of trust you need to place in your messenger. But there is still one aspect of Session that requires trust: The Session Team. You need to trust that Session is actually what we say it is, that we’ve built the app in the way it was designed, and there are no monsters hiding under the bed. Assuming you weren’t a master coder with endless free time to check the code yourself, you had to hope we were being honest and acting in good faith. Now — the audit shows we’ve done that, at least up until now. Quarkslab has read the code for you. They’ve analysed the app for you. You don’t have to take our word for it.

Session is as advertised: Private. Secure. No metadata.

What were the issues raised in the audit?

In total, Quarkslab raised 2  issues with the Desktop client, 7 issues with iOS, and 7 issues with Android. Many of these issues have already been fixed, leaving the outstanding issues raised being 1 on Desktop, 4 on iOS, and 4 on Android.

Only one of the issues raised was considered severe by Quarkslab, and only pertained to Session on Android. It related to TLS verification when gathering information about the service node list, leaving a potential vulnerability to malicious certificate authorities attacks. This issue has already been fixed.

Many of the ‘unfixed’ issues are actually intended Session functionality. While they are valid recommendations, things like being able to copy your recovery phrase to your clipboard, take screenshots in the app, and default notification configurations are deliberate design decisions made to improve the functionality and user experience of Session.

So, now that Session has a code audit…

What’s next? Well, this is a really big day for Session. Understandably, plenty of privacy enthusiasts, journalists, activists, and other groups have been waiting for Session to be audited before they gave it their full support. Like we said before, it’s all about trust, and for things like the Secure Messaging Apps Comparison, having no code audit made it hard to trust Session — now, Session is easy to recommend.

Session has been going from strength to strength, with voice calls on the horizon and 100,000 monthly active users right around the corner.

It’s time for us to really flex our muscles and spread the word of Session.

<![CDATA[End-to-end encryption: Secure messengers and messaging]]> 1i7pyNJo9XQXVjQK0hoUB2 2021-04-25T22:00:00.000Z End-to-end encryption (E2EE) is offered in most modern messaging apps. Everything from dedicated encrypted messaging apps like Session all the way to basic things like Facebook Messenger offer some kind of encrypted messaging functionality. There is a whole lot of hoo-ha about end-to-end encryption, but what is it exactly, and why does every messenger and its type: embedded-entry-inline id: 2PdmmxtBWv9V9bIqDHHl35 integrated cryptocurrency wallet seem to have it these days?

End-to-end encryption is the most private and secure way to communicate online, making it essential for any serious messenger. When you use end-to-end encryption, only you and the person you are talking to can see the contents of your messages — nobody else. Without physical access to your device, your conversations can’t be seen by hackers, governments, or even the company who makes the app you’re using. This is important for lots of different people, for lots of different reasons.

How does encryption work?

Before we get to talking about end-to-end encryption, we should explain how encryption itself works. Encryption is a really important part of security. Nowadays, encryption is everywhere — even in places you don’t realise.

But really, people have always used basic forms of encryption to keep secrets. Cryptography has been traced all the way back to the Spartans, who used leather straps and differently sized rods to send messages to each other — the letters on the strap could only be read if you wrapped it around a wooden rod of the correct size.

Next, the Romans developed ciphers, where different letters (or eventually combinations of letters) would be completely substituted so that the written message looked like complete nonsense. You could only decode the message if you knew the system that was used to encode it. This is the basis for encryption, and is the same fundamental idea we use now — although things have gotten a lot more complicated.

In the 1970s, modern encryption really started to get going, as IBM and other computer scientists developed computer-based encryption. Around the same time, the Diffie-Hellman key exchange was developed. Computer-based encryption allowed really complex, difficult-to-crack,  and mathematically rigorous forms of encryption to become commonplace.

Now, when you encrypt something using computer-based encryption, you are encoding your message (or any piece of information) so that it becomes completely unreadable to anyone who doesn’t have the information required to decrypt it.

How end-to-end encryption works

E2EE uses encryption to protect your messages all the way from their origin (you) to their destination (the person you’re talking to).

Most explanations of E2EE feature two classic characters — Alice and Bob. The scenario is this: Bob wants to send Alice a message.

In the real world, Bob can just talk to Alice, there is nobody needed to facilitate the conversation.

But online, things aren’t that simple. The majority of the time, you need some kind of service in the middle to connect Bob and Alice.

At the bare minimum, most services use transport encryption. This means that anyone who intercepts the message while its being delivered won’t be able to read it. But there’s a problem, the service provider — whoever that may be (Facebook, Google, etc.) — can easily read the contents of Bob’s message.

This is because the server provider holds the decryption key required to read Bob’s message. The solution seems simple enough — if the provider just doesn’t have those keys, only Bob can read the message.

But how do you know that the provider isn’t sneakily holding onto that key? Well, using public and private key pairs. Alice can create two keys — a private key that they keep to themselves, and a public key that they can share with anyone.

Anyone with Alice’s public key can encrypt a message for Alice, but only Alice has access to the private key — so you know only she can decrypt the message.

But there’s still a problem — you have to trust the service provider to give you Alice’s real public key. Instead, they might choose to give you a public key they have the matching private key for, which could compromise your messages. This is an issue called Trust on First Use, and the solutions are a bit more complicated than just encryption.

But now, your messages are end-to-end encrypted. This protects you from hacks and keeps your messages private.

What apps use end-to-end encryption

Lots of messaging apps have started using end-to-end encryption implementations over the last few years. Popular apps like WhatsApp, Signal, Session, and Wire use end-to-end encryption by default.

Supporting end-to-end encryption by default is super important. because otherwise some people using the app might not enable the feature, leaving them and the people they talk to vulnerable.

Some apps, such as Telegram and Facebook Messenger, do support E2EE — but not by default. In the end, this results in the vast majority of people using the app without end-to-end encrypted messages.

In the end, E2EE is just one (very important) piece of the puzzle when building a private and secure messenger. You also have to consider things like decentralisation and what information is required to register for the messaging service.

<![CDATA[Your adversary: Who’s a hacker, anyway?]]> 4q3pnPS0yTBLg9H8yaIwXs 2021-04-19T22:00:00.000Z It’s time to talk about a fundamental concept underpinning the entire field of cybersecurity: your adversary. Now that we’ve completed our implementation of the Session Protocol, we want to take a moment to talk about threat modelling and security design. Without adversaries, there wouldn’t really be any need for cryptography or anonymity systems. The concept of an adversary is quite simple — adversaries are any two parties who, for whatever reason, have opposing interests. In this article we’ll assume that one of these parties is you — someone using Session.

Adversary, adversary, what do you want with me?

There are a number of different groups who may present themselves as adversaries to Session users.

Hackers — generally individuals or small groups; maybe they’re just trying to break the system to show they can; they might not even be interested in you specifically, just creating chaos and poking holes. Nonetheless, if hackers are trying to penetrate a system you’re using — they’re your adversary.

Criminals — normally financially motivated, a criminal adversary generally want to gain information they can turn into dollars in their pocket.

Vigilantes — also commonly referred to as hacktivists, these kinds of adversaries are similar to hackers, but with the added twist of a political or philosophical message they hope to convey by attacking you or the system you’re using.

Last but certainly not least, nation-states — probably the most competent, well-resourced, and imposing of the adversaries we’re considering here, this category includes things like military groups and intelligence agencies. Nation-state adversaries can be expected to conduct attacks intended to further the goals of the state — whatever those goals may be.

Our systems are down! Adversary attack!

It’s important to consider the kinds of things that adversaries can actually (try to) do to you or the system you’re using. Ultimately, an adversary can try to compromise any combination of the privacy, integrity, or availability of a system.

If the privacy of the system is compromised, that means some information about the system, its users, or its operation, is being exposed to the adversary. In the case of a messaging app, this might be things like your identity, the contents of your messages, the people you are talking to, or when you’re talking to them.

On the other hand, compromising the integrity of a system means the adversary can somehow alter or otherwise affect the system. For messaging apps, this might mean editing messages, making messages look like they were sent by someone else, or sending completely fake messages.

An availability compromise is exactly what it sounds like — an attack that makes a service unavailable. This might mean preventing messages from being sent or received, blocking logins to the service, or stopping you from downloading the application at all.

Cyber shields back up to 100%

So, attacks on privacy, integrity, and availability are the main ways a pesky attacker might attempt to compromise a system, and we know some of the motivations attackers might have, but what does an attack actually look like?

The exact kind of attack always depends on the kind of system we are dealing — but let’s consider a few examples where Alice (A) wants to send a message to Bob (B).

Example 1: Central server, transit encryption only

In this example, the privacy, integrity, and accessibility of the system are completely dependent on the server (S). The server can freely store, read, share, alter, or just choose not to deliver the message Alice is trying to send to Bob. Let’s have a look at what a bad actor could do to compromise Alice and Bob’s communications in this very basic scenario.

Privacy: Alice’s message is not private. The server operator can read it themselves or share it with whoever they like. They know Alice sent the message, what Alice said, and that they’re saying it to Bob.

Integrity: The integrity of Alice’s message cannot be verified by Bob. The server operator could alter the message however they like before delivering it to Bob.

Availability: The availability of the message is not guaranteed. Alice may not be able to reach the server, the server can choose not to  deliver the message to Bob, or something may prevent the server from delivering the message.

But, what if Alice end-to-end encrypted their message to Bob?

Example 2: Central server, end-to-end encryption

Our system now has some privacy — the server can’t freely read, share, or alter the contents of the message without Bob and Alice realising. However, the server still knows who Alice is, knows who Bob is, and knows exactly when they are messaging. On top of that, the server can decide (or be forced) to stop delivering messages at any time. So what could bad actors do to compromise Alice and Bob’s communications with end-to-end encryption in the mix?

Privacy: The server no longer knows what Alice is saying, however they still know that Alice is speaking to Bob, including when they exchange messages.

Integrity: The server can’t alter the message Alice sends Bob — if it tries to, Bob will be able to tell the message was signed by someone other than Alice. That is, assuming the server has given you and Bob the correct information to encrypt messages for each other. Read our article about trust on first use to understand more about this problem!

Availability: In terms of availability, we still have all the same problems from example 1.

Now, one of Session’s hallmark features is using onion requests over a decentralised network — what if we add that into the equation?

Example 3: Decentralised network, onion routing

Looking much better. There’s no more central server, and the message is encrypted multiple times for each node it travels through, meaning the system has more privacy — all Ntype: embedded-entry-inline id: 4LXFSusZwvCHfPNV4Eq2v0 knows is that Alice is sending a message somewhere, all Ntype: embedded-entry-inline id: vtspVos1fpPHPj9qbINGL knows is that someone is sending a message somewhere, and all Ntype: embedded-entry-inline id: 7DGvOh5yjB5Eq5Wtvn3ZVd knows is someone is sending a message to Bob.

All these layers of protection mean that it’s also much harder to compromise the accessibility of this system in a targeted way. Even if Ntype: embedded-entry-inline id: 4LXFSusZwvCHfPNV4Eq2v0 decides that they don’t want to propagate Alice’s message (or is forced not to propagate the message), Alice can just as easily build a new path using a different node in the network. Problem solved — all thanks to the epic power of decentralisation. Let’s take a look at exactly what bad actors could do to compromise Alice and Bob’s communications here:

Privacy: Just like before, the contents of Alice’s messages are completely private. On top of that, none of the nodes actually know that Alice is talking to Bob at all. And in the case of Session, because it doesn’t use personal identifiers (like phone numbers), there isn’t really a good way to know who Alice or Bob truly are at all.

Integrity: Alice’s messages cannot be altered, and if any of the nodes try to alter or corrupt the message, Bob will know.

Availability: Because the network is decentralised, no single node failing or misbehaving can prevent the delivery of a message. If one node is down or can’t forward the message, you can simply use a different node in the network.

Thanks to its combination of decentralisation, onion routing, end-to-end encryption, and anonymous sign-up, Session brings you a messaging system that is extremely resilient in terms of privacy, integrity, and accessibility.

Different designs depending on your adversary

It’s pretty much impossible for one system to be completely bullet-proof. With Session, we’ve taken every measure we can to try and create as secure of a system as possible without having to resort to one-time pads and smoke signals, but it’s always important to consider what kinds of threats you want to protect against when you are picking something as crucial as a messaging app.

Depending on where you are, who you are, and what you’re doing — different systems and strategies might be required. For example, if you’re somewhere that is often subjected to internet shutdowns, things like mesh networking might be relevant — but if you’re sipping lattes in Sacramento, a mesh-based solution might be more frustrating than helpful. We all live and work in very different situations, and those situations come with very different security and privacy requirements. It’s important to consider what your needs are, so you can make the best choices for you.

<![CDATA[The crypto craze: Implementing cryptocurrency into a messenger]]> 6cxOvdR7DUJnUVvGbGF7wK 2021-04-07T22:00:00.000Z Cryptocurrencies are in the headlines again lately. Everyone who’s anyone is talking about them, trading them, and…putting crypto into their messenger? This year, messaging apps are riding the crypto wave and introducing coin payments and crypto wallets into their services. We’re all for this — after all, Session has blockchain built right into its DNA. As much as we believe in the power of blockchain and cryptocurrency, it’s not always sunshine and daisies. Plenty of cryptocurrencies have dubious backgrounds, serious technical issues, or just aren’t really all that useful.

Because of our background with blockchain tech, we figured it was time for Session to weigh in.

Hopping on the hype train

Blockchain and crypto technology is exciting — that’s why we designed Session to utilise the power of a distributed blockchain network. We’ve believed in this movement for a long time, and a lot of the things Session prides itself on — like decentralisation and onion routed messages — wouldn’t be possible without leveraging blockchain tech.

For so long now, we’ve ardently believed that blockchain is the future of technology. It has always remained at the core of Session. Slowly, we’re starting to see more and more people join us on the blockchain bandwagon. While we’re happy everyone is nabbing a ticket to the privacy party, there is a wrong way to put a crypto into a messenger or any other app.

  • Centralising the blockchain network into the hands of a few trusted validators

  • Using transparent blockchain architectures which expose addresses, amounts being sent and recipients in transactions

  • Relying on proprietary CPU or GPU based technologies only offered in select data centres to run blockchain nodes

  • Using slow and expensive blockchains

As messengers start introducing cryptocurrency payments and wallet integrations into their apps, it’s important to keep privacy and security at the forefront of our minds. Not all cryptocurrencies are made equal — some lack privacy, some lack security, some are just complete landmines. Just like any other feature: the implementation details matter.

There is a whole world of blockchain development, design, and implementation. We’ve been a part of that world for years now, and as crypto the masses, Session is a uniquely positioned to messenger.

The vision for Session and crypto

Our plan for introducing crypto to Session is simple and effective: Oxen. Oxen is the cryptocurrency that backs the network Session already runs on. It’s private, secure, and has stood the test of time. Oxen was built from the ground up with apps like Session in mind.

Oxen is a fully decentralised network, with over 1,500 service nodes securing, maintaining, and validating the blockchain. These service nodes are run by lots of different operators all around the world — with no central point of weakness. Anyone can run a service node  — the code is completely free and open source, and doesn’t require any proprietary software or hardware to run.

Oxen also lives up to the standards of privacy and anonymity that underpin Session itself. Originally, Oxen was a fork of Monero — the most well known and respected privacy coin in the world. Thanks to those beginnings, Oxen has ring signatures, stealth addresses, and bulletproofs protecting the privacy of every single transaction on the network. On top of that, the Oxen blockchain has excellent long-term security thanks to its implementation of checkpointing

Oxen has made some key improvements to Monero, though — most importantly through Pulse — its Proof of Stake implementation — and Blink — its instant transaction mechanism. This makes using the Oxen blockchain both fast and cheap.

If it seems like Oxen is the perfect fit for Session, that’s because…it is. Oxen was made to be the perfect fit for Session. And it’s probably a good fit for other messengers, too.

New romance: Messenger apps and crypto

We’re so excited to see more and more projects looking into blockchain technology. The thing is, blockchain technology can do so much more than just being tacked on top. Session is already proof of this — its entire network is powered using blockchain technology, and it’s all the better for it.

Like with any foray into new and unknown realms, we just don’t want to see the messaging scene held back by new flaws and vulnerabilities that could be introduced by a mad rush to jump on the latest tech trend.

<![CDATA[Trust on first use: The Achilles heel of centralised messengers]]> 4JEUZNnX8HhCfRuJkBo4TT 2021-04-06T22:00:00.000Z We’re here to talk about TOFU, and no, we don’t mean soy-based protein. When we say TOFU, we’re talking about Trust On First Use. Whenever you send a message, you expect it to arrive at its intended destination without being re-routed to, read by, or responded to by anyone but the person (or people) you sent the message to. With some messengers (they know who they are), people now realise that’s not the case. Some companies and their apps can’t be trusted to keep your conversations private. But the good guys — the encrypted messaging apps like Session — need to guarantee your messages are arriving without being exposed or tampered with without placing trust in the server(s) or service provider powering the application. Obviously end-to-end encryption is a big part of the solution here, but it’s not a silver bullet for trust issues when it comes to private messengers.

The trust issue

Most messengers that require a phone number, email address, or username to sign up have a trust problem. Namely, you must fully trust the servers of these applications to correctly direct your messages to the intended recipient, as well as to give you the information required to correctly encrypt messages. To make matters worse, at any point during all conversations on messengers like this, your messages could be re-routed to a completely different person without you ever knowing.

Apps suffering from this trust issue include popular messengers like Signal, WhatsApp, Telegram, Facebook Messenger, and Threema.

TOFU: Trust on First Use

The issue with the above applications is that they rely on an authentication method called Trust on First Use (TOFU). The reason for this is fairly obvious — when you want to message someone on one of the these messengers (Signal, for example) you need to know two things before your first message can be sent: the recipient’s identifier, so you can tell Signal who you’re messaging,) and the recipient’s public key, so you can encrypt your message. In the case of Signal, the recipient’s long term public key and identity are the same, and this is referred to as the ‘identity key’. This means Signal’s servers must map between each user’s phone number (or other identifier) with their matching identity key.

This allows people with your identifier (in this case, your phone number) to encrypt a message to you without having to actually handle a public key — or even know what a public key is.

There are some legitimate reasons for this system. For example, if your phone breaks, the private part of your identity key will be lost — because it’s only stored on-device. But if you retain access to your phone number, Signal’s servers allow you to regenerate a new identity key and update the mapping on their server. This way, people can still encrypt and send messages using the same phone number.

Every application listed above follows some sort of similar behaviour, with a centralised server storing a mapping between your phone number or email address and an in-app identity/key which allows for the routing of messages.

Possible attacks

The problem here is clear: when using encrypted messaging applications, there’s an expectation that messages should be encrypted for the correct person and sent to the correct destination without having to trust the server.

Continuing with the Signal example, it’s possible Signal’s servers could give you the identity key of a completely different person than whoever you intended to message.

Scarier yet, if someone malicious gained root access to a messenger’s servers, they could insert a man-in-the-middle (MITM) into a conversation. For example, when Alice sends her first message to Bob using his phone number, the Signal servers could return Mark’s identity key instead of Bob’s. Mark can then request Bob’s identity key, impersonating Alice. When Alice sends a message to who she believes is Bob, the message is actually sent to Mark, who reads the contents then encrypts and passes the message onto Bob (and vice versa when Bob replies).

Potential solutions for trust on first use

Safety numbers

Signal, Whatsapp, and Wickr all use the ‘Safety Number’ construct. The idea behind safety numbers is that after you have added someone using their phone number, you can physically scan a QR code or confirm the safety numbers of your chat partner outside of the application. If the ‘Safety Numbers’ match on both devices, then you know for sure you’re talking to who you expect to be talking to — the person with that device.

This method works to protect users against man-in-the-middle attacks which are possible due to TOFU. The key issue with the safety number construct is that very few users actually verify their contacts’ safety numbers, and key changes happen regularly enough that people typically ignore them altogether.

A user study completed by USENIX investigated the real world usage of Signal safety numbers. In the study, 10 pairs of participants were asked to send a credit card number over Signal securely. To send the number securely, participants needed to verify their partners’ safety number. All 20 participants failed to properly authenticate their partners, meaning if the Signal server had been hacked or was acting dishonestly, all participants could’ve been connected to an entirely different user — potentially resulting in their credit card information being stolen or leaked.

The Ideal solution

Ideally, when you add a new contact on a messaging platform, you immediately know with full confidence you’re speaking to that person. There would be no server you had to trust to connect you with the right contact by keeping a mapping of their phone numbers, email address, or username and your public key.

Applications like Session, Tox and Bitmessage achieve this by directly using the device’s or client’s public key as the network identifier and encryption key.

The Session model

Everyone on Session has a unique Session ID, and allows for offline backup of these Session ID’s (using a BIP-39 mnemonic). Whenever you want to message a new user,  you use their Session ID. That Session ID provides both their swarm location as well as their encryption key. Again, as long as your friend gave you their correct Session ID, it’s impossible for you to encrypt a message for the wrong person, even if the service node network (Session’s servers) is dishonest.

The Tox model

Tox gives each user a Tox ID. When you add a new friend on Tox, you use their Tox ID to discover and encrypt your first message for them. Since there is no lookup for their encryption keys, it’s impossible for you to encrypt a message for the wrong person.

The Bitmessage model

Bitmessage uses identities which are encoded public keys. Bitmessage identities act as both an encryption key and a network identifier. When adding a new contact, as long as you have the correct Bitmessage identifier, you can be sure that your message is encrypted and sent to the correct individual.

Although most trusted messaging applications now employ end-to-end encryption, it’s important to understand how it’s implemented. Messaging applications which allow users to add new contacts using phone numbers, email addresses or usernames, are all employing a trust on first use model. This model opens up users to man-in-the-middle attacks during the initial resolution between a username, phone number, or email address and the cryptographic keys required to encrypt a message for the intended recipient.

Some messaging applications have attempted to resolve this issue by introducing the ‘Safety Number’ construct which requires users verify cryptographic keys outside of the messaging application. However, user studies have shown that the real world usage of this feature is low, and even those who do attempt to verify may still be vulnerable due to user error. This leaves many people open to attacks which could leak the contents of their conversations.

Session, Bitmessage and Tox, have taken their security model one step further — directly using cryptographic keys as a person’s identity in the app. This means every single message sent will always be encrypted for the specified users identity, removing the ability for dishonest servers to attack users.

<![CDATA[Ground Safe: Putting secure tech in the hands of democracy’s defenders]]> 5tdPfhEKjj1b1ghS11yw8Y 2021-03-18T23:00:00.000Z In 1787, philosopher and politician Edmund Burke rose to his feet in the Palace of Westminster amidst a heated parliamentary debate. Here began the life of the term ‘Fourth Estate’: an attempt to mock the scribes of the press gallery that Burke was squabbling with.

What Burke was really saying was that the self-important members of the press needed to learn their place in the world. That place, in Burke’s mind, being below members of parliament like him. As it turned out, the press didn’t mind being referred to as the Fourth Estate, and took up the moniker for themselves. Reclaimed like a snide retort being shouted down the halls of history: Yes, that’s right Edmund, we’re here to hold you — and everyone in power — accountable. That’s the power and the duty of the Fourth Estate.

But with accountability comes conflict. It’s a tale as old as time: governments at odds with journalists and other members of civil society. But that’s just part of the job for journalists and other members of civil society,  like activists. Of course, butting heads with some of the most powerful people going around can put you into some really sticky situations. But they do it — for  the people. For us.

Defending democracy and all the rights and liberties that come with it is a crucial service to the public. So what can we do for them?

Defending human rights in the digital world

Ground Safe, a new research report released by our very own colleagues at the OPTF, has some answers to this critical question.

The world has come a long way since Edmund Burke spoke in front of his fellow parliamentarians, and so has the world of civil society. Now, the life and work of most people happens online. Our digital lives are, for all intents and purposes, simply… our lives. The internet. Mobile phones. Social media. Every day. On the whole, this shift has been hugely positive. It’s easier than ever before to connect and communicate with people all over the world. Information can move around fast and free. These incredible pieces of technology should be great gifts to democracy.

But these same liberating forces are now being lassoed by the powers that be and twisted into instruments of harm. Governments have realised that these tools can be corrupted, abused, and manipulated to not only suppress people’s work defending democracy and human rights, but to further their own agendas — whatever they may be.

Human rights defenders are exposed to a huge volume and variety of digital attacks — direct hacking of their personal devices and accounts, attacks through legislation and regulation, internet shutdowns, surveillance and monitoring, doxxing, the list goes on. All these attacks not only directly limit the ability for human rights defenders to do their work, but also create anxiety and uncertainty, and even place human rights defenders in real danger. The Ground Safe report found that most people felt helpless under the threat of digital surveillance, attacks, and abuse.

Building digital safety — from the ground up

So how can we go about putting some power back in the hands of our defending Davids as they front up to their Goliaths? Ground Safe makes a lot of recommendations on this, but we’re just going to focus on a few.

The first one is something that’s very close to our hearts here at Session — building secure tech tools that work effectively and are easy to use. You could make the most secure communication system in the world, but if nobody can use it, well, what use is it really? To succeed, secure tech needs to make sense — just like any other piece of tech. We’ve got to build apps that suit the specific needs of human rights defenders. There is a Goldilocks zone of security and useability that we need to find to make sure that anyone can use the technology they need to keep themselves safe. There’s no point having security and privacy if it’s only accessible to full stack devs and characters from The Matrix

On top of that, let’s get real with each other. If your tool has a limitation, gap, or weakness, tell people about it. The race to be seen as the most secure, most military grade encrypted, absolutely uncrackable app ever created isn’t useful to anyone. Privacy and security aren’t always a yes or no question, and it’s more productive for everyone if we’re up front and honest about what our tech can do and what it can’t do.

Going hand-in-hand with these issues is education. Education is sorely needed for human rights defenders who are living under the threat of digital attacks every single day. The first step is making sure people understand the kind of threats they might encounter — that way they can start planning and strategising to protect themselves. There needs to be more training provided, and it needs to be more local, so that people can learn about the issues, tactics, and tools that are relevant to their specific situation.

The future of human rights

Just like in other spheres and professions, we’re starting to see privacy and security valued more highly by journalists, activists, lawyers, educators, and other human rights defenders. While this is great, there is still a gap that needs to be closed.

We hope that in the future, the internet and everything it enables can be both useful and safe for human rights defenders.

And we know Session can be a huge part of that.

<![CDATA[Session Release Roundup #11: Return of the Multi-Device]]> 4v65gAKxQ0ygp6st2AxCMw 2021-03-04T23:00:00.000Z It’s a new dawn, it’s a new day, it’s a new device for me — and I’m feelin’ good

This is getting out of hand, now there are two of them! That’s right, multi-device is back and better than ever. Now that we’re running on the slick new Session Protocol, we’re finally able to bring back one of our most requested features: multi-device.

In August of last year we came to the decision to put a pause on multi-device support — its implementation was just too unstable for our liking. As it turned out, creating a system for messages to be synced on a completely decentralised, anonymous messaging app was… hard.

Part of the reason we moved to the Session Protocol was to fix this problem. Rather than using the Signal protocol, which wasn’t built to handle a decentralised application, we decided to develop our own protocol based on the Signal protocol — but streamlined and designed around our needs. The return of multi-device is only the beginning. The Session Protocol will allow us to implement heaps of changes we’ve been wanting to make (and you’ve been asking for) for ages.

Multi-device isn’t all we’ve got for you, we’ve also packed in a brand new look for the iOS conversation screen, quality of life changes to voice messages, and some performance and reliability improvements.

We’re here to link devices and chew bubblegum — and we’re all out of bubblegum

  • Session now supports multi-device — again (iOS, Android, Desktop)

It’s the big one, multi-device is back and better than ever. Since this is still in beta, we wrote a guide to setting it up, which you can view here.

  • The conversation screen now has a fresh new look! (iOS)

Out with the old and in with the new, Session now has a fresh coat of paint. The conversation screen is where you spend most of your time on Session, so making sure it’s spick and span is high priority.

  • Voice messages will now play one after another if there’s multiple (iOS)

We know you want to hear all of your friends’ beautiful voices as smoothly as possible, so now you can listen uninterrupted.

  • Swipe to reply (iOS)

It can be cumbersome to tap-and-hold messages to reply, so we’ve streamlined the process of replying with “lmao” to all the memes your friends are sending.

  •  Double tap a voice message when it’s playing to speed it up (iOS)

Look, we get it: you’re busy. There’s just not enough time in the day — and we’re here to help. Now you can get all of your daily listening down in record time, and the bonus of making everyone sound like a chipmunk — who says efficiency can’t be fun?

  • Fixed an issue that could prevent the conversation screen from scrolling properly (iOS)

We all hate to be stuck, whether it be in traffic, a queue, or on your conversation screen — well, we can help with one of those. Scrolling should now be smooth as butter.

  • You can now set nicknames for contacts by going into the conversation settings and editing the name (iOS)

Have you got 4 different contacts all called Alex? Well there’s no need to confuse them any more, now you can be sure who is who at a glance.

  • The app now shows the number of unread messages for a conversation (iOS)

No more being ambushed by 56 unread messages, now you can know exactly what you’re getting yourself into before you dive into a conversation.

  • When opening a conversation, Session will now automatically scroll to the first unread message in that conversation (iOS)

We know your time is valuable, and we want to want to make sure not to waste it. Now you can find the messages you want to see straight away and spend more time thinking up the perfect response.

  • Improved closed group reliability (iOS, Android, Desktop)

  • Improved performance (iOS, Android)

Just a few under-the-hood changes to make sure that Session delivers the most streamlined and reliable experience possible.

What’s that on the horizon? It looks like Session usernames!

As always: there’s a lot coming up for Session. Multi-device is still in early beta, so a big part of the plan is to work on its implementation and take it from beta to the best version it can be.

We’re also working on rewriting the code for message sending and receiving on Android to help with stability and to allow us to move faster on fixing bugs in this area in future. And don’t worry, robot lovers — we’re not playing favourites. We’ll also be giving Android a brand new look for the conversation screen to match the iOS makeover.

Oxen Name Service support is also on the table for the next round of updates, allowing users to spend Oxen to buy a permanent Session username to replace their Session ID. And, as always, we’ll be squishing, squashing, and spraying every bug we find.

Thank you!

Once again we want to thank you for your support, and your questions and comments. We’re doing as best we can to continue to innovate and push the limits of blockchain technology and your feedback is invaluable in doing so. Keep it coming and we’ll do our best to keep the improvements coming too.

So long, and we’ll see you again soon!

— The Session team

<![CDATA[Multidevice beta: How you can use it — and help improve it]]> 1H0Qgc0988pXpS2bAQb5nx 2021-02-15T23:00:00.000Z A while back, we pulled multidevice support back into the workshop with the aim of implementing a more effective version in future, promising it would return someday.

Well, today is that day, and the future is now. Multidevice is rolling out in early beta right now to an App Store or Play Store near you!

So how does it work?

Using multidevice: The steps

  1. Set up a Session ID on one of the devices you want to use in a multidevice configuration (if you already have a Session ID set up, skip to Step 2)

  2. Download Session on the second device you want to set up with the same Session ID, but do not create a Session ID on this device

  3. Copy the recovery phrase for the Session ID set up in Step 1

  4. Restore that recovery phrase on the second device

Done! Your second device should now sync with your first device, and both devices should be able to send and receive messages from the same Session ID.

Known issues

There are a few known issues with this early beta release of multidevice.

  • Leaving open groups does not sync between devices (resolution: leave the open group on both devices)

  • Message expiration timer changes (disappearing message timers) do not currently sync between devices (resolution: manually change the timer to the desired setting on both devices)

  • When you restore your Session ID to your second device, you’ll be asked for a display name. You must set this display name to be the same as on your first device. If you don’t, your display name when messaging other people will alternate depending on which device you’re messaging from!

  • If you have already tried restoring your recovery phrase to multiple devices prior to this release, you may encounter unexpected issues (resolution: if you have already tried restoring your recovery phrase to multiple devices prior to this release, you may need to create a fresh Session ID for multidevice to work as intended)

Multidevice is in early beta, so there may be issues we aren’t aware of. If you encounter any unexpected behaviors or bugs, report them on our GitHub (Desktop; iOS; Android) or contact us directly at to let us know!

<![CDATA[Data, data, data: Session user analytics and anonymity]]> 3iWfQAUE0RwgQOx7DRdtzs 2021-02-09T23:00:00.000Z Session has been seeing massive user growth recently, with tens of thousands of active users in dozens of countries around the world. But hold on a minute — Session is also completely anonymous, with no phone numbers or other identifiers. So how do we know how many users we have, or where they are?

Mobile app stores: Opt-in options

When you create an account with the Apple App Store or Google Play Store, you’re asked whether you want to share diagnostics and usage data with Apple (or Google) and app developers. If you opt in to usage data sharing, Apple (or Google) will collect some basic, somewhat anonymised information about the apps you install, use, and uninstall, including which apps you download, whether you launch them after downloading them, whether you uninstall them, and how long you keep them installed. This information is then made available to mobile app developers.

Developers cannot see any information about individual users — they can see the basics, like download numbers, the number of active users, user retention (how many people continue actively using an app after downloading it), and which countries an app is being used in.

But if you don’t opt in to sharing diagnostics and usage data — Apple (or Google) does not collect any information about your app usage after installing an app. That means your app usage is not included in the user numbers developers see.

Known unknowns

So what does this mean for Session? Well, first and foremost, it answers the question of where we get our user data. Apple and Google provide us with basic, anonymised information about how many people are using Session, and which countries Session is used in.

Session itself has absolutely no trackers or other privacy-invading technology, and only users who have opted in to diagnostics and usage data sharing are included in those App Store and Play Store statistics. So when we say that we have “more than 50,000 active users”, we actually don’t know just how many more. Because Session’s users are privacy-conscious people, it’s quite likely that there are a lot of people actively using Session on their mobile devices with data sharing disabled — but we’ll never know about them.

And because Session Desktop is downloaded directly from our privacy-respecting downloads page, we have no information about how many active desktop users we have, where they are, or anything else — all we know is the total download count.

Bonus privacy tip: Making your device respect (more of) your privacy

If you want to make sure your mobile device isn’t collecting your usage data, you can disable that feature in just a few easy steps.

On iOS:

  • Open Settings

  • Go to Privacy > Analytics and Improvements

  • Switch off any data sharing toggles you’re uncomfortable with

On Android:

  • Open Settings

  • Go to Google > More > Usage & diagnostics

  • Turn Usage & Diagnostics off

(Note: steps on Android may vary slightly depending on the Android skin your device is running)

<![CDATA[Session Release Roundup #10: Mega edition]]> 2uZg3bvgfJWpT1cDweuO84 2021-01-27T23:00:00.000Z Closed groups grow to 100! Plus: Protocol changes, performance improvements, and more

Hello, it’s me, haven’t seen you in a while. It’s been a few months since we last piped up, but don’t worry — we’ve been hard at work tippy-tapping away, writing, wrangling, and working on brand new code to build a bright future for Session.

It took a lot of coffee, elbow grease, and rocket fuel, but the Session Protocol is done! And the update is live… as in, now!

The new protocol makes Session smoother than a triple cream brie — so if you’ve tried Session before and put it down, now is a great time to pick it back up and give it another spin.

Without further ado, welcome to the biggest Session Release Roundup in history! Let’s roll.

I can’t believe it’s not butter! Session: Now smoother than ever

We’ve been talking about the Session Protocol for a little while now — and it’s out. Thanks to Session’s new super-slick protocol, you should notice top-to-bottom performance and reliability improvements across the entire app.

  • Finalised implementation of the Session Protocol. iOS, Android, Desktop

  • Multiple crash fixes. iOS, Android

  • Improved message sending reliability. Android

Note: If you haven’t already updated to the latest, Session Protocol-based version of the app, make sure to do so — older clients can no longer communicate with the Session Protocol-powered latest versions.

Lots of you have been asking about closed group sizes. We hear you. Closed groups are now 5x bigger.

  • Increased maximum closed group size to 100. iOS, Android, Desktop

  • Fixed open group profile picture bug. iOS

  • Improved closed group reliability. iOS, Android

With supercharged closed groups, you’ll want to get all your mates on Session. We’ve added a handy in-app invite button to help you and all your friends go green.

  • Added in-application invite button. iOS, Android

  • Fixed issue preventing you from copy-pasting Session IDs. Android

Push notifications have long been Session’s white whale. Turns out creating reliable push notifications in a decentralised, end-to-end encrypted, hardcore private messenger is… tricky. After a long journey, type: embedded-entry-inline id: V7VdjIv7FXZnDo9hoXdGv Niels has conquered the beast.

  • Increased push notification reliability. iOS, Android

  • Push notifications now preview message content and sender, instead of displaying generic ‘You have a new message’ notification. iOS

  • Push notifications now always successfully appear. Android

  • Upgraded background polling (slow mode). Android

A few months back, Session IDs received a security upgrade. At first, we let people keep their old Session IDs if they wanted to — but (if you haven’t already) the time has come for everyone to get themselves a shinier, safer, smarter Session ID.

  • Made Session ID upgrade mandatory. iOS, Android, Desktop

In 2021, no chat app is complete with just text messages — you have to be able to send memes, voice messages, videos, and animated Powerpoint presentations. Sometimes iPhone users weren’t getting their attachments, leaving them longing for their multimedia fun.

  • Fixed onion request issue which caused occasional attachments download failure. iOS, Android

  • Attachments now download automatically after opening the app via push notification. iOS

Voice messages are great — maybe you want to add a personal touch, or just don’t have a hand free to mash a message on your keyboard. We’ve given voice messages some upgrades for when a text just isn’t enough.

  • New and improved voice messages design. iOS, Android

  • Fixed voice messages not playing when device is muted. iOS

  • Voice messages limited to one minute duration. iOS, Android

Link previews are handy to make sure you’re not about to get Rick Rolled — or at least just give you an idea of where that link is heading. Now, Session will show previews for each and every link you’re sent.

  • Enabled link previews for any any URL. iOS, Android

Free and open access is an important part of Session — and that means everything from the under the hood design all the way to accessibility features like VoiceOver. This update is packing some much improved VoiceOver support for vision-impaired Session users.

  • Improved VoiceOver support. iOS

Just because you remove someone from a closed group doesn’t mean the party has to end. Closed groups weren’t working properly after people were removed  — but we’re making progress on fixing that up.

  • Fixed some issues in closed groups after user removal. iOS, Android, Desktop

Session has tapjacking protection baked right into the app, but the message that displays when these safety measures kick in was showing up incorrectly — all fixed now.

  • “Interaction temporarily disabled for security purposes” dialog no longer displays unnecessarily. Android

Guess who’s coming back, back again? Multi-device!

That’s right, now that the Session Protocol is in the field, our old friend multi-device is slated for a comeback. We decided to put multi-device on the bench late last year, but after that temporary time-out, it’s time to bring back what has become one of our most-requested features.

We’ll be putting a lot of work into getting multi-device working, but the good news is that it should actually be much easier now that the significantly streamlined, purpose-built Session Protocol is implemented on all platforms.

Closely trailing after multi-device and bigger closed groups in the most-requested-features marathon is account restoration. Not just Session ID restoration — but full restoration including messages and contact history. We’ll be digging in and starting on a fully-fledged version of account restoration in our next sprint.

Thank you!

The climb towards full implementation of the Session Protocol has been an epic one. Thanks to everyone who has already updated, and followed us along the way towards its creation. Now that the Session Protocol is established, Session is well and truly off to the races.

So long, and we’ll see you again soon!

— The Session team

<![CDATA[How to help us translate Session into new languages quickly and easily]]> 2AEOuG9RJjsKwUCdTu8hc9 2020-12-27T23:00:00.000Z There are people all around the world who can benefit from access to Session — and that means we need to make Session available in as many languages as possible. We’ve had a number of requests from community members wanting to help out by translating Session into currently unsupported (or only partially supported) languages. If you speak multiple languages and you want to help us make Session available in another language you speak, this guide will show you how to translate Session’s iOS and Android apps quickly and easily.

Translating Session for iOS:

Translating Session for iOS into a new language is easy! Here’s how:

  • Head to

  • Create a CrowdIn account (or log in to an existing account)

  • Click on the language you’d like to translate Session into (note: the % beneath each flag shows how much of the app is already translated into that language — if a language shows 100%, that translation is already complete!)

  • On the next screen, click localizable.strings

  • You’ll see a screen with a list of items on the left — these are the “strings” (chunks of text) that need to be translated

  • Click the first string in the list, read the English text that appears under “Source String” in the middle of the screen, then type in the translation and click Save

  • Repeat this process for the rest of the strings

Voila! Just like that, you’ve helped us translate Session into a new language.

Anonymous translation for iOS

We know many Session users may not want to link their identity to anything related to Session — including CrowdIn. If you want to help us translate Session but you don’t want to create a CrowdIn account, you can still help — it’s just a little more involved. You’ll need a web browser, a plaintext editor (TextEdit on macOS or Notepad on Windows will do), and a little bit of time and patience.

Step 1: Retrieving English strings

  • Go to Session’s iOS GitHub page

  • In the list of folders and files, click Session

  • Click Meta

  • Click Translations

  • Click en.lproj

  • Click localizable.strings

  • Scroll down to Line #2557 (using the line numbers on the left-hand side of the text). This line should contain the text // MARK: - Session (Note: if this line does not contain that text, use Ctrl+F, Cmd+F, or your browser’s Find on Page function to find the line which contains that text)

  • Select and copy all text from that line down to the end of the file

  • Open a plaintext editor (TextEdit on macOS, Notepad on Windows, or your preferred plaintext editor) and create a new file

  • Paste the text you copied earlier into this blank file

Step 2: Translate!

This file will now have a large number of lines of code. Each line contains 2 sets of information, both in quotation marks, like this:

"continue_2" = "Continue";

For each line of code, translate the word or sentence to the right of the equals sign into the language you are translating into. Do not edit the text to the left of the equals sign.

Once you are finished translating, save the file with a filename that specifies which language you have translated the app into, and email the file to us at along with information about the language you have translated the app into. Be sure to specify in your email that you have translated the iOS app (for information on translating the Android app, see below). Our developers will then take your translation and apply it to the Session iOS app. Thank you for helping make Session more accessible for everyone!

Translating Session for Android:

Translating Session for Android into a new language is easy! Here’s how:

  • Head to

  • Create a CrowdIn account (or log in to an existing account)

  • Click on the language you’d like to translate Session into (note: the % beneath each flag shows how much of the app is already translated into that language — if a language shows 100%, that translation is already complete!)

  • On the next screen, click strings.xml

  • You’ll see a screen with a list of items on the left — these are the “strings” (chunks of text) that need to be translated

  • Click the first string in the list, read the English text that appears under “Source String” in the middle of the screen, then type in the translation and click Save

  • Repeat this process for the rest of the strings

Voila! Just like that, you’ve helped us translate Session into a new language.

Anonymous translation

Just like with iOS, we know many Session Android users may not want to link their identity to anything related to Session — including CrowdIn. If you want to help us translate Session for Android but you don’t want to create a CrowdIn account, you can still help — it’s just a little more involved. You’ll need a web browser, a plaintext editor (TextEdit on macOS or Notepad on Windows will do), and a little bit of time and patience.

Step 1: Retrieving English strings

  • Go to Session’s Android GitHub page

  • In the list of files and folders, click res

  • Click values (you will need to scroll down to find this folder; make sure you click the folder named values and not any of the folders named values-xx or with other suffixes)

  • Click strings.xml

  • Scroll down to Line #1657 (using the line numbers on the left-hand side of the text). This line should contain the text  <!-- Session --> (Note: if this line does not contain that text, use Ctrl+F, Cmd+F, or your browser’s Find on Page function to find the line which contains that text)

  • Select and copy all text from that line down to the end of the file

  • Open a plaintext editor (TextEdit on macOS, Notepad on Windows, or your preferred plaintext editor) and create a new file

  • Paste the text you copied earlier into this blank fil

Step 2: Translate!

This file will now have a large number of lines of code. Each line will contain <string name=”xxx”> and </string> tags. To translate Session Android, translate the text between these tags. For example:

<string name="continue_2">Continue</string>

In this line, translate the word Continue into the language you are translating into. Do not translate any other text. Do not translate the text inside either pair of angled brackets <>.

Translate the word or sentence between each pair of <string></string> tags, on each line.

Once you are finished translating, save the file with a filename that specifies which language you have translated the app into, and email the file to us at along with information about the language you have translated the app into. Be sure to specify in your email that you have translated the Android app (for information on translating the iOS app, see above). Our developers will then take your translation and apply it to the Session Android app. Thank you for helping make Session more accessible for everyone!

<![CDATA[The Session Protocol: What’s changing — and why]]> 4u7qZepUnv6BAGxNHKLoPK 2020-12-15T23:00:00.000Z Note: This article provides a non-technical overview of what the Session Protocol will achieve, and why we’re introducing it. For a more detailed, highly technical explanation of the Session Protocol, check out our technical deep dive.

One of the most vital steps when setting out to build a private messenger is threat assessment. In order to determine which features should be prioritised, developers need to understand how and when each feature will be beneficial to you — the user.

As an example of this type of process, we can take a look at a specific example of threat assessment being employed. Any messaging application needs to decide how (or if) messages will be protected from prying eyes. The simplest way to transmit messages is in plaintext (in other words, not encrypted) — it’s easy to implement and work with, but any third party that can access the messages while they’re in transit or at any other point will be able to read them, so if you’re after security, this option is out.

One step up from there is encryption in transit and at rest, where messages are encrypted in transit between devices, but are decrypted upon reaching the server that routes them. This method provides protection against unauthorised parties accessing the messages in transit, but still allows for anyone with access to the central server to read the contents of every message, along with viewing metadata associated with a message, including information about the sender and recipient. If such a threat is important to protect against, it’s necessary to go another step further — end-to-end encryption.

If you’ve spent any time reading about private messengers, you’ve probably heard of E2EE before. E2EE means that only the sender and the recipient have the means to decrypt messages. Neither the central message-routing server nor any third parties who intercept messages in transit can see the contents of an E2EE message. Many applications don’t use end-to-end encryption, either because of the additional development costs to implement or because they want central servers to have access to user messages — it’s all down to developers’ threat assessments, and the protections and mitigations they decide to implement.

Companies or projects that want the highest degree of privacy and security for their users will often consider implementing a decentralised infrastructure for their app or service — with no central servers whatsoever, users don’t have to worry about trusting the entity running the network at all.

Mission: Possible — Session Protocol

In Session’s case, our analysis has led us to a conclusion: the features we think will be most important for our users are best served by migrating Session to its own encryption protocol — the Session Protocol.

The Signal Protocol is great at what it does, and what it does is security — a whole lot of it. Session does security too, but the problem is that Session’s scope also includes a focus on anonymity and decentralisation. Now that Session is well-established and we’re working to add features, one issue keeps cropping up: the Signal Protocol simply wasn’t built to work this way. It was built to operate in a centralised environment, and we’ve been trying to shoehorn it into Session’s starkly different infrastructure.  That’s where the Session Protocol comes in. This new protocol will let us improve stability and streamline the development of new features. Of course, nothing in life comes easy, and there are a few features that won’t join us on the next leg of this adventure. However, the benefits of the Session Protocol make this transition well worth it.

PFS and deniable encryption: Effective protection… in theory

First things first, let’s talk about what we’re leaving behind: Perfect Forward Secrecy (PFS) and deniability. For more information about these properties, you can check out our technical deep-dive on the differences between the Signal and Session protocols, but read on for an abbreviated overview.

PFS means that if long-term keys for a given conversation are compromised, only a small amount of recent messages can be decrypted. However, under typical circumstances, the only way long term keys can be compromised is through full physical device access — in which case an attacker could simply pull the already-decrypted messages from the local database.  As is often said in the infosec community, physical access is total access.

Cryptographic deniability, or deniable authentication, prevents either party in a conversation from proving the origin of any message to a third party — essentially, Alice can’t cryptographically prove to anyone outside the conversation that Bob was the one who sent a specific message. The problem is that practical applications for deniability are very limited. Court rulings and media reporting both commonly ignore deniability and defer to evidence of the conversation taken directly from the device — like screenshots. One example of deniability as an unsuccessful defense was in the case of the communications between Chelsea Manning and Adrian Lamo.

Session’s mitigations

The simple fact of the matter is that Session provides protections against these types of threats in other ways — through fully anonymous account creation, onion routing, and metadata minimisation, for example. These protections will prove as effective, or more so, in many real-world scenarios within Session’s scope and threat model.

We believe the new possibilities and significantly streamlined encryption pipeline introduced by the Session Protocol make these tradeoffs well worth it for our users.

In addition, Session will be introducing a new feature to mitigate edge-case risks associated with message retrieval. Session messages are temporarily stored on specific “swarms” of 5-7 nodes, from which they can be retrieved by a Session client if the client is offline at the time a message is sent (and thus unable to receive the message in real-time). We will be implementing long term key-based signature checks into this retrieval process as an additional layer of security to prevent any device or client besides the intended recipient from retrieving messages being held in temporary storage on swarms. Because messages remain fully encrypted while in swarm storage, such a risk is extremely minimal even under the current implementation. However, we want to make Session as secure and private as possible, which means taking steps to mitigate risk wherever possible, all while building a messenger with high levels of functionality and ease of use.

Party rockin’ with the Session Protocol

Now the fun part: the benefits of this new protocol. First off, simplicity — we built it, we know the ins and outs, and we can build on it to create the features you want (and need). The switch will also fix some bugs relating to the way key pairs are exchanged in the Signal Protocol (once again, for more information visit this deep-dive).

Multi-device is one key feature that the Session Protocol will let us implement (or re-implement, in this case). We’ve had a hell of a time trying to cram a decentralised multi-device implementation into the Signal protocol, but try as we might, it just wouldn’t fit. Now that we have our own protocol, we can streamline the process and reimplement multi-device much more easily. Account restorations will also be made much more reliable.

The most important feature of this new protocol is that it is purpose-built for Session. The Signal protocol was exactly what we needed when starting out, but as Session has grown, it has become clear that it requires a protocol designed for a decentralised platform.

The Session Protocol:  A win for devs and users alike

When assessing threats and practical ways to mitigate them, ranking both threats and mitigations is a vital step. Our transition to the Session Protocol comes down to the types of protections we believe will be most meaningful in the real world to the majority of our users. We believe that anonymity and decentralisation can provide strong protection against censorship, privacy infringement, and other threats. We want to optimise Session to solve these wider issues — and the Session Protocol is the best way to do that.

<![CDATA[Session Protocol: Technical implementation details]]> 39jdRkgJSHwpZTdE4uJ7N7 2020-12-14T23:00:00.000Z Note: This blog is a highly specialised writeup containing detailed information about the new Session Protocol. For a less technical overview of what’s happening and why, check out our overview of the Session Protocol.

Since Session’s first release, we’ve used the Signal protocol to provide end-to-end-encryption (E2EE) for all one-on-one chats, and the Sender Keys system for encryption in closed groups. Taken together, the Signal protocol and the Sender Keys system provide certain cryptographic properties to each conversation, specifically Perfect Forward Secrecy (PFS), deniability, and (in the case of the Signal protocol) self-healing. In some theoretical scenarios, these properties do protect users; however the utility of these protections in real-world scenarios is often more limited in scope than might be expected. We must also consider that these safeguards are offered at the expense of additional complexity, decreased account portability, and multi-device limitations. These protocols were simply not designed to be run over a decentralised network.

To empower future development efforts, and thus ensure that Session is able to acquire as many users as possible over the course of 2021, it is necessary for us to use a more streamlined, purpose-built protocol. This will allow us to focus on delivering increased reliability, implementing features such as a scalable version of a multi-device, better restoration from backups, and massively simplifying the codebase. The new Session Protocol accomplishes all of this while maintaining E2EE and sacrificing very few practical benefits over the Signal protocol.

Properties of the Signal protocol

We will begin by examining the properties provided by the Signal protocol, and how these properties function to protect users both theoretically and in real world scenarios.

Perfect Forward Secrecy (PFS)

PFS is a feature provided by the Signal protocol which protects former conversations or messages from being read when long-term key information is exposed. This is achieved through key ratcheting — periodically deriving new shared ephemeral keys which are used for message encryption. These keys are periodically deleted from the device each time new keys are derived, meaning those messages will not be able to be decrypted even if your long-term private key is compromised.

PFS specifically provides protection when the long-term keys of a device are compromised. Assuming the application properly manages keypairs, the only way this should occur is through full device access. It is this detail which limits the cases in which PFS is applicable. If an attacker has full device access, decrypted messages can be pulled directly from the Signal/Session database.

PFS would be effective in the instance of a user using disappearing messages or if manually deleting messages while an attacker was intercepting their messages at the network level. In this case, the attacker could not decrypt the messages collected at the network level by compromising the long-term key of the device. However, the usage of disappearing messages is low, and sophisticated attackers that have full network and device access are likely to perform easier and more damaging attacks, like accessing current contact information, reading future messages, and compromising device information — which neither the Signal protocol nor the Session protocol are currently able to protect against.

Deniability, also known as deniable authentication, allows for both parties in a conversation to authenticate the origin of the message(s) they receive during the conversation, but prevents either party from proving the origin of the message to a third party post-conversation. This property is provided in the Signal protocol through the derivation of per-conversation shared encryption keys, which are used for encryption and authentication. Messages are not signed with a long-term identifiable key.

Deniability in the Signal protocol is a cryptographic property which prevents a cryptographic proof from being provided that a person signed a message with a particular key. In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting. For example, cryptographic deniability was used unsuccessfully as a defense in a court case involving the communications of Chelsea Manning and Adrian Lamo. Instead, courts often rely on screenshots of conversations from a dishonest chat partner or seized devices to establish the real world identities of the chat participants.

Additionally, deniability fails to provide protection if a chat partner or device is compromised during the sensitive conversation. In such a case, the compromised participant or device can prove which device or chat partner sent which messages post-conversation.

Self-healing is a property of the Signal protocol which ensures that if a ratchet key is leaked, no future message keys can be derived from it, and thus, no future messages will be compromised. This property is provided by ongoing Diffie-Hellman key exchanges which reset sending and receiving ratchets. Without these secrets, the exposure of a ratchet key only allows the attacker to read messages associated with the current ratchet.

If keys are being properly managed by the application, the only way a session key could be compromised is if the attacker gains full device access. If an attacker can gain access to the device, then they can read previous plaintext messages from the database. If full device access is gained, they can also use the long-term keys of the device to request a session reset, which will lead to all future messages being compromised by the attacker.

Sender Keys

Session uses a modified version of the Sender Keys component of the Signal protocol, which was developed by Signal but is not currently used in the Signal application (the most prominent current deployment of Sender Keys is in WhatsApp). Sender Keys provide all closed group conversations with PFS and deniability, but not self-healing. These protections are primarily provided through agreeing on a shared group key using the existing 1-1 chat mechanism and then establishing a Sender Key per participant which ratchets after each message is sent.

As a derivative feature of the Signal protocol, the Sender Keys system has many of the same properties, and thus the same practical drawbacks. If an attacker compromises any of the devices in the chat and participants do not have disappearing messages turned on, the attacker can simply read all messages straight from the database. If the attacker compromises the long-term keys of any of the devices in the chat, then all future messages can be read. Deniability is provided by enforcing the non-signing of messages with each device’s long-term keys. However, just as with cryptographic deniability for 1-1 messages when used as a defense in the media or court system, cryptographic deniability for group chats is largely impractical as a real-world defense in such situations.

The Session Protocol: Rollout and technical information

Rollout details

The Session Protocol will be rolled out in two stages. The first stage, which was released to mobile app stores and the desktop client on Friday Dec 11 AEDT, is a modified version of the Session Protocol which maintains backwards compatibility with older Session clients still relying on the Signal protocol. This version of the protocol is detailed below as “Session Protocol with backwards compatibility”. The second stage, which will be released at a later date, will strip out the backwards compatibility layer, fully realising our vision for a streamlined E2E encryption protocol. This version of the protocol is detailed below as “Session Protocol (full implementation”.

Technical details

Session Protocol with backwards compatibility: 1-to-1 chats

A long-term X25519 keypair is generated for each Session account at time of account creation, and the public part of this keypair is the account’s “Session ID”.

Consider a scenario where Alice wants to send Message M to Bob, whose Session ID is `IPK_2`. To do that, Alice first signs Message M using her private (identity) key `IPK_1`:

S = sign(M, IPK_1);

Alice then generates an ephemeral keypair `(ESK, EPK)`, where ESK and EPK are private and public components, respectively. She then performs an Elliptic-Curve Diffie Hellman (ECDH) over `(ESK, IPK_2)` to generate a shared secret, which is then used to derive a shared key `SK` using a key derivation function HKDF. Alice can now use a symmetric cipher (AES-GCM) to get ciphertext `C` using `SK` to encrypt `(S || M)`.

The ciphertext is sent to Bob, along with the public component of the ephemeral keypair `EPK`.

Bob performs ECDH over `(ISK_2, EPK)`, repeating the same steps as Alice to obtain the secret key `SK`. Bob can now use `SK` to decrypt the ciphertext `C` and obtain `S || M`. Bob can check the validity of the signature using Alice’s identity key, ignoring the message `M` if the signature is invalid. If the signature is valid, it is deleted and the message is stored in the device’s local database.

Session Protocol (full implementation): 1-to-1 chats

Under this scheme, a message (M) consists of the message being sent, the sender’s ED25519 public key, and the recipient’s X25519 public key. This message is then signed using the crypto_sign() function in libsodium with the sender’s ED25519 private key to produce S. The plaintext message and the signature are then encrypted using libsodium’s crypto_box_sealed() function, taking the sender’s ED25519 public key and the recipient’s X25519 public key to produce X. X is then sent to the recipient, along with the message tag (the recipient’s public X25519 key) which ensures that the message can be identified and requested from the swarm.

m = message || sender_pubkey_ed25519 || recipient_pubkey_x25519

s = signature(m, sender_privkey_ed25519)

x = crypto_box_sealed(message || sender_pubkey_ed25519 || s, recipient_pubkey_x25519)

Session Protocol with backwards compatibility: Closed groups

When a user wants to establish a closed group, they will generate a shared long-term symmetric key `SK` and share it with other members via pairwise channels, as is the case in the Sender Keys protocol. However, unlike under the Sender Keys system, users will not establish individual Sender Keys. Instead the messages will be encrypted directly with `SK` using a symmetric cipher, and messages will be signed with users’ identity keys. New entrants to a group will be notified of the current `SK` so they can begin sending and receiving messages. When a user leaves, or is kicked, the group will establish a new shared group key `SK’`.

Session Protocol (full implementation): Closed groups

As an overview of the scheme, first the creator of the group will derive a shared ED25519 public keypair for the group. This key will be shared to all group members via the 1-1 chat network.  Once a member has this keypair, they can identify new messages destined for the group and encrypt new messages for the group.

A message (M) consists of the message being sent, the sender’s ED25519 public key, and the group’s shared X25519 public key. This message is signed using the crypto_sign() function in libsodium with the sender’s ED25519 private key to produce S. The plaintext message and the signature are then encrypted using libsodium’s crypto_box_sealed() function taking the sender’s ED25519 public key and the group X25519 public key to produce X. X is then sent to the group’s defined swarm, along with the message tag (the group’s X25519 public key), which ensures that the message can be identified and requested from the swarm.

m = message || sender_pubkey_ed25519 || sharedgroup_pubkey_x25519

s = signature(m, sender_privkey_ed25519)

x = crypto_box_sealed(message || sender_pubkey_ed25519 || s, sharedgroup_pubkey_x25519)

Session Protocol: Advantages

Simplicity and reliability

Using existing long-term keypairs in place of the Signal protocol massively simplifies 1-1 messaging. Complex key exchange processes and sharing of prekey bundles — processes which are particularly difficult to manage in a decentralised environment — are no longer required. This new protocol also makes it impossible for sessions to go out of sync or for messages to be encrypted for nonexistent sessions — both very common errors frequently encountered by Session users under the current protocol.

For closed groups, removing individual sender keys removes the need to progressively ratchet keys for each user, which can also cause messages to be encrypted for nonexistent sessions.

Under the Session Protocol, multi-device can be reimplemented by simply sharing a user’s long-term key pair to a new device and duplicating sent messages back into their own swarm. This is significantly less complex and intricate than our old approach to multi-device, which required that sessions be kept constantly in sync between multiple devices which could be online or offline, without relying on a centralised server.

Account restoration

The removal of ephemeral keys stored only on a local device will massively increase the portability of Session accounts. This means that when restoring your Session ID, you will be able to receive new messages immediately. Under the previous implementation (i.e., the Signal protocol), new messages would be encrypted for nonexistent sessions until the user who restored their account performed a session reset.

Code implementation

The Signal protocol maintains three complex yet separate implementations of the Signal protocol between Android, iOS and desktop clients. The simplicity of the Session protocol allows the encryption and decryption pipelines to be implemented in less than a page worth of code — code which can effectively be standardised across all platforms. This significantly reduces the difficulty of making future changes, and also makes the protocol easier to understand and analyse from a security perspective.

Session Protocol: Theoretical disadvantages

Switching to the Session Protocol means that Session will no longer have deniability and PFS in 1-1 chats, or PFS in closed groups. However, as previously discussed, these properties provide only limited protections in real-world scenarios. To demonstrate this, it is useful to explore situations in which the Session Protocol would be weaker than the Signal protocol and old closed group Sender Keys system.

Perfect Forward Secrecy

If an attacker has full device access, neither the Session Protocol nor the Signal protocol can prevent an attacker from reading all previous messages in the conversation by pulling plaintext message history directly from the device. If the attacker has full device access and the user has disappearing messages turned on, both the Session Protocol and the Signal protocol prevent the attacker from reading any previous messages.

If an attacker has both full device access and targeted network scraping capability, and the user has disappearing messages turned on, the Signal protocol can protect users’ previous messages from being read, while the Session Protocol will not. The situation for closed groups is similar. There are ways for Session to limit the scope of this attack by limiting the data which an attacker can scrape, which will be discussed later.

All messages sent using the Session Protocol are signed with the long-term key of the sender, and thus a cryptographic proof can be provided to a third party proving that a particular keypair did indeed sign a message.

However, since signatures are immediately deleted after validation, this limits the Session Protocol’s divergence from the practical benefits of the Signal protocol in real-world scenarios. Practically speaking, an attacker or recipient would need to have compromised the device’s long-term key pair and be able to scrape messages off the network or off the device before the signature was deleted in order for this difference to have any meaningful security implications, and as with the scraping attack discussed above, there are protections which can be deployed against this type of scraping.

The Session Protocol has no session keys, and thus the self healing property of the Signal protocol is not retained. If long-term keys are compromised in either protocol, an attacker can compromise future messages by requesting a session reset.

Addressing theoretical disadvantages

Scraping: Protections and mitigations

Since all messages in Session are onion-routed to their destination swarm, they cannot be scraped during transit by ISPs or the Service Nodes in the onion routing path due to the additional layers of encryption provided by onion routing. Messages can however be scraped from the swarm, either by any of the nodes in the recipient’s swarm (a swarm typically consists of 5-7 Service nodes) or by another entity which makes a request to a node in the recipient’s swarm.

Currently, message retrieval requests are unauthenticated, meaning any user can request any other user’s (encrypted) messages. To limit scraping, we will require a signature from the requester’s long-term key. This signature will be validated by the Service Node, which ensures that unauthorised parties cannot scrape data from swarms without being able to produce a signature from the long term key belonging to a stored message. This does not prevent scraping in every possible scenario; a sufficiently well-resourced and motivated attacker could run Service Nodes and pull messages directly from their own database. However, this would be extremely costly due to the staking requirement needed to run a Service Node (~US$15,000). Further, since Service Nodes cannot choose their swarms, targeting particular users would be extremely difficult to the point of practical impossibility.

On the loss of cryptographic deniability

As previously mentioned, cryptographic deniability is often something that is largely ignored by the court system and the media. If contextual information can be provided around screenshots, this is often enough to lead to a conviction or personal damages, regardless of the presence or absence of cryptographic deniability.

Instead of designing a cryptographic protection, Session will add the ability to edit other users’ messages locally, thus providing a way to completely forge conversations. Since signatures are deleted after messages are received, there will be no way to prove whether a screenshot of a conversation is real or edited, diminishing the value of screenshots as evidence.

Other Notes

There are certain other aspects of Session which further limit the need for use of the Signal protocol.

Ephemeral identities and anonymous account creation

Unlike in Signal, where accounts are tied to their phone numbers and tend to be established and maintained for a long period of time, Session is built on the concept of ephemeral identities. Session IDs can be created and abandoned on a per-conversation basis, weekly, monthly or as often as a user likes. If you want to destroy your account and create a new one, you can do so at any time, and there will be absolutely no cryptographic link between that account and your real world identity. This limits the likelihood of key compromise or message scraping.

Onion routing

Session’s use of onion routing for message sending and receiving increases deniability at the network level since no central server has a log of when messages are retrieved or sent, or which IP addresses are sending or receiving those messages. This is not the case in Signal; Signal’s central servers have a log of which IP address sends which message and which IP address retrieves that message.

The Session Protocol massively reduces application complexity, makes sessions easier to manage, and increases account portability, all while increasing reliability and making highly-requested features like multi-device, account restoration, and other upcoming improvements significantly easier to implement.

The practical protections provided by the Session Protocol and the Signal protocol in real-world scenarios are similar. Furthermore, features being added to the Session application, such as authenticated Service Node requests and recipient-side message editing, bring the practical benefits of the two protocols virtually in line with each other — all while massively increasing message sending and receiving efficiency, and enabling development of exciting new features.

<![CDATA[The Session Protocol: A new standard for decentralised private messaging]]> 4lVDKORcC33YiQyyr7Bsz0 2020-12-13T23:00:00.000Z Session has come a long way since its public launch in January of 2020. Today, we’re announcing the next big step for our lean, mean encrypted messaging machine: a new encryption protocol, built from the ground up for decentralised secure messaging. But before we dive into that, let’s take a walk down memory lane and look at where we’ve been, where we are, and (most importantly) where we’re going.

What’s past is prologue

Back in 2018, the vision that would become Session was just a twinkle in our eye. We wanted to build something nobody had built before: a fully decentralised, end-to-end encrypted anonymous messaging platform running on a global network of user-operated nodes.

Simply put, we wanted to create a messenger that put the power back in users’ hands.

So we set out to build it.

Early builds of the app that would become Session were… a little rough around the edges, to say the least. But the bones were there — largely thanks to the  Signal codebase. Forking Signal’s well-established client and encryption protocol gave Session a great starting point. At the time, building on Signal’s foundations gave us exactly what we needed to get a headstart in the crowded and highly competitive messaging space.

Session makes a splash

After a year in early alpha and beta stages, Session made its public debut back in January 2020 — and we were amazed by the response. Obviously, we believed in what we were building, but as download counts skyrocketed and positive (and constructive!) reviews poured in, it became clear you believed in our vision too. It was hugely encouraging that so many people saw the very real need for a fully anonymous, decentralised encrypted messenger.

Invigorated by this deluge of support, and keeping both positive feedback and constructive criticism in mind, we began rethinking our aims for the project. It was clear that Session was fast outgrowing its roots as the little anonymous decentralised Signal fork that could, and users were requesting features that would make Session even more useful and competitive — features like multi-device support, voice and video calling, and more. We wanted to give users the features they needed in order for Session to fit into their lives and their workflows, but as we began adding more and more custom code on top of the Signal codebase, things started to get tricky.

Unexpected interactions, bugs, and other issues arose as we worked to implement these new features and integrate them with Session’s foundation of Signal code. So we began to consider how we could streamline Session, keeping everything that makes the app and platform unique while enabling us to build and integrate powerful new features with ease.

The refactor factor

One important part of this streamlining process was a refactor: restructuring Session’s code to make it more streamlined, without changing or removing any user-facing functionality. As Session has grown, we’ve ended up with messy Session-Signal overlaps and redundant code that introduced stability and reliability issues and made development harder than it needed to be.

Now, as it turned out, this refactor actually turned into a number of refactoring efforts, starting with our refactor of the Service Node communication code all the way back in April, and continuing with our partial refactors of the mobile and desktop clients, and other smaller refactors along the way. These refactors have made Session’s code much leaner, meaner, and easier to work with — particularly in the areas where our code overlapped with Signal’s.

At this point, we’d refactored a large chunk of Session’s client-side code. But there was still one area of the app we hadn’t streamlined.

Encrypt, decrypt, repeat

One of the parts of Session’s original, Signal-forked codebase that consistently introduced the most issues during our efforts to implement new features was the encryption protocol itself. The Signal protocol is the industry standard for a reason. It’s rock-solid, and it gave us guaranteed security while we built out the rest of Session on top. But while the Signal protocol is great for, well, Signal, building on it began to introduce challenges for the Session project. The reality is that while Signal is laser-focused on security, Session’s vision includes a focus on anonymity and decentralisation, too — and trying to shoehorn the Signal protocol into that vision was like forcing a square peg into a round hole. The Signal protocol wasn’t built with decentralisation in mind, for example.

It might be feasible for a huge organization like WhatsApp, backed by Facebook’s practically unlimited development resources, to cram the Signal protocol into their messenger. But it became clear to us that trying to build the crucial new features our users needed on top of the Signal protocol was making Session’s development less like running a race and more like trudging through mud. After spending years cozied up to the Signal codebase, it became clear to us that the best way forward for Session would be using its very own purpose-built protocol.

Introducing: the Session Protocol

We believe Session is the future of decentralised messaging — and to fully realise our vision, Session needs a streamlined, purpose-built protocol.

Today, we’re announcing exactly that: the Session Protocol. The Session Protocol is built from the ground up for anonymity and decentralisation. This new protocol streamlines Session’s design, enabling us to build and implement exciting new features — while ensuring your messages stay secret, safe, and secure.

We’ll be releasing a comprehensive technical writeup shortly that will outline the nuts and bolts around how we’ll be implementing this new protocol. In a nutshell, we’ll be rolling the Session Protocol out in stages to ensure backwards compatibility with older Session clients which still rely on the Signal protocol. More information on that rollout will be available soon.

The Session Protocol lays the groundwork for the future of Session — and we can’t wait to get started.

<![CDATA[Privacy on trial: How encryption bans and backdoors threaten us all]]> 6cDsL8vCVYTCNhpYYMwr3u 2020-12-03T23:00:00.000Z “For competent authorities, access to electronic evidence is not only essential to conduct successful investigations and thereby bring criminals to justice, but also to protect victims and help ensure security.” These words — lifted from a leaked European Council memo — echo the sentiments of legislatures around the world who seek to weaken the privacy of their citizens to supposedly protect them from ‘criminals’.

Similar efforts can be seen worldwide, from the Five Eyes alliance bemoaning the “significant challenges to public safety” caused by end-to-end encryption, to the Brazilian “Fake News Bill” which seeks to mandate traceability in private messaging. The growing antipathy toward digital rights on display in these instances illustrates a misunderstanding of the differences between physical and digital privacy.

All for one and one encryption backdoor for all

Regardless of whether you agree with law enforcement having the ability to gain access to people’s private data, the pertinent issue with all of these endeavours is the impossibility of keeping these powers only in the hands of ‘competent authorities’. To create the possibility of a third party viewing end-to-end encrypted messages defeats the entire point of encryption. If a backdoor is created for law enforcement to view private messages, there is nothing to ensure only law enforcement can use it. Anyone with either know-how or luck could discover these backdoors — and considering how lucrative such a process can be, there will always be malicious parties looking for them.

Too often, authorities justify compromising the privacy of their citizens with the promise of using their newfound power to catch dangerous criminals, but not only is there very little evidence that this is the case, there is a multitude of evidence that authorities will use any powers afforded to them outside the intended scope. The idea of a police officer scanning your personal messages because you got a speeding ticket would be right at home in a pulpy dystopian cyberpunk novel — it’s not something that should ever approach reality.

So, considering the glaring problems with these intrusive measures and the fervour with which they are being pushed by legislatures and regulators all over the world, what can we do about it?

The future is open-source (and decentralised)

There are two crucial features that a private messenger must have to protect users against overzealous governments.

The first: be open-source. The best protection against the creation of a backdoor is for the source code of the application to be publicly available. If it’s possible for every user to scrutinise the make-up of the app and compile it themselves, it becomes almost impossible to hide a malicious piece of code. Of course, it can still be done, which is why it’s still best practice to have a security audit — so any problems missed by the community will be found and rectified. When it comes to privacy, trust is a dirty word. An application having closed-source code means the developers are asking you to trust that there is nothing malicious going on. Open-source lets you see for yourself.

The second may be less obvious, but it is no less vital: decentralisation. The age-old problem with centralised services is that when the government decides they want a backdoor into a private messenger, they don’t ask nicely — they demand. A centralised service would then most likely have two options: comply or be shut down. Here comes that trust word again. A decentralised service has an advantage in this scenario, because there is no operating company to tap on the shoulder and shut down the service. You don’t have to trust a provider to keep their services available to you — even in the face of litigation or intimidation. Instead of one central server or server cluster for message routing, there are hundreds or thousands all around the world, outside the jurisdiction of any single governing body. And even shutting down the developers won’t stop a service that is both decentralised and open-source, as the code will still be available for anyone to compile themselves.

Privacy is not negotiable. There is no such thing as a backdoor that only law enforcement can access — if it exists at all, it exists for everyone. When seeking measures to curb criminal activity, it should be imperative that the rights of every citizen aren’t infringed — it simply isn’t worth it.

<![CDATA[Session Release Roundup #9: Closed groups grow up! Plan a party, message your squad, or nail down that next office meeting]]> 3aFmptdPnnqpKDSWfzZsnY 2020-10-07T22:00:00.000Z After spending some time in the wilderness, closed groups are now living their best lives. To celebrate, closed groups are having a party, and they’re inviting you and up to 20 friends! That’s right, closed groups can now handle a whopping 20 people at once.

On top of that, this update is packing push notification improvements — now fast mode notifications will be…well, fast!

Let’s get into it!

Put on your party hats: Huge improvements to closed groups

Closed group improvements. We’ve put a lot of work into this one, and we know it’s going to be super important to lots of you. With the implementation of our shared sender key system, closed groups will now perform better, be more reliable, and support more people.

  • Increased closed group size (iOS, Android, Desktop)

  • Improvements to closed group performance and reliability (iOS, Android, Desktop)

The push notification haunting is over! This update should cleanse your Session app of all ghost notifications, stop notifications showing up after you’ve already opened a message, and banish all empty notifications.

  • Improved push notification reliability and performance (iOS, Android, Desktop)

  • Push notifications will consistently display message previews if they are enabled (iOS, Android, Desktop)

  • Push notifications will not deliver after a message has been opened (iOS, Android, Desktop)

  • Push notifications will only deliver if a message has been received (iOS, Android, Desktop)

  • Improved background polling reliability (Android, Desktop)

A lot of Android users were running into an issue causing Session to stop dead in its tracks. We’ve resolved this, so you shouldn’t see Session crashing to the home screen any  more.

  • Crash fixed (Android)

In 2020, profile pictures are the purest form of expression, so we’re rolling out some fixes and improvements for profile pictures.

  • Jazzicons removed, replaced with new multi-coloured avatars (iOS, Android, Desktop)

  • Open group profile pictures now display correctly (iOS)

  • Closed group profile pictures display member profiles instead of generic ‘group’ image (Desktop)

Nobody likes getting left on ‘read’. Now you can avoid the awkwardness and turn off read receipts.

  • Added read receipts toggle in in-app settings (iOS)

In open groups, selecting messages lets you reply, copy the message, copy the Session ID, or report a user. All very useful — so we’ve fixed up an issue that was stopping Android users from selecting open group messages properly.

  • Messages in open groups can be selected (Android)

  • Copying a Session ID in an open group now works correctly (Android)

Tapjacking is a known Android hack that can be used to monitor your phone usage. We’re not a fan of snooping, so we’ve implemented some new security features to keep your Session messages protected even if your phone gets tapjacked.

  • Implemented tapjacking protections (Android)

  • Previews are hidden in the app switcher by default (Android)

Whether it’s a blanket hog or a battery hog — hogs are the worst. We’ve made some changes to make sure your phone can last all day and all night while you’re using Session.

  • Reduced background battery usage (Android)

Hooking up all your mates on Session was a bit cumbersome, so we wanted to streamline the process. Now, you can copy your friend’s Session ID straight from the conversation settings, so you can easily share their contact info.

  • Added ‘Copy Session ID’ button to the conversation settings (iOS)

So you’ve sent your friend a funny meme, but don’t want to scroll all the way through your conversation to find it again? Never fear — now you can easily view all your shared images, voice recordings, videos, and file attachments in your conversation settings.

  • Added an ‘All Media’ button to the conversation settings (iOS)

When you received new messages in a conversation you already had open, the new messages were being marked as unread. We’re assuming that if you’ve got the convo open — you’ve read the message. So we’ve fixed this up.

  • Open conversations will now mark new messages as read (Desktop)

I think we’re gonna need a bigger attachment!

There’s a lot on the horizon for Session, but the immediate future holds two big improvements: support for larger file attachments, and more granular path rebuilding. At the moment, Session’s onion requests system makes it hard to send big files. This is because when you send a 2MB file, that file turns into around 10MB of onion requests before arriving safely and anonymously at its destination. We’ll be reworking onion requests to slim down those numbers and streamline onion requests. What this means for you: way bigger file attachments.

In regard to path rebuilding, some of you have noticed that Session is often trying to connect to a very large number of IP addresses — this is because Session is constantly rebuilding its onion-routed path around Session’s decentralised network. In an upcoming update, we’ll be reworking the path rebuild system, so Session clients won’t need to rebuild paths as frequently — resulting in a more reliable and consistent messaging experience.

Thank you!

Session is getting better every day, and we couldn’t do it without you. We’re doing everything we can to push the envelope in the world of encrypted messaging — but operating on the bleeding edge means that your help with experimentation and testing is hugely important to us. Your dedication as Session users and advocates keeps us going! Well, that… and coffee.

See you next time!

The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[Session Release Roundup #8: Light mode arrives — and much, much more]]> 4wY5TQXpGBNYKU545LNXBp 2020-09-03T22:00:00.000Z Hello world! It’s been a while — but the Session team have been busy, busy bees, hammering away on an absolute mountain of fixes, quality-of-life improvements, and, oh, freakin’ light mode!

That’s right, you asked, and we heard you. Light mode is now available! But more on that down below. This round of releases has fixes and improvements to almost every part of the app, on every platform, and we’re super excited to be sharing these updates with you.

Light mode (is just the beginning)

The first thing you’ll notice when you fire up your newly-updated Session client is a bold new look for the UI — light mode is here! Prefer to live life on the dark side? Never fear. Just head into Settings and toggle between modes with the handy switch.

  • Light mode! (iOS, Android, Desktop)

  • Light mode is now the default interface mode. (iOS, Desktop)

  • Interface mode follows system settings for light/dark mode. (Android)

We’re always working on making Session more accessible to our international communities, and this round of releases is no exception. There’s a shiny new Persian localisation for mobile clients, improvements to the iOS Chinese localisation, and betas for a number of new languages on desktop!

  • Improved Chinese (simplified) translation. (iOS, Android)

  • Persian translation. (iOS, Android)

  • Added beta translations for German, French, Italian, Russian, Spanish, Portuguese (Brazil), Chinese (simplified), Spanish and Persian. (Desktop)

  • Added RTL text support. (Desktop)

Session is a great way to send photos securely and privately, but there were a few issues getting in the way. With these changes, enjoy a smoother, more reliable photo-sharing experience.

  • Fixed an issue with small photo captions not showing up. (iOS)

  • Sending photos is now more reliable. (iOS, Android)

  • Saving photos on Android Q should now work again. (Android)

  • Fixed a crash that could occur on inserting an emoji into a photo caption. (Android)

  • Photo captions now show fully. (Android)

Session isn’t just perfect for sharing photos — it’s great for sending other file attachments securely too. Uploading and downloading attachments should now be more reliable and consistent.

  • Attachments sometimes wouldn’t download after receiving a push notification; now they do. (iOS)

  • Attachments without a width and height are now handled. (Android)

  • Attachment uploads should now be more reliable. (Android)

Session’s new light mode has the UI looking better than ever — but there were some more improvements to be made to the interface. These QOL changes will make Session’s UI shinier than ever.

  • Replies now correctly show the display name instead of the Session ID. (iOS)

  • Cleaned up the message that’s shown when you change the disappearing messages timer. (iOS)

  • Various UI improvements. (iOS, Android)

  • Any display name is now allowed. (iOS, Android)

  • Build number now shows in in-app settings. (Android)

  • Added a list of blocked contacts in the Settings panel. (Desktop)

Looking beyond improvements, there were some annoying little bugs that were making Session’s UI a little bit frustrating. This small mountain of UI fixes should make the interface more consistent and reliable.

  • Fixed link previews. (iOS)

  • Fixed a bug that could make a conversation get stuck with an unread message. (iOS)

  • Fixed an issue where profile pictures sometimes wouldn’t display. (iOS)

  • Fixed an issue where if you tapped a notification while in the settings screen, it wouldn’t take you to the conversation screen. (iOS)

  • The muted label now disappears correctly when the mute period expires. (iOS)

  • Mentions now show up correctly in notifications. (iOS, Android)

  • Fixed various minor UI issues. (Android)

  • The app now correctly sends delivery receipts (Android)

  • Made app UI closer to mobile, when possible. (Desktop)

  • Fixed emoji panel overflow. (Desktop)

Open groups are a great way to have big conversations about big ideas — or just catch up with all your friends. With this round of bug fixes for open group messages, profile pictures, and more, open groups will be more reliable than ever.

  • Fixed an issue where messages could show up in duplicate in open groups. (iOS)

  • Fixed open group profile pictures. (iOS)

  • Messages should now be ordered correctly in open groups. (iOS, Android)

  • Fixed open group message deletion. (iOS, Android)

  • Fixed a bug that could cause missing open group messages. (Android)

  • Increased timeout for joining open groups. (Desktop)

Closed group users, never fear — open groups aren’t hogging all the love. We have some big updates for closed groups on Android, including closed group editing and preparation for shared sender keys, which will enable larger and more reliable closed groups in the near future. And for our iOS users, stay tuned for the same improvements making their way over to iOS shortly!

  • When a member of a closed group leaves it now shows their name rather than their ID. (iOS)

  • Closed groups now have a disappearing messages setting. (iOS)

  • You can now edit closed groups. (Android)

  • We prepared the app for shared sender keys, which will allow larger and more performant closed groups. (Android)

Restoring an account with its recovery phrase was a bit wonky on mobile — these changes should make account restoration smoother and more reliable.

  • Fixed various issues related to account restoration. (iOS, Android)

And speaking of reliability, we’ve nailed down and fixed up a number of bugs across the board. The biggest fix was nailing down a particularly nasty bug that was eating up data and battery in the background on Android — hooray! With that, and the rest of these changes and fixes, everything from message sending to app launching should tick over more reliably than ever.

  • The app is now better at handling faulty and unreliable Service Nodes. (iOS, Android)

  • Various crash fixes. (iOS, Android)

  • Disabled multi-device. (iOS, Android)

  • Fixed an issue that could cause excessive data and battery use. (Android)

  • Fixed a crash that could occur on sharing your QR code. (Android)

  • Fixed an expiration timer compatibility issue between iOS and Android. (Android)

  • Updated the app for the latest versions of Android. (Android)

We’ve made some improvements to encrypted sessions on both Android and iOS to fix those ‘bad encrypted message’ errors some of you have been seeing.

  • Session reset now works correctly. (iOS)

  • Session reset now correctly shows you a confirmation when finished. (iOS)

  • The app should now recover from bad encrypted messages. (iOS, Android)

Up next: Bigger, better closed groups

That was a lot. But catch your breath and get ready for more, because the next round of updates will be here before you know it. Over the next few weeks, we’ll be hard at work preparing to activate shared sender keys across all platforms, which will bring larger and more reliable closed groups, as well as quite a few more UI improvements and bug fixes — stay tuned for more on that soon.

Thank you!

As always, it’s feedback, comments, and suggestions from users like you that keep us working on the issues that need fixing and the improvements our community wants to see. Keep the feedback coming, and we’ll keep working hard to build the best version of Session yet. Thank you for all your feedback and support!

The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[Session Release Roundup #7: Translations, notifications, and more!]]> 1fcOejTAJ33VY9INfENcN4 2020-08-02T22:00:00.000Z With the last of the big code refactors out of the way, you might think it was time for us to take a moment to rest on our laurels and catch our breath, but…

Hell no it ain’t. That’s not how the Session team rolls.

In this round of releases, we’re making some sweeping changes to improve the user experience — most notably, taking multi-device back into the shop for some love and attention (more on that below). We’re also implementing some new language localisations, making some big improvements to message notifications, and ironing out the onboarding experience on mobile — and that’s just the start.

Read on for a rundown of all the latest and greatest changes in today’s releases of Session!

What’s new, doc?

Session’s multi-device implementation introduced a large number of bugs which have had some pretty bad impacts on user experience. We’ve decided to temporarily remove multi-device linking and sync support to resolve these issues. This release disables new device linking, and existing secondary clients will be erased later this week. But never fear, multi-device will return in future! Note: For more information on the removal of multi-device, check out our article.

  • Disabled multi-device linking in preparation for temporary removal of multi-device (iOS, Android, Desktop)

Even though multi-device is temporarily being taken back into the shop for some work, we want to make sure it’s running as smoothly as possible before then. Blocked contact lists weren’t syncing properly between mobile and desktop clients — this should fix that right up.

  • Fixed blocked contact syncing (Desktop)

Onion routing is Session’s special security sauce, and now we’ve slathered that onion-routing goodness on file uploads and open group traffic across all three platforms.

  • File uploads and open groups are now fully onion routed (iOS, Android, Desktop)

Sending onion-routed file attachments is one of Session’s killer features — but there were a couple kinks in the attachment-sharing experience on Android and Desktop. Photos should now download more reliably on Android, and photo captions will now show up properly on Desktop.

  • Fixed an issue that could prevent photos from downloading (Android)

  • Fixed attachment caption display (Desktop)

Session has growing communities of international users, and we’re hard at work adding more languages to make Session more accessible. In this update, we’re bringing Chinese (simplified), Brazilian Portuguese, and Italian translations to iOS and Android, along with some improvements to our existing French translation.

  • Chinese (simplified), Portuguese (Brazil), and Italian translations (iOS, Android)

  • Improved French translation (iOS, Android)

Session’s onboarding experience for new users was a little overwhelming — so we slimmed it down and made it a little more cuddly.

  • Simplified the onboarding process for new users (iOS, Android)

We also ironed out a bunch of tiny interface niggles that have been bugging us and our users for a while now. Thanks to all our users who pointed out these minor improvements that’ll make a major difference for Session’s usability!

  • Various minor UI improvements (iOS, Android)

It’s pretty tricky to nail message notifications while preserving your privacy — but these changes will significantly improve the notification experience on iOS and Desktop.

  • Fixed a common crash that could occur after tapping a push notification (iOS)

  • Fixed an issue that could prevent push notifications from appearing (iOS)

  • When you tap a push notification to open the app, all your messages are now visible right away (iOS)

  • Fixed message TTL for push notification server (Desktop)

Desktop users were running into some issues deleting messages in open groups, but that should be much more reliable now.

  • Fixed open group message deletion (Desktop)

There were a few miscellaneous issues popping up here and there on Desktop — but after a little game of Whack-a-Bug, we’ve got them fixed up.

  • Various other bug fixes (Desktop)

And speaking of Whack-a-Bug, we’ve made some improvements to error logging on Desktop to help us nail down bugs faster and more efficiently, so you can look forward to rapid-fire bug fixes in future.

  • Improved error logging (Desktop)

Up next: Whack-a-Bug, shared sender keys, and more

We’ll be pushing out another few cross-platform updates over the next couple weeks, aiming to iron out some of the remaining wrinkles and bugs. We’re also planning to enable shared sender keys across all platforms as soon as we have the Android implementation finished up, so you can look forward to increased closed group sizes on every platform in the near future!

Looking further into the crystal ball, after the next few rounds of bug fixes we’ll be embarking on a major UX overhaul across all three platforms — after laying the groundwork with the recent refactors, we’re almost ready to start reaping the benefits by making some significant improvements to Session’s user experience. We’ve got some exciting concepts in the works, and we can’t wait to share them with you.

Thank you!

Many of the bug fixes and improvements in this round of releases wouldn’t have been possible without the valuable feedback and input from you — Session’s users. It’s comments and suggestions from users like you that help us build the app you want to use, so keep the feedback coming, and we’ll keep hammering away to make Session the best private messenger we can. As always, thank you for your feedback and your support!

The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[The future of Session’s multi-device support]]> 7eJVvjRzgF4Mpn7eEJ6T5c 2020-08-02T22:00:00.000Z Multi-device support is important for any messenger that wants to compete in the hotly contested private messaging space, and we’ve been hard at work implementing and improving Session’s multi-device support since launch. In its current implementation, multi-device theoretically allows for two devices to be linked, and for conversations and message histories to be securely synced between those devices.

However, in practice, Session’s multi-device implementation has introduced a large number of bugs which have negatively impacted user experience. In order to resolve these issues, we have decided to temporarily remove multi-device linking and sync support.

This removal will occur in two stages:

Today, we will release a Session client update for all platforms which will disable the device linking interface. No new devices will be able to be linked, and users with existing multi-device configurations will see a warning informing them about the upcoming second stage.

Later this week (we’re targeting the 6th of August in AEST), all secondary clients in existing multi-device configurations will be erased. Primary clients (clients on which a Session ID was first created) will be unaffected and will still be able to be used normally.

Although removing multi-device might sound like a step backwards, it will allow us to make significant improvements to Session’s user experience. These improvements include:

  • Reducing message send times by approximately 2 seconds (due to not needing to poll for device links)

  • Better closed group scaling

  • Reduction in message sending errors (these errors are often caused by issues related to multi-device)

  • Significant reduction in complexity of development and testing, which will let us get new features out the door faster

  • Letting us give multi-device some serious love and attention to make sure it can live up to the standards we’ve set for Session’s user experience

Will multi-device be coming back?

Yes. Make no mistake, multi-device is absolutely a feature we want to support. However, we will need to reassess how to implement it without compromising on stability, reliability, or other aspects of the user experience.

Over the next two months, the Session team will spend most of our time working on UX improvements. After that work is finished up, we’ll be taking another swing at multi-device. Whichever implementation we decide on, we will test it extensively before re-adding it, to ensure we can deliver a secure, private multi-device experience with no compromises.

<![CDATA[Session Release Roundup #6: The moment you’ve all been waiting for… Desktop overhaul!]]> ah3XqUEszwrIdkTZu2XKl 2020-07-16T22:00:00.000Z How many refactors does it take to overhaul the entire Session code base? Well, 3 — one for iOS, one for Android… and now, one for Desktop. That’s right — the Desktop client refactor is DONE! You can download it right now! Although this might seem like ‘just another refactor’, it will actually bring huge reliability benefits on all platforms, as well as making it much easier for us to forge ahead with new features and fixes.

Refactor aside, Session is becoming quite the polyglot — we’ve brought French, German, and Russian language versions to Android. New language versions are coming in hard and fast at the moment, and as per usual, we’d love to hear your thoughts on how to make these translations as amazing as possible!

Now let’s get to the good bit — the update list.

Completing the trilogy: Desktop refactor

Closed groups are a core part of Session — but if you’ve invited any Desktop users to your closed groups lately, you might have noticed messages weren’t being delivered to everyone successfully. This really defeats the whole point of having a group chat, but the Desktop refactor will mean everyone in your closed group gets the memo.

  • Protocol-level overhaul and refactor. Desktop

  • Fixed a session handling bug that could occur in closed groups. iOS, Android

Even if you’ve been using the freshly-refactored iOS and Android versions of Session, you still might’ve been left wondering why messages still weren’t delivering consistently. Well, Desktop still had a lot of problems sending and receiving messages, but (once again) the Desktop refactor should clear those issues up for EVERYONE!

  • Protocol level overhaul and refactor. Desktop

For most folks out there, multi-device means linking your computer and your phone. Although Android and iOS have already gotten a lot of device linking updates, Desktop was still waiting for its round of multi-device fixes. Now that the Desktop refactor is out in the wild, multi-device should be a lot more reliable across the board.

  • Protocol level overhaul and refactor. Desktop

  • Fixed an issue that prevented devices linking. Android

If you’ve ever regretted adding someone on Session, you probably noticed there isn’t an easy way to block someone. Friend requests acted as a bit of a filter, but after accepting the request — you could be left open  to spam or harassment. That’s why we’ve decided to replace the friend request system with contact blocking functionality.

  • Added ability to block other users. Desktop, Android

  • Removed friend requests. Desktop, Android

Hallo! Bonjour! Privet! We’ve added three new language versions for Session — German, French, and Russian.

  • Translated the app into German, French and Russian. Android

Some users were reporting lots and lots and lots of notifications flying in as soon as they launched the app. With this update, Session should keep its cool — it’ll only send you notifications when you actually have a new message.

  • Prevent repeated notifications after user is offline for extended period. Android

There was one other notification bug causing a couple of different issues on Android. Firstly, it meant Android users with background polling notifications were… never getting notifications. Ever. And people using Firebase notifications were experiencing very fast battery drain. Worst of both worlds! We’ve squashed this bug now, so these notification issues should be fixed on Android.

  • Fixed high battery usage when using Firebase notifications. Android

  • Users will now receive notifications when using background polling. Android

We’ve rolled out a few fixes for in-chat mentions lately, and we’re pretty happy with the way they’re functioning. However, iOS mentions were working differently to Android and Desktop, which could be confusing to people using Session across multiple platforms. With that in mind, we’ve changed iOS mentions — they’ll now behave the same way as other platforms.

  • Modified mentions behaviour to bring it in line with other platforms. iOS

Refactor: Complete. Development: Steaming ahead.

Session’s freshly refactored codebases on all three platforms have laid the foundation for a whole new world of future improvements. These refactors bring bug fixes, reliability improvements, and performance improvements straight away — but the real benefits are yet to be realised.

Another change we’ve decided to make to expedite development is to bench friend requests. Don’t worry — friend requests aren’t gone forever, they’ll likely return as an optional feature in the future. But in their current implementation, friend requests were introducing more issues than they solved. In this Desktop update, a new contact blocking feature replaced friend requests, and we’ll be making that same change on iOS and Android soon.

We’ve got some more language versions coming up soon, including Persian! This one is a little different to all of our other language translations, because Persian is written from right-to-left, whereas all the other languages we’ve added to Session so far are written left-to-right. This means some extra work will be required to get Persian purring along, but once that’s done, it’ll pave the way for adding other RTL languages in future. As always, if you want to see Session translated into your language, be sure to let us know on one of our social channels!

We’re also still hammering away at shared sender keys for closed groups. Shared sender keys will drastically improve closed groups in several ways, including performance upgrades and a higher cap on closed group member numbers.

Thank you!

Getting the code refactors done for iOS, Android, and Desktop has been a monumental task. We’ve been working on it for weeks and weeks now, and we couldn’t have done it without the ongoing feedback and support from the community. Making a kickass messenger without analytics is a tough job — and without your help, bug fixes, UI upgrades, and performance improvements would be a lot harder to come by.

We’re listening carefully to all of the problems you’re having and all of the features you want to see in Session. Now that the refactors are done, we can shift focus to implementing the new features and fixes you’ve all been waiting for.

Catch you on the flip side!

The Session team

<![CDATA[Session Release Roundup #5: Staying mobile]]> 7dYCc5YxKNq3l3x1IqGjHd 2020-06-25T22:00:00.000Z Aaaaand we’re back! No, it’s not the Desktop refactor — that’s still on its way. But here’s something to whet your appetite in the meantime — we’ve got brand new updates for iOS and Android rolling out this week!

These updates aren’t anywhere near as big as the iOS and Android refactors from the last few weeks, but they should help tie up a few loose ends.

Let’s take a look at the goodies in store for you this week!

Mission launch: Rocket powered performance

That Desktop refactor IS coming. Mobile’s already had its time in the sun, but we had to make a few extra changes to make sure mobile clients will be compatible with the Desktop refactor.

  • Protocol changes to ensure compatibility with upcoming Desktop refactor (Android, iOS)

The most basic thing you can do on Session is send a message, but some iPhone users were encountering a bug which stopped you from being able to do that. It turns out there was an encryption problem — and if Session can’t encrypt a message, it doesn’t send the message. It should be all cleared up now — message away!

  • Fixed an encryption issue that could prevent some messages from being sent (iOS)

Another issue that was stopping some of you from sending messages: the clock on your device desyncing from the Service Node network. Session will now let you know when the clocks are out of whack, so that they can be resynced and you can keep messaging.

  • Session now notifies you when this your device clock is out of sync with the Service Node network (Android, iOS)

Some people were running into a problem where their messages got stuck on ‘encrypting message’. Well, it turns out Session was encrypting a message that whole time, it’s just that the proof of work it was trying to complete was very difficult. This is a known Service Node bug, so Session will now ignore Service Nodes asking for insanely difficult PoW calculations.

  • Session now guards against Service Nodes specifying an unreasonably high proof of work requirement (iOS)

Open groups help build community spirit on Session, but they’ve been running into some problems. Some people weren’t able to join open groups at all! All of these issues should be resolved now— open groups are now, well, open!

  • Improved reliability of joining whitelist-based open groups (Android, iOS)

  • Fixed open group messaging from a linked device (iOS)

  • Open group names and logos now update correctly (iOS)

  • Fixed an issue where some messages were missing after leaving and rejoining an open group (iOS)

In-line replies in closed groups weren’t working consistently, so it was hard to get someone’s attention in the middle of a big conversation. Thankfully this should be all fixed now — just long-press on a message to reply to it.

  • Fixed replying in closed groups (Android)

The last thing you want is someone you don’t know crashing your party. Unknown contacts kept showing up when creating closed groups, so it was possible to accidentally add random people to your conversations. With this update, the closed group creation screen will only list contacts you’ve actually added.

  • Unknown contacts no longer show up when creating a closed group (iOS)

Profile pics weren’t showing up for some people in closed groups, making it a bit difficult to keep track of who was saying what — that should be cleared up now.

  • When someone messages you in a closed group, you will now correctly see their profile picture (iOS)

Profile pictures let you show off a little bit of style on Session, but they weren’t syncing  up on secondary devices for multi-device users. Profile pictures should now sync up for both devices linked to your Session ID!

  • Your profile picture should now sync correctly when linking a device (Android, iOS)

If you’ve ever tried to send a selfie on Session, you might have noticed the photo looked a bit blurry. The camera within Session wasn’t performing as intended, but now you can send crystal-clear pictures using the in-app camera.

  • Improved quality of photos taken using the in-app camera (iOS)

We like Session to look pretty, so we’ve made a few changes to clean up the look and feel of Session

  • All mentions are now styled the same (Android, iOS)

  • Minor UI improvements (Android, iOS)

Session can’t just look the part — it needs to have the performance under the hood to match its good looks. These changes should result in a very noticeable performance upgrade for iPhone users!

  • Overhauled database handling (iOS)

  • Improved use of multithreading (iOS)

There have been a LOT of fixes to help smooth out the process of linking a device. But what if you want to unlink a device? Some people had problems with zombie secondary devices coming back over and over again. This fix should double-tap those zombie devices and make sure they’re removed. Permanently.

  • Devices don’t return after being unlinked (iOS)

We bang on about Session being open source — and it really is important. But up until now, it’s been relatively difficult for the average person to compile Session’s iPhone app from source. We’ve made it a lot easier, so you can compile the code for yourself for your own peace of mind (if you want, at least).

  • Building the app from source is now considerably easier (iOS)

Sometimes Session screeches to a sudden halt. App crashes are really frustrating for everyone, but thankfully you should be seeing less of them with this latest update.

  • Several crash fixes (Android, iOS)

  • Fixed a crash that could happen after opening a notification (iOS)

  • Fixed crash which occurred when searching group chats (iOS)

(Almost) ready to launch: Desktop refactor

Yes, the Desktop refactor is coming soon! We’ve been hammering away at it for a while now, and it should be ready for you in the next few weeks. The arrival of the Desktop refactor should have a flow-on effect which improves messaging performance for all users — even those of you who aren’t using Desktop at all.

The refactor will involve a bunch of performance improvements, bug fixes, and should make linking Desktop clients more reliable.

We’re also still working on shared sender keys, which will be a huge upgrade for closed groups. Once shared sender keys roll out, closed groups will be much faster, and they’ll be able to have way more members!

Thank you!

As per usual, the biggest props go to you — Session’s users. We’re putting in all these hours because we want to do our bit to protect your online privacy, but don’t underestimate how much of a role you’re playing too — by using and supporting projects like Session. Those of you reading these update notes, sending feedback via social media and email, and using Session every day are the people who make all of this possible.

See you next time!

The Session team

Still have questions?

We’re happy to help with any questions you might have. Check out more information on our helpful features at the link below or reach out to us at

<![CDATA[Session for beginners: Your Session starts here]]> 2SvhVX24miiuWp5vp8kKos 2020-06-18T22:00:00.000Z There have been a lot of reasons for people to suddenly take an interest in private messengers recently. Previously, encrypted messengers were mostly used by tech aficionados — and it shows in the way these apps are designed. But now private messengers are becoming more and more popular. Let’s go through some of the basics of the encrypted messenger Session.

Session allows you to send encrypted text messages, images, and file attachments — like voice messages or PDFs. Session uses the internet to send your messages, so you’ll need internet connectivity (via Wi-Fi, Ethernet, cellular etc.) to be able to send messages.

Session has several major advantages over other encrypted messengers:

Session is end-to-end encrypted. This means nobody but you and the people you’re talking to can read the contents of your messages.

Session doesn’t require a phone number. This means the messages you send can’t be tied to your real identity.

Session is decentralised. This helps protect your messages from being exposed to hackers or authorities.

Session is open-source and not-for-profit. This means Session’s code is public and free to be inspected by anyone, giving you confidence that Session is doing what it claims, and isn’t trying to collect, share, or sell your information.

Getting started

You can download Session for iOS on the App Store, or from the Google Play Store if you’re using Android. You can also download Session from our GitHub or the Session website if you want to avoid using the Google Play Store.

When you first launch the app, you’ll see this screen:

type: embedded-entry-inline id: 67LG10n3aG3hIcDPcNnkVSIf you’ve never used Session before, tap to create an account.

type: embedded-entry-inline id: 1bQbfMtrkLz8WYgWYjWJCmIf you already had a Session ID, you can tap here to start using it again.

This is your Session ID — it’s the contact number you give to people so they can message you on Session. Think of it like an anonymous phone number.

You can copy it now if you need, but you can always find it by going to your app settings. Tap Continue to progress through your account creation.

This is how your name will appear to your friends on Session. You cannot add people using a display name — they’re for appearances only.

There are two options for handling notifications on iOS and Android.

The top option — Fast Mode — provides more reliable push notifications, but is considered less private. This is because your IP is exposed to Apple or Google (respectively) if you choose this option. If other apps are using push notifications on your device, these services are likely already being used, so it’s quite likely safe to select.

The bottom option — Slow Mode — provides less reliable push notifications, but offers some additional privacy as it doesn’t rely on Apple or Google’s push notification service.

Note: If you’re on an Android device without Google Play Services, Fast Mode will not function. You’ll need to select Slow Mode.

You can change this setting at any time in your app settings.

Almost done! You can now add friends and start messaging on Session. But let’s take a look at this first:

Tapping ‘Continue’ takes you to this screen:

Here you can find your recovery phrase. You should copy this phrase and store it securely, such as a password protected file, or by physically writing it down and keeping it in a safe place.

This phrase can be used to recover your Session ID if your device is lost or destroyed, or if you need to re-install Session. To use your recovery phrase, select this button type: embedded-entry-inline id: 1bQbfMtrkLz8WYgWYjWJCm when you launch Session for the first time on a new device or new installation.

If you tap ‘Continue your Session’ at the launch screen, you’ll see this screen:

You can restore your existing Session ID by entering your recovery phrase into the text box. If you have already given your Session ID to friends, published it on your website, or listed it on your social media, people will then be able to continue messaging you using that Session ID.

Note: This does not restore any of your old contacts or messages. For the sake of your privacy, Session only stores this information locally, so once it is deleted, it is gone forever and cannot be recovered by anyone.

Adding friends and sending messages

Now that you’ve got your account set up, it’s time to start messaging people. The simplest way to use Session is to start a one-on-one chat.

Tap and hold on the type: embedded-entry-inline id: jK8AA968OlK13EnmsJkm7 icon, and you should see these three options pop up.

type: embedded-entry-inline id: 1jSwkvayJHgX9tJIOSpYRA will allow you to start a chat with one other person.

type: embedded-entry-inline id: mIzXK6GiWsfznONhaavcj will allow you to start a ‘closed group’ — an end-to-end encrypted group chat.

type: embedded-entry-inline id: 26rxYX0gzd94WQD1dwKODz will allow you to join an ‘open group’ — a very large group chat which is not end-to-end encrypted.

If you choose to start a one-on-one chat you will be greeted by this screen:

By starting a session with another user, you are also sending them a friend request.

There are two ways to get started:

You can type or paste your contact’s Session ID into the text box.

You can scan their unique QR code. This is easiest if you are physically with your contact — they can display their QR code by navigating to their app settings and clicking the type: embedded-entry-inline id: 6uRE7viwORneNC2W2qBqb9 icon in the top right-hand corner.

Once they are displaying their QR code, swipe right to scan a QR code, and hold your phone’s camera in front of the QR code until it is recognised by the app.

Next, type and send a message to your new contact. They will receive your message as a friend request. You won’t be able to send any additional messages until they accept your friend request, but once they have accepted, you’re free to message like you would normally.

Now, let’s take a look at ways to message more than one person once — groups.

Closed groups

Closed groups are end-to-end encrypted group chats. They have a limited number of members (currently 100), because encrypting a chat with too many people would cause performance problems.

To start a closed group, tap the type: embedded-entry-inline id: mIzXK6GiWsfznONhaavcj icon. You will then be able to select the group members and group name, tap ‘Done’ to create your closed group.  Note that you can only add people you are already friends with to a closed group.

Open groups

Open groups are group chats with lower security which can contain a very large number of members. Open groups are intended for large online communities, and don’t have the same security and privacy features of sessions and closed groups.

You cannot create an open group within the Session app. Creating open groups is somewhat technical, but we do have a guide available here

To join an open group, tap the type: embedded-entry-inline id: 26rxYX0gzd94WQD1dwKODz icon, and insert the URL for the open group.

Additional security settings

Additional security settings can be found in Session Settings > Privacy.

Typing indicators — If this setting is enabled, you will see and share typing indicators — like this: type: embedded-entry-inline id: 7fzn89VNZEAtbm1yIXN6Jp —  in all of your chats. If you don’t want people to be able to see when you are typing a message, disable this setting.

Screen lock — This provides an extra layer of security. Enabling this setting means Session will require a passcode, Touch ID, or Face ID verification to unlock, even if your phone is already unlocked. This way, if somebody gains control of your unlocked device, they will still not be able to access Session.

Disable preview in app switcher — This will make it so that your Session messages can’t be seen from your phone’s app switching screen. If this setting is enabled, there is no risk someone will accidentally see your Session messages when you’re not directly using the app.

Send link previews — Enabling this setting will mean that link previews will be sent for supported websites. Link previews sometimes carry the risk of leaking metadata, although Session handles link previews in a way which reduces this risk.

What to do if you encounter bugs or other issues

If you’ve run into bugs or issues using Session, please contact us via email at above or the open group — the team would love to hear your thoughts about Session!

You can also contact us via Twitter or Facebook

It may also be worth reading the Session FAQ.

You’re good to go!

You’re all set to start messaging with Session while maintaining your privacy and security. But remember, no application is completely foolproof. Session is just the how of secure messaging. The who matters as well — be careful not to share any sensitive information with people you don’t know or who may not act in your best interest.

If you would like to know more about Session, we’d love to hear from you! There are lots of ways to get in touch with us. Once again, feel free to reach out via email

<![CDATA[Android trackers and permissions: Did I say you could do that?]]> 6Fay1wFap01jTJhdpou0X5 2020-06-14T22:00:00.000Z As netizens have become more and more tech-literate over the years, lots of people have developed their own list of ‘scam app’ red flags to look out for. This might be things as simple as poor reviews, poorly written app descriptions, or things just looking plain dodgy. Most people have been around the internet rodeo for a while, and they can smell spyware from a million miles away.

But when you’re not quite sure — when some things seem right and other things don’t — you need cold hard facts to help you out. For a lot of people, the permissions required by an app is one of the first things to check out.

You shall not…have permission!

Permissions are a big deal in the mobile world, they can give apps the right to access your Android phone’s hardware (like the camera) or personal information (like your geographical location). And apps aren’t like kindergarteners asking their teacher if they can go to the bathroom — a lot of the time, apps are given permissions without explicitly asking.

More serious permissions (like location data) will normally require you to give it the manual tick-of-approval, but if the app is asking for permissions that aren’t directly explained by its functionality, your scam senses should be tingling.

Remember, the size of the permissions list doesn’t necessarily matter: some apps might require a lot of permissions, but there might be legitimate reasons they’re asking for them.

Let’s take a look at some of the best private messengers in the world, and see what kinds of permissions they’re asking for on Android  — and why.

Signal has one of the cleanest records going when it comes to security. It’s trusted by tech-heads all around the world, including people like Edward Snowden and Twitter’s Jack Dorsey.

Signal, Telegram, and WhatsApp — the three most popular encrypted messaging apps — require the most permissions. And Signal requires the most permissions of any of these apps — what’s up with that?

Well, it’s not ideal, but it’s probably not as big of a deal as it seems.

A lot of the permissions Signal asks for make sense, like the ability to send SMS messages — because Signal can be used to send an SMS.

Most of these apps — including Signal, Telegram, and WhatsApp — request the ability to view your contacts, probably so that they can check which numbers in your phone’s contacts list are also registered on their app, and suggest you message them. Let’s be honest, that’s really not ideal from a privacy perspective — but at least it’s easy to explain why the permission is needed.

But what about Session? We know all the inner workings of Session, so let’s take a deeper dive into some of the permissions used by Session and why they’re required.

Session permissions on Android: What and why

ACCESS_NETWORK_STATE This allows Session to check whether your device has a valid internet connection, which is required for basic message sending functionality.

ACCESS_SESSION_SECRETS  This allows Session to cache information about your encryption sessions for improved performance.

BROADCAST_STICKY Allows Session to display sticky notifications — notifications that don’t go away after they’ve been seen.

CAMERA Session requires this in order to let you take and send photos in your messages.

DISABLE_KEYGUARD This permission is required in order to enable Session’s PIN lock feature.

FOREGROUND_SERVICE Allows Session to use ‘Service.startForeground’.

INSTALL_SHORTCUT This allows you to add Session shortcuts to your launcher.

INTERNET Allows Session to open network sockets.

MODIFY_AUDIO_SETTINGS This is required in order to set your Session notification sound from within the app.

RAISED_THREAD_PRIORITY This is required to enable certain features that require high processing priority, such as real-time audio playback.

READ_EXTERNAL_STORAGE This is required in order for you to access pictures and files from within Session.

RECEIVE Session uses this to receive notifications from Google Firebase if you have opted in to Google Firebase notifications.

RECEIVE_BOOT_COMPLETED Allows Session to receive the ‘Intent.ACTION_BOOT_COMPLETED’ message which is broadcast once your device has finished the boot process.

RECORD_AUDIO Session uses this for recording and sending voice messages.

REQUEST_IGNORE_BATTERY_OPTIMIZATIONS This permission is used on devices without Play Services installed; Session will prompt the user to disable battery optimizations so the app can poll for notifications in the background.

VIBRATE This allows Session to provide haptic feedback using the device’s vibrator motor.

WAKE_LOCK Allows using PowerManager WakeLocks to keep the processor from sleeping or the screen from dimming when you’re using Session.

WRITE_EXTERNAL_STORAGE This allows Session to save photos and other attachments to your device.

READ_SETTINGS, WRITE_SETTINGS Allows Session to read or write the system settings, such as your notification sound for Session messages.

READ_SYNC_SETTINGS, WRITE_SYNC_SETTINGS Allows Session applications to communicate with devices which use Android sync, such as wearables and Android Auto.

These aren’t the trackers you’re looking for

We’re not gonna beat around the bush with this one — trackers are bad news for your privacy, and really you should be looking for apps using zero trackers.

Generally, trackers indicate developers are using some kind of analytics service to see the way you use the app or your device. This isn’t harmless information, and with things like fingerprinting, this could potentially lead to you being profiled or identified by the developer or the analytics services they’re using.

Google is the king of analytics. You’ll see either Google Analytics or Google Firebase Analytics used in Telegram, WhatsApp, Riot, and Wickr — it provides information about 500 unique actions you might perform when you’re using the app. Of course, this information can prove invaluable for developers — but it’s important to make sure it’s always opt-in.

App versions analysed: Status v1.3.0, Wickr v5.54.7, Wire v3.49.921, Session v1.2.3, Riot v0.9.12, Telegram v6.2.0, WhatsApp v2.20.189, Signal v4.63.2

Riot also uses Matomo, which is an open-source alternative. That’s a good step up from giving all your information to Google, but really, we’d rather see Riot find a way to get by without the use of trackers.

Session, Status, Wire, and Signal come up trumps here with no trackers in sight.

Do your own research

Like we said, it’s not really about the amount of permissions required, so much as it’s about what permissions are required. Have a look at some of your own most-used apps and make the call for yourself.

You can use tools like Exodus Privacy to audit your own applications and weigh up the pros and cons of whether it’s worth using for you. As per usual, it all depends on your threat model: something that’s a deal breaker for Alice might be perfectly fine for Bob.

<![CDATA[Cost of admission: What info do you give away when signing up for a new private messenger?]]> 5Ce5IGR40DP8A8e9bmEMs7 2020-06-10T22:00:00.000Z Signing up is a critical moment whenever you start using a new service, and sometimes it can feel like signing a deal with the devil — how much are you sacrificing to start sending messages securely? And when you’re making an account on a (supposedly) private messenger, it can feel like this is all defeating the point.

Account systems, especially in messengers, are important. Usually, your account is also your messaging address — it’s how your friends can find and contact you.

On that note, let’s take a look at what it takes to sign up for some of the most popular private messengers: what information you give up when you sign up, and what that means for you.

Private messengers that need a phone number: type: embedded-entry-inline id: zbUsP47sdg1ChL9juZD7y, type: embedded-entry-inline id: 7JUPvNcjdTuhIObBKWdOtL, and type: embedded-entry-inline id: 4l4qcNHa8JMG3wyjAueado

Signal, WhatsApp, and Telegram all require an active phone number to create an account. We’ve covered the pitfalls of phone numbers again and again — they contain a treasure trove of information about you, so exposing your phone number is really bad news for both your privacy and anonymity. Ideally these services are handling your phone number with care, not just sharing them with anyone who asks nicely, although WhatsApp has landed in some hot water for leaking user phone numbers

In the case of Signal, your phone number is encrypted — although phone numbers are still the primary way to look up a new contact, so your phone number will often be exposed to the people you’re talking to.

Telegram gives you the option to hide your phone number from other users and use a pseudonym instead. This is an improvement, because it means you don’t have to expose your phone number to everyone you want to message.

Signal hasn’t implemented a system like this just yet, so users are stuck using phone numbers to make contact with people. Signal does let you set a profile, including a pseudonym and profile picture, but the people you’re messaging can still see your phone number, which is a thumbs down for privacy.

But Signal still shines when it comes to security, it allows you to use a PIN to lock the registration of your phone number. Like we said before, the list of issues with phone number security is quite long, but at least the PIN feature helps protect your Signal account from SIM swapping and phone number recycling. Your PIN means an extra level of verification is required when connecting a new device to a Signal account. Now, your phone number being compromised doesn’t necessarily mean your Signal account will be too.

This is a good additional security measure. However, the fundamental issue remains — you still have to expose your precious digits at sign-up, and that introduces risk for anyone looking to use Signal, Telegram, or WhatsApp.

Private messengers that don’t need your info: type: embedded-entry-inline id: 4OprmIs55xfiR3Pz04o4TZ, type: embedded-entry-inline id: 2iNZNPZ3kJGWsSamZ4MYWd, type: embedded-entry-inline id: 3oX5Z6aPFDkEFwWUb0bHom, and type: embedded-entry-inline id: 1kz8lqD93Q0Gvhpm5b8ozk

When we forked Signal to build Session, one of the major things we set out to do was anonymise the account system.

You don’t need to give up any information when you create a Session ID — you’re just creating a private-public key pair. You do choose a pseudonym which will be displayed when you send someone a friend request — but this nickname has nothing in common with your real identity (unless you want it to, of course). And soon you’ll also be able to anonymously assign a unique name to your Session ID using the Loki Name System.

The Swiss messenger Threema also uses a private-public key pair to create your account.

Wickr and Riot let you sign up using a pseudonymous username — no email or phone number required. They do, however, give you the option to link your phone number (or your email, in the case of Riot), if you want to make it easier for friends (and other interested parties) to find you.

No matter what you’re signing up for, it’s important to keep in mind what information is being asked of you. Sometimes it’s your name, maybe your date of birth, your postcode, your phone number, email, the first street you lived on, your childhood best friend, or your mother’s hairdresser’s second cousin’s first dog’s middle name.

It might seem like this information is harmless, or perhaps even necessary. But always make sure to ask yourself: is it?

Depending on your threat model, giving away your phone number might be OK. But those ten digits contain a lot of information, so you should consider very carefully whether the weaknesses of phone numbers might punch a gigantic hole in your security.

<![CDATA[Session Release Roundup #4: Spreading the love]]> 752ySkrEzBig4TPpEXw04s 2020-06-04T22:00:00.000Z Three-hop onion requests improve anonymity on Desktop, Android, and iOS

You get an update! You get an update! Everybody gets an update! Session isn’t playing favourites this week, every platform is getting an update — iOS, Android, and Desktop.

Seeing as we live in the land of kangaroos, one-hop onion requests simply weren’t enough — onion requests have now been upgraded to three hops on all platforms.

Mobile users might notice a mysterious glowing dot in the corner of their Session app — try tapping on it to find the brand new onion requests display. There, you can see the path your messages take all around the world.

This update is also packing lots of new bug fixes and user interface changes that should help make sure Session sparks joy.

Let’s get right into it!

Big hops: What’s in the latest update

¿Hablas español? Use an Android phone? Both? You asked for it, you got it. Session now has a Spanish-language version. This is our first foray into translating Session, so we’re only rolling out on Android for now — we’re looking forward to hearing your feedback!

  • Spanish-language support added (Android)

A hop, skip, and a jump! Three-hop onion requests have finally arrived! This is a really big deal — Session now provides more anonymity than ever before. For that reason, this one is rolling out on all platforms at the same time.

  • Three-hop onion requests enabled (iOS, Android, Desktop)

Three-hop onion requests are a pretty big deal, so we thought we’d show you what we’re talking about. Tap the green dot in the corner of your conversation screen on Android or iOS to find our newest feature — a way to display the path your messages take through the Service Node network.

  • You can now see the Service Nodes used by your app for onion requests (and what countries they’re in) (iOS, Android)

iOS devices were going a bit overboard with push notifications Obviously one notification per message is plenty, this fix should get us to that 1:1 ratio we’ve been after.

  • No more duplicate push notifications (iOS)

Group chats had some problems that made it hard to know who was in on the conversation — members counts for open groups got stuck, and profile pictures weren’t displaying correctly in closed groups. We’ve patched groups up so that you’ll always know who’s in the room.

  • Open groups show the actual number of members now (iOS, Android)

  • Fixed profile pictures in closed groups (iOS, Android)

Some users were experiencing a bug that stopped them from accessing the bottom of their conversation list, but with this change, you should be able to get in touch with those long lost friends.

  • The bottom of your conversation list is now always reachable (iOS)

Sometimes it’s a bit cumbersome trying to share your friend’s Session ID with someone else. Loki Name System will help with this — you can add contacts via a nickname. But in the meantime, we’ve made it possible to copy your contact’s Session ID from your conversation settings.

  • Made the Session ID in conversation settings copyable (iOS)

We updated the conversation button on mobile a little while ago, but it never quite worked properly on Android. You should now be able to either long-press or tap on the new conversation button!

  • Improved responsiveness of new conversation button (Android)

Android and iOS recently got some big fixes for friend requests and multi-device, but Desktop is still to come. Desktop will be getting some major lovin’ over the next few weeks, but a few tweaks should improve things in the meantime.

  • Minor protocol refactoring resulting in friend requests and multi-device bug fixes (Desktop)

Not everyone has an 8K 34” ultrawide display. Lots of users have mentioned problems with Session’s user interface on smaller screens, but thanks to this update, size truly doesn’t matter.

  • User interface displays and works correctly on small screens (Desktop)

Party planning: Future updates

We’ve put a lot of work into making sure closed groups are stable and working as expected lately, and now the party can really get started. We’re planning our first major upgrade for closed groups — they should be able to handle way more people once we’ve implemented an upcoming feature called shared sender keys. Keep an eye out, it’s coming soon!

That Desktop refactor is on the way, and it’s one of our top priorities. It will include a lot of the same improvements you’ve already seen on Android and iOS: performance improvements, improved closed groups, working multi-device, and a looooong list of bug fixes.

We’ve also got a couple of behind-the-scenes things to add for onion requests. We want to add onion requests for the file server (the server that’s used when you send images and files through Session) and open groups. Although this might not seem as shiny as some of the other things we’re working on, it’ll provide an extra layer of protection for all Session users.

Thank you!

We’re so happy with how Session has been coming along the last few weeks. We’ve made huge leaps in stability and performance across all platforms — and we couldn’t have done it without YOU! To everyone reading these update notes, sending in feedback, and talking to their mates on Session — thank you so, so much. Talk soon!

The Session Team

Still have questions?

We’re happy to help with any questions you might have. Check out our FAQ for more information on our helpful features, or reach out to us at

<![CDATA[Session Release Roundup #3: Filling the Android void]]> 2uUPuJIGzz915YRdviM0Nr 2020-05-26T22:00:00.000Z Major Android overhaul brings stability and reliability

Who says robots can’t have feelings? Android is certainly feeling the love with this latest Session update.

We took a more fundamental approach with this update — instead of focusing on specific bug fixes, we decided to change the underlying logic of Session’s basic functionality (on Android, at least). What we’re really saying is: the bones of the Android Session client just got a major calcium injection.

This means sweeping improvements you’ll be able to feel everywhere in the app: messages sending reliably, nitro-boosted performance, and (fingers crossed) multi-device improvements.

Let’s get into the nitty-gritty.

Android deployed: What’s in the latest update

Session is meant to help you keep in touch with your buddies, but problems with friend requests kept getting in the way. Sometimes, you’d send a friend request but your mate would never get it. Or maybe they’d already accepted your request but it never showed up for you. Well, now receiving and accepting friend requests should go off without a hitch.

  • Overhauled underlying friend request logic (Android)

Closed groups are supposed to connect you with your friends, but the groups themselves weren’t quite ready for the party — to put it plainly, they didn’t work well. Now, closed groups have finally RSVP’d — expect improved closed group functionality, especially for multi-device users.

  • Overhauled closed group logic and handling (Android)

If you’ve ever tried to pair your Android device, you might have noticed device linking was really unreliable. Maybe devices never paired at all, or if they did, messages didn’t sync. Multi-device has been something of a problem child, but these fixes should make linking with Android devices much smoother.

  • Overhauled underlying multi-device logic (Android)

Re-sync session. Re-sync session. Re-sync session. Sometimes re-syncing your session felt like Groundhog Day. Re-syncing should successfully fix broken sessions now, and message sending should be more reliable in general.

  • Overhauled underlying encryption session handling (Android)

Like we said before, this update was more of a makeover than a touch-up. You’ll notice the app should be faster and much more stable. Good vibes all around.

  • Refactor of the entire Session protocol (Android)

  • Fixed several UI bugs which blocked the user from performing certain actions (Android)

On the conveyor belt: Future updates

Android refactor: Done. iOS refactor: Also done. The next cab off the rank is the Desktop refactor. With the mobile versions out of the way, we’ll be turning the screws on our Desktop refactor — that update should be arriving in your inboxes in the next few weeks. This should mean a whole host of similar improvements to the ones iOS and Android just got: improved multi-device functionality, session handling, and overall performance.

And yes, the Spanish translation for Session is getting VERY close! Yes, really! It’ll most likely arrive on Android first, so Android users — keep an eye out for español in an upcoming update.

We’re going to make some updates to onion requests, too — soon they’ll reach their final form: triple-hop requests. We’ll also be adding a brand new feature to display onion request progress, so you can see your messages being routed around the world in real-time.

Last but not least, we’re still working on implementing shared sender keys to take closed groups to the next level — once we’ve got this implemented, you’ll be able to invite way more people to your closed groups.

Thank you!

All of the people out there sending in bug reports, feedback, and pet peeves — you are the secret sauce that makes Session so good. We’re so grateful for all of your help, let’s make Session the best private messenger on the planet. See you next time!

<![CDATA[Session Release Roundup #2: Fresh apples!]]> 2GPYFM8l5CztyEjAweJO7m 2020-05-10T22:00:00.000Z It’s been a crazy couple of weeks since we last talked, and iOS 1.2.0 is rolling out now. This brand-spanking-new iOS release is brimming with bug fixes and quality-of-life boons. We know the app has been having some teething issues — but hang in there, we think Session will have you smiling soon! Here’s everything that’s shipped and slated for Session.

In the apple cart: Changes in the latest Session updates

Multi-device users reported some strange encounters of the third kind behaviour with friend requests, but these fixes should clear those problems right up.

  •  Fixed multi-device friend request acceptance (iOS)

  •  Fixed multi-device auto-generated friend request bug (iOS)

  •  Contacts now sync when using multi-device (iOS)

Push notifications were acting more like crawl notifications. If you’re using the Apple Push Notification service (APNs) and your push notifications have been arriving slowly, in clumps, or not at all, this should help fix that.

  • Fixed APNs token uploading issue (iOS)

Multi-device has been suffering from multi-issues — lots of you couldn’t even get your devices linked at all. These changes should make linking devices and using multi-device much smoother!

  • Made device linking more reliable (iOS)

  • Fixed multi-device display name updating bug (iOS)

  • Fixed multi-device message status bar updating bug (iOS

You might’ve heard whispers of zombie RSS feeds haunting Session. No matter how many times you deleted them, they always came back! Well, we double-tapped ‘em for you — Loki News and Session Updates RSS feeds will no longer come back if you delete them.

  • Made default RSS feeds deletable (iOS)

  • Don’t auto-join default RSS feeds (iOS)

Some messages were getting lost in the ether due to issues with message delivery, so the network will now store your messages for longer to make sure you get them before they’re deleted.

  • Increased message Time-To-Live (iOS)

  • Improved message fetching performance (iOS)

Nobody wants to see nasty images they never asked for. Although friend requests can’t contain images, your profile image still shows — so it was possible for someone to send you an unsolicited image (their profile picture) before you accepted their request.

  • Don’t attach the sender’s profile picture URL to friend request messages (iOS)

We’ve done a complete overhaul of the codebase to keep Session feeling rosy (i.e., less crashes, less weird bugs, and less weird UI issues). This should also make things easier for us when we’re debugging and updating things going forward.

  • Fixed various database handling bugs (iOS)

  • Fixed various minor UI issues (iOS)

  • Fixed various crashes (iOS)

  • Major refactoring of the Session protocol layer (iOS)

  • Added tests for Session protocol corner cases (iOS)

Not quite ripe: Changes planned for upcoming Session updates

You asked for it, and you’re getting it: Session habla español! For those waiting on other translations: hopefully Session will reach polyglot status soon, but we want to make sure its Spanish is up to scratch first. The good news is, the process of transforming Session into a shining Spanish star should mean we’re ready to rumble when we move on to future translations.

The next mission for Session is to get another big list of fixes implemented for Android and Desktop clients. Until then, iOS users still might run into some issues when talking to their non-iPhone friends. Session en español will roll out in the next big Android update, which should be coming in the next few weeks (that’s right robot lovers, we haven’t forgotten about you).

Beyond that, we’ll be working on something called shared sender keys, which will make closed groups bigger and better than ever before. And it just wouldn’t feel right if we didn’t spend some time working on multi-device, so we’re planning to start work on a new multi-device approach which should mean faster message syncing across devices.

Thank you!

Once again, we love hearing all your thoughts and feedback about the app — it really does mean everything to us! So long for now, and thanks for all the support.

<![CDATA[Session Release Roundup #1: You’ve got mail!]]> 2EICfeivlfvGU00oTe5K5 2020-04-22T22:00:00.000Z Welcome to the first ever Session release roundup! In these posts, we’re going to talk about all of the newest fixes, features, and future plans for Session. Every time there’s a major Session release, we’ll put out one of these — and an accompanying email newsletter — so you can see what’s changed, and what changes are coming up next. If you want these posts delivered straight to your email inbox, hop down to the bottom of the page and sign up to the Session newsletter!

Today, it’s all about the latest mobile and desktop releases of Session (1.1.0 on mobile, 1.0.7 on desktop) — available now! For this round of releases, we wanted to focus on making Session more dependable, so we’ve packed in UI polish and bug fixes instead of bundling new features. A lot of the work that went into 1.1.0 sets Session up for future updates as well — these releases will help us troubleshoot problems with closed groups, open groups, and multi-device.

On-board for delivery: Changes in the latest Session updates

There have been some widespread problems with message delivery. These changes should help make sure your messages reach their destinations and don’t get lost on the way.

  • Session now correctly retries with a different Service Node if a message fails to send. iOS

  • Heavily refactored Service Node communication layer to improve reliability. iOS, Android

  • Various fixes and improvements to client-Service Node communication. Linux, macOS, Windows

We noticed that Session felt a little bit slooooooow. We’ve made some tweaks to improve Session’s performance.

  • Made various multithreading improvements. iOS, Android

Every now and then, Session does some odd stuff. Sometimes it’s plain old crashes, sometimes it’s stranger things. This change should fix a lot of those problems.

  • Changed some things which were incorrectly happening in parallel. This was causing race conditions which could cause invalid states in the app. iOS, Android

Chatting is more fun when you’re doing it with more than one. Closed groups are a core part of Session, but they needed some TLC to get them working properly.

  • Closed group descriptions now show a snapshot of the group’s state per message instead of updating dynamically iOS, Android

  • Closed group messaging is disabled when user is removed iOS, Android

  • Ignore messages from users that aren’t in the closed group iOS, Android

  • Correct message is now shown when user is removed from a closed group iOS, Android

  • All closed group members now notified when a user is removed iOS, Android

  • Fixed unnecessary database checks for open groups to reduce CPU usage Linux, macOS, Windows

Session’s privacy-preserving notifications turned out to be so private they didn’t even tell you when you received messages — we’ve implemented a whole new notification system to make notifications more reliable on mobile.

  • Session now offers you the choice between Apple Push Notification service (iOS)/Firebase Cloud Messaging (Android) and background polling (old system) for push notifications. APNs/FCM provide more immediate and reliable push notifications. iOS, Android

Note: using Apple Push Notification service or Firebase Cloud Messaging notifications exposes your device IP to Apple or Google respectively. Of course, your messages are still encrypted and onion routed — so Apple and Google still can’t see your message contents, who you’re talking to, or when you’re sending and receiving messages.

Speaking of being notified — it should be obvious when someone @s you.

  • Added @mentions in side panel of desktop client Linux, macOS, Windows

Auto-update isn’t all that useful when it doesn’t happen automatically. We’ve made some fixes so that this is (hopefully) the last version of Session Desktop that you’ll have to download manually.

  • Desktop clients now auto-update successfully Linux, macOS, Windows

Here’s a riddle: how do you moderate a chat when you can’t select or delete messages? Well, you can’t… so we fixed that.

  • Message selection and deletion now work properly Linux, macOS, Windows

Sent a rant about work to your boss by mistake? Accidentally sent a confession of love to your crush? We’ve got your back — just click ‘unsend’.

  • Message delete button now shows ‘unsend’ for messages that can be deleted from their servers. Linux, macOS, Windows

Did someone ask for more onions? That’s right, 1-hop onion requests are now available on Session desktop. This should also make message delivery more reliable.

  • Enabled 1-hop onion requests Linux, macOS, Windows

In the workshop: Changes planned for upcoming Session updates

The work that went into refactoring the Service Node communication layer is going to be super important over the next few weeks — now we’ll be able to enable onion requests and more reliably fix issues with closed groups, open groups, and multi-device.

We’ll be working on implementing three-hop routing — the reason we built the onion request system — some time over the next few weeks.

We’re also working on implementing shared sender keys, which means we’ll be able to increase closed group size! We don’t have a specific number to share with you just yet — but the number of members allowed in a closed group will increase substantially.

¿Hablas español? That’s right, we’ve been hard at work on localising Session into some of the most-requested languages, and our Spanish localisation is almost ready! We’re putting the finishing touches on the Spanish translation, so keep an eye on our social channels for the latest updates.

Thank you!

We’ve been busy bees lately, and there’s still plenty of work left for us to do. For now, thank you to all our community members who have helped us find all the bugs and bumpy parts of Session. We don’t use the normal privacy-invading analytics tools that other developers rely on to improve their software — so your help means the world to us.

<![CDATA[Verifying software downloads on Linux, Windows, and macOS]]> 7ma3t6wTndpMX5bKfyRZ5L 2020-04-08T22:00:00.000Z Don’t care what’s behind the scenes? Skip straight to software verification tutorials for macOS, Linux, and Windows.

Back in the day, software used to arrive in the form of floppy discs, MiniDiscs, and CD-ROMs. But now, it’s all about the download. Everything is downloaded: the apps you use to keep in touch with your family, the video games you use to wind down after work, and probably even the web browser you’re using to read this article.

But this introduces a problem — how do you make sure all this software you’re downloading is authentic?

Well, first thing’s first: you should always make sure you’re downloading software from a trusted source. For Session (and most open-source projects), all our official releases can be found on our GitHub and our website, If you really want to, you can even check Session’s code and compile it yourself. That way, you know exactly what your computer is running.

For the rest of us, you can do something called hash verification. Hash-what, you ask? Well, you can apply a cryptographic hashing algorithm to a piece of information — such as a computer program — and it’ll generate a functionally unique hash. This means that if two different people can generate the same hash, they can verify that they’ve both got the exact same information.

256 bits of data on the wall: SHA-256

One of the most commonly used hashing algorithm families is the ingeniously named Secure Hash Algorithm 2 (SHA-2), which contains the hashing function SHA-256 (more on that later).

But, the biggest reason hashes are important is because they’re one-way tickets: you can use any data to generate a hash, but you never use a hash to generate data.

This means that, for example, if you and a Session developer can generate matching hashes using a version of Session, you’ll know for sure your version is exactly the same as the one shipped by the developer.

Signed, sealed, delivered: Public key encryption

So, you compared the hash of your version of Session with a hash published by a Session developer, and they matched! Great, but… how do you know it’s really a Session dev that sent you that hash? Verifying online identities can be tricky, but in this case it’s doable using public key encryption — like the one Session uses in its decentralised friend request system

GNU Privacy Guard (GPG) allows for the secure transmission of information, and we can use it to verify both the origin of a message, and that its contents haven’t been altered.

Using GPG encryption, you can sign a piece of information — like a message containing a hash. Once you’ve done that, anybody that has your GPG public key can check to see if it was the real you that signed the message.

That’s why we always publish signed hashes with all of our releases — so you can rest easy knowing your copy of Session hasn’t been tinkered with. You can find them on our GitHub, or at

Here’s how you can use those signed hashes to verify your downloads. The process is slightly different depending on which operating system you’re using, so we’ve included guides for Windows, Linux, and MacOS.

Verifying files using GPG on Windows

If you prefer, we’ve also created a video tutorial for verifying files using GPG on Windows.

0. Download a copy of Session, and then find a message that looks like this:

The following hashes have been signed for verification using keejef's GPG keys located in the loki core repository at

SHA256 Hashes

latest-linux.yml 1c529ec13984163337b750af6a11492fc3007d34cc35f3d52dcacebfbf04c685 latest-mac.yml 424583aebbf6ad7bf1c1703f4590206c68cc24724e9e53e39941fa53f9d2aef4 latest.yml 51ccf1a9a156709f99cff89f606540e7bd8ac8761ed005295d79261c08111f1e session-messenger-desktop-linux-amd64-1.0.6.deb 4a2f8832887cd901bf091d6122aa20d9f6317db62b922407b5e9ebbf72cb439c session-messenger-desktop-linux-x86_64-1.0.6.AppImage 43abf0d0aedf200c14a853070965142d3fdbe39b26e4186e1814418612f9f8b5 session-messenger-desktop-mac-1.0.6.dmg 04128f0e2ba8568ffde61a68ddf27b8753064823683ab9fa9889857bc27fb98e session-messenger-desktop-mac-1.0.6.dmg.blockmap d91d444071c9e9941a04c75831172b9341703a31ddd6cce5f0394e8f6f5499b5 a17ad640ba619a55ee77b99e6051ba5ac7066cc973099a61c29fec488026c9f2 session-messenger-desktop-win-1.0.6.exe 0f4b0231ea0db7a2179311ea014dfb30364bd787ddc94af41c4340bc0687b609 session-messenger-desktop-win-1.0.6.exe.blockmap b7bf63565caed4ca60e3d68893786b333f622554e9c4a3ade3f909da7ea1f5d7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEcBAEBCgAGBQJeiBa0AAoJEKyXFIlc5F1VL/cH/iyfqB9a1T9PDFOPTSFrAfWg OOC2na/vlBDuI5a7wY71ZkWXIgFln/hmJTotU0L9d35HqD9/DEBhjDhftceOKrzt h/RdQrm5YIBRdwdmEhXrTGfN2GVs0MpHobfc++InOR/E+pJ8+lvIXvX4WqO2cQJl fJWcJ02l2qoE5sC7VkQ71uEhggP7fsXlCT+yqAr01sr8Z8RAZ2snOzN97cejFUXF /E8L4amIE2/EkXvWBps+Q82AuuOLilkV00r+lAmqgStiDAEhtPSYA/lq2d9HzE8x utx4NbHOOysJgaPjU+iL/IaAeOaapX1Ejs2zM37+3wJdJ4MnVUCm9fI2v9sbV3s= =o45M -----END PGP SIGNATURE-----

It’s always located with the release notes on GitHub and under the Signatures button at Here’s everything else you’ll need to do:

1. Download and install a trusted GPG utility such as gpg4usb

2. Find the public key that signed your download. The public keys of all of our developers are on our GitHub. In this example, the PGP signed message says this at the top:

The following hashes have been signed for verification using keejef’s GPG keys located in the oxen core repository at

Follow the link in this message.

3. Copy the entire PGP public key block to your clipboard.

4. In gpg4usb, click ‘Import Key’ > ‘Clipboard’.

5. The key import details should appear in a pop-up window. Click ‘OK’. The name of whoever owns the key should appear in the right-hand window.

6. Tick the checkbox next to this name.

7. Copy the entire PGP signed message and PGP signature from step 0.

8. Paste it into the text-box in the left-hand window of gpg4usb.

9. Click ‘verify’.

10. If the message was signed by the key you imported, a green bar at the bottom of the text-box will appear with the message ‘Text was completely signed by: Kee Jefferys’.

We’ve now successfully verified that the hashes posted with the release were uploaded by Kee — a trusted developer for Session.

Now we need to check that the hash of your local file matches the hash that Kee generated.

11. Open a command line — such as Command Prompt, which comes pre-installed with Windows.

12. Type the following into your command line:

certUtil -hashfile your_file_path_here sha256

13. Hit enter. Your command line should generate a SHA256 hash.

14. Compare the hash you generated with the one published in Kee’s signed message. If they match, you’ve successfully verified that your files are the same.

Verifying files using GPG on Linux

If you prefer, we’ve also created a video tutorial for verifying files using GPG on Linux.

0. Download a copy of Session, and then find a message that looks like this:

The following hashes have been signed for verification using keejef's GPG keys located in the loki core repository at

SHA256 Hashes

latest-linux.yml 1c529ec13984163337b750af6a11492fc3007d34cc35f3d52dcacebfbf04c685 latest-mac.yml 424583aebbf6ad7bf1c1703f4590206c68cc24724e9e53e39941fa53f9d2aef4 latest.yml 51ccf1a9a156709f99cff89f606540e7bd8ac8761ed005295d79261c08111f1e session-messenger-desktop-linux-amd64-1.0.6.deb 4a2f8832887cd901bf091d6122aa20d9f6317db62b922407b5e9ebbf72cb439c session-messenger-desktop-linux-x86_64-1.0.6.AppImage 43abf0d0aedf200c14a853070965142d3fdbe39b26e4186e1814418612f9f8b5 session-messenger-desktop-mac-1.0.6.dmg 04128f0e2ba8568ffde61a68ddf27b8753064823683ab9fa9889857bc27fb98e session-messenger-desktop-mac-1.0.6.dmg.blockmap d91d444071c9e9941a04c75831172b9341703a31ddd6cce5f0394e8f6f5499b5 a17ad640ba619a55ee77b99e6051ba5ac7066cc973099a61c29fec488026c9f2 session-messenger-desktop-win-1.0.6.exe 0f4b0231ea0db7a2179311ea014dfb30364bd787ddc94af41c4340bc0687b609 session-messenger-desktop-win-1.0.6.exe.blockmap b7bf63565caed4ca60e3d68893786b333f622554e9c4a3ade3f909da7ea1f5d7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEcBAEBCgAGBQJeiBa0AAoJEKyXFIlc5F1VL/cH/iyfqB9a1T9PDFOPTSFrAfWg OOC2na/vlBDuI5a7wY71ZkWXIgFln/hmJTotU0L9d35HqD9/DEBhjDhftceOKrzt h/RdQrm5YIBRdwdmEhXrTGfN2GVs0MpHobfc++InOR/E+pJ8+lvIXvX4WqO2cQJl fJWcJ02l2qoE5sC7VkQ71uEhggP7fsXlCT+yqAr01sr8Z8RAZ2snOzN97cejFUXF /E8L4amIE2/EkXvWBps+Q82AuuOLilkV00r+lAmqgStiDAEhtPSYA/lq2d9HzE8x utx4NbHOOysJgaPjU+iL/IaAeOaapX1Ejs2zM37+3wJdJ4MnVUCm9fI2v9sbV3s= =o45M -----END PGP SIGNATURE-----

It’s always located with the release notes on GitHub and under the Signatures button at Here’s everything else you’ll need to do:

1. Find the public key that signed your download. The public keys of all of our developers are on our GitHub. In this example, the PGP signed message says this at the top:

The following hashes have been signed for verification using keejef’s GPG keys located in the loki core repository at

2. Copy the entire PGP public key block to your clipboard.

3. Open your command line — such as Terminal.

4. Type the following and then hit enter:

gpg --import

5. Paste your clipboard and hit enter.

6. Press ctrl+d, this will import the key you’ve just pasted. Some information should appear about the owner of the key.

7. Copy the entire PGP signed message and PGP signature from step 0 to your clipboard.

8. Go back to your command line, type the following, and hit enter:

gpg --verify

9. Paste your clipboard and hit enter.

10. Press Ctrl+D, this will verify that the key you imported signed this message. A message should appear containing ‘good signature’. If it says bad signature, the key you imported did not sign the message.

Hopefully, we’ve now successfully verified that the hashes posted with the release were uploaded by Kee — a trusted developer for Session.

Now we need to check that the hash of your local file matches the hash that Kee generated.

11. In your command line, type the following and hit enter:

sha256sum your_file_path_here

12. A SHA256 hash will appear in your command line. Compare the hash you have generated to the one published in Kee’s signed message. If they match, you’ve successfully verified that your files are the same.

Verifying files using GPG on MacOS

If you prefer, we’ve also created a video tutorial for verifying files using GPG on MacOS.

0. Download a copy of Session, and then find a message that looks like this:

The following hashes have been signed for verification using keejef's GPG keys located in the loki core repository at

SHA256 Hashes

latest-linux.yml 1c529ec13984163337b750af6a11492fc3007d34cc35f3d52dcacebfbf04c685 latest-mac.yml 424583aebbf6ad7bf1c1703f4590206c68cc24724e9e53e39941fa53f9d2aef4 latest.yml 51ccf1a9a156709f99cff89f606540e7bd8ac8761ed005295d79261c08111f1e session-messenger-desktop-linux-amd64-1.0.6.deb 4a2f8832887cd901bf091d6122aa20d9f6317db62b922407b5e9ebbf72cb439c session-messenger-desktop-linux-x86_64-1.0.6.AppImage 43abf0d0aedf200c14a853070965142d3fdbe39b26e4186e1814418612f9f8b5 session-messenger-desktop-mac-1.0.6.dmg 04128f0e2ba8568ffde61a68ddf27b8753064823683ab9fa9889857bc27fb98e session-messenger-desktop-mac-1.0.6.dmg.blockmap d91d444071c9e9941a04c75831172b9341703a31ddd6cce5f0394e8f6f5499b5 a17ad640ba619a55ee77b99e6051ba5ac7066cc973099a61c29fec488026c9f2 session-messenger-desktop-win-1.0.6.exe 0f4b0231ea0db7a2179311ea014dfb30364bd787ddc94af41c4340bc0687b609 session-messenger-desktop-win-1.0.6.exe.blockmap b7bf63565caed4ca60e3d68893786b333f622554e9c4a3ade3f909da7ea1f5d7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEcBAEBCgAGBQJeiBa0AAoJEKyXFIlc5F1VL/cH/iyfqB9a1T9PDFOPTSFrAfWg OOC2na/vlBDuI5a7wY71ZkWXIgFln/hmJTotU0L9d35HqD9/DEBhjDhftceOKrzt h/RdQrm5YIBRdwdmEhXrTGfN2GVs0MpHobfc++InOR/E+pJ8+lvIXvX4WqO2cQJl fJWcJ02l2qoE5sC7VkQ71uEhggP7fsXlCT+yqAr01sr8Z8RAZ2snOzN97cejFUXF /E8L4amIE2/EkXvWBps+Q82AuuOLilkV00r+lAmqgStiDAEhtPSYA/lq2d9HzE8x utx4NbHOOysJgaPjU+iL/IaAeOaapX1Ejs2zM37+3wJdJ4MnVUCm9fI2v9sbV3s= =o45M -----END PGP SIGNATURE-----

It’s always located with the release notes on GitHub and under the Signatures button at Here’s everything else you’ll need to do:

1. Download and install GPGSuite

2. Find the public key that signed your download. The public keys of all of our developers are on our GitHub. In this example, the PGP signed message says this at the top:

The following hashes have been signed for verification using keejef’s GPG keys located in the loki core repository at

3. Click ‘RAW’, and then save the .asc file to your computer.

4. Open your command line (such as Terminal), type the following, and hit enter:

gpg --import your_.asc_file_path_here

5. Right click the ‘gpg: key’ that appears, and then click copy.

6. Type the following into your command line, then hit enter:

gpg --fingerprint paste_gpg_key_here

7. You’ve now imported a GPG key. Some information should appear about the owner of the key.

8. Copy the entire PGP signed message and PGP signature from step 0 to your clipboard.

9. Type this into your command line and hit enter:

gpg --verify

10. Paste your clipboard, hit enter, then hit ctrl+d. A message should appear containing ‘good signature’. If it says bad signature, the key you imported did not sign the message.

Hopefully, we’ve now successfully verified that the hashes posted with the release were uploaded by Kee — a trusted developer for Session.

Now we need to check that the hash of your local file matches the hash that Kee generated.

11. In your command line, type the following and hit enter:

shasum -a 256 your_file_path_here

12. A SHA256 hash will appear in your command line. Compare the hash you have generated to the one published in Kee’s signed message. If they match, you’ve successfully verified that your files are the same.

Verifying software with GPG: Done!

There is a lot to learn in the world of public key encryption. Really, this article just brushes the surface of what you can accomplish with these tools.

Verifying the software you’re downloading is always important, especially if you’re dealing with something that is going to handle sensitive information — like a private messaging app. Now you can make sure your version of Session is the same as the version we shipped, and relax knowing that nobody in the world can snoop on your messages.

<![CDATA[Dev Diary: The rise and fall of the zombie swarm]]> 7LuzoQmxBEJsNtvS82xJBP 2020-03-23T23:00:00.000Z Most traditional private messaging apps have a centralised server that lets you store and send all of your messages without a hassle.

But, for all the convenience that centralised servers offer, there’s always the chance whoever’s running them will end up screwing you over. You’ve just gotta hope the operator won’t snoop on your messages, share your conversations, or leak your information through a simple, honest error.

It’s these drawbacks that pushed us to use a decentralised network for Session. But, with no central server to easily store and relay messages between users, we’re sacrificing some convenience.

So, how do we deliver your messages without a central server?

Session uses things called swarms. Swarms are groups of 5-7 Service Nodes (run by independent operators around the world) that are ‘connected’ to each other. When you create a Session account, your client will be assigned to a swarm. This way, if you’re offline when someone sends you a message, it can be stored in your swarm until you come online to retrieve it.

Generally, you won’t be in the same swarm as the person you’re trying to contact, so your client needs to find out which swarm your contact is in before you can send them a message. Then a copy of your message is sent to three different Service Nodes in your contact’s swarm — this gives some extra insurance that your message will be stored and delivered successfully.

Obviously, it’s critical that messages have guaranteed delivery. If one swarm handles 90 per cent of all messages, we’re going to run into some serious performance problems. But… Session is all about privacy — we don’t know anything about your messaging habits, so how can we make sure messages are distributed evenly across the network?

We needed a protocol that could reliably deliver messages in our network.

MISSION: To design a way to deterministically distribute the storage of messages approximately evenly across the Service Node network.

We knew our solution needed to be deterministically calculated — meaning anyone could join the network, follow a set of rules, and come to the same conclusions about any given swarm. But we had to make sure it wasn’t easy to predict which swarm a Service Node would end up in, otherwise a malicious actor could theoretically gain control of a whole swarm and cheat message storage tests (these are simple tests which Service Nodes use to ensure all peers in their swarm are storing messages correctly).

If one actor could reliably gain control of a swarm, they’d effectively get to choose whether your messages are ever delivered. That doesn’t sound very trustless, does it?

So, we needed to work out how to group all the Service Nodes into swarms in a relatively unpredictable way, and then find a way to evenly distribute users into those swarms. For now, we’re going to focus on the second part of this problem: how to distribute users into swarms.

We decided to map swarm IDs and user public keys onto the same number line, then assign users to the swarm IDs they were closest to on the line. Public keys are randomly generated for new users, but how should we create new swarm IDs?

Imagine we have a swarm distribution that looks like this. Note: swarm #10 wraps around to swarm #0.

In this situation, swarms #6 and #9 are going to get way too much traffic — all the public keys mapped from 2 ½ – 6 ½ will be in #6, public keys from 8 – 2 ½ will be in #9, and public keys from 6 ½ – 8 will be in #6.

A new swarm can be created to lighten the load, but if we do randomly generate swarm IDs the way we do for public keys, we might end up with something like this:

As you can see, adding swarm #8 would solve nothing. Swarm #6 would still have all the public keys from 2 ½-6 ½ mapped to it, and swarm #9 would now have 8 ½-2 ½ — similar to before.

Of course, being random, the new swarm could just as easily pop up at #3 and solve the problem — but we needed a method which would work all the time. Next we tried making new swarm IDs fill the biggest gap on the number line. This way, we should get a more even distribution, like this:

Simulations showed a much healthier load distribution when we used this gap filling method, which always ensured the largest swarm would never be more than double the size of the smallest.

We implemented what we thought was a winning strategy, only to discover…our code was actually broken. We didn’t notice during our initial testing, because it was breaking in ways we couldn’t see. But when we were gathering some testnet statistics, we noticed that one of our scripts seemed to be suggesting more than 20 nodes belonged to a single swarm — very alarming! There should only ever be 5-7 nodes in a swarm.

Our system seemed to be working fine up until then, and we hadn’t touched any of the relevant code in months — so this was pretty confusing. All of a sudden, there was a serious problem right before release.

Turns out the algorithm itself was correct, and it was just a single line of code in the implementation causing all the trouble.

To figure out what was going on, we needed to see some historical data about swarm sizes. Unfortunately, that information didn’t exist: we didn’t have the relevant logs and the blockchain only stores the latest swarm state. To get the logs we needed, we were going to have to replay the whole blockchain for ourselves — from the very beginning.

When we did that, our reconstructed swarm assignment history showed nodes joining the pathological swarms seemingly out of nowhere. After looking at some other logs, it all clicked — they were decommissioned nodes.

We had recently introduced the decommissioned state — a kind of purgatory for nodes before they get deregistered. This way operators have a bit of time to patch up their unhealthy nodes before they’re lost for good. Decommissioned nodes were never counted towards swarm size — otherwise you could end up with a swarm full of faulty nodes.

Here’s the problem: decommissioned nodes automatically return to their original swarm if they come back online — completely bypassing swarm size limitations.

So, Nodes that were about to be decommissioned weren’t resetting their swarm ID values. That made the solution pretty simple: we had to reset the swarm ID value for nodes the moment they are decommissioned. Implementing this fix only required adding one line of code, but it took a couple of days to figure out.

On its own, the oversized swarms would probably just add some inefficiency to the network, but there was another, more insidious problem.

By design, if the size of a swarm gets dangerously small, the network might redistribute the swarm’s healthy nodes — essentially removing the swarm. What would happen if a single decommissioned node were to come back into a swarm that no longer existed?

We called it a zombie swarm — a swarm brought back from the brink. Before the patch, the network would allow the swarm to operate even if it only had one node — far too small for it to be considered reliable.

But thanks to our one-line fix, our release went ahead as planned and the zombie swarms never took over.

We ran into a lot of problems trying to come up with a dependable decentralised message delivery system.

For all the headaches along the way, in the end all we needed was that one line of code — to fix the zombie swarm dilemma — for everything to fall into place.

<![CDATA[Sybil disobedience: How Session protects your anonymity using blockchain and crypto tech]]> 65ucMvySi3nAP0xrBelEUK 2020-02-25T23:00:00.000Z ‘Blockchain’: The buzziest buzzword of the last decade. You’ve probably heard claims about how blockchain is going to ‘revolutionise’ every industry, and how it’s the ‘future’ of security, privacy, data storage, and more. But blockchain has struggled to find meaningful real-world applications, and for most people, the word feels like vaporware — or worse, a shameless cash-grab by companies trying to scam their customers.

‘Cryptocurrency’ hasn’t fared much better, either as a buzzword or as a product. Very few cryptos have delivered on their grand promises, and the ones that have are facing ever-stricter government regulation. Just like wider blockchain tech, crypto hasn’t gotten mainstream adoption, and real-world use cases are still pretty limited.

Even more worryingly, the last five years have seen plenty of fraudulent blockchain and cryptocurrency projects rise to prominence, and dishonest (or simply incompetent) ‘altcoin’ or ‘shitcoin’ projects seemingly outnumbering legitimate projects that can actually deliver.

Session bucks this trend of empty promises — we’ve built a real product that leverages a cryptocurrency blockchain to provide a useful, and even vital, service: secure, highly anonymous encrypted communications.

But why does Session even need a cryptocurrency, or the blockchain?

Session and the blockchain: Back to basics

You might’ve heard us talk about the Service Node network — the community-operated decentralised network that runs Session. Decentralisation is Session’s ace in the hole (for more on why decentralisation is so crucial, check out our article on centralisation vs. decentralisation). But what does that have to do with blockchain?

At its core, a blockchain is a ledger of transactions, and each block in the chain is made up of a set of transactions, a cryptographic hash of the previous block in the chain, and a hash of itself. (Blocks also include the solution to a complex mathematical puzzle — but that’s beyond the scope of this article. For more on how blockchains work, check out the primer on the Oxen blog.) New blocks of transactions are validated by ‘full nodes’ or ‘masternodes’ — user-operated computers on the blockchain network. These nodes work together to decide which transactions are valid, and the order they’re entered into the blockchain ledger. And in a properly decentralised blockchain, participation is permissionless — that means there’s no central authority that gets to decide who can (or can’t) run a node.

Oxen Service Nodes: Servers at your service

The Oxen blockchain doesn’t just have full nodes or masternodes — it has Service Nodes. What’s the difference? In a nutshell, Oxen Service Nodes do all the typical full node tasks, like validating new blocks, and storing the blockchain. But Service Nodes also provide services to the network above and beyond those basics — including securely routing Session messages from person to person. Session’s onion routing technology limits the information any one Service Node has about messages being sent — they only know the IP address of the previous and following nodes in the message routing chain. This means it’s not possible for any one Service Node to figure out who’s talking to whom.

The Service Node network is the backbone of Session’s secure messaging system. But here, we run into a problem. If anyone can run a Service Node, couldn’t one attacker start up a bunch of malicious Service Nodes and swarm the network with them? And if suddenly every node in a message routing chain was controlled by the same attacker, couldn’t this compromise Session’s anonymity?

This kind of attack is called a Sybil attack, and it’s a real danger for most decentralised networks — with no barrier to entry, a malicious actor can simply start up an overwhelming amount of nodes and gain control of (or simply spy on) the network.

Luckily, Session has a solution.

Sybil war: Session’s market-based Sybil resistance

‘Sybil resistance’ is why the cryptocurrency element is important. There’s a financial barrier (in the form of a $OXEN cryptocurrency staking requirement) to starting up a Oxen Service Node, making it prohibitively expensive for an attacker to start up enough nodes to execute a Sybil attack on Session’s network.

The long version:

On many decentralised networks, starting up a new node is as simple as turning on your PC (or renting a VPS), installing the network’s node hosting software, and turning it loose onto the network. This makes it relatively simple for a third party to start up dozens or even hundreds of nodes and conduct a Sybil attack.

Attacking the Oxen network isn’t quite so simple. To run a Oxen Service Node, a prospective node operator has to ‘stake’ — temporarily lock up — a certain amount of the Oxen cryptocurrency. In return for providing services to the network, Service Node operators are periodically rewarded with a portion of the Oxen block reward. This incentive helps to keep the network healthy, and drives network growth to further strengthen the network.

Only nodes that have met the staking requirement (15000 $OXEN) are allowed to participate in the network — if a node hasn’t met the staking requirement, it cannot participate in building the blockchain, routing Session messages, or providing any of the other services in the Oxen privacy suite.

Most of the time, getting enough Oxen to run a node will require purchasing from the market. At any one time, there is a finite amount of Oxen available to purchase, and basic supply and demand principles mean that as the amount of available Oxen dwindles, the price increases accordingly.

This supply-demand effect is further reinforced by something called lock-up. If Oxen is staked to a Service Node, it can’t be moved or traded — meaning that the purchasable supply reduces as the number of Service Nodes increases. If a prospective attacker attempted to buy up a massive amount of Oxen (in order to stake a large number of nodes), the cost would ramp up as they purchased, making it extremely expensive to actually conduct a successful Sybil attack.

The staking requirement, enabled by the Oxen cryptocurrency, gives the Oxen Service Node network — and, by proxy, Session — what we refer to as ‘market-based Sybil resistance’.

The nitty-gritty:

Running a Service Node lets you give back to the Session and Oxen communities, while also receiving cryptocurrency rewards. Interested? Check out Oxen’s Service Node (a.k.a. masternode) rewards calculation guide, or look at our docs for information on how to set up an Oxen Service Node.

Okay, but why not [Bitcoin/Lightning/Monero/my favourite crypto]?

We’ve seen lots of people wondering why we didn’t simply use an established crypto as the basis for the project, and it’s a reasonable question: so here’s our reasoning.

The first reason: Incentivisation

Or, why not Bitcoin/Lightning?

The fundamental reason that we couldn’t use an existing crypto, such as Bitcoin, is that we need to incentivise Service Nodes by rewarding them with crypto in return for their services. We couldn’t do this in another coin’s economy, since we wouldn’t be able to modify their blockchain algorithm to create new crypto with which to reward Service Nodes. The only other alternative, which we would have to adopt if we built Session on something like the Lightning Network, would be to charge per message sent in Session — but this would be a significant barrier to Session’s adoption.

The second reason: Foundational changes.

Or, why not Monero?

If anonymity is the issue, why fork Monero, and not just use Monero itself?

Essentially, we needed to make some foundational changes to the Monero blockchain to support the Service Node architecture we’d envisioned, and integrating those changes into Monero would have been difficult, if not impossible, because Monero’s main values do not include developing ancillary privacy tools based on their network. Instead, we forked the Monero codebase — leaving it open-source, of course — and began making the changes and additions necessary to support the additional privacy services we wanted to provide, such as instant messaging. In keeping with the open-source ethos of collaboration and community spirit, we’ve contributed back to Monero in several ways, including adding IPv6 support and helping to fund Monero’s research lab.

Session is a rare beast in the blockchain world: a tangible, functional product with a robust feature set, supported by extensive documentation, and backed by a certified non-profit foundation. The Oxen blockchain gives Session its network of Service Nodes, and the Oxen crypto gives the network its market-based Sybil resistance properties — solving a crucial problem that many other decentralised networks continue to struggle with. Session, the Oxen blockchain network, and the Oxen cryptocurrency are three crucial pieces of the online privacy puzzle, and they create a network that’s much more than the sum of its parts.

Over and above all of that, though, Session marks another sort of milestone for blockchain-based tech: Session provides security and anonymity using the blockchain — without making the experience all about blockchain.

If blockchain-based tech is to go truly mainstream, the blockchain itself needs to fade into the background. Think of it like this: you don’t need to know about the protocols behind your email provider; you just need to know that it sends emails. Session’s users leverage the power of the blockchain every time they send a message — without ever having to know about it. That’s what makes Session a truly different breed of blockchain project.

<![CDATA[Community spirit: How to contribute to Session’s development]]> 6VyS8a9cOugSiOl5khRrb7 2020-02-16T23:00:00.000Z Session is fully open-source — every line of code in the app, on all supported platforms, is publicly available on our GitHub (iOS; Android; Desktop). This has some serious security benefits: if you want to verify our security and anonymity claims, you can inspect the code yourself. And if you’re particularly security-conscious, you can even download the code and compile it on your computer, so you know exactly what code is running on your machine.

But by far the biggest benefit of open-source software is collaboration.

Open-source software is built by the community, for the community. Developers from different projects work together to solve problems, introduce new features, and fix bugs. For example: The Loki Project team (the team behind Session) collaborated with the developers of the Monero blockchain to give Monero IPv6 support. Open-source means more than just being able to look at the code; it means everyone can work together to build better software.

So what does this mean for you? If you run into a bug, or if Session is doing something you don’t think it should be, you can head to Session’s GitHub page for your platform (see links above) and open an issue. GitHub’s Issues section is a handy way for our developers to track problems that users are having, and if you open an issue, you can be sure one of our devs will take a look at it as soon as they can.

Opening an issue is simple: just click the link for your respective platform(s) above, sign in (or sign up) to GitHub, navigate to the Issues tab, and click ‘New Issue’. Make sure to fill out all the requested information (a description of the problem, and info about your device and platform).

Note: Make sure you have a quick look through existing open issues to see if someone has already reported the problem you’re having — avoiding double-ups helps our devs work through the issues list faster.

If you have feature suggestions, or just want to have some input without needing to make a GitHub account, you can join the official Session Feedback open group (join in the app). There is almost always someone from the team active in the group, so you know your feedback will be heard.

If you’re a developer and want to contribute directly to Session’s code, it’s as simple as forking the repo for the platform(s) you want to contribute to, making your changes or improvements to the code, and creating a pull request for our devs to review and merge — you know the drill. Session clients are written in:

You can also contribute to Session’s open group server and Loki File Server repos (both written in Javascript).

Open-source software is the backbone of a free and open internet, and Session is proud to be a part of the open-source development community. Got other questions, comments, or suggestions? Hop into the official Session public chat (join the open group in Session), join the Session Feedback open group (see above), or send the Session team an email at

<![CDATA[Metadata: Four syllables — zero privacy]]> 5quOkS0x6vGvnAXdpWKrVz 2020-02-09T23:00:00.000Z Metadata (n.): Data about data; data which describes or gives information about other data.

Metadata is the trail of footprints that you leave when you move through the digital world. Things like file creation times, file sizes and locations, and artist and album information for music files, are all examples of metadata. Metadata is created when you do things in a digital environment: create, move, or delete files, sync your phone with your computer, send an email, or even just turn on your laptop.

Some kinds can be really helpful. Your computer uses metadata to arrange files into folders and sort them by name or date. Your phone uses metadata to show you photos taken in a particular location. And your smart home assistant uses metadata to suggest relevant content for you to watch or listen to.

However, not all metadata is harmless — and not everyone who tracks and uses it has your best interests at heart.

Websites you visit will often collect metadata about you: for example, what browser and device you’re using, your IP address and location, how long you spend on the site, and whether you’ve visited before. This information can be used in helpful ways — sending you to the right site for your location, adapting the website design if you’re on a mobile device, and serving content relevant to you if you’ve visited before.

But this information can also be used by advertisers to build up a profile of who you are — a profile they can use to track and target you across the internet.

Advertisers often pay websites to host tracking software that lets them track you not only on one website, but on most or all of the sites you visit. Some advertisers may also simply buy access to websites’ stored metadata. Either method lets the advertiser build up a much more detailed and complete profile than if they could only see your browsing habits on a single website. Advertisers are then able to serve up ads specifically designed to target your needs, wants, and desires — walking a very fine line between helpful and just plain creepy.

Metadata takes on a whole new level of significance when you move into the realm of private messengers. Often, you use a private messenger because you either want privacy, or because you need it. But whether it’s a want or a need, metadata threatens your privacy when it comes to messaging.

End-to-end encrypted messaging apps secure the contents of your messages from prying eyes. If the messenger you’re using is truly end-to-end encrypted, nobody but you and the recipient can read it. Pretty private, right?

Not necessarily.

Every time you send or receive a message, even in an encrypted private messenger, you generate metadata. Sender and recipient identities, message lengths, and the dates and times messages are sent and received — your private messenger can log and store all these fragments of metadata, and more.

If the messenger uses centralised servers, you simply have to trust that the company or group running the app won’t store or sell your metadata.

Centralisation refers to a single central entity having control over a group or a system. In computer networks, centralisation means that there’s a single server (or cluster of servers) that manages data traffic over the network. For centralised messaging apps, this central server routes messages from sender to receiver — meaning that the server has to know who’s talking to who.

Even if the company behind the app is trustworthy, the simple fact that metadata is generated in the first place can be a security risk. If it exists, there’s the possibility it could be leaked, stolen, or exposed to the public.

The sheer existence of messaging metadata also opens up the possibility for governments or other third parties to file court orders forcing the company running the app to log, store,  and surrender metadata about specific users — even if the company would otherwise never do so.

If you want real privacy, you need to minimise your metadata footprint — both on the web and in your messenger. There are a number of tools you can use to block invasive tracking in your web browser — the Ghostery browser extension blocks tracking across a number of browser platforms, and if you’re looking for an all-in-one solution, Mozilla Firefox comes with built-in tracking prevention.

When it comes to messaging apps, your options are more limited. Session is the first private messenger to use a combination of decentralised servers, onion and proxy routing, and end-to-end encryption technologies to keep your metadata footprint as small as possible. Because Session is truly decentralised, there are no central servers to log or store metadata about your conversations.

You don’t have to trust that the app won’t misuse your messaging metadata — it’s simply not possible.

Your messages are encrypted before being routed over Session’s decentralised network, so there’s no way for it to know who you’re talking to.

 And to top it all off, Session is built from the ground up to minimise metadata generation. Not only is there no central server to store your metadata — it simply doesn’t exist. You don’t have to take our word for it, either. Session is open-source, meaning that anyone can take a look under the hood.

It’s time to take back your online privacy. Send messages — not metadata. Get Session.

<![CDATA[Onion requests: Session’s new message routing solution]]> HV6N0lbMQfjTinDoxQrcz 2020-01-29T23:00:00.000Z When the Loki Project set out to build Loki Messenger, the app that became Session, we knew that anonymity, security, and freedom needed to be at the very core of the app. And it seemed that the best way to accomplish that was to build Session on top of Lokinet, our bleeding-edge anonymous onion routing network. We knew that routing Session messages over Lokinet would provide total user anonymity and class-leading security.

However, as Session’s development progressed, we began to realise that Lokinet might not be the perfect fit for Session at this point in time.

Lokinet does offer the security, features, and versatility necessary for Session to succeed in its goal of providing secure and truly anonymous communications. However, as we worked to implement Lokinet on Android and iOS, it became clear that the changes required to get Lokinet working on mobile devices would not be trivial (see:, and even once Lokinet was successfully implemented, Session still wouldn’t be guaranteed to get approval for the iOS App Store and, to a lesser extent, the Google Play store.. Additionally, Lokinet has been undergoing some growing pains after its move to a much larger router network earlier this year, and the DHT and router discovery will need to be reworked before it is reliable. While these changes are underway now, they will not be completed in time for Session’s launch.

Lokinet is powerful — extremely so. But Session doesn’t need a network as versatile as Lokinet to get messages from A to B securely.

From a technical standpoint, Lokinet is powerful because it’s able to onion-route both TCP and UDP network traffic, allowing for highly versatile potential use cases (like live-streaming and video calling over an onion-routed connection). But because Session v1.0 will just be sending messages and file attachments, Session only needs a secure routing solution that supports TCP traffic.

Due to the nature of Session, we realised that the same protections could be provided with a much simpler onion router. Session’s new routing solution, onion requests, will accomplish this goal. Onion requests work by selecting three random Service Nodes (the user-operated servers on the decentralised network Session runs over)  and building an onion-encrypted path through them. Encryption is handled using the existing X25119 keys held by each Service Node Storage Server, and each onion request is processed by the Loki Storage Server.

There is no privacy loss with onion requests (compared to a Lokinet-based implementation) because onion requests are still based on the Sybil-resistant Service Node network, and 3 hops are still taken between origin and destination nodes. The major change is the reduced complexity of the system. The onion request system doesn’t support UDP streams or exit node functionality, so implementation will take weeks, compared to the months which would have been spent making Lokinet functional on mobile platforms.

Effects on the Lokinet and Session roadmaps

The decision to move Session from Lokinet to onion requests does not affect the Lokinet roadmap. If the completion of the DHT and router discovery improves Lokinet’s stability, and we can build out the appropriate Lokinet mobile clients, then we would want to switch Session from onion requests back to using Lokinet, since Lokinet offers better ways to synchronously communicate with users, as well as allowing for potential future Session features such as onion-encrypted real-time voice chat.

So, taking all of that into consideration, how does this change affect the Session roadmap? At launch, Session will still be using the interim proxy routing solution discussed in the Session FAQ. But within weeks of launch, we will move to using onion requests, heightening both security and anonymity for all Session users. At the end of the day, moving Session’s message routing from Lokinet to onion requests will significantly cut down development time, with no negative impacts on security, anonymity, metadata protection, or user experience — the very definition of a win-win solution.

For an extended look at the new onion request system, watch Loki CEO Simon Harman and CTO Kee Jefferys explain the change on our YouTube channel.

<![CDATA[Anonymity 101: Day-to-day ways to stay anonymous online]]> 2yLqoZwbx9RS0FYsInqOUd 2020-01-22T23:00:00.000Z With global connectivity constantly increasing, the dangers of cyberattacks and identity theft are becoming more real every day — anyone who uses the internet could be vulnerable. So how can you protect yourself — and your data — on the web?

Here are 9 tips for staying more secure and anonymous online:

1. Online hide and seek

Your IP (Internet Protocol) address can be used to determine your physical location and even your actual identity. By using a VPN (Virtual Private Network) or an onion router, you can keep your identity private while browsing online.

A VPN works by encrypting your browsing data and providing you a new anonymised IP address, so your ISP (Internet Service Provider) doesn’t receive information about you or your browsing habits. VPN software is great, but you’ll need to make sure your VPN provider isn’t selling your data to third party services or advertisers. And not all VPNs are created equal when it comes to security, either— some popular VPNs, like NordVPN, have gotten into hot water for mishandling data.

Onion routers use multiple layers of encryption to conceal your online identity. When you use onion routing, your data ‘hops’ from computer to computer through an interconnected network, finding a path to its final destination. None of the computers in the onion routing network network have access to any information that can identify you. But onion routing is the digital equivalent of taking the scenic route home — it can really slow down your internet speeds.

Check out: Private Internet Access or ProtonVPN for VPNs; TOR or Lokinet for onion routing.

2. No more cookies

Cookies are used to collect information on your behaviour as you browse the internet. Websites and advertising services may use cookies to collect data that can better inform their marketing or development decisions. While some people don’t mind targeted advertisements, this kind of tracking can be considered a serious breach of privacy. Luckily, there are browser extensions that can block tracking cookies and keep your browsing private.

Check out: Privacy Badger, uBlock Origin, Ghostery

3. HTTPS rules — HTTP drools

Hypertext Transfer Protocol (HTTP) is a digital protocol designed to allow communication between web browsers and servers. HTTP communications aren’t encrypted, so it leaves you vulnerable vulnerable to both man in the middle and eavesdropping attacks. These attacks can give attackers access to web accounts, sensitive information, and even allow an attacker to force your browser to download malicious software.

Hypertext Transfer Protocol Secure (HTTPS) is an extension of HTTP, used for secure communication over a computer network. HTTPS secures you against a variety of attacks, including those mentioned above; however, HTTPS is only effective if the website hosts all its pages over HTTPS.

You can use a browser extension to automatically upgrade HTTP websites to HTTPS, to help make sure you’re always secure.

Check out: HTTPS Everywhere, Smart HTTPS

4. De-Google your life

It doesn’t matter if you’re using the Google search engine, Gmail for email, or even just an Android phone; every time you use Google services, Google stores your data — as much data as it possibly can. Google offers a lot of convenience, and giving up the niceties of the Google suite can be a real challenge.

But there are a few simple steps you can take to begin de-Googling your life:

  • Don’t use Google’s search engine — try alternatives like DuckDuckGo or Startpage

  • Avoid using Gmail when possible, try ProtonMail or Tutanota

  • Don’t use the Google Play Store, download your apps as APK files from F-Droid (an alternative app store for free, open-source software).

Check out: DuckDuckGo, Startpage, the r/DeGoogle subreddit, Mozilla Firefox, F-Droid, ProtonMail

5. Encrypted messaging applications

Lots of us have grown up using SMS (texting) every day, but SMS is actually shockingly insecure. Attackers could contact your mobile service provider and impersonate you, then port the number from your SIM card  to a SIM card they control. This is especially dangerous if you’re using SMS-based 2FA to secure important accounts or information.

Luckily, encrypted messaging apps can help you steer clear of the downfalls of SMS. End-to-end encrypted messengers let you send messages, attachments, and more without exposing your conversations.

Using an encrypted messenger isn’t always enough to keep your identity safe, though. Even if messages are encrypted, requiring identifying information to create an account can potentially leave you vulnerable. A good encrypted messaging app won’t need a phone number or email address to register an account.

The best encrypted messengers also won’t have central servers. Apps with no central server give you the peace of mind that the company behind the app can’t spy on who you’re messaging, or when.

Unfortunately, there are often compromises on some or all of these points when picking a new messenger.

A few options: (underline = benefit, bold italics = security issue)

Signal (encrypted, phone number required, central server), Session (encrypted, no phone numbers, no central server), Wire (encrypted, no phone numbers, central server), Threema (encrypted, no phone numbers, central server)

6. Delete your files — for real

Did you know that when you delete files from your computer, they’re not really gone? Have you ever deleted files from an SD card only to be told the card is still full? The usual Delete functions on computers and phones often leave parts or traces of the file behind.

File shredder software was developed to delete files from a computer — permanently. Typically, deleting a file only hides it from the operating system — meaning that with a little bit of know-how, the file can be recovered.

A file isn’t truly gone until that same storage space has been overwritten with something else, and then deleted. This is where file shredder programs come into play. File shredders overwrite deleted files with random sets of data, making the original deleted file(s) completely unrecoverable.

Check out: Eraser, WipeFile

7. Password variety

Using difficult (and unique) passwords for each of your online accounts is a great way to keep your accounts secure. This way, even if one of your accounts is compromised, the attacker can’t use the same login credentials (email and password) to get into your other accounts.

Curious to know whether any of your accounts have been compromised? Try haveibeenpwned.

Password manager browser extensions do a great job at producing randomised passwords to use when creating a new account, allowing for easy storage and access to your difficult to crack passwords.

Check out: LastPass, 1Password, or Dashlane. If you’re on macOS, you can also try Safari’s built-in secure password generator.

8. Two-factor authentication

Two-factor authentication (2FA) requires a user to provide extra evidence they’re who they claim to be when trying to log in. This extra evidence usually comes in the form of a one-time secondary password to enter in addition to the usual account password.

The most common form of 2FA requires you to enter a one time-password that is either generated by an app, or sent to an email or phone number associated with the account; however, hardware-based 2FA is also possible.

Check out: Microsoft Authenticator or Authy; for a hardware-based solution, try Yubikey, Titan Security Key, or U2F via Ledger / Trezor devices.

9. Lock it up

The simplest tip in this list: Make sure your phone or computer cannot be accessed without entering a passcode or passing a biometric scan. Much like 2FA, a passcode or biometric scan adds an additional layer of protection against attackers.

Not all smartphones feature biometric scanning capabilities, but all smartphones let you enable a passcode lock for your home screen.

Most smartphones also come with an optional setting to wipe all data on the phone after a certain amount of incorrect login attempts. This keeps your phone safe from brute-force attacks, where an attacker tries every possible passcode combination to break into the phone. This kind of security measure is important for making sure your personal data doesn’t fall into the wrong hands.

Check out: Locker, Complete Wipe, 1 Tap Eraser

Staying private online isn’t always easy. You can’t flip a switch and instantly have complete privacy. If it was that simple, everyone would do it. Online privacy and security does take some work, but it’s easy to take the first steps towards protecting yourself online. Each of the things on this list will bring you one step closer to real privacy and security online. Don’t overwhelm yourself — take it one step at a time. Switch to a more private messenger, put a passcode on your phone, or make the move away from Google services — they’re all important steps towards staying safe online.

<![CDATA[Dev Diary: Creating a decentralised friend request system]]> 2aeYgor7E5oHv11AKU8FAq 2020-01-15T23:00:00.000Z Session is designed to be privacy first — decentralised servers, no phone numbers, the whole lot — but that creates some problems. Like, how do you let users exchange encryption keys and establish a chat ‘session’ (wink, wink) as quickly and smoothly as possible?

Session was originally a fork of Signal, but we wanted to improve upon some of Signal’s inherent vulnerabilities. When you use Signal or WhatsApp, your phone number is used to identify you. It’s how your friends know that it’s really you when they send you a message.

When you register your phone number on Signal, you upload several pre-key bundles to Signal’s servers. Once someone adds you as a friend, the server can then hand out your keys — even if you’re offline. The person adding you can then immediately establish an encrypted chat ‘session’. Using phone numbers and central servers makes exchanging encryption keys (and communication) super easy, but it compromises user privacy. For example, it’s very easy for your phone number to be hacked, sim-swapped, or for your provider to reassign your number to another person or account

We didn’t want to make this compromise — user privacy is our core mission.

Where centralised messaging apps like Signal and Whatsapp collect, store and distribute keys when users receive friend requests, Session uses decentralised servers — so we needed to find a way to do this asynchronously.

MISSION: To design a ‘friend request’ system without using phone numbers, in order to establish a Signal protocol session in an asynchronous network.

Signal’s friend request system uses something called the Diffie-Hellman Key Exchange protocol — and so does Session’s, but we had to make some modifications.

The Diffie-Hellman protocol allows you to generate a shared secret. This shared secret is made through a sequence of concatenated keys — a sprinkle of your secret key, a dash of your receiving partner’s secret key, and a final splash of an agreed public key.

Check out this diagram to understand it better:

  1. Alice has Secret Key A and Bob has Secret Key B.

  2. Alice and Bob both agree to use Public Key C.

  3. Alice mixes A and C (AC) while Bob mixes B and C (BC).

  4. They share these results with each other.

  5. Alice then mixes A with BC (ABC) and Bob mixes B with AC (ABC) so they both come to the final key.

Note: Anybody listening to the communications would see C, AC and BC, but without seeing A or B alone – they cannot get to the final key, ABC.

Basically, Diffie-Hellman allows you to create a new secret key together. This method of encryption allows Alice and Bob to decrypt and read their messages easily without anyone else snooping.

Signal uses a protocol called the Extended Triple Diffie-Hellman, in which a sequence of these Diffie-Hellman shared secrets are generated and bundled up — into something called a ‘pre-key bundle’. People in conversation can use these pre-key bundles to mutually authenticate each other.

When you use Signal, you will generate a large amount of these pre-key bundles and store them on Signal servers. This way, if somebody wants to try and message you, they can immediately initiate a session, because Signal can provide a pre-key bundle.

But, because Session is decentralised, it doesn’t have servers for this kind of storage, which is extremely tricky to get around. Basically, this means there’s no way for a sender to know that the receiver has got their message until they respond. Establishing a session requires certain encryption primitives, so you need to be certain that both parties have the correct keys (and enough of them!) otherwise they won’t be able to read each other’s messages.

When you send a friend request in Session, you’re not just sending one Diffie-Hellman key — you’re sending four. Using ephemeral keys — which are one time use public keys, designed to be deleted once they’ve been used — you can make pre-keys that allow you to continue sending messages once the session has started.

These 4 keys are then bundled together using a key derivative function, forging one key to rule them all.

Finally, you can send this single pre-key bundle (the one to rule them all) as a friend request.

A few other messages need to be sent before all parties agree that the session has begun, and also agree on its parameters. To better understand this, let’s go back to Alice and Bob:

  1. Alice generates a pre-key bundle and sends it to Bob as a friend request

  2. Bob generates his own pre-key bundle and mixes it with Alice’s, initiating a session on Bob’s end.

  3. Bob then sends an empty message back to Alice with his pre-key bundle attached in the background. Note: Public keys are being sent in this step, but it’s still encrypted.

  4. Alice receives Bob’s keys, and mixes them with the ones she sent him earlier, initiating the session on Alice’s end. Note: Alice knows the session is valid IF she can decrypt Bob’s empty message.

  5. Alice confirms that the session is established on her end by sending an empty message back to Bob encrypted as a standard protocol message.

  6. Once Bob receives this message, he knows the session has been established.

The intricacies we needed to work out involved modelling the state of the exchange on both ends, and being able to smoothly recover any lost messages — without sacrificing on UX.

Contrast this with Signal’s protocol. When you friend request someone, they’ve prepared a bunch of pre-key bundles which are stored on Signal’s servers. So you never need to contact your new friend directly — you just need to communicate with Signal’s servers.

Session doesn’t have this luxury. Its decentralised design means you can’t have a bunch of pre-key bundles ready to go — they have to be created and sent peer to peer when you establish a chat session.

It wasn’t easy. We came back to this problem 3 – 4 times over several months, And it took a few iterations. We’d think we’d reached a solution, then a month later we’d discover an ‘edge case’, and need to keep revising.

This sounds exhausting but the truth is, our solutions became more ironed out — they just got better and better.

<![CDATA[Confirming identities online]]> 7CRpEdFpj7lLtET7WCnJNo 2020-01-09T23:00:00.000Z How to inspect who you’re expecting

Staying private, secure, and anonymous online is important for everyone — but for some, it can be crucial. However, total anonymity can also introduce some problems. When you’re communicating anonymously, how do you know you’re talking to the person you think you’re talking to? If a whistleblower is sending a journalist some confidential info, the whistleblower needs to know beyond a shadow of a doubt that they’re really talking to their contact, not an imposter.

So how can you stay private — and anonymous — while verifying someone else’s identity?

In person, there are lots of ways that you might try to do this, like using code phrases, secret meeting places, and disguises.

But things are very different when you’re online. Everything you do can leave a trail, and there’s lots of information about you that could betray your true identity. IP addresses, digital fingerprinting, and information linked to your real identity — like phone numbers — can all be used to work out who you are.

So, what can you do? Well, for starters, it’ll come in handy to know about something called PGP. PGP stands for Pretty Good Privacy, and it’s a kind of encryption that can be used to put a lock on otherwise unprotected information.

PGP allows you to encrypt a message so that only one person, with the exact digital key that matches the message, can ever read it. PGP is often used to encrypt e-mails, messages, and files. But PGP doesn’t always provide total security and anonymity. For example, if you send an email encrypted using PGP, the sender, receiver, and subject line of the email are left unencrypted — making them visible to the email provider, and possibly others.

Alternatively, you can use an encrypted messenger. Some encrypted messengers will allow you to stay totally anonymous while you talk. In any good encrypted messenger, only the person you’re chatting to has the key to unlock (and read) the messages you send them — just like PGP.

Some messengers might try to get you to tie a piece of personal information to the account — like your name or phone number — so that others can confirm your identity. But this is risky, because phone numbers introduce serious privacy threats — and they’re definitely not anonymous.

However, there are encrypted messengers that won’t expose your identity. Some allow you to use keys (similar to PGP keys) as your account ID or ‘username’. These kinds of account systems let you avoid tying your real-life identity to your account ID.

This type of system has a number of benefits for staying safe, secure and anonymous. But this anonymity sword cuts both ways. If you’re using an encrypted messenger with a key-based account system — like Session — there is no way to be completely sure that an account you’re chatting with belongs to the person you think it belongs to.

This is by design — after all, the goal is secure, anonymous communication. However, if you also need to be doubly, triply sure that you’re talking to the right person, you may need to use a secondary channel of communication to verify that the account you’re chatting to actually belongs to the person you’re trying to contact.

This might involve communicating with your desired contact via a secondary means to trade keys. When in-person contact isn’t an option, one of the safest alternatives is Secure Drop. If you want to send information this way, here’s how you can do it safely.

When you want to communicate anonymously, it’s really hard to ever be 100 per cent sure who you’re talking to. But, then again — that’s kind of the point. Verifying who you’re communicating with online is still super important — encryption won’t always protect you from sending something to the wrong person. Make sure you always verify who you’re talking to online before you start sending sensitive information!

<![CDATA[How to make an anonymous tip — and stay safe]]> 2vvNylNQMzOp0wYGXYmYhn 2020-01-06T23:00:00.000Z Whistleblowers are needed to make sure that information which is in the public interest reaches the public. Whistleblowers have been critical in uncovering major stories like the Panama Papers, Watergate, and the Pentagon Papers. But, whistleblowers have long been plagued with the first contact problem. Most of the time, if you get in touch with a journalist, they will know how to secure and anonymise your communications. But, by the time you get in touch with a journalist, it’s possible that a lot of information has already leaked. Potentially, enough info to ID a whistleblower.

If you have a tip, there are some things you should do before you even think about contacting a journalist.

Do not!

Caution: Identifying data. Handle with care.

  1. Call or text. Calls and texts are unsecured lines of communication. As soon as you text or call a journalist, you have created a direct and unsecured line of communication, and it is easy to connect you to a leak.

  2. Send an email. By default, emails are unsecured. Even if you do use encrypted email, it most likely uses PGP — meaning the email’s subject line and the name of the sender are visible. Once again, this creates a direct line of communication between you and the journalist.

  3. Drop a letter off at the post office. If you really want to send a letter or package to a news organisation in the mail, use a post box. This will help you stay anonymous.

Every step of the way: anonymous tips

Would you be suss if Jim from accounting suddenly started surfing the darknet?

Remember, no system is guaranteed to be one hundred per cent secure. Nearly all digital communications can leave some kind of trail. What we are outlining is for situations where it is essential that you stay anonymous. In a lot of cases, you might only need to follow a few of these steps to make your tip and stay safe.

  1. You have a tip. Make sure you keep it to yourself.

  2. Get a VPN. Getting a VPN — a virtual private network — is a fairly run of the mill thing to do. It shouldn’t raise any flags for you to sign up to a VPN — but make sure you get a reputable provider. Some VPNs may log or store your information, largely defeating the purpose of getting one in the first place. For extra security, use a public internet connection — like one at a library — to sign up for the service. This way it will be hard to even prove that you got a VPN at all.

  3. Get an onion router. Onion routers help you stay anonymous on the internet. They are a little complicated, so check out our article on onion routing for more info on this one. Make sure that whenever you’re researching or downloading onion routing technology, you are using your VPN.

  4. Make the drop. Once you are using an onion router, you are as safe as you’ll ever be to actually make contact with a journalist. If you use a service like SecureDrop, you can strip messages and files of metadata and then share them with a journalist.

Extra things to consider

No, a tin foil hat is not one of them

The steps above will help to limit the trail you leave behind when you’re online, but sometimes there is more to consider.

  1. The device you use. You might want to get a device that isn’t associated with your identity. Your work and personal devices probably have information on them that will tell anyone looking at it that it’s your device. Getting a burner device to make the tip, and getting rid of it after you’re done is one option. But, if you don’t want to go to those lengths, you can still delete any files that connect you to the leak as soon as possible.

  2. The operating system you use. Some operating systems respect your privacy more than others. Using an operating system like Tails, which is private by default, can help prevent your operating system from accidentally leaking data.

  3. Use a metadata scrubber. Metadata scrubbers are programs that remove metadata from files. This way, you can remove metadata from your files before you upload them or send them to anyone else. This is safer than relying on metadata to be removed or obfuscated after you’ve already uploaded it to the internet. Some operating systems — like Tails — include metadata scrubbers.

  4. Switch to a private messenger. Sending messages back and forth over SecureDrop might not be convenient. Instead, you could leave a point of contact — like your Session ID — to enable secure and anonymous communication.

<![CDATA[Session and Australia’s Laws to Circumvent Secure Communications]]> 17KsQ0NqfUzHd0v0QNl3L6 2020-01-01T23:00:00.000Z Governments around the world are seeking backdoors to access encrypted communications, and building secure tech infrastructure and tools, such as the Session messaging app, has meant that we have kept a very close eye on the evolving laws that aim to govern the work we do and the products and services we are creating.

Rest assured – the Session messenger and the underlying Loki Network is secure. There are no backdoors. The code is open-source, so anyone can see how it works and make sure there’s no malicious surveillance happening.

Australia’s controversial Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018 does give authority to a number of government agencies to provide ‘designated communications providers’ with ‘technical assistance requests’ or ‘technical assistance notices’.

What this means for example, is that Australia’s intelligence services can compel Loki to develop tools that can be used to investigate specific targets. However, what is most important is that the request or notice cannot force Loki to build or install “a systemic weakness or systemic vulnerability” in to our network or our products.

The Session messenger is permissionless. There is no immediate way for us or anyone else to know the identity of our users. Because of the network’s open nature, any party can easily gain access to it and request all kinds of information. This includes us, intelligence agencies, or any other curious party. However, because it is all end-to-end encrypted, and uses onion routing to store and retrieve messages, no one is able to piece together who is talking to who or what is actually being said.  Technical assistance notices don’t make a lot of sense in the context of Session or the Loki Network, as we, nor anyone else has the ability to identify users and decrypt their messages.The only way requests or notices would be useful to anyone is if we were to introduce a systemic weakness, which we can not legally be compelled to under current law.

Session has access to lawyers and works closely with industry partners and digital rights groups to ensure we are on top of the law and also working with our peers to advocate for laws that protect users and give confidence to the tech industry in relation to data encryption and digital privacy.

We understand the double-edged nature of the secure communications tools we are building, but as many others have argued and pointed out, the right to freedom of expression and privacy is vital for a healthy democracy, and it is something we will continue to promote and defend.

<![CDATA[Freelance journalism: Who's got your back?]]> 6sNtFmRhOVsoXA5VrARI1d 2019-12-30T23:00:00.000Z Journalists are often searching for and publishing things that someone wants kept quiet. This is good, of course — it’s what journalism is for. A free press doesn’t work to keep people happy, it works to keep people accountable.

It can be shockingly easy for journalists to end up in court, especially when they’re covering crime and grime. Most journalists can rest easy knowing that their publication will have their back if anything goes sour. But freelancers don’t necessarily have the same protections.

Sometimes you’ll get a good egg, like when The Huffington Post backed up freelance contributor Yashar Ali in 2017. Ali was hit with a $50 million defamation lawsuit over his reportage of sexual harassment allegations against ex-Fox News host Eric Bolling — and the summons omitted any mention of HuffPost. Ali believed that this may have been to target him personally. The allegations were never proven, but the Huffington Post stood by Ali’s reporting and promised to support him in his legal battle.

But, depending on your work contract, this kind of support might not be guaranteed, and not all news organisations will be so chivalrous. The reality is, if someone out there is in a litigious mood, freelancers can present an easier target than publication-backed journalists.

So what can you do?

Staying organised, private, and secure as a freelancer

Keeping all your sources and communications secure and organised will go a long way.

Freelance journalists don’t get the same institutional support to maintain their digital security. There are no company firewalls, computer technicians, or lawyers watching over your shoulder while you work — so you gotta cover yourself.

Making sure you keep minutes or record your interviews. Keeping an archive of these things even long after the story you publish the story is always a good idea too. Make sure it is stored securely — and that means no cloud storage. Remember the rules of proper data storage: at least three copies, on two different types of storage (internal hard drive, USB), and two different locations. This will help protect you from data loss. And of course, make sure whatever storage solution you use is encrypted and password protected.

If you’re communicating or reporting digitally, make sure you are always using an encrypted messenger (in case you missed it: how to pick a good encrypted messenger), and an encrypted email provider. This will help protect you from hacks, source leaks, and information leaks that are out of your control.

For large news publications, it can be hard to keep up to date with the most ‘private’ messaging and email providers. The latest and greatest can change quickly, and getting the whole office to switch over is time consuming and impractical. But as a freelancer, you have an advantage: you don’t have to convince a whole office to start using a new technology — you just have to make the switch yourself.

And of course, you’re not just protecting yourself by using encrypted communications — you’re protecting your sources too.

Get specialised insurance that covers the perils of journalism

Newsgathering and publishing can get you into some unusual situations. If you’re working as a freelance journalist, you should choose an insurance policy that covers problems specific to working in the media. Sometimes, publications cover their freelancers in their own insurance policies — but not always, so it’s worth checking.

The best policy for you will depend on where you’re working, but you’ll likely want the policy to include things like breach of privacy, defamation, libel, copyright infringements, and factual errors.

When you’re negotiating a contract, most publications worth their salt will agree to take on the liability of your work as a reporter. If they don’t, it’s definitely worth trying to get your own insurance policy to avoid ending up in litigation hell.

Freelancers can have access to legal advice, too

If you’re working for a large news publication, they might have a legal team on-staff. These people know the ins and outs of media law, so if you have access to these people — use them. They can comb your copy and make sure that it is absolutely air-tight.

If you don’t have access to one of these teams, it is possible you can still access legal advice without having to pay through the nose for it. Foundations like the Reporters Committee for the Freedom of the Press can help you sidestep any legal landmines. But, be careful — you don’t have attorney-client privilege when you contact legal hotlines, so don’t send anything confidential.

Freelance journalism doesn’t need to be scary

Freelance journalists have all the same problems as every other journalist — plus a few more. Although there are extra challenges that come with being a freelance reporter, there are lots of ways to protect yourself. And taking just a few steps to prevent the lawsuit apocalypse from arriving at your front door can help you focus on the scoop, not the suit.

<![CDATA[Onion routing: Private messaging’s missing link]]> t8uSmYm8RDyHpmzSdMSWb 2019-12-25T23:00:00.000Z End-to-end encrypted messaging apps are popping up left and right, but finding the most private and the most secure can feel like a game of Whack-a-Mole — with your online privacy at stake.

Every private messaging app has its pros and cons, but there’s a crucial ingredient missing from their security salads: onion routing.

End-to-end encryption

The gold standard — with a glaring flaw

Traditional end-to-end encryption schemes (like those used by Signal and WhatsApp) are highly secure, and prevent anyone from snooping on the contents of messages being sent over the internet.

But traditional encryption has a pretty big weakness: Hackers might not be able to read messages in transit, but they can still tell who’s talking with whom.

Let’s say we have two people, Alice and Bob, talking to each other using an end-to-end encrypted messaging app. Every message Alice sends to Bob (and vice versa) is wrapped in a secure layer of encryption from the moment it leaves Alice’s phone to the moment it arrives on Bob’s.

If someone else — let’s call her Eve — is able to intercept a message in transit, all Eve sees is a garbled mess of encrypted data. Great!

The problem is that even with end-to-end encryption enabled, an observer can still see some information about Alice and Bob. Depending on who Eve is, she can figure out that Alice is messaging Bob by snooping on the traffic moving through the network. Eve could use temporal analysis to identify that since Alice’s phone is sending messages, and Bob’s phone is receiving messages a few moments later, Alice is probably messaging Bob. Eve could also figure this out by gaining direct access to the messaging app’s central server, which would let her see every conversation being conducted using the app.

This is because while end-to-end encryption protects messages in transit, it does nothing to stop someone from discovering who is talking to whom.

Imagine if you were trying to have a private phone call with your partner, but every time you picked up the phone, someone on the other side of the world could figure out you two were talking with just a few keystrokes. Sure, nobody knows exactly what you two are saying — but that’s still not very private, right?

Onion routing

Salad-powered security

Onion routing is a technique for sending data anonymously over a network. Unlike traditional encryption schemes, onion routing doesn’t just stop someone from reading or intercepting data. By using multiple layers of encryption and bouncing messages through multiple servers before they reach their destination, onion routing stops observers from being able to tell who’s talking (i.e. sending data) to whom.

So how does that work, then?

Let’s go back to Alice and Bob. Imagine Alice wants to send Bob a message, but she doesn’t want Eve to know that she’s messaging Bob at all. Instead of opening Signal or WhatsApp, Alice fires up an onion-routing enabled messaging app like Session.

Alice fires off her message:

>Imagine if Eve knew we were planning her surprise party right now!?

When Alice hits send, the Session app encrypts her message twice, then passes the message to Lokinet, which encrypts it 4 additional times (Wondering why 4? We’ll come back to this later). Each layer of encryption is wrapped on top of the others, forming an ‘onion’ of encryption layers, with the message at the centre.

This ‘onion’ message is then sent to a Loki Service Node. This node decrypts one layer of encryption, then passes the message to another service node, which decrypts another layer — this process is repeated 4 times, once for each layer of encryption applied to the message after it left Alice’s Session app. Finally, when the message arrives on Bob’s device, Bob’s Session app decrypts the final two layers of encryption, and Bob reads the message.

The really cool part? Each service node involved in this message-passing chain only knows about the service node it received the message from, and the node it passed the message to. The first node in the chain knows that Alice sent a message, and the last node knows that Bob received a message. But no service node in the chain (and no outside observer) is able to connect the dots and figure out that Alice is messaging Bob.

Onion routing isn’t a perfect solution; an attacker could theoretically use temporal analysis to link Alice and Bob together. However, onion routing — especially when used in combination with a decentralised network structure — makes this type of attack significantly more difficult.

Level up!

Most modern messaging apps offer at least some kind of encryption, and the more secure options, like Signal, are end-to-end encrypted by default. But all this encryption doesn’t really keep your communications private when someone else can still tell who (and when) you’re messaging!

Onion routing gives your private conversations a whole new level of security.

Using an onion routing-enabled private messaging app, you can DM and DnM to your heart’s content — confident that no snooping spectators are watching.

End-to-end encryption is great for communicating securely, but even if you’re using it, an attacker can still tell who’s talking to whom — even if they can’t see what’s being said. Onion routing protocols, like the one Session uses, encrypt your messages multiple times and bounce them between several servers before they reach their destination. This stops attackers from knowing who you’re talking to, as well as what you’re saying!

<![CDATA[Centralisation vs decentralisation in private messaging]]> 6zakxEIMJQBuubVIbmyhyi 2019-12-22T23:00:00.000Z What are they — and why should you care?

End-to-end encrypted (E2EE) private messaging apps are secure, but in today’s world, end-to-end isn’t enough.

Many secure messaging apps have a fatal flaw: centralisation.

Centralisation and centralised networks in private messaging

It’s all about trust, baby

In a nutshell, centralisation means that a system (or a network) is controlled by a central authority. Governments are a real-world example of centralisation. The government acts as a central authority for the country it governs: passing and enforcing laws, managing relations with other countries, and making other decisions that affect the country as a whole. The central government acts as a proxy for the population at large, making decisions on behalf of the country. A centralised system like this is also known as a trusted system: participants need to trust that the central authority will act in the best interests of the network. In the case of a government, the citizens need to trust that the government will make decisions that are in everyone’s best interests.

Centralisation is also common in computer networks. Every computer network is a set of linked nodes: computers or other devices that store and share data. In a computing context, centralisation means that a network of nodes is controlled and governed by a central server. While this may sometimes be a single server, a central server can also refer to a central cluster of servers.

There’s also another layer of centralisation at play here: if the network relies on a central server to function, the entity (company, group, etc.) which controls that server is effectively in absolute control of the network.

Just like a government managing a country, a central server manages the network. It controls the flow of data, decides which devices are allowed to connect and transfer data over the network, and performs other duties to keep the network running. This kind of network is also a trusted system: just as in the case of a government, users of the network must place their trust in the central server to manage the network safely and responsibly.

Many E2EE messaging apps rely on a centralised server to route messages from sender to receiver. Think of the central server as a very, very busy postman. The server receives messages, then passes them to their intended recipient — hundreds or even thousands of times per second. And yet, believe it or not, the main reason many messaging apps structure themselves this way is efficiency.

The pros of centralisation in networking and private messaging

A shortlist — and a short list

Centralised systems have three main benefits: efficiency, ease of maintenance, and consistency.

Returning to our government metaphor, it might seem like governments take a long time to make and act on decisions — but imagine how long it would take if every single person in the country had to have their say on every decision! Having a central authority (or central server) in charge of everything keeps the network running smoothly. Because the central server knows exactly where each message is coming from, and where it’s heading, the server is always able to deliver messages efficiently.

Centralisation can also make it easier for network administrators to keep the network running smoothly. If administrators need to apply critical software updates or security patches, those patches only need to be applied to the central server, and hey presto — all done. Upgrading the hardware in the central server can also upgrade the performance and capabilities of the whole network.

Finally, centralisation makes it easier to keep data synchronised across the network. Because all your messages are synced with a central server, that server can help to ensure that chat histories are consistent across devices, and that messages are delivered reliably.

The cons of centralisation

Putting the con in concentrated data

Centralisation’s greatest strengths are also its greatest weaknesses. Remember how centralised systems are also known as trusted systems? Well, there’s the problem.

When you participate in a trusted system, you have to trust that the central authority which controls that system will act in your best interests. In a democracy, you can cast a vote to have your say over how the system — the country — will be governed. But in the case of a centralised E2EE messaging app, you have no say over who is in control — or the actions of the central server itself.

This trust requirement has some serious privacy and security implications for private messaging. End-to-end encryption means that no-one but you and the person you’re messaging can read your messages. But because the central server is responsible for routing messages from sender to receiver, the server needs to know their digital identities or addresses. The central server also could have access to all the other metadata associated with an E2EE conversation: IP addresses, times, dates, locations and more. The central authority controlling this server could keep logs of all this metadata. As a user of a centralised E2EE messenger, you have to trust that the central authority won’t do that.

But that’s not a problem, right? Companies never act against the best interests of their users… right?

Even if the company in charge doesn’t want to violate your privacy, the simple fact that it’s possible to do so creates more issues. Governments or other third parties could compel the central authority to log conversations and hand over metadata against their will. And if a malicious third party is able to get access to the central server — through hacking, social engineering or otherwise — they’ll also have access to all that metadata. If you’re serious about privacy, you have to assume that if metadata can be collected, it will be collected — and potentially misused.

There are other issues, too. If something happens to the central server, the whole network goes down, along with the services it provides. If the central server falls victim to a natural disaster or a power outage, you can kiss the entire service goodbye. And if there’s a critical bug or flaw in the server’s software, it could affect the entire network. This disastrous scenario has been seen over and over again — recent examples include the February 2017 AWS server outage that took down Trello, Quora and IFTT, and the September 2019 server failures that took Facebook and Instagram offline for several hours.

Centralised E2EE messengers are also highly vulnerable to censorship. Although the app encrypts all messages, making them unreadable by the central authority — this means the authority can’t ban or block messages about specific topics — central authorities can still ban users,  groups, or even regions from using the app. This problem is worsened if the app uses an identifier tied to your real-world identity, like a phone number or email address.

Centralisation might be efficient, but it sucks for privacy and security. You’ve probably figured out by now that we have a solution waiting in the wings.

So what’s the alternative?

A decent solution to an indecent problem.

Decentralisation is exactly what it sounds like: the polar opposite of centralisation. Control is distributed between participants in the system, rather than being held by a central authority. The government of a democratic country is a centralised authority, but the people put that government into power through a decentralised process: voting.

In decentralised computing, instead of a network being governed by a central server — and controlled by a central authority — control is held by a distributed network of nodes (servers). These nodes make democratic decisions about the network, with all (or some, depending on the protocol) nodes “having a say”. This collective works together to handle tasks like data traffic routing and maintaining network security.

Where centralised systems are referred to as trusted systems, decentralised systems are known as trustless systems. This might sound like a bad thing — trust is good, right? — but in a security and privacy context, trust is dangerous! In a trusted (centralised) network, you have no choice but to trust the central server — and the central authority which controls it. A trustless (decentralised) network is set up in such a way that you never need to trust a central authority to make the right decisions.

So how does decentralisation benefit E2EE messaging apps? Well, it addresses virtually all the pain points of centralised messaging apps.

The most secure decentralised end-to-end encrypted messaging apps send messages by routing them through a random selection of nodes on the network. The set of nodes being used changes with every new message. If a malicious node was trying to collect data about users’ messaging activity, it could only do so for messages relayed directly through it — a tiny fraction of the total message traffic on the network. Onion routing protocols add additional layers of security by encrypting a message multiple times, once for each server it passes through on its way to the destination. If onion routing is in use, malicious servers can’t even track messages passing directly through them, as they are only aware of the node before and after them in the chain.

A decentralised, end-to-end encrypted messaging app is trustless because you do not need to place your trust in anyone when using it. You know that your conversations are anonymous and secure — no trust necessary.

Decentralisation makes it impossible for third parties to compel the network’s creator to provide information about users, because in a fully decentralised system, the entity which created the network does not have the capability to collect that information. Decentralisation also significantly limits the data a malicious third party could collect if they attempted to hack into the network. An attacker would need to gain access to the vast majority of nodes on the network to collect any specific user’s conversation data — much more challenging than just hacking into a central server.

Because decentralised networks don’t rely on a central server, the network is unaffected if unforeseen circumstances cause nodes to go offline. The network will simply route messages through other, unaffected nodes. This makes decentralised networks far more resistant to natural disasters and power outages.

Decentralised networks are also far more censorship-resistant than centralised networks. A messaging app based on a centralised network is vulnerable to censorship: the central authority can ban users at will. On a decentralised network, users can’t be banned or otherwise targeted because there’s no controlling authority which could target them — and if the decentralised network is using onion routing, users are completely anonymous, adding another layer of censorship resistance to the network.

Decentralisation: The future of truly private messaging

Decentralise your digital life

So, when all’s said and done, how do centralised and decentralised messaging apps stack up?

Centralised encrypted messaging apps are trusted systems. Users have to trust that the central authority won’t act in bad faith by collecting conversation data for themselves or for third parties. Centralised systems are vulnerable to software or hardware bugs and other failures. If a disaster takes down the central server, the whole network goes down. Central servers make it simpler for malicious third parties to hack into the network. And as if that wasn’t enough, centralised systems are vulnerable to censorship. If the central authority decides to ban you — or if a third party pressures them to do so — there’s nothing anyone can do to stop it.

Decentralised encrypted messaging apps are trustless systems. You don’t need to place your trust — or your privacy — in the hands of a controlling entity when you use a decentralised messaging app. There is no central authority to collect, sell or give away your conversation metadata, and if the messaging app is using onion routing, the decentralised servers can’t collect any data either. Decentralised systems can tolerate losing servers to software bugs, hardware failures or natural disasters. Finally, decentralised networks are censorship-resistant by design. There’s no central authority making decisions about who can use the network — so there’s no chance of users, groups or countries being blocked, banned or censored.

You can never trust centralised networks to be private, secure, or safe from censorship. Decentralised networks remove trust from the equation completely.

<![CDATA[What can someone do with your phone number?]]> 7LabfHsBKYGqJHbE7DNoUj 2019-12-16T23:00:00.000Z The dangers of phone numbers in the digital age

Have you ever noticed how closely your phone number is tied to your identity these days? We use our numbers to swap contact details, talk and text, and confirm and authenticate who we are online. Consider how many apps you have that now require you to ‘level up’ your security using SMS-based two-factor authentication.

Here’s the problem: phone numbers were never meant to be anything more than user identifiers for the telephone network. Many aspects of our digital lives now hinge on our mobile phone numbers. We get plenty of benefits from this arrangement: convenience, simplicity, and — supposedly — security. But there are some crucial risks and dangers you need to be aware of before tying your phone number to your online identity.

SMS security issues

There’s a hole in my two-factor, dear Liza, dear Liza…

When you make an account using your phone number, or add your number to set up two-factor authentication, you get a text with a verification code. We all know the drill: Punch in your mobile number, wait a few seconds, type in the six-digit authentication code and away you go.

But did you know that the system which delivers those codes is shockingly insecure?

SMS (text) messages are part of the GSM telecommunications standard. GSM was first deployed in the early 1990s, making it almost twenty years old! This venerable communications standard has held up surprisingly well, considering how quickly standards and protocols become obsolete in the fast-moving world of technology.

However, GSM has some serious security vulnerabilities that affect the security of SMS.

GSM data traffic between a mobile phone and a service provider is encrypted using the A5/1 and A5/2 stream cipher encryption algorithms, and the A5/3 block cipher encryption algorithm.

Stream ciphers turn each character in a message into another random character, and the receiving device uses a special key to reverse this process.

Block ciphers do the same thing, but with whole blocks of information rather than one character at a time, which lets them use more complex encryption for each block of encrypted information.

This sounds great — except for the fact that A5/1 and A5/2 were developed in the late 1980s, and A5/3 was developed in the late 1990s. Since then, hackers have demonstrated a number of ways to break all three algorithms. The much less secure A5/2 has since been retired, but A5/1 and A5/3 are still vulnerable to a number of attacks that make it possible for people to intercept and read SMS messages before they reach your phone.

So what does this mean for you?

All of your accounts that rely on SMS-based two-factor authentication are using a twenty-year-old communications protocol, secured by twenty- and thirty-year-old insecure encryption schemes, to keep people away from your personal information.

Yeah. We’re gonna say it. That’s not good enough anymore.

SIM swapping

Who ya gonna call?

So we know that SMS isn’t the most secure protocol in the world. So what? It still takes some serious technical knowledge and skill to hack into your text messages — right?

Not exactly.

Sometimes, hacking your account is as simple as knowing who to call.

The easiest way for someone to get access to your mobile number doesn’t involve firing up a command line and hacking like a madman. Instead, attackers exploit the weakest link in these security scenarios: people.

The most secure account password in the world is useless if someone can convince you — or the company your account is with — to give it up. People trying to gain access to your accounts can contact the account or service provider and convince the company that they’re you. The company then gives the attacker access to your account — they’re ‘you’, after all. This tactic, known as social engineering, is the first (and often the most reliable) tool in any hacker’s toolkit.

Social engineering can be used for all sorts of things, ranging from harmless to nefarious. Famous — and notorious — security researcher Kevin Mitnick used social engineering to get unlimited bus rides in Los Angeles by convincing a bus driver to tell him where he could get a  punch card machine (used for validating bus tickets). Mitnick was just 12 years old at the time. In a less amusing case, the Badir brothers — three Israeli brothers who were blind from birth — set up a six-year-long phone scam ring that brought in more than US$2 million, all by convincing their victims that they were operators at a nonexistent long-distance phone company.

When it comes to mobile phones, it’s often much easier than you might expect to hijack a phone number using social engineering. This kind of hijacking is referred to as a SIM swap attack. Here’s how it works.

  1. First, a malicious actor puts a blank SIM card into a burner phone.

  2. They call up your mobile service provider and trick them into thinking they are you, through a combination of lies and manipulation — social engineering.

  3. Your mobile service provider then transfers your mobile number to the attacker’s blank SIM. Now, all your texts and calls — including 2-factor authentication codes — are sent straight to the attacker’s phone. Instant access to your emails, bank accounts, cloud data and even your playlists!

Mobile service providers already have protocols in place to make it quick and easy to transfer a number from one SIM to another. These transfer systems exist so that if you lose your phone (or your SIM), you can quickly get back up and running using a new SIM.

Cell phone provider number recycling

The accidental hack

SIM swapping is a huge security issue — with a single phone call, your number can end up in someone else’s hands. But sometimes phone numbers change hands without anyone doing anything malicious at all. Have you ever received a text message from someone thinking you were someone else? It’s likely they’ve fallen victim to phone number ‘recycling’.

Phone providers regularly terminate inactive mobile phone numbers, putting those numbers back into the pool of numbers that can be given to new accounts. Sometimes, this recycling deadline can be as short as 90 days — meaning if you don’t pay your phone bill or show activity on the account within 90 days, the provider could recycle your number and hand it over to a new customer.

Number recycling can lead to some awkward situations: anybody trying to contact you on that number will end up texting a stranger. But even worse, if your number’s new owner tries to use the number to create an account with an app or website that you’ve already linked the number to, the new owner could end up getting access to your existing account — your private information could be compromised completely by accident!

Cell phone provider lookup: Doxxing

Get your doxx in a row

So, we know SMS is old, insecure, vulnerable, and even hackable by accident. But it gets worse. There’s a very simple, very real danger to linking your online life to your phone number: phone numbers (in most countries, at least) are a concrete link between your online personas and your real-world identity.

If you’re using a service that relies on phone numbers as usernames or logins, you have to give people your phone number in order for them to contact you through that service. This means that people you add on these services can call you and text you. Worse, they can even use your phone number to figure out your real name and address through a form of Internet stalking known as doxxing.

‘Doxxing’ is a catch-all term for a wide range of approaches and attacks, but they all have one thing in common: the goal of doxxing is to identify real-life information about you, which can then be used for other nefarious purposes like scamming or even real-life stalking.

Doxxing can be incredibly easy — so easy that anyone, not just malicious hackers, can do it. Reverse phone number lookup services let someone type in your phone number and find your real name and physical address. Even just a simple Google search of your phone number can reveal social media profiles, pictures, posts and more — people can find treasure troves of information about you using only your phone number.

Things can get even worse if an attacker adds some social engineering into the mix. Once they’ve found your social media profiles, they can start targeting your friends, setting up fake accounts to contact them and find out more about you through lies and manipulation.

Once you use your phone number to identify yourself online, that account (or service, or app) is inextricably linked to your real identity — which can have serious implications for your online privacy.

Keep your phone number safe: What can you do?

Your number’s number is up

In short, don’t use anything that forces you to give up or use your phone number as an identifier. Also, we get it – that’s not easy when most apps still do. Most.

Phone numbers are outdated and insecure. Using a phone number to secure your online life gives malicious actors a dozen different doors into your digital identity. And thanks to number recycling, someone else could get access to your accounts totally by accident!

It’s time for us to find better ways to keep our digital lives secure. Mobile two-factor authentication apps like Authy and LastPass Authenticator are a step in the right direction — but even then, if someone gets ahold of the device holding your authenticator app, you could be in trouble.

Phew, that’s a lot! A better solution is to keep your online accounts completely separate from your real identity — no linking your phone number when you can! Apps like Session skip over phone numbers entirely.

Staying away from phone-number-required apps and services will help you keep your online and mobile life truly secure — with less chance of anyone invading your privacy through hacking, SIM swapping, number recycling or doxxing.

<![CDATA[Private messaging: Who needs a secure messenger — and why?]]> 3PbbXbVY0uja233edCwL0J 2019-12-14T23:00:00.000Z Everyone has the right to privacy, and a private messenger is the number one tool for people who want to communicate safely and securely on the internet. Nobody wants to feel unsafe online. Whether you’re swapping movie ideas with a friend or sending your boss some sensitive documents, private messaging keeps your communications secure.

For some, privacy is no joke. The messages you need to send privately are the most important ones — the ones that might have consequences if they’re not sent securely.

When you’re sending a message to someone and need to be sure only they will see it, you need a private messenger.

Private messengers: What makes a secure messenger secure?

There are a few things to look out for when you’re searching for a private messenger.

The first thing any private messenger needs is end-to-end encryption, AKA E2EE — this is the non-negotiable starting point for any app claiming to be a private messenger. End-to-end encryption means your messages are encrypted the entire time they’re in transit, so even if someone manages to intercept your messages, they still won’t be able to read them. Only you and the person you’re messaging have the encryption key necessary to read any given message.

But not all E2EE is created equal. Some methods of encryption are more hardy than others, so it’s important to check out what kind of encryption your messenger is using.

You also need to consider who is handling and storing your messages. If the company running the messaging app is storing your messages (and the messages aren’t encrypted well enough), the company may be able to decrypt them. And depending on where and how the messages are being stored, law enforcement agencies or other third parties could even force a company to expose your messages.

To protect against this, some messengers avoid storing messages in one place, or program messages to expire after a while.

In addition, some messengers may be private, but not anonymous. A private messenger will generally hide the contents of a message you send, but not hide the fact that you sent it. An anonymous messenger hides all the information about the conversation, not just the contents of your messages. And a messenger isn’t anonymous if you need to tie your name, email, or phone number to your account. This connects your digital account with your real-world identity — forever.

Staying completely anonymous means nobody can trace your conversations back to you.

Private messaging: The #1 fans

As we hinted at earlier, there are some groups of people who regularly need to send high-stakes private messages. For these people, finding a truly anonymous private messaging solution can make a world of difference.

People like journalists, whistleblowers, politicians, and activists need to communicate privately every day.

Private messaging for journalists

Journalists are targets for hacking and doxxing, often to expose their sources’ identities. But journalists are increasingly turning to private messengers to more safely and privately communicate with sources.

It’s not just about source protection for journalists, though. In our modern political climate, with press freedom in freefall, journalists need to protect themselves as well as their sources. This need for protection drives journalists to use end-to-end encrypted private messaging apps. Law enforcement agencies can’t subpoena the company running the app to obtain copies of journalists’ messages, because the company is never able to read the messages in the first place.

And if the private messaging app in question is decentralised as well as end-to-end encrypted, conversation metadata (identities of the interlocutors, times and locations of conversations, etc.) can’t be subpoenaed either.

Private messaging for whistleblowers

By definition, a whistleblower is an insider who shares confidential information with the public (or intends to do so). Whistleblowing is typically done to expose illegal or unethical practices. This often means large corporations (or even governments) breaking the law.

Whistleblowers have a clear and pressing need for private and anonymous communications. If the whistleblower’s identity becomes known, the entity they blew the whistle on could sue them, arrest them, or worse.

It’s absolutely crucial for whistleblowers to communicate privately and anonymously with journalists, lawyers, and anyone else they may need to contact to successfully blow the whistle on the misconduct they’ve discovered.

Private messaging for politicians

As a routine part of their job, many politicians need to communicate about secret or classified information. Private messaging apps allow politicians to securely discuss top-secret matters while minimising the risk of their conversations being leaked, hacked or otherwise accessed without their knowledge or consent.

Private messaging for activists

Activists — especially activists fighting for (or against) highly controversial causes — are often targeted by governments, law enforcement agencies, or third parties who object to their activism. They may fall victim to attempts to hack, subpoena or otherwise obtain their messages, to be used as evidence in a court of law or simply to garner a conviction in the court of public opinion.

Activists use encrypted private messaging apps to find like-minded people, organise protests, and spread the word about their cause. This way, they can protect themselves from anyone who might want to shut them down or stop them from achieving their goals.

Private messaging: Conclusion

For some people, private, anonymous messaging apps can be absolutely crucial. Journalists use these apps to safeguard their sources — and themselves. Whistleblowers need them to get the word out without compromising their identity. Politicians use them to keep the country’s secrets safe. And activists rely on them to further their cause without compromising their safety or security.

Whether you’re talking about super-sensitive stuff or having a deep and meaningful with a friend, private messengers are the way to go. And decentralised, end-to-end encrypted private messengers like Session aim to be the cream of the crop.

It’s time to take back control of your online privacy. Get ready to switch to a secure decentralised messenger.