"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.
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" <[email protected]>
To:
<[email protected]>
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?
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
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/
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy
