Re: [Mops] Roman Danyliw's Discuss on draft-ietf-mops-streaming-opcons-10: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Roman,

When you have time, would you mind reviewing the proposed PR and check whether is addresses your DISCUSS point ?

Thank you in advance

Regards

-éric


From: iesg <[e-mail]> on behalf of Spencer Dawkins at IETF <[e-mail]>
Date: Wednesday, 25 May 2022 at 22:31
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, Jake Holland <[e-mail]>, "[e-mail]" <[e-mail]>, MOPS Working Group <[e-mail]>, Sanjay Mishra <[e-mail]>, "Holland, Jake" <[e-mail]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-mops-streaming-opcons-10: (with DISCUSS and COMMENT)

Hi, Roman,

(Top-posting)

Did you have a chance to consider Jake's response about your Discuss ballot (below)?

Best,

Spencer

On Wed, May 11, 2022 at 3:04 PM Jake Holland <[e-mail]<mailto:[e-mail]>> wrote:
Hi Roman,

We discussed this in an author's chat, and we're trying to pin down some good text that would cover your DISCUSS.  (We're separately considering your other excellent comments as well, but wanted to focus on this first.)

We think the points to make are:
- media operators, your media is part of an arms race aiming to track users for more effective advertisers
- There are some efforts, such as [Topics](https://github.com/patcg-individual-drafts/topics), to get the ecosystem to reduce its reliance on individual tracking while still achieving targeted ads, which are worth a lot of money (pick out a reference or 2 from e.g. [1] https://www2012.universite-lyon.fr/proceedings/proceedings/p111.pdf )

As an initial idea, we're thinking perhaps to add a paragraph after the first mention of targeting, and we're wondering if this is in the right direction, and whether you can suggest any specific improvements?:
https://htmlpreview.github.io/?https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/blob/gh-pages/draft-ietf-mops-streaming-opcons.html#section-5.4-5:

Traditionally, targeted ads have relied on user tracking, which involves a relatively large privacy exposure for end users.  At the time of this writing some proposals such as [Topics](https://github.com/patcg-individual-drafts/topics) have been made in an effort to reduce that exposure without losing the effects of targeting (ref from [1] that measures a high impact).

We found a few references touching on the risks, like:
- https://www.makeuseof.com/tag/targeted-ads-threat-privacy/
- https://getterms.io/blog/the-risks-of-targeted-advertising/

But maybe you know a better reference?

Thanks and regards,
Jake (and Spencer and Ali)

On Mon, May 9, 2022 at 3:32 PM Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-mops-streaming-opcons-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mops-streaming-opcons/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 5.4.

   Ads may be inserted either with Client Side Ad Insertion (CSAI) or
   Server Side Ad Insertion (SSAI).  In CSAI, the ABR manifest will
   generally include links to an external ad server for some segments of
   the media stream, while in SSAI the server will remain the same
   during advertisements, but will include media segments that contain
   the advertising.  In SSAI, the media segments may or may not be
   sourced from an external ad server like with CSAI.

         …

   As a
   mitigation for concerns driven by those incidents, some SSPs have
   required the use of players with features like reporting of ad
   delivery, or providing information that can be used for user
   tracking.  Some of these and other measures have raised privacy
   concerns for end users.

Thanks for starting the discussion about privacy.  The framing doesn’t seem
completely accurate.  Whether there is ad fraud or not, user data of some kind
is being sent off to ad exchanges (it’s the basis of the bidding process), and
network level tracking is being facilitated through connects to CSAIs.  Please
provide some editorial construct to suggest that practically any kind of
targeted ads are going to entail some trade in privacy, and explain the risks
specifically or with a reference.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Thanks for distilling a diverse ecosystem into a single document.  To make
navigating this ecosystem easier, please provide definitions for terms like
“media provider”, “streaming media provider”, “intermediary”, “intermediate
streaming operators”, and “content provider”; and show a notional architecture
between them.  If some of these terms or elements are interchangeable, please
make it clear.  I’ll call out some of the places where I got confused below.

** Section 3.5.  Is there are reference that can be provided to support the
assertion that better codecs (which save bandwidth) can’t offset increased
video consumption.

** Section 4.  Is the definition of “ultra low-latency” used here the same as
“ultra low latency caches” in Section 3.4?

** Section 4.2.  What is a “premium service to the delivery of live video”?  Is
that “premium” in the sense of my ISP and associated provisioning? Or in the
sense of my relationship with the content provider?

** Section 4.2.  This section lists HLS, DASH and a few other enabling
technologies.  Are the technologies for ultra low-latency applicable?

** Section 4.3.

   This level
   of latency is often considered adequate for content like news or pre-
   recorded content.

What is the difference between the “pre-recorded content” described here and
the “on-demand” described in Section 4.4?

** Section 5.4

   In general this is a rapidly developing space with many
   considerations, and media streaming operators engaged in advertising
   may need to research these and other concerns to find solutions that

Who are “media streaming operators”?  Are those different than “media providers”

** Section 6.1.
   … we have trusted UDP-based
   applications to limit their impact on other users

Who is the “we”?  Can this “trust” please be clarified.  Same comment for
Section 6.2.

** Section 6.1.

   Although it is
   possible to saturate a path between a DNS client and DNS server with
   DNS requests, in practice, that was rare enough that DNS included few
   mechanisms to resolve contention between DNS users and other users
   (whether they are also using DNS, or using other application
   protocols that share the same pathways).

Can this observation please be restated?  How is a DNS server to resolve
contention for non-DNS traffic?

** Section 7.
      Media encrypted at the application layer, typically using some
      sort of Digital Rights Management (DRM) system, and typically
      remaining encrypted "at rest", when senders and receivers store
      it.

Is this proposed scheme where the media remains encrypted even when at rest in
fact just describing object encryption/security – that is, the security
properties of the encrypted media hold and are independent of the communication
mechanism transporting them?

** Section 7.

   The use of strong encryption does provide confidentiality for
   encrypted streaming media, from the sender to either an intermediary
   or the ultimate media consumer, and this does prevent Deep Packet
   Inspection by any intermediary that does not possess credentials
   allowing decryption.

What is an intermediary here?  Is it any on-path observer?

** Section 7.1.

   An intermediary that can identify an
   encrypted media stream without decrypting it, may be able to
   "fingerprint" the encrypted media stream of known content, and then
   match the targeted media stream against the fingerprints of known
   content.  This protection can be lessened if a media provider is
   repeatedly encrypting the same content.

-- I had trouble following the setup.  I assumed the text was trying to
abstractly describe the methodology in [CODASPY17].  Recommend:

NEW
An on-path observer that can identify that encrypted traffic contains a media
stream, could “fingerprint” this encrypted media steam, and then compare it
against “fingerprints” of known content.

-- Per the last sentence, “[t]this protection …”, what protection is being
lessened here?

** Section 7.1

   If traffic analysis is successful at identifying encrypted content
   and associating it with specific users, this breaks privacy as
   certainly as examining decrypted traffic.

Please be more precise on the security properties being lost rather than
summarizing it has “privacy”

** Section 7.2.

   If a content provider does not actively work to avoid interception by
   intermediaries, the effect will be indistinguishable from
   "impersonation attacks", and endpoints cannot be assumed of any level
   of privacy.

Please be precise on what security properties are in play from “impersonation
attacks” and loss of “privacy”.  In the situation described above, it seems to
be both confidentiality (e.g., the intermediary can see the entirety of all
communication between the end-point and the media provider) and authenticity
(e.g., no party can trust the content received in fact came from the expected
party)

** Section 7.2

      Server And Network assisted DASH [MPEG-DASH-SAND] - this
      specification introduces explicit messaging between DASH clients
      and network elements or between various network elements

Are “network elements” the same as “intermediaries?”

** Section 7.2
   The choice of whether to involve intermediaries sometimes requires
   careful consideration.  As an example, when ABR manifests were
   commonly sent unencrypted some networks would modify manifests during
   peak hours by removing high-bitrate renditions in order to prevent
   players from choosing those renditions, thus reducing the overall
   bandwidth consumed for delivering these media streams and thereby
   improving the network load and the user experience for their
   customers.

-- Please be clear on who is deciding to involve the intermediaries. Is it the
media provider?

-- It isn’t clear who is operating these intermediaries – is it the media
provider or the connectivity provider of the end user?  I took to be the
latter.  Assuming that’s right, how is this a design choice by the media
providers? Did the media providers explicitly choose to use an unencrypted
protocol to support these network operators; or did the network operators
exploit this design choice without coordination?

** Section 7.2

Now that ubiquitous encryption typically prevents this
   kind of modification, in order to maintain the same level of network
   health and user experience across networks whose users would have
   benefitted from this intervention a media streaming operator
   sometimes needs to choose between adding intermediaries who are
   authorized to change the manifests or adding significant extra
   complexity to their service.

There is an implicit architectural assumptions being made that I’m not
following.  This text suggests that the media streaming operators are operating
the intermediaries.   Are these intermediaries in a network controlled by the
media streaming operator?  Before, intermediaries were modifying manifests, and
now due to encryption more intermediaries are needed?

** Section 7.3.

Unfortunately, as noted in [RFC7258], there is no way to prevent
   pervasive monitoring by an "attacker", while allowing monitoring by a
   more benign entity who "only" wants to use DPI to examine HTTP
   requests and responses in order to provide a better user experience.

s/Unfortunately//.  Keeping "unfortunately" is a value judgement.  Some users
might be quite pleased by this development.

** Section 7.3.  What is an “Intermediary streaming operator”?  How is that
different than a “media provider” or “media streaming provider”?

Editorial

** Section 1.  Consider if you can simplify the first sentence, “This document
examines …”.  It is dense.

** Section 1.  Typo. s/availability,but/availability, but/

** Section 3.2.  Typo. s/contraints/constraints/

** Section 3.2. s/bandwith/bandwidth/

** Section 3.2.  Typo. s/occuring/occurring/

** Section 3.4  Per the paragraph starting with “Caching and pre-loading …”,
consider if this can be simplified.  It’s exactly one sentence long with
multiple “especially …” clauses.

** Section 3.4.  Editorial

   And as with other parts of the ecosystem, new technology brings new
   challenges.  For example, with the emergence of ultra-low-latency
…
Consider if the first sentence is needed.  This who paragraph seems to be
related to caches   Perhaps just start this paragraph with “With the emergence
of …”

** Section 3.5. Consider defining “mobile data.”

** Section 4.1.

   This introduces new challenges relative to less-
   restricted levels of latency requirements because this latency is the
   same scale as commonly observed end-to-end network latency variation
   (for example, due to effects such as bufferbloat ([CoDel]), Wi-Fi
   error correction, or packet reordering).

This sentence doesn’t parse.

** Section 4.1.

   These effects can make it
   difficult to achieve this level of latency for the general case, and
   may require tradeoffs in relatively frequent user-visible media
   artifacts.

The wording isn’t right here –- “… may require tradeoffs ...”  Does this text
mean “... may require accepting relatively frequent user-visible media
artifacts.”

** Section 5.5.3.  Typo. s/detction/detection/

** Section 6.1.  Per “In recent times”, please restate this as this phrase is
not precise and is unlikely to age well.

** Section 6.1.  Typo. s/tansport/transport/

** Section 6.3.  Per “… without melting the Internet”, consider a less
colloquial expression.

** Section 6.3.  Per “As noted in [RFC8312], both the CUBIC congestion
controller and its predecessor …”, consider re-writing this sentence for
readability.  The double “and both were ...” clauses makes this text very dense.

** Section 7.3.  The opening paragraph of this section appears to be a
restatement of the opening paragraph of Section 7.1.