• youmaynotknow@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    7 hours ago

    This is cool. If you’re worried about the safety on their instance, spin your own. They have a very clear and simple docker way to do just that.

  • peregus@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    13 hours ago

    Send lets you share files with end-to-end encryption

    How is this possible if the only thing that is shared between sender and receiver is just a link (that is provided by the website)?

    How can we trust https://send.vis.ee/? Who are they?

    • RmDebArc_5@sh.itjust.works
      link
      fedilink
      arrow-up
      13
      ·
      13 hours ago

      How it works: I don’t know about this service in particular, but usually the shared contains the encryption key so like this: example.com/files/file_id/encryption_key or something similar

      As for trust: This appears to be a individual, so you will have to just trust it when using the public instance. However, since it is FOSS, you can audit the code and spin up your own instance

      • peregus@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        2 hours ago

        How it works: I don’t know about this service in particular, but usually the shared contains the encryption key so like this: example.com/files/file_id/encryption_key or something similar

        But if the key is in the URL, that’s provided by the server, where’s the utility of the encryption since the server knows it and so does everyone that has the URL?

        • flux@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 hours ago

          So the trick is to use the #fragment part of the URL, that is not sent to the server.

          Of course the JS one downloads from the server could easily upload it to it, so you still need to trust the JS.

          • peregus@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            2 hours ago

            But the JS code could be checked on the webpage, correct? If so, the page could be trysted (if vetted).

      • Handles@leminal.space
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        10 hours ago

        spin up your own instance

        Absolutely. If you’re at all worried about sending files through third party sites, set up your own. Provided you trust your own security skills, of course.

        I would certainly be more interested in having an install under my own domain than using some rando’s that I don’t know.

    • chebra@mstdn.io
      link
      fedilink
      arrow-up
      4
      ·
      13 hours ago

      @peregus @dl007

      Wiki End-to-end encryption:
      > The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves. Because no third parties can decipher the data being communicated or stored, for example, companies that provide end-to-end encryption are unable to hand over texts of their customers’ messages to the authorities.

      You don’t have to trust the server.

      • peregus@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        3 hours ago

        The recipients retrieve the encrypted data and decrypt it themselves

        Ok, but how can the recipient decrypt it if he doesn’t have the key? The only thing that’s shared is the URL and if the key is in the URL, well, I don’t know what’s the use for it since the server knows it.

            • chebra@mstdn.io
              link
              fedilink
              arrow-up
              0
              ·
              2 hours ago

              @peregus It’s explained in other threads here. The key is in the url but behind # and that part is invisible to the server. protocol://host:port/path?query#fragment, server will only see …?query, so both participants can decrypt, but server can’t => E2EE

      • jwmgregory@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        11 hours ago

        that still isn’t an explanation of how the server supposedly “does not have the means to decrypt them [the messages]”, which isn’t me saying it’s impossible. i’m well aware of possible cryptographic solutions here. but, it isn’t wrong to be sus of this application until the organization/developers have demonstrated a degree of trustworthiness. i honestly don’t see why you would use this over just encrypting and transfering the data yourself using more traditional methods that involve the minimum number of parties. i might just be ignorant of this project, but i’m weary of it until i have a chance for further investigation

    • redxef@feddit.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      13 hours ago

      The fragment of a URL is not sent to the server, so that’s where such platforms usually store the key. That’s also the way cryptpad does it. You can thus share the URL and with it the key.

      Of course, you still need to trust the platform. The sourcecode link at the bottom of the page links to https://github.com/timvisee/send who forked from mozilla/send and links back to the web page.