Topic: 5 BTC giveaway! (Ended) - page 2. (Read 6134 times)
cfb7327f9360
Dooglus, I'd be interested in your feedback on this site in comparison to satoshidice.com. Do you see any interesting pros/cons in contrast?
To me it seems straight-up better here.
To me it seems straight-up better here.
SatoshiDice is clearly much better. Because I'm a shareholder.
Other than that, the almost-instant feedback here is very nice, as is the ability to make custom games.
SatoshiDice obviously has much higher max bets than any of the recent clones and works even when the website is unavailable. But other than those two advantages CoinRoll looks good to me. I guess another concern would be whether they have a large enough bankroll to cover the inevitable swings of fortune. When the edge is only 1% you can go quite far into the red before seeing a profit, and the site needs to be able to cover the loss for a while. Then of course there's the question of reputation. SDICE has been around for a long time (in Bitcoin years...) and so feels a little safer than the new places for now. Provable fairness doesn't help you if the site just disappears with your balance one day.
553098633cb8
Dooglus, I'd be interested in your feedback on this site in comparison to satoshidice.com. Do you see any interesting pros/cons in contrast?
To me it seems straight-up better here.
553098633cb8
6f4f1bec95fa
Thanks for a great game
Thanks for a great game
9c309fd00ce4
6ac480b50387
I simply don't know what is your experience with this, and on what you are basing your answers. Are you aware of, for example, http://seckb.yehg.net/2012/06/xss-gaining-access-to-httponly-cookie.html ? This is the return of five seconds googling, I hope you are aware of people that simply don't share their findings in this area. Storing passwords in plain text anywhere is simply a bad idea, supposedly safe cookies in 2013 do not make them a better idea. You can just ignore the situation, of course.
Had you read your own damn link you'd realize:
a) This is a JAVA/SILVERLIGHT/INSERTSTUPIDSHITHERE EXPLOIT
b) It still doesn't break the domain sandbox, which means that the attacker would have to XSS it into my website somehow. I filter/sanitize all user-supplied input.
Class dismissed.
You are skipping another approach that should be obvious: there are bugs everywhere. I don't actually need to compromise a computer in order to access their cookies (including the httpOnly ones), I just need a browser with a bug that has been published (or not) which allows access to cookies.
Of course there are other approaches, maybe they are just not feasible for you ? GMail uses cookies too, but plain passwords is something you won't find there.
Of course there are other approaches, maybe they are just not feasible for you ? GMail uses cookies too, but plain passwords is something you won't find there.
I suspect you're going to have to wait for a long time for that bug, because this is the sort of bug that would break the entire internet. Cookies are sandboxed. If a bug allows a website to read another website's cookies then that's the mother of all 0days.
I simply don't know what is your experience with this, and on what you are basing your answers. Are you aware of, for example, http://seckb.yehg.net/2012/06/xss-gaining-access-to-httponly-cookie.html ? This is the return of five seconds googling, I hope you are aware of people that simply don't share their findings in this area. Storing passwords in plain text anywhere is simply a bad idea, supposedly safe cookies in 2013 do not make them a better idea. You can just ignore the situation, of course.
You are skipping another approach that should be obvious: there are bugs everywhere. I don't actually need to compromise a computer in order to access their cookies (including the httpOnly ones), I just need a browser with a bug that has been published (or not) which allows access to cookies.
Of course there are other approaches, maybe they are just not feasible for you ? GMail uses cookies too, but plain passwords is something you won't find there.
Of course there are other approaches, maybe they are just not feasible for you ? GMail uses cookies too, but plain passwords is something you won't find there.
You're arguing just for the sake of argument.
I suspect you're going to have to wait for a long time for that bug, because this is the sort of bug that would break the entire internet. Cookies are sandboxed. If a bug allows a website to read another website's cookies then that's the mother of all 0days. In a universe where a bug of this magnitude is likely to happen then you might just have browsers accessing your files (along with your wallet.dat), accessing other processes' memory (yes, your encrypted wallet), or even deleting your hard drive.
Here are the alternatives:
1) Sending the password encrypted to the browser. That would accomplish nothing since there's still a 1-to-1 relationship of encrypted to cleartext.
2) A static session ID. Again, if someone got a hold of your session ID they would be able to access your account.
3) A dynamic session ID that changes on every request. Would make it a bit harder but the end result is the same.
Since the password is dynamically generated and I don't allow you to change it, it acts as a unique ID. This is not Gmail, this is not a banking website. It's a game with loginless "accounts".
Nice layout, and I'm mostly ok with the API.
But! This is a big "but" for me, by the way. Stop storing the user/password in a cookie, and specially do not store anywhere in plain text (much more specially don't do that in the cookies!). I just did a SELECT * FROM moz_cookies WHERE baseDomain = 'coinroll.it'; on cookies.sqlite from Firefox and I see everything as clear as it can get.
My second issue is the limit of bets. Are you scared of someone suddenly getting lucky on < 1 and stealing all your pot ?
Nevertheless, congrats on making a decent API for it.
But! This is a big "but" for me, by the way. Stop storing the user/password in a cookie, and specially do not store anywhere in plain text (much more specially don't do that in the cookies!). I just did a SELECT * FROM moz_cookies WHERE baseDomain = 'coinroll.it'; on cookies.sqlite from Firefox and I see everything as clear as it can get.
My second issue is the limit of bets. Are you scared of someone suddenly getting lucky on < 1 and stealing all your pot ?
Nevertheless, congrats on making a decent API for it.
This was a design choice. I wanted it to be loginless and stateless. The alternative would be to have a (static) session ID which would pretty much have the same effect: if someone has access to your machine they can access your Coinroll balance. Which I don't think is a problem anyway. If your system is compromised you have bigger problems than your balance on a gambling website.
The cookie has the 'httpOnly' and 'secure' flags set, so it can't be read by javascript and it is only transmitted via HTTPS.
You are skipping another approach that should be obvious: there are bugs everywhere. I don't actually need to compromise a computer in order to access their cookies (including the httpOnly ones), I just need a browser with a bug that has been published (or not) which allows access to cookies.
Of course there are other approaches, maybe they are just not feasible for you ? GMail uses cookies too, but plain passwords is something you won't find there.
5e90c36ccef5
Lucky #
e98f-6c29-003c
e98f-6c29-003c
Nice layout, and I'm mostly ok with the API.
But! This is a big "but" for me, by the way. Stop storing the user/password in a cookie, and specially do not store anywhere in plain text (much more specially don't do that in the cookies!). I just did a SELECT * FROM moz_cookies WHERE baseDomain = 'coinroll.it'; on cookies.sqlite from Firefox and I see everything as clear as it can get.
My second issue is the limit of bets. Are you scared of someone suddenly getting lucky on < 1 and stealing all your pot ?
Nevertheless, congrats on making a decent API for it.
But! This is a big "but" for me, by the way. Stop storing the user/password in a cookie, and specially do not store anywhere in plain text (much more specially don't do that in the cookies!). I just did a SELECT * FROM moz_cookies WHERE baseDomain = 'coinroll.it'; on cookies.sqlite from Firefox and I see everything as clear as it can get.
My second issue is the limit of bets. Are you scared of someone suddenly getting lucky on < 1 and stealing all your pot ?
Nevertheless, congrats on making a decent API for it.
I just saw your post, sorry for the delay.
This was a design choice. I wanted it to be loginless and stateless. The alternative would be to have a (static) session ID which would pretty much have the same effect: if someone has access to your machine they can access your Coinroll balance. Which I don't think is a problem anyway. If your system is compromised you have bigger problems than your balance on a gambling website.
The cookie has the 'httpOnly' and 'secure' flags set, so it can't be read by javascript and it is only transmitted via HTTPS.
People don't leave Bitcoins on the website. They also make (and they should) new accounts for every session.
As for your second question, the pot is big enough to make that event highly unlikely. The betting limits are adjusted based on that.
Needs less addiction.
38fcb87f7035
I lost
, though hopefully better luck on the prizes here.
I lost
, though hopefully better luck on the prizes here.
Really great site design, that renders well on mobile as well.
c1ccb033e57a
Especially like the small house edge, and the micro bet capabilities
c1ccb033e57a
Especially like the small house edge, and the micro bet capabilities
4aaec33df448
Sadly for my wallet it's very addictive.
Sadly for my wallet it's very addictive.
Jump to: