The latest articles on DEV Community by Shubham Sahu (@isagi0011). https://dev.to/isagi0011 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4168853%2F83ede465-24bc-4e79-a1be-1d50e68865a2.jpg https://dev.to/isagi0011 en Shubham Sahu Wed, 07 Oct 2026 12:29:46 +0000 https://dev.to/isagi0011/sharing-a-file-once-is-a-workflow-problem-not-just-an-encryption-problem-nosus-design-questions-27ma https://dev.to/isagi0011/sharing-a-file-once-is-a-workflow-problem-not-just-an-encryption-problem-nosus-design-questions-27ma <p>I'm Shubham, the developer of NoSus, a sharing product built with Flutter/Dart, Supabase/Postgres, Deno functions, and a Next.js website. I would appreciate technical and usability feedback on the boundaries between encryption, access controls, and what the interface promises.</p> <p>A file-sharing interface has to answer several different questions:</p> <ul> <li>Can the recipient open it without an account?</li> <li>Does a read consume access, or can the same link be reopened?</li> <li>What does revocation stop after a recipient has already opened or downloaded something?</li> <li>Does a displayed name or email prove who the viewer is?</li> </ul> <p>NoSus has an account-free Burn tool at <a href="https://nosus.foo" rel="noopener noreferrer">https://nosus.foo</a>. Its direct links carry encryption keys in the URL fragment. However, single notes/files also generate a two-digit redemption code: the corresponding key remains server-side temporarily while that code is valid, even when someone uses the direct link. That distinction matters when describing the security model.</p> <p>The document-sharing workflow uses viewer-entered email watermarks, activity logs, and revocation. An entered email is an attribution clue, not verified identity. SecureSend is access-controlled rather than end-to-end encrypted. Revocation cannot erase screenshots, printed pages, or downloaded copies.</p> <p>Here is a small test with no confidential content: create a dummy Burn note, copy its link, open it in another browser, and attempt a second open. Note which steps are unclear and whether the result matches what you expected.</p> <p>For developers who build sharing flows, I would value feedback on:</p> <ol> <li>Which UI wording best distinguishes future-access revocation from erasing an existing copy?</li> <li>What failure cases would you prioritize testing for a one-time claim, particularly concurrent opens or an interrupted connection?</li> <li>How would you explain the server-held redemption-key window without hiding it behind a generic encryption badge?</li> </ol> <p>Please keep any security findings non-sensitive in public replies. This is a request for critique of my own product, not a claim that a forum discussion constitutes a security audit.</p> showdev security webdev discuss