Subject: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jul 2014 12:28:55 -0400

Call For Adoption: draft-nottingham-safe-hint

Colleagues,

This note begins a Call For Adoption for the above document to be adopted
as an APPSAWG working group item.  The Call ends on August 8, 2014.

Keep in mind that adoption of a document does not mean the document as-is
is ready for publication.  It is merely acceptance of the document as a
starting point for what will be some later final product of APPSAWG.  The
working group is free to make changes to the document according to the
normal consensus process.

There was some favorable discussion toward adoption of this document at
IETF 90 in Toronto.  We will factor this into the decision at the close of
this Call.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item of
APPSAWG (as opposed to some other venue).  Feel free to include discussion
of constraints that the WG should consider with respect to its mini-charter.

-MSK, APPSAWG co-chair

---

From: James M Snell <[email-masked]>
Date: Mon, 21 Jul 2014 09:45:01 -0700

I'm generally +1 on the draft but do not currently have any specific
implementation plan (I just don't need it for my stuff). I will note,
however, that this draft makes the assumption that "safe mode" is a
binary on-off preference; however, both Google and Bing (as examples)
offer three choices: Off, Moderate and Strict. The Prefer header
allows for optional parameters and I think it would be worthwhile to
leverage that capability here.

  Prefer: safe=moderate
  Prefer: safe=strict
  Prefer: safe=off

Note, also, that additional parameters may be applied if additional
granularity is required. For instance:

  Prefer: safe=strict; max=Y7   (prefer strict safe mode with a max
rating of Y7)

- James

On Mon, Jul 21, 2014 at 9:28 AM, Murray S. Kucherawy
<[email-masked]> wrote:
> draft-nottingham-safe-hint

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Jul 2014 15:35:36 -0400

The overwhelming feedback I’ve had is that making this anything other than a binary flag is a non-starter — both because we’d have to define a universal taxonomy, and because we’d be exposing more than one bit of information for fingerprinting.

Note that the draft currently allows sites to have finer gradations of preferences overlaid via their own mechanisms (e.g., cookies) if need be.

Cheers,

On 21 Jul 2014, at 12:45 pm, James M Snell <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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

---

From: James M Snell <[email-masked]>
Date: Mon, 21 Jul 2014 12:47:49 -0700

At the very least, there needs to be a mechanism for explicitly
requesting that safe browsing mode be turned off (e.g. Prefer:
safe=off). Beyond that, as I said, I won't be implementing this
myself, so if potential implementers are providing feedback that a
simple boolean flag is good enough, then I certainly do not object.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Jul 2014 15:49:03 -0400

It sounds like you’re arguing for Prefer: nsfw… :)

Cheers,

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 19:54:40 -0000

In article <[email-masked]> you write:
>The overwhelming feedback I've had is that making this anything other than a
>binary flag is a non-starter -- both because we'd have to define a universal
>taxonomy, and because we'd be exposing more than one bit of information for
>fingerprinting.
>
>Note that the draft currently allows sites to have finer gradations of
>preferences overlaid via their own mechanisms (e.g., cookies) if need be.

Agreed.  This draft describes a design that is implemented in actual
browsers, and that people apparently find useful.

Please, let's not waste time encrufting it with extra stuff that the
users have not asked for and are unlikely to implement.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2014 21:19:21 -0000

In article <CABP7RbdUTKkW=[email-masked]> you write:
>safe=off). 

Why?  I'm not snarking, I really don't understand how that would differ
from having no Prefer: header at all.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jul 2014 17:27:53 -0400

On 7/21/2014 3:35 PM, Mark Nottingham wrote:
> The overwhelming feedback I’ve had is that making this anything other than a binary flag is a non-starter 

In terms of decision-making about something like this, we have a few
typical choices:

   1. Simply accept the claim of a person who polled other folk.

   2. Engage in some omphaloskepsis and treat ourselves as experts

   3. Solicit input from the relevant community

Each of these can be reasonable, under the right circumstances.

Certainly we have experience that simpler is better.  But sometimes
things can be /too/ simple.  There's a long distance between a mechanism
that covers all possible variations and one that covers none.

The question about having the setting choice of on/off strikes me as the
most compelling reason to be careful about having no parameters at all.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Jul 2014 14:39:25 -0700

If the default operating mode is to enable "safe" mode. How else would I
indicate my preference for disabling it?
On Jul 22, 2014 2:19 PM, "John Levine" <[email-masked]> wrote:

> In article <CABP7RbdUTKkW=
> [email-masked]> you write:

---

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2014 17:45:47 -0400

> indicate my preference for disabling it?

I don't see anything in the draft about a "default operating mode".  If a 
request contains "Prefer: safe" it's asking for safe content.  If 
it doesn't, it isn't.

If you want all safe content, you add it to all your requests.  If you 
want all porn, you add it to none of your requests.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 18:04:29 -0400

> In terms of decision-making about something like this, we have a few

[…]

4.  Speculate wildly because there's effectively no way to answer the question.

I think we're in this category.  The only way to know whether people
would like a binary-on preference or a preference system-with-knobs
would be to run an experiment to see what people would actually do.
And even there, you'd have to have several knob-profiles to allow us
to know which sort of knobs people want.

I think this would be a fascinating piece of research if you could set
up the experimental conditions so that you didn't have to ask people
what they actually want.  Experience with successful commercial UIs
suggests that, even though people often _say_ they want more choices,
the actually useful UI presents fewer choices.  

The original proposal has a simple use case, which is, "I go to all
these websites and turn on this setting, and I have no clue what it
does from site to site, but there's always an on/off switch so that's
what I do.  I want the global on/off switch."  I don't myself have any
desire for this behaviour, but it seems to me that the binary-on use
case is easily described.  On the other hand, any with-knobs use case
will immediately force the question of the knob semantics, and I can't
see any way to answer that in a general way without a complete
vocabulary for safe-for-work preferences.  As someone pointed out in
the meeting, we already _had_ efforts at such vocabularies, and they
have not set the world on fire.  So I see no justification to refuse
the binary-on use case on the grounds that it has insufficient knobs.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Tue, 22 Jul 2014 18:09:41 -0400

My understanding is we are running the experiment. Did not people say that most of the browsers and many of the large sites are already implementing a binary-only hint?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 18:18:31 -0400

> My understanding is we are running the experiment. Did not people say that most of the browsers and many of the large sites are already implementing a binary-only hint?

If we redescribed that as, "We already have the result, and no-knob
won," I might be more inclined to agree.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Jul 2014 15:29:48 -0700

Mark: do you have details on where this has been implemented? Which
browsers? Are there server properties that support this yet?
On Jul 21, 2014 12:35 PM, "Mark Nottingham" <[email-masked]> wrote:

> The overwhelming feedback I’ve had is that making this anything other than
> a binary flag is a non-starter — both because we’d have to define a
> universal taxonomy, and because we’d be exposing more than one bit of
> information for fingerprinting.
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Jul 2014 18:35:54 -0400

On 22 Jul 2014, at 18:29, James M Snell <[email-masked]> wrote:

> taxonomy

How about a (rational) number between 0 and 1?  *)
Pretty universal concept, if you ask Mathematicians :-)
And you can turn it into a slider in the chrome.

Grüße, Carsten

*), OK, maybe between 0 and 11.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 23 Jul 2014 10:08:17 +0100

> information for fingerprinting.

I agree. My take on this is that you could switch your browser into such a
mode to essentially assert you're expecting the site to self-censor.

I see this as being useful to avoid getting caught out by someone posting
another link to goatse, for setting defaults on Google searches, etc. I'd
imagine that if a porn site supported it at all, it'd use it to throw an
error. Exactly what "safe" means is almost certainly entirely subjective,
and any intermediate value would probably need qualifications that I'm not
too keen to explore in great detail, and in any case I'm not sure what the
state of the art in penis recognition actually is.

I do, however, think that there needs to be an explicit "nosafe" - by this
I do not mean "unsafe", but simply no preference on "safe". The reason is
that in the absence of "safe", the default is to treat it as no preference,
and for at least some sites, I imagine they'd prefer to default to "safe",
since we cannot tell between browsers supporting "Prefer: safe" and those
which do not. By having a "nosafe", this means the default value can - ahem
- safely remain "safe", and users which require minimal filtering can
explicitly note this.

So, summary: Binary yes, but can we have both bits explicit, please?

Also, I'll continue to review this and would be happy to see it adopted; I
believe the ongoing discussion supports this.

Dave.

---

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Jul 2014 09:49:25 -0400

Quoting Dave Cridland <[email-masked]>:

>> The overwhelming feedback I?ve had is that making this anything other than
>> a binary flag is a non-starter ? both because we?d have to define a
>> universal taxonomy, and because we?d be exposing more than one bit of

Prefer: nosafe is basically broadcasting on the Internet, "yes please,  
more pr0n". There is no plausible deniability.

Most people who want nosafe content want it sometimes--not all the  
time--and don't want to broadcast it, because it is embarrassing. It  
is also worth pointing out that "nosafe" is already the default on the  
Internet.

So I disagree. Prefer: safe and <empty> are fine. I understand why  
mnot only wants one bit.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Jul 2014 10:01:34 -0400

I would like a discussion on:
Prefer: safeforwork
(aka SFW)

Despite my past e-mail advocating for just one bit, I think there is  
commercial value to indicate that you want content that is "safe for  
work" as opposed to just "safe".

There is a lot of content that is "safe" for work, but not appropriate  
for child / family situations. Examples might include: sex topics (not  
pr0n--like medical articles or whatever), videos or documents laden  
with expletives. Conversely, there is a lot of content that is "safe"  
for child / family situations, that is not appropriate for work.  
Examples might include: time wasting games, extreme religious or  
political websites.

Even for those technologists opposed to censorship in all forms ought  
to recognize that employers tend to exercise control over the content  
that their workforce may access. Of course they do this by purchasing  
very expensive enterprise software. Expressing this desire in a  
standardized way will lower costs in that market, making it easier to  
do what many employers may attempt to do anyway.

Another way to put it might be:
Prefer: safe; for=work
Prefer: safe; for=home  [or if 'home' is too much information, just  
leave that blank]
Prefer: safe; for=work,home

Juuuuust throwing it out there...

Sean

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jul 2014 10:07:50 -0400

> Prefer: safe; for=work,home

It's always good to see demonstrations that a slope truly is as slippery
as one feared.

It's not that any of these ideas or models or suggestions are bad,  It's
that they create a complicated mechanism, especially in combination.

So, for example, how do we reconcile work/non-work vs. child/adult? Both
are important distinctions for such filtering?

At a minimum, anything discussion that proposes attributes and values to
this mechanism probably ought to

     a) have language that is generic and therefore useful across a
variety of contexts, and

     b) explain why it is essential for broad-based utility.

I found the off/moderate/strict distinction interesting, in that regard,
given the apparent importance of being able to say on/off and some
existing base of use of moderate/strict.

d/

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2014 14:09:39 -0000

>I would like a discussion on:

We already have PICS and POWDER that provide all sorts of info about
how naughty a web page is.  I think it's fair to characterize them as
failures in practice.

If someone can show interest from browser developers or web sites for
more than one Prefer: bit, maybe we can do this.  As a purely
speculative extension, it'd be a waste of time.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jul 2014 11:43:26 -0700

> speculative extension, it'd be a waste of time.

I have seen no interest from that; having spoken to all of the browser
people involved, some sites, and some folks who I believe to have
relevant specialized knowledge and experience.  The opposite in fact.
Every time this question comes up, there is a very strong reaction:
anything more than a single bit would be disastrous.

Think of the children.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Jul 2014 14:52:13 -0400

> Think of the children.

We all are.  More than a little bit.

d/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jul 2014 15:49:46 -0400

Note:  the very first time I came to the IETF in person was to argue
against Nathaniel Borenstein's KidCode
https://datatracker.ietf.org/doc/draft-borenstein-kidcode/.   The scars I
got from the politics, backstabbing, and insanity that lead through that
discussion to the IETF VAC effort (voluntary access control, see:
http://lists.w3.org/Archives/Public/www-talk/msg01707.html) and on to the
spin up of p3p (http://www.w3.org/P3P/) still throb on cold nights.

There is not even a single bit of good to be done here.  The amount of
misapprehension and mischief available is simply too high.  Forget it and
walk away.

I oppose adoption of this draft.

With all respect to those not quite so scarred,

Ted

---

From: James M Snell <[email-masked]>
Date: Wed, 23 Jul 2014 12:53:38 -0700

> anything more than a single bit would be disastrous.

No interest from whom? It would be fantastic if there was more
information provided about who "all of the browser people" are. And
how exactly would it be "disastrous"?

Given that both Bing and Yahoo both currently offer non-binary
SafeSearch options and Google/Bing/Yahoo all provide the option to
explicitly turn SafeSearch off entirely and persistently, a valid
argument can be made that not everyone thinks that a strictly binary
mechanism is "what everyone wants".

Allowing for three specific options is not that complicated:

  safe=strict -> no adult content
  safe=moderate -> no images or video
  safe=off -> do not filter

Make it so that if the parameter is omitted, it defaults to strict
(e.g. "Prefer: safe" is equivalent to "Prefer: safe=strict").

It does not have to be any more complicated than that. Implementations
would be free to treat safe=strict and safe=moderate as equivalent,
and they're free to simply ignore safe=off if they wish -- that's the
beauty of using the Prefer header for this.

If any particular browser implementation wanted to limit itself to a
binary on/off option, then it can easily do so without difficultly or
confusion. Servers will decide for themselves what level of
granularity to support beyond that and a best practice will emerge
over time.

At the very least, give potential implementers (on both ends of the
connection) the option now to determine for themselves which of the
two approaches works best rather than hand waving a bunch of vague "we
already talked to everyone" statements around.

- James

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jul 2014 16:00:21 -0400

Ted,

On 7/23/14, 3:49 PM, Ted Hardie wrote:
> https://datatracker.ietf.org/doc/draft-borenstein-kidcode/.   The
> scars I got from the politics, backstabbing, and insanity that lead
> through that discussion to the IETF VAC effort (voluntary access
> control, see: 
> http://lists.w3.org/Archives/Public/www-talk/msg01707.html) and on to
> the spin up of p3p (http://www.w3.org/P3P/) still throb on cold nights. 
>
> misapprehension and mischief available is simply too high.  Forget it
> and walk away.
>

Being sensitive to the abuse of abuse, and mindful that I don't wish you
to relive a miserable experience, that was 1995 and I can't actually
tell from the above text what issues were in play at the time, and
whether those are still applicable.  Some of the archives are lost.  Can
you summarize so we can understand what we're in for?

Eliot

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Jul 2014 16:01:54 -0400

On Wed, Jul 23, 2014 at 3:53 PM, James M Snell <[email-masked]> wrote:

> [...]

We've drifted somewhat off-topic here.  Remember, please, that this is only
a call for adoption; the question before the working group at the moment
isn't "How should we change this?", but "Should we take this as an APPSAWG
work item?"

I don't mind getting a jump-start on the technical discussion, but several
people have offered opinions about technical details rather than the real
question we're [supposed to be] discussing.  Please, if you continue with
this thread, at least do the latter before continuing with the former.

-MSK, APPSAWG co-chair

---

From: "John R Levine" <[email-masked]>
Date: 23 Jul 2014 16:10:44 -0400

> how exactly would it be "disastrous"?

Earlier this week at the appsarea session, I believe that Mark mentioned 
Mozilla and IE as having implemented the single bit.  (My notes say it's 
implemented but I didn't write down by whom.)  Since this is clearly a 
topic of interest, you would have heard him discuss it on the audio 
stream.  He also noted that there's no commonality among the more detailed 
filters that sites provide, and attempts to categorize them, PICS and 
POWER, have not caught on.

If you're aware of browser writers that want more than a single bit, 
please tell us who they are.  Or if you aren't, please stop.  Designing 
features that nobody plans to implement is, I hope we agree, a waste of 
time.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jul 2014 16:15:14 -0400

> speculative extension, it'd be a waste of time.

Dear John,

Agreed.  While we have many bits originating from a net-nanny product, many of the different responses relate closely with the geo-code of the client.  I too think that one bit is likely to provide the most conservative approach.  Systems attempting to offer higher granularity will likely not set the safe bit.

Regards,
Douglas Otis

---

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Jul 2014 13:52:53 -0700

> Agreed.  While we have many bits originating from a net-nanny product, many of the different responses relate closely with the geo-code of the client.  I too think that one bit is likely to provide…

For purposes of WG adoption, what if we say "yes the draft should be 
adopted" but the first issue *in the WG after it is adopted* is "how can 
we make this one bit, and still have it extensible so that in the 
future, old parsers will not choke on the old one-bit setting"? I.e., 
design for extensibility in mind.

Prefer: safe [; type=value; type=value; type=value]

where in v1, simply agree "there is no consensus if more should come 
after...so we'll design this extensibility mechanism and kick the 
decision down for later...v1 generators MUST NOT generate parameters and 
v1 parsers MUST ignore any parameters that come after the safe keyword, 
but MUST recognize that parameters might exist"?

Sean

---

From: Karl Dubost <[email-masked]>
Date: Thu, 24 Jul 2014 10:19:08 +0900

Le 22 juil. 2014 à 01:28, Murray S. Kucherawy <[email-masked]> a écrit :
> This note begins a Call For Adoption for the above document to be adopted as an APPSAWG working group item.  The Call ends on August 8, 2014.

potential for ratholes discussions. 
a "safe" preference is strongly attached to a cultural context. Cultural contexts are related to groups and often physical access to places with a notion of sealed environments.  

A magazine stand will put some publications into a dedicated environment (hidden, special room, etc) according to the law of the country (or the province). The mechanism of enforcement is often done through the barrier of a human person controlling the access. Same thing for alcohol, tobacco, amusement park (height), etc. 

Putting a label on the browser side is indeed a way to advertise that you do not want to receive some type of content, but the issue is that "safe" has no meaning with regards to the Web because the cultural concepts associated with the word "safe" is highly dependent on the community and geographical location of the person using the browser.

This document is likely to lead to long discussions, will not solve anything in a satisfying way, will be abused in all the ways you can imagine. It will be even a potential source of additional tracking for ads businesses along "This person is probably religious or a child, let send targeted ads."

-- 
Karl Dubost 🐄
http://www.la-grange.net/karl/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Jul 2014 23:14:30 -0400

Sorry for the top post (iPhone), but given the quoted message I'd like to ask whether this controversy could be solved by calling it "opaque-pref-bit-a" would help.  I want to know whether we're disagreeing over what we call something or what it does. 

Best regards,
A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Jul 23, 2014, at 21:19, Karl Dubost <[email-masked]> wrote:
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Jul 2014 09:18:23 -0400

On Wed, Jul 23, 2014 at 4:00 PM, Eliot Lear <[email-masked]> wrote:

> to relive a miserable experience, that was 1995 and I can't actually tell
> from the above text what issues were in play at the time, and whether those
> are still applicable.  Some of the archives are lost.  Can you summarize so
> we can understand what we're in for?
>
> Eliot
>

​The short answer is that a user setting of this type creates an
expectation that amounts to a "do what I mean".  Since it becomes obvious
pretty quickly that "what I mean" means different things to different
folks, and that some of them will be very upset when their expectations are
not met, it becomes easy to persuade yourself that defining what the user
means is the right thing to do.   That moves you from the problem of
inferring everything from context into the equally intractable problem of
exhaustively defining human behavior, art, and expectation.

In short:

A single bit DWIM is useless in any reasonably large number of contexts.
A complex exploration of expressing human behavior and expectations is
impossible.

When those are the options, you should not even take up the task.

regards,

Ted

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 24 Jul 2014 15:22:40 +0200

> A single bit DWIM is useless in any reasonably large number of contexts.

Perhaps. But someone said earlier in the thread that two widely distributed 
browsers have implemented the single bit, or did I misunderstand?

Arnt

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Jul 2014 09:58:48 -0400

Hi Ted,

On 7/24/14, 9:18 AM, Ted Hardie wrote:
> expectation that amounts to a "do what I mean".  Since it becomes
> obvious pretty quickly that "what I mean" means different things to
> different folks, and that some of them will be very upset when their
> expectations are not met, it becomes easy to persuade yourself that
> defining what the user means is the right thing to do.   That moves
> you from the problem of inferring everything from context into the
> equally intractable problem of exhaustively defining human behavior,
> art, and expectation.
>
> In short:
>

Thanks for this explanation. 

What you are arguing is that the set of what the user believes is smut
and the set of what the content provider believes are not equal. 
Further the content provider's set will be withheld from the user, not
what the user thinks.  The incentives for content providers are to only
mark that which they are required to mark as inappropriate.  That will
be governed by varying community standards and laws.  That doesn't mean
that this mechanism isn't useful.  So long as the intersection between
the two sets covers the preponderance of content to be excluded, and
does not cover the preponderance of content that is not to be excluded,
this seems to me useful.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jul 2014 09:59:56 -0400

On 7/24/2014 9:18 AM, Ted Hardie wrote:
> The short answer is that a user setting of this type creates an
> expectation that amounts to a "do what I mean".  

That's not the definition that has been provided here multiple times.
The actual definition being used here is that the user is saying to the
provider "do what /you/ mean."

Google has a 'safesearch' feature.  It's on or its off.

One bit.

Google tells you it's about 'sexually explicit content'.  That's /their/
definition of safe, not mine.  (Mine is being spared from simplistic,
silly, mindlessness and empty marketing blather, but no, I don't expect
anyone's 'safe' feature to filter those out.  If only...)

I believe we been told that at least one other major provider supports a
binary switch.  We should document those.

The fact that there is an existing feature in a very major service that
supports exactly the model we are describing here -- one bit, defined by
provider -- is encouraging.

d/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 07:06:12 -0700

On 24 July 2014 06:58, Eliot Lear <[email-masked]> wrote:
> What you are arguing is that the set of what the user believes is smut and
> the set of what the content provider believes are not equal.  Further the
> content provider's set will be withheld from the user, not what the user
> thinks.  The incentives for content providers are to only mark that which
> they are required to mark as inappropriate.  That will be governed by
> varying community standards and laws.  That doesn't mean that this mechanism
> isn't useful.  So long as the intersection between the two sets covers the
> preponderance of content to be excluded, and does not cover the
> preponderance of content that is not to be excluded, this seems to me
> useful.

https://en.wikipedia.org/wiki/Corn_smut

I think that the difference, as Mark was careful, is important.  It's
explicitly not DWIM, it's DWYTB (Do What You Think Best).

To my mind, this is sufficient, but I respect Ted's perspective; the
ease with which this turn into DWIM does mean that it will happen.
But I am not as concerned about the negative consequences of that
outcome.

---

From: Erik Wilde <[email-masked]>
Date: Thu, 24 Jul 2014 16:11:32 +0200

> provider -- is encouraging.

i was wondering why nobody was bringing up google safe search, so thanks 
a lot!

safe search obviously exists and seems to be useful enough that people 
use it and google keeps it around. doesn't that mean then even though 
this bit may delegate a user's definition of what "safe" means to the 
server, it seems to be something that people seem to like instead of not 
having such a feature at all?

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Jul 2014 10:21:45 -0400

> provider "do what /you/ mean."
​I was asked to comment on my experience with this in the past, and that
experience tells me that the end user will believe that "make this safe"
will correspond to what *they* think is safe.  That the DWIM has an
indirection that involves a presumption that what they think is safe maps
to what the server thinks is safe may well be true.  For the end user,
though, I believe it will be a DWIM.​

One bit.
Bing's has: stric​t, moderate and off.

http://www.bing.com/account/general?ru=http%3a%2f%2fwww.bing.com%3a80%2f&FORM=SEFD

As this sort of web page shows, Google also has had more than one bit in
the past

http://www.ehow.com/how_8092625_lock-safesearch.html

> binary switch.  We should document those.
​I don't see that value, personally.  If a service wants to do it, they can
set it up in their own systems, and I see no value in standardizing
something that _will have no standarddized results_.  But I know how to
mute a thread, should the working group decide on spending its time up on
this.​

> ​I am not so easily encouraged, given the history here.

Ted​

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jul 2014 10:28:12 -0400

On 7/24/2014 10:21 AM, Ted Hardie wrote:
> On Thu, Jul 24, 2014 at 9:59 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>>wrote:

ack.  I see that too.

> http://www.ehow.com/how_8092625_lock-safesearch.html

Note that you are pulling that from a site that isn't Google's.  Note
that Google's /current/ system is a single bit.

Taking the bit of history you cite as a given, that means that Google
moved /to/ a single bit of on/off.

In the scheme of usability learning curves, Google might not be
definitive, but they certainly represent interesting input.

> ​I don't see that value, personally.  

You probably aren't the target user.

>If a service wants to do it, they
> can set it up in their own systems, and I see no value in standardizing
> something that _will have no standarddized results_. 

Yes, it's certainly an odd thing to do, in protocol standardization
terms, and exactly for the reason you cite.

And that's why existing practice is so important here.

d/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Jul 2014 10:55:19 -0400

On Jul 24, 2014, at 9:18 AM, Ted Hardie <[email-masked]> wrote:

> A complex exploration of expressing human behavior and expectations is impossible.
> 

If you phrase it like that, sure. But the proposal is not "DWIM": you predicted that is what would happen. With all due respect, your predictive abilities suck as badly as everyone else's here.

The document says that the proposal is "DWYM". It can maybe say that a few more times.

I support the adoption of this document by the WG.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2014 14:58:14 -0000

I appreciate Ted's concern, but this seems different enough and
limited enough to be OK, so I endorse adopting it.

Needless to say, I'd prefer not to make any changes other than minor
editorial ones on the way through.

R's,
John

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Jul 2014 13:32:10 -0400

> You probably aren't the target user.
​I meant the value of standardizing it, not the value of using it.​

> > something that _will have no standardized results_.
>

​I believe that a document titled  "$FOO's use of the MUMBLE header"​

would be fine
information for the community of folks how might encounter it.  Publishing
a standard,
or even something that came across as the IETF offering this advice, seems
to me to
open up the issues raised in this thread.

regards,

Ted​

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Jul 2014 14:45:15 -0400

> I don't see that value, personally.  If a service wants to do it, they can

The value is in browsers being able to offer an option that will work
well for many cases.

It's not uncommon for us to standardize a mechanism and semantics, and
to leave some details to implementations.  Here we have a mechanism
(insert "Prefer: safe") and semantics (only return content that you
consider "safe", by your judgment).  The semantics include a general
sense of what "safe" means, but we have left the specific details to
the implementation.

In reality, anyone who really needs to use this (to keep their
children from seeing body parts, or whatever) has to check out the web
sites beforehand anyway -- if for no other reason than to make sure
they support the feature.  When you do that, you can determine whether
the site's definition of "safe" sufficiently matches yours.

I don't see that this is any different from other cases where we let
the server determine what "too long", "too large", or "too much load"
means.

Barry

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Jul 2014 15:01:03 -0400

> the server determine what "too long", "too large", or "too much load"

​I think that is an interesting, and very telling parallel.  We would never
advise someone to
express a constraint to a server as "don't send me anything too long".  We
would say, no,
say what "too long" means (note that semantic is "too long for the client
emitting the statement").
It's a negotiation fail waiting to happen, otherwise.

The semantic here is "don't send me anything unsafe for me" here, even if
the syntax is
"don't send me anything not marked safe by you".

This will be last message on this topic; I've muted it now.  I've said my
piece, and I've seen
the end of the show in any case.

good luck,

Ted

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2014 20:22:01 -0000

A few moments of googlage finds these public descriptions of existing
implementations of the "Prefer: Safe" header.

The draft, as far as I can tell, describes the existing practice, and
I still would like us to adopt it.

Client implementation in Firefox:

https://blog.mozilla.org/privacy/2014/07/22/prefersafe-making-online-safety-simpler-in-firefox/

Client implementation in IE 10 and IE 11, and server implementation in Bing:

http://support.microsoft.com/kb/2980016

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jul 2014 17:50:10 -0400

> the site's definition of "safe" sufficiently matches yours.

However, in reality, there is one current purpose as defined by the 
supportive browsers (IE, Firefox) -- Parental Controls.  In fact, it 
is automatically send by the browser when the OS has parental controls 
enabled. The draft seems to not directly reference this fact.

> the server determine what "too long", "too large", or "too much load"

I see your point, but its very different in my book. Thats Flow 
Control.  Here is Content/Context Control.

Based on my readings of the draft and of Levine post of browser 
support links, the client browser isn't going to do any display 
filtering with the server output but just send the HTTP header.  It 
expects the server to filter, manage, control the output of 
"safe/unsafe" information.

With the "safe" hint, the server/site will assume liability risk if it 
chooses to honour (honor) it and its gets it wrong.   It may be 
legally safer to ignore this HTTP header until there is better 
understanding of the controls necessary by a web server/site.

Overall, there should be some guidelines of what this header means and 
based on what I read about the browser support, it is 100% related to 
parental controls concept.  That should be referenced and emphasized 
in the draft.

Probably for appendix B:

      Current browsers in the market are automatically sending this
      HTTP header to indicate Parental Controls were set by the
      Operating System.

-- 
HLS

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 15:21:14 -0700

On 24 July 2014 14:50, Hector Santos <[email-masked]> wrote:
> supportive browsers (IE, Firefox) -- Parental Controls.  In fact, it is
> automatically send by the browser when the OS has parental controls enabled.
> The draft seems to not directly reference this fact.

The draft doesn't say that because the intended usage is wider than
just Parental Control.  It specifically avoids talking about the
motivation behind sending the header field.

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jul 2014 18:55:05 -0400

Yes, understood, open ended, etc.  But parental control is the primary motivation in practice today and it is in fact, what automatically enables it, a common signal between browsers and the OS.  While there could be other safe data associations,  parental controls should be the principle practical reason stated in the draft that exist today. This would be a primary reason a web site may begin to leverage and "honour" this header when it begins to include sensitive data considered to fall under parental controls.

--
Hector Santos
http://www.santronics.com

> On Jul 24, 2014, at 6:21 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jul 2014 16:34:58 -0700

Hi Ted,

On 23 Jul 2014, at 12:49 pm, Ted Hardie <[email-masked]> wrote:

> Note:  the very first time I came to the IETF in person was to argue against Nathaniel Borenstein's KidCode
> https://datatracker.ietf.org/doc/draft-borenstein-kidcode/.   The scars I got from the politics, backstabbing, and insanity that lead through that discussion to the IETF VAC effort (voluntary access control, see:  http://lists.w3.org/Archives/Public/www-talk/msg01707.html) and on to the spin up of p3p (http://www.w3.org/P3P/) still throb on cold nights.  
> 
> There is not even a single bit of good to be done here.  The amount of misapprehension and mischief available is simply too high.  Forget it and walk away.
> 

I was a member of the P3P WG, and I bear the scars as well, so I’ll assume that your appeal to authority above wasn’t directed at me.

Let me construct my own appeal to authority below — the authority of *implementor interest*.

This discussion represents my main concern around asking for this draft to be standards track — defining the vocabulary to use when describing policy like this is a hornet’s nest for any standards activity, particularly when the set of people standardising it are NOT well-educated in this area, just bystanders (yes, being a parent makes one a stakeholder here, but that doesn’t make one educated on the underlying issues).

Note that I’m not really a stakeholder either; I just wrote down a mechanism that had some interesting properties:

* It is simple and single-bit, avoiding the pain of P3P
* It aligns the interests of the parties involved (unlike DNT)
* it works well with HTTP 

After I wrote it down, I let it sit. After a while, I got interest from the people at Microsoft who implement Family Safety; they are very well-educated in the issues here, and they decided it was interesting enough to implement. Then Mozilla came on board.

That told me that it might be worth standardising. I brought this draft here to see if we could do something small and simple to allow preferences to be expressed and then acted upon; the use case is very clearly defined in the draft. 

I did not do this to open up a can of worms of inventing a taxonomy for Web content safety; my scars and yours tell me that doing that is an especially stupid thing to do. This draft, however, does not do so; it’s just a bit, and it’s site-defined. If this devolves into an exercise of describing different levels of safety, etc., I’ll do my best to shoot the entire thing in the head personally, as that smacks of the worst of this process. 

Anyone suggesting a “NSFW” preference should identify the use cases and convince implementers. So far I’m hearing people with opinions and “good ideas" being answered by crickets on the implementer side.

In my estimation, it should take this draft a few weeks to get through the WG; there are a few editorial issues, but it’s substantially ready to get to the IESG. If it takes longer than that, it tells me that something is very, very wrong.

Cheers,

P.S. Some big Web sites have privately expressed to me that if this is standardised, some jurisdictions will require Web sites to honour it with jurisdictional (not site-specific) semantics. This very well may happen, and in that case, I’d encourage those big Web sites to use their (extensive) lobbying capabilities to make sure that there were a carve-out of an appropriate shape, so that the site retains its ability to define what “safe” is. I don’t, however, think that that’s a valid reason to resist standardisation here. After all, a sufficiently motivated jurisdiction can already do that with Cookies today; all this mechanism does is relieve end users of the burden of setting cookies for multiple sites.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 25 Jul 2014 10:01:16 +0900

I know that two efforts in this space at W3C have produced specs, but 
not much in terms of deployment as far as I know. I have learned from 
Ted that earlier efforts at IETF also didn't work out well.

But independent from this, having observed the discussion over the past 
few days, I think that the topic already has and will continue to 
generate too much mail to be appropriate for the WG and this list, and 
take away valuable resources from other work.

I therefore oppose adoption of this document by the WG. I suggest that 
if Mark wants to continue, he get a few coauthors from browser vendors 
and submit it directly through an AD or as an independent submission, 
possibly as informational. Another choice would be to create a dedicated 
mailing list (and maybe later a dedicated WG) but I think that would be 
overkill.

Regards,   Martin.

---

From: James M Snell <[email-masked]>
Date: Thu, 24 Jul 2014 18:22:53 -0700

+1

On Thu, Jul 24, 2014 at 6:01 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> I know that two efforts in this space at W3C have produced specs, but not
> much in terms of deployment as far as I know. I have learned from Ted that
> earlier efforts at IETF also didn't work out well.
>
> But independent from this, having observed the discussion over the past few
> days, I think that the topic already has and will continue to generate too
> much mail to be appropriate for the WG and this list, and take away valuable
> resources from other work.
>
> I therefore oppose adoption of this document by the WG. I suggest that if
> Mark wants to continue, he get a few coauthors from browser vendors and
> submit it directly through an AD or as an independent submission, possibly
> as informational. Another choice would be to create a dedicated mailing list
> (and maybe later a dedicated WG) but I think that would be overkill.
>
> Regards,   Martin.
>
>

---

From: James M Snell <[email-masked]>
Date: Thu, 24 Jul 2014 19:32:19 -0700

On Jul 24, 2014 4:35 PM, "Mark Nottingham" <[email-masked]> wrote:
[snip]
> Let me construct my own appeal to authority below — the authority of
*implementor interest*.
[snip]

Mark, for whatever it is worth, my input on this has been offered in good
faith with my author-of-the-prefer-header-rfc hat on.

I intentionally set a low bar for the Prefer header: Not all preferences
will be obvious, but all should have at least some testable quality. One
challenge with "safe" is that I have absolutely no way of knowing whether
or not a site complied with the preference. If I get content back that I
find objectionable, did the site not understand the safe preference? Does
it disagree with my notion of safe? Is there a bug I ought to report? How
would I know?

Use of the Preference-Applied response header would be one solution to at
least the question about whether the site understood the request. Obviously
that doesn't help with the "was it a bug or a disagreement" question (which
is why I'd prefer to see some baseline testable requirement). But, if
implementors are fine with that ambiguity, then so be it.

- James

---

From: Graham Klyne <[email-masked]>
Date: Fri, 25 Jul 2014 08:09:36 +0100

> P.S. Some big Web sites have privately expressed to me that if this is standardised, some jurisdictions will require Web sites to honour it with jurisdictional (not site-specific) semantics. This v…

Reading this thread, it occurred to me that a /possible/ use for this might be 
to deflect the UK government's bone-headed requirement for ISPs to 
default-censor internet access.  Since its introduction in UK, there have been 
numerous stories of perfectly innocent sites being blocked (including, 
frequently, sites aimed at providing health-related advice and helplines for 
young people).

A mechanism like this might provide an alternative to the blunt and damaging 
instrument of censorship at the Internet subscription level.

Just a thought.

#g
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 Jul 2014 09:15:14 -0400

On Thu, Jul 24, 2014 at 6:55 PM, Hector Santos <[email-masked]> wrote:

> Yes, understood, open ended, etc.  But parental control is the primary
> motivation in practice today and it is in fact, what automatically enables
> it, a common signal between browsers and the OS.  While there could be
> other safe data associations,  parental controls should be the principle
> practical reason stated in the draft that exist today. This would be a
> primary reason a web site may begin to leverage and "honour" this header
> when it begins to include sensitive data considered to fall under parental
> controls.
>

This post does not address the call for adoption.  It looks like you're
already working on the draft.  I've already posted asking that the latter
be limited until we resolve the call for adoption.

Should APPSAWG take up this work?  If "no", are there other venues where it
should be pursued?

Please and thanks.

-MSK, APPSAWG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 Jul 2014 09:18:50 -0400

On Thu, Jul 24, 2014 at 9:01 PM, "Martin J. Dürst" <[email-masked]>
wrote:

> as informational. Another choice would be to create a dedicated mailing
> list (and maybe later a dedicated WG) but I think that would be overkill.
>

The ADs have gotten pretty good at spinning up dedicated, tightly-focused,
short-lived working groups for specific projects.  In retrospect, I think
they and we agree that Webfinger, for example, should've done that rather
than processing it through this working group.  So it might be overkill in
other areas, but probably not here.

For Webfinger, we ended up processing it through this working group but
gave it its own mailing list, so that's also an option.

Thanks for both suggestions.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jul 2014 13:24:28 -0400

> Should APPSAWG take up this work?  If "no", are there other venues where it

As a web server developer, I support the idea for adoption for 
additional work needed to provide better guidance in implementing it.

Thanks

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 14:26:51 -0400

On 7/25/2014 9:18 AM, Murray S. Kucherawy wrote:
> The ADs have gotten pretty good at spinning up dedicated,
> tightly-focused, short-lived working groups for specific projects.

I strongly suggest that anyone proposing that there be a working group
include in that proposal details for what specific, technical work they
believe is required.

>From the mailing list transcript, one might try to divine the work list,
but let's avoid guessing and make it explicit, from whomever believes it
is needed.

d/

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 26 Jul 2014 09:57:00 +0000

>> Should APPSAWG take up this work?  If "no", are there other venues where it

having read the  draft-nottingham-safe-hint and all the mail discussions till now
I do think this is something worth to work on
and I do support the adoption of this work by APPSAWG

cheers
Sal

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Jul 2014 10:11:10 -0400

--On Thursday, 24 July, 2014 14:45 -0400 Barry Leiba
<[email-masked]> wrote:

>> I don't see that value, personally.  If a service wants to do
>> it, they can set it up in their own systems, and I see no
>> value in standardizing something that _will have no
>> standardized results_.
> 
> The value is in browsers being able to offer an option that
> will work well for many cases.
> 
> It's not uncommon for us to standardize a mechanism and
> semantics, and to leave some details to implementations.  Here
> we have a mechanism (insert "Prefer: safe") and semantics
> (only return content that you consider "safe", by your
> judgment).  The semantics include a general sense of what
> "safe" means, but we have left the specific details to the
> implementation.
> 
> children from seeing body parts, or whatever) has to check out
> the web sites beforehand anyway -- if for no other reason than
> to make sure they support the feature.  When you do that, you
> can determine whether the site's definition of "safe"
> sufficiently matches yours.

Hi.

Do keep in mind that, while "body parts or whatever" is what
usually comes to our minds, there are many places in the world
where "critical of the principles of my religion" makes
something "unsafe" too.   It is probably far harder for a server
to make the guesses needed to avoid "unsafe" by those sorts of
criteria than it is to make a guess about body parts.  On the
other hand, in some places, the religious types of safe are
already covered by national law and it is illegal for a server
to "export" offending material into that jurisdiction.    If
someone wants high-precision hair-splitting with something like
this, it isn't going to work _and_ people are going to give up a
lot of privacy by trying/asking.

Just a small suggestion.  I don't see "safe" (with or without
the change suggested below) as being terribly useful, but I
don't see much harm either (Graham's and Mark's observation
about overzealous regulators notwithstanding).  AFAIK, the
hugely complex,
probably-cannot-be-interpreted-by-any-normal-parent, W3C
recommendation in this area is still around, although largely
unused.  So we sort of have a choice between "much too simple"
(this proposal) and "much too complex" (W3C platform).  There
probably isn't much of a middle ground except insofar as the
idea below counts.

How about adding two things to the spec:

(1) An [even more] explicit note along the lines of some of the
comments that have been made already, i.e., that this is a vague
request, that the server's interpretation of "safe" may differ
from that of the user responsible for the client, and that a
truly evil site might either ignore it or interpret it as a
"child here" indication for targeting.  It might go on to say
that someone wanting more precise control could look to the W3C
spec, with the understanding that it is rarely supported and
that roughly the same possibilities for abuse by evil parties
and sites exist.

(2) Ultimately, there are probably only two simple, but still
meaningful, statements that can be made about child-safe (or
other-safe) content.  One is "please apply my personal criteria
and my globally-unique personal identifier that is bound to
those criteria".  The server probably doesn't know and can't
guess what those criteria are, and globally-unique personal
identifiers are a major problem in and of themselves.  The W3C
spec was an approximation at a language for describing that
degree of preference and, IMO at least, just wasn't usable.
The other is to make an appeal to organizational criteria.
Various organizations have put a lot of effort into establishing
criteria for banning (or cursing) content they don't like.
Sometimes those criteria come down to "I know it when I see it",
with some of the world's greater hypocrites searching the web
and elsewhere to view and enjoy such content for the ostensible
purpose of rating it for others.  The W3C system was supposed to
provide a vocabulary for describing those criteria but appears
to have failed in the marketplace (I've thought, at least in
part, because it didn't have a category set of "I know better
than anyone else and I know bad stuff when I see it").    Maybe
none of that makes any difference.

So we allow a parameter on the "safe" indicator that permits
pointing to one, or a list of, organizational names who
establish criteria or lists so that the client can identify
which definition of "safe" is intended.  If more than one is
specified, the server gets to assume that, for that client's
purposes, all of them are equivalent so it can pick any one to
believe in.  If the server doesn't recognize any of them, the
request reverts to the server's definition of "safe" or, perhaps
in an excess of caution, the server decides that the client just
didn't want its content.  If it does recognize at least one,
that one informs the choice.  We do _not_ get dragged into this
by setting up a registry.  Either the entities involved get
together and work something out or we encourage them all to
apply for OIDs, perhaps in the ITU arc (they need the work and
revenue) and provide that only OIDs are to be listed.

And maybe this does go with some sort of "Preferences-honored"
header so that the truly concerned client can reject content
from any server that doesn't appear "safe" enough.

Now, my personal opinion is that this won't accomplish much
except in the subset of cases where both users/clients and
servers are acting with considerable good sense, flexibility,
patience, and maybe a bit of humor about what is going on and
feasible.  I think Mark assumes that there is a lot more of that
around than this thread has assumed and I agree with him.
However, turning around Mark's concern about overzealous
jurisdictions and Graham's observation about the UK situation,
it could provide a framework to prevent the zealots from causing
much broader problems (or at least to push back on them).  If
that parameter has a value of "Mational Purity Commission of
Lower Slobbovia", the server at least knows what it is up
against rather than having to play an unlimited form of the
nasty game of "you provide it and then we get to decide whether
you a criminal".  As Graham said, "A mechanism like this might
provide an alternative to the blunt and damaging instrument of
censorship at the Internet subscription level."   And that might
be useful enough.

    john

IPR disclaimer: Many years ago, when it looked like the W3C work
might go somewhere (and even be required by overzealous
regulators), Rohit Khare and I came up with an idea about
letting organizations reify those preference models into a
simple set of discrete, perhaps ordinal, categories.  Some of
the idea above is derived from that work or the thinking that
went into it.   MCI filed a preliminary patent application on
the idea.  Then, in some order, he left, I left, and MCI ended
up with bigger battles to fight.  As far as I know (after having
done a bit of research) the actual patent application was never
filed and any relevant IPR claims are now dead.  But I don't
know that for certain and there might be something floating
around out there somewhere.  I have no firsthand knowledge one
way or the other and will not file a third-party disclosure
because I don't believe there is anything to disclose nor would
I know what to say.  But those who are inclined to spend time
worrying about such things have now been warned.

---

From: Eric Burger <[email-masked]>
Date: Sun, 27 Jul 2014 11:03:55 -0400

John’s arguments lead me to think we should just do the binary hint and be done with it. Here is why:

1. People seem to want something. Nothing has been a vacuum that a number of experiments have tried to fill. Ignoring the need will foster incompatible ‘solutions.'

2. People do not care about an all-encompasing, covers all situations marking mechanism.  Lots of effort went into the W3C 3P thing, and it’s still not out there.

3. ‘hint’ is simple enough that if need be, we can extend it later.

I am reminded of packet switched versus circuit switched or SMTP versus X.400 or IP versus ATM or LDAP versus X.500. The former was said to be way too simple to be useful. The latter was said to be way to complicated to be used. I would offer that years on, the X.400, ATM, and circuit switched folks were somewhat right: ESMTP today has a lot of the functionality X.400 had out of the box, IP now has MPLS which ATM had out of the box, etc. However, without the deployment of the simple stuff, we would not have anything.

So, do the simplest standard, a binary safe-hint, and in a few years if people really want more fine gradations, we will know what they are and have an idea how to do them.

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Jul 2014 11:17:54 -0400

--On Sunday, 27 July, 2014 11:03 -0400 Eric Burger
<[email-masked]> wrote:

> John's arguments lead me to think we should just do the
> binary hint and be done with it. Here is why:
> 
> 1. People seem to want something. Nothing has been a vacuum
> that a number of experiments have tried to fill. Ignoring the
> need will foster incompatible 'solutions.'
> 
> 2. People do not care about an all-encompasing, covers all
> situations marking mechanism.  Lots of effort went into the
> W3C 3P thing, and it's still not out there.
> 
> 3. 'hint' is simple enough that if need be, we can extend
> it later.
> 
> 
> I am reminded of packet switched versus circuit switched or
> SMTP versus X.400 or IP versus ATM or LDAP versus X.500. The
> former was said to be way too simple to be useful. The latter
> was said to be way to complicated to be used. I would offer
> that years on, the X.400, ATM, and circuit switched folks were
> somewhat right: ESMTP today has a lot of the functionality
> X.400 had out of the box, IP now has MPLS which ATM had out of
> the box, etc. However, without the deployment of the simple
> stuff, we would not have anything.
> 
> So, do the simplest standard, a binary safe-hint, and in a few
> years if people really want more fine gradations, we will know
> what they are and have an idea how to do them.

FWIW, except for the last comment above, this completely works
for me.  The organizational parameter suggestion was only if
someone really felt a need to do "more".  Where Eric and I
disagree, but not by much, is about the fine gradations becoming
clear enough that we could do something useful with them.  We
tend to talk about these things in terms of jurisdictions and
other rather crude differences but perceptions of what is
reasonable for children is deeply cultural and/or religious.
People have been trying to sort out a common, non-judgmental,
and unbiased way to describe those differences for many
centuries.  The amount of progress that has been made strongly
suggest that the odds of a new and complete understanding
emerging "in a few years" that is good enough for us to "know
what they are and have an idea how to do them" seems very
slight.   The roots of the organizational idea lie in the notion
that people often can at least identify someone or some
organized group whom they trust to speak for them about these
preferences.

I really don't see much hope of engineering our way out of this,
no matter what set of procedures we were to adopt.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Jul 2014 17:19:45 +0100

FWIW, I agree with Ted's position. I'd prefer we don't do this.

While it may be deployed, I suspect that standardising this
will lead us down a bad path where effort is wasted on trying to
develop more fine-grained values. I think the discussion so far
indicates that such a development is highly likely no matter that
the proponents of this would like it to remain a single bit
signal forever.

And while DNT is different from this in some respects, in others,
they are the same - an underspecified signal is emitted by a browser
in the hope that an unspecified and unenforceable action is taken
by a server. The IETF did exactly the right thing in rejecting the
idea of standardising DNT and should do the same here. (In fact,
I bet if you asked W3C folks now, they might agree that taking
on DNT was a mistake;-)

Separately, (in terms of arguing against adoption), I don't believe
this is required for interoperability, and could do some damage
to interoperability, if badly implemented on the server side,
and given the unspecified nature of the server side here that
seems not unlikely.

For example, I'm concerned that the word safe may be interpreted
in a way that is not intended and that is applied to more than
just one request/response pair or even more than just the web.
I've heard various Chinese folks, some government, some not, talk
where translators have used the word safe to mean what appears to
me to specifically denote a government controlled Internet. I would
therefore be concerned that a browser emitting this signal might
be treated as preferring a network where e.g. the use of encryption
is at best frowned upon, where middleboxes interepting everything
is considered the norm etc.

I don't know if that's likely or not but haven't seen this aspect
raised. And I'm not sure that documenting that the prefer value
is only meant to apply to *this* HTTP request/response pair will
help much. If a single prefer header were to affect more than one
request/response pair, then if e.g. my calendar emitted that signal
(on the basis that it'd be no harm) that might cause a server to
fail to send content to my browser that I need.

I'd also object to the text in the draft that says that a proxy
"can be used" to enforce this, but doesn't say how. That could
of course be deleted or maybe fixed if this is adopted, but I'd
not be surprised to hear someone saying that adopting this means
that we have already agreed to specify how a proxy can force this
setting for all browsers. FWIW, I do not accept that proposition.

So for me:

Prefer: just-say-no

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Jul 2014 17:25:35 +0100

Sorry, I forgot one thing.

I think this proposal is one where appsawg (or any area-wg more
generally) is too narrowly focused and where it would be much
better if a WG were formed so that the entire IETF could weigh
in on its charter.

IMO treating the HTTP forwarded header as this one is being
treated was a similar mistake. By the time that draft reached
the IESG, it was effectively too late to make any substantive
change and we ended up with an almost-blocking batch of
abstain ballots. I could see that happening in this case.

Stuff like this is really of interest to more than just the apps
area I think and should not be adopted without at least some
message being sent to the main IETF list.

S.

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Jul 2014 12:32:04 -0400

--On Sunday, 27 July, 2014 17:25 +0100 Stephen Farrell
<[email-masked]> wrote:

> Stuff like this is really of interest to more than just the
> apps area I think and should not be adopted without at least
> some message being sent to the main IETF list.

Of course, the same things could be said about the DNS
operational aspects of "nullmx" and of a huge number of other
relationships.  On the other hand, if the work were done by
individual submission rather than an area WG, the community
would have even less opportunity to comment, even with four
weeks instead of two to do it.

   john

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Jul 2014 17:36:39 +0100

> weeks instead of two to do it.

That's fair, and different folks will find an area wg suitable
or not for different things. For example, I think processing
the nullmx thing in appsawg was just fine, but then I care
more about this topic than that. I'm fine that whoever judges
the consensus for the adoption call takes that factor into
account.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jul 2014 10:56:40 +1000

Hey Stephen,

> the proponents of this would like it to remain a single bit

I'm a bit confused by your position, since from what I see, there are a very large number of people who are strongly arguing against doing something more complex / fine-grained, and a few people saying it "might be useful," but only speculatively.

So what's the problem? Does anyone here strongly feel that this MUST be more than one bit and is prepared to defend that position -- or are we just fighting paper tigers?

Regards,

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jul 2014 02:12:14 +0100

Hiya,

On 28/07/14 01:56, Mark Nottingham wrote:
>> While it may be deployed, I suspect that standardising this will
>> lead us down a bad path where effort is wasted on trying to develop
>> more fine-grained values. I think the discussion so far indicates
>> that such a development is highly likely no matter that the
>> proponents of this would like it to remain a single bit signal
>> forever.
> 
> I'm a bit confused by your position, 

The above is not the entirety of my position, just one part.
I'm happy to try explain this part or the others further of
course.

> since from what I see, there are
> a very large number of people who are strongly arguing against doing
> something more complex / fine-grained, and a few people saying it
> "might be useful," but only speculatively.

Yes, that's accurate as a description of the list traffic on
this thread to date.

> So what's the problem? 

IMO one (not the only) possible problem is that those voices
wishing to generalise the signal will win in the long run, no
matter what is the consensus at the start. I don't think there
is any way to objectively evaluate that so its just my opinion.
And the opposite opinion is also just that, i.e. opinion.

> Does anyone here strongly feel that this MUST
> be more than one bit and is prepared to defend that position -- or
> are we just fighting paper tigers?

Fallible as I and we all are, I don't think we need such an argument
to conclude that the number of folks proposing extensions here is
perhaps the tip of an iceberg. While it may be reasonable to discount
my concern, its also reasonable (I claim) to choose to navigate so
as not to have to ever worry about that particular iceberg.

S.

> 
> Regards,
> 
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jul 2014 11:22:33 +1000

> as not to have to ever worry about that particular iceberg.

So, AIUI roughy -- "somebody might come along down the road and somehow overcome widely-held, strong arguments; therefore we shouldn't do anything."

Alternatively, we could get consensus on constraining it to one bit before adopting the document, put that in the charter if need be, and ship the thing in a couple of weeks.

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jul 2014 02:29:49 +0100

On 28/07/14 02:22, Mark Nottingham wrote:
>>> Does anyone here strongly feel that this MUST be more than one
>>> bit and is prepared to defend that position -- or are we just
>>> fighting paper tigers?
>> 
>> Fallible as I and we all are, I don't think we need such an
>> argument to conclude that the number of folks proposing extensions
>> here is perhaps the tip of an iceberg. While it may be reasonable
>> to discount my concern, its also reasonable (I claim) to choose to
>> navigate so as not to have to ever worry about that particular
>> iceberg.
> 
> So, AIUI roughy -- "somebody might come along down the road and
> somehow overcome widely-held, strong arguments; therefore we
> shouldn't do anything."

Well, no. More accurate would be "someone might come along down
the road and gain consensus for widely repeated arguments for
extending this, therefore that is one more argument amongst
others for not doing this particular thing."

> Alternatively, we could get consensus on constraining it to one bit
> before adopting the document, put that in the charter if need be, and
> ship the thing in a couple of weeks.

I don't think we can practically constrain future IETF consensus
that way. If this does go ahead, attempting to constrain the future
as you suggest is probably a less bad plan than not doing so. But
it being reasonable to contemplate that we try to control the future
in such a way does seem to indicate (to me anyway) that this is a
potentially problematic spec.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 27 Jul 2014 18:41:37 -0700

Given your worry that someone might successfully extend this specification in the future, but we might stop them from doing their own (dangerous) multi-faceted header, would your concern be mitigated by something in the spec that says "this header may never have any value than the one specified in this document"?

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Sun, 27 Jul 2014 19:08:11 -0700

You could create such a constraint for the safe preference specifically but
not for the Prefer header itself. That's already been defined.
On Jul 27, 2014 6:41 PM, "Paul Hoffman" <[email-masked]> wrote:

> Given your worry that someone might successfully extend this specification
> in the future, but we might stop them from doing their own (dangerous)
> multi-faceted header, would your concern be mitigated by something in the
> spec that says "this header may never have any value than the one specified
> in this document"?
>
> --Paul Hoffman

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 28 Jul 2014 09:00:04 +0000

Hi Stephen,

sorry I don't completely understand if you are concerned about the possibility
that the signal will be generalised somehow in the future
or you concern more about the "safe" concept in general.
In the case it is the latter I would like to understand better your concerns.

thanks
Salvatore

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jul 2014 10:44:36 +0100

Apologies for not being clear enough. I'll try again.

> that the signal will be generalised somehow in the future

Right, that is one concern. I personally don't think that we'll
be able to keep it to one bit in the longer term. But that's
just my prediction, which is as imperfect as anyone else's.

> In the case it is the latter I would like to understand better your concerns.

Yes, the specific new concern that I raised there relates to
equating this signal emitted from a browser with the "safe"
concept of networking in general that seems to be espoused
by for example the Chinese govt, where "safe" is apparently
interpreted to mean quite a few things with significant
impact on networking in general. A server-side or a n/w that
did that could badly impact on interop.

I also think the similarity with DNT is worrying. We were
absolutely correct to not take that one on, as its troubled
history within W3C I think shows.

And I think this topic ought be considered by the IETF as
a whole and not only on appsawg, before the work is adopted.
Looking at appsawg's charter I think its fair to say that
this is not a "small-scale addition" to HTTP - while it may
appear so in terms of bits on the wire, the impact of that
one new bit in a request is arguably large-scale. And I'd
also argue that the ADs would be justified in thinking
"wider input is needed before accepting the proposed work
item."

Cheers,
S.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 28 Jul 2014 18:07:07 +0000

thanks for the clarification
more in line

> did that could badly impact on interop.

<sal>about this specific concern, is more about the fact that the "safe" word can be
"interpreted" in quite a broad way or is about the concept per se?

> "wider input is needed before accepting the proposed work

<sal>about doing the work in appsawg, maybe the problem could be
that in this wg the discussion about safe-hint can be easily flooded by mail protocol related discussions.
However it's up to the ADs to evaluate if this is something can be done
in existing wg or it requires an ad-hoc wg.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jul 2014 19:37:18 +0100

Hiya,

> "interpreted" in quite a broad way or is about the concept per se?

The fact that the signal term suggested clashes with that used
(in a translation) to describe general network controls such
as used in e.g. China is a concern. That has two aspects: 1) the
colliding but undefined term indicates a specific actual problem
that could otherwise be considered only a potential issue and
2) the signal emitted could well be (mins?)interpreted as being
much more broad than http or than this request/response pair and
I don't see how to rule that out without assigning at least some
semantics to the signal and thereby invalidating the stated goal
of the proponents that this signal does not have defined
semantics. (If one tried to tie "safe" to one http request/response
then presumably a page-load could result in not-"safe" content
being seen. If one broadens it out then, how much, for how long
etc? Both seem problematic.)

> in existing wg or it requires an ad-hoc wg.

My concern is not where the work is done. My suggestion is that the
IETF as a whole decide on adoption before any commitment (implied
or explicit) is made to finish the work. My concern is that if this
(or any) area wg is used to adopt controversial work like this, that
increases the likelihood of a difficult IETF LC and IESG evaluation,
and it'd be better to have the argument earlier. (Again, HTTP forwarded
should have been handled that way would be my post-mortem take on that
document.)

S.

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2014 19:03:38 -0000

In article <[email-masked]> you write:
>Given your worry that someone might successfully extend this specification in the future, but we might stop them from doing their own
>(dangerous) multi-faceted header, would your concern be mitigated by something in the spec that says "this header may never have any value
>than the one specified in this document"?

No, but it might be helpful to note in the mini-charter for this
document that it is limited to documenting and standardizing existing
practice.

In view of the complete failure of many previous attempt to create
fine grained content labels that people actually use, I am at a loss
to understand why anyone thinks it would be a productive use of
anyone's time to do it again.

R's,
John

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jul 2014 14:41:06 +1000

> did that could badly impact on interop.

How? Please paint me a picture; I'm not seeing the scenario.

> history within W3C I think shows.

DNT asks servers to act against their own self-interest voluntarily, and everyone* knows it's not going to work because of that. This spec does not; in many cases, the interests of the server are well-aligned with their users (as evidenced by the prevalence of 'safe' already using cookies).

> "wider input is needed before accepting the proposed work

What does "considered by the IETF as a whole" mean -- chartering a working group, or slogging it out on [email-masked] (such a constructive list), or...?

Given that I have trouble even getting other WGs to interact with HTTPbis about HTTP extensions, this feels like a very... constructed... barrier. Is there a precedent for it?

Cheers,

* Some with the benefit of hindsight.

---

From: James M Snell <[email-masked]>
Date: Mon, 28 Jul 2014 22:10:43 -0700

> How? Please paint me a picture; I'm not seeing the scenario.

It wouldn't have an impact on interop because there's absolutely no basis
upon which to determine interop in the first place. There is a ton of
inherent ambiguity that does make it unlikely that any two implementers
will actually do the same thing the same way, however. But if implementers
are good with that, so be it. It is just a Preference after all.

Mark: my recommendation would be to publish an independent document on the
informational track. Give it a few years to see what people actually do
with it, then if it seems useful to do so then, do some standards track
thing once there is more implementation experience to back up or refute all
the arguments.

- James

> DNT asks servers to act against their own self-interest voluntarily, and
everyone* knows it's not going to work because of that. This spec does not;
in many cases, the interests of the server are well-aligned with their
users (as evidenced by the prevalence of 'safe' already using cookies).
> What does "considered by the IETF as a whole" mean -- chartering a
working group, or slogging it out on [email-masked] (such a constructive
list), or...?
>
> Given that I have trouble even getting other WGs to interact with HTTPbis
about HTTP extensions, this feels like a very... constructed... barrier. Is
there a precedent for it?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Jul 2014 07:48:02 +0200

James,

On 7/29/14, 7:10 AM, James M Snell wrote:
>
> It wouldn't have an impact on interop because there's absolutely no
> basis upon which to determine interop in the first place. There is a
> ton of inherent ambiguity that does make it unlikely that any two
> implementers will actually do the same thing the same way, however.
> But if implementers are good with that, so be it. It is just a
> Preference after all.
>

If the flag is set, then the server may wish to render alternate content
or a warning or in fact it may wish to redirect the user to another
location.  I don't see that really as an interoperability problem, but
rather more as a result of interoperability.

Eliot

---

From: James M Snell <[email-masked]>
Date: Mon, 28 Jul 2014 22:57:20 -0700

Such behavior may emerge as being common. I'm saying that the spec itself
provides zero basis for interop, that will only come from implementors
deciding to do things in similar ways, which won't be based in spec.
Therefore, it makes no sense to have a standards track spec or a WG
spinning cycles on it

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Jul 2014 09:35:26 -0400

--On Sunday, July 27, 2014 18:41 -0700 Paul Hoffman
<[email-masked]> wrote:

> Given your worry that someone might successfully extend this
> specification in the future, but we might stop them from doing
> their own (dangerous) multi-faceted header, would your concern
> be mitigated by something in the spec that says "this header
> may never have any value than the one specified in this
> document"?

Paul,

My sense is that our track record when saying "this may never
have any value..." has been rotten.  The people, or
implementers, who think they need additional capabilities just
ignore such constraints and do their own thing, typically in a
way that creates confusion rather than interoperability.    If
we were going to do anything along those lines, it would be
better to lay out some minimal syntax with no semantics and then
reserve it for future extension and explain why the reservation
is needed and specify what to do if a current-technology server
implementation encounters a use of the extended syntax.  

So, if one wants to try to keep the spec to a single bit (at
least until some other consensus emerges), it would probably be
best to specify a parameter field (see
draft-snell-http-prefer-18), to specify that it is reserved for
future expansion and semantics, and even to require that, should
a non-null parameter field appear, it most contain a version
number and, for now, a value of 0 and nothing else and that a
server encountering a non-zero version number or parameter field
not containing such a version number must treat the field as
missing.  If one wanted to be really aggressive about that, one
might require that a server encountered a non-empty,
none-version-zero parameter would return an error message rather
than any web content.   

That is a bit extreme but, if we really want to "stop them from
doing their own...", that would probably do it where "never have
any value..." would not.

Stephen,

I don't see the Chinese issue as particularly relevant to this
proposed extension.  Their current policy, at least as widely
reported outside China, is "nothing is allowed on the network
that is not 'safe' as we define it".  The presence of a header
that says "I prefer 'safe'" would have no impact at all,
positive or negative, on such a policy since there is already a
policy requiring that sites emit only "safe" material (whether
the header is present or not).  It would be different if there
were no precedent for sites returning different, or a more
restrictive set of, material for different types of users but
the sites Mark identifies have already shown both the ability
and willingness to do that.   

FWIW, while the definition of "safe" varies, the perceived
Chinese requirement/behavior is not, AFAICT, significantly
different from that advocated by various "conservative" or
Internet-afraid legislators around the world.  I'm afraid of
those legislators, but I don't see how this header would affect
them one way or the other.  In that regard, it is somewhat like
the evil bit of RFC 3514 and far more like the claims that
ICANN's delegation of the XXX TLD would make the Internet safe
for children and others who didn't want to be exposed to
pornography.  I don't expect this header to be very useful, but
suspect that standardizing it, with appropriate disclaimers,
might turn out to be better than leaving each system to figure
out its own format and implied semantics.

    john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Jul 2014 10:55:38 -0400

> etc? Both seem problematic.)

Stephen, I think this is a real stretch.
The document doesn't just throw out "safe" with no explanation at all,
and more explanation of what's intended could easily be added to make
it yet clearer.  But if we're trying to make it so that nothing we do
could be misinterpreted and abused by parties inclined to abuse it,
we're going to fail, and we'll do nothing.

>>> history within W3C I think shows.

There's very little similarity with DNT.  DNT said, "I know you want
to track the user, but the user doesn't want that.  Please don't."
Safe-hint says, "You have a 'safe' setting that you offer the user.
The user is hereby opting into that."  They vastly different things,
with the only similarity being that they're both using HTTP headers to
request a feature.

>>> one new bit in a request is arguably large-scale.

I think this is a stretch also.  In any case, I'll point out that what
little objection there is, is from a vocal minority; that this *is* a
small-scale addition with one person (you) trying to argue that it's
more than that; that appsawg has quite broad participation; and that
the IETF community outside appsawg will be able to comment during last
call, which is likely to happen very quickly.

Barry

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2014 17:46:08 -0000

>thing once there is more implementation experience to back up or refute all

I'm sorry, but that makes no sense.  This draft is already more widely
implemented than half of the proposed standards we've published in the
past decade.

All it says is "if you want to have a one-bit safe content flag,
here's how everyone else does it."  It's clear that you really hate
this hack, but the objections appear to assume that it will never be
implemented, which we know isn't true.

Telling people not to use such a flag isn't an option, since they
already do.  We're the standards group, not the content czars.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Jul 2014 16:15:32 -0400

On Jul 29, 2014, at 1:46 PM, "John Levine" <[email-masked]> wrote:

> here's how everyone else does it."  

How/when is it activated? How do severs use it?  Any examples?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 30 Jul 2014 10:07:09 +0200

Servers don't use it, web applications do.

Some web applications have some sort of cookie, like Google's "safe 
search", which tells Google wether to show you goatse. This HTTP header 
merely supplies a default if the site has such a cookie and that cookie 
isn't set in your browsing session.

Arnt

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Jul 2014 10:32:42 -0400

Intranet servers surely can use it.  With such systems, file I/O applications are built in and custom web applications and web sites don't need do a thing.  It (access controls) are automatic.  Thus far, based on my web tech readings, the browsers queries the Windows OS for its parent controls registry settings and sets the http header for all queries.   Cookies is more of the details but it would be per web site, if any, and may not be necessary.  Cookies could be another "safe" control bit as well, i.e. cookies can be disabled independent of any other safe bit intention, right?  If not, then that particular dependency needs to be in the "specs."

Rhetorically, I want to know one thing in order to consider the implementation directly into our intranet package or just allow the web site developer use it -- under what specific, practical circumstances will it be enabled?  All I see is parental controls at the moment.    In other words, I am looking for a generality here, so it does not matter what http client is coming in, which we know does not need to be a "browser."

> On Jul 30, 2014, at 4:07 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Some web applications have some sort of cookie, like Google's "safe search", which tells Google wether to show you goatse. This HTTP header merely supplies a default if the site has such a cookie and that cookie isn't set in your browsing session.
> 
> Arnt
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 31 Jul 2014 02:31:42 +0200

You mention access control. Well, it's called "prefer" because it's not 
access control, it's a preference. It says "hello, web page, if you're just 
going to ask me something like google's safesearch question, you may assume 
that I'll answer yes."

Arnt

---

From: Hector Santos <[email-masked]>
Date: Thu, 31 Jul 2014 12:11:12 -0400

Hi Arnt,

The funny thing about the IETF and its work effort, is that we are often asked to adopt a work effort proposal but for the most part it is really asking to support, endorse what has already been written as is.  Of course, we "prefer" the most obvious items clarified, refined, fixed and/or removed or even split for additional work.  I hope we can keep with the latter effort and not "rubber stamp."  However,  maybe what we got now as an informational status document is sufficient.

In my opinion, this proposal touches base with an "access control" (info filter) mechanism where the proposal is using the term "prefer" or preference because it is the current logical practical relationship or "tie-in" to what currently exist and presented as UI options or "preferences" to browser users and/or at the OS level with admin access,  i.e.  See Windows vista/7/8 Control Panel or search how parental controls was approached without then prefer header [1, 2, 3].

In other words, this was not done in the blind.  The proposal genesis is 100% regarding parental controls which does include "safe search" concepts for that particular application.  Parental controls should be the main focus since it is the most production we can get from it today. If we are thinking about other open ended potential abstract controls, then some additional HTTP request  prefer attribute should probably be included.  But "prefer: safe" by itself, today, is about parental controls.

This is an informational status doc and I guess in that respect, it's publication, even as a draft, has advertised sufficiently to the ISV world that this concept exist for implementation on both ends,  We can pretty much stop here.  It exist, parental controls and it's important today, how do we communicate this to servers?  

Based on my technical reading and history of the parental controls design issues which goes back as far as 2007 with the earlier OSes first making it available,  the prefer header is a new 2014 proposal to help satisfy a big part of the Parental Control filtering missing from the client/server web model. 

In other words, additional BCP or PS documents will probably be needed to cover the technical aspects of what already has been done without the prefer header and also show how the new prefer header will assist in this "filtering" process but this time from the server side.   The proposed header will make it easier for the client side by reducing and simplifying its filtering overhead by allowing the server to do some of the filtering upfront. 

Right now, based on current http request/response filtering blocking methods, if a server was to see a prefer header and decides a particular content should be filtered, a http 450 response is used to convey this blocking action to the client.  That is what I currently extract from the research on the subject.

Finally, our server can definitely use this header for filtering request and server content. So I support whatever effort the IETF decides.

[1] http://support.microsoft.com/kb/2980016
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms711890(v=vs.85).aspx
[3] http://parents-in-education.moe.gov.sg/pie/slot/u1/Resources%20and%20References/cyberwellness/Internet%20Browsers.pdf

> On Jul 30, 2014, at 8:31 PM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> You mention access control. Well, it's called "prefer" because it's not access control, it's a preference. It says "hello, web page, if you're just going to ask me something like google's safesearch question, you may assume that I'll answer yes."
> 
> Arnt
>