Hide Secrets With ******

[atomicorange]

I have not found one but is there a way to hide "***************" the secret fields in the preferences / settings box so it can only be viewed with a password. I am on OSX Maverick.

 

 

[ChrisH]

There is no such option. Why would you want that?

BTSync is a peer-to-peer platform, not the master-server-dumb-clients solution that some people seem to expect.

[crash893]

I agree with ChrisH on this

 

Why

 

do you think someone is going to memorize a secret key over your shoulder in the 1 second you paste it into the window?

 

 

the only argument for ******************* ing the password is because you have someone over your shoulder (which can easily be solved)

or you have a malicious program doing screen shots or taking snapshots of your clipboard which if that is the case your system is compromised anyway so the point is still mute 

[ChrisH]

The way I understood it is that he wants to roll out BTSync to users without them having the secret.

 

By your interpretation the requirement makes even less sense to me

[lg0]

What would be nice is if you setup the folder via the API to supply a password so that the secret read write is not displayed when requested unless the password is supplied, only avalible through the API

 

 

 

Use Case: Accounting Department shares files between computers. One user is getting fired today and wants to take it all with him.... OMG they have the keys to the castle. 

[ChrisH]

So the user just plugs in his trusty portable harddisk / USB key / smartphone and copies all the juicy data onto that.

 

(Also, WTF? An accounting department that can't afford a simple file server?)

[piotrnik]

I do think something like this would be nice, but I also agree that it's kind of against the design philosophy of BTSync in the first place - peers are equal, and it's not  a client/server setup.

[lg0]

So the user just plugs in his trusty portable harddisk / USB key / smartphone and copies all the juicy data onto that.

 

(Also, WTF? An accounting department that can't afford a simple file server?)

 

You haven't worked for a company called upside... a server is an old developers workstation.

[alleoma]

Imagine, there is a client that hides keys: the IOS one (and, apparently, the Android one, too, although it can be set up to give out keys). Instead, it offers you "links", so that two peers could share the real key between them. Some folks do feel very uncomfortable with that (see more http://forum.bittorrent.com/topic/31588-wont-use-getsynccom-link-for-sharing/). And that makes sense.

 

However, the IOS client does one good thing. It asks your approval on every new peer it registers to use one of its keys. And that provides for some "server/clients" policy administration. You may write down the key, which would be of no use until approved with every particular peer client.

 

I'd suggest extending this peer approval approach (as an option) to all desktop versions as well (in fact, it already is there, in 1.4), and complementing it with a list of approvals being in effect (currently, you seem not to be able to see whom have you given an approval, or whom have you turned down), and an option to revoke particular approvals per peer client.

 

Certainly, some provisions should be made to describe these approvals in manual config files (like those on Linux, NASes, etc.). And that, in turn, may need some disclosure of peer identifiers that Sync uses. And the latter might help suggesting peers without knowing their IP addresses and incoming ports (I can't tell my desktop client anything about a mobile client, as I can't tell or set up a fixed incoming port on any mobile client, which would also be quite apposite in this context; no matter if I can set up a fixed IP address for it).

 

That would add much more to the feeling of security than just hiding keys from direct view. Although, a sort of passcode to sensitive settings would also be welcome.