5 ms·

They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and

by logn 12y ago

They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and enterprise policy to allow localhost. Also this is preferred way to communicate with localhost: https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging

jorangreef 12y ago
Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.
- logn 12y ago
  I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c32 https://code.google.com/p/chromium/issues/detail?id=378566#c...
dvirsky 12y ago
Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.
- jorangreef 12y ago
  Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.
  - dvirsky 12y ago
    Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?
    - jorangreef 12y ago
      Not likely, as I think it will be blocked in the same way that mixed content is blocked (whether CORS is allowed or not). I think the plan is just to cut off access to localhost entirely whether intentioned or not, because WSS already has an Origin header which functions similarly to CORS when the client is a browser.
      - dvirsky 12y ago
        what I meant was that I think allowing CORS or a similar mechanism is probably enough, and breaking apps like Dropbox is not a great idea, even if there is a non standard mechanism to override it.
        jorangreef 12y ago
        Yes I agree, and WSS already has that mechanism in place. A similar point was also raised in the issues thread but has not been responded to.
        justinschuh 12y ago
        As I explained elsewhere, the origin header in WS(S) allows a server to overtly protect itself from a client. Unlike CORS, it doesn't allow the browser to make security decisions regarding requests, and so would not address any of the attacks we're trying to prevent.
    - justinschuh 12y ago
      Potentially, yes, and it's one of the ways we're looking at addressing per-page opt-in.
  - 12y ago
graycat 12y ago
Sorry, but I didn't find "sub-resources" in my Webster's. Could we please have a definition or a link to a definition? In general in documentation for computing, or other technical documentation, or any serious writing on any subject, we should avoid undefined terminology. Sorry to be critical, but computer security is a serious subject; since all it takes is one little gap to have a terrible computer virus infection, we need to be quite clear right down to the level of each little issue, quite clear and explicit. So far this year, I've spent over half my time fighting viruses. Bummer.
- justinschuh 12y ago
  A subresource is basically additional content that a page includes via a URL (e.g. script, iframe, images). The problem underlying this is that any page on the web can currently probe and then attack devices and servers on your internal network or local host. So, the proposal is to block that by preventing remote websites from navigating to or including sub-resources from anything on your internal network or local host (unless some explicit opt-in or exception is configured).
justinschuh 12y ago
We'd be blocking sub-resources and navigation from web to private. Of course, direct navigation via a bookmark or the omnibox would still work. And navigation or resource inclusion from private to the web would still work. As I explained in another comment, we're also working on exception mechanisms (including per-page opt-in, possibly via CORS) to cover the valid use cases.
- atomi 12y ago
  Some of us still use tiddlywiki. Make sure that still works.

by logn 12y ago

jorangreef 12y ago

Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.

logn 12y ago
I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c32 https://code.google.com/p/chromium/issues/detail?id=378566#c...

dvirsky 12y ago

Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.

jorangreef 12y ago
Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.
- dvirsky 12y ago
  Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?
  - jorangreef 12y ago
    Not likely, as I think it will be blocked in the same way that mixed content is blocked (whether CORS is allowed or not). I think the plan is just to cut off access to localhost entirely whether intentioned or not, because WSS already has an Origin header which functions similarly to CORS when the client is a browser.
    - dvirsky 12y ago
      what I meant was that I think allowing CORS or a similar mechanism is probably enough, and breaking apps like Dropbox is not a great idea, even if there is a non standard mechanism to override it.
      - jorangreef 12y ago
        Yes I agree, and WSS already has that mechanism in place. A similar point was also raised in the issues thread but has not been responded to.
        justinschuh 12y ago
        As I explained elsewhere, the origin header in WS(S) allows a server to overtly protect itself from a client. Unlike CORS, it doesn't allow the browser to make security decisions regarding requests, and so would not address any of the attacks we're trying to prevent.
  - justinschuh 12y ago
    Potentially, yes, and it's one of the ways we're looking at addressing per-page opt-in.
- 12y ago

graycat 12y ago

Sorry, but I didn't find "sub-resources" in my Webster's. Could we please have a definition or a link to a definition? In general in documentation for computing, or other technical documentation, or any serious writing on any subject, we should avoid undefined terminology. Sorry to be critical, but computer security is a serious subject; since all it takes is one little gap to have a terrible computer virus infection, we need to be quite clear right down to the level of each little issue, quite clear and explicit. So far this year, I've spent over half my time fighting viruses. Bummer.

justinschuh 12y ago
A subresource is basically additional content that a page includes via a URL (e.g. script, iframe, images). The problem underlying this is that any page on the web can currently probe and then attack devices and servers on your internal network or local host. So, the proposal is to block that by preventing remote websites from navigating to or including sub-resources from anything on your internal network or local host (unless some explicit opt-in or exception is configured).

justinschuh 12y ago

We'd be blocking sub-resources and navigation from web to private. Of course, direct navigation via a bookmark or the omnibox would still work. And navigation or resource inclusion from private to the web would still work. As I explained in another comment, we're also working on exception mechanisms (including per-page opt-in, possibly via CORS) to cover the valid use cases.

atomi 12y ago
Some of us still use tiddlywiki. Make sure that still works.