I don't trust Greasemonkey an inch. A bunch of web coders pretending to be real software engineers and in way out of their depth.
You don't fix exploits like that by testing and issuing patches. You do it by understanding what the hell you're doing from the outset and having an architecture that is robust from the outset. You know where the boundaries of trust are, they're so obvious that anyone can point to them, and they're followed through into the implementation. The attitude of "we'll have to add another little security test here, then it'll be right" has never worked. Just read your history from before '99 (ask your grandad)
We curse M$oft often enough for their buffer overflows and random holes, but at least they have some notion at recruiting time of the distinction between real engineers and someone who wrote a few lines of code that appeared to work.
I agree. It's clear that the GM authors didn't take a principled stance on security, and the ad hoc way in which features have been added has led to the current state. It was obvious that they were getting into dangerous waters when they created GM_* equivalents for functions like XMLHttpRequest in order to get around the existing Mozilla security model.
Sentences like "Unlike the XMLHttpRequest object, GM_xmlhttpRequest is not restricted to the current domain; it can GET or POST data from any URL" (from Dive Into Greasemonkey) should have been ringing warning bells considerably earlier than they did.
Absolutely. Allowing access to the user's own machine was one big problem - allowing JS from the page itself to use GM was another. The combination is fairly obviously lethal.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
You don't fix exploits like that by testing and issuing patches. You do it by understanding what the hell you're doing from the outset and having an architecture that is robust from the outset. You know where the boundaries of trust are, they're so obvious that anyone can point to them, and they're followed through into the implementation. The attitude of "we'll have to add another little security test here, then it'll be right" has never worked. Just read your history from before '99 (ask your grandad)
We curse M$oft often enough for their buffer overflows and random holes, but at least they have some notion at recruiting time of the distinction between real engineers and someone who wrote a few lines of code that appeared to work.
(no subject)
Sentences like "Unlike the XMLHttpRequest object, GM_xmlhttpRequest is not restricted to the current domain; it can GET or POST data from any URL" (from Dive Into Greasemonkey) should have been ringing warning bells considerably earlier than they did.
(no subject)
(no subject)
(no subject)
Now upgrading beyond Atom 0.3 That's hardcore mandatory - where the protocol authors actively hunt down and kill errant versions.