On Thu, Apr 8, 2010 at 1:09 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wed, Apr 7, 2010 at 4:54 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Thu, Apr 8, 2010 at 12:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> On Wed, Apr 7, 2010 at 4:29 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
>> >> > In regards to data expiration, part of ensuring the security of data<br>
>> >> > is<br>
>> >> > knowing how long it will be stored on disk. If I let someone borrow<br>
>> >> > my<br>
>> >> > computer to check their email, and the email client happens to save<br>
>> >> > some<br>
>> >> > data onto the client, then that person’s data will now be on my disk<br>
>> >> > for<br>
>> >> > who<br>
>> >> > knows how long. That represents a data security issue. By allowing an<br>
>> >> > expiration date to be tied to the data, you can have reasonable<br>
>> >> > assurance<br>
>> >> > that the data isn’t just going to be sitting around waiting for<br>
>> >> > someone<br>
>> >> > to<br>
>> >> > try and use it.<br>
>> >> ><br>
>> >><br>
>> >> It is true that not having control over your data could be an issue,<br>
>> >> but<br>
>> >> simply<br>
>> >> embedding expiry into the data may not buy you much to protect it.<br>
>> >> Insofar<br>
>> >> as the crypto wouldn't be running in a TPM, it would be easy to reverse<br>
>> >> engineer<br>
>> >> it and extract the data; it would also be fairly easy to reset the<br>
>> >> clock on the device<br>
>> >> to keep data from being deleted.<br>
>> ><br>
>> > One thing that might be interesting is a way to cache large amounts of<br>
>> > data<br>
>> > that are deleted when the browser and/or tab closes. This might be<br>
>> > something for the new file system API to consider (hence adding ericu to<br>
>> > the<br>
>> > thread). But time based controls aren't going to do anything more than<br>
>> > give<br>
>> > perceived security. (In your use case, expiration doesn't add much<br>
>> > actual<br>
>> > security for the reasons Dirk mentioned.)<br>
>><br>
>> I disagree. Having data time out is a good "additional layer" of<br>
>> security. For example if your laptop gets stolen, then it's much<br>
>> better if the thief only gets access to the sites you've used the last<br>
>> 24h, than any site you've ever used.<br>
>><br>
>> This is why people do things like enforce password changes every X<br>
>> weeks. Yes, password changing has social downsides, like people<br>
>> writing down passwords on post-its etc. However those problems do not<br>
>> seem to apply here.<br>
>><br>
>> So I don't think anyone is arguing that expiration is good security in<br>
>> and of itself. But it is a good (and low cost) way of getting<br>
>> additional security.<br>
><br>
> Sure, but it should not be thought of as anything more than a hint. If I go<br>
> to a site that says expire the data in 24 hours and then I turn it off and<br>
> don't use it for a year, that data is still there.<br>
<br>
</div></div>This is true, and important.<br>
<div class="im"><br>
> Anything that has the outward appearance of adding more security than it<br>
> actually does worries me. (I'm obviously worried a lot. :-)<br>
<br>
</div>I think it's pretty obvious though that expiring the data X seconds in<br>
the future doesn't in and of itself give any protection what so ever<br>
until the data has actually been expired.<br>
<br>
I guess it could be argued that it isn't obvious that the data is only<br>
expired if the browser is running.</blockquote><div><br></div><div>It's possible UAs can be a bit more smart about this as well. For example, many OSs have a way to schedule things to run in the future. (And could have a helper program that does the deleting.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I don't think this is enough of a<br>
problem to kill the feature though.<br></blockquote><div><br></div><div>I think this is a good feature to try and integrate into existing APIs if it's possible to do so cleanly. I don't think it's worth creating yet another persistent storage API over, though.</div>
<div><br></div><div>It seems as though expiration policies could be added to the creation of databases and the new FileWriter/FileSystem APIs pretty easily. For localStorage, we could add a origin-wide setting or add an optional param to setItem.</div>
<div><br></div><div>But still....we need some use cases. :-)</div></div>