4 ms·

There's a reason: it generates unique input data for each user, presumably to prevent a given user's answers from being reused. If you have a Github account, it

by aaronem 11y ago

There's a reason: it generates unique input data for each user, presumably to prevent a given user's answers from being reused. If you have a Github account, it's trivial to authenticate and doesn't request undue privileges with your account. (That's what I used.) Up to you whether that's too high a bar, but IMO it's really not asking a whole lot.

such_a_casual 11y ago
You're joking right? The site could just use cookies like every flash game ever made. The site could generate a registration for the user. The site could take manual registration from the user. This trend of linking accounts between sites is completely inappropriate from people who are well aware of the privacy and security issues the internet faces today.
- aaronem 11y ago
  You're seriously suggesting that every random site on the Internet should take email addresses and passwords, with all the increased attack surface that implies, instead of delegating to authentication providers who know what the hell they're doing and are not going to serve up everyone's credentials and private data to the first halfway serious attacker to happen along. And you're asking me if I'm joking?
  - cgriswald 11y ago
    The attack surface is only increased for those individuals who reuse passwords. Risk is actually reduced for those who use unique usernames and passwords. GP said nothing about requiring email addresses and provided several other alternatives that require nothing of the user at all. Additionally, the reason you gave as to why the site might require it provides no real value to the user. There is no incentive to link yet-another-website to an authentication provider, except to access the site; which seems completely unnecessary. Finally, I object to categorizing Google, Reddit, et al., as "authentication providers." While that may be a service they perform, they are actually, instead, just tracking you. If you'll forgive the clumsy metaphor of a caffeine-deprived mind, it would be a bit like calling police serving a search warrant "furniture reorganizers."
    - aaronem 11y ago
      Accepting user registrations generally entails obtaining a means of contact which can be used to unlock an account whose password has been forgotten. By far the most common contact method used is email. GP may not have mentioned it in so many words, but the implication is trivial. Requiring unique registration on a site also demonstrably results in significantly fewer people actually making use of the site. It's perceived as a burden, and people not unreasonably wonder why they have to providing sensitive information in order to find out whether there's anything there worth providing sensitive information. As ever, whether or not you think this should be true doesn't affect whether or not it is. Too, leaving aside the question of whether it's a security risk for the user, maintaining a password database is certainly a security risk for the developer. Having your password database stolen is a credibility disaster. Similar exposure of a collection of OAuth tokens, none of which provides any access whatsoever to privileged data and all of which can be trivially deauthorized by their owners or en masse by the application developer, is about as minor a concern as any security compromise possibly can be. From the developer's perspective, that's an extremely strong argument for three-legged OAuth. Addressing the other alternatives in detail: Using session cookies alone is great, except that they will eventually expire or be deleted, at which point all progress is lost. That's not a major problem, I suppose, but I can see people potentially being annoyed by it, especially shell cowboys who solve everything with one-liners. I'm not sure what "The site could generate a registration for the user" even means. And I think there's a fair argument to be made that authentication via OAuth with a third party hits a sweet spot between user convenience on the one hand, and persistence and distinguishability of identity on the other. Finally, I'm really not sure why "they're tracking you!" is such a concern in this case. Yes, third-party tracking is an increasingly ubiquitous reality of life on the modern web, and yes, in many ways that is a very bad thing. On the other hand, there is such a thing as nuance, and I think it's a pretty long stretch to argue that it is likely to result in a major privacy violation to let on to Github, or for that matter Facebook or Twitter if I had accounts with them, that I'm a programmer. I suppose it's possible there are people who need to keep that a secret for some reason, although I can't imagine what reason that might be. For them, it's probably not worth it to use Advent of Code, even with a throwaway account. For me and apparently quite a lot of other people, it is. I'm having a very hard time seeing the prima facie unreasonability of that perspective that it seems like some folks do.
  - such_a_casual 11y ago
    You're basing your argument on an assumption instead of what I wrote.
    - aaronem 11y ago
      What assumption is that?
  - sln 11y ago
    I think the suggestion was that this site doesn't really need to identify its users. It's a quiz site. If you want to make custom inputs for each user, drop a cookie with a big random number and stop fretting about the cases where that fails.
ubernostrum 11y ago
There are plenty of ways to generate a one-off random seed for values used in the quizzes. And many of them don't require me to authenticate to the site; as others suggested, a cookie could be used, or even just a querystring value in the URL. And promiscuously asking to connect social accounts to random things on the internet, even if they swear up and down that they don't request "undue" privileges, trains people to just always do it, which sets them up to get owned later on by someone who will take advantage of that.

by aaronem 11y ago

such_a_casual 11y ago

You're joking right? The site could just use cookies like every flash game ever made. The site could generate a registration for the user. The site could take manual registration from the user. This trend of linking accounts between sites is completely inappropriate from people who are well aware of the privacy and security issues the internet faces today.

aaronem 11y ago
You're seriously suggesting that every random site on the Internet should take email addresses and passwords, with all the increased attack surface that implies, instead of delegating to authentication providers who know what the hell they're doing and are not going to serve up everyone's credentials and private data to the first halfway serious attacker to happen along. And you're asking me if I'm joking?
- cgriswald 11y ago
  The attack surface is only increased for those individuals who reuse passwords. Risk is actually reduced for those who use unique usernames and passwords. GP said nothing about requiring email addresses and provided several other alternatives that require nothing of the user at all. Additionally, the reason you gave as to why the site might require it provides no real value to the user. There is no incentive to link yet-another-website to an authentication provider, except to access the site; which seems completely unnecessary. Finally, I object to categorizing Google, Reddit, et al., as "authentication providers." While that may be a service they perform, they are actually, instead, just tracking you. If you'll forgive the clumsy metaphor of a caffeine-deprived mind, it would be a bit like calling police serving a search warrant "furniture reorganizers."
  - aaronem 11y ago
    Accepting user registrations generally entails obtaining a means of contact which can be used to unlock an account whose password has been forgotten. By far the most common contact method used is email. GP may not have mentioned it in so many words, but the implication is trivial. Requiring unique registration on a site also demonstrably results in significantly fewer people actually making use of the site. It's perceived as a burden, and people not unreasonably wonder why they have to providing sensitive information in order to find out whether there's anything there worth providing sensitive information. As ever, whether or not you think this should be true doesn't affect whether or not it is. Too, leaving aside the question of whether it's a security risk for the user, maintaining a password database is certainly a security risk for the developer. Having your password database stolen is a credibility disaster. Similar exposure of a collection of OAuth tokens, none of which provides any access whatsoever to privileged data and all of which can be trivially deauthorized by their owners or en masse by the application developer, is about as minor a concern as any security compromise possibly can be. From the developer's perspective, that's an extremely strong argument for three-legged OAuth. Addressing the other alternatives in detail: Using session cookies alone is great, except that they will eventually expire or be deleted, at which point all progress is lost. That's not a major problem, I suppose, but I can see people potentially being annoyed by it, especially shell cowboys who solve everything with one-liners. I'm not sure what "The site could generate a registration for the user" even means. And I think there's a fair argument to be made that authentication via OAuth with a third party hits a sweet spot between user convenience on the one hand, and persistence and distinguishability of identity on the other. Finally, I'm really not sure why "they're tracking you!" is such a concern in this case. Yes, third-party tracking is an increasingly ubiquitous reality of life on the modern web, and yes, in many ways that is a very bad thing. On the other hand, there is such a thing as nuance, and I think it's a pretty long stretch to argue that it is likely to result in a major privacy violation to let on to Github, or for that matter Facebook or Twitter if I had accounts with them, that I'm a programmer. I suppose it's possible there are people who need to keep that a secret for some reason, although I can't imagine what reason that might be. For them, it's probably not worth it to use Advent of Code, even with a throwaway account. For me and apparently quite a lot of other people, it is. I'm having a very hard time seeing the prima facie unreasonability of that perspective that it seems like some folks do.
- such_a_casual 11y ago
  You're basing your argument on an assumption instead of what I wrote.
  - aaronem 11y ago
    What assumption is that?
- sln 11y ago
  I think the suggestion was that this site doesn't really need to identify its users. It's a quiz site. If you want to make custom inputs for each user, drop a cookie with a big random number and stop fretting about the cases where that fails.

ubernostrum 11y ago

There are plenty of ways to generate a one-off random seed for values used in the quizzes. And many of them don't require me to authenticate to the site; as others suggested, a cookie could be used, or even just a querystring value in the URL. And promiscuously asking to connect social accounts to random things on the internet, even if they swear up and down that they don't request "undue" privileges, trains people to just always do it, which sets them up to get owned later on by someone who will take advantage of that.