@potta
more from that month
Embed/Enable Donate BCH button
#PoweredByMonolith @Read.Cash recently posted (or boosted) a wonderful list of sites which are either built on top of BCH or use BCH in some way. One of the coolest among that list I found was the Donate Button site. If you have a website or a blog like the one on read.cash, you are able to add a widget and let people donate BCH to you and your cause. I am going to try it out here in this post and see if it works. I don't know if I can use HTML markup in these posts so let's try this out! <iframe src='https://donatebutton.cash/e?a=qpk8cy96gak3kw7d2a3gneahvne3lj79dg7rcytmwx&l=BCH PLS' width='150' height='150' style='border:none;overflow:hidden'></iframe> `<iframe src='https://donatebutton.cash/e?a=qpk8cy96gak3kw7d2a3gneahvne3lj79dg7rcytmwx&l=BCH PLS' width='150' height='150' style='border:none;overflow:hidden'></iframe>` If you have any questions about this or want some help embedding this button on your site or blog, please just let me know and i'll be happy to help!
12 comments
@Monolith here is my SLP address simpleledger:qp7jghrmkguan5qmf6mmy78nr0dz64dguctyrh8x37
Reward campaign is over thanks to read.cash inconsistencies and lowsy customer service.
Oh, I did not know that. Thanks for letting me know!
I don't think it makes any sense to allow that embed, because we have basically the same button right beneath each article...
Yup that totally makes sense. I was only thinking of it because this one looks a little fancier with color and styling etc but that makes sense.
And yes, we don't allow HTML in posts, because allowing random HTML would allow a smart person to get to the seed phrase stored in the browser, so everybody who reads the article might kiss their BCH good bye :)
This makes sense but I would think the seed phrase is stored in some sort of a one way encryption algorithm right and not as plain text. Hopefully it’s not that easy to steal the seed phrase!
One-way encryption means you encrypt it and can never decrypt it. How would you use it then? That is only used for password storage, since we don't need to know your password. We just need to compare the results of encryption of when you registered to encryption result right now. If they match - great, we let you in. For seeds you probably mean symmetric encryption, where you encrypt it and can decrypt it later (in code) to use it, because every transaction that you make needs your unencrypted seed phrase (actually a private key derived from the unencrypted seed phrase). But here is the thing - if OUR code can somehow get to the unencrypted seed phrase (no matter how well encrypted it was prior) - then ANY code we allow via HTML can get to it. There's just no "secure enclave" in browsers that we can use to securely store it so that only SOME code can get to it. The only way would be to ask for a decryption password everytime you click "send" or tip or anything to move your money. But this password must be pretty long (maybe 30 characters) to avoid brute force (hackers trying every possible compination to decrypt your seed). Imagine the horrible user interface and experience where you have to type 30 letters just to tip somebody $0.01 and then you have a problem that if a code can be run - hackers can simulate the same password prompt and then just steal your password. So, yeah, it's freakingly easy to steal your seed from a web browser if one can run any code on read.cash. We closed probably evey possible way to do it, but that's exactly why we tell people not to keep a lot in this online wallet. There is one way to improve the security of this - keeping the seed in a iframe on another domain, but it's technically much more complex to do, so we still haven't got to do it. Someday... when we have a little more time. But it's still not a guarantee :)
Got it. I was thinking maybe just store the hashes and authenticate it the way you authenticate password hashes. If both the hashes match then you're good to transact. But I guess at that point a hash is as good as the unencrypted seed if that is enough to make a tx. So is the unencrypted seed stored as a cookie in my browser? Does that mean anything else that can read my cookies can also read my seed? That anything else can be another application which is writing other cookies or malware. Also instead of that, could you not do any kind of session based or token based authentication to get rid of the seed storage altogether? Just thinking out loud.
Not cookies, but "local storage". We (read.cash) can see your cookies, but we can't see your local storage. Ok, we _could_ see, but we don't do it. By default we see cookies and don't see the local storage. Only sites on "read.cash" domain can read your local storage. The problem is that if we do it ANY other different way - it means that WE are storing your private key, not you. In that case we are money servicing business and that requires AML/KYC and a ton of licenses.
Taking the time to explain all these issues coherently means a lot in this space.
Thank you for explaining all this in such a clear language. This is a topic other site creators seem to shun. Some of us in the process of creating sites have calculated and recalculated how to achieve what you are doing in the same context. ---- The issue this illustrates is the necessity of competent wallets for BCH. ---- Those of us who have thought this through want absolutely nothing to do with handling payments for someone else. The 'your keys, your cash, your choices' mantra makes BCH awesome, and it survives as long as we who serve can help clients spend safely. ---- An excellent read.