Re: [ServiceWorker] Should window.caches be removed (or readonly) for security reasons? (#698)

> Is there any difference between trusted-only and caches.match(url).then(r => r.url == url ? r : null)?

I believe there is no difference. Just brevity.

> If you make the cache API more difficult to use, developers will move to another storage system such as idb, which can be accessed between page & worker. Eg, the original cache polyfill was idb based.

I agree.

> Browser storage is accessible in both pages and workers. We need a really good reason to make an exception here, and I don't think we have one.

I agree, but I still have a bad feeling about the combination of service worker capabilities and a global caches API.

I think it would make sense to consider an API to "protect" caches. Let's call it a security feature, while at the same time not limiting ease of use for more advanced use cases. 

Another idea (besides `trusted-only`) would be to mark specific caches as "limited to service workers" during the cache creation.

```javascript
// In Serviceworker
self.addEventListener('install', function(event) {
  caches.open('secure-cache-name', {sw-only: true}).then(function() {
    // do something
  });
});

// In Page
caches.open('secure-cache-name'); // throws an Error
```

This is definitely a bigger change compared to `trusted-only`. As it is not possible to control whether the cache was created from a page before (without the `sw-only` option set), the `sw-only` option would need to be set to true even if the cache already exists. (I guess setting it to false should not work). It feels a bit awkward.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/698#issuecomment-105082708

Received on Monday, 25 May 2015 00:54:42 UTC