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
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.
Don't do that then. Store the cart or cart identifier in a first party
(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?
It is not just the browser. It is every security system in place,
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.
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
