A solution to the final classes problem

[John Hendrikx]

On 2/09/2012 08:58, Tom Eugelink wrote:
> On 2012-09-02 07:33, Randahl Fink Isaksen wrote:
>> I do not disagree with you – maybe some things need to be final. I 
>> just think you cast too wide a net, that is all.
>>
>
>
> Which again leads me to repost my question; Swing has no final classes 
> what so ever, you can extend any component (even JFileChooser 
> http://docs.oracle.com/javase/6/docs/api/javax/swing/JFileChooser.html). 
> Swing also is the most used UI framework, so there is enough 
> incentive. Is there any example of how this has ever been misused as a 
> security leak? Or perhaps an example of how this could be used as a 
> security leak, which would have been prevented had the classes been 
> final (and is not easily done some other way)?
>
> Tom
>
It's trivial enough to put the features that really need to be secure in 
a seperate final class (to which the UI delegates), or even in final or 
private methods.  Perhaps this is what Swing is doing internally.  Some 
analysis is needed to make sure results from these methods donot get 
used in non-final methods.

Not that I can think of any realistic example why a FileChooser should 
be secure in the first place -- this is already handled at a lower 
level.  Even if it did allow you to select some dangerous file, 
attempting to manipulate it would immediately throw a security exception.

In fact, most stuff involving the UI should be secured at a much lower 
level because any control provided by JavaFX can easily be recreated 
using more basic controls.

I can imagine though that stuff like going full screen (with transparent 
screens especially) and allowing one to open seperate windows would need 
to be stuffed behind a security check.  There's very little stopping you 
to create an exact look-a-like of some password dialog, or even some 
website + password entry fields.  It does not necessarily have to 
compromise your local machine to be a security issue...