<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Dave,</div><div class=""><br class=""></div><div class="">thanks for writing up that document [1] highlighting the different approaches and architectures we use for powering the various about: pages. 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. 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 class=""><br class=""></div><div class="">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. 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 class=""><br class=""></div><div class="">Thanks,</div><div class=""> Christoph</div><div class=""><br class=""></div><div class="">[1] <a href="https://docs.google.com/document/d/1zTT7gHW5SzIUJkr2OkE44Xapj2JDIHJqjvJooxoB-J4/edit" class="">https://docs.google.com/document/d/1zTT7gHW5SzIUJkr2OkE44Xapj2JDIHJqjvJooxoB-J4/edit</a></div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2018, at 7:17 AM, Zibi Braniecki (Gandalf) <<a href="mailto:zbraniecki@mozilla.com" class="">zbraniecki@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Thanks Dave for bringing it up.</div><div class=""><br class=""></div><div class="">This has been on my mind a lot lately as I'm trying to plan localization strategy for non-privileged content.</div><div class=""><br class=""></div><div class="">Fluent is slowly getting introduced into Firefox via Preferences first, but soon we'd like to start opening it up to other areas of code and non-privileged showed up on multiple occasions.</div><div class=""><br class=""></div><div class="">We know we want to provide very similar experience there to what we provide in privileged - same declarative API, same imperative API.<br class=""></div><div class=""><br class=""></div><div class="">In the context of localization, there are three major questions:</div><div class=""><br class=""></div><div class="">1) Where do data come from (l10n resources)<br class=""></div><div class="">2) Where does the parsing/formatting code live?<br class=""></div><div class="">3) Where do additional data come from? (Intl APIs, regional preferences and settings etc.)<br class=""></div><div class=""><br class=""></div><div class="">What I mean by this is that we first have to somehow fetch the localization resources (1). In case of Fluent we use asynchronous generator to get a lazily resolved iterator of fallbacks.</div><div class=""><br class=""></div><div class="">It works really well when Localization.jsm can directly call L10nRegistry.generateContexts. Things get a bit tricky when you want to do the same in non-privileged.</div><div class=""><br class=""></div><div class="">We can either move all the code to the non-privileged side and have special version of Localization.jsm and L10nRegistry.jsm that only fetches I/O from the privileged side over some postMessage, or try to reuse as much as possible of the privileged side and use the postMessage to call for particular l10n-ids and get formatted messages back.</div><div class=""><br class=""></div><div class="">The latter seems tempting, but carries cost - it means that for each non privileged document we need to maintain its localization context on the privileged side and make sure we destroy it when the document goes away.</div><div class=""><br class=""></div><div class="">We would love to ask for help in deciding what strategy to use here, and if there's an effort to unify the strategy around the priv/non-priv, to make localization part of it.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">There's also another interesting question around localization and non-priv.</div><div class=""><br class=""></div><div class="">In Fluent, when we localize messages in the web context, we can only access the publicly available APIs (Intl.*) which have been designed to minimize fingerprinting and are by nature fairly limited.</div><div class=""><br class=""></div><div class="">When we localize Firefox UI, we have access to the same APIs on steroids (mozIntl.*) which can do additional tricks like looking into Operating System Regional Preferences Settings, or retrieving some other customizations.</div><div class=""><br class=""></div><div class="">When localizing non-privileged content, we can either send the request to the privileged side and format the message there using all the goodies, or format the message in the unprivileged context.</div><div class=""><br class=""></div><div class="">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 class=""></div><div class="">Will they understand why Downloads UI uses different date/time formatting than Web Payments?</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">The decision here has some serious consequences on the first topic, and I'm not sure who should make the call here.</div><div class=""><br class=""></div><div class="">I have some draft of an API here: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1407418" class="">https://bugzilla.mozilla.org/show_bug.cgi?id=1407418</a> - and would appreciate any and all feedback and help I can get to figure out the final design of this feature.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">zb.<br class=""></div></div>
</div></blockquote></div><br class=""></body></html>