On 31/01/2019 01:24, OwN-3m-All wrote: > As a web developer, I create a lot of embeddable cross origin iframe > widgets. Unfortunately, if you have configured the Firefox setting of > "Block cookies and site data" to "Cookies from unvisited websites", my > iframe widgets no longer work when used on a cross origin domain, as they > rely on user sessions. Is there any documentation that defines what 3rd > party cookies are? I understand some users want to block them (as I myself > was doing until I realized that would break my iframe widgets), but what I > don't understand is why the cookies are continually blocked if a user > specifically interacts with an iframe widget. Doesn't user interaction > imply it's now a visited website? I should think the first load of the > iframe would trigger blocked cookies, but if the user interacts with the > iframe content willingly (by clicking a button which triggers an ajax call, > for example), any resulting cookies should be respected even if Firefox is > set to block 3rd party cookies. I'm all for blocking 3rd party cookies > that are loaded dynamically and are unwelcome, but if the user starts > interacting with these iframes or controls, it would make sense to allow > cookies, and that would be enough for my apps to not be broken if the user > blocks 3rd party cookies. I think web developers need a solution for > keeping their legitimate cross origin apps from being blocked by 3rd party > cookie settings if users are interacting and using them. > > I put together a sample application that shows how Firefox blocking third > party cookies completely breaks sessions (since the cookie that is returned > from the iframe call is discarded / not used). > > https://github.com/own3mall/firefox-3rd-party-cookies-test > > I created a basic test to see if I could get Firefox to maintain sessions > with iframes using a cross origin domain as the source. Unfortunately, I > could not. Is there any work-around, or an easy way to detect the user's > 3rd party cookie settings so I can warn them? I'd still like to know what > is considered 3rd party, and what happens if you visit the cross origin > domain directly in another tab before interacting with that iframe. Is it > still considered 3rd party then? What is the behavior and rules for this? > > This seems like a serious problem that needs a better solution, and I like > the interaction idea. >
Situation is a lot worse than you think. Firstly, aggressive abuse from the advertisement industry has caused most means of detecting 3rd party domains as "harmless" to be rendered useless, because that industry makes ad-sponsored websites add all the magic tags and javascript to pass the automated tests. Secondly, due to the issue above, many privacy and security plug ins extend these restrictions far beyond cookies. Some will block all content from 3rd party domains by default, some will actively strip data from referer [sic] headers, URL parameters etc., some will even object to different names under the same domain (e.g. a request from dinofly.com to data.dinofly.com may be blocked until an exception is added by the user). For example, to the web browser, it is nearly impossible to distinguish between a user filling out a form in a visible iframe, and a malicious javascript function doing so on it's own (to trigger your proposed rule). In general, the use of multi-domain mashup web designs is almost as dead as P3P declarations (which, like most such labeling frameworks, lacked the nuances to express reality of honest sites anyway). You would fare a lot better if your iframe content opened a new tab (preferably via the "target" attribute on links), thus causing the domain to be the 1st party domain during the interaction, and (probably) a visited domain afterwards. Also make sure your server side code has no problem getting the page reloaded multiple times as users are adding exceptions to their setup one rule at a time (I have seen forms that discard all data or abandon completed transactions when they do something that needs extra "firewall" rules to continue, which is bad when a user is actively trying to allow you to do stuff). Great tools for testing compatibility are the uMatrix, RequestPolicy and NoScript extensions. These plugins may or may not require that you use the old Firefox 52 ESR for site testing, as at least RequestPolicy hasn't been updated in years. I am suggesting these 3 extensions because they let you easily test blocking and unblocking operations one by one, unlike the automated "ad-blocker" style extensions. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
