Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Observation of Usage Behaviour by Distinguishability #124

Open
roeslpa opened this issue Jan 5, 2016 · 2 comments
Open

Observation of Usage Behaviour by Distinguishability #124

roeslpa opened this issue Jan 5, 2016 · 2 comments

Comments

@roeslpa
Copy link
Collaborator

roeslpa commented Jan 5, 2016

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?!

@roeslpa
Copy link
Collaborator Author

roeslpa commented Jan 11, 2016

@cburkert and @schulze what do you think?

@cburkert
Copy link
Contributor

Seems to be a valid point. I'd suggest we keep this in mind for the Drop redesign.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants