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

From: "John Levine" <[email-masked]>
Date: 23 Oct 2014 14:06:35 -0000

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

I have read this draft and support its adoption.

It describes a very simple http option that is already adopted by
several widely used browsers and several popular web sites.  It would
be nice to document it on the standards track so other browsers and
web sites that implement it (which they will) do so in a compatible way.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Oct 2014 19:53:12 +0100

I think doing this is a bad idea and commented on that before
on apps-discuss. [1] (Start of that mega-thread is [2])

I think all the same objections apply other than the one that
called for the discussion to be had here rather than in appsawg.
(And thanks Barry for doing that.)

S.

[1] https://www.ietf.org/mail-archive/web/apps-discuss/current/msg12628.html
[2] https://www.ietf.org/mail-archive/web/apps-discuss/current/msg12512.html

On 21/10/14 22:33, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'The "safe" HTTP Preference'
>   <draft-nottingham-safe-hint-05.txt> 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
> [email-masked] mailing lists by 2014-11-18. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> 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.
> 
> 
> 
>

---

From: "John Levine" <[email-masked]>
Date: 23 Oct 2014 19:31:31 -0000

>web sites that implement it (which they will) do so in a compatible way.

It's probably worth mentioning that among the virtues of this draft
is that it is specifies a single bit with no provision to extend it.

R's,
John

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 Oct 2014 17:36:42 -0400

On Thu, Oct 23, 2014 at 3:31 PM, John Levine <[email-masked]> wrote:
>...

I believe it has many of the problems discussed in RFC 3675.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Oct 2014 13:35:36 -0700

Hello,
>[email-masked] mailing lists by 2014-11-18. Exceptionally, comments may be

Having the IETF publish this safe hints proposal as a Proposed 
Standard is not a good idea.  However, I do not oppose that as it 
will not have a negative impact on my interests.  I am in two minds 
about whether to suggest to a regulator to set a requirement for this 
(intended) standard or not.

 From Section 1:

   'That said, the intent of "safe" is to allow end users (or those
    acting on their behalf) to express a desire to avoid content that is
    considered "objectionable" within the cultural context of that site;
    usually (but not always) content that is unsuitable for minors.'

I did not understand the meaning of "cultural context of that site" 
in the above.  Does it mean that content unsuitable for minors in one 
country may be deemed suitable in another country?

Does cultural context mean that a site that is considered as 
appropriate in, for example, Canada would not be considered as 
appropriate in the Norway?

 From Section 2:

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

 From https://support.google.com/youtube/answer/174084?hl=en

   "While it's not 100 percent accurate, we use community flagging,
    age-restrictions, and other signals to identify and filter out
    inappropriate content."

The criteria mentioned above might have to be clarified.

 From https://help.pinterest.com/en/articles/safe-mode

   "Safe mode prevents any changes to your account until you reset
    your password."

"Safe mode" means something else on that site.

The site at https://www.facebook.com/about/privacy/minors could be 
encouraged to implement this proposal.

Minors are ingenious.  It is simply a matter of time for them to 
figure out how to bypass the mechanism proposed by this draft [1][2][3][4].

Regards,
S. Moonesamy

1. http://www.bbc.com/news/technology-25759345
2. https://twitter.com/dalerapp/status/511897259882340352
3. https://twitter.com/25Taters/status/329596015005011969
4. https://twitter.com/coolstarorg/status/497960379444510720

---

From: t.p. <[email-masked]>
Date: Fri, 24 Oct 2014 12:23:20 +0100

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 23, 2014 3:06 PM
> I have read this draft and support its adoption.

Me too.  It seems a straightforward step in the right direction for the
Internet at large.   It is a small step but then taking small steps in
the right direction is something that the IETF does rather well.

Tom Petch

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Oct 2014 08:07:19 -0400

> web sites that implement it (which they will) do so in a compatible way.

+1

The arguments against this specification seem wholly to rely on pure
speculation, biased in one direction and with no special foundation to
justify the speculation. So, one could, just as easily, assert
/favorable/ speculation and claim that that demands publication.
Neither line of fantasy is very helpful to a standards process.

Worse, the speculation completely ignores that this is providing a
support mechanism for an existing capability.

I thought the IETF considered it useful to document existing practice.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Oct 2014 14:26:26 +0200

> the right direction is something that the IETF does rather well.

+1.

Eliot

---

From: [email-masked]
Date: Fri, 24 Oct 2014 11:54:19 -0700 (PDT)

> the right direction is something that the IETF does rather well.

I have also read the draft, and while I'm not entirely enthusiastic about the
approach, it's quite clear this is going to happen regardless, and having a
standardized mechanism for it strikes me as a far superior situation than
having a bunch of nonstandard ways to do it deploy.

I also find the objections to adopting it I've seen so far to be lacking
foundation.

I therefore support adoption of this draft.

				Ned

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Oct 2014 22:49:08 +0300

Hi

I have read the draft, and I do not support its publication. What worries me about it is not speculation about extensions that we’ll be asked to do or mis-use by content providers. It is that there is no way to use it properly. The drafts does not specify what “safe” content is and what “unsafe” content it, and some people treat this as an advantage. The result is that there’s no way for a content provider to know what a user means when their browser emits the “safe” hint, and no way for the user to know what kind of content they are going to get.

Stephen Farrell has made some interesting points about what “safe” might mean in other cultures. I think the failure is much closer to home, so let’s assume for the sake of argument that everyone affected is mainstream American (although neither Stephen nor I are Americans). So obviously anyone would consider porn to be “unsafe”, because we don’t want the children to see it and we don’t want it at work. A rabbit teaching the alphabet to kids OTOH is “safe” ([1]). But those are the easy types of content. What about political content? What about political content that is non-mainstream? Even inflammatory? Is it safe? For whom?  A signal is useless if there is no agreed-upon semantic to it. Yet the draft punts on attaching such a semantic. 

Section 3 mentions YouTube. That is actually a perfect example of what I mean. Sites like YouTube, deviantArt, Flickr, and Wattpad, even Wikipedia provide user-generated content.How are they to decide what is and isn’t “safe”? They have several choices:
 - They can ask the contributors to mark their content. Many of them do that. When you upload something, they require you to mark it as “mature”, “strictly mature” or not, and you even get to pick one of several categories of mature: "nudity", "sexual themes", "violence/gore", "strong language", and “ideologically sensitive”.([2])  They can use those indications in filtering content for people who prefer their content “safe”. But what happens when a user complains that the content they got was non-safe even thought it doesn’t fall into those categories?  (although “ideologically sensitive”?  Anything can fall into that!) 
 - They can assume everything is safe until someone complains. That makes sense. Everything that someone objects to is by definition objectionable. Pretty soon, only the alphabet-teaching rabbit is considered safe, and people have to turn off the hint to get anything done. 
 - They can intelligently (through a combination of heuristics by computers and human intervention) actually judge all content to figure out some rational definition of safe. There’s two problems with that. First, it’s hugely expensive. Wikipedia would die if it needed to do that, and I doubt even Google can afford to have people watch all of Youtube’s videos to rate them.. Second, whatever definition of “safe” they came up with, the users may not agree with them. 

IMO this does more harm than good, and I think we should not publish it.

Yoav

[1] yes, there are some who view talking animals as a violation of the second commandment. I did say “mainstream” Americans.
[2] that is also a great argument against the claim that content providers want just one bit. I think it is the browser vendors who aren’t willing to emit more than one bit.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Oct 2014 16:12:56 -0400

On Fri, Oct 24, 2014 at 10:49:08PM +0300, Yoav Nir wrote:
> 
> no way to use it properly. The drafts does not specify what “safe”
> content is and what “unsafe” content it, and some people treat this
> as an advantage. 

Not as an advantage, but the whole point of the feature.

> The result is that there’s no way for a content
> provider to know what a user means when their browser emits the
> “safe” hint, and no way for the user to know what kind of content
> they are going to get.

This is true.  It is also what is the case on the Internet today.

Suppose the feature, instead of being called "safe", was called
"userflag".  Sites had a local policy that provided one set of
functionality when userflag=1 and a different set of functionality
when userflag=0.  What the policy was varied from site to site, and it
was up to users to know, for any site, what the policy would be if
they turned userflag on.  But once they did, then they'd get the
userflag-enabled service from that site.

"Ah," you might reply, "but what the user actually wants is a
fine-grained preference control system.  So the userflag feature is
stupid and bad and we should prevent it."

Moreover, suppose that there already was a mechansism that permitted a
user to expose all the things that he or she did and did not want to
experience in using a site, and that its main problem was that nobody
used it.

The story above is roughly what we have here.  There is already at
least one well-specified, comprehensive vocabularly for you to express
all the things you think to be safe and non-safe:
http://www.w3.org/PICS/.  It is, in commercial terms, almost a total
failure in the sense that it's too hard to use and doesn't solve the
problem people think they have.

As a result, sites offer a "safe mode" that does whatever it is that
the site does.  It isn't anything that I personally find at all
useful, and I think that trusting sites to have the same judgement as
I do suggests a touching faith in humankind.  But the full-bore system
is already there, it doesn't get used, and people are already using
this one-bit style of approaching the problem.  All the draft does is
say, "If you're going to use this one bit style, please signal it
thus."

If the goal is interoperability on the Internet, it seems to me that
getting all the dumb ways to "protect" yourself to signal "dumb
protection, please" the same way is a good thing.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked]
Date: Fri, 24 Oct 2014 13:20:41 -0700 (PDT)

> I therefore support adoption of this draft.

Small point of clarification: By "approach" I meant the underlying apporach of
having a safe mode, not the mechanism defined by the draft to control it. Poor
word choice on my part; sorry.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 24 Oct 2014 20:28:25 -0000

>... The result is that there’s no way for a content provider to know
>what a user means when their browser emits the “safe” hint, and no way for the user
>to know what kind of content they are going to get.

Mozilla Firefox, Microsoft Internet Explorer, and Google's Bing search
engine have already implemented it.  Could you please clarify why
Bing's implementation doesn't work?  On the Bong homepage at
http://www.bing.com, there's a gear icon at the upper right.  Click
that, and you'll find a discussion of their existing SafeSearch
feature that may be helpful.

At the bottom of Google's search page at https://www.google.com is a
"Settings" button.  If you click that, you'll find that one of the
settings is an option called SafeSearch that you can turn on and off.
It's currently implemented in a cookie, but I hope it's obvious how
they could use the safe hint to turn on the same setting.  Can you
clarify why this feature doesn't work, and why using the safe hint
would make it worse?

>Section 3 mentions YouTube. That is actually a perfect example of what I mean. Sites
>like YouTube, deviantArt, Flickr, and Wattpad, even Wikipedia provide user-generated
>content.How are they to decide what is and isn’t “safe”?

I'm just guessing, but my guess is that they will do it exactly the
way they do right now.  If you look at https://www.youtube.com and
scroll to the bottom of the page, you will see a box where it says
"Safety" Off" or "Safety: On".  If you click it, they show a short
summary of what it means, and you can turn it on and off.  Can you
clarify why this feature doesn't work, and why they couldn't use the
safe hint flag to set the same preference?

R's,
John

---

From: Yoav Nir <[email-masked]>
Date: Sat, 25 Oct 2014 00:09:15 +0300

> On Oct 24, 2014, at 11:28 PM, John Levine <[email-masked]> wrote:
> 

So is the Prefer: Safe header the same as “Moderate SafeSearch”, or “Strict SafeSearch”. Because apparently they need two bits of information, not just one.

Youtube and Goodle Search have just one bit. Flickr, deviantArt have multiple bits. 

> summary of what it means, 

True, except that with a browser hint, you don’t get to see the site-specific explanation of what “safe” means.

Yoav

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Oct 2014 18:12:52 -0700

Hi Yoav,
At 12:49 24-10-2014, Yoav Nir wrote:
>Stephen Farrell has made some interesting points 
>about what "safe" might mean in other cultures. 
>I think the failure is much closer to home, so 
>let's assume for the sake of argument that 
>everyone affected is mainstream American 
>(although neither Stephen nor I are Americans). 
>So obviously anyone would consider porn to be 
>"unsafe", because we don't want the children to 
>see it and we don't want it at work. A rabbit 
>teaching the alphabet to kids OTOH is "safe" 
>([1]). But those are the easy types of content. 
>What about political content? What about 
>political content that is non-mainstream? Even 
>inflammatory? Is it safe? For whom?  A signal is 
>useless if there is no agreed-upon semantic to 
>it. Yet the draft punts on attaching such a semantic.

I think that Stephen and you raised good 
points.  I was testing some stuff recently and I 
noticed that Google did not serve the same 
content.  There are other sites which do not 
allow me to view some content because of my 
location.  In the first case it is for regulatory 
reasons whereas in the second case it is for 
commercial reasons.  When it comes to porn it is 
viewed in a country as a matter of free speech 
(see Free Speech Coalition).  The good part about 
Mark's proposal is that it is closer to the 
user.  Obviously, it is far from perfect (re. safe hint).

What about political content which is deemed 
illegal?   Some governments might block the 
content.  Some governments use other means to 
tackle that.  Would the IETF standardize 
that?  There have been proposals about interception; they did not go far.

>Section 3 mentions YouTube. That is actually a 
>perfect example of what I mean. Sites like 
>YouTube, deviantArt, Flickr, and Wattpad, even 
>Wikipedia provide user-generated content.How are 
>they to decide what is and isn't "safe"? They have several choices:

Some of the sites mentioned above monetize 
user-generated content.  There is a commercial 
incentive for them to figure out the semantics of 
"safe".  I doubt that Wikipedia would die anytime 
soon (see http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative ).

The question I would ask is whether Mark's 
proposal puts the user at risk.  I don't see an 
increase in risk.  The proposal does not attempt 
to touch encryption stuff.  It might help to 
reduce the pressure to standardize state interception services.

Regards,
S. Moonesamy

---

From: joel jaeggli <[email-masked]>
Date: Sun, 26 Oct 2014 20:26:57 -0700

> beginning of the Subject line to allow automated sorting.

I think this a bad idea.

A safe hint could have a semantic meaning if it were to express what
the user meant by safe. Were that the case it would in many respects be
privacy revealing (I am child, I am browsing from a computer in a US
federal office building, I am a resident of an Amana colony, a kibbutz,
or the temple of Set) and therefore only appropriate between parties
with a pre-existing or at a  minimum consent based relationship.

As it is the meaning of a safe hint is to be intuited by the recipient.

I send you the request you send me the bits, if I need to run software
that applies meaning and context to those bits and chooses therefore to
fail to serve them that's my business.

joel

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2014 17:57:57 -0000

>As it is the meaning of a safe hint is to be intuited by the recipient.

Yes.  That's not a bug.

I don't understand the point of hypothetical arguments about whether a
safe flag might be useful.  We already know the answer: Many of the
largest web services in the world already have one.  Youtube puts
theirs right on the home page.

All this does is to provide a consistent interface to the existing
feature, and some operational flexibility to environments like schools
and corporate networks where the person sitting at the browser isn't
the one who sets the content policy.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Oct 2014 11:54:18 +1300

> theirs right on the home page.

John, I don't think the argument is about whether it will work technically
or whether it will be used. The argument is about whether this is something
that the IETF should endorse as a Proposed Standard, which implies that
we think it will be effective.

I would have no objection to this being published as an Informational RFC,
to document existing practice. But to be completely clear, I was *not* being
sarcastic when I compared it to RFC 3514, because its intended semantics can
be ignored by any web site operator that chooses to do so.

   Brian

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Oct 2014 16:13:47 -0700

> we think it will be effective.

Just to be clear: are you saying that you believe that those large web properties already doing this has *not* been effective? I have to believe that they have spent more time than us measuring that, and that they came to the conclusion that it was continuing to be effective.

--Paul Hoffman

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 28 Oct 2014 09:39:37 +1000

On 28 October 2014 08:54, Brian E Carpenter <[email-masked]>
wrote:

> sarcastic when I compared it to
> ​​
> RFC 3514, because its intended semantics can
"If you were going to ask me if I wanted to use your 'safe mode', you can
assume I'd have said 'yes'" -- it's a pretty hard semantic to ignore, and
the cost of doing so is pretty small anyway. My suspicion is that if sites
already present the option, there'd be motivation to support the hint
(better UX, for one), and no reason at all to ignore it. And for sites that
never presented the choice, well, it's irrelevant to them.

It's not really existing practice, either. Yes, content servers providing
an option for consumers to receive whatever version/subset of the content
the servers consider "safe" (in whatever terms they've couched it) is a
thing, but allowing consumers to preempt the question is new, and that's
what's on offer. And this proposal does it in the simplest way, which can
easily be aligned with the sort of options currently in use (and into the
future).

​I think there's value in it being a proposed standard.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Oct 2014 12:45:15 +1300

> Just to be clear: are you saying that you believe that those large web properties already doing this has *not* been effective? I have to believe that they have spent more time than us measuring tha…

No. I mean that a badly motivated web site can pretend to offer safe material
using this but actually offer objectionable material (for whatever definition
of safe or objectionable you care to adopt). For example a site being used
to "groom" innocent victims could pretend that all its content was safe.
This would actually make the site much more dangerous than before, because
of the illusion of safety.

    Brian

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Oct 2014 16:51:25 -0700

> of the illusion of safety.

And you believe that the sites using this feature now have not thought of that, yes? I'm trying to figure out why you think that your analysis of the problem is probably more correct than that of the large sites that have implemented it already.

--Paul Hoffman

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Oct 2014 13:24:07 +1300

> And you believe that the sites using this feature now have not thought of that, yes? I'm trying to figure out why you think that your analysis of the problem is probably more correct than that of t…

I am not worried about sites that use the feature legitimately.

   Brian

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2014 00:49:20 -0000

>of the illusion of safety.

How does this differ from the current situtation?  Any site can show
logos that say "100% family friendly", and have a safe mode flag you
can toggle in your browser.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 17:53:13 -0700

On 10/27/2014 4:45 PM, Brian E Carpenter wrote:
> of safe or objectionable you care to adopt).

Brian,

That's a pretty surprising and quite disturbing criterion.  Apply it
consistently and we get no standards at all.  Ever.  Any site can choose
to be deceptive.

For example, when a message is relayed to a site and it accepts it, we
can't be sure it won't choose to mis-route it.

The purpose of the safe mechanism is to provide a standard way that a
user can state a basic desire to a server.  It is not the purpose of the
mechanism to guarantee that the server will behave honorably.

   1. The mechanism already has plenty of field experience demonstrating
basic utility.

   2. The proposed mechanism opts for simplicity.  More complexity would
actually increase the likelihood that a user's expectation's are not
matched.

Criticisms of the proposal are tending to miss the established
experience, or to propose entirely different designs that have no basis
from that experience, or to raise concerns that are frankly outside the
proper scope of the specification.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Oct 2014 14:25:56 +1300

> can toggle in your browser.

Yes, of course, but now they could automatically persuade a
browser itself that they conform to the IETF RFC7xxx standard
for safe browsing. Maybe the browser could display a little
"figleaf" icon just like the little "padlock" icon.

I'm going to shut up now because I've made my point as clearly
as I can.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 19:13:22 -0700

> "figleaf" icon just like the little "padlock" icon.

"persuade a browser itself" has nothing to do with the current proposal,
since the current proposal stops with making a request to the server.

So there is no model for communicating back to the browser that content
is safe or not, nevermind for communicating up to the user.

Hence this concern is another case of extrapolating far beyond the
current specification, constructing a strawman, and then using it to
argue against the actual proposal.

It would be particularly foolish for a browser to attach a
safety-related icon when there is no safe 'mode' acknowledged by the
server.  And it would be foolish to pursue such an acknowledgement for
the current proposal, since it is seeking a far simpler and more narrow
scope.

d/

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 28 Oct 2014 12:19:17 +1000

> is safe or not, nevermind for communicating up to the user.
Actually, there's Preference-Applied. I don't recall seeing that forbidden
by this draft, and it's a "MAY send" in RFC 7240. That said, it would still
be a bit silly for a browser to add UI to advertise the presence of the
header.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 19:21:25 -0700

On 10/27/2014 7:19 PM, Matthew Kerwin wrote:
> Actually, there's Preference-Applied. I don't recall seeing that
> forbidden by this draft, and it's a "MAY send" in RFC 7240. That said,
> it would still be a bit silly for a browser to add UI to advertise the
> presence of the header.

Forgive me, but:  THAT HAS NOTHING TO DO WITH THIS DRAFT.

My comments concerned only this draft.

D/

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 28 Oct 2014 13:19:11 +1000

> My comments concerned only this draft.
​It's a normative reference. While I support the draft, I'm still willing
to play​ devil's advocate here. Brian has managed to point out that, today,
there's no metadata or side-channel communication from server to browser
that suggests that the content is in anyway "safe", but by standardising
Prefer:safe, we introduce Preference-Applied:safe, which allows servers to
"lie" in metadata as well as in data.

Whether or how much of a lie it is depends on the interpretation of
Preference-Applied:safe

As I said earlier, I don't believe it's an issue, but it's still a new
thing, introduced by this draft. It's right for us to address it, even if
just to say it's not an issue.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 20:29:14 -0700

...
...
> ​It's a normative reference. While I support the draft, I'm still
> willing to play​ devil's advocate here. 

Devil's advocacy can be useful, but it requires some care.

The draft's reference to 7240 is quite narrow, pertaining only to the
basic mechanism used to communicate the preference.  It does not have
any discussion about browser response.

> Brian has managed to point out
> that, today, there's no metadata or side-channel communication from
> server to browser that suggests that the content is in anyway "safe",
> but by standardising Prefer:safe, we introduce Preference-Applied:safe,
> which allows servers to "lie" in metadata as well as in data.

Note that the Security Considerations section already cites exposures
with the mechanism and possible misbehaviors by the server.

d/