[Freedombox-discuss] BitTorrent Sync

Jonathan Wilkes jancsika at yahoo.com
Wed Jan 30 18:14:58 UTC 2013


----- Original Message -----

> From: Elena ``of Valhalla'' <elena.valhalla at gmail.com>
> To: freedombox-discuss at lists.alioth.debian.org
> Cc: 
> Sent: Wednesday, January 30, 2013 4:06 AM
> Subject: Re: [Freedombox-discuss] BitTorrent Sync
> 
> On 2013-01-29 at 16:56:16 -0800, Jonathan Wilkes wrote:
>>  "Supports ssh", or even "supports encryption" is not 
> the same as "uses
>>  encryption out of the box".  From that same link:
> 
> one significant usecase for git-annex is condivision of files 
> between computers in one own home, using only devices under 
> you control (e.g. usb storage devices).

We just assume the LAN to be secure for these use cases?

> 
> using encryption in these cases is either not needed (the devices 
> don't leave your home) or better left to the filesystem layer 
> (the devices do leave your home, but you want to be able to 
> access the contents directly)

I have a hard time believing the modern cost of encrypting/decrypting
outweighs the benefit of a one-click interface-- like Mega-- where
encryption is built into the design.  (And I'm _only_ talking about the
interface here-- it's irrelevant whether Mega actually delivers any
security unless you believe that screwing around inside config files
is vital to the design of an application.)

No doubt the user should devote some thought to the difference between
running code on machines he/she owns and on machines under someone
else's control, but that's mostly to realize what a danger the latter is.  It
doesn't mean you forgo security in the former case, especially when forgoing
security measures would result in more configuration and cognitive load for the
user.

> 
>>  "git-annex mostly does not use encryption. Anyone with access to a git
>>  repository can see all the filenames in it, its history, and can access
>>  any annexed file contents."
> 
> the git repositories are supposed to be local or under owner's control; 
> special remotes don't usually include a git repo
> 
>>  and from http://git-annex.branchable.com/walkthrough/using_ssh_remotes/
>> 
>>  "Note that normally git-annex prefers to use non-ssh remotes, like a 
> USB drive, before ssh remotes. They are assumed to be faster/cheaper to access, 
> if available. There is a annex-cost setting you can configure in .git/config to 
> adjust which repositories it prefers. See the man page for details."
>> 
>>  Note that "non-ssh remotes" are by default unencrypted-- these 
> could include network drives
>>  or other resources on the LAN that you're not accessing through ssh 
> (and thus lose the benefit
>>  of its encryption).  The user shouldn't have to choose the slower 
> method of transporting data in order
>>  to get encryption, nor should they have to tunnel a LAN resource over ssh 
> just to get the benefit of
>>  its encryption for syncing data.  "Unencrypted = fast" sets up a 
> false dichotomy.
> 
> note that in the manpage the distinction is not between ssh and
> non-ssh, but between *local* (=directly connected to your computer) and 
> *remote* (=accessed via a network, *including* a LAN): most devices that 
> are directly connected to the machine (e.g. USB storage devices) *are* 
> faster than anything accesses through a network. 
> The wording in the walkthrough is misleading, probably because 
> it came from a time where the only remotes available where ssh 
> and local filesystem.
> 
> Of course, if you can access some network device via the filesystem 
> git-annex has no way to know that device is not really local, 
> and here is where the remote.<name>.annex-cost configuration 
> is useful.
> 
>>  > As for scaling, it depends what you're after, but since (if using 
> the
>>  > assistant) you can nudge remotes into attempting to pull from one
>>  > another via XMPP, I think it's got quite a few of the real world 
> use
>>  > cases covered for scalability too.
>> 
>>  Why wouldn't the machines pull from each other by default?
> 
> mostly because they are not assumed to have direct and constant access 
> to each other.

It's too bad there isn't a file-sharing protocol designed to work under the
assumption that machines are constantly jumping on and off the net.

-Jonathan

> 
> -- 
> Elena ``of Valhalla''
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
> 



More information about the Freedombox-discuss mailing list