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

[Spencer Dawkins at IETF <[e-mail]>]

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]>
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]> 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.
>>
>>
>>
>>