pes10k / web-api-manager

(Unmaintained) WebExtension based browser extension to manage and block untrusted parts of the Web API.
GNU General Public License v3.0
102 stars 17 forks source link

[bug] not working with container tabs and First Party Isolate #53

Open ghost opened 6 years ago

ghost commented 6 years ago

WAM does not seem to be compatible with containerized tabs (Firefox Multi-Account Containers https://addons.mozilla.org/en-GB/firefox/addon/multi-account-containers/)

In the console it is showing Unable to find the Web API Manager settings for when a tab is containerized. It might be another drawback due to the cookie approach of WAM

theWalkingDuck commented 6 years ago

when you use container tabs, privacy.firstparty.isolate is enforced by default and WAM has a problem with it.

I disabled that pref in favor of this extension. ... hope some day WAM works with privacy.firstparty.isolate enabled.

ghost commented 6 years ago

reading here https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers there is no reference to privacy.firstparty.isolate but privacy.userContext.enabled, which seems different. There are cookie managers having no trouble with containers, hence I am not sure that containers are enforcing privacy.firstparty.isolate

theWalkingDuck commented 6 years ago

You are right, I mixed up Anyway I don't think it works with container-tabs, if it's not working with privacy.firstparty.isolate. The level of isolatiion with container-tabs goes even further beyond privacy.firstparty.isolate.

ghost commented 6 years ago

It does work with container tabs enabled as long as a domain is not assigned to a container other than the default FF container. Once a domain is however designated to a user defined container WAM does not work. Reason seems to be the cookie concept of WAM as opposed to the webAccess API, respectively Mozilla's currently imposed restrictions with privacy.userContext. Logically WAM can access the default container but not user defined containers, at least not the way is currently designed.

privacy.userContext is restricting to context (of a container) whilst privacy.firstparty.isolate is more strict to the First Party only, hence would even further enhance the container context.

Applications dealing with cookie/storage management have no issues with containers as they are relying on a different API than WAM. They are however currently suffering from the same fate with FPI.

Since WAM is currently at odds with both, containers and FPI, the user would have to choose between WAM and containers/FPI. Perhaps worth stating at the WAM AOM site and/or the WAM wiki (to mitigate confusion for potentially interested parties).

My preference would be containers (and perhaps FPI) over WAM, hoping that one day soon they all could coexist just fine.

Thorin-Oakenpants commented 6 years ago

@theWalkingDuck & others: FYI

FPI and containers and PB mode have OA's (Origin Attributes) - and items/cookies can have multiple OA's. So for examples

https://example.com^firstPartyDomain=example.com https://example.com^userContextId=1 https://example.com^userContextId=1&firstPartyDomain=example.com

not sure how a PB mode is indicated (edit privacy.userContext I think see post abve), but PB mode & FPI can co-exist. AFAIK containers & PB mode cannot.

Under PB mode there are restrictions (eg cookies & thus local storage can not be controlled, IDB doesn't exist, etc), and FPI covers a load of items including service workers, HTTPS2, etc, loads. FPI is the real problem, it seems to have broken many internal FF mechanisms such as sanitize, and it also kills a lot of logins due to the evercookie-flow/nature of some site logins (eg using Google to log into YT).

@n8v8R - thanks for the info on containers

Thorin-Oakenpants commented 6 years ago

The level of isolatiion with container-tabs goes even further beyond privacy.firstparty.isolate.

I think that is the other way round - just sayin' :)

pes10k commented 6 years ago

I appreciate everyones' comments here. I'm not sure much can be done though, at least until the WebExtension standard gives someways for content scripts to get information from the background script before run_at: "document_start" finishes. If anyone has any cross-browser suggestions for this, I would be extremely grateful!

ghost commented 6 years ago

@snyderp Not sure whether related and working cross-browser but been wondering whether this FF 59 patch might cure the issue?

Thorin-Oakenpants commented 6 years ago

Peter, I'll just throw this here - article - in case you wanted to add to the conversation (no login required to comment), and/or clear anything up

psnyde2 commented 6 years ago

@Thorin-Oakenpants Wow, this is great, thanks very much!

I swear I'm working on getting the subscription rule sets worked out. I'm in the middle of finishing a thesis, but once that's done 🤞

jmichael2497 commented 6 years ago

possibly related odd behavior in Firefox noticed a few versions ago and currently on 61.0

normal mode correctly blocks svg but displays in private browsing mode.

i disabled all other add-ons, but normal mode would not show the svg chart until i disabled this add-on.

example page for testing https://swappa.com/prices/planet-gemini-pda-unlocked