A DESCRIPTION OF THE REQUEST :
JWS is missing a SocketService that works the same way the PersistenceService, PrintService, ClipboardService, etc.. work.

JUSTIFICATION :
There is a clear need to interoperate with and leverage existing corporate services. Currently secure Java applications (unsigned) are unable to interoperate with existing corporate services solely because of a lack of a SocketService. Examples of Java's inability to interoperate:
1. Web Services (SOAP)
2. WebDAV
3. Access to financial systems (ACCPAC, QuickBooks, etc... which use TCP/XML to communicate)

Signing applications is a step backwards to the virus and spyware ridden world of the 1990's. A SocketService gives the user total control over when a TCP connection is made and where it is made to. I believe that this is the last missing service and that fine-grained security manager would be unnecessary if a SocketService were available.

I have written a short paper on why signing applications is a non-starter here:
http://www.scheduleworld.com/itsYourLife.html

Running unsigned applications is the perfect secure system and a special edge that .NET does not have.

However, obviously the inability to work together with other services over the network (doesn't McNealy state the N in SUN stands for Network?) is a serious oversight. Please correct it.

Thank you.
(Review ID: 187392) 
======================================================================

N/A

This sounds like a very usefull rfe, unfortunately, we have just finished our proposed specification changes for tiger, and may not be able to implement this untill mustang, unless it is escallated.
 xxxxx@xxxxx  2003-06-16

It may be possible to implement this w/o an API or a spec change, similar to how printing is now handled through the security manager.
If we override checkPermission in JavaWebStartSecurity, we can catch a security exception and just re-throw if not asking for a socket permission, or if configuration dosn't allow or user doesn't accept a security dialog.

 xxxxx@xxxxx  2005-1-06 16:51:37 GMT

I recently made an effort to:

1. Increase developer awareness about secure unsigned JWS applications.
2. Get feedback from developers about the secure environment.
3. Garner some support for the SocketService RFE (4876235).

I did this by posting an article on JavaLobby.org:
http://www.javalobby.org/thread.jspa?forumID=61&threadID=13865

I think the feedback from the folks that took the time to respond spoke favorably about the idea of unsigned JWS and the number of votes for this RFE have increased from 1 to 9. However, the lack of a SocketService stuck out as the key missing piece of functionality that basically removed unsigned JWS as an option for most developers.

I believe, and I think it is fair to say, that until JWS provides a SocketService the unsigned JWS environment will not be considered by the majority of Java developers. This is a shame for many reasons - I shared a few of them in the article.

I _think_ I'm preaching to the choir. The RFE evaluation states, "This sounds like a very useful RFE" so some of the required minds at Sun seem to be aligned on this issue.

Who at Sun needs to be convinced that the SocketService is a fundamental component and needs to be implemented now, not 2.5 years later (June 2003 -> Jan 2006 Mantis).

Who is this anonymous wizard and what white tower do I need to patiently wait outside of to arrange a visit?

To all: if you have any spare votes and care about secure Java Web Start applications please vote for RFE 4876235.

Cheers.

(Reposted to fix the formatting...)

I recently made an effort to:

1. Increase developer awareness about secure unsigned JWS
 applications.
2. Get feedback from developers about the secure environment.
3. Garner some support for the SocketService RFE (4876235).

I did this by posting an article on JavaLobby.org:
http://www.javalobby.org/thread.jspa?forumID=61&threadID=13865

I think the feedback from the folks that took the time to respond spoke
favorably about the idea of unsigned JWS and the number of votes for
this RFE have increased from 1 to 9. However, the lack of a
SocketService stuck out as the key missing piece of functionality that
basically removed unsigned JWS as an option for most developers.

I believe, and I think it is fair to say, that until JWS provides a
SocketService the unsigned JWS environment will not be considered
by the majority of Java developers. This is a shame for many reasons -
I shared a few of them in the article.

I _think_ I'm preaching to the choir. The RFE evaluation states, "This
sounds like a very useful RFE" so some of the required minds at Sun
seem to be aligned on this issue.

Who at Sun needs to be convinced that the SocketService is a
fundamental component and needs to be implemented now, not 2.5
years later (June 2003 -> Jan 2006 Java 1.6).

Who is this anonymous wizard and what white tower do I need to
patiently wait outside of to arrange a visit?

To all: if you have any spare votes and care about secure Java Web
Start applications please vote for RFE 4876235.

Cheers.

This is the one sore point which makes JavaWebStart fairly useless at the moment, at least in the internet scenario. I hate having to give "all permissions". With easy user control of what the app may do, the security argument for java would be totally overwhelming.

+1

JavaWebstart and other Java on the desktop initiatives need more attention from Sun!