Есть ли причина не доверять ASP.NET AntiForgeryToken?

Я знаю, что сайты Stack Exchange не используют встроенный в ASP.NET MVC @Html.AntiForgeryToken()для предотвращения атак XSRF/CSRF. . Вместо создания скрытого ввода с именем __RequestVerificationTokenс действительно длиннымзначением на основе раздела machineKey файла web.config, метод Stack Exchange создает ввод с именем fkey. ] с НАМНОГОболее кратким значением.По-видимому, это руководство, и на основании данных из проекта Stack Exchange Data Explorer в Google Codeэто значение привязано к каждому отдельному пользователю и остается практически постоянным до тех пор, пока вы не войдете в систему или не выйдете из нее.

Кроме того, значение Stack Exchange является постоянным на странице и доступно для клиентского сценария, так что Ajax публикует сообщения для голосования и подобные вещи также используют токен. Напротив,

Так почему же Stack Exchange идет к своему собственному барабанщику?

• Есть ли причина не доверять AntiForgeryToken?
• Есть ли у AntiForgeryToken какие-то ограничения, которые команда Stack Exchange не хотела принимать? Если да, то какие?
• Или, может быть, AntiForgeryToken просто не существовало (он зародился в проекте MVC Futures), когда было запущено Stack Overflow, и если бы им пришлось делать это с нуля сегодня, они бы использовали AntiForgeryToken?

Мне не удалось найти какие-либо сообщения в блогах от Джеффа или других членов команды Stack Exchange, в которых объяснялись бы руководящие принципы политики предотвращения XSRF в сети SE. Было бы очень хорошо, если бы кто-то из них мог написать статью, при условии, конечно, что это можно сделать в общих чертах, не создавая уязвимости. Это будет действительно ценная информация для тех из нас, кто хочет сделать наши веб-сайты безопасными, но не совсем комфортно просто слепо доверять Microsoft, чтобы сделать это за нас.