info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
iframes, sessions within iframes, CORs & 3rd Party Cookies - Any documentation, and interaction should allow cookies?
3,716 views
Skip to first unread message
OwN-3m-All
Jan 30, 2019, 7:24:36 PM1/30/19
to dev-p...@lists.mozilla.org
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.
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.
Jakob Bohm
Jan 31, 2019, 11:18:12 AM1/31/19
to
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
OwN-3m-All
Feb 12, 2019, 12:37:59 PM2/12/19
to Jakob Bohm, dev-p...@lists.mozilla.org
> 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).
That's probably true, but it appears Chrome and Firefox are starting to do
> 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).
this in an attempt to stop the auto-play of videos and sounds (something
I'm also vehemently against for many reasons), so there must be a way
they're detecting if the user interacts with certain content or not? I
would say if the content in the iframe becomes focused, that would be an
indication that the user has interacted with it? I don't believe JS from
the iframe can force focus on itself. The website the iframe loads on
could possibly force focus, I believe, but still, there's got to be some
way to detect if the user initiated the focus to that iframe / interacted
with that iframe.
> 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.
cookies are blocked, the session isn't maintained, and so the cart is empty
when they reach that page.
This is a big problem. I doubt a warning letting people know that
functionality won't work with 3rd party cookies blocked still won't get
them to change that setting. Is there an official browser way to prompt
the user to make an exception?
Jakob Bohm
Feb 12, 2019, 7:30:46 PM2/12/19
to
On 12/02/2019 18:37, OwN-3m-All wrote:
>> 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).
>
> That's probably true, but it appears Chrome and Firefox are starting to do
> this in an attempt to stop the auto-play of videos and sounds (something
> I'm also vehemently against for many reasons), so there must be a way
> they're detecting if the user interacts with certain content or not? I
> would say if the content in the iframe becomes focused, that would be an
> indication that the user has interacted with it? I don't believe JS from
> the iframe can force focus on itself. The website the iframe loads on
> could possibly force focus, I believe, but still, there's got to be some
> way to detect if the user initiated the focus to that iframe / interacted
> with that iframe.
>
The annoyance of videos and sounds is much smaller than the impact of a
>> 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).
>
> That's probably true, but it appears Chrome and Firefox are starting to do
> this in an attempt to stop the auto-play of videos and sounds (something
> I'm also vehemently against for many reasons), so there must be a way
> they're detecting if the user interacts with certain content or not? I
> would say if the content in the iframe becomes focused, that would be an
> indication that the user has interacted with it? I don't believe JS from
> the iframe can force focus on itself. The website the iframe loads on
> could possibly force focus, I believe, but still, there's got to be some
> way to detect if the user initiated the focus to that iframe / interacted
> with that iframe.
>
privacy or security breach, so weaker methods can be acceptable.
>> 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.
>
> I do this when the user wants to view items in his cart, but if 3rd party
> cookies are blocked, the session isn't maintained, and so the cart is empty
> when they reach that page.
(encrypted) cookie or URL parameter, then transfer whatever is needed
via (encrypted) URL parameters at checkout and after payment. Once the
credit card is out of the pocket, security protections become more, not
less important. All credit card entry should be on a dedicated tab/page
with no other content or functionality, preferably on an extra secure
server with its own URL such as
"https://payment.someprocessor.bank/pay?merchant=id&amount=nn.nn&invoice=yyyyyy&sig=kkkkk".
The return URL for payment made or rejected should be on file at the
payment processor, not passed in a parameter. This prevents attacks
that send users back to the wrong page, even if someone compromises
the shopping cart system. However the delivery address could be passed
to or from the processor if they check that as an anti-fraud measure.
Ultimately, the features of such a payment server is up to the
processor, and it'll be take it or leave it for the shop webmaster.
Yet the same principles could/should be used for shopping cart service
providers.
>
> This is a big problem. I doubt a warning letting people know that
> functionality won't work with 3rd party cookies blocked still won't get
> them to change that setting. Is there an official browser way to prompt
> the user to make an exception?
>
including the web filtering in "antivirus" and "firewall" packages, some
of which may even be locked down to prevent stupid users saying OK to
the wrong exception.
Any official means of asking for exceptions is immediately spammed by
malicious and dubious content, making most users choose "fire and
forget" settings, that don't allow custom exceptions.
As a webmaster myself, I have long since done the hard work of
minimizing cookies and extra host names used, though there is always
more to be done.
R. Jason Cronk
Feb 12, 2019, 7:50:28 PM2/12/19
to dev-p...@lists.mozilla.org
"The annoyance of videos and sounds is much smaller than the impact of
a
privacy or security breach, so weaker methods can be acceptable."
a
privacy or security breach, so weaker methods can be acceptable."
Is it though? This is an INTRUSION under the Solove Taxonomy of
Privacy: a invasion in one's tranquility or solitude. Many people have
been quietly surfing the web only to be rudely interrupted by a loud
sound emanating from their speakers. What's more than annoying is when
you open up several tabs and have to find which tab is playing the
video to shut it off. Depending on what sounds came from the speakers
and who was in earshot, it could be a DISCLOSURE violation as well,
revealing truthful information about someone that adversely affects
their security or causes people to judge their character. False
information through an audio ad could by a DISTORTION violation. ("Do
you suffer from erectile dysfunction?")
Back in the days, my friends and I had Nextel Push to Talk radio
phones where the recipient didn't have to answer. If we knew our
friend was in a particularly sensitive place, we shout all sorts of
obnoxious things through their phone, until they turned them off.
Anyway, my point is the impact of autoplaying sound or video can be
pretty significant.
Jason
.....................................................................
R. Jason Cronk | Juris Doctor
Privacy and Trust Consultant | IAPP FIP, CIPT, CIPM, CIPP/US,
PbD Ambassador
ENTERPRIVACY CONSULTING GROUP [1] | Author of Strategic Privacy by
Design [2]
Privacy notices made simple: https://simpleprivacynotice.com [3]
....................................................................
UPCOMING TRAINING
Privacy by Design Professional: Cyprus (April [4]), Belarus -
English/Russian (July)
Online (coming soon): https://privacybydesign.training [5]
----- Original Message -----
From:
"Jakob Bohm" <jb-mo...@wisemo.com>
To:
<dev-p...@lists.mozilla.org>
Cc:
Sent:
Wed, 13 Feb 2019 01:30:39 +0100
Subject:
Re: iframes, sessions within iframes, CORs & 3rd Party Cookies - Any
documentation, and interaction should allow cookies?
"https://payment.someprocessor.bank/pay?merchant=id&amount=nn.nn&invoice=yyyyyy&sig=kkkkk".
Enjoy
_______________________________________________
dev-privacy mailing list
dev-p...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-privacy
Links:
------
[1] http://webmail.dreamhost.com/HTTP://WWW.ENTERPRIVACY.COM/
[2] https://iapp.org/store/books/a191a00000345yDAAQ/
[3] https://simpleprivacynotice.com/
[4] https://enterprivacy.com/cyprus-training/
[5] https://privacybydesign.training/
Jakob Bohm
Feb 12, 2019, 8:22:32 PM2/12/19
to
On 13/02/2019 01:50, R. Jason Cronk wrote:
> "The annoyance of videos and sounds is much smaller than the impact of
> a
> privacy or security breach, so weaker methods can be acceptable."
>
> Is it though? This is an INTRUSION under the Solove Taxonomy of
> Privacy: a invasion in one's tranquility or solitude. Many people have
> been quietly surfing the web only to be rudely interrupted by a loud
> sound emanating from their speakers. What's more than annoying is when
> you open up several tabs and have to find which tab is playing the
> video to shut it off. Depending on what sounds came from the speakers
> and who was in earshot, it could be a DISCLOSURE violation as well,
> revealing truthful information about someone that adversely affects
> their security or causes people to judge their character. False
> information through an audio ad could by a DISTORTION violation. ("Do
> you suffer from erectile dysfunction?")
>
> Back in the days, my friends and I had Nextel Push to Talk radio
> phones where the recipient didn't have to answer. If we knew our
> friend was in a particularly sensitive place, we shout all sorts of
> obnoxious things through their phone, until they turned them off.
>
> Anyway, my point is the impact of autoplaying sound or video can be
> pretty significant.
>
>
Yet not as significant as having your every move recorded by and
> "The annoyance of videos and sounds is much smaller than the impact of
> a
> privacy or security breach, so weaker methods can be acceptable."
>
> Is it though? This is an INTRUSION under the Solove Taxonomy of
> Privacy: a invasion in one's tranquility or solitude. Many people have
> been quietly surfing the web only to be rudely interrupted by a loud
> sound emanating from their speakers. What's more than annoying is when
> you open up several tabs and have to find which tab is playing the
> video to shut it off. Depending on what sounds came from the speakers
> and who was in earshot, it could be a DISCLOSURE violation as well,
> revealing truthful information about someone that adversely affects
> their security or causes people to judge their character. False
> information through an audio ad could by a DISTORTION violation. ("Do
> you suffer from erectile dysfunction?")
>
> Back in the days, my friends and I had Nextel Push to Talk radio
> phones where the recipient didn't have to answer. If we knew our
> friend was in a particularly sensitive place, we shout all sorts of
> obnoxious things through their phone, until they turned them off.
>
> Anyway, my point is the impact of autoplaying sound or video can be
> pretty significant.
>
>
sold to large gangs of powerful people wanting to abuse your privacy
in much more severe ways.
I am not aware of that particular theoretical taxonomy you quote, but
the danger of 3rd party code and cookies often reaches the higher
level of having your private life recorded and seen against your will,
essentially the violation of a peeping tom.
Classifying disturbance as a significant "privacy" violation is a
theory most often used as a misdirection by those seeking to violate
deeper privacy, using phrases such as "not used in a form that
identifies you" or "not used to contact you", leaving much worse
unrestricted. Those two phrases often translate to "we will not
even bother with your name before harming you" and "we will not
ask before stealing from you".
R. Jason Cronk
Feb 12, 2019, 9:26:16 PM2/12/19
to dev-p...@lists.mozilla.org
Dan Solove's Taxonomy from 2005 UPenn law review article
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=667622
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=667622
A slightly more digestible infographic of the
taxonomy. https://enterprivacy.com/wp-content/uploads/2018/09/A-Taxonomy-of-Privacy.pdf
Jason
P.S. I don't dispute there are other risk which may have greater
magnitude. I'm only suggesting you don't discount the potential risks
imposed by auto-playing audio and video content.
.....................................................................
R. Jason Cronk | Juris Doctor
Privacy and Trust Consultant | IAPP FIP, CIPT, CIPM, CIPP/US,
PbD Ambassador
ENTERPRIVACY CONSULTING GROUP [1] | Author of Strategic Privacy by
Design [2]
Privacy notices made simple: https://simpleprivacynotice.com [3]
....................................................................
UPCOMING TRAINING
Privacy by Design Professional: Cyprus (April [4]), Belarus -
English/Russian (July)
Online (coming soon): https://privacybydesign.training [5]
----- Original Message -----
From:
"Jakob Bohm via dev-privacy" <dev-p...@lists.mozilla.org>
To:
dev-p...@lists.mozilla.org
Cc:
Sent:
Wed, 13 Feb 2019 02:22:25 +0100
Subject:
Re: iframes, sessions within iframes, CORs & 3rd Party Cookies - Any
documentation, and interaction should allow cookies?
Enjoy
OwN-3m-All
Feb 12, 2019, 9:55:12 PM2/12/19
to Jakob Bohm, dev-p...@lists.mozilla.org
I'm not handling payments though. That is all handled by PayPal in my
case. It doesn't matter what you're doing. Blocking 3rd party cookies
makes cross domain and cross origin widgets and applications break. And
there are a lot of good use cases for these... like in my case. A seller
can embed their store on their own web page, which is cross origin (and is
not something I manage or control). I handle all the processing, the end
user pays with PayPal, and the service gets notifications that payments
have been processed. It allows the seller to use my app anywhere on any
page. But with 3rd party cookies blocked, this is not possible.
There needs to be a way to better handle this. I'd even go so far as
proposing that the end user not be allowed to block all 3rd party cookies.
Only those 3rd parties that are known to abuse the functionality...
case. It doesn't matter what you're doing. Blocking 3rd party cookies
makes cross domain and cross origin widgets and applications break. And
there are a lot of good use cases for these... like in my case. A seller
can embed their store on their own web page, which is cross origin (and is
not something I manage or control). I handle all the processing, the end
user pays with PayPal, and the service gets notifications that payments
have been processed. It allows the seller to use my app anywhere on any
page. But with 3rd party cookies blocked, this is not possible.
There needs to be a way to better handle this. I'd even go so far as
proposing that the end user not be allowed to block all 3rd party cookies.
Only those 3rd parties that are known to abuse the functionality...
Bil Corry
Feb 13, 2019, 12:16:49 PM2/13/19
to OwN-3m-All, Jakob Bohm, dev-p...@lists.mozilla.org
I realize this thread is about influencing Mozilla to change their cookie
behavior, and my only thought there is even if Mozilla changes their cookie
behavior (extremely unlikely), there are other major browsers and your
solution will still not work universally. You will need to find another
way to accomplish what you're after within the confines of third-party
cookie restrictions.
PayPal had the exact same problem and did the heavy lifting for everyone by
open sourcing their solution. You can read about it here:
https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d
For third-party cookies in particular, this describes how they do it using
their open-source libraries:
https://medium.com/@bluepnume/safaris-new-tracking-rules-and-enabling-cross-domain-data-storage-85241eea7483
Best wishes on your project,
- Bil
behavior, and my only thought there is even if Mozilla changes their cookie
behavior (extremely unlikely), there are other major browsers and your
solution will still not work universally. You will need to find another
way to accomplish what you're after within the confines of third-party
cookie restrictions.
PayPal had the exact same problem and did the heavy lifting for everyone by
open sourcing their solution. You can read about it here:
https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d
For third-party cookies in particular, this describes how they do it using
their open-source libraries:
https://medium.com/@bluepnume/safaris-new-tracking-rules-and-enabling-cross-domain-data-storage-85241eea7483
Best wishes on your project,
- Bil
0 new messages