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

[Barry Leiba <[e-mail]>]

Thanks for your comments, Joseph.

What, specifically (including suggested text) would you like to see
changed in the document to address your comments?

Barry

On Thu, Nov 13, 2014 at 7:19 AM, Joseph Lorenzo Hall <[e-mail]> wrote:
> -----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
> [e-mail]
> 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-----
>