ietf
[Top] [All Lists]

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

2014-11-18 11:22:05
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 11/16/14, 7:12 PM, Mark Nottingham wrote:
Hi Joe,

Thanks for the substantive comments. Responses (hopefully equal in
substance) inline.

On 14 Nov 2014, at 4:19 am, Joseph Lorenzo Hall <joe(_at_)cdt(_dot_)org>
wrote:

Signed PGP part

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

This is definitely a concern, and one of the big reasons that it's
restricted to one bit.

However, as pointed out, while it could indicate a vulnerable user,
"safe" is also usable by others; anecdotally, many people turn
"safe" mode on in search engines out of personal preference, not
because they're children or otherwise vulnerable.

I think any intentional use of this signals some level of
vulnerability. It could almost in part be flippantly called the
"troll-me" bit, as sending unsafe content conditioned on this flag
would almost always give rise to an emotional response on the part of
the user.

(Incidentally, if something outside the browser inserts this header it
may be very difficult for the user to actually turn off, as well. I'm
not sure if that's something you've thought about. In DNT, there are
applications you can install that will insert that header for you on
each request (AVG does this).)

Additionally, "safe" is by no means a complete solution; it is not
designed to be a filtering technology, nor to protect users from
tracking / targeting; to attempt that it needs to be used in
conjunction with other technologies (e.g., filters, ad blockers,
tracker blockers, DNT -- although there is much debate about the
effectiveness of these technologies as well).

Hmmm, it is definitely a "filtering preference technology", and the
desperate interpretations of the other endpoint as to what "safe" will
mean seems to set up more opportunity for confusion... not the
characteristic of a good standard, IMO.

The draft already mentions most of this, and I'm happy to
strengthen that text if you think it will help.


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

Yes, this is possible.

The question, to me, is whether this potential abuse is outweighed
by the potential benefit, and whether there are ways to mitigate
the abuse.

Unfortunately, the forums in which to counteract abuse of this kind of
thing are as varied as the interpretations of "safe". :/ We see the
potential for badness as not just being abuse but more importantly
sites responding very differently to a standardized semantic signal.

Anyway, sorry to go around in circles here.

Side story - When I was in Istanbul for IGF in September, I had a
chat about "safe" with a well-respected researcher/advocate for
online child safety. He was excited about it, because he had
advocated something similar but much more bold to browsers in the
past -- broadcasting the child's age bracket in requests.

Needless to say, that didn't happen, and I was surprised that
someone with his knowledge and experience would consider putting
such specific information in requests. I didn't ask at the time,
but afterwards I surmise that he was implicitly relying on
regulatory or legislative relief to assure that it wouldn't be
abused.

Wowza!

"safe" is by nature much more conservative than this -- it only
reveals one bit of information, and that bit is not specific to any
one group of users. If someone is adding it to your requests (a
situation that should becoming more uncommon, if numbers about
HTTPS adoption are to be believed), that's happening within a legal
context that can offer relief as appropriate.


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

Again, "safe" is not a filtering technology; it is only
pre-configuring the site's 'safe' mode if it has one, by the rules
of that site. Whether or not that site's definition of 'safe' is
appropriate to the user is a separate decision, one that might be
enforced by a filter or some other mechanism.

In common deployments, I think it's best to view it as an extension
of a Web filter *into* the site.

As above, I'm happy to expand / strengthen text here if you think
it will help.

BTW, if the utility of the specification is indeed undermined as
you point out, I think that's a largely self-correcting situation;
lack of utility certainly hasn't stopped the IETF from making
something a standard in the past.

Thanks again,

-- Mark Nottingham   https://www.mnot.net/


- -- 
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(_at_)cdt(_dot_)org
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)

iQIcBAEBCAAGBQJUa4AFAAoJEF+GaYdAqahxProP/jEHi/tSvCj7TWlAEbi0Uql0
6VEICKsIW+w5omcLcoswsiKvU8x3vPBkW6gHeBHePjmMeNO/qVjdRqmcHPQ+AdHs
6qy+eRRBN/3bM2jLwtfOzS6oCEC8Yd6IsgSSyl03dklqi8OOWaXbZcK/JstZC99C
oEp2+jsjcm95fTupxfvLpFdr69KhYpUra+3ZMq62t1a78qed86/f6uSFMiyjkRsQ
LOoMbDYl9XITHPu+7HX0P1BPM6vN9BaVnCOJaKEaArPjNNfvpIkpVshOTYXCUV/V
jOoFDLMQudi3H7ZPhh0+Sq97cc3zZjz+rXETFdnYfaSVO5F+0zy4YyJiEK3Tnd+K
34d9ng2rP4BGIAIjM5BIb49MaZrwGv+CTqTKDRkxqxD/+kbJRV7tXD7v+ru/EboY
L765+S7RxHWzMRF1Fw/dqWoNfxgixbxG0AJeUjWBN+ljHs3n7ZzZ2U+aELh36+GS
vhwM8lmN1MH5GTrLXPGzJ4KP0vqvjC8a53KlMLWV374bszH/bMvdInF7PSmcgXmI
JCaWWrWH2exdwxKsgwaTu46DcfD+cQpVj8DrDjYSm/OlmxHwuB4dr5t+n2o17WJh
FoC1i9B1FkfJMMrD02Uivwvpnl1eEJf9Sy4UZnRaKHTuAZvttmmBntDd3/LEQIuv
4XPF61EERvcKzsphY/nG
=4uSF
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>