Re: [webappsec] Rechartering: Sub-Origins

+jww, lcamtuf

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Mon, Nov 10, 2014 at 1:04 PM, David Bruant <bruant.d@gmail.com> wrote:

> I believe this is a bad idea.
>
> Background :
> http://www.infoq.com/presentations/Secure-Distributed-Programming
> Especially the first 8 minutes and the comparison with Astronomy.
> In my opinion, introducing sub-origins is another layer of "circles on
> circles on circles".
>
> "Currently, web applications are almost always compartmentalized by using
> separate host names to establish separate web origins."
> => In the other side of the "almost" stands Caja [1] and other tooling
> that enables isolation of untrusted code within the same domain.
> It works. Today. But it's somewhat impractical because of performance
> concerns (Caja added runtime checks to ES3 code to enforce some
> properties). But the Caja team via Mark Miller (cc'ed) provided feedback to
> TC39 (he's part of it) which in turn helped shape ES5 and ES6 to make
> JavaScript a language where it's practical to isolate code.
> ES6 with proxies and weakmap enable to fully isolate untrusted code within
> a membrane with marginal performance losses (which can certainly be reduced
> to a point we cannot grasp yet as pretty much only Firefox implemented
> proxies, so they're not used yet in the wild so optimization work has been
> minimal).
> Proxies are a reality in implementors agreement and in the ES6 spec that
> is being written. They are in development in IE [2].
>
> "Sandboxed frames can be used to completely separate untrusted content,
> but they pose a large problem for containing trusted but potentially buggy
> code because it is very difficult, by design, for them to communicate with
> other frames."
> => Buggy code is hard to communicate with regardless of sandboxed iframes.
> I'm not sure platform features should be added to work around buggy code.
> At that rate, I'd love if the browser engineers came fix my code for me :-)
>
>
> "The synthetic origins assigned in a sandboxed frame are random and
> unpredictable, making the use of postMessage and CORS difficult."
> => how so? How is postMessage affected by sandboxed iframes?
>
>
> "Sandboxed Frames and Content Security Policy (CSP). Both are powerful but
> have shortcomings and there are many external developers building legacy
> applications that find they cannot use those tools."
> "Content Security Policy is also promising but is generally incompatible
> with current website design. Many notable companies found it impractical to
> retrofit most of their applications with it."
> => Should the web platform suffer a change only because "Many notable
> companies" don't care to prioritize their development to secure their
> application?
> Will the feature be relevant even when these legacy systems go away?
>
>
> At this point, we know that proxies are a future answer to the code
> isolation problem. We don't know yep if sub-origins are agreed upon by
> enough browsers to ever become a practical solution.
> I'd really prefer if time was spent on solutions based on features we know
> will happen.
>
> David
>
> [1] https://code.google.com/p/google-caja/
> [2] https://status.modern.ie/?term=proxies
>
> Le 10/11/2014 01:04, Brad Hill a écrit :
>
>  Rechartering Thread 5: Sub-Origins
>>
>> Based on our survey results and discussion at TPAC, there is strong
>> consensus for supporting work on a sub-origin proposal based on the
>> following input document:
>>
>> http://www.chromium.org/developers/design-documents/per-page-suborigins
>>
>> Joel Weinberger would be editor.
>>
>> Please reply to this thread if you would like to or express an
>> interest in serving as a co-editor, have input documents to
>> contribute, or wish to express an objection to this consensus.
>>
>> Thank you,
>>
>> Brad Hill
>>
>>
>
>