[R] mozilla and R -- again

Marc Schwartz mschwartz at medanalytics.com
Sat Mar 29 06:11:04 CET 2003


Good evening all,

This will be my last post on this subject...I promise...  :-)

I have spent more time searching this evening on this, only because I
had some gut feelings that my first impression earlier today was not
entirely accurate. Indeed, that seems to be the case here. While I
have not located "conclusive" facts to explain this phenomenon, I have
located sufficient piecemeal information to at least suggest some
possibilities.

In addition, I am also rapidly coming to the conclusion that I am
learning much more about the internal workings of Mozilla than I
really need to know.  :-)

First, the URL showing in the Mozilla DOM/JavaScript Object browser in
WinXP that I referenced earlier
("wyciwyg://0/file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngin
e.html") reflects the use of the "wyciwyg" protocol, which is
apparently used by the Gecko engine to interact with the "Cache"
functions in the browser for **dynamically generated pages**. Thus the
active page URL is not actually "corrupted" as I suggested and this
also applies to the Linux variant of the same URL.

This may not be the sole "rasion d'etre" for wyciwyg, but it certainly
seems to be a significant foundation.

In other words, as I understand it, when you use the Back and/or
Forward buttons and the page you are recalling was dynamically
generated, it is the wyciwyg protocol that Gecko uses to retrieve the
URL's and the page from the Cache. Hence the prefix of "wyciwyg://0/"
in the URL above.

There are several sites that came up in searches suggesting that the
combination of the wyciwyg protocol and Java/JavaScript, along with
both the memory and disk caches can result in the compromise of
"dynamically" generated pages (at least as they are rendered in the
browser after being recalled from the cache). In addition there are
references to possible security risks with the wyciwyg protocol due to
URL spoofing. 

There is an indication in Bugzilla that the latter issue has been very
recently resolved via patches to docshell and imposed restrictions on
what type of pages can be loaded via the wyciwyg protocol and it may
be this change that was reflected in the Security Warning in the
JavaScript Console that I included earlier today.

Some information on these sites would imply that the type of behavior
that we see with relative URL links from the R Java search engine
applet might be expected as a consequence of the combination of the
various above factors.

It is also suggested that the "broken URL" behavior does not occur in
MS IE since MS does not utilize the wyciwyg protocol approach to
recalling dynamically generated pages from IE's cache. 

This would seem to reinforce the possibility that there is something
unique to the use of the wyciwyg protocol by the Gecko engine in this
scenario and the possibility of some "environmental" compromise of the
integrity of the page content in the browser.

In either case, since specific details are somewhat sparse, I am
unclear as to whether or not this behavior is to be fixed. What is
clear is that these symptoms appear to be known and at least similar
issues have been around for a period of time over which multiple
versions of Mozilla have been released without a change.

At this point, I'll leave you with the above and presume that we'll
need to live with this behavior for at least the near term,
notwithstanding the workarounds discussed earlier.

Best regards to all,

Marc Schwartz



More information about the R-help mailing list