Advent of Code – solve a puzzle every day(adventofcode.com)
adventofcode.com
Advent of Code – solve a puzzle every day
http://adventofcode.com/
11 comments
Love this. I did the first couple of days within irb (Ruby REPL) before deciding to actually write scripts, seeing the second exercise for a given day builds on the first. Found it interesting there's a "Leader board" since well, there's no "points" to accumulate other than completing two puzzles per day, so whomever is listed there is just those 100 who came to see the puzzles first. So far they're not very hard, but still fun.
26 points, but no discussion here... I guess many were lured into the challenges, trying to solve the currently available puzzles instead of commenting. #nerd-sniping
It appears to require me to authenticate to it with a social network just to even try out the first puzzle. So that's a "close tab and move on" from me.
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.
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.
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?
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."
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."
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.
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.
You seem to be going back and forth between the general case and this specific case. When I'm talking about the specific case, you start arguing in generalities, and when I'm talking about the general case, you switch to talking about the specifics.
> 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.
In this specific case, using your guessed-at reason for the need for registration, the implication that an email address is required isn't trivial. It simply isn't necessary at all. If it had been required, I also would have forgone registering. They have no need to contact me that I consider valid.
> 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.
Yet linking it to their social media or other accounts is not perceived as a burden? It is demonstrably percieved as a burden as evidence by both the other poster and myself. You also seem to be suggesting that linking a social media or other account is providing less sensitive information than creating a unique login. That may be the case at times, but I suspect, and I'd be surprised if you disagree, that usually you are providing more information by linking an external account versus a unique login.
> 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.
I think there is too, in general, but not in this specific case if the only need is to have a unique identifier.
> Finally, I'm really not sure why "they're tracking you!" is such a concern in this case.
I'm not sure why you've gone from speaking very generally about the issue to getting very specific about the site in this case. I objected, very clearly, to identifying them as "authentication providers" in general. I never said anything about whether it was a huge privacy violation that they know you visited this particular site.
> 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.
In this specific case, using your guessed-at reason for the need for registration, the implication that an email address is required isn't trivial. It simply isn't necessary at all. If it had been required, I also would have forgone registering. They have no need to contact me that I consider valid.
> 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.
Yet linking it to their social media or other accounts is not perceived as a burden? It is demonstrably percieved as a burden as evidence by both the other poster and myself. You also seem to be suggesting that linking a social media or other account is providing less sensitive information than creating a unique login. That may be the case at times, but I suspect, and I'd be surprised if you disagree, that usually you are providing more information by linking an external account versus a unique login.
> 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.
I think there is too, in general, but not in this specific case if the only need is to have a unique identifier.
> Finally, I'm really not sure why "they're tracking you!" is such a concern in this case.
I'm not sure why you've gone from speaking very generally about the issue to getting very specific about the site in this case. I objected, very clearly, to identifying them as "authentication providers" in general. I never said anything about whether it was a huge privacy violation that they know you visited this particular site.
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.
You're basing your argument on an assumption instead of what I wrote.
What assumption is that?
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.
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.
discussion are here it seems
https://www.reddit.com/r/adventofcode/
most interesting so far is "I'm doing the advent with 25 different languages, who wants to join?!" https://www.reddit.com/r/adventofcode/comments/3vhzob/im_doi...
No one is code golfing it yet
most interesting so far is "I'm doing the advent with 25 different languages, who wants to join?!" https://www.reddit.com/r/adventofcode/comments/3vhzob/im_doi...
No one is code golfing it yet
Uh oh, he already used up a bunch of 'common' languages. He's going to be stuck doing the later, harder problems in asm and brainfuck. I'd have problems even naming 25 languages.
There is some degree of golfing going on in the Day X threads.
I'd say it is interesting, so the votes indicate "hey, more people should see this", but it is pretty straightforward what it is and means, so not much to discuss?
nah, I would expect people to complain about puzzles being too easy, too hard, ugly graphics, nice retro style etc.
I am with grandparent in guessing people are mostly playing :)
I am with grandparent in guessing people are mostly playing :)
It's not acceptable to force the use of a twitter/github/google/reddit login.
OK, but of course no-one is forcing anyone to anything. You are completely free to not partake in the silly programming exercises, as there are plenty of alternatives out there for your enjoyment. You could even buy a book, in cash, disconnect your computer from the Internet and satisfy your programming desires in absolute privacy and anonymity. I, for one, have no problem with the site's requirements, and find it quite enjoyable. Happy Holidays.
Given that everyone gets a different 'input' string for every problem to prevent the simplest form of cheating and to enable such a thing as a leaderboard, I think this is a very reasonable measure, better than having yet another e-mail login for a service that is by definition seasonal.
Also, when you connect it to GitHub, it does only ask for a very limited amount of data. What solution would you have proposed?
A reply I made to another user in this thread:
"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."
While I agree that having one account to rule them all is generally a pretty bad idea if you're talking about projects that deal with sensitive data, I still think it's not that big a deal here. A cookie would tie you to one device, and I really think it is preferable to have this site (which is not dealing with any sensitive information about me whatsoever) not handle an e-mail/password combination, but let GitHub etc handle security. From a UX standpoint, I think this is a good solution that doesn't add too much complexity. If the app dealt with more private data, I would be screaming for a manual login myself.
i agree with your original post, but i'm assuming the login with other services bit was to reduce effort expelled in making the project
having reddit on the list of options means the barrier to entry can be counted in keypresses
you can make as many reddit accounts as you want, much like hn, where the only requirements are username and password
make one and just treat it like an advent login
having reddit on the list of options means the barrier to entry can be counted in keypresses
you can make as many reddit accounts as you want, much like hn, where the only requirements are username and password
make one and just treat it like an advent login
That's a fair point. I'll take your advice and use a reddit account. Thank you.
What are the privacy implications of having your github account provide an oath token to some rando site that you input a few numbers and strings into?
I guess they could collect wrong attempts and use them to try to shame people?
I guess they could collect wrong attempts and use them to try to shame people?
There is no implication whatsoever. It's explicit. This website has no need for your irl identity (or even just your identity as a programmer).
Okay, what are the dire problems that arise from sharing an identity with some rando site that you also put some numbers into?
Utterly nonexistent, which is why I'm surprised to see people making such a big damn deal over it. The privacy implications of having an identifiable account on any of the services used for AoC login are enormous by comparison, but I guess there's always some folks who'll "strain out gnats, yet swallow camels".
It's totally acceptable to a lot of people. In fact I wouldn't be surprised if adding email registration reduced the conversion rate.
This adventofcode is a gem, you are really missing out if you let the registration system deter you.
This adventofcode is a gem, you are really missing out if you let the registration system deter you.
Email registration is the same thing. There's no reason that anyone should be forced to connect an account from another site to this one. However, at least with email addresses, it's trivial to use a temporary one.
It's also trivial to get a throwaway reddit account.
Force is the wrong word, the site has ~0 leverage over visitors.
Nice site! I've completed till Day 5 and enjoyed the puzzles. I solved them mainly in JS on browser console, although for the Day 4 challenge I had to run it on node js so my browser won't hang; and also Day 2 challenge in C++ to take advantage of the scanf function in parsing the input.
The problems are fresh & fun. I loved the day 4, almost felt like mining bitcoins :)
Looking forward for the next puzzles !
Looking forward for the next puzzles !
"The first character in the instructions has position 1, the second character has position 2"
This project seems awesome but playful -1 for non-zero-based-indexing :)
[Edit:]
another note (obviously I'm hooked).. This instruction isn't 100% parseable. It's not clear whether the desire is for three unique vowels need to appear or if three positions in the string need to be vowels. For instance, would 'aaa' qualify?
"It contains at least three vowels (aeiou only), like aei, xazegov, or aeiouaeiouaeiou"
[Edit Again: Nevermind... the test example 'aaa' clears it up]
This project seems awesome but playful -1 for non-zero-based-indexing :)
[Edit:]
another note (obviously I'm hooked).. This instruction isn't 100% parseable. It's not clear whether the desire is for three unique vowels need to appear or if three positions in the string need to be vowels. For instance, would 'aaa' qualify?
"It contains at least three vowels (aeiou only), like aei, xazegov, or aeiouaeiouaeiou"
[Edit Again: Nevermind... the test example 'aaa' clears it up]
It played pretty nicely with using map followed by a scanLeft (which prepends its starting element) on the input. Happy accident...
Which problem is solved by this (in Python)? ;-)
try:input()
except Exception as e: print e.offsetThose are some happy little puzzles. Delightful!
I suppose the problems get harder the closer we are to christmas?
I suppose the problems get harder the closer we are to christmas?
I solved most of the 6 first days in Bash. I used Lua for days 4 and 6 for performance reasons (I have working solutions in Bash too, but they are way too slow).
Lovely puzzles. Solved day 5 without resorting to regexes (which was kinda fun). Only gripe I have is that I can't use requests to get at the data.
I'm having the same problem. Getting the session token from a request made via browser, and using that token in my programmatic requests, does work, but that feels like cheating. What I really want to do is authenticate to Advent of Code programmatically via Github, but I haven't found a way to get my code to authenticate to Github itself; I keep getting redirects to github.com/login.
> Only gripe I have is that I can't use requests to get at the data.
The input.txt files, or the code to be used as input/starting point? I just download the file (or save the code) instead of re-downloading it over and over. (Is also handy if you're coding in the train or another place without internet connection.)
The input.txt files, or the code to be used as input/starting point? I just download the file (or save the code) instead of re-downloading it over and over. (Is also handy if you're coding in the train or another place without internet connection.)
Anybody have a Python 3 approach to problem 4 that doesn't end up with the delightful:
secret+str(n).encode()
Nice ! Would be a good idea to throw in a some bitcoins as a treasure at some stage ...Or maybe there already is ?
I don't think it would be a good idea. The author already went through the work to make the website, to require him to pay you for having fun would be a bit too much.
http://adventofcode.com/about says
"If you'd like to support Advent of Code, you can do so indirectly by helping to Share it with others, or directly via Paypal or bitcoin. "
so I guess you are welcome to throw in some bitcoins...
so I guess you are welcome to throw in some bitcoins...