6 ms·

I work on this feature. Ask me anything.

by floil 9y ago

Kiro 9y ago
What are the drawbacks? Edit: Just saw Known Issues on the page.
lend000 9y ago
It says 'highly experimental.' Is it ready for prime-time, given the situation?
- floil 9y ago
  Personally, I have turned it on. The highly experimental language dates back for several years (I think there's been a patch to revise the wording). This mode is already launched for all extension content since mid 2017, so it is well exercised. I no longer consider it highly experimental. The things that we know don't with are listed on the originally linked page; memory usage surprised us by not being a worse regression than it was. The TLDR of site isolation is that the same origin policy is enforced at a process boundary, rather than relying on the rendering engine to keep the JavaScript contexts within a process (say, evil.com and its bank.com iframe) from accessing each other's memory. With site isolation on, we put the subframe in it's own process; the parent process can't, for example, read cookies for the child process's origin. This relates to the novel CPU vulnerabilities because, to quote the blog post today, "The primary ramification of Variant 1 is that it is difficult for a system to run untrusted code within a process and restrict what memory within the process the untrusted code can access." Site isolation was designed as a defense in depth against the type of renderer compromise that would give an attacker arbitrary code execution in the renderer process. Variant 1 gives attackers something weaker than that, so the protection works.
  - Etheryte 9y ago
    Given the above, when do you think this will become enabled by default?
    - floil 9y ago
      Sooner than it would have if Spectre hadn't happened. Spectre, in my view, really changes the cost/benefit considerations here. Wish I had a better timeline to share, but with stuff like printing not working properly, it's not an easy decision to just flip it on for everyone.
      - e40 9y ago
        but with stuff like printing not working properly Wait, it breaks printing? In what situations?
xg15 9y ago
Could you explain the point about not sending sensitive documents to a cross-origin process further? From my understanding, the mentioned MIME types were already protected by CORS (e.g., you can load a non-allowed cross-origin HTML document in an iframe, but then you won't get scripting access to it; If you try to get it directly via fetch or XHR, you cannot access the result) So what exactly changes for consumers of such documents?
- floil 9y ago
  Great question. Your intuitions are mostly right, in that the document blocking logic is related to CORS protection. In fact, when the document blocker sees a valid access-control-allow-origin header in a response, that's sufficient to allow it through. However, there are a couple reasons though why CORS alone is not enough. First, the CORS checks (the ones that generate console warnings when they fail) are done inside the renderer process -- meaning some of the response data has already arrived in the process, and may be available for exfiltration by an agent able to read that process's memory. Secondly, CORS only applies to cors-enabled requests (e.g. XHR and fetch). Our goal is to prevent, say, the HTML of your bank account details page or a similarly sensitive JSON-based API from arriving in any renderer process other than one dedicated to rendering pages for your bank's site. An attacker could point a script tag at the target resource -- script tags by default aren't required to go through the CORS dance (as an aside, <script crossorigin> exists, but I'm not entirely sure why). Since the attackers goal is just to cause the response to wind up in its renderer process memory, the attack still succeeds even if the JSON or HTML doesn't successfully execute as valid javascript. So we need something stronger, which runs outside the renderer process. The idea is to look for responses that would necessarily result in an error in the context of any legitimate cross-origin use case (other than fetch/xhr, where CORS dictates what's legal). We need to block HTML, but allow stylesheets, images, and scripts. The blocking logic is really based on the substance of the http response, rather than what the renderer says it's to be used for, since the renderer is untrusted in this scenario. JSON is a particular headache, since a subset of JSON is also valid javascript (dicts are syntax errors, but lists are we aren't), and as a result, JSON in the wild is often prefixed, and thus doesn't sniff as JSON. JSON also is often served with a JavaScript mime type. An important takeaway for website authors is to serve any JSON or HTML with the appropriate mime type and the nosniff header.
espadrine 9y ago
As webapp developers, does recommending our users to enable it give any meaningful protection for our website if we don't don't set Access-Control-Allow-Origin (or only set it to a star)?
- Ajedi32 9y ago
  > don't set Access-Control-Allow-Origin (or only set it to a star) Huh? These are two _very_ different situations. Not setting `Access-Control-Allow-Origin` would mean that no third party site can read data from your domain. Setting it to `*` would do the exact opposite, allowing any site to read data on the page. It's also unclear to me how this relates to Spectre and Meltdown.
  - espadrine 9y ago
    The Site Isolation page[0] states: > This protection is made possible by the following changes in Chrome's behavior: > […] > - Cross-site "documents" (specifically HTML, XML, and JSON files) are not delivered to a web page's process unless the server says it should be allowed (using CORS). I understand it to mean that the tab's process used to hold code that verified the CORS header, and that the verification is now out-of-process. [0]: http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio...
- floil 9y ago
  Setting it to star allows arbitrary cross origin access (star means 'any site' in this context). Omitting it is supposed to be the opposite. Important not to confuse the two! Enabling site per process in chrome will give your users some protection of their data on your site, but only if your mime types are already correct. See the probably linked document for recommended headers.
icefox 9y ago
In Chrome's implementation are the cache, cookiejar, and history all kept completely separate? For example if I go to foo.com and inside that it loads a facebook script in an iframe could it get all the normal facebook cookies or would it be blank? Which "site" would the iframe be? Back in the day (Around when I ported chrome to Linux for a time context) I wrote up a spec and implemented a browser that did site data compartmentalization. Data leaks from cookies, history and especially cache were not possible because the data just wasn't there to be leaked. It was a pretty cool design that along with per site settings and split view search was definitely ahead of its time. Alas I was forbidden from working on it by my employer at the time and have been watching for some of the features to appear in other browsers since. https://benjamin-meyer.blogspot.com/2009/08/next-generation-desktop-web-browser.html https://benjamin-meyer.blogspot.com/2009/08/next-generation-...
- floil 9y ago
  The three data sources you mention are kept in the browser process (which is the privileged singleton process that spawns the sandboxed child processes that actually parse and execute web content). However the child processes can query and mutate them (to support e.g document.cookie). Those JS apis do work in iframes. In your example, we would create a facebook.com subframe process separate from the foo.com process for the main document. You can see your example in action by enabling site isolation, visiting a page with a FB like button, and opening Chrome's task manager. You can even kill the subframe process, and it shouldn't take down the whole tab.
frik 9y ago
Does Chrome's software_reporter_tool.exe now consume all your CPU too, while you are afk?? Whatever this tool does, it does scan all my files and consumes a LOT of IO and CPU. I certainly don't need a file-scanner that wastes my battery nor power. It only starts automatically after a while when no one is logged in or the screensaver is running for some time - very sneaky indeed, that's why probably only a few every saw it. And it's installed in a very obscure location: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\SwReporter\24.137.203\software_reporter_tool.exe whereas Chrome is installed there: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe The only way to get rid of it seems to delete the fucking exe file every time. As this tip doesn't work: https://productforums.google.com/forum/#!topic/chrome/XCbMKkublMk;context-place=topicsearchin/chrome/category$3Awindows7%7Csort:relevance%7Cspell:false https://productforums.google.com/forum/#!topic/chrome/XCbMKk... Better stop this shit, can someone tell them do so please.

I work on this feature. Ask me anything.

by floil 9y ago

I work on this feature. Ask me anything.

Kiro 9y ago

What are the drawbacks? Edit: Just saw Known Issues on the page.

lend000 9y ago

It says 'highly experimental.' Is it ready for prime-time, given the situation?

floil 9y ago
Personally, I have turned it on. The highly experimental language dates back for several years (I think there's been a patch to revise the wording). This mode is already launched for all extension content since mid 2017, so it is well exercised. I no longer consider it highly experimental. The things that we know don't with are listed on the originally linked page; memory usage surprised us by not being a worse regression than it was. The TLDR of site isolation is that the same origin policy is enforced at a process boundary, rather than relying on the rendering engine to keep the JavaScript contexts within a process (say, evil.com and its bank.com iframe) from accessing each other's memory. With site isolation on, we put the subframe in it's own process; the parent process can't, for example, read cookies for the child process's origin. This relates to the novel CPU vulnerabilities because, to quote the blog post today, "The primary ramification of Variant 1 is that it is difficult for a system to run untrusted code within a process and restrict what memory within the process the untrusted code can access." Site isolation was designed as a defense in depth against the type of renderer compromise that would give an attacker arbitrary code execution in the renderer process. Variant 1 gives attackers something weaker than that, so the protection works.
- Etheryte 9y ago
  Given the above, when do you think this will become enabled by default?
  - floil 9y ago
    Sooner than it would have if Spectre hadn't happened. Spectre, in my view, really changes the cost/benefit considerations here. Wish I had a better timeline to share, but with stuff like printing not working properly, it's not an easy decision to just flip it on for everyone.
    - e40 9y ago
      but with stuff like printing not working properly Wait, it breaks printing? In what situations?

xg15 9y ago

Could you explain the point about not sending sensitive documents to a cross-origin process further? From my understanding, the mentioned MIME types were already protected by CORS (e.g., you can load a non-allowed cross-origin HTML document in an iframe, but then you won't get scripting access to it; If you try to get it directly via fetch or XHR, you cannot access the result) So what exactly changes for consumers of such documents?

floil 9y ago
Great question. Your intuitions are mostly right, in that the document blocking logic is related to CORS protection. In fact, when the document blocker sees a valid access-control-allow-origin header in a response, that's sufficient to allow it through. However, there are a couple reasons though why CORS alone is not enough. First, the CORS checks (the ones that generate console warnings when they fail) are done inside the renderer process -- meaning some of the response data has already arrived in the process, and may be available for exfiltration by an agent able to read that process's memory. Secondly, CORS only applies to cors-enabled requests (e.g. XHR and fetch). Our goal is to prevent, say, the HTML of your bank account details page or a similarly sensitive JSON-based API from arriving in any renderer process other than one dedicated to rendering pages for your bank's site. An attacker could point a script tag at the target resource -- script tags by default aren't required to go through the CORS dance (as an aside, <script crossorigin> exists, but I'm not entirely sure why). Since the attackers goal is just to cause the response to wind up in its renderer process memory, the attack still succeeds even if the JSON or HTML doesn't successfully execute as valid javascript. So we need something stronger, which runs outside the renderer process. The idea is to look for responses that would necessarily result in an error in the context of any legitimate cross-origin use case (other than fetch/xhr, where CORS dictates what's legal). We need to block HTML, but allow stylesheets, images, and scripts. The blocking logic is really based on the substance of the http response, rather than what the renderer says it's to be used for, since the renderer is untrusted in this scenario. JSON is a particular headache, since a subset of JSON is also valid javascript (dicts are syntax errors, but lists are we aren't), and as a result, JSON in the wild is often prefixed, and thus doesn't sniff as JSON. JSON also is often served with a JavaScript mime type. An important takeaway for website authors is to serve any JSON or HTML with the appropriate mime type and the nosniff header.

espadrine 9y ago

As webapp developers, does recommending our users to enable it give any meaningful protection for our website if we don't don't set Access-Control-Allow-Origin (or only set it to a star)?

Ajedi32 9y ago
> don't set Access-Control-Allow-Origin (or only set it to a star) Huh? These are two _very_ different situations. Not setting `Access-Control-Allow-Origin` would mean that no third party site can read data from your domain. Setting it to `*` would do the exact opposite, allowing any site to read data on the page. It's also unclear to me how this relates to Spectre and Meltdown.
- espadrine 9y ago
  The Site Isolation page[0] states: > This protection is made possible by the following changes in Chrome's behavior: > […] > - Cross-site "documents" (specifically HTML, XML, and JSON files) are not delivered to a web page's process unless the server says it should be allowed (using CORS). I understand it to mean that the tab's process used to hold code that verified the CORS header, and that the verification is now out-of-process. [0]: http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio...
floil 9y ago
Setting it to star allows arbitrary cross origin access (star means 'any site' in this context). Omitting it is supposed to be the opposite. Important not to confuse the two! Enabling site per process in chrome will give your users some protection of their data on your site, but only if your mime types are already correct. See the probably linked document for recommended headers.

icefox 9y ago

In Chrome's implementation are the cache, cookiejar, and history all kept completely separate? For example if I go to foo.com and inside that it loads a facebook script in an iframe could it get all the normal facebook cookies or would it be blank? Which "site" would the iframe be? Back in the day (Around when I ported chrome to Linux for a time context) I wrote up a spec and implemented a browser that did site data compartmentalization. Data leaks from cookies, history and especially cache were not possible because the data just wasn't there to be leaked. It was a pretty cool design that along with per site settings and split view search was definitely ahead of its time. Alas I was forbidden from working on it by my employer at the time and have been watching for some of the features to appear in other browsers since. https://benjamin-meyer.blogspot.com/2009/08/next-generation-desktop-web-browser.html https://benjamin-meyer.blogspot.com/2009/08/next-generation-...

floil 9y ago
The three data sources you mention are kept in the browser process (which is the privileged singleton process that spawns the sandboxed child processes that actually parse and execute web content). However the child processes can query and mutate them (to support e.g document.cookie). Those JS apis do work in iframes. In your example, we would create a facebook.com subframe process separate from the foo.com process for the main document. You can see your example in action by enabling site isolation, visiting a page with a FB like button, and opening Chrome's task manager. You can even kill the subframe process, and it shouldn't take down the whole tab.

frik 9y ago

Does Chrome's software_reporter_tool.exe now consume all your CPU too, while you are afk?? Whatever this tool does, it does scan all my files and consumes a LOT of IO and CPU. I certainly don't need a file-scanner that wastes my battery nor power. It only starts automatically after a while when no one is logged in or the screensaver is running for some time - very sneaky indeed, that's why probably only a few every saw it. And it's installed in a very obscure location: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\SwReporter\24.137.203\software_reporter_tool.exe whereas Chrome is installed there: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe The only way to get rid of it seems to delete the fucking exe file every time. As this tip doesn't work: https://productforums.google.com/forum/#!topic/chrome/XCbMKkublMk;context-place=topicsearchin/chrome/category$3Awindows7%7Csort:relevance%7Cspell:false https://productforums.google.com/forum/#!topic/chrome/XCbMKk... Better stop this shit, can someone tell them do so please.