3 ms·

Hey, creator here. I'm a little late to reply as I was getting some sleep. You're obviously entitled to your opinion about Puter. It's completely fine if you t

by ent101 4y ago

Hey, creator here. I'm a little late to reply as I was getting some sleep. You're obviously entitled to your opinion about Puter. It's completely fine if you think this is a very terrible idea. I disagree but I guess only time will tell. But I just wanted to say that it's categorically false that Puter is trying to harvest data and sell it later. It's clearly spelled out in its Terms of Service and Privacy Policy. I'm not trying to dupe anyone into anything, just hoping to build a better cloud storage service...

survirtual 4y ago
I am not doubting business potential; I can give two expletives about you or anyone else making money. I care only about users / customers. A few things: 1) please read my other comment about encrypting / address encryption of data. 2) a ToS can be changed at any time in the future. If you value privacy, bake in client-side encryption ASAP. Use bcrypt + salt for the password hashing and use something like libsodium (https://libsodium.gitbook.io/doc/secret-key_cryptography/secretstream https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...) to encrypt/decrypt. These are both available in js: Bcrypt: https://www.npmjs.com/package/bcrypt https://www.npmjs.com/package/bcrypt Libsodium: https://www.npmjs.com/package/libsodium https://www.npmjs.com/package/libsodium Off the top of my head, have a user enter a password, generate a random nonce, hash it with bcrypt, store that hash to localstorage. Create a secretbox stream with that hash and run any data being persisted through that stream. This will add some safety to userdata. 3) if you do well and get acquired your ToS doesn’t protect anyone but yourself / the new owners 4) the instant you start accepting VC money you will slowly have less and less say in any of this — make protecting customers your first priority asap.
- ent101 4y ago
  I agree with you 100% on client-side encryption. I need some time to get it right but it's definitely a priority. It's coming soon. As for ToS and Privacy Policy. I didn't use an off-the-shelf document from the internet because I was trying to make sure it's clear the data is not being harvested in any way, but I guess I need to amplify that more. What do you suggest? I'm genuinely curious and would like to know your suggestions. Thanks again :)
  - survirtual 4y ago
    I’m not a lawyer so I’d suggest working with one and seeing what sort of language can protect your users now and in the future. Encryption is an important key here, and I’d want to see source of the core app to make sure it handles all that appropriately. If I was you, I’d publish the core app as open source, and I’d sandbox apps potentially in iframes with reduced permissions & inject a message channel to talk with the main app. You could control access to any secrets on the main app this way, so users have some safety guarantees. Basically: Main app (secret management, styling, window management, etc) | |——————— msg channel <-> apps | | |——————— (de)crypt <-> persist Have the apps talk with the core and any core services via a message based event loop. Have all persistence go through a service on the core. Apps can potentially be closed sourced safely that way. Whatever you do, make it so third party power users can independently verify it is legit and the entire project will be much more able to stand scrutiny.
    - ent101 4y ago
      Thank you for the detailed reply. The sandboxing and messaging is already implemented. I think that's the only way I can guarantee data safety when it comes to having 3rd-party apps. I'm actually planning to open source the whole thing (fingers crossed) this way anyone can look into the code!

by ent101 4y ago

survirtual 4y ago

I am not doubting business potential; I can give two expletives about you or anyone else making money. I care only about users / customers. A few things: 1) please read my other comment about encrypting / address encryption of data. 2) a ToS can be changed at any time in the future. If you value privacy, bake in client-side encryption ASAP. Use bcrypt + salt for the password hashing and use something like libsodium (https://libsodium.gitbook.io/doc/secret-key_cryptography/secretstream https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...) to encrypt/decrypt. These are both available in js: Bcrypt: https://www.npmjs.com/package/bcrypt https://www.npmjs.com/package/bcrypt Libsodium: https://www.npmjs.com/package/libsodium https://www.npmjs.com/package/libsodium Off the top of my head, have a user enter a password, generate a random nonce, hash it with bcrypt, store that hash to localstorage. Create a secretbox stream with that hash and run any data being persisted through that stream. This will add some safety to userdata. 3) if you do well and get acquired your ToS doesn’t protect anyone but yourself / the new owners 4) the instant you start accepting VC money you will slowly have less and less say in any of this — make protecting customers your first priority asap.

ent101 4y ago
I agree with you 100% on client-side encryption. I need some time to get it right but it's definitely a priority. It's coming soon. As for ToS and Privacy Policy. I didn't use an off-the-shelf document from the internet because I was trying to make sure it's clear the data is not being harvested in any way, but I guess I need to amplify that more. What do you suggest? I'm genuinely curious and would like to know your suggestions. Thanks again :)
- survirtual 4y ago
  I’m not a lawyer so I’d suggest working with one and seeing what sort of language can protect your users now and in the future. Encryption is an important key here, and I’d want to see source of the core app to make sure it handles all that appropriately. If I was you, I’d publish the core app as open source, and I’d sandbox apps potentially in iframes with reduced permissions & inject a message channel to talk with the main app. You could control access to any secrets on the main app this way, so users have some safety guarantees. Basically: Main app (secret management, styling, window management, etc) | |——————— msg channel <-> apps | | |——————— (de)crypt <-> persist Have the apps talk with the core and any core services via a message based event loop. Have all persistence go through a service on the core. Apps can potentially be closed sourced safely that way. Whatever you do, make it so third party power users can independently verify it is legit and the entire project will be much more able to stand scrutiny.
  - ent101 4y ago
    Thank you for the detailed reply. The sandboxing and messaging is already implemented. I think that's the only way I can guarantee data safety when it comes to having 3rd-party apps. I'm actually planning to open source the whole thing (fingers crossed) this way anyone can look into the code!