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

[Ballot comment]
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.

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-nottingham-safe-hint-09. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will have one action to complete.

The following entry will be added to the HTTP Preferences registry at

https://www.iana.org/assignments/http-parameters

Preference: safe
Value:
Description: Indicates that "safe" / "unobjectionable" content is preferred.
Reference: [this document]

The designated experts for this registry have confirmed their approval of this registration.

Note:  This message is meant only to confirm the list of actions that will be performed when the document is sent to us for processing.

Thank you,

Amanda Baber
Lead IANA Services Specialist

[This write-up replaces the one sued when the draft came forward on the IETF stream]

Overall, this document seems complete and interoperably implementable.
Here I take "interoperably" in the limited sense that the server will
clearly understand what the client is asking; the document correctly
describes the semantic ambiguities as to how to interpret the request,
which will be inherent in any such feature.  Assuming there are HTTP
servers that wish to allow clients to request "safe" content and clients
that will send such requests, this document will have benefit to the
Internet community by providing a common implementation target.

For the authors:

- The Implementation Status section is useful, but the links are likely to
become stale over time.  It would be useful to summarize the content of the
linked pages as of this writing.

- I disagree with the author's conclusion that "Prefer: safe" should not be
used over non-secure HTTP.  As much as I love to discourage use of
non-secure HTTP, this preference value could provide some incremental
utility there.  Security fixes get backported :)

[Ballot comment]

--- OLD DISCUSS

Before I abstain on this I would like to briefly
discuss the evaluation of rough consensus and check if
a few points raised were addressed. I'll put those as
discuss points, but plan to abstain once those are
briefly covered as I think that this is something the
IETF should not specify, never mind "endorse" as a
proposed standard. I think it is something we would
regret publishing, much as we would have regretted it
had we produced an RFC for the (IMO quite similarly
broken and damaging) do-not-track (DNT) flag.

(1) While I am definitely in the camp who would prefer
that we not specify this at all, and hence am a biased
judge, I can't see that there was rough consensus for
this, having just re-read the IETF LC mails. The
write-up does clearly acknowledge that any consensus
was very rough in the view of the sponsoring AD. Note
that I'm not at all questioning Barry's intentions
here, just his conclusion. In any case, my reading is
that there were arguments not addressed (see below) and
that it is just not credible that all this LC discussion
results in no change at all in the draft, and it is
basically not at all clear to me that what seems like a
more or less 50:50 set of folks in each camp, (I didn't
count though), with both "camps" making reasonable
arguments for and against, can in this case constitute
even a very rough consensus. So I'd like to chat about
that with the IESG in case my biased opinion turns out
to better map to the mail archive than Barry's AD
evaluation of the last call.

(2) I also don't believe the point I raised about the
scope of this was ever addressed. Does emitting this
apply to just the response to that request, or to the
origin or to whatever the server thinks is correct or
what? Having an undefined semantics and an undefined
scope seems broken to me at least but the point was
never addressed that I can see.

(3) The proxy injecting this header field means that
the user cannot get any signal that this has been done
and appendix C even says that the site should not allow
the UA to unset the proxy's preference.  This also
encourages the use of plaintext. Other than saying
"yeah, that's what's done" I don't believe that this
problem was explored at all, never mind addressed.

(4) The point raised by Joe Hall of CDT that emitting
this signals a higher probability that the site is
dealing with a minor (and hence perhaps with a user
more easily socially exploited) is I think valid and is
not reflected in the draft nor much in the discussion.
While the author offered to add text, no change
occurred.

(5) I don't see where the point raised by Christian
Huitema was dealt with - that the IETF standardising
this will likely lead to (in particular) governments
who wish to censor content requiring conformance to
RFC7xxx. I'm not sure that we have a good BCP telling
us to not collude with such, but I don't believe
that point was addressed in the LC.

(Note: it's quite possible that I missed some things
that were dealt with, or that there's scope for
disagreement as to whether or not things were or were
not addressed.)

--- OLD COMMENT

- I didn't raise this during LC so I'll just make it a
comment, but I also find it objectionable that Appendix
C says that even if the user stops sending this
preference then the servers should continue to behave
as if it is being sent. That just seems like broken
protocol behaviour to me esp with no defined semantics.

- "become much simpler" is IMO utterly clearly not
correct yet not even that obvious change was made after
IETF LC.

[Ballot comment]
Still not too sure how to ballot this document. So no record for now.

So basically the proxy for my company/provider/country will decide what's "safe" versus "objectionable" content.
Btw, http://charliehebdo.fr/ "objectionable" content or not? It depends, right...
So basically a proxy is required, right? We can't expect web server to flag themselves what could be "objectionble" content, like advertisement, porn, or charliehebdo. (that would remind me of the evil bit april 1st RFC: If you're evil, say it.).
That could work if the laws are changed, the laws in all countries. And bbviously there is an international agreement on what "safe" means. Let's face it, that will not happen. Note: Moving a server in a different countries because different rules apply is no big deal.

Therefore, I'm kind of hesitant between:
- publishing this document doesn't matter because it will not be widely implemented, So it won't matter much.
- this specification might be enforced in wrong way, so it's evil and we should not publish it

I want to hear about the different arguments before balloting.

[Ballot comment]
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).

[Ballot discuss]

Sigh. The disposition of this is no longer clear so I
am re-instating my discuss.

Before I abstain on this I would like to briefly
discuss the evaluation of rough consensus and check if
a few points raised were addressed. I'll put those as
discuss points, but plan to abstain once those are
briefly covered as I think that this is something the
IETF should not specify, never mind "endorse" as a
proposed standard. I think it is something we would
regret publishing, much as we would have regretted it
had we produced an RFC for the (IMO quite similarly
broken and damaging) do-not-track (DNT) flag.

(1) While I am definitely in the camp who would prefer
that we not specify this at all, and hence am a biased
judge, I can't see that there was rough consensus for
this, having just re-read the IETF LC mails. The
write-up does clearly acknowledge that any consensus
was very rough in the view of the sponsoring AD. Note
that I'm not at all questioning Barry's intentions
here, just his conclusion. In any case, my reading is
that there were arguments not addressed (see below) and
that it is just not credible that all this LC discussion
results in no change at all in the draft, and it is
basically not at all clear to me that what seems like a
more or less 50:50 set of folks in each camp, (I didn't
count though), with both "camps" making reasonable
arguments for and against, can in this case constitute
even a very rough consensus. So I'd like to chat about
that with the IESG in case my biased opinion turns out
to better map to the mail archive than Barry's AD
evaluation of the last call.

(2) I also don't believe the point I raised about the
scope of this was ever addressed. Does emitting this
apply to just the response to that request, or to the
origin or to whatever the server thinks is correct or
what? Having an undefined semantics and an undefined
scope seems broken to me at least but the point was
never addressed that I can see.

(3) The proxy injecting this header field means that
the user cannot get any signal that this has been done
and appendix C even says that the site should not allow
the UA to unset the proxy's preference.  This also
encourages the use of plaintext. Other than saying
"yeah, that's what's done" I don't believe that this
problem was explored at all, never mind addressed.

(4) The point raised by Joe Hall of CDT that emitting
this signals a higher probability that the site is
dealing with a minor (and hence perhaps with a user
more easily socially exploited) is I think valid and is
not reflected in the draft nor much in the discussion.
While the author offered to add text, no change
occurred.

(5) I don't see where the point raised by Christian
Huitema was dealt with - that the IETF standardising
this will likely lead to (in particular) governments
who wish to censor content requiring conformance to
RFC7xxx. I'm not sure that we have a good BCP telling
us to not collude with such, but I don't believe
that point was addressed in the LC.

(Note: it's quite possible that I missed some things
that were dealt with, or that there's scope for
disagreement as to whether or not things were or were
not addressed.)

[Ballot comment]


- I didn't raise this during LC so I'll just make it a
comment, but I also find it objectionable that Appendix
C says that even if the user stops sending this
preference then the servers should continue to behave
as if it is being sent. That just seems like broken
protocol behaviour to me esp with no defined semantics.

- "become much simpler" is IMO utterly clearly not
correct yet not even that obvious change was made after
IETF LC.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]

The disposition of this document now seems clear so I'm
moving to abstain, as promised. My previous discuss
text is below and I suspect explains my position
sufficiently well.

--- OLD DISCUSS

Before I abstain on this I would like to briefly
discuss the evaluation of rough consensus and check if
a few points raised were addressed. I'll put those as
discuss points, but plan to abstain once those are
briefly covered as I think that this is something the
IETF should not specify, never mind "endorse" as a
proposed standard. I think it is something we would
regret publishing, much as we would have regretted it
had we produced an RFC for the (IMO quite similarly
broken and damaging) do-not-track (DNT) flag.

(1) While I am definitely in the camp who would prefer
that we not specify this at all, and hence am a biased
judge, I can't see that there was rough consensus for
this, having just re-read the IETF LC mails. The
write-up does clearly acknowledge that any consensus
was very rough in the view of the sponsoring AD. Note
that I'm not at all questioning Barry's intentions
here, just his conclusion. In any case, my reading is
that there were arguments not addressed (see below) and
that it is just not credible that all this LC discussion
results in no change at all in the draft, and it is
basically not at all clear to me that what seems like a
more or less 50:50 set of folks in each camp, (I didn't
count though), with both "camps" making reasonable
arguments for and against, can in this case constitute
even a very rough consensus. So I'd like to chat about
that with the IESG in case my biased opinion turns out
to better map to the mail archive than Barry's AD
evaluation of the last call.

(2) I also don't believe the point I raised about the
scope of this was ever addressed. Does emitting this
apply to just the response to that request, or to the
origin or to whatever the server thinks is correct or
what? Having an undefined semantics and an undefined
scope seems broken to me at least but the point was
never addressed that I can see.

(3) The proxy injecting this header field means that
the user cannot get any signal that this has been done
and appendix C even says that the site should not allow
the UA to unset the proxy's preference.  This also
encourages the use of plaintext. Other than saying
"yeah, that's what's done" I don't believe that this
problem was explored at all, never mind addressed.

(4) The point raised by Joe Hall of CDT that emitting
this signals a higher probability that the site is
dealing with a minor (and hence perhaps with a user
more easily socially exploited) is I think valid and is
not reflected in the draft nor much in the discussion.
While the author offered to add text, no change
occurred.

(5) I don't see where the point raised by Christian
Huitema was dealt with - that the IETF standardising
this will likely lead to (in particular) governments
who wish to censor content requiring conformance to
RFC7xxx. I'm not sure that we have a good BCP telling
us to not collude with such, but I don't believe
that point was addressed in the LC.

(Note: it's quite possible that I missed some things
that were dealt with, or that there's scope for
disagreement as to whether or not things were or were
not addressed.)

--- OLD COMMENT

- I didn't raise this during LC so I'll just make it a
comment, but I also find it objectionable that Appendix
C says that even if the user stops sending this
preference then the servers should continue to behave
as if it is being sent. That just seems like broken
protocol behaviour to me esp with no defined semantics.

- "become much simpler" is IMO utterly clearly not
correct yet not even that obvious change was made after
IETF LC.

[Ballot comment]
I agree with Alissa, Brian, and Ted.

I can see the potential benefits but not enough to outweigh the concerns.
My primary concern is with proxies and having this in plaintext.
I am not persuaded about the legal liability concerns.

[Ballot comment]
I am abstaining, because I have an issue with what the safe-hint header will mean in reality and I do see issues coming out of censorship (i.e., when proxies are inserting this header w/o letting the user know).

It might be even an illegal action in some countries to inject such header into the communication between browser and server, as this will modify the communication. Take Germany as one example.

The document is not and cannot specifiy what objectionable content is, as this depends on too many factors, such as culture background.

In short, I do share what Adrian, Alissa, Kathleen and Stephen have alread said.

[Ballot comment]
This looks like a liability nightmare.  I understand why you want to do it, and to some degree sympathize, but this looks to me like a baseball bat you are handing to law enforcement that will be used against unsuspecting web operators who publish things they think are unobjectionable but that wind up being considered objectionable in some jurisdiction.  I can easily see it being used to suppress LGBT content, for example, and any sort of useful sex ed content for teens.  The IETF should not be associated with this specification.

[Ballot comment]
I wish I had had time to engage on this one during earlier discussions or IETF LC, but I did not. My apologies for that.

I see no reason to standardize this bit. Although folks have argued that it should be standardized because there are multiple independent implementations of it, I think that is a red herring given that there is no standardized semantic associated with it. "Objectionable" and "safe" are characteristics that are defined differently by different sites, users, and cultures; their meanings can change throughout time; and as evidenced by existing sites and applications that provide their own content filtering preference settings, those preferences are often not binary. (This is in fact one way in which the "safe" preference is distinct from DNT, because in the DNT case they actually tried to define the semantic. That was incredibly challenging and in the case of "objectionable" content I do not believe it is possible.)

The same is true for the "safer" concept described in Appendix C. Which is safer, filtering violent content or filtering nudity (or both)? Different users would answer that question differently. For a site that offers both of those choices independently, advising sites to associate the "safe" preference with the "safer" of those three options is meaningless to the user -- the user will still have to rely on the site's concept of which one is "safer" or "safest" if they want to experience the benefit of this preference.

Given the lack of a standardized semantic, I also think proliferation of this header could incentivize increased censorship. Since the deployment of this header is designed to dramatically increase the number of requests in which a preference for "safe" content is signaled (since it's designed to be sent on all requests), sites looking for an excuse to take down content altogether, or legal authorities looking for data to back up claims that the web should be rid of particular kinds of content in the first place or that the preference should be required to be on by default will potentially have lots more data to back up their claims. Furthermore, having a country-level proxy insert this could dramatically change content availability for a large user population with very little effort on the censor's side. I don't see the need to wait for any of these things to happen and then try to put the genie back in the bottle, because I doubt that will be possible.

I also don't see how the various arguments made about proxies inserting this preference can be properly reconciled. On the one hand, proponents of the header have argued that one of the reasons its presence does not necessarily indicate that the user is a minor or otherwise vulnerable is because a proxy could insert the preference on behalf of many users. On the other hand, the idea of a proxy inserting this against a particular adult user's wishes as a means to censor his Internet connection is clearly anathema to most folks and there is discussion about removing the proxy text. I don't see a solution where we could have it both ways -- have the preference indicate nothing in particular about the user, while discouraging proxies from inserting it. 

I have sympathy for parents for whom the landscape of sites and apps offering parental controls is complex. But I think the risks for the Internet, users, and the IETF of standardizing this preference far outweigh the benefits to parents. As long as "objectionable" content is in the eye of the beholder, setting these preferences site-by-site provides a useful safeguard.

[Ballot comment]
Thanks for your work in this area.  I do think it's important to experiment with ways to improve online safety for children and others.  I'm still thinking about my position on this, but have some comments I'd like to discuss (yes, this is a comment now, but I'd appreciate a response to learn a little more). 

I do agree with Stephen's points, although think experimenting to see if this or something similar works would be worthwhile.  Other SDOs are very concerned with child online protections and this type of thing (not this exact thing), could help quite a bit.  I really don't like that it requires clear text and agree with the list of problems Stephen has already pointed out as issues.

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.  If this is at a school, sure, it's easier to make this setting with a proxy, but realistically, the school would have images running on the computers (or should) that get overwritten on a regular basis to wipe away any malware automatically.  With this approach, it's easy enough to have this setting maintained in the browser/computer and might be a motivator for a school to take that approach as the desired settings would just be part of the standard image.  Perhaps removing or changing the example would help?  It would be good to reduce the emphasis on middleboxes and maybe make people aware that the setting should be in the browser and could be on default images at schools 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?

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

[Ballot comment]
Thanks for your work in this area.  I do think it's important to experiment with ways to improve online safety for children.  I'm still thinking about my position on this, but have some comments I'd like to discuss (yes, this is a comment now, but I'd appreciate a response to learn a little more). 

I do agree with Stephen's points, although think experimenting to see if this or something similar works would be worthwhile.  Other SDOs are very concerned with child online protections and this type of thing (not this exact thing), could help quite a bit.  I really don't like that it requires clear text and agree with the list of problems Stephen has already pointed out as issues.

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.  If this is at a school, sure, it's easier to make this setting with a proxy, but realistically, the school would have images running on the computers (or should) that get overwritten on a regular basis to wipe away any malware automatically.  With this approach, it's easy enough to have this setting maintained in the browser/computer and might be a motivator for a school to take that approach as the desired settings would just be part of the standard image.

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?

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

[Ballot comment]
I whole-heartily agree with Stephen and Joel on this.  This is an unprotected field that is indicating a desire to receive content deemed safe by someone else's subjective view.  Combine that with the encouraged use of plaintext and proxies is not good.  Even the Mozilla developers recognize that the issues here are not network/protocol issues (just like DNT).

[Ballot discuss]
I'll quote stephen here, since he makes a point that I championed during the discussion. I would like to dicuss this.


(3) The proxy injecting this header field means that
the user cannot get any signal that this has been done
and appendix C even says that the site should not allow
the UA to unset the proxy's preference.  This also
encourages the use of plaintext. Other than saying
"yeah, that's what's done" I don't believe that this
problem was explored at all, never mind addressed.

Injection of this value by proxies gets to the very heart of question of consent between two parties the requester and sender and that of the agency of the requestor. Encouraging transparent middle  boxes to mess with the contents of flows is imho an irresponsible act on the part of the IETF.

I  could have definitely held my nose and pass this without comment were it to very strongly discourage that acceptance of such a hint over non-confidential non-tamper resistant  channels.

[Ballot discuss]

Before I abstain on this I would like to briefly
discuss the evaluation of rough consensus and check if
a few points raised were addressed. I'll put those as
discuss points, but plan to abstain once those are
briefly covered as I think that this is something the
IETF should not specify, never mind "endorse" as a
proposed standard. I think it is something we would
regret publishing, much as we would have regretted it
had we produced an RFC for the (IMO quite similarly
broken and damaging) do-not-track (DNT) flag.

(1) While I am definitely in the camp who would prefer
that we not specify this at all, and hence am a biased
judge, I can't see that there was rough consensus for
this, having just re-read the IETF LC mails. The
write-up does clearly acknowledge that any consensus
was very rough in the view of the sponsoring AD. Note
that I'm not at all questioning Barry's intentions
here, just his conclusion. In any case, my reading is
that there were arguments not addressed (see below) and
that it is just not credible that all this LC discussion
results in no change at all in the draft, and it is
basically not at all clear to me that what seems like a
more or less 50:50 set of folks in each camp, (I didn't
count though), with both "camps" making reasonable
arguments for and against, can in this case constitute
even a very rough consensus. So I'd like to chat about
that with the IESG in case my biased opinion turns out
to better map to the mail archive than Barry's AD
evaluation of the last call.

(2) I also don't believe the point I raised about the
scope of this was ever addressed. Does emitting this
apply to just the response to that request, or to the
origin or to whatever the server thinks is correct or
what? Having an undefined semantics and an undefined
scope seems broken to me at least but the point was
never addressed that I can see.

(3) The proxy injecting this header field means that
the user cannot get any signal that this has been done
and appendix C even says that the site should not allow
the UA to unset the proxy's preference.  This also
encourages the use of plaintext. Other than saying
"yeah, that's what's done" I don't believe that this
problem was explored at all, never mind addressed.

(4) The point raised by Joe Hall of CDT that emitting
this signals a higher probability that the site is
dealing with a minor (and hence perhaps with a user
more easily socially exploited) is I think valid and is
not reflected in the draft nor much in the discussion.
While the author offered to add text, no change
occurred.

(5) I don't see where the point raised by Christian
Huitema was dealt with - that the IETF standardising
this will likely lead to (in particular) governments
who wish to censor content requiring conformance to
RFC7xxx. I'm not sure that we have a good BCP telling
us to not collude with such, but I don't believe
that point was addressed in the LC.

(Note: it's quite possible that I missed some things
that were dealt with, or that there's scope for
disagreement as to whether or not things were or were
not addressed.)

[Ballot comment]


- I didn't raise this during LC so I'll just make it a
comment, but I also find it objectionable that Appendix
C says that even if the user stops sending this
preference then the servers should continue to behave
as if it is being sent. That just seems like broken
protocol behaviour to me esp with no defined semantics.

- "become much simpler" is IMO utterly clearly not
correct yet not even that obvious change was made after
IETF LC.

[Ballot comment]
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 ...

[Ballot comment]
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?

[Ballot comment]
Thanks for this simple document. A fine idea.

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? Or at least, can you provide a way for sites to tell me they have changed the content?

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?

[Ballot comment]
Thanks for this simple document. A fine idea.

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

IESG/Author:

IANA has reviewed draft-nottingham-safe-hint-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

Upon approval of this document, IANA understands that there is a single action which needs to be completed.

In the HTTP Preferences subregistry of the Hypertext Transfer Protocol (HTTP) Parameters registry located at:

https://www.iana.org/assignments/http-parameters

a single new registration is to be made as follows:

Preference: safe
Value: [ blank ]
Description: Indicates that "safe" / "unobjectionable" content is preferred.
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

NOTE: We strongly suggest that the author can include the name of the registry HTTP
Preferences to the IANA Considerations section for clarity sake.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

PROTO for draft-nottingham-safe-hint
1. Summary

Murray Kucherawy is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The document itself is fairly straightforward.  It has withstood mulitple attempts by
participants to make the “safe” request multi-valued or otherwise something stronger
than a simple Boolean request flag, likely to its benefit.

There has also been some spirited discussion about whether this should be done at all.
A prior effort with which I am unfamiliar called “KidCode” apparently met with some
rancor and left some battle damage:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12570.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12587.html

My read of the archive (and hence why APPSAWG was willing to adopt the work) is that
his appeal not to take up the work was passionate but ultimately overcome by
consensus.  Still, the supervising AD decided it was probably a bigger risk than what
APPSAWG is chartered to handle, so it’s now a sponsored draft.

No particular pre-LC expert review has been done and none appears to be needed
given the simplicity of the document.  If we want to be really thorough we could try to
bounce this off the W3C, though they have been unresponsive to other similar requests
recently, at least from APPSAWG.  The results of the SecDir review should be
interesting.

3. Intellectual Property

The author has affirmed that he knows of no outstanding IPR claims that have not been
declared as per BCPs 78 and 79.

4. Other Points

The IANA Considerations section is a bit sparse.  It should at least name the registry it’s
updating for convenience of the reader.

References look fine.

Nothing else of note.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The "safe" HTTP Preference) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'The "safe" HTTP Preference'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a "safe" preference for HTTP requests,
  expressing a desire to avoid "objectionable" content.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-nottingham-safe-hint/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO for draft-nottingham-safe-hint
1. Summary

Murray Kucherawy is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The document itself is fairly straightforward.  It has withstood mulitple attempts by participants to make the “safe” request multi-valued or otherwise something stronger than a simple Boolean request flag, likely to its benefit.

There has also been some spirited discussion about whether this should be done at all.  A prior effort with which I am unfamiliar called “KidCode” apparently met with some rancor and left some battle damage:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12570.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12587.html

My read of the archive (and hence why APPSAWG was willing to adopt the work) is that his appeal not to take up the work was passionate but ultimately overcome by consensus.  Still, the supervising AD decided it was probably a bigger risk than what APPSAWG is chartered to handle, so it’s now a sponsored draft.

No particular pre-LC expert review has been done and none appears to be needed given the simplicity of the document.  If we want to be really thorough we could try to bounce this off the W3C, though they have been unresponsive to other similar requests recently, at least from APPSAWG.  The results of the SecDir review should be interesting.

3. Intellectual Property

The author has affirmed that he knows of no outstanding IPR claims that have not been declared as per BCPs 78 and 79.

4. Other Points

The IANA Considerations section is a bit sparse.  It should at least name the registry it’s updating for convenience of the reader.

References look fine.

Nothing else of note.

PROTO for draft-nottingham-safe-hint
1. Summary

Murray Kucherawy is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The document itself is fairly straightforward.  It has withstood mulitple attempts by participants to make the “safe” request multi-valued or otherwise something stronger than a simple Boolean request flag, likely to its benefit.

There has also been some spirited discussion about whether this should be done at all.  A prior effort with which I am unfamiliar called “KidCode” apparently met with some rancor and left some battle damage:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12570.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12587.html

My read of the archive (and hence why APPSAWG was willing to adopt the work) is that his appeal not to take up the work was passionate but ultimately overcome by consensus.  Still, the supervising AD decided it was probably a bigger risk than what APPSAWG is chartered to handle, so it’s now a sponsored draft.

No particular pre-LC expert review has been done and none appears to be needed given the simplicity of the document.  If we want to be really thorough we could try to bounce this off the W3C, though they have been unresponsive to other similar requests recently, at least from APPSAWG.  The results of the SecDir review should be interesting.

3. Intellectual Property

The author has affirmed that he knows of no outstanding IPR claims that have not been declared as per BCPs 78 and 79.

4. Other Points

The IANA Considerations section is a bit sparse.  It should at least name the registry it’s updating for convenience of the reader.

References look fine.

Nothing else of note.