<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2014-05-15 11:59, Kis, Zoltan wrote:<br>
    </div>
    <blockquote
cite="mid:CANrNqUdsEt24_mh9zfTy_bBqo3WUZZaG9N7nT9yuj-oy-AH2jg@mail.gmail.com"
      type="cite">
      <pre wrap="">On Thu, May 15, 2014 at 11:55 AM, Zhang, Xu U <a class="moz-txt-link-rfc2396E" href="mailto:xu.u.zhang@intel.com"><xu.u.zhang@intel.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">[Zhang Xu ] Patrick, Bai (who has left Intel) and I have designed crosswalk API permission control. The doc is here <a class="moz-txt-link-freetext" href="https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit">https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit</a>
</pre>
      </blockquote>
      <pre wrap="">
I think that's a good/flexible design. App process invokes an API
function. The renderer process (RP) sends a message to the extension
process (EP), which checks whether permission is granted. On need the
browser process (BP) pops up a user dialog.

</pre>
      <blockquote type="cite">
        <pre wrap="">and the implementation is done. I am informed that all web device APIs implementation should use Cynara’s service API directly. So the design will be dropped from web runtime side.
I will implement crosswalk runtime security issues.
</pre>
      </blockquote>
      <pre wrap="">
Here we have options.

A. Security (service) proxy is the only enforcement point. Dominig's proposal.
In this case the EP is totally transparent and inherits the app identity.
We need to solve how the browser process will know to pop up a user
dialog for permissions.
Also, all API's that are accessed by the web runtime need to be
exposed by the service proxy, which is a huge work with huge delay.

B. There may be multiple enforcement points (EP, dbus-daemon,
service-proxy). This allows direct DBUS access from apps, and in the
rest works like in A. Sub-options:
1.) EP is also enforcement point, and part of the system. Then, EP
checks if access is allowed, either by
a) asking Cynara, or
b) EP caches policy data from Cynara (with an update/sync mechanism
for that data) and makes a local decision, which is much faster than
a).</pre>
    </blockquote>
    <br>
    Minor note: B1b would not be faster than B1a, it would only add
    overhead. Cynara will provide a library (libcynara-client) for
    access checks and it will already implement caching. On cache hit in
    libcynara-client it won't contact the Cynara daemon, but just return
    cached value. Cache flushing should also be transparent for Cynara
    users.<font face="Arial"><br>
    </font>
    <div style="bottom: auto; left: 112px; right: auto; top: 89px;
      display: none;" class="translator-theme-default"
      id="translator-floating-panel"> </div>
  </body>
</html>