On Sun, Sep 2, 2018 at 10:52 PM Kenji Baheux <kenjibaheux@chromium.org>
wrote:
> Is the assumption that Servers / Server operators, unless vertically
> integrated (e.g. FB and other big players), will probably get it wrong
> because they lack the application knowledge to dissociate public vs.
> private sources?
>
> One option that was discussed in a side chat at IETF 101 was to expose
> this to JS (Fetch / Streams / ...) where the knowledge about public vs.
> private exists. But that implies a different, and most likely harder,
> adoption story.
>
I don't think JS provides a resolution for those issues - rather, it allows
for experimentation without needing to fundamentally introduce those to all
layers of the stack. This is already true of what servers are doing today -
e.g. the incremental delivery of updated assets through the combination of
Service Workers/LocalStorage + differential encoding schemes for static
resources.
The problem is when you try to generically apply this to all resources, at
a protocol layer (HTTP), because now you're fully detached from the
application semantics involved in having a single HTTP resource combining
these types of data, which seems to be an argument for use cases made by a
number of these proposals.
> The scale benefits of Servers / Server Operator is definitely appealing.
> So, I'm wondering if we have exhausted all the reasonable options. Is there
> nothing that would at least cover a significant subset of the use cases?
>
> Some naive questions / thoughts:
>
> - Would it still be valuable to enable shared dictionary compression
> by Servers for responses that are completely free of private data?
>
> No, I don't think there's a reasonable solution that somehow involves
multiple HTTP clients agreeing on what constitutes a 'safe' server of only
public data, nor do I think the goals and incentive structures are aligned
for a declarative expression.
>
> - Can a Server / Server operator infer that response isn't tainted by
> private sources, i.e. only contains "public" data? From the absence of
> specific (existing) headers?
> - If not, what if Servers had to assume "mixed" unless the response
> was augmented with a new(?) header. I imagine that a server configuration
> scheme / header would be simpler in terms of adoption than requiring web
> developers to do all the work in JS land.
>
> I think this potentially misinterprets the set of concerns raised. I think
the optimization for servers is misaligned with the security needs. Servers
will necessarily prefer to do the 'faster' things, and the incentives for
security are seen as costs/complexity, yet the benefits aren't realized by
the servers, but the users and clients accessing those resources.