Firefox Profiles with a Shared storeID?

Firefox profiles are used to keep browser data such as settings, bookmarks, passwords, and other profile data separate. It supports multiple profiles, each of which generally has its own separate data storage.

What are the advantages and disadvantages of using multiple Firefox profiles that access certain data or Groups through a shared storeID, compared to completely separate Firefox profiles?

Every profile is assigned a storeID which is a short alphanumeric string. When the Selectable Profile Service is in use the same storeID is shared by all profiles in the same group. In all other cases the storeID is unique to every profile. This identifier is used as the mechanism for grouping profiles as well as to allow storing per-group data...
The ProfilesDataStoreService.sys.mjs manages a unique SQLite database for each storeID. This means that when there are a group of profiles using the same storeID then they all use the same SQLite database allowing for persisting data that can be used by every profile in the group. It provides direct access to a SQLite connection and a mechanism for notifying running instances that are using the same database...

Should stick with the classic approach of having one profile per project and managing the data separately, even if sometimes you have the same data across different projects? You could simply export and import whatever data you need.

What impact does this approach have, in particular, on data management, profile separation, synchronization, performance, security, complexity and especially when it comes to isolation?

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论