4 ms·

> relegating them to second-class status That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the

by pdkl95 11y ago

> relegating them to second-class status That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead. > Reading/writing arbitrary files to the file system. Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice. Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.

wtbob 11y ago
> "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. You're right that it's insanity to allow a web app to spoof the native UI. But extensions aren't web apps: they are native (or should be). Extensions are extensions to the browser: they're what can actually provide secure crypto and privacy.
the8472 11y ago
> Are you trying to open up a massive security hole? Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself. Firefox components can obviously access the filesystem. So can extensions. An extension in itself is not any more a security hole than firefox itself. > Seriously, stop treating the browser as the OS+desktop. While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities. If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser. But that just addresses the "app" kind of extension. Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.
- dingaling 11y ago
  > Firefox components can obviously access the filesystem. Which is a hole that should be plugged. Beyond its home subdirectory and a tmpfs Downloads location an Internet-connected browser should be prevented from writing anywhere. Bonus points for preventing read access to non-runtume locations too. Not only prevent bad data from coming in but prevent good data from being sucked out.
  - simonster 11y ago
    Sandboxing extensions' access to the file system would be acceptable. We could work with that, just as OS X app developers have. But Chrome and the current WebExtensions API don't allow extensions any file system access beyond what webpages get.

by pdkl95 11y ago

wtbob 11y ago

> "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. You're right that it's insanity to allow a web app to spoof the native UI. But extensions aren't web apps: they are native (or should be). Extensions are extensions to the browser: they're what can actually provide secure crypto and privacy.

the8472 11y ago

> Are you trying to open up a massive security hole? Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself. Firefox components can obviously access the filesystem. So can extensions. An extension in itself is not any more a security hole than firefox itself. > Seriously, stop treating the browser as the OS+desktop. While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities. If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser. But that just addresses the "app" kind of extension. Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.

dingaling 11y ago
> Firefox components can obviously access the filesystem. Which is a hole that should be plugged. Beyond its home subdirectory and a tmpfs Downloads location an Internet-connected browser should be prevented from writing anywhere. Bonus points for preventing read access to non-runtume locations too. Not only prevent bad data from coming in but prevent good data from being sucked out.
- simonster 11y ago
  Sandboxing extensions' access to the file system would be acceptable. We could work with that, just as OS X app developers have. But Chrome and the current WebExtensions API don't allow extensions any file system access beyond what webpages get.