Bugzilla

Comment 6

•

5 years ago

(In reply to Firefox User from comment #0)

In previous versions of Firefox, one could block all cookies by default and then whitelist individual domains without issue, even with FirstPartyIsolation. However, enabling FirstPartyIsolation in Firefox 69.0a1 while cookies are set to be blocked by default breaks the Cookies and Site Data Exceptions feature.

Steps to reproduce:

Clean install Firefox 69.0a1 (currently Nightly)

Set privacy.firstparty.isolate=true in about:config

Set network.cookie.cookieBehavior=2 in about:config

Use "manage permissions" to whitelist https://www.amazon.com in about:preferences#privacy

Visit https://www.amazon.com and attempt to log in

Observe Amazon's error message "Please Enable Cookies to Continue"

Observe that cookies cannot be created for the whitelisted site

Observe that clicking the Information bubble in the Address Bar and expanding Cookies under Content Blocking lists https://www.amazon.com as blocked, even though it identifies that there's an exception for the domain (and provides the option to delete the exception).

I think this is a true regression. I suspect in this code:
https://searchfox.org/mozilla-central/source/browser/components/preferences/permissions.js#207
We're not checking if FPI is enabled; and if it is adding the permission with the correct OA.
Previously that would be find because we weren't isolating permissions by OA, but now we are so the permission is not found when it is queried.

Maybe Tim or Gary can confirm.

In addition, enabling just FirstPartyIsolation (without cookie blocking) breaks some third-party extensions, such as Brief (an RSS reader), that utilize a local SQL-Lite DB.

Steps to reproduce:

Clean install Firefox 69.0a1 (currently Nightly)

Set privacy.firstparty.isolate=true in about:config

Install the extension "Brief" from https://addons.mozilla.org/

Observe that any existing subscribed feeds are not listed within Brief's feed reader UI

Observe that none of the buttons within the extension's feed reader UI function

Observe the console output within Brief's feed reader UI cites an inability to open/read its own DB

... a subsequent restart of Firefox fixes the broken extensions as well.

I think this is conflating two things (the recent permission changes and web extensions interacting with FPI). I don't think this is a bug in Firefox (maybe it's an enhancement request for Brief though).

Web Extensions that grab cookies from the cookie jar normally have not handled the case of FPI. This means that they get cookies from the user's default cookie jar. As long as you logged into the service in question before you enabled FPI, the Web Extension works fine because it's grabbing your cookie from the non-FPI cookie jar. But if you haven't logged into the service in question before enabling FPI, then the Web Extension won't find the cookie in the non-FPI cookie jar, because it's only in the FPI cookiejar.

The Web Extension needs to first check if you have FPI enabled; and then get the cookies out of the FPI cookie jar, by specifying the correct origin attributes. I think the documentation for this is here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#First-party_isolation

Flags: needinfo?(dennis.lissov)

Denis Lisov

Comment 7

•

5 years ago

In addition, enabling just FirstPartyIsolation (without cookie blocking) breaks some third-party extensions, such as Brief (an RSS reader)

Looks like in Brief's case the main problem appears at initialization time due to a weird failure mode of the old {storage: "persistent"} database. After fixing that one, there will be probably the cookies-related problem (Brief uses standard XHR without any tricks, which probably means the default FPI cookies will have the Brief's moz-extension origin as the firstPartyDomain unless explicitly overridden, correct?).

There's also the question mentioned in bug 1554805 of whether the extension can access the same IndexedDB instance both in FPI and non-FPI mode (apart from dirty racy tricks like "disable FPI, open a tab, enable FPI and query the DB via that tab without reloading it).

Flags: needinfo?(dennis.lissov)

Tim Huang[:timhuang]

Comment 8

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #6)

(In reply to Firefox User from comment #0)

In previous versions of Firefox, one could block all cookies by default and then whitelist individual domains without issue, even with FirstPartyIsolation. However, enabling FirstPartyIsolation in Firefox 69.0a1 while cookies are set to be blocked by default breaks the Cookies and Site Data Exceptions feature.

Steps to reproduce:

Clean install Firefox 69.0a1 (currently Nightly)

Set privacy.firstparty.isolate=true in about:config

Set network.cookie.cookieBehavior=2 in about:config

Use "manage permissions" to whitelist https://www.amazon.com in about:preferences#privacy

Visit https://www.amazon.com and attempt to log in

Observe Amazon's error message "Please Enable Cookies to Continue"

Observe that cookies cannot be created for the whitelisted site

Observe that clicking the Information bubble in the Address Bar and expanding Cookies under Content Blocking lists https://www.amazon.com as blocked, even though it identifies that there's an exception for the domain (and provides the option to delete the exception).

I think this is a true regression. I suspect in this code:
https://searchfox.org/mozilla-central/source/browser/components/preferences/permissions.js#207
We're not checking if FPI is enabled; and if it is adding the permission with the correct OA.
Previously that would be find because we weren't isolating permissions by OA, but now we are so the permission is not found when it is queried.

Maybe Tim or Gary can confirm.

Yes, you are correct here. Tom. It is because of that the permission manager of preferences only adds cookie permission for the default OA. However, the cookie service will check the permission with firstPartyDomain if FPI is enabled after bug 1330467. And there will be no cookie permission for that.

I don't have a good idea for resolving this issue. One possible solution is that we can allow setting firstPartyDomain in permission manager, but it would bring another issue; It is impossible to list all possible firstPartyDomains beforehand since the firstPartyDomain could be different according to how the page has been loaded.

Or we can add the same domain as the firstPartyDomain. For example, we keyed "amazon.com" as firstPartyDomain when adding cookie permission for "amazon.com" if FPI is enabled. This would resolve the issue for the top-level loads since the firstPartyDomain and the loading URL should have the same domain in this case. However, the problem will still remain for the case that "amazon.com" is loading under other firstPartyDomains.

One last solution is that we fall back to the old behavior for cookie permission only. But I doubt that this is a good approach.

Flags: needinfo?(tihuang)

Christoph Kerschbaumer [:ckerschb]

Comment 9

•

5 years ago

(In reply to Tim Huang[:timhuang] from comment #8)

Yes, you are correct here. Tom. It is because of that the permission manager of preferences only adds cookie permission for the default OA. However, the cookie service will check the permission with firstPartyDomain if FPI is enabled after bug 1330467. And there will be no cookie permission for that.

I don't have a good idea for resolving this issue. One possible solution is that we can allow setting firstPartyDomain in permission manager, but it would bring another issue; It is impossible to list all possible firstPartyDomains beforehand since the firstPartyDomain could be different according to how the page has been loaded.

Or we can add the same domain as the firstPartyDomain. For example, we keyed "amazon.com" as firstPartyDomain when adding cookie permission for "amazon.com" if FPI is enabled. This would resolve the issue for the top-level loads since the firstPartyDomain and the loading URL should have the same domain in this case. However, the problem will still remain for the case that "amazon.com" is loading under other firstPartyDomains.

One last solution is that we fall back to the old behavior for cookie permission only. But I doubt that this is a good approach.

Hm. I think we need to find who owns this component and what they think acceptable solutions would be. Going to start with Johann and maybe he can direct.

My first thought is
a) Regardless of the FPI status, when an exception is added, add two entries: one for the non-FPI domain and one for the FPI domain (foo.com|foo.com)
b) For the third party context perhaps we could add an entry like *|foo.com and then update the code to check for the presence of that permission also?

Flags: needinfo?(jhofmann)

Tim Huang[:timhuang]

Comment 10

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #9)

Hm. I think we need to find who owns this component and what they think acceptable solutions would be. Going to start with Johann and maybe he can direct.

My first thought is
a) Regardless of the FPI status, when an exception is added, add two entries: one for the non-FPI domain and one for the FPI domain (foo.com|foo.com)
b) For the third party context perhaps we could add an entry like *|foo.com and then update the code to check for the presence of that permission also?

A wildcard approach like this is interesting. But I am wondering that if this opens a tracking factor for the given domain. However, I think this is fine since the permission is given by users and only affect the domain that is given here.

Comment 11

•

5 years ago

Tom, we are triaging dom-sec bugs at the moment. Is this really a regression which we should fix within this cycle as mentioned in comment 6? If so, it needs to be a P1, right? What do you think?

Flags: needinfo?(tom)

Updated

•

5 years ago

Flags: needinfo?(tom)

Summary: Regression in FirstPartyIsolation breaks both websites and extensions → Per-Domain Cookie Permissions are broken with FPI enabled

Comment 12

•

5 years ago

Why don't we treat permission entries with principals that have stripped firstPartyDomain as a backup to fPD-powered permission entries (so that they apply even when there's no permission with fPD attribute)?

As far as I know first-party principals have their own baseDomain as fPD, so we could selectively strip fPD in only a few places where it makes sense before adding the permission to perm manager, e.g. the cookie settings.

Thoughts? :)

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(jhofmann)

Comment 13

•

5 years ago

(In reply to Johann Hofmann [:johannh] from comment #12)

Why don't we treat permission entries with principals that have stripped firstPartyDomain as a backup to fPD-powered permission entries (so that they apply even when there's no permission with fPD attribute)?

We could do that; but I don't think there would be any way to actually add permission entries with a fPD attribute.

As far as I know first-party principals have their own baseDomain as fPD, so we could selectively strip fPD in only a few places where it makes sense before adding the permission to perm manager, e.g. the cookie settings.

Thoughts? :)

Yeah, basically there's two reasonable options in my mind:

When you add a permission in the UI, add it with non-FPD and FPD attributes; but don't change the permission check (which will use either non-FPD or FPD depending on the pref)
Change the permission check to strip FPD; and don't change the perm addition in the UI.

Sounds like you favor (2).

Updated

•

5 years ago

Flags: needinfo?(jhofmann)

BugBot [:suhaib / :marco/ :calixte]

Comment 14

•

5 years ago

Yeah, well, the permission check should not unconditionally strip FPD, since most interfaces would still add principals with FPD (permission doorhangers etc.). I'm thinking that we could fall back to looking up the stripped principal in case no entry could be found. Then we just need to make sure that the stripped versions are only really added where it makes sense to apply the permission across FPI, e.g. in the cookies dialog.

Maybe there's some downside to that suggestion but I can't see it right now.

Flags: needinfo?(jhofmann)

Comment 15

•

5 years ago

The priority flag is not set for this bug.
:ckerschb, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ckerschb)

Christoph Kerschbaumer [:ckerschb]

Updated

•

5 years ago

Flags: needinfo?(ckerschb)

Priority: -- → P3

Whiteboard: [domsecurity-backlog1]

(no longer active)

Comment 16

•

5 years ago

Do we need to apply this fix to all permissions or just to "cookie" permissions?

I'm asking because for "cookie" permissions there's (in theory) now only one place in the code base where we check them, so it should be possible to implement suggestion 2 from comment 13 there quite easily...

Comment 17

•

5 years ago

(In reply to :Ehsan Akhgari from comment #16)

Do we need to apply this fix to all permissions or just to "cookie" permissions?

Good thought.

It would apply to any permission the user adds manually. Looking at about:preferences I see the following which could also have the same problem:

Exceptions to Saved Logins (adds to a blocklist)
The popup and addon permissions

My suspicion is that when the user adds anything via that way, we add the entry into the database without a firstPartyDomain attribute and thus it does not take effect. I tested this with popup and confirmed it was the case. (And If I tried adding https://example.com^firstPartyDomain=example.com whooo boy did things get screwy.)

The choice seems to be the same:

Do we change the 'manually add permission' code to add two entries (probably only if FPI is currently enabled)
Do we change the permission checks to perform a fallback check

#1 has the (slight?) advantage of hopefully illustrating to other people messing with the Preferences panel they need to do things special. #2 you'd never know you need a fallback check.

#2 also has the (slight) disadvantage of honoring a permission created (not via the pref pane but just a doorhanger) before FPI was enabled.

But actually there's a third choice:
3) If FPI is enabled add the permission with a firstPartyDomain equal to the top level (and if FPI is not enabled, don't add it with a FPD). This was previously discarded because it doesn't solve the problem of when the domain is loaded not as a top level but as a third party iframe. The permission would not apply then. But maybe we can accept that poor behavior.

I also saw the following. They only allow the user to view and delete entries:

Exceptions to Content Blocking
The Location, Camera, Microphone, Notifications, and Autoplay permissions

Amusingly, some of these the encoded string:

Some of my Notification Permissions have it, eg: "https://sql.telemetry.mozilla.org^firstPartyDomain=mozilla.org" However I have other entries without the firstPartyDomain....
All of my exceptions to Pop-ups have a firstPartyDomain string
None of my auto-play permissions have one.

(no longer active)

Comment 18

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #17)

(In reply to :Ehsan Akhgari from comment #16)

Do we need to apply this fix to all permissions or just to "cookie" permissions?

Good thought.

It would apply to any permission the user adds manually. Looking at about:preferences I see the following which could also have the same problem:

Exceptions to Saved Logins (adds to a blocklist)

The popup and addon permissions

My suspicion is that when the user adds anything via that way, we add the entry into the database without a firstPartyDomain attribute and thus it does not take effect. I tested this with popup and confirmed it was the case. (And If I tried adding https://example.com^firstPartyDomain=example.com whooo boy did things get screwy.)

The choice seems to be the same:

Do we change the 'manually add permission' code to add two entries (probably only if FPI is currently enabled)

Do we change the permission checks to perform a fallback check

Note that not all permissions need to be checked outside of the first-party context similar to the "cookie" permission. I think a general fallback option implemented in the permission manager itself would have the downside that it would work for all permissions no matter what.

#1 has the (slight?) advantage of hopefully illustrating to other people messing with the Preferences panel they need to do things special. #2 you'd never know you need a fallback check.

#2 also has the (slight) disadvantage of honoring a permission created (not via the pref pane but just a doorhanger) before FPI was enabled.

Is #2 a case we want to support?

But actually there's a third choice:
3) If FPI is enabled add the permission with a firstPartyDomain equal to the top level (and if FPI is not enabled, don't add it with a FPD). This was previously discarded because it doesn't solve the problem of when the domain is loaded not as a top level but as a third party iframe. The permission would not apply then. But maybe we can accept that poor behavior.

This isn't always the correct behaviour. For example, it would be the wrong behaviour for the "cookie" permission which needs to be accessible both in the first and third-party context.

I also saw the following. They only allow the user to view and delete entries:

Exceptions to Content Blocking

This one is first-party only, so for example option #3 above could work for it.

The Location, Camera, Microphone, Notifications, and Autoplay permissions

These are all probably different, we'd need to look at each one in detail.

Amusingly, some of these the encoded string:

Some of my Notification Permissions have it, eg: "https://sql.telemetry.mozilla.org^firstPartyDomain=mozilla.org" However I have other entries without the firstPartyDomain....

It'd be interesting to figure out why that is, e.g. if there are call sites accessing this permission using the URI based API as opposed to the principal based API.

All of my exceptions to Pop-ups have a firstPartyDomain string

None of my auto-play permissions have one.

That is weird, and potentially a sign that we're using the URI-based API for those?

Needinfo-ing Gary in case he wants to do some investigation here.

Flags: needinfo?(xeonchen)

Kate Hudson :k88hudson

Updated

•

5 years ago

status-firefox69: affected → fix-optional

Gary Chen [:xeonchen]

Comment 19

•

5 years ago

(In reply to :Ehsan Akhgari from comment #18)

Needinfo-ing Gary in case he wants to do some investigation here.

Thanks, well-noted.

Flags: needinfo?(xeonchen)

sgl4kn

Comment 20

•

5 years ago

Seems that this is affecting the upgrade from FF67 to FF68 as well, where FPI is breaking Greasemonkey:
https://bugzilla.mozilla.org/show_bug.cgi?id=1564593
https://github.com/greasemonkey/greasemonkey/issues/3045

Comment 21

•

5 years ago

(In reply to sgl4kn from comment #20)

Seems that this is affecting the upgrade from FF67 to FF68 as well, where FPI is breaking Greasemonkey:
https://bugzilla.mozilla.org/show_bug.cgi?id=1564593
https://github.com/greasemonkey/greasemonkey/issues/3045

Note, I don't think this is (directly) related to this bug, I think this is Bug 1554805

Updated

•

5 years ago

Updated

•

5 years ago

Comment 26

•

5 years ago

•

Edited

(In reply to :ehsan akhgari from comment #18)

(In reply to Tom Ritter [:tjr] from comment #17)

All of my exceptions to Pop-ups have a firstPartyDomain string

None of my auto-play permissions have one.

That is weird, and potentially a sign that we're using the URI-based API for those?

Needinfo-ing Gary in case he wants to do some investigation here.

I tested this on w3schools, and it shows https://www.w3schools.com^firstPartyDomain=w3schools.com on my autoplay-media permission.
Tom, can you reproduce it or is it possible that those settings are saved before we double keyed permissions?

Today I heard that Thomas is working on permissions that 3rd-party domains may potentially gain permissions from first party domain.
(Maybe Thomas can give us some input here?)
If this happens (and eventually it will), that means we can simply add first party domain info into cookie permissions (when FPI is enabled) to fix this bug (case #3 of comment 17).

Flags: needinfo?(tom)

Flags: needinfo?(tnguyen)

Thomas Nguyen (:tnguyen)

Comment 27

•

5 years ago

•

Edited

I tested this on w3schools, and it shows https://www.w3schools.com^firstPartyDomain=w3schools.com on my autoplay-media permission.
Tom, can you reproduce it or is it possible that those settings are saved before we double keyed permissions?

Today I heard that Thomas is working on permissions that 3rd-party domains may potentially gain permissions from first party domain.
(Maybe Thomas can give us some input here?)

No, I have just jumped in, but fwik, Chrome disallows all third party iframe requests and enables websites to delegate their permissions via Feature-Policy (a part of work I am looking at), no doubled key or anything. I agree it would save a lot of efforts here but I am lost of plan and schedule of when we should complete that.

Flags: needinfo?(tnguyen)

Comment 28

•

5 years ago

Right, feature policy wouldn't apply to cookie permissions so we need a separate solution here.

Updated

•

5 years ago

Flags: needinfo?(tom) → needinfo?(tom)

Comment 29

•

5 years ago

(In reply to Gary Chen [:xeonchen] from comment #26)

(In reply to :ehsan akhgari from comment #18)

(In reply to Tom Ritter [:tjr] from comment #17)

All of my exceptions to Pop-ups have a firstPartyDomain string

None of my auto-play permissions have one.

That is weird, and potentially a sign that we're using the URI-based API for those?

Needinfo-ing Gary in case he wants to do some investigation here.

I tested this on w3schools, and it shows https://www.w3schools.com^firstPartyDomain=w3schools.com on my autoplay-media permission.
Tom, can you reproduce it or is it possible that those settings are saved before we double keyed permissions?

I double checked; and yes if I add the permission when FPI is enabled; I get the encoded string just as you did.

We talked about this a bit in the Uplift meeting and our thinking is:

ETP - We didn't discuss this but it was fixed in Bug 1560623 and it was easy to reason about because it only applies in a first party context.
Popup: If the user adds example.com in the pref pane; we should implement a fallback so popups work when example.com is a first party but not when example.com is a third party.
Warn on Add-Ons: We didn't discuss this one, but I'm in favor of treating it the same as Popup, it should work for first party context but not third party context.
Autoplay: We also didn't discuss this one. (I'm inclined to allow it in third party contexts though...)
Exceptions to Saved Logins: We didn't discuss this one; but because it is a block 'permission' and not an allow, I think it should take effect in both first and third party contexts.
Cookies: If you add example.com in the pref pane, and have FPI enabled, we should implement a fallback so example.com in the first party context. We were kind of torn on whether it should also fallback and allow example.com in a Third Party Context. Doing so would effectively break FPI. Breaking FPI is undesirable, so we'd probably want to be on the safe side? However, the devil's advocate side is that not enabling in a third party context could be confusing to the user and break desired workflows (e.g. "I always want to be logged into twitter across the web, but nothing else.")

I'm going to flag our bug reporters to ask about their desired use case. When you add amazon.com as a cookie exception without FPI enabled, you're allowing it to have cookies in a first and third party context. When you add it as an exception with FPI enabled, do you want all Amazon widgets across the internet to have cookies; or just when you go to amazon.com as a first party?

We'll keep discussing what the path forward is on this one, hopefully user feedback will assist.

Flags: needinfo?(tom)

Flags: needinfo?(ja_account)

Flags: needinfo?(gmx)

Flags: needinfo?(florian)

Flags: needinfo?(durlag.trolltoeter)

Flags: needinfo?(androiduserwithquestions+moz)

Francesco Florian

Comment 30

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #29)

I'm going to flag our bug reporters to ask about their desired use case. When you add amazon.com as a cookie exception without FPI enabled, you're allowing it to have cookies in a first and third party context. When you add it as an exception with FPI enabled, do you want all Amazon widgets across the internet to have cookies; or just when you go to amazon.com as a first party?

For my current use case, I would slightly prefer the safe option (just get the cookie when the site is the first party), but both would be acceptable.
I can however think of use case when the other alternative is preferable.
Would it be a lot of work to make it an option?
Ideally it should be a per-cookie option, but also one in about:config, without having to change the UI would better than no choice at all.

Referring to a previous part of your comment:

We were kind of torn on whether it should also fallback and allow example.com in a Third Party Context. Doing so would effectively break FPI. Breaking FPI is undesirable, so we'd probably want to be on the safe side? However, the devil's advocate side is that not enabling in a third party context could be confusing to the user and break desired workflows (e.g. "I always want to be logged into twitter across the web, but nothing else.")

I would say that breaking FPI is undesirable, unless it can be set per-cookie.

Flags: needinfo?(florian)

David

Comment 31

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #29)

I'm going to flag our bug reporters to ask about their desired use case. When you add amazon.com as a cookie exception without FPI enabled, you're allowing it to have cookies in a first and third party context. When you add it as an exception with FPI enabled, do you want all Amazon widgets across the internet to have cookies; or just when you go to amazon.com as a first party?

model A: all Amazon widgets get their own FPI cookie
model B: only amazon.com gets an FPI cookie

My current understanding of FPI was based on model A. I haven't given it much thought beyond that. I'm honestly not sure I have a use case where I actually need model A. I don't use any centrally authenticated logins (Facebook, Google, etc) and if all separate FPI cookies would do is isolate me from tracking, they might as well be blocked (model B). But like Francesco I can envision someone wanting select sites to have cookies parallel to the main site.

Some ideas:
Concern 1 - size: If one needed persistent cookies on Google, Facebook or Amazon domains, then FPI under model A would probably quickly pile up hundreds if not thousands of useless cookies from sites all across the web.

Concern 2 - consistency. My use case is generally blocking cookies while whitelisting a select few domains. But the exception list also works the other way, where you might generally allow cookies and block or limit to session a select few. For blacklisting the model B approach is obviously nonsensical. If I block amazon.com I don't just want to block the FPI cookie from literally amazon.com, but all Amazon cookies. At a glance I think it might be more consistent to have whitelisting and blacklisting have the same scope.

Concern 3 - usability: A salient question is perhaps, whether FPI will ever be rolled out to a general audience. It might be prudent to pick the model that least breaks the average user experience, so if FPI ever became enabled by default, adoption would be as smooth as possible. The use cases of us few, extremely privacy-concious power-users might not be representative. This problem might extend to the usability of an interface to handle exceptions, like Francesco proposes:
I would love a manual list with masked exceptions where an entry might look like: for ".google.com" allow cookie access on ".google.com, .example.com, bugzilla.mozilla.org". An entry like "accounts.google.com" on "accounts.google.com" would be strict FPI under model B while an entry like ".google.com" on "*" would be full model A. And if you only needed the main domain and one other you could easily do that.
But such a list is probably not easily accessible or understandable for an average user, so if FPI is ever planned to become a standard feature it might be prudent to pick between model A and B and just stick with it.

Sidenote: If the aforementioned list approach of defining which domains get access to a certain domain's cookies became the general way of doing cookies (meaning without FPI enabled), it would probably solve most use cases people now use FPI as a crutch for. The use case where you whitelist domains 1 and 2 and need them to get different domain 1 cookies seems fairly limited (you probably want domain 2 to recognize a login on domain 1, which would track you from domain 1's perspective regardless of FPI). Most users would probably prefer domains 1 and 2 get the same domain 1 cookie (meaning no FPI), but isolate that cookie from all other domains from whose perspective domain 1 cookies should appear blocked to prevent tracking.

Flags: needinfo?(durlag.trolltoeter)

Comment 32

•

5 years ago

Oh geez, I definitely screwed up my explanation. You are correct. I conflated cookie jars with the permission. We don't want to break FPI that badly. Let me try to damage control my earlier explanation.

Without FPI; if you block cookies but grant an exception to example.com; example.com will be able to read from one cookie jar in a first and third party context.

With FPI; if you block cookies but grant a (permanent*) exception to example.com; then example.com will still be segmented into separate cookie jars. example.com in a first party context should get the exception and be able to access it's first party cookie jar - because you granted it an exception. The question is therefore: should example.com also get (persistent*) access to first-party-isolated cookie jars in a third party context?

* I say permanent/persistent just as an example; you can replace these with the other permission types of allow for a session or block.

Having corrected myself; I think the answer is that it should not have the permission apply in a third party context. You're not going to be logged in to example.com anyway, because it has it's own FP-Isolated cookie jar.

Arthur, what do you think?

Flags: needinfo?(arthur)

Francesco Florian

Comment 33

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #32)

The question is therefore: should example.com also get (persistent*) access to first-party-isolated cookie jars in a third party context?

This means that example.com will get access to one cookie jar when embedded in example2.com, and a different jar when in example3.com?
If this is the case, my answer would be the same: for my use case is almost irrelevant, an option to toggle it would be nice (preferably on the individual cookies), and probably the default should be allowing access to third party frames.

(In reply to David from comment #31)

Concern 3 - usability: A salient question is perhaps, whether FPI will ever be rolled out to a general audience.

If you consider torbrowser to be general audience, FPI is on by default there already.

Gary Chen [:xeonchen]

Comment 34

•

5 years ago

(In reply to Tom Ritter [:tjr] from comment #32)

With FPI; if you block cookies but grant a (permanent*) exception to example.com; then example.com will still be segmented into separate cookie jars. example.com in a first party context should get the exception and be able to access it's first party cookie jar - because you granted it an exception. The question is therefore: should example.com also get (persistent*) access to first-party-isolated cookie jars in a third party context?

My understanding of your description is:

Not saving first-party info in the preferences page, unlike other permission settings.
The exception allows the given domain to save cookies regardless loaded as first-party or third-party domain.
Decide there's only one cookie jar or many cookie jars for the given domain when FPI is enabled

Did I miss anything?

Arthur Edelstein [:arthur]

Comment 35

•

5 years ago

(In reply to Gary Chen [:xeonchen] from comment #34)

(In reply to Tom Ritter [:tjr] from comment #32)
My understanding of your description is:

Not saving first-party info in the preferences page, unlike other permission settings.

No; I think we leave the preferences page alone. Where we perform the permission check on cookies - and FPI is enabled - instead of querying for http://example.com^firstPartyDomain=example.com we will do something like this:

nsIURI addressBarUri;
if (firstPartyIsolationIsEnabled()) {
    nsAutoCString uriHost;
    addressBarUri->GetAsciiHost(&uriHost);
    if (uriHost == originAttributes.firstPartyDomain) {
        //This domain is in the first party context - we want to ignore the First Party Domain when we do the permission check
        performPermissionCheckForUri(addressBarUri)
    } else {
        // This domain is in the third party context. Do not perform the permission check at all.
    }
} else { 
    // Existing behavior
    performPermissionCheckForUri(addressBarUri)
}

This will also be the same behavior for Popup, and probably Warn on Addons.

The exception allows the given domain to save cookies regardless loaded as first-party or third-party domain.

The opposite, this behavior should only allow the given domain to save cookies if loaded as a first party domain.

Decide there's only one cookie jar or many cookie jars for the given domain when FPI is enabled

We definitely keep the separate cookie jars for FPI like we do currently.

Comment 39

•

5 years ago

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories]) from comment #32)

Having corrected myself; I think the answer is that it should not have the permission apply in a third party context. You're not going to be logged in to example.com anyway, because it has it's own FP-Isolated cookie jar.

Arthur, what do you think?

I agree, on the principle that we want Permissions to be first-party isolated.

Flags: needinfo?(arthur)

Updated

•

5 years ago

Updated

•

5 years ago

Comment 40

•

5 years ago

(Stealing the component)

Paul, since we're seeing this in a slightly more supported configuration with bug 1591748 now (which was caused by your permissions OA changes), would you feel motivated to take this bug? Despite all the comments I think we can solve this in a good way. I'm happy to work through them with you.

Thanks!

Component: DOM: Security → Permission Manager

Flags: needinfo?(pbz)

Comment 41

•

5 years ago

Sure!

Assignee: nobody → pbz

Status: NEW → ASSIGNED

Flags: needinfo?(pbz)

Comment 42

•

5 years ago

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories/cve's]) from comment #35)

The opposite, this behavior should only allow the given domain to save cookies if loaded as a first party domain.

This would be quite novel and it would break several cases where users are explicitly allow-listing third parties to fix breakage. If users want to fix restrictions on a single first-party page, they can use the trackingprotection exception. So, we need to apply this to everyone, both first party and third party (and it's the better solution, IMO).

I agree, however, that we can just solve this by stripping the principal when performing the permission check. That should be quite easy.

Comment 43

•

5 years ago

Attached file Bug 1556212 - nsPermissionMgr: Added principal oa strip permission list. r=ehsan (obsolete) — Details

Comment 44

•

5 years ago

Attached file Bug 1556212 - Added test for oa strip permission list. r=ehsan (obsolete) — Details

Depends on D53191

Comment 45

•

5 years ago

Attached file Bug 1556212 - nsPermissionMgr: Added principal oa strip permission list. r=ehsan (obsolete) — Details

Comment 46

•

5 years ago

Attached file Bug 1556212 - Added test for oa strip permission list. r=ehsan (obsolete) — Details

Depends on D53251

Updated

•

5 years ago

Attachment #9109114 - Attachment is obsolete: true

Updated

•

5 years ago

Attachment #9109113 - Attachment is obsolete: true

Updated

•

5 years ago

Attachment #9109033 - Attachment is obsolete: true

Updated

•

5 years ago

Attachment #9109034 - Attachment is obsolete: true

Comment 47

•

4 years ago

Unassigning, see https://phabricator.services.mozilla.com/D53191#1640700

Assignee: pbz → nobody

Status: ASSIGNED → NEW

Updated

•

4 years ago

Comment 50

•

4 years ago

Confirming this bug is still unresolved as of Firefox 84.0a1 (2020-11-14)

bokeron2020

Comment 51

•

3 years ago

Firefox 89.0.2 - still unresolved.

I can't understand why this isn't given prority. It's a bug that brokes one of the most immediate settings in the UI - allow or deny cookies from a given site. There are underlying problems that surely get in the way to fix this bug... but the first impression is "What? This doesn't work? Firefox is not worth it".
So far the only alternative offered is to deactivate a security measure. And still this isn't a priority?

BugBot [:suhaib / :marco/ :calixte]

Comment 52

•

3 years ago

(In reply to bokeron2020 from comment #51)

I can't understand why this isn't given prority.

First Party Isolation is not a supported feature of Firefox; it's included to make it easier for the Tor Project to maintain their browser.

You want to disable FPI in about:config and set Enhanced Trackign Protection to 'Strict' in Settings-> Privacy and Security. This will enable Dynamic FPI which is very similar to FPI, and is a supported feature.

Comment 53

•

2 years ago

Clear needinfos that are pending on inactive users.

For more information, please visit auto_nag documentation.

Flags: needinfo?(ja_account)

Flags: needinfo?(gmx)

Flags: needinfo?(androiduserwithquestions+moz)

BMO Automation

Updated

•

2 years ago

Severity: normal → S3

BugBot [:suhaib / :marco/ :calixte]

Comment 54

•

2 years ago

The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates and 5 See Also bugs.
:timhuang, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(tihuang)