The actions a user performs can be distinguished by the type (=size and destination) of sent files. Thus it can be recognized that a file or a folder is shared or revoked. If the server provider knows the recipients Drop ID (e.g., by being its contact) it can guess who shares files with whom (by also uploading meta files, drop msgs can assumed to be no fake). Might be a too scientific scenario but we could be confronted with this attack.
| Action |
Drop Msg |
Meta Files |
Files |
User Relation |
| Create Dir |
0 |
2 (2xDM) |
0 |
|
| Share Dir |
1+ |
1 (iDM) |
0 |
X |
| Unshare Dir |
0+ |
n (all DMs below) |
0 |
X |
| Create File |
0 |
1 (DM) |
1 |
|
| Update File |
0 |
1 (DM) |
1 |
|
| Share File |
1+ |
3 (iDM, DM, FM) |
0 |
X |
| Update Shared File |
0 |
2 (DM, FM) |
1 |
~ |
| Unshare File |
0+ |
2-3 (iDM, DM, FM) |
0 |
X |
The easiest improvement would be always sending a random number of drop messages additional to the needed ones. This would remove the ability to track the recipient. But the actions are still distinguishable by the number of meta files. I want to ask whether we want to solve it (and then how) or accept it?!
The actions a user performs can be distinguished by the type (=size and destination) of sent files. Thus it can be recognized that a file or a folder is shared or revoked. If the server provider knows the recipients Drop ID (e.g., by being its contact) it can guess who shares files with whom (by also uploading meta files, drop msgs can assumed to be no fake). Might be a too scientific scenario but we could be confronted with this attack.
The easiest improvement would be always sending a random number of drop messages additional to the needed ones. This would remove the ability to track the recipient. But the actions are still distinguishable by the number of meta files. I want to ask whether we want to solve it (and then how) or accept it?!