Hi Tim-Luca, I'm sorry if I'm poking holes in the comments of your first post on dev.to but I feel like I should speak up given the very specific tool you developed.
Although the intentions are good and React and crypto are definitely useful skills to acquire I have to say that I'm a bit wary of the idea of a program to encrypt files running in a browser, especially if it uses npm dependencies in the browser that lately have been known to be hi-jackable if left untended for long stretches of time.
Theoretically one could inject a JS that sends the data to a third party or modifies the crypto algorithm by... not crypting :D
Think about it: telling people "do not run this while connected" doesn't mean nobody ever will, even inadvertently.
Also, what happens if there's a bug in your code but the user's browser is still serving the bugged version after the update? I have had instances of browser not updating JS files, especially if running on localhost.
Finally: since you can't control the browser the user executes the app in, how can you be sure they are always using a strong random number generator?
As you can't be sure that the user will abide by your recommendation of running it only when offline, it's hard to be sure of the rest.
You write in the README:
Use on local machine without internet
Realistically... most users's machines are often online, if not 24/7. And if the threat model of a user requires a completely disconnected computer, why bother using an in browser crypto tool at all? Isn't it safer to use a native open source tool with a signed binary and peer reviewing?
Turning off the wifi, running the tool, turning on the wifi doesn't really make it fool proof, even if you as the creator are careful.
Sorry if I'm a bit pessimistic here, I understand that it might be a safe tool for your needs, but it might not be for others and that's a little bit worrying.
It's a perfectly valid experiment though, well done!
:-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Tim-Luca, I'm sorry if I'm poking holes in the comments of your first post on dev.to but I feel like I should speak up given the very specific tool you developed.
Although the intentions are good and React and crypto are definitely useful skills to acquire I have to say that I'm a bit wary of the idea of a program to encrypt files running in a browser, especially if it uses npm dependencies in the browser that lately have been known to be hi-jackable if left untended for long stretches of time.
Theoretically one could inject a JS that sends the data to a third party or modifies the crypto algorithm by... not crypting :D
Think about it: telling people "do not run this while connected" doesn't mean nobody ever will, even inadvertently.
Also, what happens if there's a bug in your code but the user's browser is still serving the bugged version after the update? I have had instances of browser not updating JS files, especially if running on localhost.
Finally: since you can't control the browser the user executes the app in, how can you be sure they are always using a strong random number generator?
As you can't be sure that the user will abide by your recommendation of running it only when offline, it's hard to be sure of the rest.
You write in the README:
Realistically... most users's machines are often online, if not 24/7. And if the threat model of a user requires a completely disconnected computer, why bother using an in browser crypto tool at all? Isn't it safer to use a native open source tool with a signed binary and peer reviewing?
Turning off the wifi, running the tool, turning on the wifi doesn't really make it fool proof, even if you as the creator are careful.
Sorry if I'm a bit pessimistic here, I understand that it might be a safe tool for your needs, but it might not be for others and that's a little bit worrying.
It's a perfectly valid experiment though, well done!
:-)