[Manifest V3] Background page vs service worker use case

[cbonnoit]

Hi,

I wanted to share a use case that seems to me materially more challenging under the service worker paradigm than the current background page approach. Per #72, I am creating a corresponding issue here since I did not see something on that page that looked like this issue.

In a background page, I can perform synchronous periodic computations that take on order a few minutes. In my specific use case, these are computational algorithms (nonlinear optimization, etc) and the calculations are performed on a regular but infrequent schedule so the average load is low. As far as I understand, in a service worker world I will have to convert these algorithms into incremental forms by subdividing the work into synchronous chunks under the specified time limits (~30 seconds) and then manage appropriate state persistence to resume or aggregate calculations as needed. This seems like it would be pretty challenging to do well since (a) managing state persistence can be nontrivial when intermediate results are needed to effectively resume computation and (b) estimating algorithm runtime prior to execution in order to cleanly batch work is a challenging (provably unsolvable) problem.

Thanks for taking this under consideration - any suggestions are welcome!
Craig

[pospichalales]

Hi,

I would like to share our use case for extension and the complication after moving to MV3. Our extension is starting native host and then it acts as message exchanger between webpage and native host. Native host itself is loading library (DLL) for working with digital certificates/smart cards and these libraries support creating digital signatures according to eIDAS. When the page starts communication with the extension, webpage sends information for native host which library wants to load (we have multiple libraries, each one has its own functions). The native messaging host process than holds the loaded library in memory with some user data like loaded certificate store, some settings and configured certificate for the current relation.

The issue we experience after switching to MV3 is the native messaging host is being killed after around 5 minutes. The host process exits and we not longer have the signing library and relation specific settings. We would not have a problem with the lifetime limit itself if the limit would be extended with each use of extension. Once the user is inactive for 5 minutes, we would accept the stopping after this limit. We had something like this implemented in MV2 where the native host was killed after 10 minutes of user inactivity.

If you kill the native host every time after 5 minutes regardless of user activity, this would considerably affect our current implementation.

Please consider at least changing of limetime to take into account user activity.

Ales Pospichal
Prvni certifikacni autorita, a.s.

[sumantmodak]

Hello,

I'd also like to share DLP (Data Leak Prevention), IRM (Insider Risk Management) & Compliance related use cases. We have native host that is in constant communication with the chrome that observes user activity. This data is used to corelate with signals that we generate from native host. The 5min shutdown breaks this sequence and our ability to correctly co-relate information and signal critical compliance events. This is one of the major blocker for us to move to MV.3.
Not only we risk sending incorrect events but completely miss some critical compliance events in enterprise deployments. The security of IP, confidential data is paramount to Orgs.