Disabling the Sandbox

Discussion in 'Java' started by erictetz@gmail.com, Aug 6, 2007.

  1. Guest

    I'm trying to develop a java applet that operates outside the
    sandbox.

    I know I need to sign the applet for distribution, but for development
    purposes I'd like to be able to simply disable the sandbox, give my
    applet permission to do whatever it wants, even if that means
    temporarily disabling all security in my browser/VM/etc.

    Googling about I find references to a .java.profile file, but using
    the suggesting settings in that doesn't seem to work. I can't find
    options in Firefox, or IE to open up the sandbox.

    Can someone direct me to a solution, or a better forum to ask this
    question. I chose this one over java.security because it's active.

    Cheers,
    Eric
    , Aug 6, 2007
    #1
    1. Advertising

  2. Roedy Green Guest

    On Mon, 06 Aug 2007 01:11:50 -0000, wrote, quoted
    or indirectly quoted someone who said :

    >I know I need to sign the applet for distribution, but for development
    >purposes I'd like to be able to simply disable the sandbox, give my
    >applet permission to do whatever it wants, even if that means
    >temporarily disabling all security in my browser/VM/etc.


    I think someone said AppletViewer has no sandbox.
    You can make it a hybrid and run it as an application.
    See http://mindprod.com/jgloss/applet.html
    for how. code is included in the
    http://mindprod.com/products1.html#COMMON11
    and
    http://mindprod.com/products1.html#COMMON13

    Use an ANT script that does the signing. It takes only a second.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 6, 2007
    #2
    1. Advertising

  3. Roedy Green wrote:
    >>I know I need to sign the applet for distribution, but for development
    >>purposes I'd like to be able to simply disable the sandbox, give my
    >>applet permission to do whatever it wants, even if that means
    >>temporarily disabling all security in my browser/VM/etc.

    >
    >I think someone said AppletViewer has no sandbox.


    Correct. (AV is also used by JWS to launch applets,
    and JWS imposes a sandbox, but that is not relevant
    to the type of use of the AV to which you refer).

    >You can make it a hybrid and run it as an application.


    Yes. This can be good for simple applets, but might
    require more work if the applet actively uses the
    parameter map, or opens other URL's etc.

    But, I prefer ..

    >Use an ANT script that does the signing. It takes only a second.


    ..the Ant solution for this day and age.

    After all, it can not only build and sign a project in
    a matter of moments, but you can also add an FTP
    task to upload the project (applet or JWS app.)
    when it is ready for deployment or update!

    To the OP. Any of the three methods outlined by Roedy
    is better than attempting to decipher those (damnable)
    policy files as they might interact with any real world
    browser. It might be possible to get it working on your
    dev. machine, but is probably not worth the bother.

    Since it makes sense to create an Ant script to build
    (sign) and deploy the applet, it makes sense to write
    it now, and use it during development.

    As an aside, even signed applets have 'issues' in IE on
    Vista - a new security model limits them to accessing
    files from specific directories. If it needs to be signed,
    or otherwise 'loosen' that restrictive sandbox for web
    deployed apps., I would tend to look to web start*.

    * Which, ironically, is also affected by the new Vista
    security model, but I /might/ have a fix for that problem..

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via http://www.javakb.com
    Andrew Thompson, Aug 6, 2007
    #3
  4. Guest

    On Aug 5, 6:52 pm, "Andrew Thompson" <u32984@uwe> wrote:
    > As an aside, even signed applets have 'issues' in IE on
    > Vista - a new security model limits them to accessing
    > files from specific directories. If it needs to be signed,
    > or otherwise 'loosen' that restrictive sandbox for web
    > deployed apps., I would tend to look to web start*.


    *sigh*

    What about Flash? I don't really give a damn what language/tool I use,
    but it needs to be (1) cross platform, supporting at least Windows PC
    and Mac, (2) preferably browser-based so it can be seamlessly
    integrated with web content, (3) as transparent as possible to the
    user, automatically updating itself, etc. Simplicity (read: idiot-
    proofing) is the primary objective.

    Would Flash meet those requirements? Is this Applet restriction
    something Microsoft acknowledges as a problem on Vista -- something
    what will be eventually fixed -- or is it a permanent restriction? It
    seems pretty stupid that users are limited in what kinds of
    permissions they can willingly grant to web applications.
    , Aug 6, 2007
    #4
  5. Guest

    On Aug 5, 6:52 pm, "Andrew Thompson" <u32984@uwe> wrote:
    > Roedy Green wrote:
    > >I think someone said AppletViewer has no sandbox.

    >
    > Correct.


    Hmmm... that's one of the first things I tried.

    I'm using the latest Java SDK, I type 'appletviwer myproject.html',
    yet I seem to get the exactly same sandbox as when I'm running in the
    browser. For instance, if I try to call File.isDirectory() I get:

    java.security.AccessControlException: access denied
    (java.io.FilePermission c:\path\file.ext read)
    at
    java.security.AccessControlContext.checkPermission(AccessControlContext.java:
    323)
    at
    java.security.AccessController.checkPermission(AccessController.java:
    546)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:
    532)
    at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
    at java.io.File.isDirectory(File.java:752)
    at FileUploader.drop(FileUploader.java:68)
    at java.awt.dnd.DropTarget.drop(DropTarget.java:430)
    ...
    , Aug 6, 2007
    #5
  6. wrote:
    >> As an aside, even signed applets have 'issues' in IE on
    >> Vista - a new security model limits them to accessing
    >> files from specific directories. If it needs to be signed,
    >> or otherwise 'loosen' that restrictive sandbox for web
    >> deployed apps., I would tend to look to web start*.

    >
    >*sigh*
    >
    >What about Flash?


    (shrugs) ..dunno. Don't know Flash, don't have it installed.
    Last time I heard, it was going through some serious security
    issues, and I don't need the bother.

    What is it, in this *trusted* applet, that requires trust?

    Note that barring the 'seamless integration with web content'
    mentioned below, JWS would be a good fit for this, and
    could probably achieve what is needed in a sandboxed
    app.
    ...
    >...Simplicity (read: idiot-proofing) is the primary objective.


    No such thing. When you design something that is
    'idiot-proof', they release a 'new and improved' idiot.

    Any user might not have *either* Flash or Java installed.
    Any user might not only not have it installed, but either
    be unwilling or *unable* (they don't control the hardware)
    to install it. Any user might have the right plug-in installed,
    but an insufficient version of it.

    It is *our* responsibility as developers to go to our
    best effort to either get the app. running, or to provide
    useful feedback to the user if that is not possible.

    That's why we get the 'big bucks'. ;-)

    >...Is this Applet restriction
    >something Microsoft acknowledges as a problem on Vista -- something
    >what will be eventually fixed -- or is it a permanent restriction?


    MS says it is Sun's problem, and there is a bug raised
    with Sun against it. I had not looked at the details closely,
    but many of the other Java developers involved seemed
    to see it as Sun's problem, though Sun was not showing
    any clear signs of rushing to put forward a fix.

    If you care that much, search the bug DB (always a
    chore) find the bug, and vote for it to be fixed.

    >...It
    >seems pretty stupid that users are limited in what kinds of
    >permissions they can willingly grant to web applications.


    Yeah, yeah.. preaching to the converted.

    ..You're new to this whole 'trusted apps. embedded
    in a web page' type project, aren't you?

    It might help for you to describe what it is your app.
    is intended to achieve (besides being embedded in
    a web page, involved with content and 'trust' I still
    have little idea what is the ultimate point) - the app.
    might not require as much trust as you expect.

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via http://www.javakb.com
    Andrew Thompson, Aug 6, 2007
    #6
  7. Andrew Thompson wrote:
    > Roedy Green wrote:
    >> I think someone said AppletViewer has no sandbox.

    >
    > Correct. (AV is also used by JWS to launch applets,
    > and JWS imposes a sandbox, but that is not relevant
    > to the type of use of the AV to which you refer).


    The appletviewer sandbox works for me.

    Note, you can read (only) files from the path that the your classes are
    loaded from. That is necessary to, for instance, load resources and the
    class files themselves. Way back in 1.1, it classes on the classpath
    were treated as privileged (there was not the distinction of system and
    bot class loader back then). Applets often had a codebase of the current
    working directory, which was also used by the default classpath. IIRC,
    this meant they were loaded by the system class loader and given full
    privileges. This is not a problem for Java 2 (first released 1998).

    Applet support in the Java PlugIn and Java WebStart are extensions of
    the appletviewer code. There are some technical differences. I think the
    class loading is slightly different by default and PlugIn/WebStart, for
    instance, allows printing to go ahead after a dialog without any
    additional APIs. The source is of course available if you are interested.

    >> You can make it a hybrid and run it as an application.

    >
    > Yes. This can be good for simple applets, but might
    > require more work if the applet actively uses the
    > parameter map, or opens other URL's etc.


    I think it well worth doing anyway.

    >> Use an ANT script that does the signing. It takes only a second.

    >
    > .the Ant solution for this day and age.


    Or just a shell/batch file will do just as well.


    My preferred solution is to run in the sandbox, with the extra
    facilities Java WebStart gives you, or run as a normal application.
    Don't sign anything unless you know what you are doing. I am not aware
    of anyone who knows what they are doing.

    Tom Hawtin
    Thomas Hawtin, Aug 6, 2007
    #7
  8. wrote:
    ...
    >java.security.AccessControlException: access denied
    >(java.io.FilePermission c:\path\file.ext read)


    'That will fail on a Mac.' You did say this was meant to
    run on Win & Mac., right?

    So, is it that this file will eventually be on the same
    site as the applet? If so, the applet can be sandboxed.
    Check this post for details..
    <http://groups.google.com/group/comp.lang.java.help/msg/2dab0b52bd3fc072>

    If the app. needs to access files on the client PC,
    JWS provides access to the local file system, even
    in a sandboxed app. Here is a demo, with build file.
    <http://www.physci.org/jws/#fs>

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via http://www.javakb.com
    Andrew Thompson, Aug 6, 2007
    #8
  9. Thomas Hawtin wrote:
    ...
    >Note, you can read (only) files from the path that the your classes are
    >loaded from.


    I suspect that is the problem with the OP's current
    attempts, but not knowing the path to the applet,
    or the codebase, it is hard to be sure.
    ...
    >Applet support in the Java PlugIn and Java WebStart are extensions of
    >the appletviewer code. There are some technical differences. I think the
    >class loading is slightly different by default ...


    It used to be, but there were a swathe of 'broken* web
    start app.' questions in the JWS forum over recent times
    when the classloaders for the applet plug-in and web start
    (for both applications and applets) was merged into a single
    entity.

    * Most of those questions were related to finding the
    location on disk where the classes were cached, and
    that was always a broken and fragile way to go about
    finding resources, even before Sun included an option
    for the end user to specify the cache location.

    Since 'getResource()' and plain URL's always worked
    seamlessly, I never bothered to look into it that carefully,
    beyond recommending to rework the app. to use them.

    >...and PlugIn/WebStart, for
    >instance, allows printing to go ahead after a dialog without any
    >additional APIs.


    Sockets, sure, but I thought the Print API was locked out,
    except by use of the PrintService** (had never bothered
    checking it though, and frustratingly - do not even have
    a printer to test my own JWS example!).

    ** <http://www.physci.org/jws/#prs>
    ...
    >My preferred solution is to run in the sandbox, with the extra
    >facilities Java WebStart gives you, ...


    I suspect that would suffice, for this app., and that
    it would therefore by the best choice, ..except for
    that tight browser integration. I mean - try and
    configure the launch parameters of a web start
    app., using JS. ;-)

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via JavaKB.com
    http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1
    Andrew Thompson, Aug 6, 2007
    #9
  10. Guest

    On Aug 5, 7:53 pm, "Andrew Thompson" <u32984@uwe> wrote:
    > What is it, in this *trusted* applet, that requires trust?


    Access to any part of the user's file system that the user wants us to
    access.
    The user supplies the file name(s), by browsing or dragging and
    dropping them
    onto the applet. The applet then needs to read those files. The applet
    cannot
    be restricted to a subset of the file system: the files the users
    wants to
    supply us may come from anywhere on their machine.

    > Any user might not only not have it installed, but either be unwilling or
    > *unable* (they don't control the hardware) to install it. Any user might
    > have the right plug-in installed, but an insufficient version of it.


    For our purposes, if the user doesn't have control if their own
    machine, they
    won't be using our app. If they don't have the right version, *it's up
    to the
    plugin to be able to automatically update itself*. That's part of what
    I'm
    asking here. If the plugin cannot do that, I cannot use that plugin.

    > It is *our* responsibility as developers to go to our best effort to either
    > get the app. running, or to provide useful feedback to the user if that is
    > not possible.


    It is not my responsibility to ensure that Sun or Adobe has their act
    together.

    Look, the simplest option I can create for the *user* is to say "PC
    users click
    here" and "Mac users click here", and let each download a platform
    specific
    binary. In that case, *I* can make sure that each binary works on
    whatever
    version of Windows or MacOS the user may have. That's idiot-proof: it
    doesn't
    require the user to do *anything* special on their end to get the
    application
    to work.

    My desire for a cross-platform solution is to make *my* life easier,
    not the
    user's. I simply do not want to maintain two code bases.

    Now, if it turns out that the Java plugin is too stupid to keep itself
    updated,
    then that's Sun's problem, not mine (and a rather embarrassing one,
    this late
    in the game). I can't fix that, it just means I can't use Java. If
    Flash is too
    stupid to keep itself updated and/or there is no seamless, one-click
    solution
    to let the user download the latest version of the plugin and
    continue, than
    that's Adobe's problem, not mine. Again, I can't fix that, it just
    means I
    can't use Flash.

    >From what I've seen of Flash, it seems to very keep itself udpated

    transparently. If you don't have the required version, there's usually
    a 'click
    here to get the latest version' button, maybe enough click to give the
    appropriate permissions, and in minutes you're up to date. I don't
    know much
    more than that without investigating further.

    That level of user interaction is acceptable. What I *can't* have is
    something
    like "Sorry, you don't have the latest version of PLATFORM(tm), please
    visit
    PLATFORM AUTHOR's website and download the latest version of the
    PLATFORM
    RUNTIME(tm) and install it." It pretty much needs to be a one-click
    solution.

    > You're new to this whole 'trusted apps. embedded in a web page' type project,
    > aren't you?


    I have no idea if this is new or old, I just have something I want to
    do and am
    trying to figure out what tool to do it with. I really don't care who
    makes it
    or what language it is. No technology religion here at all.

    > wrote:
    > >java.security.AccessControlException: access denied (java.io.FilePermission
    > >c:\path\file.ext read)

    >
    > 'That will fail on a Mac.' You did say this was meant to run on Win & Mac.,
    > right?


    Why wouldn't it work? That path is not hardcoded (that's not even the
    actual
    path, I edited the error message to make the path generic, rather than
    reflecting my filesystem). That path comes from the user, via browsing
    or by
    drag and drop. I don't need to interact with the path contents at all,
    other
    than (in the case of Java) converting it to a String and showing it to
    the
    user, and passing it to a File object to access the file's contents.

    You mention JWS. Is that a one-click solution, or is the user going to
    be
    present with a "this application requires the latest version of the
    Java
    Runtime(tm)" type of dialog?

    Cheers,
    Eric
    , Aug 6, 2007
    #10
  11. Guest

    Damn Google groups and their < 80 character display width.
    , Aug 6, 2007
    #11
  12. Andrew Thompson wrote:
    >
    > * Most of those questions were related to finding the
    > location on disk where the classes were cached, and
    > that was always a broken and fragile way to go about
    > finding resources, even before Sun included an option
    > for the end user to specify the cache location.


    The exact path name not predictable any more. There is a random element.
    IIRC, there were a number of IE/Netscape bugs that involved planting a
    script file in a guessable location on the victim machine, and then
    executing it as if it were from the local machine.

    > Sockets, sure, but I thought the Print API was locked out,
    > except by use of the PrintService** (had never bothered
    > checking it though, and frustratingly - do not even have
    > a printer to test my own JWS example!).


    I don't have a printer either (at least not in this (constituent)
    country). I guess I could use a print-to-file printer driver.

    Anyway, if you have the JDK source,
    deploy/src/plugin/share/classes/sun/plugin/security/ActivatorSecurityManager.java.
    The override of SecurityManager.checkPrintJobAccess first checks super,
    and if that fails opens a dialog. It confused me the first time I saw it
    as I was expecting a security exception but got a deadlock.

    Tom Hawtin
    Thomas Hawtin, Aug 6, 2007
    #12
  13. wrote:
    >> What is it, in this *trusted* applet, that requires trust?

    >
    >Access to any part of the user's file system that the user wants us to
    >access.
    >The user supplies the file name(s), by browsing or dragging and
    >dropping them
    >onto the applet.


    JWS. Drop the 'embedded in web page part' and this
    is all doable in JWS.

    >For our purposes, if the user doesn't have control if their own
    >machine, they
    >won't be using our app.


    OK - that removes a lot of problems. Web start launch
    can be made a lot smoother if the user can also be
    expected to have JS enabled in their browser.

    >...If they don't have the right version, *it's up
    >to the
    >plugin to be able to automatically update itself*. That's part of what
    >I'm
    >asking here. If the plugin cannot do that, I cannot use that plugin.


    Java does auto-update, and for Win. user's it is relatively
    transparent (as you describe below for Flash).

    One of Java Web Start's main advantages beyond ensuring
    the *application* is up to date, is to make sure the end-user
    has the minimum required version of Java, to run it in the first
    place.

    ...
    >> It is *our* responsibility as developers to go to our best effort to either
    >> get the app. running, or to provide useful feedback to the user if that is
    >> not possible.

    >
    >It is not my responsibility to ensure that Sun or Adobe has their act
    >together.


    I don't think you've put enough thought/research
    yet into the 'other side' of doing things from the
    internet. That is, the User Agent (read browser)
    that is being asked to interact with either Flash,
    or Java web start launched apps. (whether applet
    or application).

    This all comes to to the *serious* threat of getting
    viruses or other malware off binaries from internet
    sites. Sometimes a plug-in will attempt to do something
    that is 'vetoed' by the browser (or the OS, or any
    of a number of browser plug-ins (e.g. pop-up killers)
    or anti-virus software).

    The maker of the Plug-In only has so much control
    over the decisions of the browser manufacturers
    (and the rest of them) - most things are a matter of
    negotiation, but Sun (no idea about the makers of
    Flash) seems unwilling to take on browser manufacturers
    for the sake of applets.

    >Look, the simplest option I can create for the *user* is to say "PC
    >users click
    >here" and "Mac users click here", and let each download a platform
    >specific
    >binary.


    Is it? I have seen installers for Win. that curl up and
    die with no clear error message.

    But that is starting to sound like your app is not
    'embedded' in a browser in any case.

    >..In that case, *I* can make sure that each binary works on
    >whatever
    >version of Windows or MacOS the user may have.


    Can you make it work on that ol' 486 of mine?
    I think it's running Win. 95. ;-)

    >>From what I've seen of Flash, it seems to very keep itself udpated

    >transparently. If you don't have the required version, there's usually
    >a 'click
    >here to get the latest version' button, maybe enough click to give the
    >appropriate permissions, and in minutes you're up to date. I don't
    >know much
    >more than that without investigating further.
    >
    >That level of user interaction is acceptable. What I *can't* have is
    >something
    >like "Sorry, you don't have the latest version of PLATFORM(tm), please
    >visit
    >PLATFORM AUTHOR's website and download the latest version of the
    >PLATFORM
    >RUNTIME(tm) and install it."


    I think the current Java update situation is ..
    - tranpsarent for Windows
    - 'visit the site' for Mac.

    >...It pretty much needs to be a one-click
    >solution.
    >
    >> You're new to this whole 'trusted apps. embedded in a web page' type project,
    >> aren't you?

    >
    >I have no idea if this is new or old, I just have something I want to
    >do and am
    >trying to figure out what tool to do it with. I really don't care who
    >makes it
    >or what language it is. No technology religion here at all.


    My point was not about competing tech., but having
    (any) trusted app. within a browser window, or 'coming
    at you' off the internet.

    >> wrote:
    >> >java.security.AccessControlException: access denied (java.io.FilePermission
    >> >c:\path\file.ext read)

    >>
    >> 'That will fail on a Mac.' You did say this was meant to run on Win & Mac.,
    >> right?

    >
    >Why wouldn't it work?


    Note the quotes, they indicated, ..

    >...That path is not hardcoded


    ..if you presume that path to be hard coded.
    ( I hoped that would become clear from my later
    comments, but then I've hoped for a pony for a
    long time, and (checks) ..no sign of that yet, either ;)

    >..(that's not even the
    >actual
    >path, I edited the error message to make the path generic, rather than
    >reflecting my filesystem). That path comes from the user, via browsing
    >or by
    >drag and drop.


    I am relatively sure that D'n'D can be used in a
    sandboxed JWS App., but have not checked it.

    >..I don't need to interact with the path contents at all,
    >other
    >than (in the case of Java) converting it to a String and showing it to
    >the
    >user, and passing it to a File object to access the file's contents.


    The sandboxed JWS API does not allow you to get
    access to a standard java.io.File object, instead you
    work with a javax.jnlp.FileContents. It is similar, but
    more limited.
    <http://java.sun.com/javase/6/docs/jre/api/javaws/jnlp/javax/jnlp/FileContents.html
    >


    >You mention JWS. Is that a one-click solution, or is the user going to
    >be
    >present with a "this application requires the latest version of the
    >Java
    >Runtime(tm)" type of dialog?


    If you app. requires Java 1.6, when the user has Java 1.4
    (or 1.5, 1.3, 1.2 or 1.1) yes. If it is compatible with 1.4,
    any user with 1.4, 1.5, 1.6.. can use it straight away.

    Most of the file/access could be achieved in the JNLP
    API that existed when it was first released (during Java
    1.2), but for GUI elements, 1.4 was a significant
    improvement. Java 1.5 added the ExtendedService to
    the JNLP API that allows the user to avoid a file open
    dialog when 'double click openning' a file with the app.

    Java 1.2 has already been shelved (long ago) and
    Java 1.4 should be going into EOL very soon.

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via JavaKB.com
    http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1
    Andrew Thompson, Aug 6, 2007
    #13
  14. Thomas Hawtin wrote:
    ..
    >> ...I thought the Print API was locked out,
    >> except by use of the PrintService** (had never bothered
    >> checking it though, and frustratingly - do not even have
    >> a printer to test my own JWS example!).

    >
    >I don't have a printer either (at least not in this (constituent)
    >country). I guess I could use a print-to-file printer driver.


    I'll have to look into that - I would love to check it myself.

    >Anyway, if you have the JDK source,
    >deploy/src/plugin/share/classes/sun/plugin/security/ActivatorSecurityManager.java.
    >The override of SecurityManager.checkPrintJobAccess first checks super,
    >and if that fails opens a dialog. It confused me the first time I saw it
    >as I was expecting a security exception but got a deadlock.


    ..'bummer' (assuming that delayed the project more than 30 seconds).

    --
    Andrew Thompson
    http://www.athompson.info/andrew/

    Message posted via JavaKB.com
    http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1
    Andrew Thompson, Aug 6, 2007
    #14
  15. Guest

    > Is it? I have seen installers for Win. that curl
    > up and die with no clear error message.


    What in the name of God are you talking about?

    First of all, our app would not need an installer. Second, if you've
    seen installers fail (as more than a once-in-a-blue-moon anomaly), you
    need to stop buying your software from the bargain bin at the dollar
    store, and watch out for photocopied labels.

    > But that is starting to sound like your
    > app is not 'embedded' in a browser in any case.


    Yes, if I supply a link to a platform specific binary, the app will
    not be embedded in the browser. Thanks for pointing that out for the
    slower readers.

    > Can you make it work on that ol' 486 of mine?
    > I think it's running Win. 95. ;-)


    (1) Yes. If I distribute a Windows binary, it would be a pure Win32
    app, runnable on anything post 3.1 pretty much. It would not require
    an installer.
    (2) That's a moot point, because if you were running a 486, you
    wouldn't be using our product anyway (or much of anything else
    remotely modern, for that matter).
    (3) You seem to be trying really hard to make a point, but damned if I
    can tell what it is. Are we a few posts away from "Mac > PC"? I'm
    feeling that creepy alternate-reality vibe setting in.

    > My point was not about competing tech., but having (any) trusted app. within
    > a browser window, or 'coming at you' off the internet.


    Applications can be digitally signed. The signature can be verified by
    an independent certification authority. My users can be assured that
    the application comes from me, so trust is not the primary issue. The
    problem is making sure the binary has a platform to run on when it
    arrives.

    > I am relatively sure that D'n'D can be used in a
    > sandboxed JWS App., but have not checked it.


    It can. Unfortunately this has nothing, whatsoever, to do with my
    issue, as explained in detail above.

    Anyway, for debugging purposes I'm just signing the applet now. There
    are several annoyances associated with that, but nobody seems how to
    turn the sandbox off locally for any platform and I'm tired of dicking
    around with it.

    I'm going to target Java 1.1, which I hope will have the broadest
    compatibility. I can write my own GUI widgets if needed. Maybe I can
    find a way to statically link in a VM and distribute one-click
    platform-specific binaries, while still letting me maintain a single
    Java code base for the core application.

    Thanks for the help, anyhoo.

    Cheers,
    Eric
    , Aug 6, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ahmed Moustafa

    What is a sandbox?

    Ahmed Moustafa, Aug 23, 2003, in forum: Java
    Replies:
    1
    Views:
    395
    Roedy Green
    Aug 23, 2003
  2. Tim Tyler

    Application in sandbox

    Tim Tyler, Nov 27, 2004, in forum: Java
    Replies:
    24
    Views:
    912
    Intel Inside
    Dec 4, 2004
  3. Replies:
    4
    Views:
    454
    Roedy Green
    Sep 27, 2005
  4. Thomas G. Marshall
    Replies:
    6
    Views:
    429
    Thomas Hawtin
    Oct 20, 2005
  5. Axel Gallus

    Disabling Sandbox?

    Axel Gallus, Oct 3, 2006, in forum: Javascript
    Replies:
    1
    Views:
    75
Loading...

Share This Page