I think there are two ways to estimate the size of an opaque response.

1. Use Quota API and CacheStorage API. This is not related ServiceWorker.
 This is a problem of Quota API.

---------------------------
  function getCurrentUsage() {
    return new Promise(r => 
      navigator.webkitTemporaryStorage.queryUsageAndQuota(u => r(u)));
  }

  function getSizeInCacheStorage(url) {
    return caches.open('test')
      .then(cache =>
        cache.delete(url)
          .then(() => getCurrentUsage())
          .then(first_usage => 
            fetch(new Request(url, {mode: 'no-cors'}))
              .then(res => cache.put(url, res))
              .then(() => getCurrentUsage())
              .then(usage => usage - first_usage)));
  }

  // This outputs the actual body size + the CacheStorage metadata size.
  getSizeInCacheStorage('https://www.google.com/').then(r => console.log(r));
-----------------------------


2. Measure the time to load the opaque response from the CacheStorage again and
 again via ServiceWorker. I think it is possible by measuring the time when the
 error handler is executed.

service_worker.js-------------------------
  self.addEventListener('fetch', event =>
      event.respondWith(new Promise(resolve =>
        caches.match(event.request.url, {cacheName: 'test'})
          .then(res => {
            if (res)
              resolve(res);
            else
              fetch(event.request)
                .then(res => {
                  caches.open('test')
                    .then(cache => {
                        cache.put(event.request.url, res.clone());
                        resolve(res);
                      })
                });
          }))));
------------------------------------------
  function tryLoad(url) {
    return new Promise(r => {
      var startTime = performance.now();
      var img = document.createElement("img");
      img.addEventListener('error', () => {r(performance.now() - startTime)});
      img.src = url;
    });
  }

  tryLoad('https://www.google.com/')
    .then(r => {
        console.log('Network fetch: ' + r);
        return tryLoad('https://www.google.com/');
      })
    .then(r => console.log('Load from CacheStorage' + r));
------------------------------------------

Given the info leak in case 1 above, I'll label this severity-medium.

horo -- who is an appropriate owner for this?

jsbell@
Could you please handle this issue?

cc people from  Issue 548556 

+nethanel.gelernter@gmail.com

jsbell: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

There is a method more accurate than timing that only requires the existing CacheStorage API:

1) Add a fixed size tiny resource to a cache
2) Repeat until the cache is full (quota manager restricts the size)
3) Remove X resources
4) Add an opaque resource

If the opaque resource fails to add, it's larger than X * fixed size. Else it's less than or equal.

 Issue 548556  has some good (older) discussion. The "size buckets" idea for opaque responses seemed reasonable. Any issues with that?

Can we somehow apply the size bucket idea to comment #16?

I imagined we would snap the |fixed size| of comment #16 to some bucket. So from the POV of QuotaManager, an opaque response that's really size 21k bytes has size 50k bytes or whatever.

Binning is trivially defeated. In the case of the OP's attack, they could pad the response size to be near the byte boundary and then determine which bin the result falls in. 

I forgot to mention how they might pad the response size for the given attack.

E.g., add -"ADhjkrhwesrhwselrHWSLRHWERWEIURHWEIRHEW <insert as many characters as you need here>" to the query.

There's now a public issue about this https://github.com/whatwg/storage/issues/31

JFYI: A reporter of the public issue on c#22 filed an  issue 596927  before.

Most of the ideas that have been discussed (e.g. size bucketing) can be defeated by repeated attack, such idea would need to be combined with rate-limiting or some sort of repeated attack detection...

I've thrown together https://docs.google.com/document/d/1v9Ac09Ax7E20WkYTOrTTviftZEe5REWpc5vVRbyjjKw/edit# to document the attacks and possible solutions in one place. Am I missing anything?

jsbell: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+csharrison as he is working on a similar issue for Content Size Policy.

Update in https://github.com/whatwg/storage/issues/31 from the SW F2F - does the suggested consensus approach seem plausible?

michaeln@ pointed out something I missed. Notably, that cloned resource should keep their random pad. If that's the case, then the attack I suggested won't work. You'd have to perform many many network requests to perform the attack. I've deleted comments #37 and #38 just so people don't wind up wasting time on them.

I've played with timing attacks to determine their accuracy, since we want quota leaks to be no worse than that. On good networks it seems like you can easily distinguish down to ~4KB. I don't yet have data for bad networks, which will be fuzzier. 

What should we target? Fuzziness of good networks or bad or somewhere in the middle?

Experimental data: https://docs.google.com/document/d/1FQ9CzFhafWoEB1ksJ_K_x9ZQGsFs729x9ud0Z2otEyY/edit#

My vote would be to have CacheStorage be no less secure than a network timing request attack - so targeting a network with high latency variance right?

There's a discussion of the timing attacks at https://github.com/w3c/resource-timing/issues/64

The solution may involve an opt-in header, such as samesite cookies, or something to prevent cross-origin no-cors requests.

Okay, we'll hold off on implementing anything in CacheStorage while that's being worked out.

Friendly ping from Security Sheriff: cmumford@, jsbell@ would you mind giving an update on this?

Currently working on (probably 75% complete) on a fix to add a random pad and bin to opaque resources. Some preliminary cleanup CL's are landing now, and the first (of two) CL's to add the pad/bin should land this week.

Note: there is still an ongoing discussion as to the efficacy of this approach to address this security problem.

Some more detail on my previous note in #c47. The pad/bin solution is to calculate some random (and fairly large) pad to _add_ to the opaque resource size. We don't actually change the cached resource - we just _lie_ to the quota manager when we tell it the origin usage. Doing this isn't that simple, and adds a fair amount of code to cache storage - increasing code complexity, likelihood of bugs, and disk I/O. The discussion is whether this cost will actually meaningfully close this security hole. Before landing this change we really need somebody to analyze the padding size, and ascertain that it actually fixes this issue enough to be worth the cost.

 Issue 658946  has been merged into this issue.

Friendly ping from the security sheriff. Re: #48, is there someone who is making that decision?

cmumford: ping again :) What can we do to help make the decision about #48? 

+Artur due to interest in the similar content-size policy discussion.

I'm not comfortable with the binning + padding. Binning doesn't add any security if you can adjust the response size. Padding is mostly useless if the distribution of random numbers is known as you can figure out where in the distribution you are with a few requests. 

@jkarlin sorry if I'm missing something obvious, but aren't those two concerns already considered and taken care of?

I might be out of date here, but the attacks you mentioned were discussed several months ago already? (you commented on the doc) https://docs.google.com/document/d/1qKYdjapL0cEdtK-xceuIALL0xol4KNfYDnvjX8JmC1I/edit

This is a complex issue, and the document isn't nearly specific enough to consider this "taken care of." What are the constants? How does a skewed distribution actually help? What are the random ranges?

And most importantly, what are we comparing against? How do you define what could be observed via network timing? That entirely depends on the given network. Reliable and fast networks can be very precise. Crappy networks (seconds of latency, lots of dropped packets) are so bad that you can't infer anything. 

I've prototyped a few padding/binning prototypes and when I run them against a simple attack, the attack is usually quite accurate with 10-100 samples. Let's put together a prototype that we can't trivially crack.

Will respond more in the doc.

OK, I understand the misunderstanding.

I thought your update was meant to imply binning/padding were flawed in principle (since the language sounds very assertive). I agree we haven't figured out the details, and there's a lot of work to be done in the binning/padding direction.

If you won't go out on vacation, I would be happy to sync this week to chat about it.

Great. I'll setup a meeting.

evn, cmumford, and I spoke a bit about existing attacks, namely network timing. I put together a demo website and a document to show what network timing attacks can do. It appears that network timing has a median accuracy of ~10KB and a 90th percentile accuracy of ~40KB.

Of course the numbers can get worse on really bad networks, but these network samples seem like a reasonable starting point.

Demo site: https://cr.kungfoo.net/jkarlin/timing/
Doc: https://docs.google.com/document/d/1FQ9CzFhafWoEB1ksJ_K_x9ZQGsFs729x9ud0Z2otEyY/edit#

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8

commit ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8
Author: cmumford <cmumford@chromium.org>
Date: Thu Dec 22 15:26:50 2016

Write out CacheStorageCache size to index file.

Persisting the size allows CacheStorage and CacheStorageManager to avoid
using simple cache to unnecessarily calculate the cache size if it is
already known.

BUG= 617963 

Review-Url: https://codereview.chromium.org/2416713002
Cr-Commit-Position: refs/heads/master@{#440425}

[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/BUILD.gn
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/README.md
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_cache.h
[add] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_dispatcher_host.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_dispatcher_host.h
[add] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_index.cc
[add] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_index.h
[add] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_manager.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_manager.h
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/browser/cache_storage/cache_storage_manager_unittest.cc
[modify] https://crrev.com/ffb8a161dcd0ff73a7fff6111a2d6f383c39dec8/content/test/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c7f20d3d858eb3381c003970a2d9179c2437a47

commit 1c7f20d3d858eb3381c003970a2d9179c2437a47
Author: mostynb <mostynb@opera.com>
Date: Mon Jan 09 13:16:38 2017

avoid GCC content::CacheStorage::kSizeUnknown redeclaration error

Fixes:
../../content/browser/cache_storage/cache_storage.cc:62:29: error: redeclaration 'content::CacheStorage::kSizeUnknown' differs in 'constexpr'

BUG= 617963 

Review-Url: https://codereview.chromium.org/2607983002
Cr-Commit-Position: refs/heads/master@{#442242}

[modify] https://crrev.com/1c7f20d3d858eb3381c003970a2d9179c2437a47/content/browser/cache_storage/cache_storage.cc

Any more changes expected on this bug, or can we mark it as fixed?

No, there is one more change in progress that should hopefully be up for review within the next few days. The first CL (#440425) was change 1 of 2.

We've hit a bit of a snag. The original proposal was to add padding to Response objects and their clones. The idea was to force the user to go to network if they want another sample. But the reality is they'll often hit the HTTP cache instead of the network, which isn't much of a deterrent from retrying as many times as necessary.

We could...
1) store the padding in the http cache as metadata (this is non-trivial and has performance costs)
2) bypass the cache for no-cors fetches

Other ideas?

@jkarlin - I thought the plan was for the padding to be stored together with the response, isn't that the case?

It's stored in CacheStorage with the response. But this is about the http cache.

Wouldn't options F and G from https://docs.google.com/document/d/1qKYdjapL0cEdtK-xceuIALL0xol4KNfYDnvjX8JmC1I/edit address that concern?

Intentionally slowing fetch() requests? That sounds like a non-starter given that we're trying to encourage sites to load via service workers and fetch and every ms counts.

I assume we don't ask sites to make tens of thousands of requests, and expect the next 10k requests go as fast.

Note this isn't an issue we can afford to just ignore.

Also, note that we could do this just for no-cors requests, if necessary. Which should limit the issues with most sites caching their own resources/app.

Thinking about the throttling: Do we need to throttle the fetch(), or just the cache put?

Even then, it's only cache puts for opaque responses, and only if many are done in a short space of time.

Just the cache put I suppose. Currently Cache runs operations sequentially, so if you throttle one then subsequent operations (potentially not no-cors) are throttled as well. That is, unless we're willing to run the operations out of order.

Does .put() know if the response came from the cache? If so, then perhaps we could generate the random padding out of some cache key/checksum?

It knows if the response came from the CacheStorage cache, but it does not know that it came from the network cache.

Friendly ping from the security sheriff. jkarlin, cmumford, do we have a plan here?

Mostly. I've put together a couple of docs:

1) How to choose the proper padding distribution to defend against N samples with F fuzziness. Early next week the plan is to nail down values for N and F. https://docs.google.com/document/d/19dJzDB61YAQ0pW2K9chd-g8BMEAhvSE7S5k71mTWDkE/edit#heading=h.rapabzqpbuez

2) How to specifically address the CacheStorage leak with the above.
https://docs.google.com/document/d/1LPUZwV0CtYBtFNGcceGX8VzJmLUf8NY1qWfJjCAjXks/edit

cmumford@ is reviewing them now and once we're happy with them (hopefully end of next week?) we'll need some security folks to look them over.

Friendly security sheriff ping - did we go ahead with the implementation here?

Yes, progress is being made. One CL (https://codereview.chromium.org/2662643002) up for review, but a flaw was detected so back to the drawing board. I have a second CL under review now (https://codereview.chromium.org/2901083002) with outstanding comments that I hope to have addressed today (or maybe next working day).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8421200aab24ddf59dfea7256ccffed8f7a61e0b

commit 8421200aab24ddf59dfea7256ccffed8f7a61e0b
Author: cmumford <cmumford@chromium.org>
Date: Tue Aug 15 15:29:30 2017

[CacheStorage] Pad and bin opaque resource sizes.

BUG= 617963 

Review-Url: https://codereview.chromium.org/2901083002
Cr-Commit-Position: refs/heads/master@{#494384}

[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/README.md
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_cache.h
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_index.cc
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_index.h
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/8421200aab24ddf59dfea7256ccffed8f7a61e0b/content/browser/cache_storage/cache_storage_manager_unittest.cc

Woot! Nice job Chris. Now all that's left is to tune the padding after we've determined appropriate values. But at least for now we have some protection.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ec1aed3b32089faaff776d4bfce69ea5f588314

commit 0ec1aed3b32089faaff776d4bfce69ea5f588314
Author: reillyg <reillyg@chromium.org>
Date: Tue Aug 15 17:33:32 2017

Revert of [CacheStorage] Pad and bin opaque resource sizes. (patchset #11 id:200001 of https://codereview.chromium.org/2901083002/ )

Reason for revert:
Crashes in these virtual test suites:

* virtual/mojo-blobs/external/wpt/service-workers/service-worker/fetch-canvas-tainting-cache.https.html
* virtual/off-main-thread-fetch/external/wpt/service-workers/service-worker/fetch-canvas-tainting-cache.https.html

https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/3992

Original issue's description:
> [CacheStorage] Pad and bin opaque resource sizes.
>
> BUG= 617963 
>
> Review-Url: https://codereview.chromium.org/2901083002
> Cr-Commit-Position: refs/heads/master@{#494384}
> Committed: https://chromium.googlesource.com/chromium/src/+/8421200aab24ddf59dfea7256ccffed8f7a61e0b

TBR=jkarlin@chromium.org,cmumford@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 617963 

Review-Url: https://codereview.chromium.org/3002693002
Cr-Commit-Position: refs/heads/master@{#494428}

[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/README.md
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_cache.h
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_index.cc
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_index.h
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/0ec1aed3b32089faaff776d4bfce69ea5f588314/content/browser/cache_storage/cache_storage_manager_unittest.cc

Fixed CL back up for review: https://chromium-review.googlesource.com/c/617241

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b

commit cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b
Author: Chris Mumford <cmumford@chromium.org>
Date: Thu Aug 17 18:15:40 2017

[CacheStorage] Reland: Pad opaque resource sizes.

This change adds random padding to opaque resources stored in CacheStorage.
The intent of this change is to obscure the size of these resources to avoid
"leaking" their actual size.

This is a re-land of 8421200aab which contained an incorrect DCHECK causing
some layout tests to fail.

BUG= 617963 

Change-Id: Ia4bccb6dec1b0c1c6145c2fd996cd9dfb36dea83
Reviewed-on: https://chromium-review.googlesource.com/617241
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Chris Mumford <cmumford@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495227}
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/README.md
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_cache.h
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_index.cc
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_index.h
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b/content/browser/cache_storage/cache_storage_manager_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea4578231b755d1bf044260748b3f0e24763b4cb

commit ea4578231b755d1bf044260748b3f0e24763b4cb
Author: Chris Mumford <cmumford@chromium.org>
Date: Fri Aug 18 23:10:40 2017

Revert "[CacheStorage] Reland: Pad opaque resource sizes."

This reverts commit cae7bbbf50c2e33926a0d0a6a3c2e36d3777ba5b.

Reason for revert: Causing crash - see issue 756821

Original change's description:
> [CacheStorage] Reland: Pad opaque resource sizes.
> 
> This change adds random padding to opaque resources stored in CacheStorage.
> The intent of this change is to obscure the size of these resources to avoid
> "leaking" their actual size.
> 
> This is a re-land of 8421200aab which contained an incorrect DCHECK causing
> some layout tests to fail.
> 
> BUG= 617963 
> 
> Change-Id: Ia4bccb6dec1b0c1c6145c2fd996cd9dfb36dea83
> Reviewed-on: https://chromium-review.googlesource.com/617241
> Reviewed-by: Josh Karlin <jkarlin@chromium.org>
> Commit-Queue: Chris Mumford <cmumford@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#495227}

TBR=cmumford@chromium.org,jkarlin@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  617963 
Change-Id: I20c00c52a115cf871cfcefdcbd4de9448769bd4a
Reviewed-on: https://chromium-review.googlesource.com/622027
Reviewed-by: Chris Mumford <cmumford@chromium.org>
Commit-Queue: Chris Mumford <cmumford@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495731}
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/README.md
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_cache.h
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_index.cc
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_index.h
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/ea4578231b755d1bf044260748b3f0e24763b4cb/content/browser/cache_storage/cache_storage_manager_unittest.cc

Note that I've improved the "just how accurate is network timing" doc, so that we have something to target. I made a better estimator, and now it gets to within 3KB 95% of the time on my laptop at home wifi and desktop at work. My 3 out of 4 bar LTE gets within 5.45KB 95% of the time.

So I'm suggesting, to be safe, that we go with 10KB as the target error. Though 5KB might be perfectly reasonable too.

https://docs.google.com/document/d/1FQ9CzFhafWoEB1ksJ_K_x9ZQGsFs729x9ud0Z2otEyY/edit#

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/46069c80325f8000a7538adc68c0e7b3dd585288

commit 46069c80325f8000a7538adc68c0e7b3dd585288
Author: Chris Mumford <cmumford@chromium.org>
Date: Tue Sep 12 00:35:22 2017

[CacheStorage] Reland (#2): Pad opaque resource sizes.

This change adds random padding to opaque resources stored in CacheStorage.
The intent of this change is to obscure the size of these resources to avoid
"leaking" their actual size.

BUG= 617963 

Change-Id: I2ad94d799a456bf646a18e54a0a9d7151cf2821e
Reviewed-on: https://chromium-review.googlesource.com/638793
Commit-Queue: Chris Mumford <cmumford@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501121}
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/README.md
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage.cc
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage.h
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage.proto
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_cache.cc
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_cache.h
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_cache_observer.h
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_cache_unittest.cc
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_index.cc
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_index.h
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_index_unittest.cc
[modify] https://crrev.com/46069c80325f8000a7538adc68c0e7b3dd585288/content/browser/cache_storage/cache_storage_manager_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e89c48a3666bc7f9bd130c9da14c7f0ca9db5168

commit e89c48a3666bc7f9bd130c9da14c7f0ca9db5168
Author: Josh Karlin <jkarlin@chromium.org>
Date: Tue Sep 12 15:37:33 2017

[CacheStorageCache] Increase padding size

Bug:  617963 
Change-Id: I5c9dcd156dfb9a6cb1b950be1f7f1d1bf77380fb
Reviewed-on: https://chromium-review.googlesource.com/663398
Reviewed-by: Chris Mumford <cmumford@chromium.org>
Commit-Queue: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501287}
[modify] https://crrev.com/e89c48a3666bc7f9bd130c9da14c7f0ca9db5168/content/browser/cache_storage/cache_storage_cache.cc

friendly ping from the security sheriff. any updates here?

Should be resolved as fixed, right cmumford@ ?

cmumford@, could you please check comments c#97 and c#98?

It's fixed.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot