Javascript call to invisible applet fails after upgrading to 1.5 (IE)

[Dag Sunde]

I have an applet with some public methods
I call from Javascript in a .html page.

I load it , and set the css-style 'visibility'
to hidden.

Then i call a method in the applet from JS.

This have worked perfectly in IE6 witj jre 1.4.x

Now I have recompiled the applet with 1.5 and
updated the java plugin to 1.5, and the method
call from JS fails as long as the applets style is hidden.

Can someone shed some light on this for me?

 

[Andrew T.]

I have an applet with some public methods
I call from Javascript in a .html page.
URL?

I load it , and set the css-style 'visibility'
to hidden.

I have been expecting to see problems with hidden
applets for some time. It is a natural* consequence
of the tightening security .

* As far as I understand it.

Then i call a method in the applet from JS.

This have worked perfectly in IE6 witj jre 1.4.x

Now I have recompiled the applet with 1.5 and
updated the java plugin to 1.5, and the method
call from JS fails as long as the applets style is hidden.

Is it a security problem? (Make sure you check both
JS and Java consloles)

Can someone shed some light on this for me?

Not sure, need more info.
(URL's to the applet both visible and hidden would help,
and I am presuiming you are not swallowing exceptions.)
A third including the applet with a width/height of 0
might also be interesting.

Andrew T.

 

[Roedy Green]

Let's say you do that. If it is a dangerous signed applet, you still
see the request for permission. If it is an unsigned Applet, what
dangerous thing could it do?

 

[Dag Sunde]

URL?

Thanks for responding Andrew.
I'm sorry, but it is a customer owned 'closed'
system, so I can't give any.

I also need to correct some information. I was
dragged into this when one of our other programmers
hit the problem, so my first info wasn't entirely accurate.

calling an applet-methods fail in 1.4.2 too, as long as the applet
or its container's visibility is set to hidden.

The case/problem we enconter is:
(Imagine a applet containing ie. a JTable
for entering bids, et.c)

When the user click on a link to enter new bids, the applets
container is set to visible, and on the following line,
one of the applet's methods are called:

//JS-code (IE 6.0)
var gridApplet = document.getElementById('gridapplet');
document.getElementById('mainContentPane').style.visibility = 'visible';
gridApplet.initMarket(market);

in 1.4.2, the above worked, but in 1.5 the call to initMarket(...) fails.
BUT! if we introduce a small delay between making it visible and calling
the method, it works with the 1.5 plugin too.

I've done a little research, and it turns out that IE doesn't call an
applet's init() and start() methods at page load/parse time if it determine
that the applet or its container is hidden. The Applet is initialized
first when it is made visible. (Firefox initializes the applet at page load,
regardless of it's visible state).

It seems like jre 1.5 plugin needs a little more time to 'wake up' before
you can call any of the applet's methods...?

Is it a security problem? (Make sure you check both
JS and Java consloles)

Have done so, nothing. Our Applet is signed, and given full privileges.
It *might* be that the developer have swallowed one or more
exceptions, but he promised me he had not... :-\

A third including the applet with a width/height of 0
might also be interesting.

That will work, because in that case the applet is 'visible', and already
initialized.

The reason we want to avoid this, is the ugly flashing that occurs when
one resizes the applet from 0 to its full size.

Thanks for your interest and tips...

 

[Dag Sunde]

Let's say you do that. If it is a dangerous signed applet, you still
see the request for permission. If it is an unsigned Applet, what
dangerous thing could it do?

That's what we concluded too, and I couldn't find *anyting* from MS or
Sun indicating that such changes have been made. Neither to the browser nor
to the java VM.

 

[Andrew T.]

....
It seems like jre 1.5 plugin needs a little more time to 'wake up' before
you can call any of the applet's methods...?

Uh-Huh, OK. To safeguard yourself for that situation, you can
delay your JS a little and check the applet.isAlive(?) method to
wait for it.

( But depsite yours and Roedy's logical countering of my
security worries, I still feel it is only a matter of time before
most invisible elements in pages will be considered at least
slightly suspicious.

Andrew T.

 

[Chris Uppal]

That's what we concluded too, and I couldn't find *anyting* from MS or
Sun indicating that such changes have been made.

I'm with Andy in suspecting that this will cause you problems in the future if
it isn't already.

a) "Invisible" elements in general are getting a very bad name, not matter what
they are expressed in. Browser designers would be very well advised to be
/extremely/ cautious about providing the ability to create stealth elements --
or indeed any elements which don't look like what they are.

b) Security thinking requires a mental model of how things behave, if things
are allowed to move outside that model, then /you just don't know/ what will
happen. If the browser-designers have managed (/if/) to learn that lesson,
then they will insist that applets (and all other elements) are constrained to
work within the limits of the /designers'/ mental model of what applets are
for.

The fact that I, personally, cannot think of an attack vector which is
available to an invisible applet, but not to a visible one, is irrelevant. The
point is that, in the absence of convincing formal proof[*], my not being able
to imagine a problem doesn't mean there isn't one there. Browser designers,
and creators of other highly security-sensitive software, are slowly learning
this way of thinking.

-- chris

[*] Quite difficult to provide, since the proof would surely require mapping
the problem domain into some formalism, and it's /precisely/ when that mapping
is performed, that divergences between the mental model of the domain, and the
actual physical domain[**], tend to get lost.

[**] i.e. real instructions operating on physically real RAM in a physically
real computer.

 

[Dag Sunde]

Uh-Huh, OK. To safeguard yourself for that situation, you can
delay your JS a little and check the applet.isAlive(?) method to
wait for it.

That's what we did. But I was suprised by the difference and the
need to do so.

We developed two different ways to "wait". The first one we used
a small loop with a JS try/catch block, calling the method in the
try, and introducing a small (250mS) delay in the catch before retrying.

The otherone uses the netscape JSObject in the applet to call back to
a JS function when the Applet's start() method is executed.

I like the latter best, leaving it to the applet to announce when its
ready.

( But depsite yours and Roedy's logical countering of my
security worries, I still feel it is only a matter of time before
most invisible elements in pages will be considered at least
slightly suspicious.

I definitely share your worries... Thats why I made some effort to
understand and check the consequences. And my conclusion is that
there is none.

But, that doesn't solve the problem that the users or their
IT-departmens will be suspicious about hidden, active content.

The only solution I can see to that is education and documentation.

 

[Andrew T.]

Dag Sunde wrote:

'applet not ready'
....

We developed two different ways to "wait". The first one we used
a small loop with a JS try/catch block, calling the method in the
try, and introducing a small (250mS) delay in the catch before retrying.

The otherone uses the netscape JSObject in the applet to call back to
a JS function when the Applet's start() method is executed.

I like the latter best, leaving it to the applet to announce when its
ready.

I cannot see the advantage. I prefer the former since it can easily
be applied to third party applets that you don't have the option of
altering.

As for the security concerns, I think Chris put it into words
better than I could. My best explanation would be
'better safe than sorry'. ;-)

Andrew T.