<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 19-05-2016 13:47, Petri Hintukainen
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1463658424.3456.102.camel@users.sourceforge.net"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I don't think you should do any translating mouse button to key
events.
Xlet developers should implement their own mouse-capture methods
using 
java.awt.event.MouseListener and java.awt.event.MouseMotionListener.
</pre>
      </blockquote>
      <pre wrap="">
The problem is I don't know any BD-J Xlet (from BD disc) that would
support mouse. Still, being able to control BD-J menus with mouse-like
device would be great (I'm thinking about touch screens / tablets).
Maybe we could translate mouse events when Xlet does not consume those.</pre>
    </blockquote>
    <br>
    All I know is that textbooks are encouraging Xlet developers to
    implement mouse support in their Xlets.<br>
    <br>
    From The HD Cookbook, page 19-1: "BD-J User Input":<br>
    "After the remote control, a mouse is the second most likely input
    device to be used. Mice are not very common with living room players
    today, but they are almost always present in computer players. For
    this reason, your title should be capable of accepting mouse input,
    but the user interface should be primarily designed for remote
    control input."<br>
    <br>
    In my humble opinion, if you wish to add some extra mouse support
    for discs that hasn't implemented mouse support, you could create a
    virtual remote control that you can click with the mouse.<br>
    (This approach is also used in the old XleTView
    (<a class="moz-txt-link-freetext" href="http://www.interactivetvweb.org/tutorials/getting_started/xletview/running_applications">http://www.interactivetvweb.org/tutorials/getting_started/xletview/running_applications</a>),
    and I believe Leawo Blu-ray player also does it that way).<br>
    <br>
    <blockquote
      cite="mid:1463658424.3456.102.camel@users.sourceforge.net"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">Yes, networking works fine in the 3 hardware players I have online
(a 
Sony BDP-S1100, a Samsung something and a Dune HD Smart D1) and also 
PowerDVD software player.

In my Xlets I'm doing a simple HTTP request to check for version of
my 
disc. I can see that this isn't going through in VLC.
</pre>
      </blockquote>
      <pre wrap="">
Most likely security manager is missing some checks (URLPermission ?).
Should be fixed soon (when git is up again).

If there are other problems, maybe you could provide a sample BD image
for testing ? Even better if it could be used to test mouse events too
:)</pre>
    </blockquote>
    <br>
    I'll look into creating a sample Xlet for testing purposes. But I
    have way too much going on around me at the moment, so it'll take a
    while.<br>
    <br>
    <blockquote
      cite="mid:1463658424.3456.102.camel@users.sourceforge.net"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I was under the impression that AACS is related to video only and has
nothing to do with signing.
</pre>
      </blockquote>
      <pre wrap="">
I think AACS is required to verify the signature chain. BD-J root
certificate hash is stored in AACS content certificate (which is signed
by AACS LA public key). So, without AACS BD-J signatures are more or
less useless.</pre>
    </blockquote>
    <br>
    Hm, well, I don't know anything about AACS.<br>
    According to The HD Cookbook, AACS is mandatory for Blu-ray Discs.
    Yet, the homebrew discs I'm producing definitely doesn't have AACS -
    and they run on all the players I've tested on (22 hardware players
    and a few commercial software players).<br>
    So it's not true that it's mandatory.<br>
    What I think they mean is that any <b>official</b> Blu-ray Disc,
    i.e. one that has a registered disc number, and has gone through the
    official replication process at one of the approved replicators - <b>they</b>
    have to have AACS. That's my guess.<br>
    But any player should (and do apparently) play Blu-ray Discs that
    doesn't have AACS.<br>
    I have not come across a single player yet that wouldn't play my
    self-signed Xlet.<br>
    <br>
    <blockquote
      cite="mid:1463658424.3456.102.camel@users.sourceforge.net"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">It is true that networking requires the Xlet to be signed, according
to the specs. This is a bit silly though, because signing an Xlet is
no trouble at all and doesn't require any special expensive
certificate (as is the case with signing MIDlets).
</pre>
      </blockquote>
      <pre wrap="">
Well, that wouldn't make any sense. Signature that can't be verified is
useless ...</pre>
    </blockquote>
    <br>
    I see your point.<br>
    But as I said, all players I've tested on seems to accept anything I
    throw at them, with my self-signed Xlet.<br>
    Maybe because Xlet developers need to be able to test their Xlets on
    real devices?<br>
    <br>
    <blockquote
      cite="mid:1463658424.3456.102.camel@users.sourceforge.net"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">But yes, my Xlets are signed. :-)

Since anyone can sign an Xlet without much trouble, I'm not sure it's
worth the effort making sure VLC doesn't allow networking if the Xlet
isn't signed - unless of course it's the aim that VLC becomes a 
trustworthy tool for Xlet developers for testing their Xlets.
</pre>
      </blockquote>
      <pre wrap="">
Most users see BD disc images as "media files", not applications, and
play those even if those are from untrusted source. So, I don't think
BD-J security issues should be taken lightly.

Ideally networking would be an option that user can toggle on/off. I'm
sure some users would like to disable all BD-J network access.

Maybe we could ask user if networking should be allowed when unsigned Xlet tries to access network. Or issue a warning when Xlet is from "untrusted" source.</pre>
    </blockquote>
    <br>
    That's <b>probably</b> what all players <b>should</b> have done
    yes. I can't explain why they don't.<br>
    However, it should also be put in perspective I think. I mean, it
    made sense for MIDlets to give these security popups, because
    sending SMS or going online or making phone-calls costs money.<br>
    But displaying a warning because a Blu-ray disc wants to make an
    online call, I don't see the point in that in this age where
    everything else is online. JavaME being the sandbox it is, shouldn't
    really be able to cause any trouble either.<br>
    <br>
    I see no problem adding a "View offline" option when opening the
    disc though. Just like there's a "No blu-ray menu" option.<br>
    <br>
    <br>
    - Roald<br>
  </body>
</html>