sonnym's comments

I have been reading through this book, as each chapter is separate to all the others. It is, overall, a quality work, but some chapters definitely stand above others. On the downside, there is little cohesion between the chapters and, while some themes run throughout the course of the book, do not expect some clear takeaway at the end.

Always remember this useful rule of thumb: "Any headline which ends in a question mark can be answered by the word no."

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

This is interestingly reminiscent of swearjure[1], clojure without alphanumerics. The IRC log in that post is very enlightening to see how the idea evolved into something absolutely frightening. I would like to see the history of JSFuck.

1. http://hypirion.com/musings/swearjure

You are correct on both counts regarding the vim and grep example - I guess I just assumed I would have to have all the files on a single line before handing them off to vim.

Thanks for the suggestion about -exec +; I will have to remember it in the future.

I use xargs a lot for refactoring work when I cannot simply use sed, e.g.

vim $(grep -lr foo | xargs)

and doing what I need to do on a file by file basis. Otherwise, for renaming functions and the like, I do a lot of:

find . -name foo_fn exec sed -i s/foo_fn/bar_fn/g '{}' \;

I generally love abusing bash. Just today I was asked about how to rename a bunch of files, specifically containing spaces, and came up with either of these two options:

find -name foo_bar -exec cp "'{}'"{,.bak} \;

and

for file in $(find -name foo_bar); do cp "$file"{,.bak}; done

Ultimately, the great thing is, if you learn CTRL-R, you can always search for these types of commands and modify them as necessary for the particular task at hand and not necessarily remember them. One I use all the time, to push git branches upstream is the following:

CTRL-R --set-

which gives me:

git push -f --set-upstream origin `git rev-parse --abbrev-ref HEAD`

This is entirely unique in my history, a common part of my workflow, and trivially searchable.

I also enjoy being able to perform something along the lines of:

vim $(bundle show foo-gem)

This is a clear example of a sampling bias. The voices of those angry with an experience of poor service will raise a cacophony compared to those who have a pleasant experience and simply carry on with their lives.

On the correlation between bearded language designers and language popularity: http://www.alenz.org/mirror/khason/why-microsoft-can-blow-of...

If you are using an e-mail client, you will be connecting to the gmail server using STARTTLS, so your e-mails will not be transferred over the public internet in plain text.

If you use the web client, everything is over HTTPS, and, like the gp stated, probably goes nowhere beyond the database, although merely a supposition.

I almost hate to be that guy, but

mount /mnt/book && cd /mnt/book && wget ...

work just fine for me with the Sony PRS-300. I imagine things might be a bit different with a more closed system, but this has been doing the trick for a few years.

Barry Cooper, a former narcotics officer, explains in pretty great detail how they train with alert dogs:

http://youtu.be/F9pGylTSDj0

A lot of the video isn't particularly relevant, but he does discuss how the officers are trained to incite the dog to alert and how the desire for the ball is a prey drive.

This is the video from the technical demonstration and explanation:

http://www.youtube.com/watch?v=R2Cq3CLI6H8

It should be noted that dustjs is not yet updated for node v0.6.x. I submitted a rather trivial pull request toward the end of October fixing the problem and another user has submitted one since then, but the author has not responded to either.

This makes me question how much the project will be supported in the future - but I suppose having a large company like LinkedIn invested in the technology is a good sign.

See: https://github.com/akdubya/dustjs/pull/36

I was merely pointing out how easy it is to fake, although you are correct a third party site could not do this.

Atwood's point is that checking the "referer" will both be unreliable and, more importantly, lead to false positives; there are better alternatives, namely, double submitting cookies as I have pointed out elsewhere with regard to this article.

You cannot assume a request is coming from a browser.

curl --referer http://www.example.come http://www.example.com

In double cookie submission, you are not issuing two requests to the server, but rather using javascript to append the session id to either the post body or the URI.

Since the browser automatically submits the cookie via HTTP Headers, single submission by itself is not safe. Since a third party cannot read the value of the cookie, they cannot recreate the proper request and will, consequently, fail.

Of course, both our methods will fail under an XSS, but should still prevent CSRF. I still think a cryptographically generated secret stored in the cookie is less guessable than a timestamp.

From http://www.codinghorror.com/blog/2008/09/cross-site-request-...

The HTTP referrer, or HTTP "referer" as it is now permanently misspelled, should always come from your own domain. You could reject any form posts from alien referrers. However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users. Furthermore, spoofing the referrer value is extremely easy. All in all, a waste of time. Don't even bother with referrer checks.

My bad, I thought the timestamp was being inserted into a form ala Rails' authenticity_token method in a way that would allow it to go stale if a new request was submitted in a new tab.

Although this makes sense, I feel it is not as safe as double submitting cookies, which effectively creates pseudo-random requests, but should still be safe enough in practice.