ietf
[Top] [All Lists]

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

2014-11-16 18:13:37
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.

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

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.

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.

"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/

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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