<story><title>Is Your Site Leaking Password Reset Links?</title><url>https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links</url></story><parent_chain><item><author>grimmdude</author><text>Can I ask your reasoning in doing this?</text></item><item><author>dmm</author><text>&amp;gt;everyone has JS enabled.&lt;p&gt;Using an addon like NoScript it&amp;#x27;s possible to selectively enable javascript per domain. When a website doesn&amp;#x27;t work without js I am forced to decide whether it&amp;#x27;s worth enabling js for this site. Very often I decide it&amp;#x27;s not worth it and I never use that site again.</text></item><item><author>VertexRed</author><text>It&amp;#x27;s 2016, everyone has JS enabled.&lt;p&gt;The ones that don&amp;#x27;t are most likely bots (now even that&amp;#x27;s changing thanks to projects like phantomjs).</text></item><item><author>oneeyedpigeon</author><text>Obviously, the drawback is that you&amp;#x27;ve introduced a javascript dependency to a core function which definitely doesn&amp;#x27;t require it. Having said that, I notice that paperhive.org renders an entirely blank page if javascript is unavailable, so I guess the password reset is the least of your concerns in that scenario.</text></item><item><author>andrenarchy</author><text>If you use javascript to extract the token from the URL then you can simply pass it via the hash (&amp;quot;fragment&amp;quot;) part of the URL. The hash portion is only interpreted by the user agent and never sent to a server (see &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;rfc3986#section-3.5&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;rfc3986#section-3.5&lt;/a&gt;). This is how we solved it at paperhive.org.</text></item></parent_chain><comment><author>mikegerwitz</author><text>When your browser runs JavaScript, it downloading and automatically executing untrusted, unsigned, ephemeral code.  Even if the site is over SSL, only the _party_ is validated---the resources themselves are not signed.&lt;p&gt;If your browser instead presented the JavaScript as a program itself, and listed the programs it executed, and from what sources, users would have a wholly different perspective.  JavaScript has the illusion of remote execution; most users don&amp;#x27;t think of it as executing programs on their computer.&lt;p&gt;Addons like NoScript are essential security precautions that mitigate a host of attacks.  Unfortunately, even security-essential software like the Tor Browser Bundle leaves JS enabled by default because it&amp;#x27;d &amp;quot;break&amp;quot; the web.&lt;p&gt;There&amp;#x27;s other reasons---as a free software user and activist, I won&amp;#x27;t run non-free JavaScript programs.&lt;p&gt;I gave a talk earlier this year about these problems and some ideas to solve them: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;media.libreplanet.org&amp;#x2F;u&amp;#x2F;libreplanet&amp;#x2F;collection&amp;#x2F;restore-online-freedom&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;media.libreplanet.org&amp;#x2F;u&amp;#x2F;libreplanet&amp;#x2F;collection&amp;#x2F;resto...&lt;/a&gt;</text></comment>
<story><title>Is Your Site Leaking Password Reset Links?</title><url>https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links</url></story><parent_chain><item><author>grimmdude</author><text>Can I ask your reasoning in doing this?</text></item><item><author>dmm</author><text>&amp;gt;everyone has JS enabled.&lt;p&gt;Using an addon like NoScript it&amp;#x27;s possible to selectively enable javascript per domain. When a website doesn&amp;#x27;t work without js I am forced to decide whether it&amp;#x27;s worth enabling js for this site. Very often I decide it&amp;#x27;s not worth it and I never use that site again.</text></item><item><author>VertexRed</author><text>It&amp;#x27;s 2016, everyone has JS enabled.&lt;p&gt;The ones that don&amp;#x27;t are most likely bots (now even that&amp;#x27;s changing thanks to projects like phantomjs).</text></item><item><author>oneeyedpigeon</author><text>Obviously, the drawback is that you&amp;#x27;ve introduced a javascript dependency to a core function which definitely doesn&amp;#x27;t require it. Having said that, I notice that paperhive.org renders an entirely blank page if javascript is unavailable, so I guess the password reset is the least of your concerns in that scenario.</text></item><item><author>andrenarchy</author><text>If you use javascript to extract the token from the URL then you can simply pass it via the hash (&amp;quot;fragment&amp;quot;) part of the URL. The hash portion is only interpreted by the user agent and never sent to a server (see &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;rfc3986#section-3.5&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;tools.ietf.org&amp;#x2F;html&amp;#x2F;rfc3986#section-3.5&lt;/a&gt;). This is how we solved it at paperhive.org.</text></item></parent_chain><comment><author>theandrewbailey</author><text>I come to a website to read it, not for it (and who knows what else) to execute code on my machine, no matter how deep into the sandbox it is. If I want to watch the video and allow it to use my data, I will explicitly allow it.</text></comment>