[FireMonkey] should honor current container cookies #378

pintassilgo · 2021-10-30T01:53:08Z

GM.xmlHttpRequest and GM.fetch always use "default" cookies, breaking scripts in container tab when cookie is relevant.

For example, an UserScript performing GM.fetch in a tab from "Personal" container should, by default (when cookie isn't explicitly passed in { headers }), pass cookies from Personal store, not to leak cookies from default container. Cookies from current tab should always be used.

This issue may affect private browsing too, but I haven't tested it.

For reference, Violentmonkey is doing it right, passing cookies from current tab container.

The text was updated successfully, but these errors were encountered:

erosman · 2021-10-30T08:23:53Z

GM.xmlHttpRequest and GM.fetch are basically standard JavaScript xmlHttpRequest & fetch that run from FireMonkey's background script.

By default, they dont send cookies.

xmlHttpRequest withCredentials defaults to false, no effect on same-site request
fetch credentials defaults to false

Using Fetch
fetch() won’t send cross-origin cookies unless you set the credentials init option. (Since April 2018. The spec changed the default credentials policy to same-origin. Firefox changed since 61.0b13.)

XMLHttpRequest.withCredentials
Note: XMLHttpRequest responses from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request, regardless of Access-Control- header values.

Note: Manually grabbing cookies require "cookies" permission.

FireMonkey currently does not manually add cookies.
📌 It can be discussed as a new feature.

Greasemonkey manually grabs and adds the cookies at all times (not container aware).
https://github.com/greasemonkey/greasemonkey/blob/efd22a93121225ada47f2fe9f021af0ab6100c21/src/bg/on-user-script-xhr.js#L128-L137
Include cookies in GM.xhr for same-origin; implement withCredentials for cross-origin

Violentmonkey also appears to manually grab & add the cookies at all times (container aware) but also has anonymous flag
https://github.com/violentmonkey/violentmonkey/blob/8322fc7eafda4dd76b3ffa01dfb595d6e4228265/src/background/utils/requests.js#L347-L357

Violentmonkey GM_* APIs
anonymous boolean (since VM2.10.1)
When set to true, no cookie will be sent with the request and since VM2.12.5 the response cookies will be ignored. The default value is false.

Tampermonkey also appears to manually grab & add the cookies at all times but also has anonymous flag

Tampermonkey Documentation
anonymous don't send cookies with the requests (please see the fetch notes)

pintassilgo · 2021-10-30T09:05:32Z

Manually grabbing cookies require "cookies" permission.

Not a problem, right? All UserScript manager require cookies permission. Except FM, right now.

As you noticed, all of them add cookies by default, This shows their intentions to pass authentication the right way, including the obvious privacy concern of not sending cookies from normal windows when in private mode.

About the specificity of containers, both VM and TM honor the container of current tabs as it's pretty obvious they all should do, Not doing it is a bug that need to be fixed, as stated in TM release notes:

Fix GM_xhr made from container tabs

There's no sense in thinking that the right approach is that a script loaded in container tab should reuse cookies from normal tab by default, this is clearly wrong and even a privacy issue. Containers are designed to be isolated scopes from each others.

Regarding GM... well... we all know that GM is essentially dead in development since 2018 and containers is a relatively new feature (started in like 2017), so it doesn't really mean much.

erosman · 2021-10-30T09:50:01Z

Not a problem, right? All UserScript manager require cookies permission. Except FM, right now.

You wont believe how much grief developers get from users over permissions. I have even had complaints about 'notifications' permission. Most users are not aware of permission risks, or lack thereof. The notices on AMO are sometimes more daunting than what they really are.
(e.g. recently #374, #375)

As you noticed, all of them add cookies by default,

I have always been concerned about security in FireMonkey, therefore, I am not very keen on that idea.
xmlHttpRequest withCredentials & fetch credentials are there specifically for this purpose.

📌 However, AFA containers and private browsing, I am currently discussing it with Firefox Security team and will try to implement.

Further information:

Enable extensions to send network requests (fetch) with a specific cookieStoreId (container tab context)

erosman · 2021-10-30T16:01:48Z

How should container XHR work?

source webpage: page.com
XHR/fetch target: target.com

When sending HTTP request to target.com the credentials for target.com are sent. That has nothing to do with the container that page.com is in. 🤔

pintassilgo · 2021-10-31T01:08:35Z

The UserScript is attached to the include/match rule. FM calls for XMLHttpRequest from background for technical reasons (I guess) but it's actually to do something in the webpage it was called for, no matter request's domain. UserScripts are content scripts, to do something on webpages.

Unless explicitly stated otherwise in the code via credentials, manually setting Cookie header, anonymous flag or whatever, the request must send cookies within the context of current tab (i.e., honoring private/non-private state & container). Anything different than this is an unexpected leak (a bug).

I can't imagine a reason to think that it's right for an UserScript to, by default, pass cookies from normal browsing when it was called from a webpage loaded in private mode. It's clearly a bug, a leak. And the same logic applies to containers. Containers are isolated from each others just like private browsing, the difference is that container data is stored.

erosman · 2021-11-01T15:59:11Z

After talking with Mozilla security team, I am going to work something out on the cookies & private/container issue.

erosman · 2021-11-02T07:38:12Z

Cookie isolation is done and will be in v2.35
There is a lot of code rewrite and it will need testing (and feedback).

erosman · 2021-11-02T17:41:15Z

After chatting with Mozilla security team, here is the latest ....

GM xmlHttpRequest/fetch Cookies

Normal Browsing Mode
Cookies are handled by Firfox according to withCredentials or credentials
- xmlHttpRequest {withCredentials} default is false, no effect on same-site requests.
- fetch {credentials} default is same-origin.
Cookies set via GM API headers will replace original Firefox cookies
Container or Private (Incognito) Browsing Mode
FireMonkey gets and sends cookies relating to the mode only
Cookies set via GM API headers will not be processed
anonymous
If set to true, all cookies are removed before sending

pintassilgo · 2021-11-02T18:06:40Z

Thanks.

I only disagree with this:

Container or Private (Incognito) Browsing Mode
Cookies set via GM API headers will not be processed

There should be a way to set cookies in any mode. Or at least in container tabs.

What if I have an UserScript that I want it to make requests using the same Cookies defined in header regardless the tab/mode?

erosman · 2021-11-02T18:19:35Z

There should be a way to set cookies in any mode. Or at least in container tabs.
What if I have an UserScript that I want it to make requests using the same Cookies defined in header regardless the tab/mode?

Originally, I had set it that way, but Mozilla team told me that "if the server replies with Set-Cookie, that would leak cookies". Therefore, they suggested to disable userscript cookie in container/private mode.

What do other managers do in container/private mode?

Also ...

Userscripts can't check if they are in container/private mode. Therefore the same userscript cookie will be sent in normal & container & private mode.
That defeats the purpose of cookie isolation which was the goal of this topic.

pintassilgo · 2021-11-02T19:12:53Z

but Mozilla team told me that "if the server replies with Set-Cookie, that would leak cookies".

What? I don't get it. Set-Cookie is a forbidden response header for fetch just as Cookies is a forbidden request header (among others), but you correctly added Cookies as an exception to allow FireMonkey to send cookies. But Set-Cookie is still forbidden (ignored). And I don't know what's the problem here. Do you have an example?

What do other managers do in container/private mode?

Tested in Violentmonkey, which in my opinion has the best code quality, and it does what it should in all cases, exactly as I'm requesting. By default, GM APIs honors the context of the tab (send default cookies when in default mode; send container cookies when in container tab...). And if I manually set Cookies, they are sent in all cases. If I manually set Cookies in UserScript's code it's because I don't care about the origin of the tab, cookies should always be sent. The only available filtering is to block Violentmonkey from running in private mode, that way the UserScript won't run at all in private tabs.

So:

  GM.xmlHttpRequest({
    url: 'http://www.example.com',
    headers: {
      'Test': 'right',
      'Cookie': 'psiu=2',
    }
  });

In Violentmonkey, both Test and Cookie are always sent, it doesn't matter the tab context. I think this is obviously the expected and right behavior, and I suggest that FM should do the same.

That defeats the purpose of cookie isolation which was the goal of this topic.

I'd say this has nothing to do with cookie isolation and the goal of this topic. Now we are talking about explicitly and deliberately user-defined cookies using headers: { 'Cookie': 'a=1' }. There's no leak when it's intentional. What was problematic, and you say it's already fixed for the next version, is that an UserScript running in container/private tab was unintentionally leaking cookies from default mode.

erosman · 2021-11-02T19:34:16Z

What? I don't get it. Set-Cookie is a forbidden response header for fetch just as Cookies is a forbidden request header (among others), but you correctly added Cookies as an exception to allow FireMonkey to set cookies. But Set-Cookie is still forbidden (ignored). And I don't know what's the problem here. Do you have an example?

Set-cookie is received on the HTTP response headers by the target server, not userscript HTTP request.

Now we are talking about explicitly and deliberately user-defined cookies

That would allow userscripts access to container/private browsing area. It maybe OK for the userscript developer but not for the users.

Imagine userscripts sends some cookie that relates to a porn site.
If user is in normal mode, it is fine.
If users goes into private mode, then it should be isolated.

Moreover, Cookies sent from xmlHttpRequest and fetch aren't stored, they are meant only for that single request. It can't do anything unexpected or insecure.

Cookies sent via HTTP request are read (and can be stored) by the destination. That is the whole point of sending them. An example would be login cookies.
The concern is the data passed from userscript to the target server, in container/private mode.

Example:

GM.xmlHttpRequest({
  url: 'http://www.example.com',
  headers: {
    'Test': 'right',
    'Cookies': 'visited=' + location.href,
  }
});

pintassilgo · 2021-11-03T03:18:02Z

Set-cookie is received on the HTTP response headers by the target server, not userscript HTTP request.

I know that. My question is still up.

That would allow userscripts access to container/private browsing area.

Access what?

Imagine userscripts sends some cookie that relates to a porn site.
If user is in normal mode, it is fine.
If users goes into private mode, then it should be isolated.

Please, give an example of how this can be abused.

Cookies sent via HTTP request are read (and can be stored) by the destination. That is the whole point of sending them. An example would be login cookies.
The concern is the data passed from userscript to the target server, in container/private mode.

Everything sent is read by the server. They receive all headers plus the body in POST requests. Do what you say, UserScripts will still be able to send any data using other headers or request body. They can also read Set-Cookie in response headers.

You said you implemented sending stored cookies for the next version. Cookies from normal mode are already sent by default. Cookies from containers will be sent by default in next version. Cookies from private browsing will be sent by default in next version (if the user has allowed FM to run in private). How is this different from allowing the UserScript to send custom cookies?

Example:

And what's the problem? Why should this be allowed when you're browsing in default container, but not in any other container?

erosman · 2021-11-03T05:36:41Z

Currently, Firefox is isolating cookies of normal, container & private modes; for security and privacy reasons.

Userscripts should follow the same principle. and isolate cookies of normal, container & private modes; for security and privacy reasons.

If Firefox is not allowed to, should a userscript developer be allowed to?
Users' security and privacy is the main factor here.

However, you can discuss it with Mozilla security team and if they agree, I will implement it.

pintassilgo · 2021-11-03T05:38:51Z

What I'm requesting doesn't break cookie isolation in any way. There's nothing being transmitted from one context to another.

erosman · 2021-11-03T08:00:49Z

Cookie Isolation: Not sending the same cookie in different modes.

Userscript is sending the same cookie in all modes.

pintassilgo · 2021-11-03T08:21:38Z

Cookie isolation: not leaking cookie from one mode to the other. Current FM doesn't work like this because default cookies are sent even when the script loads in a container tab or in private mode. So I opened this issue and now next version is supposed to fix it.

When an UserScript wants to send a custom header like foo=bar, this cookie doesn't belong to any mode. It makes no sense to think that the cookie should be sent in Default container, but not in Work container, as you're failing to provide an example.

Remembering that sending Cookie header doesn't store anything. Sending foo=bar to example.com won't create the foo=bar cookie in cookies.sqlite. Cookies are created by Set-Cookie response header or by document.cookie.

erosman · 2021-11-03T08:36:03Z

However, you can discuss it with Mozilla security team and if they agree, I will implement it.

As mentioned, it is done according to their recommendation.
As a start, you can discuss it here:
https://chat.mozilla.org/#/room/#addons:mozilla.org

pintassilgo · 2021-11-03T09:45:14Z

I'd bet you misunderstood their recommendation. Tried to find your chat in Discord, but it seems that you chatted elsewhere after starting there.

Well, I give up. For me it makes almost no difference. As you may know, I use a fork of FM. I'll implement it as I think it's right and that's it.

erosman · 2021-11-03T10:27:39Z

Tried to find your chat in Discord, but it seems that you chatted elsewhere after starting there.

It was done in private.

I'd bet you misunderstood their recommendation.

Here is part of the chat:

This is what I have done. Let me know if you think it is acceptable.

GM xmlHttpRequest/fetch Cookies

Normal Browsing Mode
Cookies are handled by Firfox according to withCredentials or credentials

Container or Private (Incognito) Browsing Mode
FireMonkey gets and sends cookies relating to the mode only

init Cookie
If set, it will replace original Firefox cookies

init anonymous
If set to true, Firefox Cookies are removed before sending, but init Cookie is kept

👤 What's init cookie?
Regardless of the implementation, you should avoid leaking cookies to unexpected contexts

userscript can set cookie when doing GM.fetch / GM.xmlHttpRequest via its ini object {headers: {cookie:"..."}}

👤 And if the server replies with Set-Cookie, that would leak cookies

What should I do?
Should I not honour cookies set by the userscript?
Should I limit them to certain mode?

👤

Or to cover the common case, only support it when cookieStoreId is firefox-default

This is my recommendation

So only allow userscript cookie when in normal mode?

👤 Yes

pintassilgo · 2021-11-03T14:17:58Z

Just adding: I mentioned Violentmonkey, but tested now and Tampermonkey also has no problem with headers: { 'Cookie': 'foo=bar' }. Cookies are always sent.

So it's a FM only issue. And for no understandable reason...

erosman · 2021-11-03T14:45:13Z

📌 I am asking Mozilla security team:

Should FM try to block Set-Cookie response?
Would it make a difference in userscripts setting cookies?

Set-Cookie Reference:

The Set-Cookie and Cookie headers
GM_xmlhttpRequest's Set-Cookie header overwrites cookies
https://github.com/violentmonkey/violentmonkey/issues/794

Note:
A quote from VM developer

https://github.com/violentmonkey/violentmonkey/issues/869#issuecomment-584746320
Just because TM has something doesn't mean we should copy it.

pintassilgo · 2021-11-03T14:45:37Z

And if the problem is when the server returns Set-Cookie, it's possible to filter them off, as Violentmonkey does (but it does only when anonymous flag is set):
violentmonkey/violentmonkey@a1955ba

pintassilgo · 2021-11-03T14:53:47Z

A quote from VM developer

This was about a request for UI, for which it makes no sense every manager to be exactly the same. But you can see in multiple comments in VM's repo that they make efforts to keep up scripts compatibility compared to Tampermonkey, "which is the de facto standard" (said by VM's dev).

erosman · 2021-11-03T14:55:54Z

And if the problem is when the server returns Set-Cookie, it's possible to filter them off, as Violentmonkey does (but it does only when anonymous flag is set):

I am also trying to verify it.

erosman · 2021-11-03T19:23:50Z

I have already written the code to filter Set-Cookie in response headers.
I have asked if that is enough to make it safe.
I am waiting for an answer.

erosman · 2021-11-04T14:12:39Z

Latest update of FireMonkey Help

Cookies Isolation

Browsing modes in Firefox can be divided into 3 distinct modes: normal, container, & private/incognito.

JavaScript xmlHttpRequest/fetch send cookies and credentials with their HTTP requests. In web pages, xmlHttpRequest/fetch send cookies according to the mode of the tab i.e. cookies belonging to normal browsing mode are not sent when in container or private mode, and vice versa. Cookies in each mode are isolated to preserve users' security and privacy.

GM xmlHttpRequest/fetch are sent from FireMonkey background script where modes do not apply. In order to honour users' browsing mode and privacy choice, FireMonkey (v2.35+) isolates cookies that are sent by the userscript according the mode of the tab userscript is running in.

Normal Browsing Mode

Cookies are handled by Firefox according to withCredentials or credentials
- xmlHttpRequest {withCredentials} default is false, no effect on same-site requests. ⓘ
- fetch {credentials} default is same-origin. ⓘ
Cookies set via GM API headers will replace original Firefox cookies
Cookies sent back in the response will be handled by Firefox

Container or Private (Incognito) Browsing Mode

Cookies set via GM API headers will replace original Firefox cookies
If Cookies are not set via GM API, FireMonkey gets and sends contextual cookies according to the mode
⚠️ Not decided what to do with cookies sent back in the response 🤔

anonymous
If set to true:

fetch
- Same as userscript setting {credentials: 'omit'}
- credentials will be set to omit ⓘ
- Tells browsers to exclude credentials from the request, and ignore any credentials sent back in the response (e.g., any Set-Cookie header)
xmlHttpRequest
- mozAnon will be set ⓘ
- Request will be sent without cookies or authentication headers.
- Cookies sent back in the response will be removed by FireMonkey

pintassilgo · 2021-11-04T14:51:57Z

It looks good, thank you.

Just one detail:

Both VM and TM don't "replace original Firefox cookies". Instead, they append/merge cookies set in header to original cookies. Example:

Firefox has the cookies number=1; abc=def for example.com.

headers: { 'cookie': 'number=3' }

Both VM and TM send number=1; abc=def; number=3. Usually the last value is used, so in the end user set cookie replaces original cookie in the request. For better compatibility with existing scripts and authors habits, FM should follow this.

But it would be good if there's also a way to do what you described: remove default cookies and send just the cookies set in header. You could implement the property mergeCookies to both GM_fetch and GM_xmlhttpRequest, default true to follow what TM and VM do.

Jfyi, still today Firefox works that way, there's a aMerge parameter to decide if the set header value should be passed cleanly or just appended to any existing value:
https://searchfox.org/mozilla-central/rev/88cd13997fb0747cdcd78638fc762ff2d75e1fc5/netwerk/protocol/http/nsIHttpChannel.idl#120-150

It would be a good feature for FM to have, an advantage over the others.

erosman · 2021-11-04T15:53:54Z

Instead, they append/merge cookies set in header to original cookies.

TBH, I have been asking around about Firefox merging multiple cookie entries but got no answer.

It appears that:

In HTTP 1 (RFC 6265) duplicate cookie headers are not allowed
In HTTP/2 (RFC 7540) they are allowed

Are multiple Cookie headers allowed in an HTTP request?
Are Duplicate HTTP Response Headers acceptable?

When testing, Firefox appear to only send one entry so only one of these are sent:

[
  {"name": "Cookie", "value": "hello=there"},
  {"name": "Cookie", "value": "good=bye"}
]

It would have been a lot easier to merge if Firefox would merge them.

Merging the cookies manually is possible but adds more async processing.

It would be a good feature for FM to have, an advantage over the others.

Let me see what can be done ....

pintassilgo · 2021-11-04T16:11:56Z

Never seen something like two cookie headers, I think you should avoid dealing with this. Even if it's somewhat allowed, probably most of the servers can't handle them properly. I was talking about merging the value of the same header.

From what I understood from your update in Help, FM will replace cookie header entirely when cookie is set in headers object. I said that FM should merge the value in headers with existing cookies from that website. But it will still be a single cookie header, just the value is merged.

And I suggested a new flag (default off) to allow to effectively replace cookie header value instead of merging.

pintassilgo · 2021-11-04T16:21:39Z

Merging the cookies manually is possible but adds more async processing.

FM will manually set cookies anyway, right? This is needed to, for example, send container cookies when in a container tab.
VM example

So I don't think it would add more processing. Simply put, currently (already written code for next version) it's:

cookies = headers.cookie || defaultCookies;

I'm suggesting to be something like

cookies = mergeCookies ? defaultCookies + ';' + headers.cookie : headers.cookie;

or

cookies = (mergeCookies ? defaultCookies + ';' : '') + headers.cookie;

Processing is the same.

erosman · 2021-11-04T16:26:00Z

And I suggested a new flag (default off) to allow to effectively replace cookie header value instead of merging.

Yes.. flag with default off would be better... replaceCookie | soleCookie | exclusiveCookie | ... ????

So I don't think it would add more processing.

ATM, FM doesn't get the cookies if userscript has set them.. but to merge, it has to get it first.

pintassilgo · 2021-11-04T16:37:38Z

ATM, FM doesn't get the cookies if userscript has set them.

Right. But the most common and default is to get them. Because most requests in UserScripts doesn't set cookie, and the default of every UserScript manager (including FM starting from next version) is to get and set existing cookies from tab context.

So it's not that it would add overhead, it will just do what it usually does.

erosman · 2021-11-04T16:56:10Z

Because most requests in UserScripts doesn't set cookie, and the default of every UserScript manager (including FM starting from next version) is to get and set existing cookies from tab context.

ATM,

if tab is in normal mode, and userscript doesn't set 'cookie', FM does nothing and lets Firefox handle it
if tab is in container/incognito mode, then FM gets the cookies and replaces Firefox cookies since Firefox will send normal mode cookies

pintassilgo · 2021-11-04T17:15:37Z

Ah, right, I forgot that Fx send normal cookies by default.

Looks like VM sends cookies even in normal tabs and this was never a problem. FM is already more efficient by not needing do get cookies for normal tabs. When the request has headers.cookie, FM should keep compatibility with other engines by merging cookies instead of replacing the header entirely. And I suggest to allow the mergeCookies conditional for the script to be able to replace the header entirely if it wants.

erosman · 2021-11-04T17:26:18Z

I suggest to allow the mergeCookies conditional for the script to be able to replace the header entirely if it wants.

If the default is going to be merge, it would be better to have a flag that is NOT the default so only check if it is true (not if it is false). e.g.

// mergeCookies with default false
if (init.hasOwnProperty('mergeCookies') && init.mergeCookies === false) { 
  // dont merge
}

// noMergeCookies with default true
if (init.noMergeCookies) { 
  // dont merge
}

FM is already more efficient by not needing do get cookies for normal tabs.

You can also set xmlHttpRequest {withCredentials} & fetch {credentials} in FM while VM|TM don't have the options.

Actually .... I might be able to use withCredentials/credentials for merge/noMerge .. let me think.

pintassilgo · 2021-11-04T18:43:48Z

If the default is going to be merge, it would be better to have a flag that is NOT the default so only check if it is true

OK.

Actually .... I might be able to use withCredentials/credentials for merge/noMerge .. let me think.

If you don't want to create a new property, you may use anonymous instead of withCredentials/credentials to not mess with an official property. Both VM and TM support anonymous to not send cookies and it's not part of XMLHttpRequest or fetch official spec.

Also... for instance, withCredentials default is false, but other UserScript engines send cookie by default (and merge headers.cookie), so you shouldn't use this or you'll break compatibility with scripts tested in other engines.

pintassilgo · 2021-11-04T19:00:23Z

So you propose to not send cookies by default? This is different from what you was proposing, also from how FM always behaved, not to mention other engines. Well, it's up to you. I understand your argument that other engines aren't following the spec. After all, no one is following because XMLHttpRequest doesn't allow to set cookie, doesn't allow cross-requests...

The only thing here is that this way you would increase FM's script incompatibility. There is already a lot of native incompatibility due to specificities of Fx's userScripts API, I use FM knowing that. I wouldn't recommend increasing this problem unnecessarily. But I understand your point.

erosman · 2021-11-04T19:05:51Z

Actually, on testing, Firefox sends cookies all the time on XHR and withCredentials doesn't make any difference since FM background page is regraded as same-site requests.

So I have to rethink that.

pintassilgo · 2021-11-04T19:11:35Z

Yes. I forgot that. This explains why UserScripts were always that way.

I guess the compatibility of some scripts is now safe in FM upon this fact. 🤭

So... reuse anonymous or implement noMergeCookies. Or do you have a third option?

erosman · 2021-11-04T19:21:41Z

anonymous is already done and I may reuse it for merge/noMerge.

anonymous + no userscript cookie = no cookie at all
anonymous + userscript cookie = only userscript cookie
userscript cookie => merge with Firefox cookies

In other words, merge all the time unless anonymous is set to true.

I need to update Help 🤦‍♂️

GM Fetch credentials -> omit works, same-origin (default) & include have the same result
GM XMLHttpRequest withCredentials -> no effect, i.e always sends

erosman · 2021-11-05T06:50:36Z

It is all done for v2.35

FireMonkey gets Firefox container/incognito cookies, when in container/incognito
anonymous will apply to Firefox cookies only
Userscript cookies will merge with Firefox cookies

Therefore .....

not anonymous = merge Firefox + userscript cookies
anonymous = only userscript cookies

erosman · 2021-11-07T11:02:39Z

Cookie Isolation also implemented in GM.download/GM_download.

pintassilgo · 2021-12-16T03:42:28Z

Are you planning on implement per-container UserScripts¹? It will be a major FireMonkey advantage.

I've seen users asking about restricting extensions per container, and with that feature FM will be able to accommodate many cases.

¹: bug 1738567 will be fixed soon, I know you're following

erosman · 2021-12-16T05:55:06Z

Are you planning on implement per-container UserScripts¹?

Yes ..... it will probably be for Firefox 97+ (release date 2022-02-08)

A metadata entry format has to be decided for it. Maybe something like this:

@container          firefox-default|firefox-container-1|firefox-container-2 ...|firefox-private

or ...

@container          default|container-1|container-2 ...|private

Note:

Container names are changeable so they cant be used
Invalid container values will cause a throw (https://hg.mozilla.org/mozilla-central/rev/9262f55fbcd6#l4.33)
If container is not present or deleted in a session, userscript will no longer match anything
UserScript developers will not know if & how containers are set up by the user, therefore @container will be most useful as User metadata

erosman · 2021-12-17T15:57:25Z

v2.41
Added container support for Firefox 97+

Note
ATM, option is only available for contentScripts.register (Bug 1470651) (used by FM for userCSS), but hopefully it will become available for userScripts.register shortly (Bug 1738567) (used by FM for userScript).

container (Firefox 97+)
Setting one or more entries will further limit the script/CSS URL matching to certain contextual identity containers e.g. default|private|container-1|container-2|...

no container
inject into all tabs
default
inject only into non-private, non-container tabs
private
inject only into private tabs
private only works if user has allowed the extension to run in private mode.
container-N
inject only into Firefox container-N tabs

Metadata Block

@container          container-1
@container          private

User Metadata

@disable-container 

@container

erosman added the feature request 💡 New feature or request label Oct 30, 2021

erosman added the more feedback needed Extra attention is needed label Oct 31, 2021

erosman added the done ✓ Completed label Nov 2, 2021

erosman closed this as completed Nov 5, 2021

erosman mentioned this issue Jan 14, 2022

Firemonkey: 4chan-x incompatibility? #408

Closed

erosman added the addon: FireMonkey label Mar 30, 2023

erosman mentioned this issue Aug 7, 2024

Proposal: Incognito parameter in userScripts API w3c/webextensions#669

Open

[FireMonkey] should honor current container cookies #378

[FireMonkey] should honor current container cookies #378

Comments

pintassilgo commented Oct 30, 2021 • edited Loading

erosman commented Oct 30, 2021 • edited Loading

pintassilgo commented Oct 30, 2021 • edited Loading

erosman commented Oct 30, 2021 • edited Loading

erosman commented Oct 30, 2021

pintassilgo commented Oct 31, 2021

erosman commented Nov 1, 2021

erosman commented Nov 2, 2021

erosman commented Nov 2, 2021 • edited Loading

GM xmlHttpRequest/fetch Cookies

pintassilgo commented Nov 2, 2021 • edited Loading

erosman commented Nov 2, 2021 • edited Loading

pintassilgo commented Nov 2, 2021 • edited Loading

erosman commented Nov 2, 2021 • edited Loading

pintassilgo commented Nov 3, 2021 • edited Loading

erosman commented Nov 3, 2021

pintassilgo commented Nov 3, 2021

erosman commented Nov 3, 2021

pintassilgo commented Nov 3, 2021 • edited Loading

erosman commented Nov 3, 2021

pintassilgo commented Nov 3, 2021

erosman commented Nov 3, 2021 • edited Loading

GM xmlHttpRequest/fetch Cookies

pintassilgo commented Nov 3, 2021

erosman commented Nov 3, 2021

Set-Cookie Reference:

pintassilgo commented Nov 3, 2021

pintassilgo commented Nov 3, 2021

erosman commented Nov 3, 2021

erosman commented Nov 3, 2021

erosman commented Nov 4, 2021

Cookies Isolation

pintassilgo commented Nov 4, 2021 • edited Loading

erosman commented Nov 4, 2021

pintassilgo commented Nov 4, 2021 • edited Loading

pintassilgo commented Nov 4, 2021 • edited Loading

erosman commented Nov 4, 2021

pintassilgo commented Nov 4, 2021

erosman commented Nov 4, 2021

pintassilgo commented Nov 4, 2021

erosman commented Nov 4, 2021 • edited Loading

pintassilgo commented Nov 4, 2021 • edited Loading

pintassilgo commented Nov 4, 2021 • edited Loading

erosman commented Nov 4, 2021

pintassilgo commented Nov 4, 2021 • edited Loading

erosman commented Nov 4, 2021 • edited Loading

erosman commented Nov 5, 2021

erosman commented Nov 7, 2021

pintassilgo commented Dec 16, 2021 • edited Loading

erosman commented Dec 16, 2021

erosman commented Dec 17, 2021

pintassilgo commented Oct 30, 2021 •

edited

Loading

erosman commented Oct 30, 2021 •

edited

Loading

pintassilgo commented Oct 30, 2021 •

edited

Loading

erosman commented Oct 30, 2021 •

edited

Loading

erosman commented Nov 2, 2021 •

edited

Loading

pintassilgo commented Nov 2, 2021 •

edited

Loading

erosman commented Nov 2, 2021 •

edited

Loading

pintassilgo commented Nov 2, 2021 •

edited

Loading

erosman commented Nov 2, 2021 •

edited

Loading

pintassilgo commented Nov 3, 2021 •

edited

Loading

pintassilgo commented Nov 3, 2021 •

edited

Loading

erosman commented Nov 3, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

erosman commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Nov 4, 2021 •

edited

Loading

erosman commented Nov 4, 2021 •

edited

Loading

pintassilgo commented Dec 16, 2021 •

edited

Loading