Future of Tor Messenger
Hi, As some of you may have already noticed, the Instantbird team (the chat client on which Tor Messenger is based) has announced that it will no longer maintain the user interface for Instantbird and instead will work towards improving the existing chat support in Thunderbird: http://blog.queze.net/post/2017/10/18/Thunderbird-is-the-next-version-of-Ins... So far, we have been maintaining two products: Tor Messenger and TorBirdy, and this change is an opportunity to consolidate those efforts into one application, which we are tentatively calling "Tor Communicator". By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. (This change will only take effect at the next ESR major version bump, in March 2018.) We would still like to stay within the Mozilla ecosystem so that we can continue making use of technologies like Tor Launcher and the secure automatic updater patches from Tor Browser. While we have not done builds for Tor Communicator yet, we expect no restrictions on the technical side as we have released "Tor Mail" bundles in the past. Tor Messenger releases have been based on Thunderbird's ESR schedule as Instantbird releases have been infrequent. This has been possible because Thunderbird and Instantbird share a common source tree in the comm-central repository. There is also the question of the future of Thunderbird itself, summarized in the "A Bright Future" section in the blog post detailing Thunderbird's future: https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/ By making this switch: - Users will get access to secure chat from Tor Messenger and secure email from TorBirdy, in a single application - Thunderbird has a single-window chat interface which is different from Instantbird (and better) - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter - Users will get a Tor Mail application which has been requested for a while The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts! -- Sukhbir
Just wanted to add something so there is no confusion: this is what we in the Tor Messenger team think and want to do in theory. We have not started work on it and we will not before discussing it with the community, which is what the previous email is about. -- Sukhbir
Sukhbir Singh:
Hi,
As some of you may have already noticed, the Instantbird team (the chat client on which Tor Messenger is based) has announced that it will no longer maintain the user interface for Instantbird and instead will work towards improving the existing chat support in Thunderbird:
http://blog.queze.net/post/2017/10/18/Thunderbird-is-the-next-version-of-Ins...
So far, we have been maintaining two products: Tor Messenger and TorBirdy, and this change is an opportunity to consolidate those efforts into one application, which we are tentatively calling "Tor Communicator". By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. (This change will only take effect at the next ESR major version bump, in March 2018.) We would still like to stay within the Mozilla ecosystem so that we can continue making use of technologies like Tor Launcher and the secure automatic updater patches from Tor Browser.
While we have not done builds for Tor Communicator yet, we expect no restrictions on the technical side as we have released "Tor Mail" bundles in the past. Tor Messenger releases have been based on Thunderbird's ESR schedule as Instantbird releases have been infrequent. This has been possible because Thunderbird and Instantbird share a common source tree in the comm-central repository.
There is also the question of the future of Thunderbird itself, summarized in the "A Bright Future" section in the blog post detailing Thunderbird's future:
https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
By making this switch:
- Users will get access to secure chat from Tor Messenger and secure email from TorBirdy, in a single application - Thunderbird has a single-window chat interface which is different from Instantbird (and better) - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter - Users will get a Tor Mail application which has been requested for a while
The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts!
Could you elaborate on what you mean with """ By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. """ and """ By making this switch: - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter """ Are you planning to maintain two applications now? That is Tor Messenger and some mail bundle? If not, should there be a transition? If so, how would that look like given that Mozilla is on its way to remove Instantbird code from the tree?[1] Georg [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1410739
* Georg Koppen:
By making this switch:
- Users will get access to secure chat from Tor Messenger and secure email from TorBirdy, in a single application - Thunderbird has a single-window chat interface which is different from Instantbird (and better) - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter - Users will get a Tor Mail application which has been requested for a while
The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts!
Could you elaborate on what you mean with
""" By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. """
and
""" By making this switch:
- We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter """
Are you planning to maintain two applications now? That is Tor Messenger and some mail bundle? If not, should there be a transition? If so, how would that look like given that Mozilla is on its way to remove Instantbird code from the tree?[1]
What I meant by this was that we will ship Thunderbird with both email and chat support; email provided by TorBirdy, and chat provided by the code that is already there in Tor Messenger plus the code which the Instantbird team will merge and maintain. As per the Instantbird blog post, "Instead of working on Instantbird, we'll refocus our energy on improving the chat features in Thunderbird, so that it becomes friendly for users who loved Instantbird and will seek a replacement." So they are just doing away with the interface but the chat code will still be there. So what this transition means is that we stop building on Instantbird and start building on Thunderbird instead (with chat and mail support), copy over whatever changes are required from the existing code and working on the new features where required. -- Sukhbir
On 10/24/17 17:11, Sukhbir Singh wrote:
Hi,
As some of you may have already noticed, the Instantbird team (the chat client on which Tor Messenger is based) has announced that it will no longer maintain the user interface for Instantbird and instead will work towards improving the existing chat support in Thunderbird:
http://blog.queze.net/post/2017/10/18/Thunderbird-is-the-next-version-of-Ins...
So far, we have been maintaining two products: Tor Messenger and TorBirdy, and this change is an opportunity to consolidate those efforts into one application, which we are tentatively calling "Tor Communicator". By doing this, we can continue maintaining Tor Messenger for our users and adding new features to it, and also prototype the "Tor Mail" bundle as has been requested in the past. (This change will only take effect at the next ESR major version bump, in March 2018.) We would still like to stay within the Mozilla ecosystem so that we can continue making use of technologies like Tor Launcher and the secure automatic updater patches from Tor Browser.
While we have not done builds for Tor Communicator yet, we expect no restrictions on the technical side as we have released "Tor Mail" bundles in the past. Tor Messenger releases have been based on Thunderbird's ESR schedule as Instantbird releases have been infrequent. This has been possible because Thunderbird and Instantbird share a common source tree in the comm-central repository.
There is also the question of the future of Thunderbird itself, summarized in the "A Bright Future" section in the blog post detailing Thunderbird's future:
https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/
By making this switch:
- Users will get access to secure chat from Tor Messenger and secure email from TorBirdy, in a single application - Thunderbird has a single-window chat interface which is different from Instantbird (and better) - We can continue supporting Tor Messenger as a chat client for IRC/Jabber/Twitter - Users will get a Tor Mail application which has been requested for a while
The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts!
Ok! here is a complete different idea :) We don't use Thunderbird at all. We build on the Browser (Tor Browser). We can start by creating a chat client, maybe a chat .onion service one like ricochet. By doing it on the browser, now that TB will be working on mobile as well, it would be easier to have this chat thing working on mobile. Latter on it could even grow with more features like a .onion service file sharing thing (like onionshare).. Thunderbird has way less resources than FF + Tor Browser. If we go that route we might find ourselves in a similar situation eventually. If we build on the top of Tor Browser it will have a better chance for a long term support. Note: I don't know anything related to building any of the things I suggested above :) maybe is just impossible or too scary (cuz of security reasons) cheers, Isabela
isabela <isabela@torproject.org> writes:
On 10/24/17 17:11, Sukhbir Singh wrote:
Hi,
<snip>
The idea behind this email is to brainstorm this switch and solicit feedback from the community, so please share your thoughts!
Ok! here is a complete different idea :)
We don't use Thunderbird at all.
We build on the Browser (Tor Browser). We can start by creating a chat client, maybe a chat .onion service one like ricochet.
I hate to diverge the original discussion but I'd like to echo this idea. I think it's a great one for multiple reasons. One of the main reasons I like it is because it binds various Tor concepts together in a way that shows consistency in Tor's plans and strategy. I feel that this thematic consistency is something important that we've been missing, and it's one of the reasons that the messenger efforts have been more neglected than the browser work. Specifically, I feel that providing different products for different use cases ("browse with Tor browser, chat with Tor messenger") confuses people a lot, because it requires them to understand two different UXs, and download two different softwares. It also makes them wonder whether "Tor messenger is still supported" (a question I've been asked a lot of times in the past), and also it requires us supporting two tor binaries, two update mechanisms, etc. On the other hand, I feel that, if we use the Tor Browser as our _central product_ and then build features aorund it we can have a much better UX for our users. It also provides more hype and anticipation to our releases in the sense that "Tor browser release X will have anon chat support!", "Tor browser release Y will have anon file browsing support!", instead of splitting the hype into 2 different products. Hype is good and healthy! Furthermore, by doing an onion service chat on the browser, we are binding various Tor visions (Tor browser + onion + anon chat) together to create a new experience on the one product that everyone should have (the browser).
By doing it on the browser, now that TB will be working on mobile as well, it would be easier to have this chat thing working on mobile.
That's true. However depending on how this chat software gets implemented, it might be much harder to port it to mobile, in a way that delays the whole project. We should be careful here. Unfortunately, I don't really know how Tor Browser plugins work and how hard such a project would be, so I can only hype it for now...
Latter on it could even grow with more features like a .onion service file sharing thing (like onionshare)..
Yes! Yes! More features for Tor users!
* George Kadianakis:
I hate to diverge the original discussion but I'd like to echo this idea. I think it's a great one for multiple reasons.
No that's perfectly fine -- that was the idea behind the email! New ideas like the one Isabela suggested are welcome and encouraged. Like I said, that is why we are looking for feedback.
One of the main reasons I like it is because it binds various Tor concepts together in a way that shows consistency in Tor's plans and strategy. I feel that this thematic consistency is something important that we've been missing, and it's one of the reasons that the messenger efforts have been more neglected than the browser work.
Specifically, I feel that providing different products for different use cases ("browse with Tor browser, chat with Tor messenger") confuses people a lot, because it requires them to understand two different UXs, and download two different softwares. It also makes them wonder whether "Tor messenger is still supported" (a question I've been asked a lot of times in the past), and also it requires us supporting two tor binaries, two update mechanisms, etc.
That's true, it solves a lot of the problems with the adaptability of "Tor Messenger".
On the other hand, I feel that, if we use the Tor Browser as our _central product_ and then build features aorund it we can have a much better UX for our users.
It also provides more hype and anticipation to our releases in the sense that "Tor browser release X will have anon chat support!", "Tor browser release Y will have anon file browsing support!", instead of splitting the hype into 2 different products. Hype is good and healthy!
Furthermore, by doing an onion service chat on the browser, we are binding various Tor visions (Tor browser + onion + anon chat) together to create a new experience on the one product that everyone should have (the browser).
By doing it on the browser, now that TB will be working on mobile as well, it would be easier to have this chat thing working on mobile.
That's true. However depending on how this chat software gets implemented, it might be much harder to port it to mobile, in a way that delays the whole project. We should be careful here.
Unfortunately, I don't really know how Tor Browser plugins work and how hard such a project would be, so I can only hype it for now...
All great points, and yes, we still have to figure out how to implement this and in what way if we go ahead with this idea. I will wait for others to comment and see if this is the direction we want to take and then I guess we go into the technical discussions. -- Sukhbir
George Kadianakis:
isabela <isabela@torproject.org> writes:
On 10/24/17 17:11, Sukhbir Singh wrote: <snip>
Latter on it could even grow with more features like a .onion service file sharing thing (like onionshare)..
Yes! Yes! More features for Tor users!
First I wanna thank Sukhbir for providing this really detailed workplan and his commitment to giving Tor users a safer way to email and chat. I also think this is a really cool brainstorm and I agree with Isa and George about uniting Tor's products around common themes. I also want to flag that the email part of Sukhbir's original idea is a really essential component. Email is used way more than chat. Popular email providers, like gmail, don't work very well in Tor Browser (they work just fine in Thunderbird). The filesharing extension would solve some of the needs people have with email, but not all. I don't know how to reconcile this, just acknowledging that it remains a problem. Alison
* Alison Macrina:
I also think this is a really cool brainstorm and I agree with Isa and George about uniting Tor's products around common themes.
I also want to flag that the email part of Sukhbir's original idea is a really essential component. Email is used way more than chat. Popular email providers, like gmail, don't work very well in Tor Browser (they work just fine in Thunderbird). The filesharing extension would solve some of the needs people have with email, but not all. I don't know how to reconcile this, just acknowledging that it remains a problem.
That's a great point as well. So if we do go with chat in Tor Browser, we will still continue maintaining TorBirdy because other than what you mentioned about Gmail not being supported, Thunderbird offers support for add-ons like Enigmail which people prefer as compared to browser alternatives like Mailvelope. So regardless of the decision we make, I think we will continue working on TorBirdy because the only alternative to that is using email in the browser :) -- Sukhbir
* isabela:
Ok! here is a complete different idea :)
We don't use Thunderbird at all.
We build on the Browser (Tor Browser). We can start by creating a chat client, maybe a chat .onion service one like ricochet.
By doing it on the browser, now that TB will be working on mobile as well, it would be easier to have this chat thing working on mobile.
Latter on it could even grow with more features like a .onion service file sharing thing (like onionshare)..
Thunderbird has way less resources than FF + Tor Browser. If we go that route we might find ourselves in a similar situation eventually.
If we build on the top of Tor Browser it will have a better chance for a long term support.
Note: I don't know anything related to building any of the things I suggested above :) maybe is just impossible or too scary (cuz of security reasons)
I really like the idea and it does solve some of the related issues as well. I have not given much thought to it -- the technical aspect as well -- and I am waiting to see what others have to say. The only issue I think will be that some users may not be happy that we are bundling this with Tor Browser, but I am sure we can come up with a way for them to opt out. -- Sukhbir
On Wed, Oct 25, 2017 at 5:00 AM, isabela <isabela@torproject.org> wrote:
We build on the Browser (Tor Browser). We can start by creating a chat client, maybe a chat .onion service one like ricochet.
I think this is a very cool idea. Chat protocols such as ricochet have the problem of growing the network large enough to be useful (the network effect). By building it into Tor Browser you would already have millions of potential users who can communicate with one another. However, there have been a number of chat clients integrated in browsers (such as Netscape Communicator, Firefox Hello, etc.) but most have eventually been discontinued. It would be good to understand why that is. On Wed, Oct 25, 2017 at 8:03 AM, Alison Macrina <alison@torproject.org> wrote:
Email is used way more than chat.
One type of chat that is extremely popular is mobile messaging (text messages, WhatsApp, Facebook Messenger, QQ Mobile, Snapchat etc.) I think a metadata-free mobile messaging app (similar to ricochet) is likely to be much more popular than any desktop chat app. So if we're looking how to transition to a new chat product, I would strongly consider switching to a focus on mobile, regardless of whether it's integrated with the browser. In general, I would advocate taking a cold, hard look at user numbers, both in terms of our own apps and apps in the same markets (chat, email, etc.). I think we should try to focus on what most users want.
* Arthur D. Edelstein:
However, there have been a number of chat clients integrated in browsers (such as Netscape Communicator, Firefox Hello, etc.) but most have eventually been discontinued. It would be good to understand why that is.
Good idea. But one of the things we do differently (other than of course Tor) is for example OTR by default and we support things like OTR over Twitter DMs. I think it is these features that make us different from other chat clients, that we designed it with security and privacy in mind and not the other way round.
One type of chat that is extremely popular is mobile messaging (text messages, WhatsApp, Facebook Messenger, QQ Mobile, Snapchat etc.) I think a metadata-free mobile messaging app (similar to ricochet) is likely to be much more popular than any desktop chat app. So if we're looking how to transition to a new chat product, I would strongly consider switching to a focus on mobile, regardless of whether it's integrated with the browser.
In general, I would advocate taking a cold, hard look at user numbers, both in terms of our own apps and apps in the same markets (chat, email, etc.). I think we should try to focus on what most users want.
I agree that mobile is important (and indeed in some countries, people just use smart phones to communicate) but my (personal) opinion on this topic is that mobile is not the platform we want to target, at least with "Tor Messenger". Now of course an argument can be made that we can transition the same patches, but that's not the main idea. I think there are other apps in the space already that are doing a better job than we could, unless of course we work on something like Ricochet for smartphones. That is why when asked, "Is there something like Tor Messenger for mobile?" to which our answer has been, "No and there are no plans. Use Signal/something by the Guardian Project." The kind of users I (and I cannot speak for the rest of the team) have in mind with something like "Tor Messenger" are the ones that need to use messaging on desktop for Twitter, XMPP, IRC, and that we can enable them to do so securely. Unless of course we do something like Ricochet on mobile, which would then beg the question if we should abandon the desktop space altogether and leave it to Pidgin and Adium? -- Sukhbir
Sukhbir Singh:
* Arthur D. Edelstein:
One type of chat that is extremely popular is mobile messaging (text messages, WhatsApp, Facebook Messenger, QQ Mobile, Snapchat etc.) I think a metadata-free mobile messaging app (similar to ricochet) is likely to be much more popular than any desktop chat app. So if we're looking how to transition to a new chat product, I would strongly consider switching to a focus on mobile, regardless of whether it's integrated with the browser.
In general, I would advocate taking a cold, hard look at user numbers, both in terms of our own apps and apps in the same markets (chat, email, etc.). I think we should try to focus on what most users want.
I agree that mobile is important (and indeed in some countries, people just use smart phones to communicate) but my (personal) opinion on this topic is that mobile is not the platform we want to target, at least with "Tor Messenger". Now of course an argument can be made that we can transition the same patches, but that's not the main idea. I think there are other apps in the space already that are doing a better job than we could, unless of course we work on something like Ricochet for smartphones. That is why when asked, "Is there something like Tor Messenger for mobile?" to which our answer has been, "No and there are no plans. Use Signal/something by the Guardian Project."
The kind of users I (and I cannot speak for the rest of the team) have in mind with something like "Tor Messenger" are the ones that need to use messaging on desktop for Twitter, XMPP, IRC, and that we can enable them to do so securely. Unless of course we do something like Ricochet on mobile, which would then beg the question if we should abandon the desktop space altogether and leave it to Pidgin and Adium?
Tor Messenger is a nice experiment and I think we have learned a lot so far. Now that a central part of it, Instantbird, is officially dead it's a good time to think about requirements for the next chat application we plan (if we want to have any at all). From my point of view there are at least two of those requirements: 1) It should not be a desktop-only application. Given that we hope to reach mobile-only users not planning with them in mind does not sound right to me. Moreover, I bet there are a bunch of non-mobile-only users that are using mobile heavily as well and who don't want to have different chat applications with different UI, different functionality etc. for different devices. They want to communicate with their friends the same way regardless whether they are on mobile or not. You would not want to make a Windows-only chat application either because most of our users are currently on that platform, right (and they might be the ones that need a secured chat environment the most)? So, let's tear this desktop/mobile barrier down while thinking about the future. 2) It should support onion service-based chat protocols. Those are a good showcase for metadata-free chat/messaging and we should support that + convince users to switch to them. Georg
On Thu, Oct 26, 2017 at 7:47 AM, Georg Koppen <gk@torproject.org> wrote: [snip]
1) It should not be a desktop-only application. [snip] So, let's tear this desktop/mobile barrier down while thinking about the future. 2) It should support onion service-based chat protocols. [snip]
I wholeheartedly agree with these points. I would only add that for chat apps in general, mobile has perhaps 20x-100x the users that desktop has.[1] So if one had to initially choose between mobile and desktop because of limited resources, I would suggest starting with mobile and expanding to desktop as funding grew. Similar to Signal's approach. [1] The biggest desktop chat apps appear to be: - Slack, with ~9 million weekly users: (https://expandedramblings.com/index.php/slack-statistics/) - Discord, with ~9 million daily active users and 45 million registered users: https://venturebeat.com/2017/05/16/discords-game-voice-communications-app-hi...). Whereas the most popular mobile chat apps are apparently WhatsApp, Facebook Messenger, QQ Mobile, and WeChat with close to 1 billion users each: https://www.statista.com/statistics/258749/most-popular-global-mobile-messen...
On 10/26/17 04:16, Arthur D. Edelstein wrote:
On Thu, Oct 26, 2017 at 7:47 AM, Georg Koppen <gk@torproject.org> wrote:
[snip]
1) It should not be a desktop-only application. [snip] So, let's tear this desktop/mobile barrier down while thinking about the future. 2) It should support onion service-based chat protocols. [snip]
I wholeheartedly agree with these points. I would only add that for chat apps in general, mobile has perhaps 20x-100x the users that desktop has.[1] So if one had to initially choose between mobile and desktop because of limited resources, I would suggest starting with mobile and expanding to desktop as funding grew. Similar to Signal's approach.
[1] The biggest desktop chat apps appear to be: - Slack, with ~9 million weekly users: (https://expandedramblings.com/index.php/slack-statistics/) - Discord, with ~9 million daily active users and 45 million registered users: https://venturebeat.com/2017/05/16/discords-game-voice-communications-app-hi...).
Whereas the most popular mobile chat apps are apparently WhatsApp, Facebook Messenger, QQ Mobile, and WeChat with close to 1 billion users each: https://www.statista.com/statistics/258749/most-popular-global-mobile-messen...
Hi there I agree with these points too. I think if we keep in mind that our use case is for folks who are looking the on a 'chat product': 'privacy, security, anonymity and censorship circumvention'. I am not sure if the whole 'build it on the top of the Browser' is possible. But the more I think about it the more I think that having something that works with Tor Browser makes sense for a few reasons. 1. If its a .onion chat - the connection to Tor will be there with Tor Browser (and of course, one less app for folks to download) 2. If I am on this .onion chat and someone sends me a link (which happens a lot) I will already have a browser that is safe for me to open it. And this allow us to complete the user experience in a safe way. [Detail that most of the chat apps above has some browsing functionality for folks to open urls within the app (so the user doesn't get out of the product, is a retention tactic).] 3. Might be easier to have it on mobile since we will work on browser on mobile. But maybe the 'on the top of the Browser' doesn't make sense and all this could still happen as a stand alone app. Without any browsing functionality of course. cheers, isabela
On 10/26/17 08:01, isabela wrote:
I think if we keep in mind that our use case is for folks who are looking the on a 'chat product': 'privacy, security, anonymity and censorship circumvention'.
Sorry this paragraph got all cut off i meant to say: I think if we keep in mind that our use case is for folks who are looking *for these qualities* on a 'chat product'
On 26 October 2017 at 14:02:53, isabela (isabela@torproject.org) wrote: On 10/26/17 04:16, Arthur D. Edelstein wrote: > On Thu, Oct 26, 2017 at 7:47 AM, Georg Koppen <gk@torproject.org> wrote: > > [snip] >> 1) It should not be a desktop-only application. [snip] So, let's tear this > desktop/mobile barrier down while thinking about the future. >> 2) It should support onion service-based chat protocols. [snip] > > > [1] The biggest desktop chat apps appear to be: > - Slack, with ~9 million weekly users: > (https://expandedramblings.com/index.php/slack-statistics/) > - Discord, with ~9 million daily active users and 45 million > registered users: > https://venturebeat.com/2017/05/16/discords-game-voice-communications-app-hits-45-million-users/). > > Whereas the most popular mobile chat apps are apparently WhatsApp, > Facebook Messenger, QQ Mobile, and WeChat with close to 1 billion > users each: https://www.statista.com/statistics/258749/most-popular-global-mobile-messenger-apps/ 1. If its a .onion chat - the connection to Tor will be there with Tor Browser (and of course, one less app for folks to download) 2. If I am on this .onion chat and someone sends me a link (which happens a lot) I will already have a browser that is safe for me to open it. And this allow us to complete the user experience in a safe way. [.. snip] 3. Might be easier to have it on mobile since we will work on browser on mobile. I think a lot of things have been suggested here, and while I think that all of them are great ideas, maybe it’s useful to try to re-focus on something that is achievable within the modest amount of effort that is currently available to dedicate to endeavour. Let me elaborate. I think that the mobile first approach is solid, mobile is also a very tricky platform to do well. As such I would maybe take into consideration the fact that you may eventually want to support mobile too, but not aim for mobile first. The idea of creating a new chat system that is based on onion services (a la richochet) is also a great idea, though that particular market (that of walled garden IM apps, think Whatsapp, Signal, Viber, Telegram, etc.) and unless we are willing to invest serious resources we are likely to get small adoption. A space that is instead very lacking, is that of good IM clients for existing protocols (think jabber, IRC, etc.). Most of the clients out there for IRC and jabber that are not for uber nerds suck. So why not try to make an amazing IRC and jabber client? I think that if you are to take this on, I would not based it on existing clients (because they all suck), but instead I would go for writing a desktop app from scratch, using technologies that can be easily adapted to support a mobile use case (ex. React and React-native). A killer feature that I think would make this sort of thing truly stand out is the ability to run an IRC bouncer (and maybe jabber too) as a onion service. It should be possible to deploy this IRC/Jabber bouncer very easily on your own server (or even your raspberry pi at home) so that you can be always online and preserve chat history. To my knowledge there is no mainstream IM client for IRC and jabber that supports this type of bouncer deployment/operation (bitlbee doesn’t count, I mean something for end users). What do you think? ~ Arturo
On 10/26/2017 03:47 AM, Georg Koppen wrote:
2) It should support onion service-based chat protocols. Those are a good showcase for metadata-free chat/messaging and we should support that + convince users to switch to them.
What if took a step back, and actually design and implemented a native Tor protocol reliable messaging layer, within the Onion Service protocol? There a lot of issues related to presence, offline delivery, asynchronous nature of messaging, and encryption that Ricochet ran into as part of their work. I know there was talk of mix networks on top of Tor, and other DHT/blockchain style efforts like BitMessage can work well over Tor, too. Ultimately, just moving to HTTP over Onion peer-to-peer messaging, doesn't seem like enough, and definitely would expose a lot of issues on mobile, where expecting a user to be online all of the time is just not a reality. +n
On 10/26/2017 12:01 PM, Nathan Freitas wrote:
On 10/26/2017 03:47 AM, Georg Koppen wrote:
2) It should support onion service-based chat protocols. Those are a good showcase for metadata-free chat/messaging and we should support that + convince users to switch to them.
What if took a step back, and actually design and implemented a native Tor protocol reliable messaging layer, within the Onion Service protocol? There a lot of issues related to presence, offline delivery, asynchronous nature of messaging, and encryption that Ricochet ran into as part of their work.
I know there was talk of mix networks on top of Tor, and other DHT/blockchain style efforts like BitMessage can work well over Tor, too.
Ultimately, just moving to HTTP over Onion peer-to-peer messaging, doesn't seem like enough, and definitely would expose a lot of issues on mobile, where expecting a user to be online all of the time is just not a reality.
Building on this, if we are looking for an Onion native messaging app that could use some love and support, I vote for Briar: https://www.briarproject.org/how-it-works.html Everyone involved in that project is top notch (https://dymaxion.org/essays/briarvision.html), and their Bramble stack is probably the closest thing today to an Onion messaging layer. I know that this project has been in the air for a long time, but they've actually shipped an app now, and been audited! https://www.briarproject.org/news/2017-beta-released-security-audit.html It definitely needs a desktop and an iOS version, which is where Tor could step in. That said, Briar has an active community on its own, so it would be more like the partnership with TAILS, then Tor taking on a whole messaging app itself. Also, Tor would make Eleanor and many others very happy by not promote yet another secure messaging tool: https://dymaxion.org/essays/pleasestop.html +n
On Thu, Oct 26, 2017 at 12:01:22PM -0400, Nathan Freitas wrote:
On 10/26/2017 03:47 AM, Georg Koppen wrote:
2) It should support onion service-based chat protocols. Those are a good showcase for metadata-free chat/messaging and we should support that + convince users to switch to them.
What if took a step back, and actually design and implemented a native Tor protocol reliable messaging layer, within the Onion Service protocol? There a lot of issues related to presence, offline delivery, asynchronous nature of messaging, and encryption that Ricochet ran into as part of their work.
I know there was talk of mix networks on top of Tor, and other DHT/blockchain style efforts like BitMessage can work well over Tor, too.
This could maybe dovetail with a suggestion I made long ago to many Tor developers and researchers, but neither myself nor anybody else has had enough time/inclination to explore: Tor mostly builds circuits pre-emptively rather than on-demand. Tor circuits could be built in a simple timed-mix style. Every relay holds circuit extension requests for N seconds (order tens of milliseconds?) and then forwards all extend cells from the last N seconds. Questions include: what should N be? How much would this actually raise the load on a approximately GPA (adversary that is trying to just hoover up all (non-relay) timing info to associate circuits from network observations? Would it in fact raise the load for relevant adversaries any significant amount at all or is it pointless? What fraction of circuits must be on-demand (or on-demand for all hops)? What are the usability trade-offs of making all/some circuit builds conform to this? What are the security trade-offs of making all/some circuit builds conform to this? Is the simple timed-mix the best we can practically do here? If messaging errr? cells could conform to the same (or compatible a la tau-mixing) mixing constraints this could help with anonymity sets on both sides. Now do lots of research and/or wave hand as needed.
Ultimately, just moving to HTTP over Onion peer-to-peer messaging, doesn't seem like enough, and definitely would expose a lot of issues on mobile, where expecting a user to be online all of the time is just not a reality.
This might also help with that issue, or maybe make it harder ;>) aloha, Paul
On 27 Oct 2017, at 07:46, Paul Syverson <paul.syverson@nrl.navy.mil> wrote:
I know there was talk of mix networks on top of Tor, and other DHT/blockchain style efforts like BitMessage can work well over Tor, too.
This could maybe dovetail with a suggestion I made long ago to many Tor developers and researchers, but neither myself nor anybody else has had enough time/inclination to explore: Tor mostly builds circuits pre-emptively rather than on-demand. Tor circuits could be built in a simple timed-mix style. Every relay holds circuit extension requests for N seconds (order tens of milliseconds?) and then forwards all extend cells from the last N seconds.
Questions include: what should N be? How much would this actually raise the load on a approximately GPA (adversary that is trying to just hoover up all (non-relay) timing info to associate circuits from network observations? Would it in fact raise the load for relevant adversaries any significant amount at all or is it pointless? What fraction of circuits must be on-demand (or on-demand for all hops)? What are the usability trade-offs of making all/some circuit builds conform to this? What are the security trade-offs of making all/some circuit builds conform to this? Is the simple timed-mix the best we can practically do here?
Tor's internal event loop runs some callbacks every second. So the network traffic triggered by these callbacks already implements a hold-and-release design, with N = 1 second. In particular, bandwidth token buckets are refilled every second, and some pending connection events are triggered by these callbacks. I'm sure someone did a graph or a paper where they demonstrated the 1-second pattern in Tor's traffic. But I'm not sure how to track it down. T
On Fri, Oct 27, 2017 at 08:41:23AM +1100, teor wrote:
In particular, bandwidth token buckets are refilled every second, and some pending connection events are triggered by these callbacks.
I'm sure someone did a graph or a paper where they demonstrated the 1-second pattern in Tor's traffic. But I'm not sure how to track it down.
You can read about the issue on page 5 of https://svn.torproject.org/svn/projects/roadmaps/2009-07-24-measurements.pdf But we resolved the issue by refilling token buckets 10 times a second starting in 0.2.3.5-alpha. See proposal 183 and ticket #3630. --Roger
Georg Koppen <gk@torproject.org> writes:
1) It should not be a desktop-only application.
(I hope to not further derail this thread, but ...) Yes, I agree at least thinking / planning for mobile users at the start is a good idea. "In general", how likely do you think a "remote control"-style mobile application would work for mobile users? What I mean by this is: the "real" application runs somewhere (e.g. at home, or on a trusted friend's machine) and presents some kind of RPC-style API/interface over an Onion service -- the mobile application is then "just" a remote-control GUI for this. Conceptually, this seems very similar to how a lot of SaaS-type mobile applications already work (except you're running the server-side software yourself on a trusted machine, only available via Onion service). Personally, I've been thinking of this more in the context of programs like a BitCoin or Ethereum wallet/node, or a Tahoe-LAFS client -- where they kind of really do need to be online 100% (approximately) of the time to be most useful and often use a lot of data (or CPU). As in, you're not going to keep ~150GB of bitcoin transactions on your phone. For chat, this would have the advantage of being "always"-online (for e.g. IRC this is important). This *might* have privacy advantages, too (e.g. keeping metadata emanating from your home-machine slightly more consistent, keeping a consistent traffic pattern to any chat-servers like IRC or XMPP you're conncting to, etc). Another advantage: the "remote control phone" piece would presumably authenticate to your home machine via some keypair -- which can be revoked easily (e.g. if the phone is lost or stolen). Ideally such an application would keep *zero* data on the phone, and re-sync any relevant state the next time it connects via the Onion service. BUT I don't know if this would actually be a "thing that might work" for mobile users. Obviously, it's not-great for mobile users who don't have any other computing devices. Are there statistics on this sort of thing? (e.g. what % of mobile-users have a computing device somewhere else on the network?) Cheers, -- meejah
participants (12)
-
Alison Macrina -
Arthur D. Edelstein -
Arturo Filastò -
Georg Koppen -
George Kadianakis -
isabela -
meejah -
Nathan Freitas -
Paul Syverson -
Roger Dingledine -
Sukhbir Singh -
teor