Recall that one key argument for the Sonny Bono copyright extension act was that it was needed to make the US consistent with Europe. Now the Europeans are saying they need to change their laws to be consistent with the US. It's beautiful --- they make "progress" by just leapfrogging each other.
-- The EU makes compositions death of the author + 70 years, and records date of recording + 50 years -- The US becomes "consistent" by making all copyrights death of the author + 70 years -- The EU restores "consistency" by... doing what? Who wants to bet that they extend copyrights just a little beyond the US in some area, so the US will then have to "catch up"?
A couple of weeks ago, when Download.Ject was big news, there was a top-of-the-front-page article in our local newspaper, the Westchester Journal-News. It included (still top of the front page) a list of hints, including one to switch to another browser "Mozilla (www.mozilla.org), free, or Opera (www.opera.com), $39".
Mozilla does support different levels of trust. For example, a page on a remote website can't create an IFRAME whose SRC points at your local filesystem. A local file can do that. So I don't know what your point is.
This bug is about which Windows HTTP protocol handlers should be trusted. 'shell:' was trusted when it should not have been.
That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.
That is not a report of this or any other vulnerability. It's simply a suggestion for a change that would have provided a defense in case a vulnerability like this one was discovered. I agree we still should have done it, and hopefully will do it now...
On Saturday our local newspaper (Westchester Journal News) had a front page article about this stuff, including (still on the front page) a recommendation to download an alternative browser --- "Mozilla (free) from www.mozilla.org or Opera ($39) from www.opera.com"
Only if your application sucks. freedesktop.org spells out how this should work; ctrl-c/ctrl-v manage the CLIPBOARD selection, and mouse selection manages the PRIMARY selection. Selecting text with the mouse should NOT interfere with ctrl-c ctrl-v operations in ANY way.
Actually I know one Slashdot type guy who did short SCO and has made a considerable amount of money.
It was difficult though; he had to wait for a while to get a chance to short them, because almost all the stock available for shorting was already tied up in short positions!
There are two kinds of protocol handlers in Windows: system-wide and IE-specific. Mozilla supports the system-wide protocols but not the IE-specific protocols. ms-its is an IE-specific protocol.
We should probably take a second look at the system-wide protocols, though. Currently we blacklist some and let the rest through.
Actually, according to the CERT advisory, turning of Javascript and ActiveX does not close the vulnerability. So despite your precautions you're actually still vulnerable.
Microsoft will not be using SVG. They'll be using what their original docs call "WVG". (But after that leak they backpedalled saying "it's really NOTHING to do with SVG, honest"). Now I think they're just calling it part of Avalon.
It provides similar functionality to SVG, it's just different.
Firstclass support for SVG (e.g., including support for arbitrary HTML inside SVG) requires changes in various parts of the code base. SVG is not something that you can plug modularly into the engine.
Don't get confused about what deCOMtaminating SVG means. It just means that internally SVG will be more efficient. You can still manipulate SVG content from Javascript, via the DOM and other interfaces. Your charting engine will still work.
> How in hell are you meant to use it - the higher > element will recieve all the user input.
You can tab to it. Also, the element might only be partially covered. Also, this is just one example. But the bottom line is that you can't refuse to render CSS correctly just because you've determined that the page is in bad taste.
> Secondly, Konqueror, which uses the Qt toolkit, > renders it fine.
It does now, but it didn't when I tried it a couple of years ago.
I know there are platforms with toolkits where you can get this to work. The problem we have to deal with is getting it to work on every platform.
One thing I should add to that document is that the set of things we need widgets to support is expanding. For example, we want first-class SVG support, and SVG lets you put arbitrary HTML under arbitrary SVG transformations. So, will Qt let me have a scaled, rotated, slightly out of focus (i.e., convolution filtered), composited as part of an translucent group, but fully functional text box? (Hint: when Qt has full support for a rendering pipeline which can handle full SVG semantics.) How long before that's supported on all platforms? Not until Longhorn is on most Windows users' desktops, for sure.
As the document says, we do aim for the platform look and feel. We can (and on some platforms, do) use the platform file open/save dialogs etc. We should do that everywhere, it's a work item.
If you want fully native chrome, you can use Camino or Epiphany or K-Meleon or write your own thing for KDE. We didn't want to maintain N platform-specific browser UIs, but we're happy for other people to do that.
Turns out though, that an XML+Javascript crossplatform UI framework is a very cool thing, especially since we can share a lot of the implementation with our XML/HTML rendering engine. Because of that framework we have this large and growing library of Firefox/Thunderbird/Mozilla extensions that simply work everywhere. And of course, because of that framework we have Firefox and Thunderbird running on all platforms from day 1.
If you use another cross-platform UI framework, the problems I mentioned in my document don't go away. That framework ends up having to solve the same problems. For example did you know that on Windows, Qt doesn't use native widgets?
I agree, it would be nice to have stronger Mozilla integration with KDE. There is nothing stopping someone from doing that, it's just work that no-one has signed up to do. We had a Qt port for a while but no-one had time to maintain it.
(BTW I'm the original author of that document and I use KDE all the time.)
I work at IBM. I've been authorized to say the following to clear up a few misconceptions:
IBM has 3 systems that can execute Java programs: - The oldest JVM is the base for the current generation of products and is derived from Sun code, but contains significant changes to the JIT and garbage collector. See https://www6.software.ibm.com/dl/lxdk/lxdk-p - A newer product JVM (internally called J9) was developed from an IBM code base. See http://www.ibm.com/software/wireless/wme/features. html - A third (Jikes RVM) has been developed principally for research use and is written in Java. It is an existing open source project that uses GNU Classpath libraries and is popular with JVM researchers. It is not complete, mostly because Classpath is not complete. It is capable, with only the Classpath libraries, of running substantial programs such as Eclipse. See http://www.ibm.com/developerworks/oss/jikesrvm/
I got a similar DSL runaround between my ISP and my phone company. My DSL mysteriously cut out, the ISP blamed the phone company, and the phone company said that we lived too far from the central office to be supported (despite the fact that the service had worked fine for months).
Fortunately I learned of a magical solution, at least in New York: The New York Public Utilities Commission. I filed a complaint at their Web site and within a week I had a phone company repair man at my house and the DSL back on. Plus both the ISP and the phone company called me multiple times to make sure I was satisfied.
Slashdot Mirror
It's true.
e tzdowd. com/msg02579.html
Paper here:
http://eprint.iacr.org/2004/199.pdf
Independently verified here:
http://www.mail-archive.com/cryptography@m
Recall that one key argument for the Sonny Bono copyright extension act was that it was needed to make the US consistent with Europe. Now the Europeans are saying they need to change their laws to be consistent with the US. It's beautiful --- they make "progress" by just leapfrogging each other.
... doing what? Who wants to bet that they extend copyrights just a little beyond the US in some area, so the US will then have to "catch up"?
-- The EU makes compositions death of the author + 70 years, and records date of recording + 50 years
-- The US becomes "consistent" by making all copyrights death of the author + 70 years
-- The EU restores "consistency" by
A couple of weeks ago, when Download.Ject was big news, there was a top-of-the-front-page article in our local newspaper, the Westchester Journal-News. It included (still top of the front page) a list of hints, including one to switch to another browser "Mozilla (www.mozilla.org), free, or Opera (www.opera.com), $39".
What the other commenters said --- there's probably a bug here, but right now, this doesn't appear to be an exploitable bug.
Mozilla does support different levels of trust. For example, a page on a remote website can't create an IFRAME whose SRC points at your local filesystem. A local file can do that. So I don't know what your point is.
This bug is about which Windows HTTP protocol handlers should be trusted. 'shell:' was trusted when it should not have been.
That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.
That is not a report of this or any other vulnerability. It's simply a suggestion for a change that would have provided a defense in case a vulnerability like this one was discovered. I agree we still should have done it, and hopefully will do it now...
Actually, experience suggests that without a compelling reason to switch back, people will continue to use the browser they are using.
On Saturday our local newspaper (Westchester Journal News) had a front page article about this stuff, including (still on the front page) a recommendation to download an alternative browser --- "Mozilla (free) from www.mozilla.org or Opera ($39) from www.opera.com"
So it's not just techies preaching to the choir.
It's nice for reading a lot of text.
This kind of monitor is also very good for people in medicine. Think reading X-rays.
Ask your Microsoft techie friends whether they believe this rubbish.
Then ask them how they'd feel if someone wrote a book claiming that the hard work they did was actually stolen.
Then ask them how they feel about working for the company that funds this.
Only if your application sucks. freedesktop.org spells out how this should work; ctrl-c/ctrl-v manage the CLIPBOARD selection, and mouse selection manages the PRIMARY selection. Selecting text with the mouse should NOT interfere with ctrl-c ctrl-v operations in ANY way.
c /c lipboards.txt
http://freedesktop.org/Standards/clipboards-spe
Actually I know one Slashdot type guy who did short SCO and has made a considerable amount of money.
It was difficult though; he had to wait for a while to get a chance to short them, because almost all the stock available for shorting was already tied up in short positions!
"The Empire will compensate you for your losses."
6 /b oba1.wav
http://www.geocities.com/Hollywood/Bungalow/360
I bet at least five people are using that.
Mozilla is not vulnerable.
There are two kinds of protocol handlers in Windows: system-wide and IE-specific. Mozilla supports the system-wide protocols but not the IE-specific protocols. ms-its is an IE-specific protocol.
We should probably take a second look at the system-wide protocols, though. Currently we blacklist some and let the rest through.
Actually, according to the CERT advisory, turning of Javascript and ActiveX does not close the vulnerability. So despite your precautions you're actually still vulnerable.
Actually, you're exactly right.
Microsoft will not be using SVG. They'll be using what their original docs call "WVG". (But after that leak they backpedalled saying "it's really NOTHING to do with SVG, honest"). Now I think they're just calling it part of Avalon.
It provides similar functionality to SVG, it's just different.
Firstclass support for SVG (e.g., including support for arbitrary HTML inside SVG) requires changes in various parts of the code base. SVG is not something that you can plug modularly into the engine.
Don't get confused about what deCOMtaminating SVG means. It just means that internally SVG will be more efficient. You can still manipulate SVG content from Javascript, via the DOM and other interfaces. Your charting engine will still work.
> How in hell are you meant to use it - the higher
> element will recieve all the user input.
You can tab to it. Also, the element might only be partially covered. Also, this is just one example. But the bottom line is that you can't refuse to render CSS correctly just because you've determined that the page is in bad taste.
> Secondly, Konqueror, which uses the Qt toolkit,
> renders it fine.
It does now, but it didn't when I tried it a couple of years ago.
I know there are platforms with toolkits where you can get this to work. The problem we have to deal with is getting it to work on every platform.
One thing I should add to that document is that the set of things we need widgets to support is expanding. For example, we want first-class SVG support, and SVG lets you put arbitrary HTML under arbitrary SVG transformations. So, will Qt let me have a scaled, rotated, slightly out of focus (i.e., convolution filtered), composited as part of an translucent group, but fully functional text box? (Hint: when Qt has full support for a rendering pipeline which can handle full SVG semantics.) How long before that's supported on all platforms? Not until Longhorn is on most Windows users' desktops, for sure.
As the document says, we do aim for the platform look and feel. We can (and on some platforms, do) use the platform file open/save dialogs etc. We should do that everywhere, it's a work item.
If you want fully native chrome, you can use Camino or Epiphany or K-Meleon or write your own thing for KDE. We didn't want to maintain N platform-specific browser UIs, but we're happy for other people to do that.
Turns out though, that an XML+Javascript crossplatform UI framework is a very cool thing, especially since we can share a lot of the implementation with our XML/HTML rendering engine. Because of that framework we have this large and growing library of Firefox/Thunderbird/Mozilla extensions that simply work everywhere. And of course, because of that framework we have Firefox and Thunderbird running on all platforms from day 1.
If you use another cross-platform UI framework, the problems I mentioned in my document don't go away. That framework ends up having to solve the same problems. For example did you know that on Windows, Qt doesn't use native widgets?
I agree, it would be nice to have stronger Mozilla integration with KDE. There is nothing stopping someone from doing that, it's just work that no-one has signed up to do. We had a Qt port for a while but no-one had time to maintain it.
(BTW I'm the original author of that document and I use KDE all the time.)
I work at IBM. I've been authorized to say the following to clear up a few misconceptions:
. html
IBM has 3 systems that can execute Java programs:
- The oldest JVM is the base for the current generation of products and is derived from Sun code, but contains significant changes to the JIT and garbage collector. See
https://www6.software.ibm.com/dl/lxdk/lxdk-p
- A newer product JVM (internally called J9) was developed from an IBM code base. See http://www.ibm.com/software/wireless/wme/features
- A third (Jikes RVM) has been developed principally for research use and is written in Java. It is an existing open source project that uses GNU Classpath libraries and is popular with JVM researchers. It is not complete, mostly because Classpath is not complete. It is capable, with only the Classpath libraries, of running substantial programs such as Eclipse. See http://www.ibm.com/developerworks/oss/jikesrvm/
I got a similar DSL runaround between my ISP and my phone company. My DSL mysteriously cut out, the ISP blamed the phone company, and the phone company said that we lived too far from the central office to be supported (despite the fact that the service had worked fine for months).
Fortunately I learned of a magical solution, at least in New York: The New York Public Utilities Commission. I filed a complaint at their Web site and within a week I had a phone company repair man at my house and the DSL back on. Plus both the ISP and the phone company called me multiple times to make sure I was satisfied.
Then perhaps they're done. It's not widely known but Openoffice has an Access-like database front end.
http://www.unixodbc.org/doc/OOoMySQL.pdf