Prevent data: URLs from being used for XSS | Hacker News Reader

Prevent data: URLs from being used for XSS

bugzilla.mozilla.org

28 pointslucasgonze12 comments

This bug is almost old enough to drive.

I submitted an earlier version of it back in the early 00s and have been CC'd on the endless procedural back-and-forth ever since. Incredibly, nobody ever said "we're just not doing it."

One for the book of world records, Oldest Bug category.

This reminds me of "MySQL Bug #20786 gets cake":

https://www.youtube.com/watch?v=oAiVsbXVP6k

For those who were wondering: https://bugs.mysql.com/bug.php?id=20786

Ahh the rare self-closing bug. Keep the ticket open long enough, and maybe the standards group will adopt your behavior!

It's cool that the large browsers had standardized on the same non-standard behavior. Makes total sense for WHATWG to adopt it, right?

> Keep the ticket open long enough, and maybe the standards group will adopt your behavior!

But the description of the spec-fix[1] says it aligns with the behavior of all the browsers except Firefox.

So how exactly did Firefox come into alignment with the behavior of the other browsers without there being a patch associated with this bug?

[1] https://github.com/whatwg/html/commit/00769464e80149368672b8...

As far as I can make out, that isn't what happened in this case.

It seems to me that WHATWG settled on the behaviour that the reporter of 255107 originally asked for, and Firefox recently changed to match. The work just wasn't tracked in the 14-year-old 225107 (looks like it's in 1324406).

Most places I've worked, the older a bug is, the less likely it will ever be fixed. The reasoning goes "users have lived with it for this long, so it must not be important." And we have regressions in the code that's about to go out that have not faced users yet--fix them first.

Has anyone ever successfully argued for going back and fixing ancient bugs, prioritizing it over fixing more recently-discovered bugs? What argument did you use?

Bug age is not a particularly useful metric for determining priority.

In my experience, doing bug triage, old bugs generally fall into a few categories:

* Feature requests that aren't WONTFIX but so low priority that they'll stay on the bottom of the list forever (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=2892).

* Bugs that are impossible to fix in the current architecture, and are too low priority to justify the architectural changes to fix them (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=9942).

* Bugs that have too little information to be implemented, and just make everyone who stares at them decide to move onto another bug. These do get cleaned up during periodic deep triages, so I don't have a good 4-digit bug for this.

* Bugs that are political. (https://bugzilla.mozilla.org/show_bug.cgi?id=540)

* Bugs that exist in components that never get triage because no one works on that stuff (or the project itself may be dead) (https://bugzilla.mozilla.org/show_bug.cgi?id=1334).

All citations are rare 4-digit bugs or super-rare 3-digit bugs on Mozilla's bugzilla instance. I myself have triaged a few of those out of existence, but I never fixed any of them.

This reminded me of the Coding Horror blog post "New Programming Jargon"[1] - The Common Law Feature:

> A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.

[1] - https://blog.codinghorror.com/new-programming-jargon/

Nothing like fixing a bug by changing the spec.

14 years ago, it was reported on... Windows XP. PS: I do miss XP.

I have a VM that I have to fire up every once in a awhile to deal with a Delphi 7 app if you feel really sentimental.

Reply on news.ycombinator.com