If there were a community consensus that threadreaderapp.com links are better than the equivalent twitter.com links, we could maybe override that, but there's no such consensus.
> Our CSRF protection mechanism for POST requests checks that the origin and referer headers of the request are sourced from Twitter. Since we knew this to be effective for POSTs, we considered how we could implement this for GET requests.
> This proved effective in addressing the vulnerability, but it prevented this initial load of the website. You might load Twitter from a Google search result or by typing the url into the browser. To address this case, we created a blank page on twitter.com which did nothing but reload itself. Upon reload, the referer would be set to twitter.com, and so it would load correctly.
https://blog.twitter.com/engineering/en_us/topics/insights/2...