derekprior's comments

For folks with bank accounts outside of that list, GitHub Sponsors is still in beta, we're accepting applications, and we’ll continue to roll out general availability to those countries in the coming months.

Would be nice to set a body though, wouldn't it? Also, not allowed by HTML.

1. You include a script such a TypeKit. The typekit deliverable itself is not owned, but bad actors have access to typekit.com logs.

2. You use a smaller third party add on service that itself uses a logging service such as PaperTrail. PaperTrail is hacked, providing attackers access to logs.

3. You reference no external assets, but your site contains external links in the footer. Users click the navigation links rather than completing the form. You have leaked the token to whatever site that is. You are at the mercy of their log storage. YES, this does actually happen. User's click crazy things.

As I mention in the article and in other comments here: this is not likely to be exploited. Fixes, however, are not too difficult. Even adding the not-quiet-fully-supported `meta` tag to your head is a good start.

If I read this article today, I'd think, "That's interesting. let me make a note to check that out." It's not a hair-on-fire security situation, but it's not "not a problem at all" either.

They are good for 1 password reset, not 1 page load. It's possible to make them good for 1 page load, but most I've encountered are not due to the tradeoffs that would involve (see other discussions).

I might not be using the right term here, but the general idea is that you create an encrypted token out of some data and verify that the data is unchanged and still valid on the server. In that way you can provide a token that ensures the user had access to the link you sent them, but you don't have to store it in the database.

It's worth noting there are a number of reasons this JavaScript could possibly not execute beyond people who have JS turned off. I've seen a number of sites fail to execute JavaScript when an Ad Blocker is run, for instance.

In this case, there are a number of server side fixes available that wouldn't require any JavaScript. They're not terribly complicated and will always work. For that reason, I'm still comfortable with the server side fix, but think the JS fix is a decent alternative.

I feel like I've seen more of the former than the latter.

Tradeoffs...

I did consider this approach for Clearance and intended to go with it, but was discouraged from doing so after hearing reports that some enterprise email AV does things like open some links in emails.

There is also the user experience concern that a click the link in my email, do something else, then click the link again, having forgotten I already clicked the link. Now I'd have to re-request again.

Also, this approach is impossible if you use HMAC tokens.

I don't think anyone who opts for this approach is wrong but like most things, it's a tradeoff.

"Since most Mac users use Google Chrome as their primary browsers (sic)..." -- Oh really? I'd be surprised by this. Do you have numbers to back it up? I'm guessing most Mac users just use the default browser.

"Safari for Mac is just like IE for Windows, it is only used to access the web for the first time to download Google Chrome." -- I don't even... no.

"While it is a bit better than IE it still sucks and needs to be replaced ASAP." -- News to me. I use Safari every day. I've considered chrome and do tend to use it for development, but Safari is my default. It certainly doesn't suck and doesn't need to be replaced at all.

class PostsController attr_accessible: :title, :body, :related_links => { :href, :title } end

This would accept the attributes: post_title, post_body, post_related_links_0_href, post_related_links_0_title, posts_related_ink_1...

The names might not be right. I forget exactly how rails names fields. But you get the point, yes?

Additionally, you hinted at the other main reason I use GMail in your first bullet point: "Control over your own data means you own it, you have it on your hard disk, it is not on somebody else's storage medium."

Sure, this means Google has access. But it also means I don't have to find a way to make that data accessible to me everywhere I want it to be. I don't have to pay for the storage. It's a solved problem... and available at a great price point ($FREE).

I trust google slightly further than I can throw them, so for now this is an okay deal.

1) Me feeling stupid because I don't remember what Pascals Triangle is.

2) Me stumbling through some code while I try to understand the explanation you give me.

I've got a family. I need stability... and health insurance. Unless it's my only offer, a substantially better offer, or a dream job, I'm inclined to go elsewhere.