On Fri, 21 Aug 2026 11:51:56 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> `JDK has the following API : java.awt.Desktop.browse(URI) "Launches the >> default browser to display a URI." >> >> On Windows and macOS, the JDK used to call platform APIs to do this which >> would recognise some schemes as ones which would launch an associated >> application. For example on Windows "calculator:" is a scheme that windows >> may open the calculator, and on macOS "facetime:" may open the facetime >> application. >> >> Desktop.browse now always launches the browser directly, which is a problem >> for apps that took advantage of the previous behavior, since the browser >> itself may not re-direct to those applications. >> >> The current behaviour is intentional to provide a secure-by-default >> behaviour. >> >> The proposal here is to introduce an implementation system property ( >> **awt.desktop.browse_insecure**) which will allow apps to opt back into the >> old behaviour on Windows and macOS. >> >> The end-user, or the application, can set this property as a comma separated >> list of allowed schemes : >> >> -Dawt.desktop.browse_insecure=calculator,file >> >> where on Windows, the calculator and file scheme will be opened in open >> calc.exe and the File Explorer app respectively. >> >> or -Dawt.desktop.browse_insecure=* >> >> which allows all schemes. >> >> If -Dawt.desktop.browse_insecure is set or the scheme is in the allowed >> list, then JDK will open the URI using platform APIs which may open an >> associated app instead of the browser >> If -Dawt.desktop.browse_insecure is NOT set or scheme is NOT in the allowed >> list, the browser is explicitly launched and URI is handled by the browser - >> i.e. no change from current behaviour. >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Prasanta Sadhukhan has updated the pull request incrementally with three > additional commits since the last revision: > > - Use shared implementation > - Use shared implementation > - Use shared implementation Still, I think the whole chain of patches should be reworked. The initial patch should be reverted, and on top of the old behavior a filter similar to the serialization filter, but for the schema should be added. Implementation based on assumption that it is safe to pass the text w/o any validation to the binary file registered as browser is less secure. Since skipping the system dispatcher bypass the way the parameters are handles by the binary file and in the end it is possible to manipulate it. It should be reconsidered or re-investigated before the integration, since after that the java property will be supported forever. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32247#issuecomment-6030084476
