Hacker Newsnew | comments | show | ask | jobs | submit | login

Could be an easy Putnam problem.

-----


It was indeed a Putnam problem. Good guess ;)

-----


I think you are underestimating the complexity of coming up with an analogy that works. For instance, solving the same problem for 'How many numbers are needed to exceed 2' is already much harder and I don't think there exists a similar 'easy' proof.

-----


Bookmarked this HN page for later so I can make the obvious joke about this article.

-----


I'd like to live for a time, sure, but even five hundred years might be too long. I'd either get driven insane by the constant bow-shocks of ever advancing culture, or I'd lapse into some kind of boredom-induced stupor.

It's not wrong either for the rest of us to be curious.

-----


I'm both curious about living for 1000+ years, since no human has ever lived so long before, and about what happens after death. Given the chance for a 1000-year lifespan, I'd readily take it knowing that I will die, Singularity or no, given the very long but finite lifespan of the universe, and taking the long lifespan would allow me to experience both.

Although a "healthy fear" is certainly in order, I don't understand the reflexive hatred of death. I think it's more likely that consciousness is nonphysical and that there is some form of spiritual survival. Ian Stevenson's reincarnation research is pretty solid. (If I'm wrong, I'll never know.)

-----


..............

........................

I thought David was kidding. Jesus.

-----


Not at all. That's the Emacs crash course: How do you move by charcters/words/lines/sentences/paragraphs/function definitions/..., how do you open/save files, what does 'C-x M-c butterfly' mean, how do you browse the main help system, etc. It probably takes about half an hour to go through.

Emacs is largely self-documenting, but since it was written decades (and several OSs) ago, it's IMHO worth reading through the basics. For one thing, it tends to use different terminology than most people are familiar with.

-----


Centralization. (OpenID)

-----


See some of his other posts on OpenID.

-----


Indeed. The title should have appended: "...dramatically."

-----


What if your business partner dies? I thought everyone needs to confirm you are dead? What if they are dead?

-----


Sing this out loud in a low voice...awesome.

-----


And the Gmail engineers should add an opt-out "high security" mode that checks the referer to make sure the form submission is coming from Gmail itself and not some outside website. This way people who like to use custom/blank referers can ignore this security concern if they want, and all the rest of us can prevent the risk of this problem.

EDIT: Or how about just adding an in-line Javascript variable? Say, on all Gmail pages, you could embed this in the page:

   <script>var SECURITY_KEY = "918028cd79a5ba47e83e6ba68d036ca3";</script>
And then when sending AJAX or form requests in the background, make sure to include that as a request parameter. That way, even if the user has the right authentication cookies, external websites won't be able to fool Gmail into thinking they are Gmail.

Really, this doesn't seem like a very hard problem to solve...couple lines of code...

-----


Is this solution scalable though? Are you saying that they should store this key on the server side for each instance of gmail and then check every single AJAX request to see if the key is present?

-----


Not only it scalable as it is the only solution.

See "Good Patterns & procedures to prevent CSRF": http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site...

-----


That doesn't sound unscalable. It's pretty linear scaling, they already store information per logged in user anyway.

-----


They store information per logged in user but are they performing some type of lookup information for every single AJAX request? I opened up a chat box and 7 HTTP requests fired off. I have no clue what these are for, but are each one of those validated and could they be quickly? During typical gmail usage several requests are fired off in the background for simple and seemingly trivial user actions like the one mentioned above.

EDIT: ...and after I was done typing the message above I returned to gmail and 15+ more requests has been fired off without me doing anything. The message took well under a minute to type. Seems like a lot of validation would have to be done.

-----


The same key can be used for each session...when the Gmail page is being generated, I am saying this embedded in-line key can be associated TO the user's cookie, so that there is a one-to-one correspondence between this "Javascript cookie/session variable" and the user's actual cookie. There is no problem whatsoever. The only thing to be done is the exact same authentication that Google has to do to determine from which authenticated user chat requests are coming from (or any other AJAX request sent to Gmail).

EDIT: To answer your question of "are they doing some kind of lookup for each AJAX request?" Well of course, since they already have to look up a user's ID, account information, etc. based on the cookie they send.

-----


Agreed they have to authenticate but I don't think they perform a lookup on every single request. They probably use a key but it is more likely this key (let's call it the AJAX key) is generated from the user's dat (id, ip, whatever else) using some hashing function on the back-end. When the server receives a request it can check to see if a request is valid by re-generating the AJAX key from the requests meta data (header or whatever other data sent with the request for authentication purposes). This is much quicker and more scalable than a lookup for every request and its just as secure. Even if someone guesses your key generation method (which should be HIGHLY unlikely) you can simply change it and it will work for all users immediately, even ones who are logged in already.

Now maybe they are performing a lookup for each request but I just do not see how they can handle the load, or why they would want to given the alternative I just suggested. Google sends a ridiculous amount of data back to their servers during a Gmail session. I haven't examined the traffic extensively but open up a chat box in gmail and the Firebug console at the same time. Click anywhere in the chat box. See the request that fires off int he console? That happens EACH TIME you click ANYWHERE in the box. I guess they are doing some type of clicking heat map or something I don't know, but whatever they are doing it requires sending potentially 1+ AJAX requests per second for many users.

I am not knowledgeable enough to tell you how much is too much for a server/file system/database to handle quickly (~150 ms per request for millions of requests at once) so maybe the situation I just described is not as bad as I made it seem.

-----


Server-side is probably the right place to fix it, but I tend to be impatient when it comes to security.

-----


Reading that article made me expect a future in which a musician will not be known for a particular composition, but for the algorithm he devised for creating music of a particular flavor.

This only goes to show that eventually, all fields of knowledge will be nothing except mathematics!

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: