🆕 Software Suggestion | Session (ex-Loki Messenger) #1678

Open
opened 2020-02-01 01:13:25 +00:00 by lrq3000 · 78 comments
lrq3000 commented 2020-02-01 01:13:25 +00:00 (Migrated from github.com)

Basic Information

Name: Session (ex-Loki Messenger)
Category: Encrypted Instant Messengers - Decentralized
URL: https://getsession.org/
Platforms: Desktop (Mac, Linux, Windows), Android, iOS

Description

Session (new name of the Loki Messenger) is an anonymous text messenger initially forked from the Signal messenger but completely reworked 3-hops onion routing protocol on top of asymmetrically encrypted messages to anonymize all interactions. E2EE is always enabled and only lokinet users can be contacted through the app. Supports 1-on-1, private groups and public rooms text chats. No phone number nor any private information is required to register. App is cross-platform, available on Windows, Linux, Android, iOS. All open-source, including clients.

In the future, Session will migrate to the Lokinet network (ex LOKI blockchain), a blockchain initially forked from Monero which works over a LLARP (Low Latency Anonymous Routing Protocol) onion routing layer using faster UDP packets, that will allow voice calls. Indeed, Session currently only supports text messages for now due to using a TCP onion routing, but voice calls and maybe video are planned for later after migration to Lokinet (but no exact date planned)). It seems the blockchain is already online since years, but it's still in beta due to the LLARP protocol being tested out, whereas the blockchain technology used is relatively well established, the LLARP protocol is new and needs to be ironed out.

Why I am making the suggestion

Seems like a concurrent to BCM #1662, but it is entirely opensource (here for the messenger). The LLARP onion routing protocol is explained here and compared succinctly to TOR and I2P here (TL;DR: the goal is to retain the strong anonymity and security guarantees of both networks but with faster speed and easier network management - I can't describe more precisely as I am no expert). The messenger (Session) is discussed here. Blokt and SecureChatGuide reviewed it last year under beta (it still is but seems to be soon reaching the first stable release).

I think the messenger is the most directly useful part of the project right now, and hence the focus of this ticket, but the LOKI/LLARP network could also be added as an entry in Self-contained Networks (as suggested before #924) if someone with more expertise than me can understand the provided docs.

/EDIT: a technical preprint is available since 11/02/2020: https://arxiv.org/abs/2002.04609

/EDIT: Session's code was independently audited in April 2021: https://getsession.org/session-code-audit/

My connection with the software

No link, I am just interested in privacy protecting networks.

  •  I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.
## Basic Information **Name:** Session (ex-Loki Messenger) **Category:** Encrypted Instant Messengers - Decentralized **URL:** https://getsession.org/ **Platforms:** Desktop (Mac, Linux, Windows), Android, iOS ## Description Session (new name of the Loki Messenger) is an anonymous text messenger initially forked from the Signal messenger but completely reworked 3-hops onion routing protocol on top of asymmetrically encrypted messages to anonymize all interactions. E2EE is always enabled and only lokinet users can be contacted through the app. Supports 1-on-1, private groups and [public rooms](https://docs.loki.network/LokiServices/Messenger/opengroup_setup/) text chats. No phone number nor any private information is required to register. App is cross-platform, available on Windows, Linux, Android, iOS. All open-source, including clients. In the future, Session will migrate to the [Lokinet network](https://loki.network/) (ex LOKI blockchain), a blockchain initially forked from Monero which works over a LLARP (Low Latency Anonymous Routing Protocol) onion routing layer using faster UDP packets, that will allow voice calls. Indeed, Session currently only supports text messages for now due to using a TCP onion routing, but [voice calls and maybe video are planned for later after migration to Lokinet (but no exact date planned)](https://github.com/loki-project/session-desktop/issues/777)). It seems the blockchain is already online since years, but it's still in beta due to the LLARP protocol being tested out, whereas the blockchain technology used is relatively well established, the LLARP protocol is new and needs to be ironed out. ## Why I am making the suggestion <!-- Anything you would like to tell us about the software? --> Seems like a concurrent to BCM #1662, but it is [entirely opensource](https://github.com/loki-project) ([here for the messenger](https://github.com/loki-project/loki-messenger)). The LLARP onion routing protocol is explained [here](https://docs.loki.network/Lokinet/LLARP/) and compared succinctly to TOR and I2P [here](https://github.com/loki-project/loki-network/blob/c595e175fd0886755d66feb141debae32cdb19a4/docs/high-level.txt) (TL;DR: the goal is to retain the strong anonymity and security guarantees of both networks but with faster speed and easier network management - I can't describe more precisely as I am no expert). The messenger (Session) is discussed [here](https://loki.network/2018/11/09/the-state-of-private-messaging-applications/). [Blokt](https://blokt.com/guides/loki-messenger-taking-private-messaging-to-a-new-level) and [SecureChatGuide](https://securechatguide.org/decentralizedapps.html#loki) reviewed it last year under beta (it still is but seems to be soon reaching the first stable release). I think the messenger is the most directly useful part of the project right now, and hence the focus of this ticket, but the LOKI/LLARP network could also be added as an entry in Self-contained Networks (as suggested before #924) if someone with more expertise than me can understand the provided docs. /EDIT: a technical preprint is available since 11/02/2020: https://arxiv.org/abs/2002.04609 /EDIT: Session's code was independently audited in April 2021: https://getsession.org/session-code-audit/ ## My connection with the software <!-- Are you the author? Enthustiastic or early adopter? Friends with the author or requested by them to open the isue? An employee of the software maker? --> No link, I am just interested in privacy protecting networks. - [x] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.
lrq3000 commented 2020-02-01 02:33:44 +00:00 (Migrated from github.com)

Mmmm Maybe this ticket should be put on hold until the final release comes out, here is the introductory message when installing the software:

Thanks for testing Loki Messenger! This software is a beta version of the full Loki Messenger software suite, and so is missing some of the features the full version will have.
This version of Loki Messenger provides no guarantees of metadata privacy.
While your messages are secured using end to end encryption, in this beta version of Loki messenger, third parties (like your ISP or the Service Node network) can see who you’re talking to and when you’re sending or receiving messages.
It is also possible that third parties could correlate your public key to your IP address and your real identity if they learn your public key.
However, no one except you and your intended recipients will be able to see the contents of your messages. We recommend using existing methods, like Tor or I2P to mask your IP address while using Loki Messenger beta version.
As a beta, this software is still experimental. When things aren't working for you, or you feel confused by the app, please let us know by filing an issue on Github or making suggestions on Discord.

At least, it looks like they take security very seriously. Up to you guys to see whether you want to add the entry with a warning, or wait for the final release to fix these issues.

Mmmm Maybe this ticket should be put on hold until the final release comes out, here is the introductory message when installing the software: > Thanks for testing Loki Messenger! This software is a beta version of the full Loki Messenger software suite, and so is missing some of the features the full version will have. > This version of Loki Messenger provides no guarantees of metadata privacy. > While your messages are secured using end to end encryption, in this beta version of Loki messenger, third parties (like your ISP or the Service Node network) can see who you’re talking to and when you’re sending or receiving messages. > It is also possible that third parties could correlate your public key to your IP address and your real identity if they learn your public key. > However, no one except you and your intended recipients will be able to see the contents of your messages. We recommend using existing methods, like Tor or I2P to mask your IP address while using Loki Messenger beta version. > As a beta, this software is still experimental. When things aren't working for you, or you feel confused by the app, please let us know by filing an issue on Github or making suggestions on Discord. At least, it looks like they take security very seriously. Up to you guys to see whether you want to add the entry with a warning, or wait for the final release to fix these issues.
KeeJef commented 2020-02-02 14:57:43 +00:00 (Migrated from github.com)

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review.

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review.
lrq3000 commented 2020-02-02 15:45:36 +00:00 (Migrated from github.com)

@KeeJef that's great news to hear! Can't wait to test the stable release with all the anonymity features implemented :-)

@KeeJef that's great news to hear! Can't wait to test the stable release with all the anonymity features implemented :-)
wuniversales commented 2020-02-03 18:58:56 +00:00 (Migrated from github.com)

My God, what an amazing application.
Thank you

My God, what an amazing application. Thank you
wuniversales commented 2020-02-09 20:01:06 +00:00 (Migrated from github.com)
New website: https://getsession.org/
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-02-10 15:10:55 +00:00 (Migrated from github.com)

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review.

When exactly are you launching? Great project!

> Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. When exactly are you launching? Great project!
lrq3000 commented 2020-02-10 15:47:36 +00:00 (Migrated from github.com)

The app is already available, I have used it before posting this issue, but
some important features were missing such as group chat, but on the new
website it's written this is now possible, so i guess that's what was
meant, the deployment of the new release with these important group
features and security updates?

Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe <
notifications@github.com> a écrit :

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will
be launching Session in a few days on Desktop, iOS and Android, so probably
best to hold off until then for research/review.

When exactly are you launching? Great project!


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/privacytoolsIO/privacytools.io/issues/1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA
.

The app is already available, I have used it before posting this issue, but some important features were missing such as group chat, but on the new website it's written this is now possible, so i guess that's what was meant, the deployment of the new release with these important group features and security updates? Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe < notifications@github.com> a écrit : > Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will > be launching Session in a few days on Desktop, iOS and Android, so probably > best to hold off until then for research/review. > > When exactly are you launching? Great project! > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/privacytoolsIO/privacytools.io/issues/1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA> > . >
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-02-11 05:36:40 +00:00 (Migrated from github.com)

The app is already available, I have used it before posting this issue, but some important features were missing such as group chat, but on the new website it's written this is now possible, so i guess that's what was meant, the deployment of the new release with these important group features and security updates? Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe < notifications@github.com> a écrit :

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. When exactly are you launching? Great project! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA .

Yes, I meant the new features and security updates. I gave it a look on the desktop client but couldn't find a way of installing it on mobile without using Google Play store, do you know if the .apk is available somewhere?

> The app is already available, I have used it before posting this issue, but some important features were missing such as group chat, but on the new website it's written this is now possible, so i guess that's what was meant, the deployment of the new release with these important group features and security updates? Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe < notifications@github.com> a écrit : > […](#) > Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. When exactly are you launching? Great project! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA> . Yes, I meant the new features and security updates. I gave it a look on the desktop client but couldn't find a way of installing it on mobile without using Google Play store, do you know if the .apk is available somewhere?
KeeJef commented 2020-02-11 06:15:18 +00:00 (Migrated from github.com)

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review.

When exactly are you launching? Great project!

As mentioned above Session is now launched on all platforms at https://getsession.org , today we also published a whitepaper https://getsession.org/whitepaper which goes through the design in detail. We are still working through a number of issues discovered when we launched with Multi-device setups so that might not be working as expected if you encounter and edge case.

> > Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. > > When exactly are you launching? Great project! As mentioned above Session is now launched on all platforms at https://getsession.org , today we also published a whitepaper https://getsession.org/whitepaper which goes through the design in detail. We are still working through a number of issues discovered when we launched with Multi-device setups so that might not be working as expected if you encounter and edge case.
KeeJef commented 2020-02-11 07:09:56 +00:00 (Migrated from github.com)

The app is already available, I have used it before posting this issue, but some important features were missing such as group chat, but on the new website it's written this is now possible, so i guess that's what was meant, the deployment of the new release with these important group features and security updates? Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe < notifications@github.com> a écrit :

Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. When exactly are you launching? Great project! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA .

Yes, I meant the new features and security updates. I gave it a look on the desktop client but couldn't find a way of installing it on mobile without using Google Play store, do you know if the .apk is available somewhere?

APKs are here, https://github.com/loki-project/session-android/releases , We will be trying to get into F-Droid repo shortly, we're just focusing on bugfixes for now since we just released.

> > The app is already available, I have used it before posting this issue, but some important features were missing such as group chat, but on the new website it's written this is now possible, so i guess that's what was meant, the deployment of the new release with these important group features and security updates? Le lun. 10 févr. 2020 à 16:10, 5a384507-18ce-417c-bb55-d4dfcc8883fe < [notifications@github.com](mailto:notifications@github.com)> a écrit : > > […](#) > > Hey, I'm the CTO on the Loki/Session project, just to confirm, yes we will be launching Session in a few days on Desktop, iOS and Android, so probably best to hold off until then for research/review. When exactly are you launching? Great project! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1678?email_source=notifications&email_token=AAIRFXTMMKI6EJ6MOAU6ZSTRCFU77A5CNFSM4KOP2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELI3M7Y#issuecomment-584169087>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIRFXQYIG4FVLNCNXFIIMDRCFU77ANCNFSM4KOP2STA . > > Yes, I meant the new features and security updates. I gave it a look on the desktop client but couldn't find a way of installing it on mobile without using Google Play store, do you know if the .apk is available somewhere? APKs are here, https://github.com/loki-project/session-android/releases , We will be trying to get into F-Droid repo shortly, we're just focusing on bugfixes for now since we just released.
lrq3000 commented 2020-02-11 07:32:34 +00:00 (Migrated from github.com)

@KeeJef Thanks a lot for the updates, I have updated this issue accordingly. Good luck with the post-release bugfixing, you've got an awesome project here!

@KeeJef Thanks a lot for the updates, I have updated this issue accordingly. Good luck with the post-release bugfixing, you've got an awesome project here!
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-02-11 13:48:29 +00:00 (Migrated from github.com)

Congrats, I hope you get a stable release ASAP and your project is great!

Congrats, I hope you get a stable release ASAP and your project is great!
zaggynl commented 2020-02-14 16:18:38 +00:00 (Migrated from github.com)

Does this depend on the Google Services Framework? Aurora store shows a GSF dependency.

Does this depend on the Google Services Framework? Aurora store shows a GSF dependency.
wuniversales commented 2020-02-14 17:22:53 +00:00 (Migrated from github.com)

As they say during the beta, it has a traffic analyzer, then they will remove it in the stable version.

As they say during the beta, it has a traffic analyzer, then they will remove it in the stable version.
KeeJef commented 2020-02-15 02:35:02 +00:00 (Migrated from github.com)

@wuniversales all analytics have already been removed from all platforms, that was done a few weeks ago when Session was released

Regarding Aurora store flagging Session as GSF dependent, not sure why that is happening, we have APK's that you can download directly here and those work fine without Google play, i will have a look into it on Monday though.

@wuniversales all analytics have already been removed from all platforms, that was done a few weeks ago when Session was released Regarding Aurora store flagging Session as GSF dependent, not sure why that is happening, we have APK's that you can download directly [here](https://github.com/loki-project/session-android/releases/latest) and those work fine without Google play, i will have a look into it on Monday though.
PMK commented 2020-02-25 19:38:35 +00:00 (Migrated from github.com)

1.0.2 released and I'm impressed! I would like to see this being added.

1.0.2 released and I'm impressed! I would like to see this being added.
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-02-25 20:40:41 +00:00 (Migrated from github.com)

1.0.2 released and I'm impressed! I would like to see this being added.

Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal.

> 1.0.2 released and I'm impressed! I would like to see this being added. Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal.
blacklight447 commented 2020-03-02 12:17:19 +00:00 (Migrated from github.com)

1.0.2 released and I'm impressed! I would like to see this being added.

Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal.

Signal hasn't had the need to run on google for notifications for years now, and even with the google version, google only sees that you have a notification, not what the notification is about.

About Session now, what is the intended threatmodel? And also, what does it intend to solve over signal ( as of now, it seems to be a Signal fork with some blockchain stuff bolted on).

> > > > 1.0.2 released and I'm impressed! I would like to see this being added. > > Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal. Signal hasn't had the need to run on google for notifications for years now, and even with the google version, google only sees that you have a notification, not what the notification is about. About Session now, what is the intended threatmodel? And also, what does it intend to solve over signal ( as of now, it seems to be a Signal fork with some blockchain stuff bolted on).
KeeJef commented 2020-03-02 12:53:22 +00:00 (Migrated from github.com)

The threat model is defined in the whitepaper here https://arxiv.org/pdf/2002.04609.pdf

Since Session deploys proxy routing (1 hop, soon to be Onion routing 3 hops) inside it can deal with network level adversaries, as opposed to Signal in which the server can collect the sender and recipient IP addresses. Additionally it removes the need for phone numbers or email addresses as identifiers and instead uses public keys, which enhance anonymity as they are not linked to any real work identifier. Session also doesn't rely on central servers, messages are not stored on servers run solely by the developers or Loki foundation and instead are stored on Service Nodes run by community members, this makes the network resilient to being shutdown or compelled to run privacy compromising software distributions. There is more information contained in the whitepaper about how this is achieved and the properties it provides.

The threat model is defined in the whitepaper here https://arxiv.org/pdf/2002.04609.pdf Since Session deploys proxy routing (1 hop, soon to be Onion routing 3 hops) inside it can deal with network level adversaries, as opposed to Signal in which the server can collect the sender and recipient IP addresses. Additionally it removes the need for phone numbers or email addresses as identifiers and instead uses public keys, which enhance anonymity as they are not linked to any real work identifier. Session also doesn't rely on central servers, messages are not stored on servers run solely by the developers or Loki foundation and instead are stored on Service Nodes run by community members, this makes the network resilient to being shutdown or compelled to run privacy compromising software distributions. There is more information contained in the whitepaper about how this is achieved and the properties it provides.
blacklight447 commented 2020-03-02 12:59:42 +00:00 (Migrated from github.com)

The threat model is defined in the whitepaper here https://arxiv.org/pdf/2002.04609.pdf

Since Session deploys proxy routing (1 hop, soon to be Onion routing 3 hops) inside it can deal with network level adversaries, as opposed to Signal in which the server can collect the sender and recipient IP addresses. Additionally it removes the need for phone numbers or email addresses as identifiers and instead uses public keys, which enhance anonymity as they are not linked to any real work identifier. Session also doesn't rely on central servers, messages are not stored on servers run solely by the developers or Loki foundation and instead are stored on Service Nodes run by community members, this makes the network resilient to being shutdown or compelled to run privacy compromising software distributions. There is more information contained in the whitepaper about how this is achieved and the properties it provides.

So it aims to solve signals ability to correlate conversation members via your own onion routing network ( as currently, signal can still correlate via IP, but not via account's because of their sealed sender feature) and you deal with the phone number issue with a blockchain?

> > > The threat model is defined in the whitepaper here https://arxiv.org/pdf/2002.04609.pdf > > Since Session deploys proxy routing (1 hop, soon to be Onion routing 3 hops) inside it can deal with network level adversaries, as opposed to Signal in which the server can collect the sender and recipient IP addresses. Additionally it removes the need for phone numbers or email addresses as identifiers and instead uses public keys, which enhance anonymity as they are not linked to any real work identifier. Session also doesn't rely on central servers, messages are not stored on servers run solely by the developers or Loki foundation and instead are stored on Service Nodes run by community members, this makes the network resilient to being shutdown or compelled to run privacy compromising software distributions. There is more information contained in the whitepaper about how this is achieved and the properties it provides. So it aims to solve signals ability to correlate conversation members via your own onion routing network ( as currently, signal can still correlate via IP, but not via account's because of their sealed sender feature) and you deal with the phone number issue with a blockchain?
KeeJef commented 2020-03-02 13:10:42 +00:00 (Migrated from github.com)

So it aims to solve signals ability to correlate conversation members via your own onion routing network ( as currently, signal can still correlate via IP, but not via account's because of their sealed sender feature) and you deal with the phone number issue with a blockchain?

Yes it aims to resolve the IP address correlation, by using an Onion routing network. But no, it doesn't use a blockchain to solve the phone number issue, the public keys don't have any relationship to the blockchain, they are just public keys. The blockchain is used to incentivze the nodes in the network who store user messages and allow for asynchronous communications. You dont need to pay to send messages or use the messenger or anything, its abstracted away from the user.

> So it aims to solve signals ability to correlate conversation members via your own onion routing network ( as currently, signal can still correlate via IP, but not via account's because of their sealed sender feature) and you deal with the phone number issue with a blockchain? Yes it aims to resolve the IP address correlation, by using an Onion routing network. But no, it doesn't use a blockchain to solve the phone number issue, the public keys don't have any relationship to the blockchain, they are just public keys. The blockchain is used to incentivze the nodes in the network who store user messages and allow for asynchronous communications. You dont need to pay to send messages or use the messenger or anything, its abstracted away from the user.
blacklight447 commented 2020-03-02 13:19:12 +00:00 (Migrated from github.com)

Interesting. What happens if the user loses his private key? Also, are there any easy backup methods in place so the user can prevent losing said private key?

Interesting. What happens if the user loses his private key? Also, are there any easy backup methods in place so the user can prevent losing said private key?
KeeJef commented 2020-03-02 13:26:15 +00:00 (Migrated from github.com)

Interesting. What happens if the user loses his private key? Also, are there any easy backup methods in place so the user can prevent losing said private key?

The user is given access to and encouraged to write down their 12 word mnemonic seed when they create an account or at any time in the settings menu, with this phrase they can restore their private key (identity) and re-initiate previous sessions. In the future we will allow the user to password encrypt their seed and store it other locations, but that's not yet implemented

> Interesting. What happens if the user loses his private key? Also, are there any easy backup methods in place so the user can prevent losing said private key? The user is given access to and encouraged to write down their 12 word mnemonic seed when they create an account or at any time in the settings menu, with this phrase they can restore their private key (identity) and re-initiate previous sessions. In the future we will allow the user to password encrypt their seed and store it other locations, but that's not yet implemented
blacklight447 commented 2020-03-02 13:30:26 +00:00 (Migrated from github.com)

Sounds very promising. Im not sure if the software is mature enough to be a major recommendation just yet, and we also would have to see how the loki network will develop itself further (is it going to die down like most startup anonymity networks, or will it maybe thrive.) About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor?

Sounds very promising. Im not sure if the software is mature enough to be a major recommendation just yet, and we also would have to see how the loki network will develop itself further (is it going to die down like most startup anonymity networks, or will it maybe thrive.) About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor?
KeeJef commented 2020-03-02 13:37:08 +00:00 (Migrated from github.com)

About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor?

I don't anticipate that happening since the network is already about 1030 nodes strong. But technically, yes, it would require ripping the custom onion routing logic we have in our code out, but i see no reason it couldn't be switched to use Tor.

> About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor? I don't anticipate that happening since the network is already about [1030](https://lokidashboard.com/) nodes strong. But technically, yes, it would require ripping the custom onion routing logic we have in our code out, but i see no reason it couldn't be switched to use Tor.
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-03-02 15:04:51 +00:00 (Migrated from github.com)

1.0.2 released and I'm impressed! I would like to see this being added.

Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal.

Signal hasn't had the need to run on google for notifications for years now, and even with the google version, google only sees that you have a notification, not what the notification is about.

Yes it need Google notifications, I downloaded the .apk from Signal recently and they won't let you install the software if you don't have Google store installed, and also if you don't have Google services install you need to enter to the application to receive messages, if not it goes kinda buggy and won't notify you, this issue doesn't happen with Session.

> > > 1.0.2 released and I'm impressed! I would like to see this being added. > > > > > > Yeah, it works pretty sweet and it doesn't have shitty Google dependencies like Signal. > > Signal hasn't had the need to run on google for notifications for years now, and even with the google version, google only sees that you have a notification, not what the notification is about. Yes it need Google notifications, I downloaded the .apk from Signal recently and they won't let you install the software if you don't have Google store installed, and also if you don't have Google services install you need to enter to the application to receive messages, if not it goes kinda buggy and won't notify you, this issue doesn't happen with Session.
5a384507-18ce-417c-bb55-d4dfcc8883fe commented 2020-03-02 15:08:34 +00:00 (Migrated from github.com)

Sounds very promising. Im not sure if the software is mature enough to be a major recommendation just yet, and we also would have to see how the loki network will develop itself further (is it going to die down like most startup anonymity networks, or will it maybe thrive.) About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor?

I've been using it for almost two weeks now and I can say it works really really good, in comparison to Briar or Jami, which are also listed, if that's considered mature.

> Sounds very promising. Im not sure if the software is mature enough to be a major recommendation just yet, and we also would have to see how the loki network will develop itself further (is it going to die down like most startup anonymity networks, or will it maybe thrive.) About that, if the worsed case scenario happens and loki doesn't make it, will it be possible to alter session to move to another platform like Tor? I've been using it for almost two weeks now and I can say it works really really good, in comparison to Briar or Jami, which are also listed, if that's considered mature.
lrq3000 commented 2020-03-02 15:14:07 +00:00 (Migrated from github.com)
Super interesting discussion, thanks a lot everyone! I also found their blog posts very interesting about their vision of private messaging, particularly the first one: * https://loki.network/2019/03/29/mls-and-federated-messaging/ * https://getsession.org/onion-requests-session-new-message-routing-solution/ * https://getsession.org/how-session-protects-your-anonymity-with-blockchain-and-crypto/ * https://getsession.org/centralisation-vs-decentralisation-in-private-messaging/
blacklight447 commented 2020-03-02 15:22:00 +00:00 (Migrated from github.com)

@5a384507-18ce-417c-bb55-d4dfcc8883fe i have been using signal for more then 2 years without any google services on my device and recieve notifications perfectly fine.

@5a384507-18ce-417c-bb55-d4dfcc8883fe i have been using signal for more then 2 years without any google services on my device and recieve notifications perfectly fine.
Mikaela commented 2020-03-21 21:20:43 +00:00 (Migrated from github.com)

As this was brought up in #general:privacytools.io, I checked it quickly and commented this:

I don't like it being Electron and I don't really understand their answer "Is Session peer-to-peer?" - what are service nodes, are they centralized only in their control or can anyone host them and are they federated? Otherwise it looks promising other than being Electron and I am not capable of auditing it

Emphasis I added for GitHub.

As this was brought up in `#general:privacytools.io`, I checked it quickly and commented this: > I don't like it being Electron and ***I don't really understand their answer "Is Session peer-to-peer?" - what are service nodes, are they centralized only in their control or can anyone host them and are they federated?*** Otherwise it looks promising other than being Electron and ***I am not capable of auditing it*** Emphasis I added for GitHub.
KeeJef commented 2020-03-21 23:37:52 +00:00 (Migrated from github.com)

As this was brought up in #general:privacytools.io, I checked it quickly and commented this:

I don't like it being Electron and I don't really understand their answer "Is Session peer-to-peer?" - what are service nodes, are they centralized only in their control or can anyone host them and are they federated? Otherwise it looks promising other than being Electron and I am not capable of auditing it

Emphasis I added for GitHub.

The desktop version is Electron based primarily since we have forked the existing Signal applications. For us to develop and maintain native clients for all OS'es would be extremely resource intensive. Although we do recognize that Electron is not the most highly secure framework available.

Regarding the Service Node network. They are federated, and anyone with the required Loki stake can start running one and earn a reward for storing and routing user messages. The Loki foundation is not in control of the Service Node network, there are hundreds of individual node operators with altogether about 1050 Service Nodes in operation.

The reason Session isnt peer to peer is that you always connect to the Service Node network to send and store messages to other users, you never connect directly to another user as that would expose your IP address and limit the ability for messages to be sent asynchronously.

> As this was brought up in `#general:privacytools.io`, I checked it quickly and commented this: > > > I don't like it being Electron and _**I don't really understand their answer "Is Session peer-to-peer?" - what are service nodes, are they centralized only in their control or can anyone host them and are they federated?**_ Otherwise it looks promising other than being Electron and _**I am not capable of auditing it**_ > > Emphasis I added for GitHub. The desktop version is Electron based primarily since we have forked the existing Signal applications. For us to develop and maintain native clients for all OS'es would be extremely resource intensive. Although we do recognize that Electron is not the most highly secure framework available. Regarding the Service Node network. They are federated, and anyone with the required Loki stake can start running one and earn a reward for storing and routing user messages. The Loki foundation is not in control of the Service Node network, there are hundreds of individual node operators with altogether about 1050 Service Nodes in operation. The reason Session isnt peer to peer is that you always connect to the Service Node network to send and store messages to other users, you never connect directly to another user as that would expose your IP address and limit the ability for messages to be sent asynchronously.
ghost commented 2020-04-26 20:27:02 +00:00 (Migrated from github.com)

This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up

This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up
dngray commented 2020-04-27 03:20:45 +00:00 (Migrated from github.com)

This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up

No reason to wait for it to be mentioned on PrivacyTools, why not switch now and tell us how it you found it.

> This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up No reason to wait for it to be mentioned on PrivacyTools, why not switch now and tell us how it you found it.
ghost commented 2020-04-27 03:27:51 +00:00 (Migrated from github.com)

This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up

No reason to wait for it to be mentioned on PrivacyTools, why not switch now and tell us how it you found it.

Found it from reddit on the privacy section but I am gonna switch but if it was on privacy tools it would give me some reinsurance that it’s safe and secure. I know it’s a based on the electron blockchain which I heard wasn’t the best. But it does use signals protocol

> > This would be great I’m deciding on switching to session as it doesn’t need a phone or email to sign up > > No reason to wait for it to be mentioned on PrivacyTools, why not switch now and tell us how it you found it. Found it from reddit on the privacy section but I am gonna switch but if it was on privacy tools it would give me some reinsurance that it’s safe and secure. I know it’s a based on the electron blockchain which I heard wasn’t the best. But it does use signals protocol
KeeJef commented 2020-04-27 03:37:18 +00:00 (Migrated from github.com)

I know it’s a based on the electron blockchain which I heard wasn’t the best.

It is not based on the Electron blockchain (AFIK that doesn't exist), the Desktop application is using the Electron Javascript framework, as is Signal. As @dngray said you can go ahead and have a go using Session, its still early days so the user experience isn't quite as easy as Signal and you might run into bugs.

> I know it’s a based on the electron blockchain which I heard wasn’t the best. It is not based on the Electron blockchain (AFIK that doesn't exist), the Desktop application is using the Electron Javascript framework, as is Signal. As @dngray said you can go ahead and have a go using Session, its still early days so the user experience isn't quite as easy as Signal and you might run into bugs.
ghost commented 2020-04-27 03:39:36 +00:00 (Migrated from github.com)

Oh thanks for the correction that’s why you should believe some reddit user 😂

Oh thanks for the correction that’s why you should believe some reddit user 😂
blacklight447 commented 2020-05-05 07:35:43 +00:00 (Migrated from github.com)

I think session will be a great addition to the site on day, but we are currently mostly waiting for it to become more mature as software and as a service (by seeing how the loki network will expand and grow.)

I think session will be a great addition to the site on day, but we are currently mostly waiting for it to become more mature as software and as a service (by seeing how the loki network will expand and grow.)
GintokiHub commented 2020-05-24 10:42:25 +00:00 (Migrated from github.com)

I have admired the effort of the loki team (don't know them). To try and make some kind of midway best of two tor and i2p together anonymity network, first of all.
Honestly I think it might be able to be posted as a rec, for people whom need only send messages to one another.
However when, if they implement actual voice calling tech in there I think this truly will spark a lot of peoples interest.

I have admired the effort of the loki team (don't know them). To try and make some kind of midway best of two tor and i2p together anonymity network, first of all. Honestly I think it might be able to be posted as a rec, for people whom need only send messages to one another. However when, if they implement actual voice calling tech in there I think this truly will spark a lot of peoples interest.
KeeJef commented 2020-05-25 01:11:44 +00:00 (Migrated from github.com)

I have admired the effort of the loki team (don't know them). To try and make some kind of midway best of two tor and i2p together anonymity network, first of all.
Honestly I think it might be able to be posted as a rec, for people whom need only send messages to one another.
However when, if they implement actual voice calling tech in there I think this truly will spark a lot of peoples interest.

I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site

  • The app is added to F-Droid
  • The cross platform refactor is finished (This is about 2-4 weeks away) this will vastly improve message sending reliability, especially when dealing with multi device functionality
  • Full three hop onion routing is enabled in Session, instead of one hop proxy routing.
  • Closed group size is expanded

These features are all actively being worked on right as we speak and i think when these features are in and testers from this group can see that they work reliably, then there would be no reason not to list Session in the messenger section.

> I have admired the effort of the loki team (don't know them). To try and make some kind of midway best of two tor and i2p together anonymity network, first of all. > Honestly I think it might be able to be posted as a rec, for people whom need only send messages to one another. > However when, if they implement actual voice calling tech in there I think this truly will spark a lot of peoples interest. I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site - The app is added to F-Droid - The cross platform refactor is finished (This is about 2-4 weeks away) this will vastly improve message sending reliability, especially when dealing with multi device functionality - Full three hop onion routing is enabled in Session, instead of one hop proxy routing. - Closed group size is expanded These features are all actively being worked on right as we speak and i think when these features are in and testers from this group can see that they work reliably, then there would be no reason not to list Session in the messenger section.
lrq3000 commented 2020-05-25 11:21:02 +00:00 (Migrated from github.com)

Full three hop onion routing is enabled in Session, instead of one hop proxy routing.

I was going to mention the simplified routing scheme, but if the 3 hop onion routing is implemented soon, then that would be awesome!

I agree that even without voice calls, with the upcoming updates Session would be at least Worth Mentioning IMHO, until its stability is sufficiently field tested to potentially be a recommendation similarly to Briar (although I'm not sure whether it should be classified as P2P or Federated - Status.im which is based on Ethereum nodes is under Federated so maybe we should go along the same way for Session?)

> Full three hop onion routing is enabled in Session, instead of one hop proxy routing. I was going to mention the simplified routing scheme, but if the 3 hop onion routing is implemented soon, then that would be awesome! I agree that even without voice calls, with the upcoming updates Session would be at least Worth Mentioning IMHO, until its stability is sufficiently field tested to potentially be a recommendation similarly to Briar (although I'm not sure whether it should be classified as P2P or Federated - Status.im which is based on Ethereum nodes is under Federated so maybe we should go along the same way for Session?)
lrq3000 commented 2020-05-25 11:27:23 +00:00 (Migrated from github.com)

BTW thanks a lot @KeeJef for taking the time to update us, that's really appreciated (and great work on Session!).

Ah I also just noticed you published a preprint, congratulations and great work! I'll add this to the top message for reference :-)

BTW thanks a lot @KeeJef for taking the time to update us, that's really appreciated (and great work on Session!). Ah I also just noticed you published a preprint, congratulations and great work! I'll add this to the top message for reference :-)
GintokiHub commented 2020-05-26 07:33:40 +00:00 (Migrated from github.com)

I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site

Oh that wasn't what I was trying to imply. I'm just really thrilled if when it would get to that point.
For me it if at that point, if then working this would be my dream messenger come true so..

> I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site > Oh that wasn't what I was trying to imply. I'm just really thrilled if when it would get to that point. For me it if at that point, if then working this would be my dream messenger come true so..
lrq3000 commented 2020-06-12 09:55:17 +00:00 (Migrated from github.com)

For me it if at that point, if then working this would be my dream messenger come true so..

@GintokiHub I agree with you and would very much like to see VoIP (and let's dream voice calling ;-) ) through the lokinet. Maybe someday! :D Right now the future of private messaging seems bright with the emerging implementations of E2EE in WebRTC using Secure Frames, and with the lokinet it would also be anonymous to some extent.

@KeeJef please let us know when the points you mentioned are ready for large use, I can test and make a PR :-)

> For me it if at that point, if then working this would be my dream messenger come true so.. @GintokiHub I agree with you and would very much like to see VoIP (and let's dream voice calling ;-) ) through the lokinet. Maybe someday! :D Right now the future of private messaging seems bright with the emerging implementations of E2EE in WebRTC using Secure Frames, and with the lokinet it would also be anonymous to some extent. @KeeJef please let us know when the points you mentioned are ready for large use, I can test and make a PR :-)
ph00lt0 commented 2020-06-12 10:18:47 +00:00 (Migrated from github.com)

Session has trackers from Google Firebase, doesn't seem like something PTIO should recommend.

Session has trackers from Google Firebase, doesn't seem like something PTIO should recommend.
lrq3000 commented 2020-06-12 10:28:10 +00:00 (Migrated from github.com)

@ph00lt0 I guess this issue explains why Firebase is used?

I remember reading a blog post about the difficulties with pushing updates to Android devices without using a connection to a centralized server that could diminish anonymity, maybe it was on the Session blog but I can't remember or find with Google where.

@ph00lt0 I guess [this issue](https://github.com/loki-project/session-android/issues/182) explains why Firebase is used? I remember reading a blog post about the difficulties with pushing updates to Android devices without using a connection to a centralized server that could diminish anonymity, maybe it was on the [Session blog](https://getsession.org/blog/) but I can't remember or find with Google where.
lrq3000 commented 2020-06-12 10:31:38 +00:00 (Migrated from github.com)

PS: it seems that using Firebase is optional, although enabled by default if I understand correctly the issue linked above?

PS: it seems that using Firebase is optional, although enabled by default if I understand correctly the issue linked above?
subsys-R9boq8 commented 2020-06-12 10:34:38 +00:00 (Migrated from github.com)

PS: it seems that using Firebase is optional, although enabled by default if I understand correctly the issue linked above?

It's possible to use Firebase Cloud Messaging as a push service, but users can opt not to use it, and the setting screen is explicit enough (pop out after first run of app update) to consider it no harmful intention.

Though it still feels strange enough to me, because using FCM doesn't require Firebase Analytics, right?

And the analytics result of Exodus only returns one Java class (com.google.firebase.analytics.connector.AnalyticsConnector), which is not the case for normal apps (for example: pixiv 8 classes start with com.google.firebase.analytics.) that embedded Firease Analytics.

> > > PS: it seems that using Firebase is optional, although enabled by default if I understand correctly the issue linked above? It's possible to use Firebase Cloud Messaging as a push service, but users can opt not to use it, and the setting screen is **explicit enough** (pop out after first run of app update) to consider it no harmful intention. Though it still feels strange enough to me, because using FCM doesn't require Firebase Analytics, right? And the analytics result of Exodus only returns one Java class (com.google.firebase.analytics.connector.AnalyticsConnector), which is not the case for normal apps (for example: pixiv 8 classes start with com.google.firebase.analytics.) that embedded Firease Analytics.
ph00lt0 commented 2020-06-12 10:50:19 +00:00 (Migrated from github.com)

@subsys-R9boq8 this is exactly my point. It's not about the push notifications. Although I would say it should use alternative methods either way. The use of trackers like Firebase Analytics is just wrong.

@subsys-R9boq8 this is exactly my point. It's not about the push notifications. Although I would say it should use alternative methods either way. The use of trackers like Firebase Analytics is just wrong.
subsys-R9boq8 commented 2020-06-12 10:56:57 +00:00 (Migrated from github.com)

@ph00lt0 Yes, and it also sounds strange, Firebase Analytics seems quite broke in Session-Android.

@ph00lt0 Yes, and it also sounds strange, Firebase Analytics seems quite broke in Session-Android.
KeeJef commented 2020-06-13 00:37:18 +00:00 (Migrated from github.com)

We have never actually used Firebase analytics in a production version of the application, these static code analyzers seemed to be picking up the inclusion of the Google Firebase library (Used for FCM) as and flagging that, but as of last week we have excluded those parts that were getting flagged by Exodus and now we are passing https://reports.exodus-privacy.eu.org/en/reports/network.loki.messenger/latest/.

You can see the PR here https://github.com/loki-project/session-android/pull/219

Regarding FCM for push it is only ever used if the user opts in to use it,and there is a big onboarding screen explaining the consequences/benefits, you can use Session Google free if you just use background notifications.

We have never actually used Firebase analytics in a production version of the application, these static code analyzers seemed to be picking up the inclusion of the Google Firebase library (Used for FCM) as and flagging that, but as of last week we have excluded those parts that were getting flagged by Exodus and now we are passing https://reports.exodus-privacy.eu.org/en/reports/network.loki.messenger/latest/. You can see the PR here https://github.com/loki-project/session-android/pull/219 Regarding FCM for push it is only ever used if the user opts in to use it,and there is a big onboarding screen explaining the consequences/benefits, you can use Session Google free if you just use background notifications.
subsys-R9boq8 commented 2020-06-13 01:44:47 +00:00 (Migrated from github.com)

We have never actually used Firebase analytics in a production version of the application, these static code analyzers seemed to be picking up the inclusion of the Google Firebase library (Used for FCM) as and flagging that, but as of last week we have excluded those parts that were getting flagged by Exodus and now we are passing https://reports.exodus-privacy.eu.org/en/reports/network.loki.messenger/latest/.

You can see the PR here loki-project/session-android#219

Regarding FCM for push it is only ever used if the user opts in to use it,and there is a big onboarding screen explaining the consequences/benefits, you can use Session Google free if you just use background notifications.

Just checked the latest release and it's free of Firebase Analytics, thanks for the clarification!

> > > We have never actually used Firebase analytics in a production version of the application, these static code analyzers seemed to be picking up the inclusion of the Google Firebase library (Used for FCM) as and flagging that, but as of last week we have excluded those parts that were getting flagged by Exodus and now we are passing https://reports.exodus-privacy.eu.org/en/reports/network.loki.messenger/latest/. > > You can see the PR here [loki-project/session-android#219](https://github.com/loki-project/session-android/pull/219) > > Regarding FCM for push it is only ever used if the user opts in to use it,and there is a big onboarding screen explaining the consequences/benefits, you can use Session Google free if you just use background notifications. Just checked the latest release and it's free of Firebase Analytics, thanks for the clarification!
ph00lt0 commented 2020-06-13 09:27:12 +00:00 (Migrated from github.com)

thanks for clarifying @KeeJef

thanks for clarifying @KeeJef
net-zero-day commented 2020-07-02 22:20:24 +00:00 (Migrated from github.com)

Seems ok, the only thing I don't trust is that it's based in Australia.
https://loki.network/2018/12/10/lokis-response-to-the-assistance-and-access-bill-2018/

Seems ok, the only thing I don't trust is that it's based in Australia. https://loki.network/2018/12/10/lokis-response-to-the-assistance-and-access-bill-2018/
th3m commented 2020-07-12 00:42:01 +00:00 (Migrated from github.com)

A political view research regarding the loki network, that i believe it's important to be mentioned and taken into account:
https://nitter.net/WPalant/status/1281540005190672384

A political view research regarding the loki network, that i believe it's important to be mentioned and taken into account: https://nitter.net/WPalant/status/1281540005190672384
dngray commented 2020-07-12 10:22:21 +00:00 (Migrated from github.com)

I did look at the ABC article. It looks to be a similar situation to where the Tor Project find itself. Bad people can use good technology?

As we really don't know what was said, we can never determine to what extent "they helped". The word "inadvertent", might reflect they did not know who they were before helping them.

This German-language video shows Loki Network's main developer (Jeff/majestrate) pitch his baby on 8chan and being celebrated by the alt-right for it (at 27:46). For reference, Loki Network is the foundation of Session and developed by the same startup.

I did watch that video, and the only reference was this frame:

1594548809

How do we actually know it was written by @majestrate and not copy pasted from somewhere else?

I did look at the [ABC article](https://www.abc.net.au/news/science/2019-11-08/8chan-is-back-online-and-an-australian-startup-accidently-helped/11682438). It looks to be a similar situation to where the Tor Project find itself. Bad people can use good technology? As we really don't know what was said, we can never determine to what extent "they helped". The word "inadvertent", might reflect they did not know who they were before helping them. > This German-language video shows Loki Network's main developer (Jeff/majestrate) pitch his baby on 8chan and being celebrated by the alt-right for it (at 27:46). For reference, Loki Network is the foundation of Session and developed by the same startup. I did watch that video, and the only reference was this frame: ![1594548809](https://user-images.githubusercontent.com/48640805/87243897-54955f00-c429-11ea-94be-55752118006c.png) How do we actually know it was written by @majestrate and not copy pasted from somewhere else?
lrq3000 commented 2020-07-12 10:39:35 +00:00 (Migrated from github.com)

I am not convinced by the point raised either. First because I don't see any proof, only claims in the linked twitter thread, but also because that's basically the timeless security vs liberty philosophical and political problem. For example, medicine has always been used to conduct unethical experiments including torture or worse. This unfortunately shows that even the most honorable tools can be misused. Should we blame the tool, or the user who misuse?

IMO, the technical side also matters in this question. I think that as long as the tool is not operated by the developer and is opensource, who the developer is is ultimately irrelevant.

PS: thank you for making me discover nitter, didn't know this open front-end to Twitter, I guess we should re-examine #1402 now that Invidious is being added as a Worth Mentioning in #1974?

I am not convinced by the point raised either. First because I don't see any proof, only claims in the linked twitter thread, but also because that's basically the timeless security vs liberty philosophical and political problem. For example, medicine has always been used to [conduct unethical experiments](https://doi.org/10.13169/statecrime.2.1.0072) including [torture](https://www.opensocietyfoundations.org/publications/experiments-torture-evidence-human-subject-research-and-experimentation-enhanced) or [worse](https://www.mp.pl/auschwitz/journal/english/170062,pseudo-medical-experiments-in-hitlers-concentration-camps). This unfortunately shows that even the most honorable tools can be misused. Should we blame the tool, or the user who misuse? IMO, the technical side also matters in this question. I think that as long as the tool is not operated by the developer and is opensource, who the developer is is ultimately irrelevant. PS: thank you for making me discover nitter, didn't know this open front-end to Twitter, I guess we should re-examine #1402 now that Invidious is being added as a Worth Mentioning in #1974?
subsys-R9boq8 commented 2020-07-12 10:47:22 +00:00 (Migrated from github.com)

Guys, some of you have gone OT for very far, any issues that relate more to LokiNet than Session should be discussed at #1940 (Lokinet) but not #1678 (here).

Guys, some of you have gone OT for very far, any issues that relate more to LokiNet than Session should be discussed at #1940 (Lokinet) but not #1678 (here).
majestrate commented 2020-07-12 14:04:59 +00:00 (Migrated from github.com)

just to die up a loose end (further mud flinging can go into #1940 )

How do we actually know it was written by @majestrate and not copy pasted from somewhere else?

the aforementioned post was on a former contributor's imageboard, and since imageboards love to steal each other's style sheets it makes sense that it was confused with 8chan. original post from the screenshot is from https://endchan.net/tech/res/12870.html

just to die up a loose end (further mud flinging can go into #1940 ) >How do we actually know it was written by @majestrate and not copy pasted from somewhere else? the aforementioned post was on a former contributor's imageboard, and since imageboards love to steal each other's style sheets it makes sense that it was confused with 8chan. original post from the screenshot is from https://endchan.net/tech/res/12870.html
dngray commented 2020-07-12 14:41:31 +00:00 (Migrated from github.com)

@majestrate thanks for clarifying that. I got this feeling from that CCC speaker that it felt like he just wanted to show a bunch of alt-right propaganda/meme/shock material to viewers, I think it could have done with a lot less of that and still gotten his point across.

We should get this back on-topic.

@majestrate thanks for clarifying that. I got this feeling from that CCC speaker that it felt like he just wanted to show a bunch of alt-right propaganda/meme/shock material to viewers, I think it could have done with a lot less of that and still gotten his point across. We should get this back on-topic.
subsys-R9boq8 commented 2020-07-20 14:16:01 +00:00 (Migrated from github.com)

I might have missing some function, but I didn't see anything like Signal's "safety number". Why is that? Can session or the lower LokiNet platform prove that I am talking to the person with no insider interference (Like MITM), or is the platform naturally immune to this kind of attack?

I might have missing some function, but I didn't see anything like Signal's "safety number". Why is that? Can session or the lower LokiNet platform prove that I am talking to the person with no insider interference (Like MITM), or is the platform naturally immune to this kind of attack?
KeeJef commented 2020-07-21 02:31:31 +00:00 (Migrated from github.com)

@subsys-R9boq8 We do have the ability to view a users safety number on desktop, it should be on all platforms, not sure why it got removed. However the security model is quite different than Signal, since Signal users can change their underlying key pairs without breaking a session (Phone number is ultimate truth) whereas your identity (SessionID) in Session is actually your public key meaning you cant change it.

This means that if you talk to someone with X session ID, you know you are speaking to them and there is no TOFU or MITM attack possible (as long as the out of band Session ID sharing is done properly). However it still makes sense to have safety numbers because someone out of band might claim to be X person when they are Y person, if you speak to X person in real life or through some secure means then you can either compare Session ID's or safety numbers, however safety numbers are a little easier to compare (Have a QR code and nice formatted representation)

@subsys-R9boq8 We do have the ability to view a users safety number on desktop, it should be on all platforms, not sure why it got removed. However the security model is quite different than Signal, since Signal users can change their underlying key pairs without breaking a session (Phone number is ultimate truth) whereas your identity (SessionID) in Session is actually your public key meaning you cant change it. This means that if you talk to someone with X session ID, you know you are speaking to them and there is no TOFU or MITM attack possible (as long as the out of band Session ID sharing is done properly). However it still makes sense to have safety numbers because someone out of band might claim to be X person when they are Y person, if you speak to X person in real life or through some secure means then you can either compare Session ID's or safety numbers, however safety numbers are a little easier to compare (Have a QR code and nice formatted representation)
ghost commented 2020-09-15 15:16:06 +00:00 (Migrated from github.com)

Why are you using legacy GPG version 1.4? https://github.com/loki-project/session-android/releases

Why are you using legacy GPG version 1.4? https://github.com/loki-project/session-android/releases
KeeJef commented 2020-09-16 05:19:22 +00:00 (Migrated from github.com)

@ZarusMods No particular reason, is there a compelling reason to update? CVE or something?

@ZarusMods No particular reason, is there a compelling reason to update? CVE or something?
LorisTecnology commented 2021-03-06 17:37:28 +00:00 (Migrated from github.com)

i use it
is great and is even better now that have added multi device sync

i use it is great and is even better now that have added multi device sync
ghost commented 2021-04-30 18:40:31 +00:00 (Migrated from github.com)

Session's code audit is done:
https://getsession.org/session-code-audit/

Session's code audit is done: https://getsession.org/session-code-audit/
KeeJef commented 2021-05-10 01:21:14 +00:00 (Migrated from github.com)

I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site

  • The app is added to F-Droid
  • The cross platform refactor is finished (This is about 2-4 weeks away) this will vastly improve message sending reliability, especially when dealing with multi device functionality
  • Full three hop onion routing is enabled in Session, instead of one hop proxy routing.
  • Closed group size is expanded

All of this is finished now, took us a lot longer than expected 😂 Session is now much less buggy than it was a year ago, i don't know exactly how this process works but i think moving forward on further research or putting a recommendation into https://privacytools.io now would be great

> I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site > > * The app is added to F-Droid > * The cross platform refactor is finished (This is about 2-4 weeks away) this will vastly improve message sending reliability, especially when dealing with multi device functionality > * Full three hop onion routing is enabled in Session, instead of one hop proxy routing. > * Closed group size is expanded All of this is finished now, took us a lot longer than expected 😂 Session is now much less buggy than it was a year ago, i don't know exactly how this process works but i think moving forward on further research or putting a recommendation into https://privacytools.io now would be great
lrq3000 commented 2021-05-10 12:05:43 +00:00 (Migrated from github.com)

Thank you for the update @KeeJef. Very exciting news! I'm very happy to see this much progress and work!

Adding on privacytools is on a volunteer basis, so it just depends on whether someone decides to make the adequate file modifications and then if peers accept the changes after review.

I have a few questions before I see if I can make the changes:

  1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance).
  2. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route.
  3. Who runs the nodes used in the onion routing?
  4. Do you have an estimation for the migration of Session onto the Lokinet network?
Thank you for the update @KeeJef. Very exciting news! I'm very happy to see this much progress and work! Adding on privacytools is on a volunteer basis, so it just depends on whether someone decides to make the adequate file modifications and then if peers accept the changes after review. I have a few questions before I see if I can make the changes: 1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance). 2. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route. 3. Who runs the nodes used in the onion routing? 4. Do you have an estimation for the migration of Session onto the Lokinet network?
lrq3000 commented 2021-05-10 12:10:04 +00:00 (Migrated from github.com)

Also BTW I have tested the app both on desktop and Android, and I must say the stability and reliability has indeed vastly improved, same for the registration process which creates a private key very easily and transparently, so I can confirm the app is ready for non-technical end user use as a text messenger (voice calls not available until Session migrates to the Lokinet network using UDP instead of TCP). It also now supports both public and private groups.

The app on Android also asks on registration or first launch whether to use Google notification servers or not, in the latter case the notifications aren't immediate as the app needs to fetch updates itself, but it fully protects all metadata then. Very nice to have implemented this suggestion :D

@KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.

Also BTW I have tested the app both on desktop and Android, and I must say the stability and reliability has indeed vastly improved, same for the registration process which creates a private key very easily and transparently, so I can confirm the app is ready for non-technical end user use as a text messenger (voice calls not available until Session migrates to the Lokinet network using UDP instead of TCP). It also now supports both public and private groups. The app on Android also asks on registration or first launch whether to use Google notification servers or not, in the latter case the notifications aren't immediate as the app needs to fetch updates itself, but it fully protects all metadata then. Very nice to have implemented this suggestion :D @KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.
KeeJef commented 2021-05-11 03:47:01 +00:00 (Migrated from github.com)
  1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance).

Yes, its actually something that we have an intern assigned to now, this issue should track progress https://github.com/oxen-io/session-desktop/issues/1492

  1. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route.

Theres no button in the app to do this, since we tend to prefer to continue to use good random routes rather than rotate users into potentially unstable routes, and depending on a users preferences for route selection allowing then to change their route could offer potential for some more subtle attacks.

  1. Who runs the nodes used in the onion routing?

Routers are Service Nodes in the Oxen blockchain network, the number of nodes and distribution can be found here https://oxendashboard.com/#5

  1. Do you have an estimation for the migration of Session onto the Lokinet network?

Its going to take some time, we have just finished the core of liblokinet which should allow the mobile applications to more easily integrate with Lokinet, but its still going to take work, so its hard to give an estimation. For now we are OK continuing to use Onion requests, but we will need Lokinet integration for features like voice calling.

> 1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance). Yes, its actually something that we have an intern assigned to now, this issue should track progress https://github.com/oxen-io/session-desktop/issues/1492 > 2. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route. Theres no button in the app to do this, since we tend to prefer to continue to use good random routes rather than rotate users into potentially unstable routes, and depending on a users preferences for route selection allowing then to change their route could offer potential for some more subtle attacks. > 3. Who runs the nodes used in the onion routing? Routers are Service Nodes in the Oxen blockchain network, the number of nodes and distribution can be found here https://oxendashboard.com/#5 > 4. Do you have an estimation for the migration of Session onto the Lokinet network? Its going to take some time, we have just finished the core of liblokinet which should allow the mobile applications to more easily integrate with Lokinet, but its still going to take work, so its hard to give an estimation. For now we are OK continuing to use Onion requests, but we will need Lokinet integration for features like voice calling.
KeeJef commented 2021-05-11 03:48:46 +00:00 (Migrated from github.com)

@KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.

Hmm this might be something we look into, if you wanted to file an issue for that we could look at it in an upcoming release

> @KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work. Hmm this might be something we look into, if you wanted to file an issue for that we could look at it in an upcoming release
lrq3000 commented 2021-05-12 17:15:55 +00:00 (Migrated from github.com)

Ok thank you for your clarifications. I think it's time to make a PR, we'll
see what the peer reviews says.

To mabe my job easier, could you please clarify the following:

About forcing a new route, i meant to do something like Tor Browser is
doing, such as simply relaunching the whole client to force generate a new
random route. I understand the security issuks otherwise. The issue you
linked to already asked for this feature for performance reason (ie,
unreliable network) instead of security but implementing it will fit both.

About the nodes, i can see thad they are well distributed over the world,
nice charts. Can you precise who are currently running these nodes? Users
of the Oxen blockchain who are incentivized by the proof of stake algo or
are most nodes yours at the moment?

Finally, could you please clarify how the whole ecosystem is connected and
what each piece is doing in the big picture? Before i think lokinet was
supposed to be the blockchain and llarp combined, but now it seems that
Oxen is the blockchain which provides TCP onion routing and encryption ,
Lokinet which will be the llarp fast udp onion network that will work in
tandem with Oxen. Session uses Oxen only for now and in the future will use
both Oxen and Lokined, switching transparently when fast data transfer is
needed. Is that an accurate overview?

Le mar. 11 mai 2021 à 05:49, Kee Jefferys @.***> a
écrit :

@KeeJef https://github.com/KeeJef I have one suggestion about the
registration process on desktop, it doesn't require the user to copy/save
the private key as it does on mobile, so non technical users may
unknowingly lose their account if they create one on desktop and aren't
aware of how blockchains work.

Hmm this might be something we look into, if you wanted to file an issue
for that we could look at it in an upcoming release


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/privacytools/privacytools.io/issues/1678#issuecomment-837745751,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIRFXUONJAQBF4IWYSVPPLTNCSLDANCNFSM4KOP2STA
.

Ok thank you for your clarifications. I think it's time to make a PR, we'll see what the peer reviews says. To mabe my job easier, could you please clarify the following: About forcing a new route, i meant to do something like Tor Browser is doing, such as simply relaunching the whole client to force generate a new random route. I understand the security issuks otherwise. The issue you linked to already asked for this feature for performance reason (ie, unreliable network) instead of security but implementing it will fit both. About the nodes, i can see thad they are well distributed over the world, nice charts. Can you precise who are currently running these nodes? Users of the Oxen blockchain who are incentivized by the proof of stake algo or are most nodes yours at the moment? Finally, could you please clarify how the whole ecosystem is connected and what each piece is doing in the big picture? Before i think lokinet was supposed to be the blockchain and llarp combined, but now it seems that Oxen is the blockchain which provides TCP onion routing and encryption , Lokinet which will be the llarp fast udp onion network that will work in tandem with Oxen. Session uses Oxen only for now and in the future will use both Oxen and Lokined, switching transparently when fast data transfer is needed. Is that an accurate overview? Le mar. 11 mai 2021 à 05:49, Kee Jefferys ***@***.***> a écrit : > @KeeJef <https://github.com/KeeJef> I have one suggestion about the > registration process on desktop, it doesn't require the user to copy/save > the private key as it does on mobile, so non technical users may > unknowingly lose their account if they create one on desktop and aren't > aware of how blockchains work. > > Hmm this might be something we look into, if you wanted to file an issue > for that we could look at it in an upcoming release > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/privacytools/privacytools.io/issues/1678#issuecomment-837745751>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAIRFXUONJAQBF4IWYSVPPLTNCSLDANCNFSM4KOP2STA> > . >
KeeJef commented 2021-05-14 01:29:13 +00:00 (Migrated from github.com)

About the nodes, i can see thad they are well distributed over the world,
nice charts. Can you precise who are currently running these nodes? Users
of the Oxen blockchain who are incentivized by the proof of stake algo or
are most nodes yours at the moment?

The vast majority of nodes in the network are run by community members, the largest single operator of Service Nodes in the network is the OPTF who runs about ~9% of the networks Service Nodes. Anyone can start a Service Node and begin earning rewards if they have the required stake to do so.

lokinet was supposed to be the blockchain and llarp combined, but now it seems that
Oxen is the blockchain which provides TCP onion routing and encryption ,
Lokinet which will be the llarp fast udp onion network that will work in
tandem with Oxen. Session uses Oxen only for now and in the future will use
both Oxen and Lokined, switching transparently when fast data transfer is
needed. Is that an accurate overview?

Session currently uses a system called onion requests for onion routing, which is TCP based, this system still uses the ~1750 Service Nodes to onion route all messages, but it doesn't use Lokinet. Onion requests are single shot, which means you send a request and get a response, they don't allow a user to hold a onion routed connection open with a Service Node or other Session client.

Lokinet is a different onion router which can route any IP based protocol, it also uses the Service Node network to create routes through the network, however because Lokinet can route any IP based protocol it is much more versatile, and it can keep connections open with the Service Node network to be able to stream data. Lokinet is slated for future implementation, since it will help us provide voice calling and other functionality.

> About the nodes, i can see thad they are well distributed over the world, > nice charts. Can you precise who are currently running these nodes? Users > of the Oxen blockchain who are incentivized by the proof of stake algo or > are most nodes yours at the moment? The vast majority of nodes in the network are run by community members, the largest single operator of Service Nodes in the network is the [OPTF](https://optf.ngo/) who runs about ~9% of the networks Service Nodes. Anyone can start a Service Node and begin earning rewards if they have the required stake to do so. > lokinet was supposed to be the blockchain and llarp combined, but now it seems that > Oxen is the blockchain which provides TCP onion routing and encryption , > Lokinet which will be the llarp fast udp onion network that will work in > tandem with Oxen. Session uses Oxen only for now and in the future will use > both Oxen and Lokined, switching transparently when fast data transfer is > needed. Is that an accurate overview? Session currently uses a system called onion requests for onion routing, which is TCP based, this system still uses the ~1750 Service Nodes to onion route all messages, but it doesn't use Lokinet. Onion requests are single shot, which means you send a request and get a response, they don't allow a user to hold a onion routed connection open with a Service Node or other Session client. Lokinet is a different onion router which can route any IP based protocol, it also uses the Service Node network to create routes through the network, however because Lokinet can route any IP based protocol it is much more versatile, and it can keep connections open with the Service Node network to be able to stream data. Lokinet is slated for future implementation, since it will help us provide voice calling and other functionality.
lrq3000 commented 2021-05-15 03:39:54 +00:00 (Migrated from github.com)

Thank you @KeeJef for the additional clarifications.

I have opened a PR at #2293, it's going to take some time for review, hopefully the editorial board will greenlight it.

Thank you @KeeJef for the additional clarifications. I have opened a PR at #2293, it's going to take some time for review, hopefully the editorial board will greenlight it.
lrq3000 commented 2021-05-30 00:29:24 +00:00 (Migrated from github.com)

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes
KeeJef commented 2021-05-30 05:42:09 +00:00 (Migrated from github.com)

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

This is only really relevant for Lokinet, Session traffic doesn't exit the network in any way where it could be hijacked, Lokinet does have exits but doesn't have a publicly incentivised infrastructure yet, but yes we are aware of these issues in Tor.

> @KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes This is only really relevant for Lokinet, Session traffic doesn't exit the network in any way where it could be hijacked, Lokinet does have exits but doesn't have a publicly incentivised infrastructure yet, but yes we are aware of these issues in Tor.
majestrate commented 2021-05-30 13:56:49 +00:00 (Migrated from github.com)

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

i agree it could be a problem but it is probably far less of an issue as lokinet exits are not picking from a giant pool of randos, you manually choose your exit so if some bad actor is running an exit no one will use it (free market regulating itself etc), additionally as @KeeJef pointed out, session wont be using exits anyways so it is probably not an attack that is in scope for it.

> @KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes i agree it could be a problem but it is probably far less of an issue as lokinet exits are not picking from a giant pool of randos, you manually choose your exit so if some bad actor is running an exit no one will use it (free market regulating itself etc), additionally as @KeeJef pointed out, session wont be using exits anyways so it is probably not an attack that is in scope for it.
Victor239 commented 2021-06-03 09:21:15 +00:00 (Migrated from github.com)

Lokinet/Session aren't suitable for PTIO:

Lokinet/Session is based in Australia, which makes it a non-starter for PrivacyTools.io thanks to it's 2018 Access and Assistance Bill (AKA gov can force them to introduce vulnerabilities into their encryption tech and not disclose this) as well as the likely forthcoming Identify and Disrupt bill which allows hijacking darknet providers accounts (like Lokinet) if authorities believe serious crimes are taking place on it (i.e. every darknet provider in Australia is at risk).

https://github.com/privacytools/privacytools.io/issues/1940#issuecomment-853722071

Lokinet/Session aren't suitable for PTIO: > Lokinet/Session is based in Australia, which makes it a non-starter for PrivacyTools.io thanks to it's 2018 Access and Assistance Bill (AKA gov can force them to introduce vulnerabilities into their encryption tech and not disclose this) as well as the likely forthcoming Identify and Disrupt bill which allows hijacking darknet providers accounts (like Lokinet) if authorities believe serious crimes are taking place on it (i.e. every darknet provider in Australia is at risk). https://github.com/privacytools/privacytools.io/issues/1940#issuecomment-853722071
lrq3000 commented 2021-06-09 18:01:28 +00:00 (Migrated from github.com)

Please read the discussion pointed by @Victor239 but I don't think that this legislation impacts Lokinet/Session any differently than other communication softwares, so I'm not sure why this would make Session unsuitable for PTIO compared to competitors, if anything Session appears to be more resilient given its onion routing architecture that others lack.

Please read the discussion pointed by @Victor239 but I don't think that this legislation impacts Lokinet/Session any differently than other communication softwares, so I'm not sure why this would make Session unsuitable for PTIO compared to competitors, if anything Session appears to be more resilient given its onion routing architecture that others lack.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1678
No description provided.