Stephen wrote: > 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 We had that discussion before, but to recap where I think we're at: > 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. This isn't relevant, as it's in LC now and no extensibility is allowed (as John points out). > 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;-) DNT doesn't work because the incentives are very poorly lined up; the user is asking the site to do something against its own interest. It needs legislative / regulatory cover to actually work. Safe lines up the incentives very well; sites want to give the users the content they prefer. This is demonstrated on search engines, social network sites, and so on. > 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 really don't know what you're talking about here, Stephen. People who want to willfully misinterpret semantics will do so; we can't prevent that, and more to the point, someone in a position to perform a hostile MITM with legal cover will do so whatever the client says it wants. > 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. Again, I think you're seriously off base and hand-waving here, Stephen. Do you have any evidence that this will actually happen -- keeping in mind that this is already deployed on extremely large Web sites, and in major Web browsers? > 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. The obligations and capabilities of proxies are reasonably well-defined in HTTP, and we're currently looking at making that better. Regards, -- Mark Nottingham https://www.mnot.net/