From hang.vo at oracle.com Sat Sep 1 10:48:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 01 Sep 2012 17:48:39 +0000 Subject: hg: openjfx/8/controls/rt: Fixed broken test: new converters were missing from StyleConverter Message-ID: <20120901174842.D86024785B@hg.openjdk.java.net> Changeset: 722aeb6b5389 Author: rbair Date: 2012-09-01 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/722aeb6b5389 Fixed broken test: new converters were missing from StyleConverter ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleConverterTest.java From hjohn at xs4all.nl Sat Sep 1 11:02:40 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 01 Sep 2012 20:02:40 +0200 Subject: API REVIEW: RT-23888, Make PopupFeatures and PromptData final In-Reply-To: References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <2A78E3F2-775E-45E4-B4F0-02BDADED3B4E@gmail.com> Message-ID: <50424DC0.7010109@xs4all.nl> On 1/09/2012 00:51, Richard Bair wrote: >> I agree with the other guys that final classes are annoying for us, but if they are needed to make things better then so be it. >> >> I think the emotive responses might be a result of us not knowing/understanding the benefits of the final usage and therefore only being able to assess it by its negative aspects. >> >>> 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. >> Can you elaborate on this? Let's say I was a malicious, Hollywood-style hacker. What kind of damage could I do and how would I do that damage via some non-final class (the 'animation' ones for example caused me much grief by being final). > http://www.oracle.com/technetwork/java/seccodeguide-139067.html > > And now that you have this power, please use it for good and help us find security bugs before they hit the net. BTW, if you do find such a bug, email me privately before publicizing to the world ;-). > > Richard I haven't read this yet, although I will. However, these security issues only apply to JavaFX apps running inside a browser. And although I think it is very cool that they can run in a browser, it is not in the least a concern of mine as I am not targetting the browser (so messages like "press escape to exit full screen" are kinda superfluous for me :)). The final keyword however cannot be turned off by disabling the security manager, and so I'm wondering if perhaps classes that are dangerous to subclass in a "secure" environment could not simply check if they are being subclassed in their constructors and throw the usual SecurityException if so. Something like: public MyWannabeFinalSecureClass { public MyWannabeFinalSecureClass() { if(!getClass().equals(MyWannabeFinalSecureClass.class) && !Platform.checkSubclassingAllowed()) { // Safe because getClass() is final. throw new JavaFXSecurityException(); } // Otherwise, subclass away... } } Of course, this being my first venture into Java Security Managers, I could be totally off :) --John From randahl at rockit.dk Sat Sep 1 11:20:25 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 1 Sep 2012 20:20:25 +0200 Subject: A solution to the final classes problem In-Reply-To: <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> Message-ID: <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> Richard, I think we could all benefit from an improved design of the final classes, which would both allow critical parts to be final (like you prefer), while allowing non-critical parts to be overridden (like many on this list prefer). Take FileChooser for instance. I would like to subclass it to add some of my own framework features, but I can't because it is final. After reading the security article you linked to, I can see why there could be sound reasons for declaring it final if, say, the class contains security checks in some methods. I think the main problem is, that both the UI stuff (which I want to override and improve) and the security related stuff (which I do not wish to harm in any way) is rolled into one big class. I believe an improved design would be to implement the FileChooser as a pure UI component that delegates security-sensitive work to a separate class, along the lines of nonfinal FileChooser ----> final SecureFileManager That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language. The result would be OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager If you guys keep your classes final, we third party developers end up with a much less desirable design OurFileChooser --knows--> FileChooser This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone. Yours Randahl On Aug 31, 2012, at 18:15 , Richard Bair 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 From phidias51 at gmail.com Sat Sep 1 12:45:58 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 1 Sep 2012 12:45:58 -0700 Subject: A solution to the final classes problem In-Reply-To: <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> Message-ID: It would also be useful if FileChooser could be used with nio2 classes. This would make it possible to support new file systems. Cheers, Mark On Sat, Sep 1, 2012 at 11:20 AM, Randahl Fink Isaksen wrote: > Richard, I think we could all benefit from an improved design of the final > classes, which would both allow critical parts to be final (like you > prefer), while allowing non-critical parts to be overridden (like many on > this list prefer). > > Take FileChooser for instance. I would like to subclass it to add some of > my own framework features, but I can't because it is final. After reading > the security article you linked to, I can see why there could be sound > reasons for declaring it final if, say, the class contains security checks > in some methods. > > I think the main problem is, that both the UI stuff (which I want to > override and improve) and the security related stuff (which I do not wish > to harm in any way) is rolled into one big class. I believe an improved > design would be to implement the FileChooser as a pure UI component that > delegates security-sensitive work to a separate class, along the lines of > > nonfinal FileChooser ----> final SecureFileManager > > That way, I can extend the FileChooser in our framework and create > OurFileChooser which automatically does a lot of useful work for the > application developer, such as providing automatic internationalization > support, that sets the title in accordance with the user's preferred > language. > > The result would be > > OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager > > If you guys keep your classes final, we third party developers end up with > a much less desirable design > > OurFileChooser --knows--> FileChooser > > This design requires us to implement every single method of FileChooser in > OurFileChooser for the sole purpose of delegating to your class, which is a > lot harder to maintain, and a lot more error prone. > > Yours > > Randahl > > > > > On Aug 31, 2012, at 18:15 , Richard Bair 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 > > From javafx at olifanz.com Sat Sep 1 14:45:21 2012 From: javafx at olifanz.com (Gaja Sutra) Date: Sat, 01 Sep 2012 23:45:21 +0200 Subject: High performance text component In-Reply-To: <3C5F5BCB-0AAA-4C1A-8624-895CEDAC5892@oracle.com> References: <501930DB.1030004@freenet.de> <501B3CE3.6070408@freenet.de> <65D70FDB-66E6-4D78-ACB4-446196F9DFD6@oracle.com> <501F8B51.8070604@bestsolution.at> <502C0FDB.6020002@freenet.de> <75611275-CEAA-4FBE-81BC-71E38DCB3E1D@oracle.com> <3C5F5BCB-0AAA-4C1A-8624-895CEDAC5892@oracle.com> Message-ID: <504281F1.9090907@olifanz.com> > (I'm finally able to edit the openjfx wiki!) > > We are still in a very early stage but this is what we are planning for Rich Text: > > https://wikis.oracle.com/display/OpenJDK/Rich+Text > > Let me know if you have any suggestions or concerns. > Not a suggestion/concern for a first draft of Rich text API, but probably not fully exempt of usefulness: to keep possible as a future problem, in a long time, after all usual features like vertical alignment, vertical text and possibly even after boustrophedon. How a component builder can implement an embedded span-like object, like your image, but supporting linebreaking? By example, a component displaying mathematical formulas can support linebreaking, particularly on small screens, cf. [1, 2] for proving the non-empty interest in this problem. I am not asking for a response, just signalling a non-usual possible future problem to not forget (and keep open). I don't see any problem with current API for adding, in the future, this feature (e.g. by implementing an interface if supporting linebreaking), but I suggest this open problem when seeing your embedded objects in rich text and asking myself how to embed something other. Most expected impact will not be in API, but in implementation: to avoid complex entanglement of hyphenation and text and let future extensions be possible without large refactoring of code. Sorry for exotic mail. Gaja. [1]: http://www.dessci.com/en/products/mathplayer/tech/mathml3-lb-indent.htm [2]: linebreaking (fourth row of table) in http://www.maths-informatique-jeux.com/blog/frederic/?post/2012/09/01/Mozilla-MathML-Project%3A-Roadmap From philip.race at oracle.com Sat Sep 1 19:58:22 2012 From: philip.race at oracle.com (Phil Race) Date: Sat, 01 Sep 2012 19:58:22 -0700 Subject: A solution to the final classes problem In-Reply-To: <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> Message-ID: <5042CB4E.9070208@oracle.com> On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote: > Richard, I think we could all benefit from an improved design of the final classes, which would both allow critical parts to be final (like you prefer), while allowing non-critical parts to be overridden (like many on this list prefer). > > Take FileChooser for instance. I would like to subclass it to add some of my own framework features, but I can't because it is final. After reading the security article you linked to, I can see why there could be sound reasons for declaring it final if, say, the class contains security checks in some methods. > > I think the main problem is, that both the UI stuff (which I want to override and improve) and the security related stuff (which I do not wish to harm in any way) is rolled into one big class. I believe an improved design would be to implement the FileChooser as a pure UI component that delegates security-sensitive work to a separate class, along the lines of > > nonfinal FileChooser ----> final SecureFileManager Really? Implicitly suggesting there's a "non-secure" FileChooser - and what's more you want to use it ? I'd not buy your app ;-) OK yes, you can promise to make it secure and what's more you're trustworthy etc, etc. But also we'd really not be able to ship the platform like that. How many developers would search for "F" for FileChooser and never spot the one they are supposed to use under "S". Yes, OK there's probably some clever way you could the right one more obvoius. However at the end of the day we can't accommodate everyone's wishes. A wants X. B want Y. X and Y are incompatible. Please make A and B happy if possible, but if you can't do the best you can .. and above all be secure. -phil. > > That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language. > > The result would be > > OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager > > If you guys keep your classes final, we third party developers end up with a much less desirable design > > OurFileChooser --knows--> FileChooser > > This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone. > > Yours > > Randahl > > > > > On Aug 31, 2012, at 18:15 , Richard Bair 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 From randahl at rockit.dk Sat Sep 1 21:30:24 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sun, 2 Sep 2012 06:30:24 +0200 Subject: A solution to the final classes problem In-Reply-To: <5042CB4E.9070208@oracle.com> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> Message-ID: Phil, any JavaFX developer can *already* ship any kind of FileChooser they want to. No matter how you ship your platform, you cannot prevent anyone from creating an app containing their own EvilFileChooser. The fact that you have a final class called FileChooser does not prevent that, as no one is forced to extend your class. Moreover, I bet that 99% of the JavaFX apps that uses the FileChooser do so from a method in the app that is not declared final. How would you prevent anyone from overriding that app method and bringing up another EvilFileChooser? I think it is a shame to lower the flexibility of JavaFX just to get a false sense of security. Randahl On Sep 2, 2012, at 4:58 , Phil Race wrote: > On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote: >> Richard, I think we could all benefit from an improved design of the final classes, which would both allow critical parts to be final (like you prefer), while allowing non-critical parts to be overridden (like many on this list prefer). >> >> Take FileChooser for instance. I would like to subclass it to add some of my own framework features, but I can't because it is final. After reading the security article you linked to, I can see why there could be sound reasons for declaring it final if, say, the class contains security checks in some methods. >> >> I think the main problem is, that both the UI stuff (which I want to override and improve) and the security related stuff (which I do not wish to harm in any way) is rolled into one big class. I believe an improved design would be to implement the FileChooser as a pure UI component that delegates security-sensitive work to a separate class, along the lines of >> >> nonfinal FileChooser ----> final SecureFileManager > > Really? Implicitly suggesting there's a "non-secure" FileChooser - and what's more > you want to use it ? I'd not buy your app ;-) OK yes, you can promise to make it > secure and what's more you're trustworthy etc, etc. But also we'd really not be able to > ship the platform like that. How many developers would search for "F" for FileChooser > and never spot the one they are supposed to use under "S". Yes, OK there's probably > some clever way you could the right one more obvoius. > However at the end of the day we can't accommodate everyone's wishes. > A wants X. B want Y. X and Y are incompatible. Please make A and B happy > if possible, but if you can't do the best you can .. and above all be secure. > > -phil. > >> >> That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language. >> >> The result would be >> >> OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager >> >> If you guys keep your classes final, we third party developers end up with a much less desirable design >> >> OurFileChooser --knows--> FileChooser >> >> This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone. >> >> Yours >> >> Randahl >> >> >> >> On Aug 31, 2012, at 18:15 , Richard Bair 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 > From philip.race at oracle.com Sat Sep 1 21:39:04 2012 From: philip.race at oracle.com (Phil Race) Date: Sat, 01 Sep 2012 21:39:04 -0700 Subject: A solution to the final classes problem In-Reply-To: References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> Message-ID: <5042E2E8.9000604@oracle.com> FileChooser probably isn't the best example here, since it implies a level of trust to be able to access the file system so as to your point here, sandboxed apps surely can't "ship any kind of FileChooser" They'd have to live within whatever we allowed untrusted apps to do which may be very little for a FileChooser. -phil. On 9/1/12 9:30 PM, Randahl Fink Isaksen wrote: > Phil, any JavaFX developer can *already* ship any kind of FileChooser they want to. No matter how you ship your platform, you cannot prevent anyone from creating an app containing their own EvilFileChooser. The fact that you have a final class called FileChooser does not prevent that, as no one is forced to extend your class. > > Moreover, I bet that 99% of the JavaFX apps that uses the FileChooser do so from a method in the app that is not declared final. How would you prevent anyone from overriding that app method and bringing up another EvilFileChooser? > > I think it is a shame to lower the flexibility of JavaFX just to get a false sense of security. > > Randahl > > > > On Sep 2, 2012, at 4:58 , Phil Race wrote: > >> On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote: >>> Richard, I think we could all benefit from an improved design of the final classes, which would both allow critical parts to be final (like you prefer), while allowing non-critical parts to be overridden (like many on this list prefer). >>> >>> Take FileChooser for instance. I would like to subclass it to add some of my own framework features, but I can't because it is final. After reading the security article you linked to, I can see why there could be sound reasons for declaring it final if, say, the class contains security checks in some methods. >>> >>> I think the main problem is, that both the UI stuff (which I want to override and improve) and the security related stuff (which I do not wish to harm in any way) is rolled into one big class. I believe an improved design would be to implement the FileChooser as a pure UI component that delegates security-sensitive work to a separate class, along the lines of >>> >>> nonfinal FileChooser ----> final SecureFileManager >> Really? Implicitly suggesting there's a "non-secure" FileChooser - and what's more >> you want to use it ? I'd not buy your app ;-) OK yes, you can promise to make it >> secure and what's more you're trustworthy etc, etc. But also we'd really not be able to >> ship the platform like that. How many developers would search for "F" for FileChooser >> and never spot the one they are supposed to use under "S". Yes, OK there's probably >> some clever way you could the right one more obvoius. >> However at the end of the day we can't accommodate everyone's wishes. >> A wants X. B want Y. X and Y are incompatible. Please make A and B happy >> if possible, but if you can't do the best you can .. and above all be secure. >> >> -phil. >> >>> That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language. >>> >>> The result would be >>> >>> OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager >>> >>> If you guys keep your classes final, we third party developers end up with a much less desirable design >>> >>> OurFileChooser --knows--> FileChooser >>> >>> This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone. >>> >>> Yours >>> >>> Randahl >>> >>> >>> >>> On Aug 31, 2012, at 18:15 , Richard Bair 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 From randahl at rockit.dk Sat Sep 1 22:33:13 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sun, 2 Sep 2012 07:33:13 +0200 Subject: A solution to the final classes problem In-Reply-To: <5042E2E8.9000604@oracle.com> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> <5042E2E8.9000604@oracle.com> Message-ID: <6CE19DCC-BD0E-4331-A190-473A0748055B@rockit.dk> Thank you Phil ? that is my point exactly! Whether or not an app is allowed to open a file *is not* a question of whether you make FileChooser final. It is a question of whether the app is allowed to do stuff like read from the hard drive. A sound design would separate the stuff developers could safely customise into a non-final customisable class, and put the stuff which *really* needs to be final into its own final class. For example, I am sure you agree that it does not matter to the security of JavaFX whether I get to override the way the title of the FileChooser is set. Currently the title is set like this myFileChooser.setTitle("The title"); I wish to subclass FileChooser so developers who use our framework can create OurFileChooser like this public class OurFileChooser { OurFileChooser(String keyToTitleResource) { String title = InternationalizationSystem.getString(keyToTitleResource); setTitle(title); } } where the constructor of OurFileChooser automatically loads the proper internationalized text for the title using the resource key the developer provides, and then sets the title. We could build this, if the FileChooser class was not final, and you could still put all the things you want to prevent me from overriding in a final class which FileChooser delegates to. And this is just an example ? there would be many other cool things I could do in a subclass to save the application developer a lot of hard work. 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. Randahl On Sep 2, 2012, at 6:39 , Phil Race wrote: > FileChooser probably isn't the best example here, since it implies a level of trust to be able > to access the file system so as to your point here, sandboxed apps surely can't "ship any kind of FileChooser" > They'd have to live within whatever we allowed untrusted apps to do which may be very little > for a FileChooser. > > -phil. > > > On 9/1/12 9:30 PM, Randahl Fink Isaksen wrote: >> Phil, any JavaFX developer can *already* ship any kind of FileChooser they want to. No matter how you ship your platform, you cannot prevent anyone from creating an app containing their own EvilFileChooser. The fact that you have a final class called FileChooser does not prevent that, as no one is forced to extend your class. >> >> Moreover, I bet that 99% of the JavaFX apps that uses the FileChooser do so from a method in the app that is not declared final. How would you prevent anyone from overriding that app method and bringing up another EvilFileChooser? >> >> I think it is a shame to lower the flexibility of JavaFX just to get a false sense of security. >> >> Randahl >> >> >> >> On Sep 2, 2012, at 4:58 , Phil Race wrote: >> >>> On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote: >>>> Richard, I think we could all benefit from an improved design of the final classes, which would both allow critical parts to be final (like you prefer), while allowing non-critical parts to be overridden (like many on this list prefer). >>>> >>>> Take FileChooser for instance. I would like to subclass it to add some of my own framework features, but I can't because it is final. After reading the security article you linked to, I can see why there could be sound reasons for declaring it final if, say, the class contains security checks in some methods. >>>> >>>> I think the main problem is, that both the UI stuff (which I want to override and improve) and the security related stuff (which I do not wish to harm in any way) is rolled into one big class. I believe an improved design would be to implement the FileChooser as a pure UI component that delegates security-sensitive work to a separate class, along the lines of >>>> >>>> nonfinal FileChooser ----> final SecureFileManager >>> Really? Implicitly suggesting there's a "non-secure" FileChooser - and what's more >>> you want to use it ? I'd not buy your app ;-) OK yes, you can promise to make it >>> secure and what's more you're trustworthy etc, etc. But also we'd really not be able to >>> ship the platform like that. How many developers would search for "F" for FileChooser >>> and never spot the one they are supposed to use under "S". Yes, OK there's probably >>> some clever way you could the right one more obvoius. >>> However at the end of the day we can't accommodate everyone's wishes. >>> A wants X. B want Y. X and Y are incompatible. Please make A and B happy >>> if possible, but if you can't do the best you can .. and above all be secure. >>> >>> -phil. >>> >>>> That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language. >>>> >>>> The result would be >>>> >>>> OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager >>>> >>>> If you guys keep your classes final, we third party developers end up with a much less desirable design >>>> >>>> OurFileChooser --knows--> FileChooser >>>> >>>> This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone. >>>> >>>> Yours >>>> >>>> Randahl >>>> >>>> >>>> On Aug 31, 2012, at 18:15 , Richard Bair 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 > From tbee at tbee.org Sat Sep 1 23:58:39 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 02 Sep 2012 08:58:39 +0200 Subject: A solution to the final classes problem In-Reply-To: <6CE19DCC-BD0E-4331-A190-473A0748055B@rockit.dk> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> <5042E2E8.9000604@oracle.com> <6CE19DCC-BD0E-4331-A190-473A0748055B@rockit.dk> Message-ID: <5043039F.8000508@tbee.org> 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 From hjohn at xs4all.nl Sun Sep 2 00:40:35 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 02 Sep 2012 09:40:35 +0200 Subject: A solution to the final classes problem In-Reply-To: <5042CB4E.9070208@oracle.com> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> Message-ID: <50430D73.2080002@xs4all.nl> On 2/09/2012 04:58, Phil Race wrote: > On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote: >> Richard, I think we could all benefit from an improved design of the >> final classes, which would both allow critical parts to be final >> (like you prefer), while allowing non-critical parts to be overridden >> (like many on this list prefer). >> >> Take FileChooser for instance. I would like to subclass it to add >> some of my own framework features, but I can't because it is final. >> After reading the security article you linked to, I can see why there >> could be sound reasons for declaring it final if, say, the class >> contains security checks in some methods. >> >> I think the main problem is, that both the UI stuff (which I want to >> override and improve) and the security related stuff (which I do not >> wish to harm in any way) is rolled into one big class. I believe an >> improved design would be to implement the FileChooser as a pure UI >> component that delegates security-sensitive work to a separate class, >> along the lines of >> >> nonfinal FileChooser ----> final SecureFileManager > > Really? Implicitly suggesting there's a "non-secure" FileChooser - and > what's more > you want to use it ? I'd not buy your app ;-) OK yes, you can promise > to make it > secure and what's more you're trustworthy etc, etc. But also we'd > really not be able to > ship the platform like that. How many developers would search for "F" > for FileChooser > and never spot the one they are supposed to use under "S". Yes, OK > there's probably > some clever way you could the right one more obvoius. > However at the end of the day we can't accommodate everyone's wishes. > A wants X. B want Y. X and Y are incompatible. Please make A and B happy > if possible, but if you can't do the best you can .. and above all be > secure. If his app does not run in the browser, what's the difference? Also, what's stopping us from making our own FileChooser, apart from some time investment? From hjohn at xs4all.nl Sun Sep 2 00:58:45 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 02 Sep 2012 09:58:45 +0200 Subject: A solution to the final classes problem In-Reply-To: <5043039F.8000508@tbee.org> References: <5040B53D.6070800@oracle.com> <5040B62D.5010400@tbee.org> <1A91A8AD-6401-4DED-A00D-7C02430FE7D7@oracle.com> <0A72C92A-A796-4256-8812-85ED42824E4E@rockit.dk> <5042CB4E.9070208@oracle.com> <5042E2E8.9000604@oracle.com> <6CE19DCC-BD0E-4331-A190-473A0748055B@rockit.dk> <5043039F.8000508@tbee.org> Message-ID: <504311B5.7090606@xs4all.nl> 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... From zonski at gmail.com Sun Sep 2 06:27:32 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Sep 2012 23:27:32 +1000 Subject: An FXML Browser (topic branched from Re: High performance text component) Message-ID: So this one has me intrigued. I sort of assumed that building a Scene per page and throwing it away (or worse just removing it from the scene but keeping it in memory) would be way too heavy a thing to do in desktop land. But then I guess that's what Chrome, Firefox and IE must be doing, so why can't we. This does kind of open up a whole new set of pathways for doing what Flow is trying to achieve and here's a bit of random, thinking out loud. As an experimental starting point, I've just knocked up a very crude (one class) 'FXML Browser', which basically can browse FXML files from the web, much like Chrome browses HTML files. http://code.google.com/p/jfxee/source/browse/trunk/jfxbrowser/ I've ignored the 'controller' aspect for now, and just done a bit of a hack where I scan the built Node for any 'Hyperlink' elements, and then I use the 'userData' attribute to hold the URL (i.e. to act like the 'href' property in a web anchor). When the Hyperlink gets clicked, the Browser navigates to the new URL and shows that (i.e. builds a new scene from the new FXML). The previous page (i.e. node) is removed from the scene but cached in a list so the 'back' button can reshow it without loading (i.e. just like a web browser). I'm sure we could do something similar with a 'form' concept - effectively achieving the entire web experience (minus JScript) without touching controllers at all. Remarkably simple and nothing to it really. Are you telling me that navigating loads of 'pages' (i.e. FXML files) in this sort of fashion shouldn't be a problem and the Scene graph is basically designed to handle this? All I do is remove the node from the Scene graph, I don't have to manually tell it to release any resources or anything like that? I've uploaded two hardcoded, dumb FXML files to my server just for testing (the above code will open one of them on startup, which then links to the second page). http://zenjava.com/demo/browser/fxml/hello-world.fxml http://zenjava.com/demo/browser/fxml/another.fxml Obviously there would be nothing stopping the Browser from pointing to a dynamic webapp such as a SpringMVC one that generates FXML instead of the normal HTML. Basically achieving the exact same experience we can get with HTML-based web-apps right now, it's just that the display is FXML (instead of HTML) and the browser is a Java one (instead of Chrome/IE/Firefox). I'm not too sure what I want to do with this yet. The 'controller' side of things would be the obvious next bit to work out, which means getting into the classloading side of it. I guess it's conceptually the same as a web browser loading a JavaScript file when the page loads - a direct mapping of this would pretty much be a separate classloader for each 'page'. Not sure that'll scale in a proper Java environment (but maybe). Alternatively maybe some sort of application boundary - where all URLs within the same context share a classloader which is loaded once. I feel like this could all be valuable but I'm not sure a raw FXML browser like this would be the actual target solution. Maybe. But the web has been moving away from server side stuff to 'rich clients' with AJAX, so a more inline solution could be for the server just to send down data (e.g. as JSON) and for the client then to do the template rendering, i.e. pass the data through a template to generate the page to build and then show the Node. This would allow the client to not be so totally constrained by the 'page-based' structure and instead use the generator to throw away and re-assemble sub-sections of the overall view (i.e. very much like AJAX). Perhaps the sweet spot between the web's page-based approach, and the desktop's normal monolithic UI paradigm. I think I'll mull over this for a while but if anyone wants to throw in some comments, feel free. On Fri, Aug 31, 2012 at 11:39 PM, Richard Bair wrote: > Hi Daniel, > > Ok, so really we're just talking about a new type of layout pane than has > a concept of lines and wrapping as part of its layout algorithm? > > > Yes, exactly. > > > That is true, although I think that is also why people who hate > programming for the web hate it so much -- it tries to see the entire world > through > > the lens of a document, when really that only covers some of the use > cases. But in our world, you can put a full TabPane or other layout > container > > in the Paragraph, or vice versa, as your mood or fancy or use case > requires. But really Paragraph exists not for laying out the entire > application, but > > for rich text scenarios. Word allows you to embed graphs and tables, we > need to allow for the same. > > I agree with your conclusion but I'm not sure the 'page' concept is what > people hate about web programming (or at least its not my main gripe). For > me the big, big problem is that layout management doesn't really exist and > we have to use CSS, which is just not built for it as well as all the > horrid cross-browser compatibility issues (and then the fact we have to use > untyped JScript to do anything dynamic with the page). Your combination of > 'Paragraph' layout and the normal desktop-like layouts does sound like the > best of both worlds (without cross-browser problems and with real Java) > > > No, the page concept I think is wonderful, when what you are doing is a > page. But when what you are trying to do is a traditional application UI / > desktop layout, then it is fighting against you (as you mentioned above). > That's what I was getting at. You basically have two layout metaphors -- > grids and flows. For flows, text based flow (ie: HTML) works really well. > For grid like layouts, traditional layout managers (hbox, vbox, grid, > contraint-based, whatever) work really well. Unfortunately HTML tries to > treat everything as a nail 'cause all it has is a hammer. > > Would it be possible (i.e. performant/practical) to do something where we > use a templating language (I've just been using google-closure-templates > instead of JSPs and it's pretty nice, but any templating language would do) > to generate a scene. > > So we would have a template like: > > >

> {$myTitle} > {foreach $thing in $list} >