On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <adam@xxxxxxxxxxx> wrote:
On 9/15/17 1:24 PM, Paul Hoffman wrote:
Yes, please. The charter should say "HTTP/2 over TLS". There is no reason for current browsers adding this feature to add it using an obsolete protocol.
I think you're assuming a tighter coupling between layers than actually exists.
In particular -- since you're talking about browsers -- it would easy to implement the current draft entirely in content _javascript_. In doing so, it would be impossible for the implementation to prevent its use over HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs,
So, "the implementation" in your statement above--is that the _javascript_ or the browser?
there's no way for such an implementation to even tell what version of HTTP is in use, much less prevent certain queries from going out over unwanted ones.
So, I think you have a usage in mind that is not the usage model that the draft talks about and is not really clear in the charter--the use of this within a _javascript_ application to collect DNS responses without going through the browser/OS cache and DNS method. If that is a proposed use case, then I think there is a serious question of how the same origin policy applies here.
Assume for a second that the resource in question mimics the current DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme. If Facebook _javascript_ has a call for https://dns.fb.com/www.google.com?type=AAAA, will that be within same origin policy or not? If it is within same origin, where does the resulting data go? Just to the _javascript_ or into browser or system caches?
In addition to same origin questions, there are some privacy issues around this being used to signal external parties. Imagine a query like this:
I don't know of any cross-site cookie watcher that would catch that, but it might be needed.
This set of questions is pretty different from the ones you get with "function over different paths", because the locus of control moves from the mostly-trusted browser to the mostly not trusted downloaded application.
This all bears more on the specified solution than the charter, but I suspect that (after a reasonable back-and-forth in the ensuing working group), one reasonable outcome will be that the mechanism works over HTTPS in general, simply because it will be too much of an implementation burden to prevent it from doing so.
I'd rather not preclude the ability to have that discussion in the working group by foreclosing it in the charter language.
I agree that the working group has to tackle it if it is in scope. The question we're discussing now is whether that use case is in scope. If any potential solution must deal with that eventuality because they all *could* be done in _javascript_, like it or not, then the question is moot, but that's not personally clear to me yet.
regards,
Ted
/a