Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Unknown or expired link." - Why?

google.com

Post reply on HN
Print view View original

91–100 of 142 posts

Re: "Unknown or expired link." - Why?

#91

Post by icey »

tptacek wrote: post #77
pg wrote: post #64

Earlier quoted context omitted.

The problem there is that we switched to a new deliberately slow hashing function for passwords. Edit: I investigated further, and actually you're right, the problem was due to caching. It should be better now because we're not caching for as long. But I will work on making login links not use closures.

What'd you go with, and how much of a pain was it to get working in Arc? I ask because I'd love to be able to make a claim like "even Hacker News, which is written in a Lisp, managed to implement a modern password hash".

Gauche Scheme has a bcrypt implementation, but I don't know what the compatibility story is between mzscheme and Gauche. I think they're both R5RS compliant, so it should work.

I see that newer versions of Arc run on Racket, but I have no idea if that's what HN is using or not.

I haven't seen a scheme powered PBKDF2 implementation so I'd guess that's out.

The only other expensive KDF I can think of is scrypt, but I would be pretty surprised if that's got a scheme implementation.

Of course, I guess pg could have decided to call out to the OS to run any of those functions too.

Re: "Unknown or expired link." - Why?

#92

Post by roc »

xnxn wrote: post #49
Silhouette wrote: post #18

I've been wondering about this for a long time, but just as a data point if anyone cares, it has reached the point recently that HN is basically unusable for me a lot of the time, and I really am starting to give up on trying and spend more time elsewhere instead. Perhaps one visitor is no great loss -- I'm hardly the personality around here that someone like patio11 is -- but I hope my contribution is constructive,…

Funny, I suspect it's just the opposite. Long-standing regular contributors are unlikely to be put off by the error messages, especially if they're technically knowledgeable and understand why the error is occurring. On the other hand, new users who might not be accustomed to The Way We Do Things Around Here would be more likely to get upset at the superficial inconveniences and leave. It's probably even the case tha…

While there are plenty of cautionary tales of fora that failed their original purpose due popularity, growth and loss of focus, there are equally many cautionary tales of fora that failed due insular communities, group-think and stagnation.

It's a fine line to walk and it may not be wise to rely on programming bugs to point the way.

Re: "Unknown or expired link." - Why?

#93

Post by mfjordvald »

pg wrote: post #82
tomcreighton wrote: post #79

I find it interesting that most discussions I've seen about this exact topic are about Arc and closures... instead of about the fact that this may well be an interesting programming thing to do but it's a moronic user experience thing to do.

Your comment is in a sense its own refutation, because the ultimate test of user experience is whether users continue to use the software. Getting user experience right depends on the users. I wouldn't use this technique in an online store. Random online shoppers would be confused by expired links, and you'd lose sales. But HN users aren't confused by them. What HN users care about is the quality of the stuff on the…

I think you underestimate how annoying the issue is. It's one of those things you put up with because of the content, but which are annoying enough that they detract from the site experience.

So far I'd rate the user experience of the site around 3/5 and the content 5/5. You don't need to work any more on the content unless it starts dropping!

Re: "Unknown or expired link." - Why?

#94

Post by mhartl »

xnxn wrote: post #49
Silhouette wrote: post #18

I've been wondering about this for a long time, but just as a data point if anyone cares, it has reached the point recently that HN is basically unusable for me a lot of the time, and I really am starting to give up on trying and spend more time elsewhere instead. Perhaps one visitor is no great loss -- I'm hardly the personality around here that someone like patio11 is -- but I hope my contribution is constructive,…

Funny, I suspect it's just the opposite. Long-standing regular contributors are unlikely to be put off by the error messages, especially if they're technically knowledgeable and understand why the error is occurring. On the other hand, new users who might not be accustomed to The Way We Do Things Around Here would be more likely to get upset at the superficial inconveniences and leave. It's probably even the case tha…

I'm a long-time user (created: 1668 days ago), and I hate this error. I understand why it's occurring, but it seems bizarre that such an obvious flaw has gone unfixed for so long. It feels amateurish. (That said, pg has bigger fish to fry, and he's probably right to ignore this. C'est dommage.)

Re: "Unknown or expired link." - Why?

#95

Post by wnight »

gnaritas wrote: post #63
debaserab2 wrote: post #42

Earlier quoted context omitted.

It's not productive to have a site that randomly locks out visitors. No matter how clever the code design is, this is a product flaw.

No, it's a design choice, he favors ease of programming more than user experience. You might not agree with that choice, but it's not a flaw, he did it on purpose and knew the consequences.

It's not a feature so it's a flaw.

You're right that pg did it this way in the beginning to save time but years have gone by and the site is now more central to his business - especially as a tech demo. This back and forth argument presupposes that there isn't a better fix than the naive 'use old-style code' solution.

Anyways, the discussion is worth having. Only by pointing out problems do you fix them.

Re: "Unknown or expired link." - Why?

#96

Post by wnight »

Dylan16807 wrote: post #40
dspillett wrote: post #36

Earlier quoted context omitted.

But you are still likely to want to sign the state so you can tell if it has been corrupted (or deliberately doctored) and reject it if so.

Sign or sanity check, whichever you prefer. Personally in a simple interface like this site I'd rather sanity check the few simple parameters.

It's not a druthers kind of thing. If you need to trust that it hasn't been tampered with you must sign it.

And if you don't care you might as well not add authentication because without signing it's just a fancy CRC - ie, totally replicable by an attacker. As cookies and links are sent over TCP there should be vanishingly few errors in transmission - you're far more likely to introduce false positives with buggy code, and ...

You need to sanity check your inputs anyways. Just do it. This is also how you avoid bugs normally.

Re: "Unknown or expired link." - Why?

#97

Post by Dylan16807 »

wnight wrote: post #96
Dylan16807 wrote: post #40

Earlier quoted context omitted.

Sign or sanity check, whichever you prefer. Personally in a simple interface like this site I'd rather sanity check the few simple parameters.

It's not a druthers kind of thing. If you need to trust that it hasn't been tampered with you must sign it. And if you don't care you might as well not add authentication because without signing it's just a fancy CRC - ie, totally replicable by an attacker. As cookies and links are sent over TCP there should be vanishingly few errors in transmission - you're far more likely to introduce false positives with buggy cod…

I'm not sure what your argument is.

Yes if you want to trust it you have to sign it and make sure you implement all the crypto correctly. But I don't see a need for that here.

Also TCP's checksum sucks.

Re: "Unknown or expired link." - Why?

#98

Post by pg »

tptacek wrote: post #77
pg wrote: post #64

Earlier quoted context omitted.

The problem there is that we switched to a new deliberately slow hashing function for passwords. Edit: I investigated further, and actually you're right, the problem was due to caching. It should be better now because we're not caching for as long. But I will work on making login links not use closures.

What'd you go with, and how much of a pain was it to get working in Arc? I ask because I'd love to be able to make a claim like "even Hacker News, which is written in a Lisp, managed to implement a modern password hash".

We use bcrypt. Rtm did it. I never looked at the code till now; it's about a page of Scheme.

Re: "Unknown or expired link." - Why?

#99

Post by kens »

jgrahamc wrote: post #13

It's an artefact of the way in which news.arc (actually srv.arc) uses functions for links. Here's the key code: (= dead-msg* "\nUnknown or expired link.") (defop-raw x (str req) (w/stdout str (aif (fns* (sym (arg req "fnid"))) (it req) (pr dead-msg*)))) If the fnid (function ID) isn't in the fns* list then you get the dead message. (def flink (f) (string fnurl* "?fnid=" (fnid (fn (req) (prn) (f req))))) In many place…

My (unofficial) documentation of the Arc web server may help understand this: http://files.arcfn.com/doc/srv.html

In particular, harvest-fnids has as maximum number of allowed fnids. If there are too many, it purges any fnids that are older than their expiration time, and the oldest 10%.

Thus, the more fnids created (i.e. the more users), the sooner fnids will get harvested and you'll get the expired error.

Re: "Unknown or expired link." - Why?

#100

Post by wnight »

pg wrote: post #64
biot wrote: post #54

Earlier quoted context omitted.

Over the last week the home page appears to be cached longer than the arc timeout, no doubt due to the spike in traffic. As I throw away cookies when closing the browser, I need to login daily. It's been impossible to login from the HN home page because of this. Refreshing the page doesn't help; I've had to click through to a story to be able to login. You should hard-code that one too.

The problem there is that we switched to a new deliberately slow hashing function for passwords. Edit: I investigated further, and actually you're right, the problem was due to caching. It should be better now because we're not caching for as long. But I will work on making login links not use closures.

Is that specifically to inconvenience someone who would break in, steal your password list, and crack it offline?

If not, what was the design goal?

If slowing down web login attempts isn't part of it, why not get a dedicated auth server and offload the crypt stuff onto it?

And if it is the goal, you could use CPU-friendly sleeps on the front-end to give increasing delays to the repeated guesser.

Post reply on HN