Re: [hrpc] Call for group adoption of draft-celi-irtf-hrpc-ipvc-01

[Sheetal Kumar <[e-mail]>]

Hi everyone,

As I'm new to the group, I'd like first to say hi! My name is Sheetal Kumar
and I used to lead Global Partners Digital (GPD's) advocacy in multilateral
forums. I now support GPD's work independently as a consultant.

Thank you for this draft! I, along with Michaela, Jess, Winthrop and Lisa
(cc’d), have put together some feedback on the draft. We support its
adoption. We’re all new to the group so we hope this will be helpful at
this stage and not coming too late! The feedback is focused on providing
clarity/consistency and it follows by section.

*Introduction *

   - We would suggest including reference to how online harms can lead to
   offline harms and how technology-based IPV in the form of
   tracking/surveillance can be especially threatening and have a real
   potential to cause offline/'real world' harm to victims. This aspect could
   be spelled out more clearly in the document (ex: reference to rfc6973
   "Privacy Considerations for Internet Protocols"  (
   https://datatracker.ietf.org/doc/html/rfc6973#section-5.1.1
   <https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/rfc6973%23section-5.1.1&sa=D&source=docs&ust=1713278402010095&usg=AOvVaw1FlUWRdxUw87PyvjPcsiUg>
   )
   - At the end of the introduction, re: CSAM, the draft could still say
   that is out of scope but recognise that the distinction doesn’t always hold
   – i.e The exceptions mentioned there (CSAM and deepfakes) may also be used
   by attackers in IPV cases (e.g., CSAM of someone's child or deepfakes may
   be used to blackmail a person). Also the relative/s (in some instances this
   can even be the mother), who take the photos or videos of the child/ren can
   be part of the victim's social environment.

*3.2: Tech-based IPV tactics *

   - Under ‘dual-use’ tools, we think reference could be made to not just
   ‘anti-theft’ devices but location ‘tracking’ tools – as referring to
   tracking could help make the connections between this draft/work and work
   on tracking devices elsewhere at IETF
   - Under ‘perception of threat’: think this is important to emphasize.
   Could it also include perception of vulnerability/vulnerabilities of a
   network or system? Some research in this area that could be useful to
   reference is that on user perspectives of trustworthiness of messaging
   apps: e.g see https://www.designtrustworthymessaging.org/

*3.3: Kinds of tech-enabled IPV attacks *

   - Monitoring of the content of communications either at the application
   layer or other layers: it might be helpful to clarify what ‘other layers’
   the monitoring can happen at by an attacker in technology based IPV?
   - Where it refers to compromising of accounts and “monitor, control, or
   restrict their online communications’, reference could also be made to
   “manipulate or change”?
   - Where it says “have access to communications, audio-video content, and
   any associated meta-data” – reference could also be made to “making/storing
   copies”?
   - Where it refers to ‘exposing of private information or media’: where
   it refers to gathering of private information or private media, should we
   also consider the manner of acquiring information or data from the
   "victim"? For instance, an intimate partner may ask their partner to send
   or share intimate images (consensual in this case) but when the
   relationship turns sour, the ex-partner may (1) force the victim to share
   more intimate images or (2) extort money from the victim or (3) threaten to
   expose the images/private information to friends and relatives of the
   victim (non-consensual).
   - Denial of services: it says here that “the goal is to disallow access
   to services, or contact with family or friends”. You could also add here
   that the goal may also be to exert financial abuse by restricting the
   victim's access to their bank accounts or digital wallets
   - Coercion and control: You could add here that victims can even be
   forced to share specific information or files
   - Monitoring: You could add here online connected security
   cameras/systems for home security

*5: Recommendations *

   - General point: Perhaps this section could include a few sentences at
   the beginning to explain that the recommendations take into account that
   IPV is facilitated or carried out within a broader context of structural
   gender based violence but that as it can be assisted or exacerbated by tech
   devices and media, the recommendations focus on supporting the subject of
   attacks with means of exerting power and control (or multiply opportunities
   and means for their control/e.g account holder control) and of undermining
   the attacker's ability to carry out attacks listed in section 3.2
   - Where it says “Storage and sharing of media: media should be
   stored/posted in such a way that it can be taken down at the request of a
   victim if it consists of private media posted without consent”, we were
   wondering whether the draft could make reference on how to deal with
   re-posting? Should there be a mechanism that will ban previously-reported
   media from being posted by other accounts/devices?
   - Where it says “provide proper blocking systems that are not limited to
   an individual account”, does this mean that all accounts linked to a
   blocked account should be blocked as well? It might be helpful to elaborate
   on this.
   - Where it says that “browser history or searching information/metadata
   should be deleted by default”, the draft could specify when this
   information should be deleted
   - Add to the recommendations “Designers should be gender sensitive when
   designing tools, applications etc”
   - Consider clarifying/defining what sensitive applications might be
   - Consider making reference to considerations and steps when building
   detection tools, e.g as in slide 17 of this presentation (
   https://datatracker.ietf.org/meeting/118/materials/slides-118-hrpc-unfpa-gbv-tech-guidance-00)

   - Where it says "It is important to note that IPV should not be mistaken
   to be a privacy issue alone" consider noting other areas of impact (e.g.
   transparency and reporting mechanisms, identity management, etc.)
   - Consider making the point can be made at the very end that
   implementing the recommendations would not completely address IPV because
   of the power imbalance more widely but would help to address the use of
   tech to facilitate it

*Other (stylistic/editorial) feedback: *

   - It might be better to use a consistent pronoun for the attacker, as in
   some parts in the doc the attacker is referred to as ‘it’ (see 3.1) and in
   others using the gender-neutral they/them
   - In section 3.3, ‘ongoing’ might be a better-suited term here for
   permanent?
   - In section 5, ‘easy to access and understand’ might be a better-suited
   term for ‘good’ where it says “provide good and private mechanisms for
   reporting the posting of non-consented media”?




On Sat, 28 Oct 2023 at 17:02, Sofía Celi <[e-mail]> wrote:

> Dear, everyone,
>
> Just wanted to thank again for the discussion and reflections, and
> reiterate on Mallory's message. We will start creating the issues and
> discussions after the next IETF meeting ;)
>
> Thank you,
>
> On 05/10/2023 17:37, Mallory Knodel wrote:
> > Hi all,
> >
> > Many thanks for the thoughtful reflections. As Juliana said we would
> > like discussion to continue on the list and we can use GitHub for
> > documentation and author workflow.
> >
> > It seems to me that the outcome of reviews notwithstanding, is that this
> > draft has support for adoption by the group. I’ll make that change in
> > the datatracker imminently.
> >
> > Thanks, everyone!
> > -M
> >
> > On Thu, 5 Oct 2023 at 02:29, Jens Finkhaeuser <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi all,
> >
> >     On Oct 4, 2023 at 7:10 PM, Eric Rescorla <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >>     Document: draft-celi-irtf-hrpc-ipvc-01.txt
> >>
> >>     Thanks for posting this. I have provided some comments below:
> >>
> >>     At a high level, I think that trying to combine the romantic/sexual
> >>     partner case along with the child and elder abuse cases is a bit
> >>     confusing. This is especially true for the case of children
> >>     because it's of course very common for parents to engage in the
> >>     kind of
> >>     monitoring and access of their children discussed in S 3.3.
> >>
> >>     I know that there is a wide variety of opinions about the
> >>     appropriateness of various kinds of monitoring/controls on
> children's
> >>     Internet activity, but I don't think there's really anything like
> >>     common ground that it's inherently abusive, so perhaps it would be
> >>     better to confine the discussion here to the romantic partner
> setting,
> >>     where the question of appropriateness seems more clear.
> >     IMHO confining the scope to the romantic partner setting makes sense
> >     for the reasons you outline. But I think a stronger argument can be
> >     made to the opposite effect: how would you address child and elder
> >     abuse? A document focused on either would likely adopt a significant
> >     percentage of this document verbatim.
> >
> >     The point of this document is to describe technological means by
> >     which abuse may be enacted. It is _not_ claiming, and cannot claim,
> >     that these means are inherently abusive. If I just pick "Impersonate
> >     by using the victim's online identity to send false/forged messages
> >     to others" as an example, I know people who regularly do this for
> >     each other's convenience.
> >
> >     Rather than confining the scope, perhaps the better approach would
> >     be to restructure the document. Other drafts often follow the
> >     structure of having a problem statement section (as well as a few
> >     others) followed by the specific recommendations to address the
> >     problem. The same approach could be adopted here: expand the
> >     introduction, make the case for how IPV, child and elder abuse
> >     relate to (perceived or real) power imbalances, control, etc. And
> >     then refocus on how those can be enacted in the digital sphere.
> >
> >     It's IMHO possible to explicitly acknowledge that these methods do
> >     not have to be considered intrinsically abusive, and even make the
> >     case that parental control can adopt some of these techniques
> >     without being abusive. That being said, there is also a fine line
> >     between some parenting styles and abuse; finer than many folk would
> >     even understand. Again, however, it's not exactly the point of the
> >     document to make this judgement.
> >
> >     Jens
> >
> >     Interpeer gUG (haftungsbeschraenkt), Greifenberg
> >     Registered: Amtsgericht Augsburg, HRB 37686
> >     Geschaeftsfuehrer: Jens Finkhaeuser
> >     https://interpeer.io/
> >     <https://interpeer.io/>
> >
> >
> >     ----
> >     From: [e-mail] <mailto:[e-mail]>
> >     To: [e-mail] <mailto:[e-mail]>, [e-mail]
> >     <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
> >     Oct 5, 2023, 8:28:48
> AM_______________________________________________
> >     hrpc mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.irtf.org/mailman/listinfo/hrpc
> >     <https://www.irtf.org/mailman/listinfo/hrpc>
> >
> >
> > _______________________________________________
> > hrpc mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/hrpc
>
> --
> Sofía Celi
> @claucece
> Cryptographic research and implementation at many places, specially Brave.
> Chair of hprc at IRTF, pquip at IETF, and anti-fraud at W3C.
> Reach me out at: [e-mail]
> Website: https://sofiaceli.com/
>
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://mailman.irtf.org/mailman/listinfo/hrpc
>


-- 

*Sheetal Kumar*
T: [phone]| Time zone: GMT | M: [phone]  |
PGP ID: E592EFBBEAB1CF31  | PGP Fingerprint: F5D5 114D 173B E9E2 0603 DD7F
E592 EFBB EAB1 CF31|

---

<https://www.4dayweek.co.uk/>

GPD is proud to be an accredited four-day week organisation that cares
about the well-being of its team. Please note that our office hours are now
Monday to Thursday (9am-5pm UK time). Find out more here
<https://www.gp-digital.org/news/gpd-becomes-a-four-day-week-organisation/>.
<https://www.gp-digital.org/news/gpd-becomes-a-four-day-week-organisation/>