<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m a big fan of the RemotePageManager (RPM), which I've used extensively in the past for the Loop/ Hello project:<div class=""> - for it’s developer ergonomics. Even though it’s not documented as well as other modules might be (Mossop’s blog post(s) did help and should just be copied over to [1]), I was able to get the basics up and running very quickly. It doesn’t stray too much from the pub/sub semantics that we use with the messageManager(s), observer service and everywhere else, basically. </div><div class=""> - for it being a module that is undogmatic and extensible;</div><div class=""> - Since type assertions/ validation has been raised a concern here: `class ValidatingChildMessagePort extends ChildMessagePort {`. In other words: I think we can make that work with a bit of labor using the WebExtensions schema validator, extending the current implementation a bit.</div><div class=""> - Allows for batching of RPCs; for performance reasons, messageManager traffic-heavy content pages need ways to optimise their payloads, but preferably as a built-in feature. This is not a feature of RPM specifically at the moment, but is relatively easy to implement, IMHO.</div><div class=""> - Similar to and along with batching of messages, we should be able to imagine a simple compression scheme that sits between the content page, the messageManager and the chrome script.</div><div class=""> - At ~500LoC it’s a relatively small module, whilst declaring five classes. I found the code easy to read, understand and modify, but I know that’s very subjective.</div><div class=""><br class=""></div><div class="">I’m also a fan of the WebExtension model, but that flips the coin to being rather dogmatic and its extensibility is limited to the set of features as required by its main consumer: browser extensions, serving a potentially massive ecosystem, shielding its internals. But that’s part of its many strengths, so it might work out fine for in-browser architectures as well.</div><div class=""><div><br class=""></div><div>Those were my few cents!</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>Mike.</div><div><br class=""></div><div>[1] <a href="https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules" class="">https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules</a></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 16 Mar 2018, at 23:22, Dave Townsend <<a href="mailto:dtownsend@mozilla.com" class="">dtownsend@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">So I totally agree that we should try to have one place were we do permission checks for the APIs we expose to trusted content pages. Folks should not be rolling their own here, it's hard enough to get right that folks will get it wrong. Is that place in webidl? I'm not sure, I don't know enough about this kind of vetting so I don't know why we couldn't write basically the same code in another context, aboutCapabilities doesn't seem to use any webidl specific permission checks unless I'm missing something. The main thing I dislike about aboutCapabilities permission checks though is that you have to edit C++ to add a page which is a massive impediment to front-end developers who can otherwise work with artefact builds. We could fix that by using the permission manager for the hosts instead of a compiled whitelist.</div><div class=""><br class=""></div><div class="">That said, aboutCapabilities concerns me in other ways. The centralisation of much of the code and exposing every API to every page is problematic. It makes it difficult to track which pages use which API over time and potentially gives pages permissions they shouldn't have. I don't know if that is worth the strong type checking that webidl gives us, particularly when there are other options that also give us strong type checking.<br class=""></div><div class=""><br class=""></div><div class="">I'm actually a really big fan of what I've found from the webextension method of defining APIs (see the updated doc where I added this earlier). It can all be defined in a way supported by artefact builds and add-ons, gives strong type checking and permission checks. It also allows keeping API code with the appropriate component.<br class=""></div><div class=""><br class=""></div><div class="">On Fri, Mar 16, 2018 at 4:25 AM Christoph Kerschbaumer <<a href="mailto:ckerschb@gmail.com" class="">ckerschb@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" 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" target="_blank" class="">https://docs.google.com/document/d/1zTT7gHW5SzIUJkr2OkE44Xapj2JDIHJqjvJooxoB-J4/edit</a></div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2018, at 7:17 AM, Zibi Braniecki (Gandalf) <<a href="mailto:zbraniecki@mozilla.com" target="_blank" class="">zbraniecki@mozilla.com</a>> wrote:</div><br class="m_-4550693137450431656Apple-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" target="_blank" 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=""></div></blockquote></div></div>
_______________________________________________<br class="">firefox-dev mailing list<br class=""><a href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a><br class="">https://mail.mozilla.org/listinfo/firefox-dev<br class=""></div></blockquote></div><br class=""></div></body></html>