On 2014-11-06 4:45 PM, Chris Steipp wrote:
On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott
<datzrott(a)alizeepathology.com> wrote:
This seems completely reasonable to me. I'd
merge is personally. Is there
any reason not to?
It's fairly easy to inject javascript via css, so merging
that patch
means an admin can run javascript on the login/preferences page, while
we specifically block javascript from Common.js, etc.
For me, I like knowing that when I login on a random wiki in our
cluster, a site admin can't have (maliciously or unintentionally) put
javascript on the login page to sniff my password. I'd prefer Kunal's
patch had a feature flag so we could disable this on WMF wikis, but
sites with robust auditing of their common.css can enable it.
I should probably take some time to remind everyone that things hiding
any form of JS from single pages like the login pages makes them secure,
that restrictions like those are not that hard to bypass by using JS on
a non-login page to use AJAX and history.pushState to trick someone
clicking the login link into thinking that they actually navigated the
page and are safe from site-js, when in reality they're actually still
on the same page with malicious site-js running.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://danielfriesen.name/]