My thoughts so far

[SyncAppTester]

User interface

1. Remove action on Shared Folders tab doesn't ask user for confirmation.
   
2. "Shared Folders" would be better named "Synced Folders" (as suggested by at least one other user on this forum). This is especially true now that you have added read-only folders.
   
3. It would be nice if the Shared Folders tab indicated the degree of synchronisation with the other nodes. e.g. If I add a new folder and it has only downloaded 5% of the folder contents, it would be useful to know that.
   
4. Advanced Preferences popup has no OK or Cancel buttons, and instead has a Reset button where you expect the OK button to appear. (I keep clicking Reset by accident).
   

General

The read-only mode needs a mirroring mode (as suggested by at least one other user on this forum), or some way of bringing the folder back in sync with the "master". At the moment there's no obvious way of fixing things if you delete files from a read-only folder. My suggestion would be that read-only mode should work by constantly keeping the folder in sync with the "master" (replacing files that have been deleted) - otherwise you have abandoned the concept of "syncing".

To provide a use-case for this issue: I would like to backup my personal files from home to my work PC, as an offsite backup. I want to use a read-only folder on my work PC to reduce the risk of damaging my home files. Howwver, if I accidentally delete a file from the read-only folder on my work PC, I have then broken my offsite backup. It will not repair itself, and unless I am aware of the accidental deletion it will never be fixed.

Security

I'm guessing other users have already raised this.. but the security of the one-time secrets seems to be far lower than the normal secret or read-only secret.

The codes are far shorter and I can generate a seemingly endless supply of them, any of which will work, even after a newer one has been generated. I'm not a crypto/security expert, so maybe I shouldn't worry, but this area of the app disturbs me.

Can you explain how the one-time secrets functionality works? If I click Generate 10 times, have I just made available 10 possible "passwords" to my data? Do I even need to click Generate? Could someone guess (given enough time) one of the codes that the UI would generate?

----

In case that all sounds a bit negative.. I must say that overall BitTorrent Sync looks really promising. This kind of application has been a long time coming, so thank you for finally making it happen!

[kos13]

General

The read-only mode needs a mirroring mode (as suggested by at least one other user on this forum), or some way of bringing the folder back in sync with the "master". At the moment there's no obvious way of fixing things if you delete files from a read-only folder. My suggestion would be that read-only mode should work by constantly keeping the folder in sync with the "master" (replacing files that have been deleted) - otherwise you have abandoned the concept of "syncing".

There are two major use cases for read only. First case is that you've described. Second when you deliver something to a person and person wants to delete the file. For example to free the space. These two cases requires different behavior from Sync and we are thinking how to achieve it in a nice way.

I'm guessing other users have already raised this.. but the security of the one-time secrets seems to be far lower than the normal secret or read-only secret.

The codes are far shorter and I can generate a seemingly endless supply of them, any of which will work, even after a newer one has been generated. I'm not a crypto/security expert, so maybe I shouldn't worry, but this area of the app disturbs me.

Can you explain how the one-time secrets functionality works? If I click Generate 10 times, have I just made available 10 possible "passwords" to my data? Do I even need to click Generate? Could someone guess (given enough time) one of the codes that the UI would generate?

One time Secret is actual for 24 hours or until first time used. So depending on how fast you will use it, it would be valid for minutes up to a 24 hours. Main use case is to send the one time secret over IM or email, so person could connect device and after that one time secret becomes useless. In such a case, if someone will get access to your email, he won't be able to connect to your computer.

It is shorter than main Secret, but timeframe that it is valid is much shorter.

----

In case that all sounds a bit negative.. I must say that overall BitTorrent Sync looks really promising. This kind of application has been a long time coming, so thank you for finally making it happen!

Thank you!

[SyncAppTester]

There are two major use cases for read only.....These two cases requires different behavior from Sync and we are thinking how to achieve it in a nice way.

You're right about needing two different behaviours. I hope that you able to accomodate both, as they would both be useful.

One time Secret is actual for 24 hours or until first time used. So depending on how fast you will use it, it would be valid for minutes up to a 24 hours. Main use case is to send the one time secret over IM or email, so person could connect device and after that one time secret becomes useless. In such a case, if someone will get access to your email, he won't be able to connect to your computer.

It is shorter than main Secret, but timeframe that it is valid is much shorter.

When I click Generate, to generate a new one-time secret, is that a purely random key that is stored locally by the Sync client for 24 hours, and then discarded?

Or is the Sync client deriving a key from a combination of the current time and the main secrets?

[kos13]

When I click Generate, to generate a new one-time secret, is that a purely random key that is stored locally by the Sync client for 24 hours, and then discarded?

Correct. Plus it is discarded if another peer connected using this one-time secret.

Let me show you the algorithm to explain the concept:

Machine 1: You generate one time secret, it is completely random without any relation to master secret;

Machine 1: Sync is waiting for another peer that will have this one time secret;

Machine 2: You enter one-time secret. Machine 2 will find Machine 1 and connects to it;

Machine 1: See new peer that uses one-time secret, sends master secret. Disconnects. Discard the key.

Machine 2: Got master key and connects to Machine 1 using master secret;

If Machine 1 will not see any peer for this one-time secret in 24 hours, it will discard the key.

[SyncAppTester]

That's great, and very reassuring! Thank you for the detailed explanation.

[kanine]

Just to also confirm my thoughts on sync after a few days use. I'd also like to see some kind of Mirror/Two Way sync differentiation. I like to think of this as either a Subscription, or Collaboration.

With subscription, you are offering the secret to those clients that want to Subscribe to the information from the master. That means it will always be an exact duplicate (maybe with some client side filters). With collaborate it is a true two way sync with the original master, once again maybe client level filters can come into play.

Then we have an excellent backup/replication tool as well as a great collaboration tool.

I thought it was really cool when I recently added a second computer at home, and included it to sync with the office. Seeing it pull the data from the office and other home lan client was a very satisfying moment. Perhaps I need to get out more!

Keep up the great work, I think this tool has a great future.

[kos13]

You have two option right now:

- You distribute RW key - then two users could collaborate;

- If you distribute Read Only key, the second computer will get all changes from master, but can't affect master copy.

Will this cover your cases? Or you have some other use cases?