The content of the session storage gets stored on the hard drive
Reported by
pagnon.f...@gmail.com,
Aug 3 2016
|
|||||||
Issue description
Chrome Version : 52.0.2743.116 (Build officiel) m (32 bits)
URLs (if applicable) : Any
Other browsers tested:
Firefox (48.0): OK.
IE (11.0.9600.18097): OK.
What steps will reproduce the problem?
(1) Visit any website.
(2) Open the developer console.
(3) Create a new entry into the session storage : sessionStorage.setItem('test', 'myvalue');
(4) Close the browser and go to following directory : C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\Session Storage
(5) Open the file with the extension *.log.
What is the expected result?
I would expected the content of the session storage to be stored in memory.
What happens instead?
The file contains all the data contained in the session storage in clear text as opposed to the local storage which uses the built-in Windows encryption API.
I've double checked and this is not due to the developer console.
Is there a reason why the data from the session storage would be stored locally ?
Regards.
,
Aug 4 2016
,
Aug 4 2016
,
Aug 5 2016
@pagnon.francois: Could you please have a look at the attached video and let us know if this is the correct procedure to repro this issue. Else, provide us the screen-recording for better understanding. Thank you.
,
Aug 5 2016
That's it. That's how I've done it.
,
Aug 5 2016
@pagnon.francois: Could you please explain in detail about the expected result and where exactly are you intending it to store the memory? Thank you.
,
Aug 5 2016
My understanding of the session storage is that its content is valid for the current session until you close the tab or browser. This works fine. Now I've noticed that the content of the local storage is encrypted which is not the case of the session storage as I would expect. Therefore, I would expect the content of the session storage to be stored in the process memory unless there is some requirements to store it on the hard drive (eg. recovery after a crash).
,
Aug 5 2016
,
Aug 5 2016
Doesn't appear to have anything to do with devtools. It seems the reporter just has questions about the implementation of session storage in Chrome. Session storage is currently persisted via leveldb. Local storage is persisted in sqlite (but we'll likely change that soon). Note that local storage is *not* encrypted, contrary to the claims by the bug. Re-tagging as a feature; I'm not sure why we do persist session storage to disk but presumably there's a good reason. michaeln@ ?
,
Aug 10 2016
I think this is "not a bug", just some questions, is that right? Marking as wont fix on that basis. SessionStorage is put on disk to support things like "session restore" or the "continue where you left off" startup setting, or restarting to complete an upgrade, or restoring tabs after a crash. That, and on a device like a phone, when exactly does the browsing session start and stop from a users perspective? In our view, its more or less one long never ending session. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ligim...@chromium.org
, Aug 4 2016Labels: Needs-Bisect M-52