The "safe" HTTP Preference
draft-nottingham-safe-hint-11

I am balloting No Objection, not because I approve of the document itself, but rather because I believe in the ISE's right to publish what they see fit; if I were balloting on the document *itself* I'd probably ballot Discuss[0], but this has now morphed into balloting on the inclusion of the IESG Note. 

While I would *like* the ISE and authors to address the questions raised in the Conflict Review IESG Note I respect their independence.  As I do not see this actively breaking any IETF technology, I feel that the only response I can give is No Objection.

[0]:I think that it is not very well described and that there are risks... but this isn't my call to make.

Thanks for this simple document. A fine idea to document it.

I found...
   Note that this specification does not precisely define what "safe"
   is; rather, it is interpreted within the scope of each Web site that
   chooses to act upon this information (or not).
That is good, but perhaps not painted red enough for some folk, notwithstanding the discussion in the Security Considerations section.
How about:
   Note that this specification does not precisely define what "safe"
   is; rather, it is interpreted within the scope of each Web site that
   chooses to act upon this information. Furthermore, requesting
   "safe" does not guarantee that the Web site will apply any filters.

---

I looked for (and found!) discussion of the insertion of "safe" into a stream. It's a fair discussion, but a worry for me. Having created this tool, is there a way to ensure that it is not used to filter my access to Web sites without me knowing?

Of course, an intermediary that can insert "safe" can also modify the content, but it is much simpler to rely on the server to do that so it would be nice to have a way to prevent or detect insertion of "safe". Similarly, an intermediary that can insert "safe" in a request can remove "safe-supplied" from a response.

Perhaps there is nothing to be done?

I agree with Joel's discuss.  My concerns are with the ability to insert this flag to enable censorship.

I do also have concerns about using a binary flag for "safe".  For instance, is a webpage with comments filled with graphic sexual threats "safe"?  Sad to say, they are common.  Does sexual material (except for things like sex ed, breastfeeding help, etc.) get grouped with violence, offensive political, etc?  Is it better to have 32 semantic-less flags so that nuance can be better supported?

I agree with Kathleen that an effort to improve the draft is worthwhile.

Thanks for your work in this area.  I do think it's important to experiment with ways to improve options for getting safe content without needing a proxy service to filter it out for you.  I do think there is more to work through before this goes forward, but think it is worth trying to figure out if there is something we can do here.

I do agree with the concerns of other ADs on this potentially being used for censorship, although think experimenting to see if this or something similar works would be worthwhile.  Since this just sets a technical option, and you can already do this with cookies, I'd be happier to see this just between a server and client.  If this can be altered by middleboxes, there is the potential for censorship with MITM approaches if a cleartext session is used. Assuming this is between a server and client, with the onus on the server to provide "safe" content (whatever that means to the server), there could be regional restrictions as to what that means put in place.  However, I don't think there is anything to stop that from happening now and we have already had offshore/out-of-country web servers to get around taxes and other local/regional requirements.  I don't think this flag will cause censorship issues forced on servers in a region where it wouldn't happen anyway.  I do think there is an opportunity to reduce the number of middleboxes (proxy web servers filtering by DNS or URLs) used by organizations that can afford to run these services to protect their users from objectionable content.  We are just talking about a technical option with no policy definition or requirements for it provided.  The current methods require the ability to deploy a box and pay for personnel to administer it.

Although there are a few implementations listed, how has this been working in experiments?  I see this draft is listed as standards track.

I'd prefer the option to be strictly between client and server and not with middleboxes requiring cleartext.  It would help to have the text clearly state that this might be used at organizations to prevent objectionable content to meet HR requirements to remove the focus from children so this is seen as a broader solution.  If this is at a school or corporate setting, sure, it's easier to make this setting with a proxy, but realistically, most use standard images running on the computers (or should) that get overwritten on a regular basis to wipe away any malware automatically (kiosks at schools, corporate may not get overwritten as often or at all).  With this approach, it's easy enough to have this setting maintained in the browser/computer.  Perhaps removing or changing the example on schools would help?  

Thanks for removing the emphasis on middleboxes.  I think it would help to emphasize that the setting should be in the browser and could be on default images at schools/organizations for client to server communications.  Grade schools might not be using images, but Universities do as they have learned from experience with malware.

I'm also wondering how this might interact with ads.  I know there are different technologies at play for ad insertion, but don't know the details of how they all work.  Would ads be "safe" as well?  Ideally, this would happen at the web server as we should be striving for encrypted sessions( As opposed to ad insertion by a middlebox - likely to be how this is done), which would change how this flag works from the current proposal that requires cleartext.  Do ad servers recognize this or might ads be racy on a "safe" page?  If ads are not safe, then this is really meaningless to prevent the issues I've had to deal with as a former CISO at a few organizations where we have had to investigate and fire people who have viewed porn at work.  This could be really helpful to others in the same position I was in, preventing such access at work.

I'm not as worried about the cleartext as I think the push for encryption will lead to a change in how this flag is set and where it can be changed rather than prevent people from turning on encryption.  From the EFF statistics, 30% of web sites are encrypted (may be higher now) and from our corporate observations, as of last June, 78% of EMC employee web traffic is encrypted (I hope that's about the same for other organizations, but don't have access to their stats).

A lot of the objections to this document seem to be missing the overall context for this document, in terms of what sites and middleboxes can already do.

Even without this header:
* Sites can create a "safe cookie", so that once they've encountered a user, they know to provide the safe version
* Proxies can block, inject, or alter content at will [1][2]

In other words, if your nightmare scenario is proxies injecting this header to censor what users get, you're already living in a worse nightmare.

The main impacts of this draft are incremental.

* In today's world, sites have to default to a safe setting on first visit, since they get no information about the users' preferences.  If users that want safe content are expected to send "Prefer: safe", then the contrapositive could give sites *more* latitude.

* Indicating safety preference below the application layer lets UAs express their users' intent more clearly in cases where the user configuring the UA is different from the application-layer user (parent vs. child; employer vs. employee).

* And in the worst case, where proxies use it to interfere with user sessions, it provides an incentive for users to ask for HTTPS.

As the IAB work on content filtering indicates [3], if we're going to live in a world with content filtering, the most Internet-friendly way for that to happen is for it to be negotiated on an end-to-end basis, between the user and the site.  This document is an instance of that design pattern.

As far as the argument that this flag will be an attractive target for regulatory pressure, I can agree that this is a fight I would rather we not have to have.  I'm on the short list of people that people call when they want things like this turned on by default, and I'm not looking forward to those calls.  

But it seems like there are so many counter-arguments that the outcomes of these debates are far from pre-judged.  The most obvious one is the DNT argument -- if this signal doesn't accurately reflect user intent, then sites will ignore it.  And by the same token, pressuring sites to not ignore it is tantamount to just outlawing the content to start with.

tl;dr: There may be some regulatory wrangling, but it's worth it to move content filtering / negotiation away from middleboxes to a more e2e footing.

[1] http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
[2] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
[3] http://tools.ietf.org/html/draft-iab-filtering-considerations-06

I'm looking at this text:

   Origin servers that utilize the "safe" preference SHOULD document
   that they do so, along with the criteria that they use to denote
   objectionable content. 

and wondering 

- is this an RFC 2119 SHOULD? I'm guessing documenting that you utilize "safe" has no impact on interoperation, so maybe this is more like "ought to"?

- is there any guidance that could be given about how this documentation might be made available to users, so it would be easier for users to find it? I won't be a bit surprised if the answer is "no", but I wanted to ask ...