RE: SRI, cache validation and ServiceWorkers

I would argue that most security/privacy risks occur by the nature of what users do on the internet, i.e. the site (or referenced sites) that users visit, and not how they got there (apart from access via non-secure WiFi networks…). Even well-meaning sites can be susceptible to threats (e.g. Heartbleed). Once you’ve safely driven your Hummer to the wrong side of town, you can still be in danger when you arrive.

Connection security can be very helpful, but is not a silver bullet.

From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Monday, May 19, 2014 4:56 PM
To: Alex Russell; Daniel Appelquist
Cc: public-webappsec@w3.org; www-tag; Jake Archibald
Subject: Re: SRI, cache validation and ServiceWorkers

I have long argued that privacy and security issues are the biggest threats to the Web.
Yes, https and other forms of encryption do increase server load but as an enterprise
would you choose to save a few bucks and expose your users to identity theft and other
forms of malice?  Ask Target!
Best, Ashok

On 5/19/2014 7:11 PM, Alex Russell wrote:
Replying here because my previous response didn't cc the TAG. Apologies for thread-splitting.

On Mon, May 19, 2014 at 3:46 AM, Daniel Appelquist <Daniel.Appelquist@telefonica.com<mailto:Daniel.Appelquist@telefonica.com>> wrote:
Yoav Weiss <yoav@yoav.ws<mailto:yoav@yoav.ws>> wrote:
> Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
> > And sites that use service workers ought to be using HTTPS anyway.
>
> Why?

+1.

I have a concern about this orthodoxy of always putting service worker
apps under TLS.  Since the STRINT workshop, and also in light of the
coming move to http/2, I¹ve been talking to a lot of web developers about
moving to https.  I¹ve heard a lot of concerns with this, even from large,
established web sites.  Developers¹ concerns generally fall into the
following categories:

1. TLS itself is a pain to administer - the logistics of the certificates,
installing them, making sure they remain valid, ensuring they cover all
the needed domains, keeping up to date with best practice, etc...

In the post-Snowden world this is the new normal. We are tool-building animals. We should build some better tools.

2. https sites require beefier hardware to serve

This is sanke-oil.

3. https sites are more difficult to load balance

SNI helps here: http://en.wikipedia.org/wiki/Server_Name_Indication


4. serving over https makes it much more difficult to use third party
content (scripts, images, videos, ad networks, whatever) in your webapp

Now you get to choose: work with reputable services that work over TLS or don't persist your thing offline. I'm comfortable with giving developers that choice. In a world where the TAG is concerned enough about pervasive monitor (which we have spent many hours on at F2F meetings), this seems like the least painful way to help encourage the transition. It's not removing old functionality, it's providing a carrot (which also simplifies deployment vs the design alternatives) for a new feature.

A head of advertising for a major UK web site told me ³moving to https
means we will lose money.²

Then I recommend they continue to serve over HTTP and not attempt to persist offline.

I¹m not saying these concerns aren¹t addressable in the long term, but I
wonder, specifically looking at service worker, and considering that
adopting service worker will already mean a big learning curve for web
developers, whether enforcing TLS-only for this burgeoning technology is
the right approach.

Yes, yes it is.

In this light, I think Yoav¹s proposal deserves some additional
consideration.

Alex, Jake - would be good to hear your opinions on this.

Dan

Apologies for the wordy disclaimer below which is stripped in by my
employer:

This electronic message contains information from Telefonica UK or Telefonica Europe which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email. Switchboard: +44 (0)113 272 2000<tel:%2B44%20%280%29113%20272%202000> Email: feedback@o2.com<mailto:feedback@o2.com> Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85 Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85 Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85