On Wed, Nov 12, 2014 at 11:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Nov 12, 2014 at 8:22 PM, Brad Hill <hillbrad@fb.com> wrote: > > There is work going on in the OAuth WG on authenticating HTTP requests: > > > > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00 > > > > Have you looked at this to see if it is suitable for your use case? > > That is not going to work for him. He needs something that sidelines > mixed content protection in browsers. That way Netflix can keep > pretending TLS is not required by using it for the top-level browsing > context while fetching all data without TLS. > Anne, I can see that from the point of view of the browser, TLS brings many benefits to users across all sites that use it. But from the point of view of a single site operator, the calculus is different. For example, we know very well the extent to which we track our users (by login and devices) and the extent to which we share user information with third parties (not at all, as far as I know). The browser doesn't know these things and so you have the Same Origin Policy, which is obviously stronger if you authenticate the identity of the origin. We also have a range of techniques at our disposal of which the browser is unaware. We think the security a privacy properties of our service are quite reasonable today, but nevertheless we're evaluating what the costs and benefits of moving to TLS would be. That evaluation will be different from browser implementors' because of what we know about our own service - things you can't assume in general - and the particularities of the content delivery workload. As part of that analysis it would be remiss not to consider other options which could give our users, and those of other video content distributors, some or most of the benefit for a fraction of the cost and thus sooner. That's what this thread is about. ...Mark > > > -- > https://annevankesteren.nl/ >
Received on Wednesday, 12 November 2014 21:40:02 UTC