Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hi, mnot has already heard the following concerns from us at CDT about
this spec, but we want to make sure that these are part of the IETF
last call comment record.

* The "Safe" preference is not only a preference but a signal.  It
  signals user vulnerability; when activated, the header would signal
  a user's potentially vulnerable status not only to site operators
  who intend to reply in good faith, but to those that will operate in
  bad faith and also to every intermediary on-path that could read the
  preference request.

  Details about an Internet user's vulnerabilities should be treated
  as sensitive information.  A broadcast signal that advertises a
  user's content preferences or restrictions can signal her youth,
  cognitive ability, relative media illiteracy, technological
  inexperience, or another potential vulnerable status.  Because of
  the risk that this information could be used to exploit immature or
  inexperienced users, CDT generally cautions against widespread
  identification of user vulnerability.  Obviously, sending such a
  preference inside an encrypted connection removes concerns about
  on-path observers, but not the more general concern with bad faith
  endpoints or other embedded endpoints that may have other interests
  (e.g., advertisers on a service may use this signal to profile
  vulnerable populations).

* Further, the ability for other intermediaries with access to the
  request stream to insert the preference, potentially without notice
  to the user, means that users may not even be aware that they are
  broadcasting potentially sensitive information about themselves,
  thus limiting their ability to take self-protective measures against
  potential abuse.

* As many of the comments in Last Call have identified, "Safe" content
  in this specification is undefined. Because the proposal
  (necessarily) lacks a definition of "safe", it is unlikely to be
  useful to parents/guardians/users.  The lack of definition will
  produce diverse and conflicting interpretations from content hosts
  and providers, which can mislead users and their guardians, and may
  invite abuse and confusion.

  The absence of guidance to websites wishing to participate in "safe"
  content delivery will lead to varied and sometimes contradictory
  results.  This could sow confusion and potential conflict among
  participating platforms and website operators, and undermine the
  utility of the specification.

  Moreover, users and their parents will have diverse expectations
  about "safe" content.  These expectations will vary considerably
  with users' age, as well as parent/guardians' cultural backgrounds.
  Without a common understanding of what qualifies as "safe" content,
  the expectations of users and their parent/guardians are likely to
  be frustrated.  Of course, it is far outside the scope of a
  technical specification to define a content-label like "safe".  But
  because a standardized definition of "safe" content is unattainable,
  the specification will have limited use as a tool for empowering
  parents to regulate and guide their children's Internet use.


- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@xxxxxxx
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)

iQIcBAEBCAAGBQJUZOgJAAoJEF+GaYdAqahxzogP/A971Lf1c4weSTq1XtCUVna/
N8+ezBEd1qJ0FaSggPQeZi6Ri6TkqpNmyLUdgZ85oACS1QX37oOCS0vGoKXODRKq
NJ15FloP0hQgPhRFjCEIFPg4z/YUJiATtBU7+QQTMPvJbV9vA/tK5PSkv5qLXGI0
W4sc01Yhh4K4OtE4BN5Lj+zedNaBrihKtB/c3oGLZt20sNhn5VX1XzmeuTktTV39
IkuoBfcV8/00gq//nJ1f5UPm7Z3GfhCeuTFhfT6DXTC9PTHhYxLUgKglARw+1ynA
P2mRdqjxkpwNBVeeS81Xeg+G6RJ3IMZ5/HCftK9GuUbXz5MSBOQmSzY2hhHEQMdc
+LZHHFx/eKTpGehmgYx+xv85pdqaUlFZti9zOAlmkYvI+Mq3AjZQfSkmtGV5OlxQ
rcfaTWAfNNeVa8C6fNfYo2bSFSAqSUPKWY2s7khY3m8nbugiitb60c57W1FnNFnX
pDPJIjAJv37Ob84kZvQbKXXaQwSQSvSnLtaUS55Y/yvpR7goVtxBRHSaGw1sY5qO
XIeAeLRSCHjmyc8yr/v21EhLvPVu1ZSgi665mTkQG/mxkmq7MSd3edQz8s4RGfIY
5Vk0dQqCayORynF97Z6i+ylCTqPbSlANDBXuaByyQU1nnnFfV2K5Xo8lgpe0T9kV
3WIlRxdvbOAabkYgjE6G
=4UPs
-----END PGP SIGNATURE-----





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]