[tbb-dev] fission meeting notes

[Richard Pospesel]

What fission is and why we do it:
    multi-process model of gecko change
        currently: each tab in own processes
        fission: each 'origin' within a tab has own process
            ie 1st party domain in one, iframes loading 3rd party things in another
    why?
        unclear if 1st-party domains in multiple tabs are same proc
        for security, helping sandbox untrusted code from ads, etc
            help mitigate spectre, meltdown, things of this nature
            better security through process boundary woop woop
        possibly better performance, but primarily security concerns driver here
Architecture:
    cross-process Navigation
        DocumentChannel
            load starts in one proc, but we don't know where it will end (ie which content process loaded contnet needs to be run in)
        Session History
            thing that allows forward/back navigation
            global thing per tab
                currently lives in the content process
                fission: moved to parent process since so child content can access it (not landed yet)
            invisible change to consumers
        Remote WindowProxy
            needed for accessing 'windows' (like iframes) which now live in different procs
            should be an invisible change to consumers
                chrome code can no longer use 'x-ray vision' to change internal thingies
        Browsing Context and Window Context
            nsIDocShellTreeItem
                cannot be used post-fission world as things are corss-proc
                relevant methods renamed with 'InProcess' 'InChildAt' suffixes
            WindowContexts
                like BrowsingContext, but not persistent across navigation
            SyncedContext
                handles syncing of context state IPC
            Browsing Context Group
                'closure' of all reachable browsing contexts
                list of all 'reachable' browsing contexts
            Syncing state:
                FIELD macro allows for syncing state between contexts, implication that it is SAFE to share data between contexts
                CanSet, DidSet methods can be overwridden 
                If you do not implement CanSet, then procs will all have write access by default
            Do not add new state to nsDocShell
                determine if state needs to survive navigation
                    if so use BrowsingContext
                    if not use WindowContext
            Do not need to necessarily check principles everywhere
                if a browser context does not have a principle, that implies it is different from yours
        JS Window Actors
            registered in a few places (damn you fast slides)
            grep for JSWindowActorChild/JSWindowActorParent
            Window Actors only receive messages from their child/parent so don't need to namespace your messages (ie: Foo:FunMessage becomes FunMessage)

Schedule
    MVP start 2021
        until then feature-based milestones
    M5 -> Nightly dogfoodable with fission
    M6 -> Enable for small % of Nightly users
Contacts:
    Dev Lead: Nika Layzell <nika at mozilla.com>
    #fission channels on Slack and Matrix

Q&A:
    Will fission be mandatory when everything is finished? -> Short story Yes, Long story No
        We're not going to add a 'make my security worse' button to about:preferences for users
        Basically we can't expect process allocation model to be as described above on all platforms
            Android for instance has a cap on # of procs
            Also constrained platforms in terms of memory so lots of procs might suck
            Interesting fact, on android chromium isolates based on login credentials existing (ie if you have credentials for a site then it should be in its' own proc)
            tldr: don't write code with the assumption that the implmentation details are exaclty as described
    What are the potential perf benefits?
        Parellelism (duh)
        tldr; it's complicated (in ways you'd expect from talking about multi-process perf) so i won't go into every point in these notes, but it's *potentially* a win for some scenarios
        interestingly, switching tabs is faster as we only have to wait for the top-level content process to finish painting, so child iframes we don't have to wait to finish
    Question about security principles and some discussion about it:
        Don't spray principles around everywhere anymore
        The general assumption now for objects that if you don't have access to a thing, then you are not allowed to read/write it
    



To test fission:
    prefs:
        fission.autostart
        gfx.webrender.all

Links:
docs: https://firefox-source-docs.mozilla.org/dom/Fission.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20200128/7ea6448d/attachment.sig>