Swisstengu

Members
  • Posts

    31
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Swisstengu

  1. Battery Drain!!

    The battery usage of the Android app is extremely heavy. Prior to installing, I could get an entire day of phone usage on a single charge.

    While using Bittorrent Sync, my phone sometimes runs out of charge by noon.

    Looking at the battery information, I've seen Bittorrent Sync use as much as 44%.

    This really needs to be addressed.

    Lastly, BubbleUPnP will not run while Bittorrent Sync is running.

    same problem on a nexus4, stock android. 3 folders, about 1.9Mo. Phone's heating, and the battery life has lowered in a very bad way (could last for about 2 days, now about 12 hours…)

  2. Hello,

    It may be a good thing to allow Sync to start on device boot - I didn't see this option in the configuration, though it may be nice to have it up n'running once the phone/tablet is started.

    Also, it may be really usefull to have the possibility to add the known_hosts configuration to the shares on the app.

    In my case, I'm wanting to not use the standard trackers, meaning I'm using DHT… and my phone has some problems finding the source for the sync-ed data…

    Would it be possible to add such features in a near future? Any roadmap/timeline?

    Thanks a lot!

    Cheers,

    C.

  3. @Dantounet: seems to be an I/O error, according to the error number (it's the sqlite error returned). Maybe the hard drive (or… SD card ? don't tell me you're using btsync on an sd-card…) has some problems.

    Also, the RPi has an unreliable USB connection - this may create some problems if you have an USB hard drive…

    For such a use, maybe the cubieboard[1] is better, as it has a dedicated sata port, and it's a bit more robust…

    Have a look at system logs (such as dmesg), it may give you some more information.

    Cheers,

    C.

    [1] http://cubieboard.org/

  4. Hello!

    About the same problem - I opened a ticket and have some contacts with BitTorrent team. Problem seems to be at sqlite level, some trailing locks or something like that.

    You can see this by enabling the debug mode, start it over - you'll stumble on SyncDB errors stating it's unable to complete the statement (i.e. cannot insert new content) - the DB is locked.

    Hopefully this will be corrected shortly.

    Cheers,

    C

  5. wouldn't really be wise as if someone finds your secret key, they could easily decode the base 64 and get your email address and password.

    http://www.opinionat...s/base64decode/

    Sure - but the point is: "Yes, we can!" actually use some custom credentials (provided they are unique - i.e. not used for our private mail account, and so on ;) ).

    Won't be less secure though provide some nice way to remember the string.

  6. I disagree, as this is a problem that has been solved numerous times over. Not to mention that using a one-time key is an additional solution over all of the other solutions already out there.

    +1

    This is a user problem, not btsync… *user* is responsible for his own security, as well as his devices security. If he wants to share keys between devices, there are a fair number of existing solutions… GPG is the one I'm using, as I, by default, use it on all my devices, but there are others… why not use SCP in order to push the configuration to some other hosts ? Or even webdav over SSL with some strong password (and, of course, SSL for the server) ?

    BTSync is one piece of the puzzle - it's working, provides nice features - the rest of the puzzle should be solved by the users.

    Some howto may be more intersting as "implementing some new stuff which will create more problems than solve" like a "secure way to exchange keys"…

  7. Public key cryptography does not solve anything when the private key is also stored on the same machine. Alternatively, if each keypair is different per peer, then you can manually verify each peer that connects to your node, however this is terrible in terms of usability. It means for every one peer you add, due to the distributed nature you have to verify that peer on every single other node. When you add another peer, you have to do that again, with one more to verify, etc. Imagine having to do with when you have 200 or more peers syncing with each other.

    Oh, this is named SSH, isn't it ? ;)

    A fingerprint may be provided by the host, maybe… It may be a nice feature, but as you pointed out, it will be a hasle to validate them while having more than 6 devices…

  8. Greetings to all,

    BTsync is really interesting.

    The problem with using your username and password rather than secret key is not given the difficulty of use.

    The problem, in my opinion, is that the password is not written anywhere and stays in people's heads.

    The secret key instead is written in clear on your pc and this can lead to being stolen.

    If a person physically takes possession of my computer for a few seconds can be seen in light of the secret key and send it anywhere.

    We must, in some way, do not write anywhere the secret key and the display of the same must be done with an additional password.

    At least as an additional feature for the truly paranoid

    The key in plain sight (especially in Windows) is not safe.

    Francesco

    Just don't use Windows, if you're "truely paranoid" ;). </troll>

  9. Under Linux, you may as well create a dedicated btsync user, give the config-file to it only (chown btsync: <config> && chmod 0600 <config>), and ensure this btsync user has at least rights to write in the directories.

    Meaning : either he owns some directory, or, if you want to sync some directories in your home, you'll have to add "btsync" to your usergroup, and ensure your umask is 002 as well as btsync process, and do a chmod 2775 <directory>.

    This way, you will be able to add content to this directory as well as btsync user.

    As previously said, there is no such thing as "login" in btsync process - only crypto. The secret key is not to be considered as a credential information, as it is a encryption key (or part of).

    Just one other note:

    if someone can physically access your computer, you're screwed, you can't do anything against that. You have to ensure nobody can log in your computer, or access the BIOS, or add stuff to it (physical keylogger for example) - at this extend, you'd better work in some bunker I guess ;).

    The current system with the secret is good enough. It's people responsability to ensure it's not in the wild. This may as well be a good way to understand how leaks happen in real life, how people can get Root CA from, for example, Komodo ;).

    Be safe, be sure of your environment - that's all.

    Side node bis: if you really want something nice, just start some headless, daemonized virtual machine such as a KVM or xen instance, running the btsync stuff - only access should be through SSH, with some private, password-protected key. You can even encrypt the VM hard drive to prevent someone clone it and get its content ;).

    Security can go really far. But, imho, it must be the user concern - BitTorrent team provided a good tool, we have to ensure our own security from now on ;).

    Cheers,

    C.

  10. I was using git in order to sync some stuff across my computers. Using AGit client on my android devices, I was able to do only pulls - no way to edit data.

    Now, with Sync, I'm able (well, I'll BE able, once we can provide the known_hosts params to Sync mobile ;) ) to push modification from my mobile devices as well.

    That's for my personnal use… Regarding some more professional suff, I'm currently testing Sync in order to maintain about 1.7To of data on ~20 servers.

    For now, we have one master, and there are, daily, an rsync running from all the others. You can imagine the load as well as the time it takes.

    With Sync, it should be able to:

    - leverate the load on the master

    - accelerate dramatically the speed of update

    Knowing there's only "small" diffs (about 10% of the total size so far), Sync should be the good way to do that. Plus, having about 20 servers, it's a good way to use the p2p protocol, as they will be able to sync different chunk from different hosts, meaning the load will be distributed on every servers. The master will still need to work a bit more than the others, but as it will distribute different chunks to each slaves, it won't be that scary.

    Thanks a lot for this app, there are some improvements (like replacing ionotify by fnotify, for example), but, really, it's on a very good way!

    Cheers,

    C.

  11. Great app indeed - just one thing is missing for me (already told to the Team): possibility to add known_hosts to the shares. As I'm not wanting to use the tracker, I have to define the known_hosts, at least with my own server.

    Can't wait for this feature to come, as, without it, my smartphone cannot sync anything :(.

    For the rest, it's really well-thought, being able to bypass the QRCode stuff is a very good point (working most of the time on headless servers… no QR can be generated ;) ).

  12. I'm using GPG in order to crypt my mails - easy, fast, works on any computer and android phone ;). Provide a good way to transfert such sensible data.

    Regarding Torxic-hero concern: for now, we can just trust Bittorrent there is no "master key" being able to decrypt all contents… That's why opensourcing the code would be a great move from their part.

    PRISM and other stuff like that (go back in time - Echelon ;) ) just show more than once we cannot really trust closed application…

    More over, opensourcing stuff may provide some great improvement if the community may provide patches to the code, more application, more apps, more security, more… just MOAR :)

    Cheers,

    C.

  13. Just encrypt your mail containing the secret - GPG isn't there for nothing ;). It may as well be used on Android phone (with APG) in case you don't have a way to get the QRCode for the mobile app (there's also something for iOS I guess).

    More over, as GreatMarko pointed it out, there's no "log in"-thing, secret is used in order to do crypto stuff on chunk content and as share folder name for btsync to know what we want.