Authenticator-Extension/Authenticator

MV3 Compatibility

mymindstorm opened this issue · 19 comments

mymindstorm commented

https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html

MV3 removes background scripts, which makes it impossible to store data in memory, but we (and other password managers) need this for key storage. We should look at how other password managers plan to handle this change.

https://crbug.com/930235

Sneezry commented

The official guide for persisting state when migrate to background service workers from background pages is using storage API: https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#state

Let's see if there will be a guide for sensitive data scenario guide.

mymindstorm commented

Do you know how long until Google deprecates MV2?

Sneezry commented

While there is not an exact date for removing support for Manifest V2 extensions, developers can expect the migration period to last at least a year from when Manifest V3 lands in the stable channel. We will continue to provide more details about this timeline in the coming months.

https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html

Sneezry commented

Some known changes that impact Authenticator

Are you using a custom content_security_policy in manifest.json?
https://developer.chrome.com/docs/extensions/mv3/mv3-migration-checklist/#security_checklist

  • Move to chrome.storage.session to cache password
  • Move to chrome.scripting to inject scan QR script
  • Replace content_security_policy with content_security_policy.extension_pages or content_security_policy.sandbox as appropriate.
  • Remove references to external domains in script-src, worker-src, object-src, and style-src directives if present.
Sneezry commented

The new storage API (in deployment) to save session data in MV3 could introduce security risk (see https://bugs.chromium.org/p/chromium/issues/detail?id=1227410). We need keep an eye on the latest progress.

Sneezry commented

We need figure out how to handle auto lock. Chrome doesn't support TTL for session storage and they have no plan to support it.

Here's some suggestions from community by woxxom (https://bugs.chromium.org/p/chromium/issues/detail?id=930235#c21)

There at least are two solutions:

  1. use waitUntil in your service worker to prevent it from unloading for up to 300 seconds (five minutes) - the benefit of this solution is that it reduces the number of restarts of the service worker, which is an extremely costly operation compared to prolonging the currently active one

self.onactivate = e => {
e.waitUntil(new Promise(resolve => {
setTimeout(() => {
chrome.storage.session.remove('foo', resolve);
}, 60e3);
}));
};

  1. use chrome.alarms to set an alarm (requires "alarms" in "permissions" of manifest.json)

chrome.alarms.create('clearSecret', {
delayInMinutes: 1,
});
chrome.alarms.onAlarm.addListener(alarm => {
if (alarm.name === 'clearSecret') {
chrome.storage.session.remove('foo');
}
});

WARNING! The alarms API is completely unreliable as it won't fire a missed alarm e.g. the user closed the browser or put the computer to sleep before the alarm fired, so if you use it you'll have to perform an explicit check of the time passed using Date but then again this is completely unreliable as the date may have been changed by the user or timezone savings. I don't see any elegant solution to this other than preventing the service worker from unloading for the entire duration of the timer. If that duration is under five minutes you can use the first example, otherwise you'll have to use chrome.runtime ports (example: https://stackoverflow.com/a/66618269). Another theoretical solution would be for Chrome to expose its internal monotonic time (the analog of performance.now() for the entire browser) via an extension API e.g. chrome.runtime.getMonotonicTime(callback).

An elegant workaround for the bug in chrome.alarms API is apparently to clear the storage if the alarm by that name is absent:

// Start of the service worker script
chrome.alarms.get('clearSecret', a => {
// No alarm means it's expired but we weren't notified due to browser restart etc.
if (!a) chrome.storage.session.remove('foo');
});

Sneezry commented

https://developer.chrome.com/blog/mv2-transition/

  • January 17, 2022: New Manifest V2 extensions will no longer be accepted by the Chrome Web Store. Developers may still push updates to existing Manifest V2 extensions, but no new Manifest V2 items may be submitted.

  • January 2023: The Chrome browser will no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions.

sum32139 commented

Thanks for responding. The issue we are running into is want to keep ACC in a private webstore so it doesn't automatically update for our users for various reasons. This means we need a new extension (with a new extension ID) so we are impacted by July 2022 rules for new extensions. Please let me know if I'm not understanding this correctly

https://learn.microsoft.com/en-us/microsoft-edge/extensions-chromium/developer-guide/manifest-v3

Sneezry commented

According to this doc, Firefox doesn't support service worker in their MV3 implement: https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

Sneezry commented

I'm wondering if Mozilla Firefox supports persistent background for MV3 since it seems it only supports event page. If persistent or storage.session is not supported, it would present a blocking issue for the migration to Firefox.

mymindstorm commented

From the migration guide:

However, MV3 removes support for persistent background pages.

Record state changes in local storage.

Sneezry commented

sessionStorage is worth for investigation for event page: https://developer.mozilla.org/zh-CN/docs/Web/API/Window/sessionStorage

DNin01 commented

Chrome will officially drop support for Manifest V2 at some point after June 2024, so you have until then to update.

  • 👍1
Sneezry commented

We will start the migration after the holiday season.

  • 🚀1