Re: [webappsec] Rechartering: Sub-Origins

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
>

Received on Monday, 10 November 2014 12:05:22 UTC