Closed Bug 1601569 Opened 4 years ago Closed 3 years ago

unable to use enterprise policies.json to allow notifications when using first party isolation

Categories

(Firefox :: Enterprise Policies, defect, P5)

Product:
Firefox
Component:
Enterprise Policies
Version:
70 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: southwindcg, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

privacy.firstparty.isolate set to true
login at protonmail.com (for example)
allow notifications for https://mail.protonmail.com when prompted
Settings - Notification Permissions displays https://mail.protonmail.com^firstPartyDomain=protonmail.com
Remove All Websites and Save Changes
enter "https://mail.protonmail.com^firstPartyDomain=protonmail.com" in appropriate location of Linux policies.json and restart Firefox

Actual results:

Settings - Notification Permissions not populated and ProtonMail asks for permission to send notifications again

Expected results:

Settings - Notification Permissions should display https://mail.protonmail.com^firstPartyDomain=protonmail.com and the site should not ask for permission again

Note that placing https://mail.protonmail.com in policies.json is not enough to prevent being asked again and having https://mail.protonmail.com^firstPartyDomain=protonmail.com appear in Settings - Notification Permissions.

I am attempting to confirm your issue, but I need more information on the step of <<enter "https://mail.protonmail.com^firstPartyDomain=protonmail.com" in the appropriate location of Linux policies.json and restart Firefox>>
How do I do that in Ubuntu 16 or 18? Can you provide some steps or a tutorial on how to add that link to the "appropriate location of Linux policies.json"?

Thank you for your contribution!

Component: Untriaged → Site Permissions
Flags: needinfo?(southwindcg)

Yes, Linux uses a file in the following location: /usr/lib/firefox/distribution/policies.json

Specifically for allowing notifications in this protonmail.com example, the file's contents would look like this:

{
"policies": {
"Permissions": {
"Notifications": {
"Allow": ["https://mail.protonmail.com"],
"Allow": ["https://mail.protonmail.com^firstPartyDomain=protonmail.com"]
}
}
}
}

The first "Allow" line does populate the settings dialog at about:preferences#privacy > Permissions > Notifications > Settings, but the second line does not. This would be fine when not using privacy.firstparty.isolate, as all sites could be allowed ahead of time by adding them to policies.json, but when privacy.firstparty.isolate is true I can only allow sites to send notifications by first visiting them and waiting for them to ask for permission.

Flags: needinfo?(southwindcg)

I am still unable to confirm it. It appears I am blocked again by the fact that the policies.json file is missing from the <</usr/lib/firefox/distribution/>> location. Is it the right location? Why is it missing? How do I get it created by default? Would be OK if I created it myself?

Has STR: --- → no
Flags: needinfo?(southwindcg)

This is somewhere between permissions and enterprise policies, but the fix/analysis is likely needed on enterprise policy side, so moving to that component.

I would guess that adding origin attributes is simply not supported in the policies file? Mike, can you confirm?

Component: Site Permissions → Enterprise Policies
Flags: needinfo?(mozilla)

(In reply to Bodea Daniel [:danibodea] from comment #3)

I am still unable to confirm it. It appears I am blocked again by the fact that the policies.json file is missing from the <</usr/lib/firefox/distribution/>> location. Is it the right location? Why is it missing? How do I get it created by default? Would be OK if I created it myself?

If I recall correctly, yes it is necessary to create the policies.json file yourself, and that it isn't there by default, much like userContent.css for example.

https://github.com/mozilla/policy-templates indicates that the firefox/distribution folder varies in location depending on Linux distro, but I'm assuming it's the same for Ubuntu as it is for Linux Mint, since Mint is a "child" of Ubuntu.

Flags: needinfo?(southwindcg)

"Allow": ["https://mail.protonmail.com"],
"Allow": ["https://mail.protonmail.com^firstPartyDomain=protonmail.com"]

I assume you don't actually have two Allow lines, you are just comparing?

When you go to about:policies, are there any errors?

This is the first time I've seen https://mail.protonmail.com^firstPartyDomain=protonmail.com as an origin. I'm not sure if they work properly in policy.

Flags: needinfo?(mozilla)

Why wouldn't you just put protonmail.com in Allow?

This looks like the enterprise policy version of Bug 1556212.

Which is to say, if we fix Bug 1556212 (it talks about cookies, but really it's applicable to (a) all permissions the user enters via the Preferences Page and (b) all permissions configurable via the policy as described here) correctly, you would get a safe behavior via a simple policy line ("Allow": ["https://mail.protonmail.com"]) for both FPI mode and non-FPI mode.

We have not fixed Bug 1556212. I don't know if "Allow": ["https://mail.protonmail.com^firstPartyDomain=protonmail.com"] will work today - if it does it's probably because of plumbing unexpectedly and unintentionally connecting the correct bits. If it doesn't, the plumbing is not connected.

There are a lot of nuances here, and we would appreciate your feedback on how you would expect things to work.

My opinion is that we really don't want to require people to write stuff like https://mail.protonmail.com^firstPartyDomain=protonmail.com - goodness gracious that is confusing and ugly. We'd much prefer you write https://example.com and if you have FPI enable - it does what you want.

But the what you want is where the nuance comes in - specifically the difference in behavior for https://example.com as a first party, and https://example.com when it's an iframe in some http://other.com (after all, FPI is partly about the difference in behavior for first and third party contexts).

For the notification permission, it's straightforward: the permission only makes sense in a first party context. But what if you specified the 'Don't Warn on Add-Ons Installation' permission?' I would argue that should apply in the first party context but not the third party context. Would you agree? And then the same question for Popups, Autoplay, Exceptions to Saved Logins, Cookies, and (checks policy documentation) camera, microphone, and geolocation? My thinking is that all of these permissions* should apply only in the first party context and not the third party context. That would be the safe behavior (from a tracking POV) because it prevents example.com from correlating the permission grant when used as a first party and a third party. It would also be a safe behavior from a web POV because I probably don't want to allow - by default - swaths of the internet to be able to do these things if they got maliciously iframed.

* Except 'Exception to Saved Login which is a 'block' permission rather than an 'allow'

However from an enterprise POV I also recognize that it's entirely likely you've got some internal website A that iframes some other internal website B - and B needs camera access and what I just proposed broke your use case. Supporting that behavior in a non-default way may be important. But if no one asks for it I'm not inclined to build it....

To try and give a conclusive status for this bug: What you are trying to do is not currently supported, because FPI is not an explicitly supported feature. We do try to fix bugs in it of course, but we don't have anyone specifically tasked to do so. The fix for it is not trivial, but it's not terrible either. (I think we could mentor someone through the patch.) If you can provide your input on how you think it should behave it will make it easier to implement it better the first time.

See Also: → 1556212

(In reply to Mike Kaply [:mkaply] from comment #7)

Why wouldn't you just put protonmail.com in Allow?
I assume you don't actually have two Allow lines, you are just comparing?

Merely having the domain allowed doesn't work when privacy.firstparty.isolate is set to true. I was asked to approve permission a second time, and then did indeed have the two Allow lines, and no errors.

"Allow": ["https://mail.protonmail.com"],
"Allow": ["https://mail.protonmail.com^firstPartyDomain=protonmail.com"]

No need to pursue this further...

We might still want to find a solution that doesn't require users to input OAs, though IMO the combination enterprise policies + FPI is rare enough to make this quite an edge case.

Priority: -- → P5
Severity: normal → S3

My understanding is we're starting to push out FPI to our regular users soon, so this will start to be more of an issue?

Flags: needinfo?(jhofmann)

(In reply to Mike Kaply [:mkaply] from comment #12)

My understanding is we're starting to push out FPI to our regular users soon, so this will start to be more of an issue?

That is dFPI (State Partitioning) which currently does not affect permissions, so we should be okay. In general I think it’s safe to assume that FPI (in the form that will add OAs to top-level sites) will never ship to a larger number of Firefox users by default.

Flags: needinfo?(jhofmann)

Do you think I should mark this bug as WONTFIX then?

FPI is unlikely to ever be a supported configuration in Firefox, so I assume that extends to enterprise policies. In the end it's your call, I think I'd call this a P5 (we're taking patches but won't spend time to fix it).

...I guess it is a P5 already

I'm going to WONTFIX this. The reporter says not to pursue, and there is a workaround.

I don't want to keep things in our backlog just because we might take a patch for them :)

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.