Re: Proposal: Prefer secure origins for powerful new web platform features

On Thu, Aug 21, 2014 at 2:11 PM, Chris Palmer <> wrote:

> On Thu, Aug 21, 2014 at 1:27 PM, Mark Watson <> wrote:
> > I'd take (took) issue with WebCrypto. I know it requires a secure origin
> in
> > Chrome but this is not required by the specification.
> It is required by common sense, however. It is not possible to provide
> users meaningful security with anonymous, MITM-mangled WebCrypto.

​I don't believe anyone's argued that. It is, however, possible to provide
useful security properties using WebCrypto with an insecure origin as we
have explained ad nauseum in the WebCrypto group. Those properties are
probably far weaker than interest you and perhaps more interesting to the
service provider than the user, but nevertheless.​

> > Switching to HTTPS it not necessarily that cheap or inconsequential to
> user
> > experience. If it were, of course I'd agree. Sounds like we don't have a
> > clear understanding of what developers are being asked to do.
> I only know about Google, but we are using HTTPS (preferring PFS, no
> less) in tier-1, throughput- and (especially) latency-sensitive
> products like Search and Gmail. Where possible and in general, we seek
> to improve performance by developing things like SPDY and QUIC, and
> deploying spiffy new ciphersuites, rather than by turning off the
> minimum level of safety.
> I understand that your deployment scenario is different — large,
> static blobs that benefit from edge-cacheing, rather than
> highly-dynamic content like Search and Gmail. If your CDNs try to
> gouge you when you ask them for HTTPS, that's a business matter and of
> course above my pay-grade. But I have a hard time seeing a technical
> problem. Sharing your experience might be informative for everyone on
> the mailing list.

​We're working on getting some data. I hope you would agree that making a
decision in the absence of clear understanding and actual data would be a
bad idea.


Received on Thursday, 21 August 2014 21:33:14 UTC