<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote"><div class="gmail_quote">On Thu, Mar 15, 2018 at 2:52 PM, Dave Townsend <span dir="ltr"><<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'd
like to hear what kind of API we should aim for, what properties do you
care about and how can we make this easier for developers to use?<br></div></div></blockquote></div></div><div class="gmail_quote"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><ul><li>I agree with others that this solution doesn't need to address documents that have chrome privilege (like about:memory), the focus should be on documents that have some amount of untrusted content and therefore don't want to run with the system principal.</li><li>Ideally the implementations of the exposed APIs don't have to be centralized in one place as history has shown it will get messy quickly unless there are enforced linting rules preventing it.<br></li><li>While the dispatchEvent approach was chosen due to it being the safest tool at the time, it's a bit clunky to use from the unprivileged page with constructing the event, dispatchEvent, and then addEventListener.<br></li><ul><li>we could make a content-accessible library for this if we really wanted<br></li></ul><li>Should the message listeners be scoped to the frame, window, or process?</li><ul><li>For the PaymentRequest dialog it's nice that the messages are scoped to the specific frame that the payment request code controls so we don't need to worry about messages from separate instances of the dialog getting mixed up (which is a security win). AboutCapabilities is currently scoped to the window (which probably makes sense if it's only for about: pages) but means I wouldn't want to use it for PaymentRequest.<br></li></ul><li>Ideally we should follow the principle of least-privilege and only give pages the minimum access they need</li><ul><li>The API should ensure in the parent process that messages are from the principal they think it's from. See below how AboutCapabilities doesn't check this.<br></li></ul><li>The API should handle sub-frames transparently so messages from/to the subframe aren't send/received from ancestor or descendant frames</li><li>Ideally artifact builds can be used to use the API in a new page. Perhaps using browser/app/permissions</li></ul></div></div><div class="gmail_quote">On Thu, Mar 15, 2018 at 11:17 PM, Zibi Braniecki (Gandalf) <span dir="ltr"><<a href="mailto:zbraniecki@mozilla.com" target="_blank">zbraniecki@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The user visible consequences are potentially significant. Lets say that someone turns on resistFingerprinting. It's pretty obvious why the person may expect that their timezone be set to UTC when they browse Web Content. But would they expect parts of Firefox UI to show up with UTC timezone?<br></div><div>Will they understand why Downloads UI uses different date/time formatting than Web Payments?</div><div><br></div><div>Is it ok that most of the Firefox UI will follow users preferred hour cycle to be 24h, but video controls or Web Authentication UI will use the default for their locale (12h) because it cannot access the privileged information?</div><div><br></div><div>If we add a special localization exposed information on the privileged side that uses AppConstants, or some other Gecko specific data, should this data be available for localization purposes on unprivileged side or not?<br></div><div><br></div><div>This part of the issue boils down to - do we expect the non-privileged to act like web content, or do we expect it to have limited privileges for security reasons, but still stay consistent UI wise with the privileged UI?</div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">IMO the "trusted content pages" should be consistent with the privileged UI in terms of l10n/i18n as users will likely think of them both as being from Firefox. The additional APIs can be exposed to the specific list of "trusted" content pages but the APIs should be limited so that they only perform the specific tasks required and not allowing things like sending arbitrary message manager messages.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">It seems like my perspective would mean that we shouldn't worry about fingerprinting from these "trusted content pages" but should worry about remote code execution and sandbox escapes.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">On Fri, Mar 16, 2018 at 4:25 AM, Christoph Kerschbaumer <span dir="ltr"><<a href="mailto:ckerschb@gmail.com" target="_blank">ckerschb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>I guess
there is no doubt that it’s desirable to settle on one approach instead
of having all the different about: pages do their own thing.</div></div></div></blockquote><div><br></div><div>IMO the solution shouldn't be specific to about: pages as this affects things like UITour, about:accounts, and other non-about: pages.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div> From a
security perspective we definitely need to get away from the framescript
approach where the various custom events rely on opt-in and ad-hoc
security checks which not only are really hard to reason about, but are
also prone to cause incidents.</div></div></div></blockquote><div><br></div><div>An alternative approach would be making it easier to do consistent/correct security checks but I do think that this approach is nicer than dispatching events anyways.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>Having said
that, I agree that the other three approaches share a lot of
similarities but with one big difference. Again, I am speaking from a
security point of view. The fact that the architecture of
‘AboutCapabilities’ relies on WebIDL; which allows to expose and define
an API in a separate file, allowing to perform security audits without
having to perform a full time intensive source code audit. </div></div></div></blockquote><div><br></div><div>If we use this approach for more than just about: pages (see above), then I worry about AboutCapabilities becoming a dumping ground for APIs needed by "trusted content pages". The same concern applies to AboutCapabilitiesListener in browser.js but as long as receiveMessage calls to outside functions there I think it will be okay.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>Particularly
beneficial is that this new behavior model allows us to enforce proven
WebIDL based principal vetting where all the different about pages have
to register within a single well defined location within our codebase. I
agree, that this registration requires some C++ to be written, but
particularly that entry point into the API should be guarded by the
strong type checking provided by C++. Please note that the actual WebIDL
implementation for the ‘AboutCapbilities’ approach is still in JS, it
only needs to be defined within WebIDL. Having all of those capabilities
encapsulated within AboutCapabilities allows for a nice unification of
the various about: pages.</div></div></div></blockquote></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">One thing which the AboutCapabilities approach is missing but I think could be useful for sandbox hardening for JS escapes would be to check the principal the message is received from in the parent process. That way arbitrary JS code that gets chrome privileges can't just use the regular sendAsyncMessage API to send a message with the "AboutCapabilities:" prefix and run the relevant code in the parent process. This would also mean segregating the required APIs per-origin rather than giving all origins on the allow all the defined APIs. If we're doing this to improve security, I think we should take this extra small step as it's easier to do while porting than to later figure out which pages need which APIs.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Matthew<br></div></div><span class="gmail-m_-3488073586747798724HOEnZb"></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>