alleoma

It would be great to limit at least IP addresses / Subnets of connecting peers, in the client itself. Just like predefined hosts can be indicated (apropos: search LAN alone seems not to help start syncing with predefined hosts on a LAN, where with DHT also on it works, so the use scenario of a trackerless, relayless, DHT-less private sync network with only some predefined clients ever contacted seems not to be possible, for DHT effectively breaks it as such). Please, add a built-in networking ACLs support to all clients. (Save the peer approval support). Thanks!

I can't tell my desktop client about a mobile client as a predefined host, which appeared on the same LAN (over Wi-Fi at home, or otherwise), or behind a NAT where such a mobile client could have been assigned a fixed portmap. Setting a fixed listening IP address for a mobile client could be done with external means. However, you can never tell the listening port it may choose. Without that, making firewall rules for additional security, establishing direct connections to mobile clients behind a NAT, etc., are impossible. Please, add the explicit setting of listening port to mobile versions of Sync. Thanks!

Added an associated Feature Request, as suggested: http://forum.bittorrent.com/topic/31843-add-use-key-advanced-setting-to-ios-client-as-on-android/

The new key exchange procedure for IOS-based devices looks like specific overcare for Apple users, as you can't get a key out of it directly. Instead, you're offered a "link" only. That makes things uncomfortable for those who sync with Linux-based NASes, etc., older Sync versions (like the Windows XP one), where you may need to edit configuration files directly, that is, with no GUI or web interface (the latter looks like gets disabled in this case at that), or otherwise need to input a key manually. A workaround for the predicament is here: http://forum.bittorrent.com/topic/31588-wont-use-getsynccom-link-for-sharing/ However, given that a key generated on IOS can be leaked easily anyway over an Android peer connection, would you please add a "Use key" option (as on Android version) to the IOS version as well, to enable also exporting a key as is, not just "links"? Thanks!

@GreatMarko > Peer Approval itself is already available in desktop versions of Sync 1.4 Except for, probably, the Linux version configured manually, with the keys (secrets) in the config file, or via the API. Am I correct? That is, presently, approvals are a GUI locked-down feature. And, if I'm not mistaken, you can't revoke approvals per peer (hopefully, changing a key for a folder should trigger general reapproval for it).

I'd suggest extending this peer approval approach (as an option) to all desktop versions as well. And complement 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 config files (like those on Linux). 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).

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.

I've found, for example, that if an IOS phone (with Sync client) on a LAN gets a new IP address over a short period of time via DHCP (after Wi-Fi reconnect, or whatever), apparently, it seems to no longer get noticed by its peer(s) (e.g., a Linux client) on the same LAN (I've waited for an hour, with DHT on, search LAN on). Restarting the Linux client helps instantly. But before that, you can't tell why it's not syncing. Would be nice to see more status info on recently connected clients. Something like "Last contacted" time indication would be of much help, too. Say nothing of its IP address and listening port, etc.

The new key exchange procedure for IOS-based devices is a specific overcare for Apple users (who must have got used to be limited to only absolutely fool-proof settings to play with; hmmm, who are they deemed to be then?). Proof: unlike on IOS, you can use an advanced setting "Use key" on Android versions of the Sync client, which gives you choice between sharing a link, or a key. Hence, I've found a solution, or rather a workaround: send/copy the key link to an Android Sync client, using it to connect a Camera Backup folder to be synced there (you may pause syncing at once, as we're not going to sync here), and then re-share the key from the context settings of that folder (for Camera Backup it'll give a RO key only). It worked for me like a charm. And now I'm happily watching syncing tens of gigabytes of pictures and movies from my iPhone to an external drive connected to my Linux box. Just had to add another section to the config file and approve the connection on the iPhone. On security of these links: with respect to IOS client at least, and bearing in mind that there is no actual key encoded in the link (as indicated above), I think, sending such links over email or whatever in cleartext gives much more peace of mind. Especially considering that: (1) links are temporary (30 days or something); (2) links are limited to the maximum number of uses (not sure how is it to be controlled without some central accounting); and (3) the IOS client (sic!) asks your approval for every client connecting using a link or a key leaked as I've explained. That is, on IOS, the client guards your pictures well. Just don't approve, and you're more or less safe. 2Sync developers: given that a key generated on IOS can be leaked easily anyway, would you please add a "Use key" option to the IOS version as well?