TA

My feedback

  1. 168 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      3 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
      TA supported this idea  · 
    • 24 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
        TA shared this idea  · 
      • 384 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          under review  ·  28 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
          TA supported this idea  · 
          TA commented  · 

          Tor does NOT mean no Javascript. Having Javascript enabled when trying not to be recognised by the site you're visiting IS a bad idea. That's why the Tor browser disables it by default.

          However, the threat model here is different - accessing Tutanota as a Tor hidden-service is about not letting your ISP, nosy government, or the creepy guy in the corner at Starbucks know that you are a tutanota customer. It prevents dragnet style attacks. Given that .onion-addresses ARE the public key of the service, the security is rather higher than the TLS/SSL PKI infrastructure, meaning it's way harder for someone to fiddle with the Javascript code of the application. Since some nation states DO legitimately own certificate authorities, TLS/SSL does NOT currently protect against nation states.

          Accessing Tutanota via Tor exit nodes is only as secure as regular TLS/SSL (see above).

          Aside 1: Legal targeted surveillance will not be impeded by this, because once you're an identified target, they can always bug your devices or shoulder surf.

          Aside 2: I don't know enough about i2p to speak to it's security properties.

        • 2 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
            TA shared this idea  · 
          • 1,061 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              53 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →

              Thank you all for your feedback. Please let us explain in more detail why we don’t plan to add pgp-support at the moment:

              Current encryption standards like pgp and S/MIME have several issue that we plan to address with Tutanota. These standards do not support forward secrecy and are not resistant to attacks from quantum computers.

              In addition, it is important to us that the subject line in emails is also encrypted. That’s why we have developed a solution that is also based on recognized algorithms (RSA and AES) and that automatically encrypts the subject, the content and the attachments. In the future, we plan to upgrade these algorithms to quantum-resistant ones that also support forward secrecy.

              We also see the importance that Tutanota needs to be interoperable with other encryption solutions. We will develop an API so that Tutanota users can communicate with users of other…

              TA supported this idea  · 
              TA commented  · 

              ...and yes, despite it's weaknesses, properly used pgp is still the largest secure mail system out there. If I know the proper key for a contact, I would like to be able to add it in my contacts and - after being warned about the potential problems - send pgp encrypted mail.

              At least enable receiving and verifying pgp emails - done properly with rotating sub-keys etc. What's the logic behind forcing experienced secure mail users to go plaintext because I'm using a secure email service.

              TA commented  · 

              RSA? How is that resistant to attacks from future quantum computers? Please reconsider this and add switch to proper post-quantum crypto. Maybe djb's nacl for everything else.

            • 193 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)
                You have left! (?) (thinking…)
                under review  ·  15 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
                TA commented  · 

                Yes, app lock isn't the greatest of security measures, but it is better than nothing. iOS, if properly configured will wipe the phone after a number of failed attempts, which makes even a simple PIN barrier quite a hurdle.

                TA supported this idea  · 
              • 137 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  23 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
                  TA commented  · 

                  I would prefer locking/unlocking functionality. Two-factor in mobile apps often leads to both factors being available on the device. That's very low security combined with the hustle of security theater.

                  A simple app locking functionality that wipes the keys in RAM is more appropriate in my opinion.

                Feedback and Knowledge Base