Yep, we should probably account for short-term cookies and maybe also session cookies (#1539 (comment)).

Removing domains from the yellowlist is dicey as long as pre-2017.7.24 releases are still around (#1474 (comment)).

Since we've mistakenly tied privacy badger versions to cookieblock list behavior, now would be a good time to fix any problems with it. We can make new versions pull from a new URL. And we won't have to worry about breaking old versions.

Ignoring session cookies seems like the right thing to do given that session cookies are meant to expire at the end of the browsing session (although apparently browsers preserve session cookies when you set your browser to continue where you left off), which seems to make session cookies much less effective for tracking versus cookies with (far-future) expiration dates.

I think it's worth visiting a bunch of sites (from error reports?) and logging what Badger learned to block because of session cookies alone. If it's all non-tracking domains, let's do it.

What's the status on this issue? It looks like we've manually fixed a lot of session cookie-related issues.

It's in the should-probably-happen-but-comes-with-hard-to-understand-implications-and-so-we've-been-collecting-evidence-and-making-one-off-fixes phase. It seems pretty important to look into further, hence it's one of our numerous high priority issues.

Now that the big badger-sett scanner is up and running, we can try to get a sense of what most trackers use for expiration times etc. Note to self to do a scan that saves cookie lifetimes.