Enable `SiteIsolationSharedProcessEnabled` by default

Component: WebKit UIProcess Site Isolation | 5fa37cf

Site Isolation은 서로 다른 site를 별개의 OS process에 배치하는 구조입니다. 이렇게 해두면 renderer 하나가 장악되더라도 — 보통 JS engine의 memory corruption 버그를 통해 도달합니다 — cross-site 데이터나 credential을 읽어낼 수 없습니다. 또한 Spectre 계열 side channel이 같은 process 안에서 origin 경계를 넘는 상황도 차단됩니다. UIProcess 쪽에서 특정 site의 frame을 어느 WebProcess에 배정할지 결정하는 컴포넌트가 BrowsingContextGroup입니다. 여기서 "shared process mode"는 site 단위 격리를 엄격하게 적용하는 대신 리소스를 아끼는 선택지에 해당합니다. site마다 process를 띄우지 않고, 여러 cross-site frame을 sharedProcessForSite와 ensureProcessForSite를 거쳐 하나의 공유 process로 보내며, 그 목록은 m_sharedProcessSites에서 관리됩니다.

이 commit은 SiteIsolationSharedProcessEnabled preference를 false에서 true로 변경했습니다. 그 결과 shared process mode는 opt-in이 아니라 기본 동작이 되었습니다. 함께 BrowsingContextGroup::sharedProcessForSite와 ensureProcessForSite 주변에 release logging이 추가되었습니다. site가 공유 process에 합류하는 시점, 그리고 해당 process가 현재 몇 개의 site를 담고 있는지가 기록됩니다.

Significance

이제 기본 설정에서 cross-site frame 여러 개가 하나의 WebContent process를 함께 쓰게 되며, Site Isolation이 제공하려던 process 경계는 그만큼 축소됩니다. 이 commit 전까지 shared process 경로는 대부분의 사용자에게 꺼져 있었습니다. flag가 켜졌다는 것은 이 code path와 그로 인해 낮아진 격리 수준이 실제 다수 사용자의 기본 환경이 된다는 뜻입니다. 동시에 새로 들어간 logging은 어떤 site들이 한 process를 공유하게 되었는지 확인할 수 있는 주된 관찰 수단이 됩니다.

Audit directions

앞으로 살펴볼 질문은, UIProcess의 다른 코드 중 어디가 "process 하나는 site 하나를 담는다"는 전제를 깔고 있는지입니다. 좁게 보면, m_sharedProcessSites를 사용하는 지점과 sharedProcessForSite/ensureProcessForSite의 배정 결과를 따라가 볼 필요가 있습니다. process 신원으로부터 단일 site나 origin을 끌어내는 정책 판단이 있는지가 관심 대상입니다. 더 넓게 보면, "이 메시지를 보낸 frame이 무엇인가?"가 아니라 "이 process는 어느 site인가?"에 답하는 코드가 대상입니다. 이런 코드는 이전까지 일대일이던 관계를 이제 다대일로 다뤄야 합니다. 점검 범위는 permission, storage, cookie 판단에서 WebProcessProxy를 origin의 대리물로 사용하는 모든 지점입니다. 가장 넓게 보면, 이 패턴은 서로 분리되어 있던 격리 도메인을 합치는 리소스 공유 최적화에 해당합니다. 그러면 파티션 구조 덕분에 부수적으로 지켜지던 invariant들은 이제 명시적인 검사로 옮겨져야 합니다. code review에서의 판별 신호는, 메시지에서 frame으로, frame에서 site로 가는 조회가 아니라 process에서 site로 바로 가는 조회입니다.

---