8 ms·

IMO, the approach taken by Chrome and other browsers is over restrictive, basically killing off the file:// protocol. Already now it's impossible to load wasm f

by est31 7y ago

IMO, the approach taken by Chrome and other browsers is over restrictive, basically killing off the file:// protocol. Already now it's impossible to load wasm files in the file:// protocol in Chrome, and I think this also had implications on using wasm in electon. Ultimately, file:// is a great, cloud free method of having web pages and applications and it should stay that way instead of forcing everything to be networked and reliant on third party computers or domain names. There are so many reports, documents, etc that live as non-networked html files. E.g. rust documentation (cargo doc --open) is generated as html files on-disk and then just displayed without the need for a webserver. Starting a localhost webserver is in fact less secure than file because now every user on the computer has access instead of just the users with read-access to the files. This has thankfully been fixed in Chrome OS though. Responsive web apps are not the solution as they still need "seeding" via the network. Maybe some kind of standardized format where you have a glorified zip file with some metadata and when you double click it, it opens in the web browser which starts a web server in the background that runs a specially designated js in that zip file and which can accept usual fetch requests and has read access to the entire zip file. The browser's "UI" would then communicate with the server via well-known protocols.

kevingadd 7y ago
It ends up definitely being a tax on developer efficiency overall. It also makes web development more hostile to newbies because they have to figure out how to configure a server or hop into some third-party toolset on the web to start experimenting. With the tendency to ban use of new features on non-HTTPS origins (hi again, Chrome) a newbie developer will soon have to have both a server and a https cert before they can even start experimenting. If they host on a third-party https domain now third parties are responsible for malware that might get hosted there. It just sucks.
- codedokode 7y ago
  Regarding HTTPS, localhost is considered a "secure" origin: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#When_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
deleted 7y ago
[deleted]
souterrain 7y ago
What are your thoughts on file:// URLs being opened/executed in a separate enclave from the network, with no access to the network? This would allow the convenience of file:// and IMHO eliminate many if not all of the risks.
- codedokode 7y ago
  This won't allow to load images, files from CDN etc.
  - souterrain 7y ago
    Correct. IMHO accessing the local filesystem is incompatible with accessing the network from a security standpoint. I’m fine with having a very clear toggle to allow this behavior for developer types, but this should default to secure.
    - dTal 7y ago
      I think this summarizes the issue and is exactly the correct solution. There's a lot of the comments along the lines of "just run python -m SimpleHTTPServer" - but doing that makes your computer just as vulnerable as allowing file:// in the first place, in theory. It's only the very awkwardness of doing that that makes it any safer. Instead of hiding this fundamental incompatibility between security and local accessibility behind a layer of inconvenience, better to drag it out into the open and label it and fully support it. While you're at it, you can slacken off some of the other restrictions in "local mode" as well. A browser is the modern VM, for better or worse. It should function locally, standalone.
- est31 7y ago
  It would improve security, but ultimately as long as the file "enclave" can execute javascript, it has access to enough side channels to communicate any data it collects to the outside, so I guess the security concerns wouldn't be fully resolved.
  - 7y ago
codedokode 7y ago
> I think this also had implications on using wasm in electon It should not. Electron runtime is not a browser and developer can tweak its security settings. I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. For example: file some-page.html and directory some-page_files.
- est31 7y ago
  > It should not. Electron runtime is not a browser and developer can tweak its security settings. Yes, that's what I meant. Sure you can override chromium, but you have to. https://github.com/adamvoss/electron-webassembly-hello/commit/0c62e5b69f65fd6ba0dabd4bf9dc4b9c9bfc6dfb https://github.com/adamvoss/electron-webassembly-hello/commi... > I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. That would certainly help. It would restrict some multi-html-file projects a bit though that use shared resources. Probably can be helped by having a folder named html-fetchable-files or something.
mort96 7y ago
Learning web programming is amazing, since you can just start writing a .html file and open it in a browser. There is no need to learn how go set up a local http server. Chrome truly is killing that experience; you can't even load javascript modules without http involved now outside of Firefox. I really hope Mozilla doesn't "fix" this "vulnerability" by destroying the experience of people learning web programming like Google did.
- deleted 7y ago
  [deleted]
- majewsky 7y ago
  Is it really that hard to run `python -m http.server` in your repository?
  - CaptainMarvel 7y ago
    For someone getting started with programming? Very hard - it steepens the learning curve significantly
    - ASalazarMX 7y ago
      This. It's not only "open Notepad and save this text file, then open it in the browser". Leave the complexity of learning what Python is, the 2 vs 3 issue, 32/64 bit versions, appending locations to your path, CLI, etc., for when the user is ready to start with dynamic web pages.
      - JetSpiegel 7y ago
        Luckly, the modern Python installers for Windows do all that.
  - MrGilbert 7y ago
    Why should I install Python, if I want to do a bit of JavaScript? That's not really the point. Of course it's not complicated to setup XAMPP, LAMPP or whatever.
Risord 7y ago
This case makes me wonder what if traditional filesystems would not separate files and directories. So that there would be just files which may have data and sub files. Then html file could include all js files etc. directly inside it so that we could give multi file permissions without leaking it to siblings.
- progval 7y ago
  The feature you are looking for already partially exists. Look for "extended attributes" (for most filesystems) or "alternate data streams" (for NTFS). But in this case, it's much simpler to make a tar or a zip with the HTML and all necessary files. eg. that's how Python "eggs" work.

by est31 7y ago

kevingadd 7y ago

It ends up definitely being a tax on developer efficiency overall. It also makes web development more hostile to newbies because they have to figure out how to configure a server or hop into some third-party toolset on the web to start experimenting. With the tendency to ban use of new features on non-HTTPS origins (hi again, Chrome) a newbie developer will soon have to have both a server and a https cert before they can even start experimenting. If they host on a third-party https domain now third parties are responsible for malware that might get hosted there. It just sucks.

codedokode 7y ago
Regarding HTTPS, localhost is considered a "secure" origin: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#When_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

deleted 7y ago

[deleted]

souterrain 7y ago

What are your thoughts on file:// URLs being opened/executed in a separate enclave from the network, with no access to the network? This would allow the convenience of file:// and IMHO eliminate many if not all of the risks.

codedokode 7y ago
This won't allow to load images, files from CDN etc.
- souterrain 7y ago
  Correct. IMHO accessing the local filesystem is incompatible with accessing the network from a security standpoint. I’m fine with having a very clear toggle to allow this behavior for developer types, but this should default to secure.
  - dTal 7y ago
    I think this summarizes the issue and is exactly the correct solution. There's a lot of the comments along the lines of "just run python -m SimpleHTTPServer" - but doing that makes your computer just as vulnerable as allowing file:// in the first place, in theory. It's only the very awkwardness of doing that that makes it any safer. Instead of hiding this fundamental incompatibility between security and local accessibility behind a layer of inconvenience, better to drag it out into the open and label it and fully support it. While you're at it, you can slacken off some of the other restrictions in "local mode" as well. A browser is the modern VM, for better or worse. It should function locally, standalone.
est31 7y ago
It would improve security, but ultimately as long as the file "enclave" can execute javascript, it has access to enough side channels to communicate any data it collects to the outside, so I guess the security concerns wouldn't be fully resolved.
- 7y ago

codedokode 7y ago

> I think this also had implications on using wasm in electon It should not. Electron runtime is not a browser and developer can tweak its security settings. I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. For example: file some-page.html and directory some-page_files.

est31 7y ago
> It should not. Electron runtime is not a browser and developer can tweak its security settings. Yes, that's what I meant. Sure you can override chromium, but you have to. https://github.com/adamvoss/electron-webassembly-hello/commit/0c62e5b69f65fd6ba0dabd4bf9dc4b9c9bfc6dfb https://github.com/adamvoss/electron-webassembly-hello/commi... > I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. That would certainly help. It would restrict some multi-html-file projects a bit though that use shared resources. Probably can be helped by having a folder named html-fetchable-files or something.

mort96 7y ago

Learning web programming is amazing, since you can just start writing a .html file and open it in a browser. There is no need to learn how go set up a local http server. Chrome truly is killing that experience; you can't even load javascript modules without http involved now outside of Firefox. I really hope Mozilla doesn't "fix" this "vulnerability" by destroying the experience of people learning web programming like Google did.

deleted 7y ago
[deleted]
majewsky 7y ago
Is it really that hard to run `python -m http.server` in your repository?
- CaptainMarvel 7y ago
  For someone getting started with programming? Very hard - it steepens the learning curve significantly
  - ASalazarMX 7y ago
    This. It's not only "open Notepad and save this text file, then open it in the browser". Leave the complexity of learning what Python is, the 2 vs 3 issue, 32/64 bit versions, appending locations to your path, CLI, etc., for when the user is ready to start with dynamic web pages.
    - JetSpiegel 7y ago
      Luckly, the modern Python installers for Windows do all that.
- MrGilbert 7y ago
  Why should I install Python, if I want to do a bit of JavaScript? That's not really the point. Of course it's not complicated to setup XAMPP, LAMPP or whatever.

Risord 7y ago

This case makes me wonder what if traditional filesystems would not separate files and directories. So that there would be just files which may have data and sub files. Then html file could include all js files etc. directly inside it so that we could give multi file permissions without leaking it to siblings.

progval 7y ago
The feature you are looking for already partially exists. Look for "extended attributes" (for most filesystems) or "alternate data streams" (for NTFS). But in this case, it's much simpler to make a tar or a zip with the HTML and all necessary files. eg. that's how Python "eggs" work.