API REVIEW: RT-23888, Make PopupFeatures and PromptData final
Randahl Fink Isaksen
randahl at rockit.dk
Fri Aug 31 09:44:55 PDT 2012
Fair enough, Richard. By the way, I had forgotten that actually Text has been changed to be non-final, following an earlier discussion we had, so thanks for that. But the issue remains for WebView as can be seen here:
http://javafx-jira.kenai.com/browse/RT-17331
Have a nice weekend
Randahl
On Aug 31, 2012, at 18:15 , Richard Bair <Richard.Bair at oracle.com> wrote:
>> Richard, I agree that obvious cases like java.lang.String have to be final to avoid security related issues. But how can that be a defence for the final classes found in JavaFX, like Text and WebView?
>>
>> Currently, I can extend PasswordField if I want to create a security breach which sends the user's password off to a remote server in Thailand, but I cannot extend Text to create a banner component which automatically makes the Text fill color flash, or extended WebView to add more innovative features. Where is the sense in that?
>
> That is actually not the security problem (because unless the attacker already has elevated privileges, they can't communicate to a different server anyway). No, the security problem with non-final classes has to do with attacks related to hacking finalizers, equals, hash code, and serialization from a sub class.
>
> Really, security is like threading. It isn't impossible, but there are things you can do with respect to your API that make it harder, or easier, to be secure (just as there are things you can do which make it harder, or easier to design APIs that are thread safe).
>
>> Whenever you make a non-value class final you prevent third party framework developers from adding more innovative features. You take the "open" out of open source. It is just wrong.
>
> I can see you are passionate about that :-). In some cases I would agree, in others I would disagree. Designing APIs for mass consumption and that are intended to be supported for many, many years is a different ballgame.
>
> Cheers
> Richard
More information about the openjfx-dev
mailing list