ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

Public bug reported:

Spun off from bug 1347892 (in particular, see
https://bugs.launchpad.net/oxide/+bug/1347892/comments/8):

Local applications are currently loaded via file:/// URLs, but this
presents some issues:

- Chromium considers all unique file paths as a different domain. Bug
1347892 was originally reported because a local application can't render
an image in to a canvas without marking it origin-unclean (which means,
it can't read the pixels back). There is a WebPreferences API to disable
this security feature, but it puts all file:/// URLs in to the same
origin which is sub-optimal. And we shouldn't require application
developers to rely on a dangerous API by default.

- The Filesystem API is disabled for file:/// URL's, and we shouldn't
think about enabling that. Origin separation for local storage when
using file URL's is pretty broken in any case.

What I've been thinking about is having "application bundles" in Oxide.
Applications would be accessed via application:// URL's, with each
registered application having its own domain (eg, accessing index.html
in application "foo" would be done by application://foo/index.html).
Underneath, each application domain would map to a directory on the
filesystem.

This type of scheme would mean we can properly enforce domain separation
between applications (so, local storage can be used) and it would fix
bug 1347892 too without having to rely on dangerous APIs

** Affects: oxide
     Importance: High
         Status: Triaged

** Changed in: oxide
   Importance: Undecided => High

** Changed in: oxide
       Status: New => Triaged

** Changed in: oxide
    Milestone: None => branch-1.6

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1410919

Title:
  Add support for local app bundles

Status in Oxide Webview:
  Triaged

Bug description:
  Spun off from bug 1347892 (in particular, see
  https://bugs.launchpad.net/oxide/+bug/1347892/comments/8):

  Local applications are currently loaded via file:/// URLs, but this
  presents some issues:

  - Chromium considers all unique file paths as a different domain. Bug
  1347892 was originally reported because a local application can't
  render an image in to a canvas without marking it origin-unclean
  (which means, it can't read the pixels back). There is a
  WebPreferences API to disable this security feature, but it puts all
  file:/// URLs in to the same origin which is sub-optimal. And we
  shouldn't require application developers to rely on a dangerous API by
  default.

  - The Filesystem API is disabled for file:/// URL's, and we shouldn't
  think about enabling that. Origin separation for local storage when
  using file URL's is pretty broken in any case.

  What I've been thinking about is having "application bundles" in
  Oxide. Applications would be accessed via application:// URL's, with
  each registered application having its own domain (eg, accessing
  index.html in application "foo" would be done by
  application://foo/index.html). Underneath, each application domain
  would map to a directory on the filesystem.

  This type of scheme would mean we can properly enforce domain
  separation between applications (so, local storage can be used) and it
  would fix bug 1347892 too without having to rely on dangerous APIs

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1410919/+subscriptions