emdee
/
tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Tox over Tor

emdee 2022-10-15 10:21:23 +00:00
parent 1b956831db
commit 146a54ff7e
13 changed files with 1003 additions and 988 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
DDosSmallNumberOfBSNodes.md

@ -1,59 +1,59 @@
Previous: [[SecurityVulnerabilities]]
By design, Tox relies on a small number of BS nodes. As the network
is now, the number of nodes is very small, and all well known. So Tox
is vulnerable to being completely taken down by blocking a small
number of nodes.
The same problem, to a lesser extent affects Tor, although they have a
few thousand nodes. Doing the best we can with what we have, we can
take advantage of something from libtoxcore: the ```tcp_server slot```.
It is supported by most clients like toxic or toxygen.
So this is what is proposed:
1. Fix libtoxcore to be able to accept .onion addresses for BS nodes,
or test the workarounds: see [[ToxAndTorInChinaAndIran]].
2. All BS node operators are asked to also run a Tor client (not exit node),
in addition to running their node. We put together easy-to-follow instructions
on how to download/configure/run Tor. There are no risks to the BS operator
from running a Tor client (not exit node), and the overhead in negligible.
The onion server is a 127.0.0.1 service, so cannot be seen by your ISP.
Your service is on the opennet anyway so an onion is just another access method.
So we get dozens of Tor onion nodes running quickly.
3. All Tor Tox client users are asked to also configure their Tox client to
use ```--tcp_server``` with a random port, and configure their Tor client
(not exit node) to provide that ```tcp_server``` as an onion accessible relay,
in addition to running the normal Tor. We put together easy-to-follow
instructions on how to configure Tor to serve that ```tcp_server``` as an onion.
There are no risks to the user as he's already running a Tor client
(not exit node), and the overhead in the Tox client in negligible.
The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP.
So we get a tcp_server extra for every Tor user. That scales well.
4. Modify Tox clients to detect if they are behind Tor and on their homepage
or splash screen ask them to run a ```tcp_server```.
5. Improve the client documentation on how to run Tox over Tor,
particularly for Android users: how to download Orbot from
<https://f-droid.org> (preferred over Srewgle Play) and configure them.
Tell them to try first running Orbot and a browser that works with it,
and test out if their mobile to see if they can run Tor. The Tor devs are actively
playing cat and mouse with Iran and have other tricks if regular Tor fails.
6. Improve our ability to monitor network performance, including TCP relays,
so we can detect if anyone is attacking the network.
PS: Trying make it easy to package and run a BS node in places like
Iran is going about it in the wrong way; I doubt running a BS node in
Iran is healthy thing to do. Get them onto Tor, and improve service over Tor.
Much better to get all of our BS nodes to run an onion service so
there is good availability and redundancy, and fix the minor problems
needed for Tox to work with onion BS nodes.
Previous: [[SecurityVulnerabilities]]
By design, Tox relies on a small number of BS nodes. As the network
is now, the number of nodes is very small, and all well known. So Tox
is vulnerable to being completely taken down by blocking a small
number of nodes.
The same problem, to a lesser extent affects Tor, although they have a
few thousand nodes. Doing the best we can with what we have, we can
take advantage of something from libtoxcore: the ```tcp_server slot```.
It is supported by most clients like toxic or toxygen.
So this is what is proposed:
1. Fix libtoxcore to be able to accept .onion addresses for BS nodes,
or test the workarounds: see [[ToxAndTorInChinaAndIran]].
2. All BS node operators are asked to also run a Tor client (not exit node),
in addition to running their node. We put together easy-to-follow instructions
on how to download/configure/run Tor. There are no risks to the BS operator
from running a Tor client (not exit node), and the overhead in negligible.
The onion server is a 127.0.0.1 service, so cannot be seen by your ISP.
Your service is on the opennet anyway so an onion is just another access method.
So we get dozens of Tor onion nodes running quickly.
3. All Tor Tox client users are asked to also configure their Tox client to
use ```--tcp_server``` with a random port, and configure their Tor client
(not exit node) to provide that ```tcp_server``` as an onion accessible relay,
in addition to running the normal Tor. We put together easy-to-follow
instructions on how to configure Tor to serve that ```tcp_server``` as an onion.
There are no risks to the user as he's already running a Tor client
(not exit node), and the overhead in the Tox client in negligible.
The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP.
So we get a tcp_server extra for every Tor user. That scales well.
4. Modify Tox clients to detect if they are behind Tor and on their homepage
or splash screen ask them to run a ```tcp_server```.
5. Improve the client documentation on how to run Tox over Tor,
particularly for Android users: how to download Orbot from
<https://f-droid.org> (preferred over Srewgle Play) and configure them.
Tell them to try first running Orbot and a browser that works with it,
and test out if their mobile to see if they can run Tor. The Tor devs are actively
playing cat and mouse with Iran and have other tricks if regular Tor fails.
6. Improve our ability to monitor network performance, including TCP relays,
so we can detect if anyone is attacking the network.
PS: Trying make it easy to package and run a BS node in places like
Iran is going about it in the wrong way; I doubt running a BS node in
Iran is healthy thing to do. Get them onto Tor, and improve service over Tor.
Much better to get all of our BS nodes to run an onion service so
there is good availability and redundancy, and fix the minor problems
needed for Tox to work with onion BS nodes.

24
GroupOfDevicesPOC.md

@ -1,12 +1,12 @@
Previous: [[Home]]
## Group Of Devices POC
One way to address the multi-device problem is to add the multiple devices of a person into a NGC group.
It may not scale well because messaging is sent to all devices of all users;
a single active user approach would be more efficient.
And it wouldn't work for groups very well as a group-of-devices can
not be a member of an NGC group.
Previous: [[Home]]
## Group Of Devices POC
One way to address the multi-device problem is to add the multiple devices of a person into a NGC group.
It may not scale well because messaging is sent to all devices of all users;
a single active user approach would be more efficient.
And it wouldn't work for groups very well as a group-of-devices can
not be a member of an NGC group.

64
Home.md

@ -1,32 +1,32 @@
# Welcome to the Wiki.
What I am noticing is that there is no notion of a Tox Improvement
Proposal(TIP), so ideas and vulnerabilities get forgotten in
abandonned PRs in abandoned repos, or ignored issues.
I suggested wiki.tox.chat as a place to identify and prioritize TIPs
but maybe we can elaborate POCs here. I want to "argue" it out to get
to the "best" proposal so work so work can get going on a trial
version. developers who know the key exchange mechanisms can bring a
lot of the existing codebase to bear on this problem, and resolve
wrinkles in the concepts.
### Multi-Device DHT announcements:
* [[MultiDevice Announcements POC]]
* [[GroupOfDevicesPOC]]
* Original TokTok ToxMultiDevice: [[ToxMultiDevice]]
### Network Resilience
* [[ToxNetworkResilience]]
### Security
* [[SecurityVulnerabilities]]:
** [[UseGroupPasswordThroughAKDF]]
** [[VulnerabilitiesInTheToxOnion]]
** [[DDosSmallNumberOfBSNodes]]
# Welcome to the Wiki.
What I am noticing is that there is no notion of a Tox Improvement
Proposal(TIP), so ideas and vulnerabilities get forgotten in
abandonned PRs in abandoned repos, or ignored issues.
I suggested wiki.tox.chat as a place to identify and prioritize TIPs
but maybe we can elaborate POCs here. I want to "argue" it out to get
to the "best" proposal so work so work can get going on a trial
version. developers who know the key exchange mechanisms can bring a
lot of the existing codebase to bear on this problem, and resolve
wrinkles in the concepts.
### Multi-Device DHT announcements:
* [[MultiDevice Announcements POC]]
* [[GroupOfDevicesPOC]]
* Original TokTok ToxMultiDevice: [[ToxMultiDevice]]
### Network Resilience
* [[ToxNetworkResilience]]
### Security
* [[SecurityVulnerabilities]]:
** [[UseGroupPasswordThroughAKDF]]
** [[VulnerabilitiesInTheToxOnion]]
** [[DDosSmallNumberOfBSNodes]]

686
MultiDeviceAnnouncementsPOC.md

@ -1,343 +1,343 @@
Previous: [[Home]]
## We need to solve the usage of Tox with multiple devices.
This proof-of-concept (POC) is based on the premise that solving the
usage of Tox with multiple devices is an urgent problem, as anyone
with mobiles runs into it, and all the competition software deals with it.
MultiDevice is much easier in centralized systems and our decentalization
is why it's hard for us; if we make it, we make be the first ever!
**Woke Warning:** gender specific, non-android/furry friendly grammar
is used throughout.
The idea here is to address one simple usecase: a person can have
multiple devices and he wants one device to be "active" at any given time.
So he pushes so kind of announcement of what device he is currently
using so that others can communicate to the device he is currently using.
The POC ignores the problem of history sync that this creates.
Others can address that later perhaps with tools like rsync.
## Background
When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their
network. If you need an address, number, or entire friend list it’s a
simple login away. [[ToxMultiDevice]]
Not the goal of this project but an important benefit, Multi-Device
support would solve some of the issues sharing a ToxID: it would allow
the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere.
## First Steps
The idea is to firstly define a PersonaID, much like a ToxPk that
stays permanent across his devices, and maps the Person to the active ToxPk.
So the first step is to extend all library code and all clients to
work with PersonaIDs as well as ToxPks. The PersonaIDs would be client
facing, and the ToxPk code would be for internal access. A simple
implementation would be duplicating all code calls that deals with
ToxPks to have a layer of calls on top that take the PersonaID and
consult a table that contains the active ToxPk, and then calls the
ToxPk function.
For the sake of argument, let's say that the table is initially
populated with all the existing ToxPks by deriving a default PersonaID
ToxID by a simple method: the default table contains a PersonaID that
is the ToxPk (identity table).
So we can add this layer of PersonaID->ToxPk mapping to the library
and all clients right away with no breakage. In time, the clients will
move to showing the PersonaID not the ToxPk as the primary client-facing ID,
and extend the clients with the ability to see the table of Personae ->
ToxPks (but maybe not change the entries), and the active ToxPk for
each PersonaID.
More concretely, the PersonaID mapping table would be like a dictionary
with 2 (or more) types of entries; before the arrival of a blob update,
the table is by default (assuming JSON)
```
{"Pk1": "Pk1",
"Pk2": "Pk2",
...}
```
So we could get the whole network switched over to accommodating PersonaIDs
with no breakage. After the arrival of a blob to update the table,
the PersonaID is an ordered dictionary mapping to a list of device PKs:
```
{"Pk1": "Pe1",
"Pe1": ["Pe1k1", "Pe1k2", ...],
"Pk2": "Pk2",
...}
```
or better still, associated ordered dictionary mapping to a dictionary with
```devices``` entry with a dictionary using nicknames:
```
{"Pk1": "Pe1",
"Pe1": {"devices": {
"Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...}
},
"Pk2": "Pk2",
...}
```
where:
* ```Pk1``` is the PK of user1,
* ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1.
* ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1,
delivered in a blob signed by ```Pe1``
Richer formats for the table are obviously possible, but we want to
maintain a structure that foresees this table being managed by a
keyring manager like ```keepassxc```.
## MultiDevice Announcements Push
So if we modify the library and clients as described above, how do we
keep it up to date when a friend changes his devices? If we know the
PersonaID, how is the library code table of PersonaID to ToxPk mapping
updated? We want this to be mainly automatic without bothering the user.
We would need to modify the client code to save a copy if the mapping
table, so that when we start up a client, the mapping table is filled
with last good values from the Persona storage. For the sake of this POC:
1. the storage file could be JSON, possibly encrypted with ToxESave, or
2. it could be a files in a ```Personae``` directory with files saved
in JSON or YAML, like we do with avatars, with the filename being named
```PersonaID.json```.
Again, we want to maintain a structure that foresees this table being
managed by a keyring manager like ```keepassxc```. It would not be
saved in a profile, as this table spans multiple profiles.
Let's say we have a friend, and we know his ToxPk. We initially derive
his PersonaID by setting it to the friend's public key - the entry in
the table is a string.
We will call "a blob" the information that will update our PersonaID
mapping to his active ToxID that is pushed to clients. We want to
watch the blob flow for changes. So what is the blob flow of information?
1. If a blob is small we can base64 encode it and stick it in his status message,
2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, and handle updates the way we do avatars.
3. We might push it as a DHT announcement.
Some clients may let the user decide whether of not to accept a blob
update when it arrives.
## MultiDevice Announcements Blob
So what is the blob of information that is pushed?
It has these characteristics:
1. It has 3 things - a name and a payload, and a NaCl signature.
2. It is small - 1K to 4K in size.
3) As we will need a NaCl signing keypair in order to sign the payload,
the name, (PersonaID) can be the public key of the signing keypair -
32 bytes or 64 hex chars.
4. If we push the blob info by DHT announcements, it pushed regularly
so people can get the PersonaID relatively soon - say hourly for now.
Any longer means a person who has not connected to that friend before
has to wait longer if they only have a PersonaID. If we push it like
avatars, then it can be pushed once at start and subsequently on any changes.
5) It might be encrypted so that the contents can not be seen in transit,
but if the push mechanism is within Tox, it would be unnecessary.
6) It must be signed so that it can be verified to be from the
PersonaID, so we will assume every person generates a NaCl signing
keypair and uses the same keypair for all of his devices. The public key
of the signing keypair can be used as the PersonaID. If a secret is used
as the seed of the signing keypair, then the generated keypair is reproducible.
If we use DHT announcements, each client would watch the stream for
blobs named the PersonaID that they are interested in, which they know
from the public signing key being in the status message of the
friends. Pushing the blob through DHT announcements would mean that
the PersonaID to ToxPk mapping could be accessed even by people who
were not yet your Friends - helping discovery. This may not be a good
idea, depending on if it's encrypted. This set of ToxPks could be keys
that open the encrypted blob. Anyone who already has a ToxPk of the
Persona could open the blob to get the update. Hence this encryption
is different from most Tox encryption in that multiple keys can open
it - like a multi-key Vera/True/dmwrapper container. But it might be
enough for the blob to be signed, and that would be a good starting
point - add encryption later if needed.
The public signing key could be put into the status message field of
each Person, and if each user put the same signature public key as the
status message on each of his devices, then that signing PK can become
the PersonaID. The mapping table can be automatically scanned and any
entries for which the PersonaID == ToxPk could be automatically
updated to use the signing key as the PersonaId.
I had assumed we would have to use the DHT to deal with decentralization.
But this POC makes me think we can use the toxcore status_message
and avatar_files code to do it without the DHT, at least to Friends.
So let's say for now to focus this discussion, we will ignore DHT announcements.
1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or
2. It can be pushed as a status message. If we compress and base64
encode the blob, sign it and attach the signature in hex, and keep it
under 1007 chars, then it can be set as your status message on all of
your devices. The status message is visible to all of your friends so
they all have a copy of the latest blob all of the time.
3. If the blog.gz is less than 1000 chars, could it fit in a QR code?
In fact we could do #2 first to get things going, and then do #1,
which is more changes to the code, although a lot of the code could be
morphed from the avatar code. Or you could push a blob as a file if
it got too big for a status message.
The same blob would be on each of a Person's devices.
### Use the status message if less than 1007 bytes
With the signature and the public key, this should leave room for at
least 12 devices in less than 1007 bytes, compressed and base64
encoded. With 1007 bytes with the signature and signing key, and
nicknames of 12 bytes it will take about 16
devices: ```1007-128-64-2/(32+6+12) = 16```
One problem with this is that only your Friends could verify the blob,
which means users you have never invited will not be able to verify,
unless they had the signing public key independently (perhaps using
/sendfile). But perhaps that's good. Clients could watch status
message changes easily using the status_message callback.
### It can be pushed as files like avatars amongst Friends
All the avatar code could be repurposed to also handle blobs, with the
signing public key put into the Person's status message. Avatars are
simple file transfers; there is a WHOLE byte dedicated for "file_kind",
which means we can "just" add a new file_kind and use the exising file
transfer code. In the beginning the clients would not need to be able
to generate the blob - a simple Python script could do it outside the clients.
Unknown for now is does the client have to send a Friend ```add
request``` to any new ToxPks found in the blob (new devices) to make
them active if the client has never seen the PK before? I assume yes.
If so then it complicates things a little as the blob might need to contain
ToxIDs. The code could accept either ToxPks or ToxIds, distinguishing
by length. Or you could just require that the Person already be a
Friend with that device before the information in the table was useable.
(The blob might be a signed way of associating nicknames with Pks if
we use associated ordered dictionary mapping to a dictionary with nicknames.)
The clients would manage this seamlessly to aggregate the ToxPks
together under one Persona that is shown to the user. The library does
most of this by accepting the update from the blob to update the table
pointing from PersonaID to the new list of ToxPks (devices) with the
first one being the active one.
The generation and signing verification of the blobs could be done
outside of the clients in a utilty common to all clients. The clients
let a user push a blob whenever he wants - like when he changes devices.
## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an
existing profile. If you just copy a profile from one device to the next it will not work as you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client would push a new blob with the new device's PK, signed by the signing keypair which is independent of profiles.
The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired.
See <https://git.plastiras.org/emdee/tox_profile>
## MultiDevice Groups
Previously, we described how we simply copy a profile to a new devices
and change the public/private keys as a starting point.
But we are left with as special problem with NGC groups.
The code is assumed to have been modified to handle Personas and, at
first glance, NGC groups become groups of Personas. Each member of the
group is a Persona, and uses the table lookup to get the active ToxPk.
But the group structure in the profile has a copy of the founder's
shared_state.founder_public_key (group_pack.c#L293) So if the profile
being copied onto a new device is the profile of the founder, then
this key would need to be updated too.
Besides the group keypair in #L351-2
* bin_pack_bin(bp, chat->chat_public_key, EXT_PUBLIC_KEY_SIZE); // 1
* bin_pack_bin(bp, chat->chat_secret_key, EXT_SECRET_KEY_SIZE); // 2
The chat->chat_secret_key is all zeros, I assume in everyone but the founder's
profile.
It seems also that self's group keypair are saved to the group:
* self_public_key #L353
* self_secret_key #L354
Do these keys have to be updated with the new keypair of the new
profile? Or do you only copy the keys from the profile that was in
use when the Person first joined the group as a user - wrinkle. In
which case, the notion of the blob needs extending from just the
ToxPks and nicknames of each of the devices, to include the secret
keys of that Persona for each NGC group the Persona belongs to.
In other words if I have 3 profiles with 3 nicks and 3 keypairs, and the
first profile had a GROUP section where I have a group_nick, could I copy
the GROUP section entirely into the other 2 profiles, and then be a member
of the NGC group known as group_nick when I used those profiles? If so,
the Persona should have dictionarys for each group, with
```group_nick```, ```self_public_key``` and ```self_secret_key``` in each.
( Aside: I don't like the idea of keeping secret keys in profiles; they
should be managed by a keymanager. In a corporate setting, this will
be a requirement. )
There is a Python script to parse profiles that could be modified to rekey
group self entries at: https://git.plastiras.org/emdee/tox_profile
## Future Directions
If Personae identify which are your devices, it opens the possibility that
clients could treat incoming messages from one of your devices differently.
Instead of simply displaying the message in a window, the client might
examine the message to see if it is a command. So clients could build in,
for example a filebot, that responds to a set of commands if it's coming
from one of your devices. Automated file transfer, DoorSpy, history sync;
the possibilities are endless.
## Summary
The changes to the core are not large:
1. Change the status message callback to look for public signing keys
2. Change the status message callback to look for blobs as a first
implementation, and then later extend the avatar file transfer mechanism
to transfer blobs
3. Use the public signing keys to verify the blobs. This a NaCl call.
4. Store the blobs in a subdirectory, with their signature.
5. Use the blobs to populate the table, and designate one entry as active.
6. Wrap all the calls that use a PK to look in the table for the active PK.
7. Update the tables, if files are deleted from the ```Persona``` directory.
All existing unmodified users would continue to work: no testnet required.
Assuming the blobs were created by an independent stand alone utility,
the changes to the clients are not large:
1. Consult the mapping table and show it to the users.
2. Accept or reject new blob updates.
3. Redefine the notion of contacts to point to the PersonaID.
4. Add the ability to push a new blob to Friends, or perhaps selected Friends.
Also we would want the Python script to keep profiles within a Persona in sync.
We need to resolve the questions about having the same groups Personae.
Previous: [[Home]]
## We need to solve the usage of Tox with multiple devices.
This proof-of-concept (POC) is based on the premise that solving the
usage of Tox with multiple devices is an urgent problem, as anyone
with mobiles runs into it, and all the competition software deals with it.
MultiDevice is much easier in centralized systems and our decentalization
is why it's hard for us; if we make it, we make be the first ever!
**Woke Warning:** gender specific, non-android/furry friendly grammar
is used throughout.
The idea here is to address one simple usecase: a person can have
multiple devices and he wants one device to be "active" at any given time.
So he pushes so kind of announcement of what device he is currently
using so that others can communicate to the device he is currently using.
The POC ignores the problem of history sync that this creates.
Others can address that later perhaps with tools like rsync.
## Background
When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their
network. If you need an address, number, or entire friend list it’s a
simple login away. [[ToxMultiDevice]]
Not the goal of this project but an important benefit, Multi-Device
support would solve some of the issues sharing a ToxID: it would allow
the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere.
## First Steps
The idea is to firstly define a PersonaID, much like a ToxPk that
stays permanent across his devices, and maps the Person to the active ToxPk.
So the first step is to extend all library code and all clients to
work with PersonaIDs as well as ToxPks. The PersonaIDs would be client
facing, and the ToxPk code would be for internal access. A simple
implementation would be duplicating all code calls that deals with
ToxPks to have a layer of calls on top that take the PersonaID and
consult a table that contains the active ToxPk, and then calls the
ToxPk function.
For the sake of argument, let's say that the table is initially
populated with all the existing ToxPks by deriving a default PersonaID
ToxID by a simple method: the default table contains a PersonaID that
is the ToxPk (identity table).
So we can add this layer of PersonaID->ToxPk mapping to the library
and all clients right away with no breakage. In time, the clients will
move to showing the PersonaID not the ToxPk as the primary client-facing ID,
and extend the clients with the ability to see the table of Personae ->
ToxPks (but maybe not change the entries), and the active ToxPk for
each PersonaID.
More concretely, the PersonaID mapping table would be like a dictionary
with 2 (or more) types of entries; before the arrival of a blob update,
the table is by default (assuming JSON)
```
{"Pk1": "Pk1",
"Pk2": "Pk2",
...}
```
So we could get the whole network switched over to accommodating PersonaIDs
with no breakage. After the arrival of a blob to update the table,
the PersonaID is an ordered dictionary mapping to a list of device PKs:
```
{"Pk1": "Pe1",
"Pe1": ["Pe1k1", "Pe1k2", ...],
"Pk2": "Pk2",
...}
```
or better still, associated ordered dictionary mapping to a dictionary with
```devices``` entry with a dictionary using nicknames:
```
{"Pk1": "Pe1",
"Pe1": {"devices": {
"Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...}
},
"Pk2": "Pk2",
...}
```
where:
* ```Pk1``` is the PK of user1,
* ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1.
* ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1,
delivered in a blob signed by ```Pe1``
Richer formats for the table are obviously possible, but we want to
maintain a structure that foresees this table being managed by a
keyring manager like ```keepassxc```.
## MultiDevice Announcements Push
So if we modify the library and clients as described above, how do we
keep it up to date when a friend changes his devices? If we know the
PersonaID, how is the library code table of PersonaID to ToxPk mapping
updated? We want this to be mainly automatic without bothering the user.
We would need to modify the client code to save a copy if the mapping
table, so that when we start up a client, the mapping table is filled
with last good values from the Persona storage. For the sake of this POC:
1. the storage file could be JSON, possibly encrypted with ToxESave, or
2. it could be a files in a ```Personae``` directory with files saved
in JSON or YAML, like we do with avatars, with the filename being named
```PersonaID.json```.
Again, we want to maintain a structure that foresees this table being
managed by a keyring manager like ```keepassxc```. It would not be
saved in a profile, as this table spans multiple profiles.
Let's say we have a friend, and we know his ToxPk. We initially derive
his PersonaID by setting it to the friend's public key - the entry in
the table is a string.
We will call "a blob" the information that will update our PersonaID
mapping to his active ToxID that is pushed to clients. We want to
watch the blob flow for changes. So what is the blob flow of information?
1. If a blob is small we can base64 encode it and stick it in his status message,
2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, and handle updates the way we do avatars.
3. We might push it as a DHT announcement.
Some clients may let the user decide whether of not to accept a blob
update when it arrives.
## MultiDevice Announcements Blob
So what is the blob of information that is pushed?
It has these characteristics:
1. It has 3 things - a name and a payload, and a NaCl signature.
2. It is small - 1K to 4K in size.
3) As we will need a NaCl signing keypair in order to sign the payload,
the name, (PersonaID) can be the public key of the signing keypair -
32 bytes or 64 hex chars.
4. If we push the blob info by DHT announcements, it pushed regularly
so people can get the PersonaID relatively soon - say hourly for now.
Any longer means a person who has not connected to that friend before
has to wait longer if they only have a PersonaID. If we push it like
avatars, then it can be pushed once at start and subsequently on any changes.
5) It might be encrypted so that the contents can not be seen in transit,
but if the push mechanism is within Tox, it would be unnecessary.
6) It must be signed so that it can be verified to be from the
PersonaID, so we will assume every person generates a NaCl signing
keypair and uses the same keypair for all of his devices. The public key
of the signing keypair can be used as the PersonaID. If a secret is used
as the seed of the signing keypair, then the generated keypair is reproducible.
If we use DHT announcements, each client would watch the stream for
blobs named the PersonaID that they are interested in, which they know
from the public signing key being in the status message of the
friends. Pushing the blob through DHT announcements would mean that
the PersonaID to ToxPk mapping could be accessed even by people who
were not yet your Friends - helping discovery. This may not be a good
idea, depending on if it's encrypted. This set of ToxPks could be keys
that open the encrypted blob. Anyone who already has a ToxPk of the
Persona could open the blob to get the update. Hence this encryption
is different from most Tox encryption in that multiple keys can open
it - like a multi-key Vera/True/dmwrapper container. But it might be
enough for the blob to be signed, and that would be a good starting
point - add encryption later if needed.
The public signing key could be put into the status message field of
each Person, and if each user put the same signature public key as the
status message on each of his devices, then that signing PK can become
the PersonaID. The mapping table can be automatically scanned and any
entries for which the PersonaID == ToxPk could be automatically
updated to use the signing key as the PersonaId.
I had assumed we would have to use the DHT to deal with decentralization.
But this POC makes me think we can use the toxcore status_message
and avatar_files code to do it without the DHT, at least to Friends.
So let's say for now to focus this discussion, we will ignore DHT announcements.
1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or
2. It can be pushed as a status message. If we compress and base64
encode the blob, sign it and attach the signature in hex, and keep it
under 1007 chars, then it can be set as your status message on all of
your devices. The status message is visible to all of your friends so
they all have a copy of the latest blob all of the time.
3. If the blog.gz is less than 1000 chars, could it fit in a QR code?
In fact we could do #2 first to get things going, and then do #1,
which is more changes to the code, although a lot of the code could be
morphed from the avatar code. Or you could push a blob as a file if
it got too big for a status message.
The same blob would be on each of a Person's devices.
### Use the status message if less than 1007 bytes
With the signature and the public key, this should leave room for at
least 12 devices in less than 1007 bytes, compressed and base64
encoded. With 1007 bytes with the signature and signing key, and
nicknames of 12 bytes it will take about 16
devices: ```1007-128-64-2/(32+6+12) = 16```
One problem with this is that only your Friends could verify the blob,
which means users you have never invited will not be able to verify,
unless they had the signing public key independently (perhaps using
/sendfile). But perhaps that's good. Clients could watch status
message changes easily using the status_message callback.
### It can be pushed as files like avatars amongst Friends
All the avatar code could be repurposed to also handle blobs, with the
signing public key put into the Person's status message. Avatars are
simple file transfers; there is a WHOLE byte dedicated for "file_kind",
which means we can "just" add a new file_kind and use the exising file
transfer code. In the beginning the clients would not need to be able
to generate the blob - a simple Python script could do it outside the clients.
Unknown for now is does the client have to send a Friend ```add
request``` to any new ToxPks found in the blob (new devices) to make
them active if the client has never seen the PK before? I assume yes.
If so then it complicates things a little as the blob might need to contain
ToxIDs. The code could accept either ToxPks or ToxIds, distinguishing
by length. Or you could just require that the Person already be a
Friend with that device before the information in the table was useable.
(The blob might be a signed way of associating nicknames with Pks if
we use associated ordered dictionary mapping to a dictionary with nicknames.)
The clients would manage this seamlessly to aggregate the ToxPks
together under one Persona that is shown to the user. The library does
most of this by accepting the update from the blob to update the table
pointing from PersonaID to the new list of ToxPks (devices) with the
first one being the active one.
The generation and signing verification of the blobs could be done
outside of the clients in a utilty common to all clients. The clients
let a user push a blob whenever he wants - like when he changes devices.
## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an
existing profile. If you just copy a profile from one device to the next it will not work as you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client would push a new blob with the new device's PK, signed by the signing keypair which is independent of profiles.
The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired.
See <https://git.plastiras.org/emdee/tox_profile>
## MultiDevice Groups
Previously, we described how we simply copy a profile to a new devices
and change the public/private keys as a starting point.
But we are left with as special problem with NGC groups.
The code is assumed to have been modified to handle Personas and, at
first glance, NGC groups become groups of Personas. Each member of the
group is a Persona, and uses the table lookup to get the active ToxPk.
But the group structure in the profile has a copy of the founder's
shared_state.founder_public_key (group_pack.c#L293) So if the profile
being copied onto a new device is the profile of the founder, then
this key would need to be updated too.
Besides the group keypair in #L351-2
* bin_pack_bin(bp, chat->chat_public_key, EXT_PUBLIC_KEY_SIZE); // 1
* bin_pack_bin(bp, chat->chat_secret_key, EXT_SECRET_KEY_SIZE); // 2
The chat->chat_secret_key is all zeros, I assume in everyone but the founder's
profile.
It seems also that self's group keypair are saved to the group:
* self_public_key #L353
* self_secret_key #L354
Do these keys have to be updated with the new keypair of the new
profile? Or do you only copy the keys from the profile that was in
use when the Person first joined the group as a user - wrinkle. In
which case, the notion of the blob needs extending from just the
ToxPks and nicknames of each of the devices, to include the secret
keys of that Persona for each NGC group the Persona belongs to.
In other words if I have 3 profiles with 3 nicks and 3 keypairs, and the
first profile had a GROUP section where I have a group_nick, could I copy
the GROUP section entirely into the other 2 profiles, and then be a member
of the NGC group known as group_nick when I used those profiles? If so,
the Persona should have dictionarys for each group, with
```group_nick```, ```self_public_key``` and ```self_secret_key``` in each.
( Aside: I don't like the idea of keeping secret keys in profiles; they
should be managed by a keymanager. In a corporate setting, this will
be a requirement. )
There is a Python script to parse profiles that could be modified to rekey
group self entries at: https://git.plastiras.org/emdee/tox_profile
## Future Directions
If Personae identify which are your devices, it opens the possibility that
clients could treat incoming messages from one of your devices differently.
Instead of simply displaying the message in a window, the client might
examine the message to see if it is a command. So clients could build in,
for example a filebot, that responds to a set of commands if it's coming
from one of your devices. Automated file transfer, DoorSpy, history sync;
the possibilities are endless.
## Summary
The changes to the core are not large:
1. Change the status message callback to look for public signing keys
2. Change the status message callback to look for blobs as a first
implementation, and then later extend the avatar file transfer mechanism
to transfer blobs
3. Use the public signing keys to verify the blobs. This a NaCl call.
4. Store the blobs in a subdirectory, with their signature.
5. Use the blobs to populate the table, and designate one entry as active.
6. Wrap all the calls that use a PK to look in the table for the active PK.
7. Update the tables, if files are deleted from the ```Persona``` directory.
All existing unmodified users would continue to work: no testnet required.
Assuming the blobs were created by an independent stand alone utility,
the changes to the clients are not large:
1. Consult the mapping table and show it to the users.
2. Accept or reject new blob updates.
3. Redefine the notion of contacts to point to the PersonaID.
4. Add the ability to push a new blob to Friends, or perhaps selected Friends.
Also we would want the Python script to keep profiles within a Persona in sync.
We need to resolve the questions about having the same groups Personae.

96
QToxGreen.md

@ -1,48 +1,48 @@
Up: [[Home]]
# Anthony Bilinski
## Zoominfo LinkedIn
Works full time as:
> C Software Engineer & Open Source Project Application
> Developer & Firmware Maintainer & Developer at Avigilon
* https://www.zoominfo.com/p/Anthony-Bilinski/628037601
* https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy )
* https://www.zoominfo.com/p/Anthony-Bilinski/3246706849
So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021?
Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives
```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address.
His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada.
## Website
His web site no longer responds https://www.abilinski.com/
It was just a one page pointing to a ToxId
* https://web.archive.org/web/20180825193239/https://www.abilinski.com/
His BS nodes no longer respond:
* tox.abilinski.com
* tox2.abilinski.com
There is no github activity since July:
* https://github.com/qtox/qtox
* https://github.com/anthonybilinski
## Funding
Nothing on reddit.com in the last 6 months:
* https://www.reddit.com/user/Anthony_Bilinski
Posted a [blog that announced he had a year's funding](<https://qtox.github.io/blog/2022/02/15/full-time)
in February, but no idea who is the sponsor. It looks like `sphaerophoria` sponsored anthony? https://github.com/sphaerophoria?achievement=public-sponsor&tab=achievements
But the licence for file for [toxext](https://github.com/toxext/toxext/),
a sphaerophoria project initialy came from
[anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person.
Up: [[Home]]
# Anthony Bilinski
## Zoominfo LinkedIn
Works full time as:
> C Software Engineer & Open Source Project Application
> Developer & Firmware Maintainer & Developer at Avigilon
* https://www.zoominfo.com/p/Anthony-Bilinski/628037601
* https://ca.linkedin.com/in/anthony-bilinski-b4178611a (archive: https://archive.ph/X6Tsy )
* https://www.zoominfo.com/p/Anthony-Bilinski/3246706849
So he's working on Open Source projects as his day job at Avigilon May 2016 - Sep 2021 - 5 years 5 months. Maybe qTox was his day job until Sept 2021?
Avigilon is a video surveillance hardware and software company founded in 2004, went public on the VSE and was bought out by Motorolla. His zoominfo listing gives
```a***@curtiswright.com``` as his email. Curtiswright is a well know USGov contractor. He did an Internship at Curtis in 2014, so the @curtiswright email may not be current - an old zoominfo address.
His boss and colleague on the zoominfo.com list both check out. His boss was a [well-known Security Industry professional](https://www.sdmmag.com/articles/100828-security-industry-mourns-the-loss-of-matthew-krebs) not based in Canada.
## Website
His web site no longer responds https://www.abilinski.com/
It was just a one page pointing to a ToxId
* https://web.archive.org/web/20180825193239/https://www.abilinski.com/
His BS nodes no longer respond:
* tox.abilinski.com
* tox2.abilinski.com
There is no github activity since July:
* https://github.com/qtox/qtox
* https://github.com/anthonybilinski
## Funding
Nothing on reddit.com in the last 6 months:
* https://www.reddit.com/user/Anthony_Bilinski
Posted a [blog that announced he had a year's funding](<https://qtox.github.io/blog/2022/02/15/full-time)
in February, but no idea who is the sponsor. It looks like `sphaerophoria` sponsored anthony? https://github.com/sphaerophoria?achievement=public-sponsor&tab=achievements
But the licence for file for [toxext](https://github.com/toxext/toxext/),
a sphaerophoria project initialy came from
[anthonybilinski/add-licence](https://github.com/toxext/toxext/commits?author=sphaerophoria) so they may be the same person.

30
SecurityVulnerabilities.md

@ -1,15 +1,15 @@
Previous: [[Home]]
* [[UseGroupPasswordThroughAKDF]]
* [[VulnerabilitiesInTheToxOnion]]
* [[DDosSmallNumberOfBSNodes]]
* Currently, toxcore uses onion routing in the process of establishing connections between friends, with the aim of obscuring their identities from third parties. However, this method does not achieve this goal. [This document describes a proposed replacement for onion routing.](https://github.com/zugz/tox-DHTAnnouncements/blob/master/DHTAnnouncements.md)This proposal is adapted from an original proposal by [grayhatter](https://wiki.cmdline.org/doku.php?id=dht:new_friend_finding).
##mCVEs:
* [CVE-2018-25022](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25022) The Onion module in toxcore before 0.2.2
See also: [[ToxComparedWithOtherIm]]
See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity>
Previous: [[Home]]
* [[UseGroupPasswordThroughAKDF]]
* [[VulnerabilitiesInTheToxOnion]]
* [[DDosSmallNumberOfBSNodes]]
* Currently, toxcore uses onion routing in the process of establishing connections between friends, with the aim of obscuring their identities from third parties. However, this method does not achieve this goal. [This document describes a proposed replacement for onion routing.](https://github.com/zugz/tox-DHTAnnouncements/blob/master/DHTAnnouncements.md)This proposal is adapted from an original proposal by [grayhatter](https://wiki.cmdline.org/doku.php?id=dht:new_friend_finding).
##mCVEs:
* [CVE-2018-25022](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25022) The Onion module in toxcore before 0.2.2
See also: [[ToxComparedWithOtherIm]]
See also: <https://github.com/TokTok/c-toxcore/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity>

169
ToxAndTorInChinaAndIran.md

@ -1,77 +1,92 @@
Up: [[Home]]
From: https://github.com/TokTok/c-toxcore/issues/419
I don't think indistinguishable message bytes and sizes are going to
make any difference when they are sent over a network of so few bootstrap nodes.
And anyone operating in a hostile environment is probably already
running Tox over Tor, which works well.
Did the reports of blocking in China include blocking over Tor? Tor
itself has implemented pluggable transport mechanisms that are
continuously being improved, and these include ways to make the
traffic look like another protocol like HTTP or whatever:
<https://snowflake.torproject.org/>
So the best way to handle this may be to improve the documentation in
Tox of how to use Tor, and how to configure Tor to use pluggable transports (obfs4).
Whether or not you trust Tor (you can't trust Exit nodes 40% of the time)
they are the only things that work right now in e.g. Egypt or Iran.
I also think the only way of getting a lot of resilience "cheaply" is
to encourage bootstrap node operators to also run a Tor client to serve
the BS node over Onionv3. This is the only way I can see dealing with the
fact that Tox is a network of so few bootstrap nodes. If the Tox nodebase was
improved to serve BS nodes, and OnionV3 relays, it would be much more resilient.
I'm assuming the adversaries cannot block .onion addresses within Tor.
There is a way of configuring a Tor client to uniquely assign a
life-of-the-tor-instance IPv4 address from a predefined private range
(VirtualAddrNetworkIPv4) to each onion address it sees:
```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a
properly configured Tor with just some properly configured BS hosts lists
(if enough BS nodes provided OnionV3 addresses). Then we could leave
the heavy lifting of the cat-and-mouse games of pluggable transports etc.
to Tor (or i2p), and not try to chase them ourselves.
If you have such a list of onion addresses, the Tor user, who is running
a Tor instance anyway to connect with the Tox client, adds this to the
```/etc/tor/torrc```
```
VirtualAddrNetworkIPv4 172.16.0.0/12
AutomapHostsOnResolve 1
```
Then with the list of onion addresses for BS nodes that are running Tox as OnionV3,
then you can use ```tor-resolve``` or ```tor-resolve -4``` to get the
good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user
does this and puts these addresses into his ```DHTnodes.json``` and boostraps his
Tox client over Tor Onions. This works with libtoxcore is it is today, as long as
your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome.
These steps would be automated by a simple bash or Python script,
perhaps a Python script wrapped into an exe for Windows. These addresses are
good for life of the Tor instance, and the script would need rerunning when Tor
is restarted. You can also get the IPv4 address of each Onion BS node,
(for-life-of-the-tor-instance which is usually long enough)
in Python using the Tor stem library.
I've tried this but it's currently impossible to test as there is no equivalent
to the ```other/fun/bootstrap_node_info.py``` script for TCP connections.
For UDP you can send a packet of len 78 with the magic first bytes and get a
version and MOTD reply. Not so for TCP (
in fact if you do send such a packet to the TCP it send the BS node into an
[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)).
So we need a simple fix to the TCP_server code to at least look for a
special packet like this and be nice and send a simple nice reply like
the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331
We should not kid ourselves that we don't all live in China or Iran -
the planet is in a loc$down, and I think we might quickly find out just
how much resiliance we need. s/China/Iran/Syria/Russia/GDR
* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751
* https://www.wired.com/story/russia-block-tor-censorship/
* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook
* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/
Up: [[DDosSmallNumberOfBSNodes]]
Up: [[Home]]
From: https://github.com/TokTok/c-toxcore/issues/419
I don't think indistinguishable message bytes and sizes are going to
make any difference when they are sent over a network of so few bootstrap nodes.
And anyone operating in a hostile environment is probably already
running Tox over [Tor](https://www.torproject.org/download), which works well.
Did the reports of blocking in China include blocking over Tor?
Tor itself has implemented pluggable transport mechanisms that are
continuously being improved, and these include ways to make the
traffic look like another protocol like HTTP or whatever:
<https://snowflake.torproject.org/>
So the best way to handle this may be to improve the documentation in
Tox of how to use Tor, and how to configure Tor to use pluggable transports (obfs4).
Whether or not you trust Tor (you can't trust Exit nodes 40% of the time)
they are the only things that work right now in e.g. Egypt or Iran.
I also think the only way of getting a lot of resilience "cheaply" is
to encourage bootstrap node operators to also run a Tor client to serve
the BS node over Onionv3. This is the only way I can see dealing with the
fact that Tox is a network of so few bootstrap nodes. If the Tox nodebase was
improved to serve BS nodes, and OnionV3 relays, it would be much more resilient.
I'm assuming the adversaries cannot block .onion addresses within Tor,
which I think is a valid assumption.
There is a way of configuring a Tor client to uniquely assign a
life-of-the-tor-instance IPv4 address from a predefined private range
(VirtualAddrNetworkIPv4) to each onion address it sees:
```AutomapHostsOnResolve 1```. So Tox could use OnionV3 BS nodes in a
properly configured Tor with just some properly configured BS hosts lists
(if enough BS nodes provided OnionV3 addresses). Then we could leave
the heavy lifting of the
[cat-and-mouse games](https://github.com/guardianproject/orbot/issues/742)
of pluggable transports etc. to Tor, and not try to chase them ourselves.
If you have such a list of onion addresses, the Tor user, who is running a Tor
instance anyway to connect with the Tox client, adds this to the ```/etc/tor/torrc```
```
VirtualAddrNetworkIPv4 172.16.0.0/12
AutomapHostsOnResolve 1
```
Then with the list of onion addresses for BS nodes that are running Tox as OnionV3,
then you can use ```tor-resolve``` or ```tor-resolve -4``` to get the
good-for-you-only IP addresses of OnionV3 BS nodes in IPv4. So the Tox user
does this and puts these addresses into his ```DHTnodes.json``` and boostraps his
Tox client over Tor Onions. This works with libtoxcore is it is today, as long as
your client doesn't suffer from the dreaded deranged-hard-coded-bs syndrome.
These steps would be automated by a simple bash or Python script, perhaps a
Python script wrapped into an exe for Windows/Android. These addresses are
good for life of the Tor instance, and the script would need rerunning
when Tor is restarted. You can also get the IPv4 address of each Onion BS node,
(for-life-of-the-tor-instance which is usually long enough) in
Python using the Tor stem library.
The best thing we can do is to make these instructions available with
Tox downloads, and to ensure that all distributions of Tox come with
```tor-resolve``` on all platforms. I doubt it comes with
[Orbot on Android](https://github.com/guardianproject/orbot/releases)
and I doubt it comes with [Tor](https://www.torproject.org/download/) or
[Torbrowser on Windows](https://www.torproject.org/download/).
We could ask the maintainers of
[TRIfA](https://f-droid.org/en/packages/com.zoffcc.applications.trifa/) and
[aTOX](https://f-droid.org/en/packages/ltd.evilcorp.atox) to include
it in their distributions, and it would be simple for us to compile a version
of ```tor-resolve``` for our packages to make sure it is available to our users.
It's a static utility that rarely changes.
I've tried this but it's currently impossible to test as there is no equivalent
to the ```other/fun/bootstrap_node_info.py``` script for TCP connections.
For UDP you can send a packet of len 78 with the magic first bytes and get a
version and MOTD reply. Not so for TCP (in fact if you do send such a packet
to the TCP it send the BS node into an
[infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)).
So we need a simple fix to the TCP_server code to at least look for a
special packet like this and be nice and send a simple nice reply like
the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331
We should not kid ourselves that we don't all live in China or Iran -
the planet is in a loc$down, and I think we might quickly find out just
how much resiliance we need. s/China/Iran/Syria/Russia/GDR
* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751
* https://www.wired.com/story/russia-block-tor-censorship/
* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook
* https://www.lifesitenews.com/news/biden-executive-order-allows-spying-on-americans-to-assess-political-instability-climate-threats/
Up: [[DDosSmallNumberOfBSNodes]]

134
ToxComparedWithOtherIm.md

@ -1,68 +1,68 @@
Up: [[SecurityVulnerabilities]]
# Tox Compared With Other IM software
## DeCentralized
### richochet
Always uses Tor, rather than Tox, where Tor can be used at will.
* <https://richochet.im> https: certificate expired over a year ago, and latest version in 2016.
* <https://github.com/ricochet-im/ricochet> last updated 2017.
Relaunched as <https://github.com/blueprint-freespeech/ricochet-refresh>
* no group chat
* can't use system Tor - only its own
* didn't see any mobile apps
* Had a [vulnerability](https://thehackernews.com/2016/02/ricochet-secure-messenger.html) with [HTML in invites](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf)
### briar
* https://briarproject.org/
* https://code.briarproject.org/briar/briar-desktop/
Features:
* Peer-to-peer encrypted messaging and forums
* Messages are stored securely on your device, not in the cloud
* Connect directly with nearby contacts - no Internet access required
* written in Java
* Uses Tor.
* has an [Android](https://briarproject.org/installing-briar-via-f-droid/) app and desktop (the app is more featured than the desktop)
* No support for Windows and macOS
* chats and groupchats
* [Well documented](https://code.briarproject.org/briar/briar/-/wikis/home)
* [Externally Audited](https://briarproject.org/raw/BRP-01-report.pdf): "the quality and readability of the app’s source code was rather exceptional"
* USGov funded: Open Technology Fund/U.S. Agency for Global Media/Radio Free Asia
* The apps are betas that expire in 90 days: "For security reasons, their accounts and data will expire with the beta."
### ZeroNet
* Abandonned by its creator, it is being carried on by a number of
non-cooperating forks.
* A known RCE vulnerability is in some of the forks, but the developers
of the patched forks have not filed a CVE.
* None of the current developers have write access to the main web site,
which distributes code with the CVE.
## Centralized
Centralized systems make it easy to MITM the E2E crypto, so unless they
are open source, they can't be trustworthy.
It is *much* harder to Tox over Tor than to block services like
WhatsApp which relay on centralized servers.
### WhatsApp
* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security
## Signal
[Signal](https://dt.gl/the-2021-review-of-messaging-service-providers-movim/)
not only uses Amazon Web Services servers but also Microsoft and Google servers,
and now to make things even more toxic they are also using
Up: [[SecurityVulnerabilities]]
# Tox Compared With Other IM software
## DeCentralized
### richochet
Always uses Tor, rather than Tox, where Tor can be used at will.
* <https://richochet.im> https: certificate expired over a year ago, and latest version in 2016.
* <https://github.com/ricochet-im/ricochet> last updated 2017.
Relaunched as <https://github.com/blueprint-freespeech/ricochet-refresh>
* no group chat
* can't use system Tor - only its own
* didn't see any mobile apps
* Had a [vulnerability](https://thehackernews.com/2016/02/ricochet-secure-messenger.html) with [HTML in invites](https://ricochet.im/files/ricochet-ncc-audit-2016-01.pdf)
### briar
* https://briarproject.org/
* https://code.briarproject.org/briar/briar-desktop/
Features:
* Peer-to-peer encrypted messaging and forums
* Messages are stored securely on your device, not in the cloud
* Connect directly with nearby contacts - no Internet access required
* written in Java
* Uses Tor.
* has an [Android](https://briarproject.org/installing-briar-via-f-droid/) app and desktop (the app is more featured than the desktop)
* No support for Windows and macOS
* chats and groupchats
* [Well documented](https://code.briarproject.org/briar/briar/-/wikis/home)
* [Externally Audited](https://briarproject.org/raw/BRP-01-report.pdf): "the quality and readability of the app’s source code was rather exceptional"
* USGov funded: Open Technology Fund/U.S. Agency for Global Media/Radio Free Asia
* The apps are betas that expire in 90 days: "For security reasons, their accounts and data will expire with the beta."
### ZeroNet
* Abandonned by its creator, it is being carried on by a number of
non-cooperating forks.
* A known RCE vulnerability is in some of the forks, but the developers
of the patched forks have not filed a CVE.
* None of the current developers have write access to the main web site,
which distributes code with the CVE.
## Centralized
Centralized systems make it easy to MITM the E2E crypto, so unless they
are open source, they can't be trustworthy.
It is *much* harder to Tox over Tor than to block services like
WhatsApp which relay on centralized servers.
### WhatsApp
* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security
## Signal
[Signal](https://dt.gl/the-2021-review-of-messaging-service-providers-movim/)
not only uses Amazon Web Services servers but also Microsoft and Google servers,
and now to make things even more toxic they are also using
[Cloudflare](https://dt.gl/cloudflare-why-the-fuss/) which makes in unusable with Tor.

636
ToxMultiDevice.md

@ -1,318 +1,318 @@
# Toxcore Multi-Device Support Design Proposal
<https://docs.google.com/document/d/1op6zGR0KYdF7tTWSSX79KQieJu30vLZ6XG327kIBhxQ/>
To be a useable communication system, Tox needs to support multiple
devices per user. This is the [TokTok](https://toktok.ltd) proposal.
## Objective
This proposal is an RFC for a possible implementation of multi-device
support for the Toxcore Messenger system. With the goal of replacing
Skype we must come close to feature parity, as well as ease of
use. Currently Tox clients need to share a ToxID. This ID inhibits
connecting with existing friends as it is only well-suited to machine
reading.
The primary goal is to make it simple for clients to securely implement multi-device support, without having to know or manage anything about a contact’s devices.
The following implementation requires some additional features to be
added to Toxcore. These features have been requested before; however,
the goal of this implementation is to add Multi-Device support
only. The additional APIs that would be required (see next section)
would only need to be minimal implementations to get multi-device
working. And while their feature set should be expanded, that’s not
the goal of this implementation.
## Background
ToxID’s are difficult to share without having an existing textual
communication connection (anything you can copy from or paste
to). Sharing ToxID’s in other ways is problematic.
When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their
network. If you need an address, number, or entire friend list it’s a
simple login away.
Not the goal of this project but an important benefit, Multi-Device
support would solve some of the issues sharing a ToxID: it would allow
the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere.
## Prerequisites
### Data Syncing (Friends and Messages):
Devices may go online and offline. It’s required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.(a)[^1](b)[^2]
### Contact Syncing
Contacts (called friends in the Toxcore API) are synced across all
devices using a transactional method. As a pair the devices decide
which will have the primary role, and which will take secondary.
hroughout the entire syncing process, the primary device will send
it’s data, followed by a “done” packet. The secondary will then send
its data, followed by its own “done” packet. The primary device will
then send a “commit” packet, and will then commit the data from
temporary storage, into active use. Once receiving the “commit”
packet, the secondary device will do the same.
Either Client can send an Error packet at either time, which will then
Message ordering
Devices may sync out of order, but messages need to be consistently
ordered. To simplify this, messages will be separated into “connection
sessions”, each getting a pseudorandom tox_session_ID. Messages will
then be ordered within that session by a delta_t. Delta_t in this case
will be the elapsed seconds from the start of the tox instance’s first
current connection to that peer.
Each session will be identified by a pseudo-unique hash from the
previous connect that included a confirmed message receipt. This will
ensure that both sessions and messages are ordered correctly once each
client is completely synced. (Optionally robust verifiability can be
gained by a git style hash of the x parent sessions)
### Pseudo-unique Message IDs
#### Update
```
typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, void *user_data);
```
with
```
typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, uint64_t message_id, uint64_t delta_t, void *user_data);
```
Required for syncing messages between friends * devices. Each message
would include a message_id that would increment with each message. and
reset with each new tox_instance (starting message ID is currently
undecided). Messages id sections would have to be grouped by a client
coming online or going offline. These are per friend, per
connection. And would be the same when sending the same message to
multiple devices of a single friend.
Each of these are pending an implementation spec. But are self-evident
in their use and general implementation.
## Implementation
Security and safety is the primary concern, however this needs to be tempered with usability. The user needs to be prompted to choose high availability or high security.
### Device IDs
Device IDs need to be unique and never changing. On each connect, each
client should query each friend they connect to, to verify if they
support multi-device AND are in a group. This can be done by asking
for the deviceID at ```__device0```. If there is a device at that
address; then enumerate for each other device. Devices will be found
by the string_to_id service using the protected `__device[0-9]+`
group. (Toxcore must protect strings that start with two underscores
such as “__[string]”, and not allow a client to use them in the
string_to_id API.)
Starting with ```__device0```, the client will attempt to resolve the
ToxID at each incrementing ```__device#```. Once a ```__device#```
returns empty, the client should stop. Each ```__device#``` string
should be queried separately, ideally in a pseudo-random order to
prevent clear text attacks on the encryption. {under discussion} For
each ToxID at each ```__device#``` the client must add them to their
list of devices for this friend/user, and probe each device in the
same way. The default should be high security mode, in which if any
list at any device do not match, toxcore should report that friend to
be in an unsecure state, and shouldn’t send any messages to any of the
devices.
The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID.
To enhance security once a ```__device#``` (number) is taken by a
device, that ```__device#``` must always resolve to either the same
ToxID, or to all zeroes [0] if the device has been removed from the
Tox “group” by the user, in a case such as losing the private key, or
uninstalling the Tox client. Toxcore will maintain a local list of
each device for each user, changes to a ```__device#``` will be
assumed to be an impersonation attack. Removed devices will still keep
their ```__device#```, but that ```__device#``` will instead resolve
to zeros. A string of zeros signifies that there was a device, but it
was removed intentionally. A ```__device#``` once resolved to zeros,
must never change back to a ToxID.
To remove or add a device, you will tell toxcore to add the device at
ToxID to this group. That toxcore instance will then, try to connect
to that device and verify that it also wants to connect to the
existing device group. Once accepted, the toxcore instance on the
primary device will assign a ```__device#``` to the new device, and
sync both it’s ID, to the other devices already in the group, as well
as the existing devices to the new device. Once all the devices in the
group are in sync, any of the existing and online devices can sync the
friend/contact list, and the selected amount of history text history
to the new device.
A max limit of devices will need to be chosen later to limit worst
case usage of enumerating devices. (Additional protocol requirements
will be detailed later, i.a. security limitations, verifiable, master
device, slave device, deauthed devices.)
## Message sending
When a client sends a message to a friend/user, Toxcore will only
attempt to send the message to the last 3 devices that sent data from
the user that are online.(c)[^3] (d)[^4] (e)[^5] E.g., Device_A sends a
message, Device_B comes online, Device_C sends a file, Device_D sends
a message then goes off line, Device_F sends a picture, Device_H comes
online. Toxcore will attempt to send only to devices A, C and F. While
H did have the latest data sent/received, it wasn’t data generated by
the user, so we assume that the user is most likely to be on one of
those 3 devices. Toxcore will only have to verify that one client
received the message, and may stop. This will protect the sender from
having to maintain a list of who needs what message, and leave the
additional data syncing up to the receiving client.
It is considered the job of the receiving client to keep all the other
devices in sync with the rest of the group.
### Alternatives Considered
1. Not supporting multi-device (separate friends in the contact list for each device).
* Not considered, this feature is required to be competitive. Not user friendly, no syncing, too hard to create and maintain friend lists.
2. Sharing the private key of a single ToxID to multiple devices.
* Non starter. Security nightmare.
* Requires protocol rewrite.
3. [[GroupOfDevicesPOC]]
4. [[MultiDeviceAnnouncementsPOC]]
### Unsolved Issues
How will messages be hashed to generate the seed for the message ID?
Effective and secure history syncing across devices.
How to add a user to your contact list
* By Primary ToxID(f)[^6](g)[^7]
* By any deviceID
* Something else?
## Roadmap
1. Unique message IDs
1. incrementing numbers
2. delta-from last
2. Device network
1. deviceID vs toxID
2. Adding a device
3. Removing a device
4. Sending a message to more than one device
3. Syncing data
1. contact list
2. messages
3. other?
## Notes & FAQ:
Conversations that need to be added to the spec:
```
<nurupo> say Alice has a tox client running on a phone and another tox client on pc. Alice has Bob in contacts. Bob is online and sends Alice a file.
<nurupo> will Alice see the file request on both clients?
<grayhatter> the file request will go to all online devices
<nurupo> ok, i'm not finished
<grayhatter> then the file will get canceled / "marked as accpeted on a different device"
<nurupo> so, Alice accepts and completes the file transfer on her phone
```
(h)[^8] (i)[^9] (j)[^10]
```
<nurupo> i guess you answered what i wanted to know
<nurupo> what if race condition happens?
<grayhatter> but I hadn't considered that detail... It'll break the existing file transfer API...
<nurupo> Alice accepts files at the same time both on pc and phone?
<grayhatter> nurupo, can't happen
<nurupo> why it can't happen?
<grayhatter> the accept will processed by toxcore on the "sending" device in a single thread, it'll accept for the first device that accepts the transfer, then cancel all other divices
<grayhatter> if two devices accept at the same time, toxcore will choose the device in the lowest number slot only because the loop will start at 0
<nurupo> what if Alice accepts a file on another device before it gets the cancel message?
<grayhatter> it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device
<nurupo> Bob will get two accepts from two devices of Alice?
<grayhatter> yes, but it will ignore the 2nd
<nurupo> how it knows which to ignore?
<grayhatter> (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet)
<grayhatter> psudo code ->
<nurupo> Alice might have accepted the file transfer on the phone first, but because of network latency, Bob received the acceptance from pc first and only then from the phone
<grayhatter> OH
<grayhatter> bob will in that case cancel the phone then
```
(k)[^11]
```
<nurupo> fair enough
<grayhatter> no reason to make it more complicated then it needs to be
```
### Feature Requests:
(Requested publicly, no suggestions have been reviewed or accepted yet.)
* Per device id priority like with XMPP https://wiki.xmpp.org/web/Jabber_Resources
* Per status+deviceid priority, XMPP does that as well
* Ability to address device id explicitly
## Footnotes
* (a)[^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base?
* (b)[^2] I haven't fully decided on the final spec for this question.
Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea.
* (c)[^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad.
* (d)[^4] I'm likely to drop that idea in total.
Currently toxcore sends everything to all devices.
* (e)[^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call.
* (f)[^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal.
* (g)[^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all
* (h)[^8] Does it make sense to think about sending the file to both
clients, if the user accepts on multiple devices? Especially for
bigger files or multiple recipients a P2P protocol (e.g. torrent)
may be useful.
* (i)[^9] Yeah, I've given that a little thought. The current idea
floating around has been to implement something torrent like inside
group chats. Maybe we could use that as well? As far as multiple
devices, what I think is best is transfer the file to the first to
accept, then let the other devices sync the file themselves. That
way the sender doesn't have to spend the extra data for the
receivers convenience.
* (j)[^10] I like that idea. Especially if one thinks about those users
on a phone with limited traffic. You wouldn't want to use all your
available data just so others can sync. You could add a button on
top of lets say a picture saying "sync with my other devices" to
start the transfer of that picture to all your other devices. But
just sending it once should be a lot easier. I'd consider media sync
between my devices as a nice-to-have.
* (k)[^11] Could it be a good idea to allow sync incomplete downloaded
files from device A to device B and then start downloading from device B
# Toxcore Multi-Device Support Design Proposal
<https://docs.google.com/document/d/1op6zGR0KYdF7tTWSSX79KQieJu30vLZ6XG327kIBhxQ/>
To be a useable communication system, Tox needs to support multiple
devices per user. This is the [TokTok](https://toktok.ltd) proposal.
## Objective
This proposal is an RFC for a possible implementation of multi-device
support for the Toxcore Messenger system. With the goal of replacing
Skype we must come close to feature parity, as well as ease of
use. Currently Tox clients need to share a ToxID. This ID inhibits
connecting with existing friends as it is only well-suited to machine
reading.
The primary goal is to make it simple for clients to securely implement multi-device support, without having to know or manage anything about a contact’s devices.
The following implementation requires some additional features to be
added to Toxcore. These features have been requested before; however,
the goal of this implementation is to add Multi-Device support
only. The additional APIs that would be required (see next section)
would only need to be minimal implementations to get multi-device
working. And while their feature set should be expanded, that’s not
the goal of this implementation.
## Background
ToxID’s are difficult to share without having an existing textual
communication connection (anything you can copy from or paste
to). Sharing ToxID’s in other ways is problematic.
When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few
examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their
network. If you need an address, number, or entire friend list it’s a
simple login away.
Not the goal of this project but an important benefit, Multi-Device
support would solve some of the issues sharing a ToxID: it would allow
the clients to connect with mobile devices (NFC, QR codes, other) and
be available anywhere.
## Prerequisites
### Data Syncing (Friends and Messages):
Devices may go online and offline. It’s required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.(a)[^1](b)[^2]
### Contact Syncing
Contacts (called friends in the Toxcore API) are synced across all
devices using a transactional method. As a pair the devices decide
which will have the primary role, and which will take secondary.
hroughout the entire syncing process, the primary device will send
it’s data, followed by a “done” packet. The secondary will then send
its data, followed by its own “done” packet. The primary device will
then send a “commit” packet, and will then commit the data from
temporary storage, into active use. Once receiving the “commit”
packet, the secondary device will do the same.
Either Client can send an Error packet at either time, which will then
Message ordering
Devices may sync out of order, but messages need to be consistently
ordered. To simplify this, messages will be separated into “connection
sessions”, each getting a pseudorandom tox_session_ID. Messages will
then be ordered within that session by a delta_t. Delta_t in this case
will be the elapsed seconds from the start of the tox instance’s first
current connection to that peer.
Each session will be identified by a pseudo-unique hash from the
previous connect that included a confirmed message receipt. This will
ensure that both sessions and messages are ordered correctly once each
client is completely synced. (Optionally robust verifiability can be
gained by a git style hash of the x parent sessions)
### Pseudo-unique Message IDs
#### Update
```
typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, void *user_data);
```
with
```
typedef void tox_friend_message_cb(Tox *tox, uint32_t friend_number, TOX_MESSAGE_TYPE type, const uint8_t *message, size_t length, uint64_t message_id, uint64_t delta_t, void *user_data);
```
Required for syncing messages between friends * devices. Each message
would include a message_id that would increment with each message. and
reset with each new tox_instance (starting message ID is currently
undecided). Messages id sections would have to be grouped by a client
coming online or going offline. These are per friend, per
connection. And would be the same when sending the same message to
multiple devices of a single friend.
Each of these are pending an implementation spec. But are self-evident
in their use and general implementation.
## Implementation
Security and safety is the primary concern, however this needs to be tempered with usability. The user needs to be prompted to choose high availability or high security.
### Device IDs
Device IDs need to be unique and never changing. On each connect, each
client should query each friend they connect to, to verify if they
support multi-device AND are in a group. This can be done by asking
for the deviceID at ```__device0```. If there is a device at that
address; then enumerate for each other device. Devices will be found
by the string_to_id service using the protected `__device[0-9]+`
group. (Toxcore must protect strings that start with two underscores
such as “__[string]”, and not allow a client to use them in the
string_to_id API.)
Starting with ```__device0```, the client will attempt to resolve the
ToxID at each incrementing ```__device#```. Once a ```__device#```
returns empty, the client should stop. Each ```__device#``` string
should be queried separately, ideally in a pseudo-random order to
prevent clear text attacks on the encryption. {under discussion} For
each ToxID at each ```__device#``` the client must add them to their
list of devices for this friend/user, and probe each device in the
same way. The default should be high security mode, in which if any
list at any device do not match, toxcore should report that friend to
be in an unsecure state, and shouldn’t send any messages to any of the
devices.
The ```__device#``` list for every client must match exactly to what every other device reports. And each ```__device#``` once used must always resolve to that ID.
To enhance security once a ```__device#``` (number) is taken by a
device, that ```__device#``` must always resolve to either the same
ToxID, or to all zeroes [0] if the device has been removed from the
Tox “group” by the user, in a case such as losing the private key, or
uninstalling the Tox client. Toxcore will maintain a local list of
each device for each user, changes to a ```__device#``` will be
assumed to be an impersonation attack. Removed devices will still keep
their ```__device#```, but that ```__device#``` will instead resolve
to zeros. A string of zeros signifies that there was a device, but it
was removed intentionally. A ```__device#``` once resolved to zeros,
must never change back to a ToxID.
To remove or add a device, you will tell toxcore to add the device at
ToxID to this group. That toxcore instance will then, try to connect
to that device and verify that it also wants to connect to the
existing device group. Once accepted, the toxcore instance on the
primary device will assign a ```__device#``` to the new device, and
sync both it’s ID, to the other devices already in the group, as well
as the existing devices to the new device. Once all the devices in the
group are in sync, any of the existing and online devices can sync the
friend/contact list, and the selected amount of history text history
to the new device.
A max limit of devices will need to be chosen later to limit worst
case usage of enumerating devices. (Additional protocol requirements
will be detailed later, i.a. security limitations, verifiable, master
device, slave device, deauthed devices.)
## Message sending
When a client sends a message to a friend/user, Toxcore will only
attempt to send the message to the last 3 devices that sent data from
the user that are online.(c)[^3] (d)[^4] (e)[^5] E.g., Device_A sends a
message, Device_B comes online, Device_C sends a file, Device_D sends
a message then goes off line, Device_F sends a picture, Device_H comes
online. Toxcore will attempt to send only to devices A, C and F. While
H did have the latest data sent/received, it wasn’t data generated by
the user, so we assume that the user is most likely to be on one of
those 3 devices. Toxcore will only have to verify that one client
received the message, and may stop. This will protect the sender from
having to maintain a list of who needs what message, and leave the
additional data syncing up to the receiving client.
It is considered the job of the receiving client to keep all the other
devices in sync with the rest of the group.
### Alternatives Considered
1. Not supporting multi-device (separate friends in the contact list for each device).
* Not considered, this feature is required to be competitive. Not user friendly, no syncing, too hard to create and maintain friend lists.
2. Sharing the private key of a single ToxID to multiple devices.
* Non starter. Security nightmare.
* Requires protocol rewrite.
3. [[GroupOfDevicesPOC]]
4. [[MultiDeviceAnnouncementsPOC]]
### Unsolved Issues
How will messages be hashed to generate the seed for the message ID?
Effective and secure history syncing across devices.
How to add a user to your contact list
* By Primary ToxID(f)[^6](g)[^7]
* By any deviceID
* Something else?
## Roadmap
1. Unique message IDs
1. incrementing numbers
2. delta-from last
2. Device network
1. deviceID vs toxID
2. Adding a device
3. Removing a device
4. Sending a message to more than one device
3. Syncing data
1. contact list
2. messages
3. other?
## Notes & FAQ:
Conversations that need to be added to the spec:
```
<nurupo> say Alice has a tox client running on a phone and another tox client on pc. Alice has Bob in contacts. Bob is online and sends Alice a file.
<nurupo> will Alice see the file request on both clients?
<grayhatter> the file request will go to all online devices
<nurupo> ok, i'm not finished
<grayhatter> then the file will get canceled / "marked as accpeted on a different device"
<nurupo> so, Alice accepts and completes the file transfer on her phone
```
(h)[^8] (i)[^9] (j)[^10]
```
<nurupo> i guess you answered what i wanted to know
<nurupo> what if race condition happens?
<grayhatter> but I hadn't considered that detail... It'll break the existing file transfer API...
<nurupo> Alice accepts files at the same time both on pc and phone?
<grayhatter> nurupo, can't happen
<nurupo> why it can't happen?
<grayhatter> the accept will processed by toxcore on the "sending" device in a single thread, it'll accept for the first device that accepts the transfer, then cancel all other divices
<grayhatter> if two devices accept at the same time, toxcore will choose the device in the lowest number slot only because the loop will start at 0
<nurupo> what if Alice accepts a file on another device before it gets the cancel message?
<grayhatter> it'll show inprogress on that device, with 0 transfer, then toxcore on the sending device will still send the cancel to that device
<nurupo> Bob will get two accepts from two devices of Alice?
<grayhatter> yes, but it will ignore the 2nd
<nurupo> how it knows which to ignore?
<grayhatter> (I'm saying all of this from what my plans are, I haven't even started on filetransfers yet)
<grayhatter> psudo code ->
<nurupo> Alice might have accepted the file transfer on the phone first, but because of network latency, Bob received the acceptance from pc first and only then from the phone
<grayhatter> OH
<grayhatter> bob will in that case cancel the phone then
```
(k)[^11]
```
<nurupo> fair enough
<grayhatter> no reason to make it more complicated then it needs to be
```
### Feature Requests:
(Requested publicly, no suggestions have been reviewed or accepted yet.)
* Per device id priority like with XMPP https://wiki.xmpp.org/web/Jabber_Resources
* Per status+deviceid priority, XMPP does that as well
* Ability to address device id explicitly
## Footnotes
* (a)[^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base?
* (b)[^2] I haven't fully decided on the final spec for this question.
Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea.
* (c)[^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad.
* (d)[^4] I'm likely to drop that idea in total.
Currently toxcore sends everything to all devices.
* (e)[^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call.
* (f)[^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal.
* (g)[^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all
* (h)[^8] Does it make sense to think about sending the file to both
clients, if the user accepts on multiple devices? Especially for
bigger files or multiple recipients a P2P protocol (e.g. torrent)
may be useful.
* (i)[^9] Yeah, I've given that a little thought. The current idea
floating around has been to implement something torrent like inside
group chats. Maybe we could use that as well? As far as multiple
devices, what I think is best is transfer the file to the first to
accept, then let the other devices sync the file themselves. That
way the sender doesn't have to spend the extra data for the
receivers convenience.
* (j)[^10] I like that idea. Especially if one thinks about those users
on a phone with limited traffic. You wouldn't want to use all your
available data just so others can sync. You could add a button on
top of lets say a picture saying "sync with my other devices" to
start the transfer of that picture to all your other devices. But
just sending it once should be a lot easier. I'd consider media sync
between my devices as a nice-to-have.
* (k)[^11] Could it be a good idea to allow sync incomplete downloaded
files from device A to device B and then start downloading from device B

2
ToxNetworkResilience.md

@ -32,7 +32,7 @@ configuration:
# Tox hidden service configuration.
HiddenServiceDir /var/lib/tor/tox-hsv3/
HiddenServicePort 3389 127.0.0.1:3389
HiddenServicePort 3389 127.0.0.1:33446
HiddenServicePort 33446 127.0.0.1:33446
```
assuming your Tor lib directory os ```/var/lib/tor```. In that subdirectory
you will find a file named ```hostname``` which is the ```.onion``` name

12
UseGroupPasswordThroughAKDF.md

@ -1,6 +1,6 @@
Up: [[SecurityVulnerabilities]]
Chatting with sudden6 (Sep 2022) says this still an open vulnerability.
Use the group password only through a KDF by sudden6
<https://github.com/JFreegman/toxcore/pull/27>
Up: [[SecurityVulnerabilities]]
Chatting with sudden6 (Sep 2022) says this still an open vulnerability.
Use the group password only through a KDF by sudden6
<https://github.com/JFreegman/toxcore/pull/27>

18
VulnerabilitiesInTheToxOnion.md

@ -1,9 +1,9 @@
Up: [[SecurityVulnerabilities]]
Chatting with JF (Aug 2022) makes me think that these are still open:
Known vulnerabilities in the tox onion:
* <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md>
* <https://github.com/TokTok/c-toxcore/issues/1121>
[algor1th](https://github.com/algor1th) created a formal model that shows that announcements are linkable, and note trace equivalent to searches. It can be found at https://github.com/algor1th/tox-verification/blob/master/dht.dps. Linkability here means that a public key of a node can be linked to it's ip adress when announcing.
Up: [[SecurityVulnerabilities]]
Chatting with JF (Aug 2022) makes me think that these are still open:
Known vulnerabilities in the tox onion:
* <https://github.com//zugz/tox-onionPathsProposal/blob/master/onionVulns.md>
* <https://github.com/TokTok/c-toxcore/issues/1121>
[algor1th](https://github.com/algor1th) created a formal model that shows that announcements are linkable, and note trace equivalent to searches. It can be found at https://github.com/algor1th/tox-verification/blob/master/dht.dps. Linkability here means that a public key of a node can be linked to it's ip adress when announcing.

2
_Footer.md

@ -1 +1 @@
Up: [[Home]]
Up: [[Home]]