<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello</p>
    <p><br>
    </p>
    There are other tor settings also entered manually. For example
    access to hidden service that requires cookie auth.<br>
    HidServAuth site.onion mycookie<br>
    <br>
    Currently i use this feature to access my servers.<br>
    <br>
    <div class="moz-cite-prefix">On 21.11.2016 15:04, arrase wrote:<br>
    </div>
    <blockquote
cite="mid:CADjgV3DsOu989nmgm5JmjhhvUOuYbY3uGoaAjXtYTT0xx2dyGA@mail.gmail.com"
      type="cite">
      <p dir="ltr">And the services that a user configure manually? Why
        do you have to lose them?</p>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">El 21 nov. 2016 2:00 p. m.,
          "Hans-Christoph Steiner" <<a moz-do-not-send="true"
            href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>>
          escribió:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            About the hidden service backups, that certainly would be a
            useful<br>
            feature, but it should not be implemented in Orbot.  The
            requesting apps<br>
            need to be entirely responsible for saving, managing and
            backing up that<br>
            key.  Orbot will never be able to provide all of the various
            levels of<br>
            security needed by different apps using Hidden Services. 
            For example,<br>
            something like OnionShare might only have one-time-use
            Hidden Services<br>
            that are thrown away after use.  Another app might have a
            long-lived<br>
            hidden service that is too sensitive to be backed up via
            Google or other<br>
            cloud services.<br>
            <br>
            .hc<br>
            <br>
            arrase:<br>
            > 2016-11-21 0:25 GMT+01:00 Nathan of Guardian <<a
              moz-do-not-send="true"
              href="mailto:nathan@guardianproject.info">nathan@guardianproject.info</a>>:<br>
            ><br>
            >><br>
            >> We only need Internet permission, so haven't had to
            deal with the new<br>
            >> permission request framework.<br>
            >><br>
            >> Why do we need a backup feature? I thought the
            approach was for apps to<br>
            >> manage their keys themselves, at least advanced
            apps?<br>
            >><br>
            ><br>
            > By example, if you have ssh running at your device and
            you want to maintain<br>
            > the same .onion in a device migration.<br>
            ><br>
            > You can manually create and restore an .onion backup
            from one device to<br>
            > another.<br>
            ><br>
            >> Even so, couldn't we offer backup without needing
            external storage<br>
            >> permissions?<br>
            >><br>
            ><br>
            >  With the ability to be exported to another device
            writing a zip in the<br>
            > external store is the simplest I think.<br>
            ><br>
            ><br>
            >> I bring this up because I know our users are very
            sensitive to this, and<br>
            >> the external storage permission is one that often
            sets off concern since<br>
            >> you are giving access to full media.<br>
            >><br>
            ><br>
            > Well, is true but with runtime permissions the user is
            asked only when is<br>
            > going to perform an action who actually needs them, so
            you can assume than<br>
            > there is no panic if the app ask for those permissions.<br>
            ><br>
            > Also, the permissions were already there before I
            started to make changes,<br>
            > so we understand that all those users who have an older
            version of android<br>
            > have to accept them when installing the application
            from the store and does<br>
            > not seem to have been a Problem for Orbot to date.<br>
            ><br>
            > On the other hand, it seems that they are not used in
            the application, if<br>
            > they are not used, why are they there? And if they are
            used, the parts of<br>
            > the code that use them are not working in the latest
            versions of android<br>
            > since there is no code that manages them.<br>
            ><br>
            > That needs a review.<br>
            ><br>
            ><br>
            >> Thanks for the hard work on this, and I will
            definitely take a look at<br>
            >> the UI issues.<br>
            >><br>
            ><br>
            > To you.<br>
            ><br>
            <br>
            --<br>
            PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA
            00AA 5556<br>
            <a moz-do-not-send="true"
href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556"
              rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/<wbr>lookup?op=vindex&search=<wbr>0xE9E28DEA00AA5556</a><br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
List info: <a class="moz-txt-link-freetext" href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev">https://lists.mayfirst.org/mailman/listinfo/guardian-dev</a>
To unsubscribe, email:  <a class="moz-txt-link-abbreviated" href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org">guardian-dev-unsubscribe@lists.mayfirst.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>