Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov a...@webkit.org wrote: 14.07.2011, в 13:59, Tab Atkins Jr. написал(а): re-using the enclosure term from the Atom format (thus minimal bikeshedding) enclosure is a completely opaque name. I have no idea how it is meant to refer to download the linked resource instead of navigating to it. If I think about it in terms of Atom I can *kinda* imagine it, but it feels like a bad term there, and it would be an even worse term in HTML. A boolean @download attribute is much clearer and more direct. If you're using @download to name the file as well, then adding a @rel value is unneeded. What meaning will this attribute have on a platform that simply doesn't expose the notion of a file? I would assume the platform would treat a href=blah.php?id=123 download=blah.pdf the same way as if it had followed a link to blah.php and received a Content-Disposition: attachment; filename=blah.pdf header. It's not introducing any new problems, and I would expect the behaviour to be consistent. I think that this attribute could be quite confusing, and it will likely become more confusing with time, as more platforms arise that have creative ways of presenting data to users. I agree we don't want to prevent creative UI in the future / platforms that don't necessarily deal with files in the traditional way. However I don't think this actually introduces any new problems, it just allows something that can already be specified in server-side code to be specified in client-side code. It also doesn't naturally help understanding that it's just poor man's Content-Disposition:attachment. From this point of view, I like Ian's original proposal (rel=attachment) more. Yes and no - both are sort of a poor man's Content-Disposition :) The question is whether we need to handle filename, and the proposal of download=filename at least maps content-disposition fully and compactly. - WBR, Alexey Proskuryakov
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard gl...@zewt.org wrote: 2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com Yes and no - both are sort of a poor man's Content-Disposition :) The question is whether we need to handle filename, and the proposal of download=filename at least maps content-disposition fully and compactly. Not fully; it lacks an equivalent for Content-Disposition: inline; filename=file. Ok, not fully, but at least covering what I would view to be the important use cases that are actually used in practice. -- Glenn Maynard
Re: [whatwg] a rel=attachment
2011/7/15 Jonas Sicking jo...@sicking.cc 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. We've discussed a different solution to the same problem at mozilla. The solution we discussed was allowing FileSaver to in addition to taking a blob argument, allow it to take a url argument. One concern which was brought up was the ability to cause the user to download a file from a third party site. I.e. this would allow evil.com to trick the user into downloading an email from the users webmail, or download a page from their bank which contains all their banking information. It might be easier to then trick the user into re-uploading the saved file to evil.com since from a user's perspective, it looked like the file came from evil.com Another possible attack goes something like: 1. evil.com tricks the user into downloading sensitive data from bank.com 2. evil.com then asks the user to download a html from evil.com and open the newly downloaded file 3. the html file contains script which reads the contents from the file downloaded from bank.com and sends it back to evil.com Step 1 and 2 require the user to answer yes to a dialog displayed by the browser. However it's well known that users very often hit whichever button they suspect will make the dialog go away, rather than actually read the contents of the dialog. Step 3 again requires the user to answer yes to a dialog displayed by the browser in at least some browsers. Same caveat applies though. One very simple remedy to this would be to require CORS opt-in for cross-site downloads. For same-site downloads no special opt-in would be required of course. It's also possible that it would be ok to do this without any opt-ins since there are a good number of actions that the user has to take in all these scenarios. Definitely something that I'd be ok with discussing with our security team. Tentatively I would feel safer with the CORS option though. And again, for same-site downloads this isn't a problem at all, but I suspect that in many cases the file to be downloaded is hosted on a separate server. Oh, and I don't have strong opinions at this time on if rel=attachment or FileSaver or both should be the way to trigger this functionality. / Jonas I agree FileSaver is useful and has its place, but I don't think it negates the need for something like rel=attachment or download=filename. For one, FileSaver currently operates on blobs and as you mention would have to be modified to handle URLs or streams more generally. Second, it would force developers to use javascript links and/or set up click listeners and so forth, which could be annoying for users (losing the ability to copy the URL etc). I don't understand why we would add CORS as a requirement for this. You can already link to things from another origin, the fact that they may be downloaded rather than displayed and then the user somehow tricked to upload them seems like a rather remote concern... if I now want to link to a StarCraft 2 patch and give the browser a hint that it's a download (so that maybe in the future the browser might be able to have more intelligent UI when I hover over it, or at least not pop up a new window that just then spawns a download) requiring CORS seems quite overkill, especially if the response would have triggered a download anyways. I guess the interesting question is If the response would not have otherwise triggered a download, and the request is cross-origin, should that require CORS and personally I would say no, this is still a remote enough concern that I would not worry about it. -Ian
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke julian.resc...@gmx.dewrote: On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote: .. It also doesn't naturally help understanding that it's just poor man's Content-Disposition:**attachment. From this point of view, I like Ian's original proposal (rel=attachment) more. Yes and no - both are sort of a poor man's Content-Disposition :) The question is whether we need to handle filename, and the proposal of download=filename at least maps content-disposition fully and compactly. ... Well, one difference is that C-D is under the control of the owner of the resource being linked to (ideally), while attributes set somewhere else might not. So there is a security-related aspect to this. Best regards, Julian So, in the interest of making progress, what if we tried... download=filename for same origin it's always downloaded (includes filesystem api from that origin) for cross-origin it's downloaded if we get a positive CORS response and/or we get a content-disposition attachment for cross-origin if we don't get positive CORS response OR content-disposition:attachment we don't download We can always start conservative and broaden out. -Ian
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/15 Jonas Sicking jo...@sicking.cc It definitely is an interesting usecase that Glenn brought up about being able to specify a save-as name without otherwise modifying the behavior of a reference. However that seems like a much more rare usecase and so not the one we should optimize for. Bear in mind that optimize for doesn't mean support at all; if download=filename is used, it seems unlikely that there will ever be *any* client-side way to supply the filename without implying attachment, which is a very different thing than not optimizing for it. I don't feel strongly enough about this to press it further, but a href=ugly download filename=pretty also seems fairly clean, and avoids combining parameters that really are orthogonal to one another. I really don't see the importance of the name the thing that isn't going to be downloaded usecase; there are countless edge cases that we could concern ourselves with in HTML but that few users will ever hit, this is one. (I also suspect a user sophisticated enough to actually save something, e.g. right click save as, is sophisticated enough to be able to type their own filename.)I think it's better overall to keep the semantics as clean and simple as possible. I suggest we move forward with a href=blah download=filename with the origin considerations mentioned in the previous email and move on. -- Glenn Maynard
[whatwg] a rel=attachment
Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. -Ian
Re: [whatwg] a rel=attachment
On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost ka...@opera.com wrote: Le 14 juil. 2011 à 14:45, Ian Fette (イアンフェッティ) a écrit : Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Which current websites? Take gmail as one example off the top of my head. If any of these files are present as an attachment I get an option to view or download. it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. Are you then proposing to reverse the contextual click on the link to give the option, view in the browser. All browsers have currently implemented save this link as? It may please some users. As a user, I will place this in the category of super annoying features. It then means I would need a preference in the browser to disable it. Then it is at least 3 modifications to implement it. Not for all links, no, only links that have rel=attachment. And I would assume that on such a link, yes, perhaps a view inline right click option may make sense. I wouldn't expect this to be used on anywhere near a majority of links, but an author can already try to craft a download link -- it's just that in many cases it's either requiring them to jump through hoops or impossible (e.g. offline apps). -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] a rel=attachment
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. -Ian I should also point out that there was a similar proposal from Dennis Joachimsthaler last year. There was a fair amount of discussion on the thread back and forth; near the end Hixie's recommendation [1] was to propose this as a rel= attribute and push forward with implementation. That is essentially what we intend to do. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028148.html -Ian
Re: [whatwg] a rel=attachment
2011/7/14 Andy Mabbett a...@pigsonthewing.org.uk 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser should treat this link as if the response came with a content-disposition: attachment header, and offer to download/save the file for the user. How would this be different to the already-available rel=enclosure ? It seems quite similar, except that afaik no browser yet acts on enclosure. I don't want to get into bikeshedding discussions, both enclosure and attachment have precedent, I simply want to implement this :) -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] a rel=attachment
The download=filename seems like a nice proposal (assuming that the filename is optional, and if not specified it just takes whatever the name would otherwise be). It also neatly solves the filename issue without cluttering the a tag with tons of options. On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the This has been raised a couple times: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread was derailed partway through) I've wanted this several times and I'm strongly in favor of it. After mulling this over with some application developers who are trying to use this functionality, it seems like adding a rel attribute to the a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf would indicate that the browser This isn't enough; the filename needs to be overridable as well, as it is with Content-Disposition. My recommendation has been: a href=image.jpg download a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg where the first is equivalent to Content-Disposition: attachment, and the second is equivalent to Content-Disposition: attachment; filename=picture.jpg. -- Glenn Maynard
Re: [whatwg] window.cipher HTML crypto API draft spec
I personally find this to be a very interesting and potentially useful proposals. One of the problems that we / the web face is a legal requirement faced by many Asian banks (esp. Korea) to digitally sign all transactions. To meet this requirement, they use ActiveX controls, as the platform doesn't really give them the primitives they need. This seems like it should give them what they need, but I would be very interested in knowing whether there's more that would be needed or whether this would actually suffice. It would be good if we can figure out whether this is sufficient for e.g. Korean banking requirements, and if not, what else would be necessary. Does anyone have contacts with the relevant industry groups? -Ian On Fri, May 20, 2011 at 8:04 AM, David Dahl dd...@mozilla.com wrote: Hello WHATWG members, With user control and privacy in mind, I have created a spec and an implementation for an easy to use cryptography API called DOMCrypt. This API will provide each web browser window with a 'cipher' property that facilitates: * asymmetric encryption key pair generation * public key encryption * decryption * signature generation * signature verification * hashing * easy public key discovery via meta tags I have created a Firefox extension that implements all of the above, and am working on an experimental patch that integrates this API into Firefox. The draft spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest The project originated in an extension I wrote, the home page is here: http://domcrypt.org The source code for the extension is here: https://github.com/daviddahl/domcrypt The Mozilla bugs are here: https://bugzilla.mozilla.org/show_bug.cgi?id=649154 https://bugzilla.mozilla.org/show_bug.cgi?id=657432 You can test the API by installing the extension hosted at domcrypt.organd addons.mozilla.org, and going to http://domcrypt.org Best Regards, David Dahl Firefox Engineer, Mozilla Corp.
Re: [whatwg] SearchBox API
I think there might be some confusion with default search / adding search providers. When you add a search provider like YouTube or php.net we just take a URL and expand one template parameter with the search query. With instant search this actually doesn't work because you need to provide the data to the page as the user is typing, you don't want to do a new GET request each time the user presses a letter. -Ian On Wed, Oct 13, 2010 at 4:18 PM, Peter Kasting pkast...@google.com wrote: On Wed, Oct 13, 2010 at 4:12 PM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Would it not be best to implement this based in the browser search integration thing that allows people to include a search option to a site through the browser, like YouTube, php.net, etc. I can't for the life of me figure out what you're saying. PK
Re: [whatwg] Why is the feature Web Storage removed from HTML5 Spec?
Many features are now in separate specifications / drafts, linked to in the introduction you reference. It doesn't mean they're dead, indeed web storage has been implemented by a number of browsers as have other features listed there such as geolocation, websockets, etc. Don't read too much into it. HTML5 is a single specification, it doesn't mean that it's the only specification browsers support. For instance, all browsers support CSS - CSS is not in the HTML5 specification, it's a distinct specification. There are many logistical advantages etc, again, don't read too much into it. On Sat, Aug 28, 2010 at 7:19 AM, zhao Matt mattzhao...@gmail.com wrote: I saw HTML5 spec 's introductionhttp://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#introductionincludes the following content, Features that are not currently in this document that were in the past considered part of HTML5...,, include:... Web Storage I know Web Storage provides ways for web applications to store key-value data in the browser, effectively replacing cookies, but I am curious why is the feature removed from HTML5 Spec? or Why can't the feature be contained in HTML5? thanks.
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
I don't understand why I would need an input type=year to get this right though. If the bank wants something in 年号 it can just let the user type in 1985 and convert that via JS to 昭和60年, no? If anything, having some sort of picker seems like it would be more complicated. Frankly, this seems a bit over-complicated. The number of times a user will be entering a year other than 1900-present has got to be infinitesimally small. In reflecting upon the years I've entered, it'a almost always been a living person's date of birth, some event I was scheduling, a date for something I was purchasing (e.g. airline ticket), or the present date. I really don't know if it's worth spending time on something that is such a minor use case, and can frankly be handled fine without a dedicated input type. And niwa-san, on every document I've ever filled out for the Japanese government, I've always written 1985年 instead of 昭和60年 and it's yet to cause me any problems ;-) I do understand that there are some sites that want it written in the traditional form, but these seem to be precious few and far between, and frankly are not the sites I would expect to find HTML5 form input elements on anyways if the US government is any indication of moving to new standards... On Mon, Aug 9, 2010 at 5:33 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: I'd just say that there might be a demand for this feature in Japan (if localized properly) because all official government document needs to dated with era name (http://en.wikipedia.org/wiki/Japanese_era_name). Some banks even implement their internal database systems using era system, and it's always cumbersome for humans to convert between era and Gregorian year. Best, Ryosuke Niwa On Sun, Aug 8, 2010 at 6:11 PM, Kit Grose k...@iqmultimedia.com.au wrote: The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider dropping the sandbox attribute from the iframe element
We (webkit/chrome) have had iframe sandbox implemented for over half a year. We've found some bugs in implementation here and there and fixed them. It solves a very real problem, has already been implemented, and your argument provides absolutely no information. Can you elaborate? On Sun, Aug 1, 2010 at 6:59 PM, Tantek Çelik tan...@cs.stanford.edu wrote: Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may not actually solve the problem it is intending to solve. More details here: http://wiki.whatwg.org/wiki/Iframe_Sandbox I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page. Thanks! Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] [URL] Starting work on a URL spec
http://code.google.com/apis/safebrowsing/developers_guide_v2.html#Canonicalization lists some interesting cases we've come across on the anti-phishing team in Google. To the extent you're concerned with / interested in canonicalizaiton, it may be worth taking a look at (not to suggest you follow that in determining how to parse/canonicalize URLs, but rather to make sure that you have some correct way of handling the listed URLs). BTW, are you covering canonicalization? -Ian On Fri, Jul 23, 2010 at 9:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/23/10 11:59 PM, Silvia Pfeiffer wrote: Is that URLs as values of attributes in HTML or is that URLs as pasted into the address bar? I believe their processing differs... It certainly does in Firefox (the latter have a lot more fixup done to them, and there are also differences in terms of how character encodings are handled). I would be particularly interested in data on this last, across different browsers, operating systems, and locales... There seem to be servers out there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, and it's not clear to me how to make things work with them all. -Boris
Re: [whatwg] HTML 5 : The Youtube response
Also related discussion, where I proposed something similar on WHATWG: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg21565.html On Thu, Jul 1, 2010 at 2:02 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote: One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular. I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful? Regards, Maciej -Kevin On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote: I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient: A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened. B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor. C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5 . D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms. E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W). F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode. I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate. Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen — text and UI elements displayed by attacker will look noticeably different. That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though. - Maciej
Re: [whatwg] Storage quota introspection and modification
Am 11. März 2010 14:50 schrieb Michael Nordman micha...@google.com: On Thu, Mar 11, 2010 at 1:29 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: 2010/3/11 Ian Fette (イアンフェッティ) ife...@google.com: Yes, but I think there may be uses of things like storage for non-offline uses (pre-fetching email attachments, saving an email that is in a draft state etc.) If it's relatively harmless, like 1mb usage, I don't want to pop up an infobar, I just want to allow it. So, I don't really want to have an infobar each time a site uses one of these features for the first time, I'd like to allow innocuous use if possible. But at the same time, I want apps to be able to say up front, at a time when the user is thinking about it (because they just clicked something on the site, presumably) here's what I am going to need. This is precisely my preferred interaction model as well. Absolutely silent use of a relatively small amount of resources, just like cookies are done today, but with a me-initiated ability to authorize it to act like a full app with unlimited resources (or at least much larger resources). In addition to more storage, another difference that ideally would come along with the full-app-privilege is for the user agent to avoid evicting that data. So stronger promises about keeping that data around relative to unprivileged app data. Also, this is being discussed in terms of apps. Can more than one app be hosted on the same site? And if so, how can their be stored resources be distinquished? Given that we have no way to enforce it in the UA (minus any radical changes to same origin policy), I am leaning towards saying no to anything that would actually be enforced. Perhaps we can make it easier for an app to define what resources it owns, so that it can be broken down in a bit more friendly way in the UI, but I really don't find it that interesting to be honest given how few people I expect to ever go to the UI or even care. ~TJ
Re: [whatwg] Storage quota introspection and modification
Am 11. März 2010 14:35 schrieb Mike Shaver mike.sha...@gmail.com: 2010/3/11 Ian Fette (イアンフェッティ) ife...@google.com: AFAIK most browsers are setting a default quota for storage options that is on the order of megabytes. Could well be, indeed. It sounded like you'd done some thinking about the size, and I was curious about how you came up with that number (versus some %age of available disk, for example). To be honest, I don't think it was all that scientific. More like If someone discovered that random.com was storing 1GB of stuff on their disk and they didn't know, would they (rationally or not) get pissed off about it? and that seemed to be a yes. 5Mb? no. We could go for a percentage of the disk, but again, how much to take? If someone discovers that their disk is half full, are they going to think to open up their browser to clear stuff out? Do they even know where their browser's profile directory is? Or are they just going to get frustrated and curse. Yes, but I think there may be uses of things like storage for non-offline uses (pre-fetching email attachments, saving an email that is in a draft state etc.) If it's relatively harmless, like 1mb usage, I don't want to pop up an infobar, I just want to allow it. So, I don't really want to have an infobar each time a site uses one of these features for the first time, I'd like to allow innocuous use if possible I think of an infobar as relatively innocuous, and a good balance of user awareness versus flow interruption, but I repeat my lack of interaction design credentials! But I really don't want to see infobars everywhere :) (Your attachment example is an interesting one, I think: do I get the request if I request too-big an attachment, but not if it's a small one? Or if it's saving a blog post draft that has a bunch of images in it, vs. one that's 140 chars long.) exactly But at the same time, I want apps to be able to say up front, at a time when the user is thinking about it (because they just clicked something on the site, presumably) here's what I am going to need. OK, I see. What if we had the named-subquota stuff, and the way you triggered that request was creation of a named subquota? That would also encourage app developers to provide a description of the quota, and perhaps the sort of necessary for offline operation vs improves performance vs supports additional features. The named subquota creation request could give an initial requested size and estimated upper bound for the size. An async event delivered back (or a callback called) could tell the app what quota it was granted, if any (or maybe just that it was granted some, but the size limit wasn't specified). My initial reaction was that I don't know how much I buy into the subquota part (vs named quota in general). E.g. if we can't enforce any of the subquota distinctions beyond a same-origin level, it seems of limited use. Upon further thought though, if you assume apps you trust are well behaved, then this may actually be a good idea. Would make displaying this information to users easier as well, even if relatively few users ever do go into options UI. At this point, if named subquota would meet the requirements I initially put forth (request a set of resource quotas that I think I need, and get a callback if I get them), and ideally be able to interrogate some sort of information about the named subquota (be it how many bytes are free vs what are you reasonably sure I can store I really don't care), I am all for it ;-) Is there some named subquota thread that I need to +1? Mike
Re: [whatwg] Storage quota introspection and modification
Am 10. März 2010 16:11 schrieb Mike Shaver mike.sha...@gmail.com: 2010/3/10 Ian Fette (イアンフェッティ) ife...@google.com: As I talk with more application developers (both within Google and at large), one thing that consistently gets pointed out to me as a problem is the notion of the opaqueness of storage quotas in all of the new storage mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the Filesystem API being worked on in DAP, etc). First, without being able to know how large your quota currently is and how much headroom you are using, it is very difficult to plan in an efficient manner. For instance, if you are trying to sync email, I think it is reasonable to ask how much space do I have, as opposed to just getting halfway through an update and finding out that you hit your quota, rolling back the transaction, trying again with a smaller subset, realizing you still hit your quota, etc. It generally seems that desktop mail clients behave in the undesirable way you describe, in that I've never seen one warn me about available disk space, and I've had several choke on a disk being surprisingly full. And yet, I don't think it causes a lot of problems for users. One reason for that is likely that most users don't operate in the red zone of their disk capacity; a reason for THAT might be that the OS tells them that they're getting close, and that many of their apps start to fail when they get full, so they are more conditioned to react appropriately when they're warned. (Also, today's disks are gigantic, so if you fill one up it's usually a WTF sort of moment.) Part of that is also helped by the fact that they're managing a single quota, effectively, which might point to a useful simplification: when the disk gets close to full, and there's a lot of data in the storage cache, the UA could prompt the user to do some cleanup. Just as with cleaning their disk, they would look for stuff they had forgotten was still on there (I haven't used Google Reader in ages!) or didn't know was taking up so much space (Flickr is caching *how* much image data locally?). The browser could provide a unified interface for setting a limit, forbidding any storage, compressing to trade space for perf; on the desktop users need to configure those things per-application, if such are configurable at all. If I really don't like an app's disk space usage on the desktop, I can uninstall it, for which the web storage analogue would perhaps be setting a small/zero quota, or just not going there. One thing that could help users make better quota decisions is a way for apps to opt in to sub-quotas: gmail might have quotas for contact data, search indexing, message bodies, and attachments. I could decide that on my netbook I want message bodies and contact data, but will be OK with slow search and missing attachments. An app like Remember The Milk might just use one quota for simplicity, but with the ability to expose distinct storage types to the UA, more complex web applications could get sophisticated storage management for free. So I guess my position is this: I think it's reasonable for apps to run into their quota, and to that end they should probably synchronize data in priority order where they can distinguish (and if they were going to make some decision based on the result of a quota check, presumably they can). User agents should seek to make quota management as straightforward as possible for users. One reasonable approach, IMO, is to assume that if there is space available on the disk, then an app they've offlined can use it. If it hurts, don't go back to that site, or put it in a quota box when you get the achievement unlocked: 1GB of offline data pop-up. Mike Mike - I think apps will have to deal with hitting quota as you describe, however with a normal desktop app you usually have a giant disk relative to what the user actually needs. When we're talking about shipping something with a 5mb or 50mb default quota, that's a very different story than my grandfather having a 1tb disk that he is never going to use. Even with 50mb (which is about as much freebie quota as I think I am comfortable giving at the moment), you will blow through that quite quickly if you want to sync your email. The thing that makes this worse is that you will blow through it at some random point (as there is no natural installation point from the APIs we have. You just get some freebie appcache, web *** database quota etc.) You seem to propose if the user has offlined the app, set the default quota to be unlimited and provide better ways for the user and application to manage this when there is pressure on disk space. I would personally be in favor of this approach, if only we had a good way to define what it meant to offline the app. Right now, appcache, database, everything is advisory. The browser runs across an appcache manifest and magically makes
Re: [whatwg] Storage quota introspection and modification
Am 11. März 2010 12:00 schrieb Mike Shaver mike.sha...@gmail.com: 2010/3/11 Ian Fette (イアンフェッティ) ife...@google.com: I think apps will have to deal with hitting quota as you describe, however with a normal desktop app you usually have a giant disk relative to what the user actually needs. When we're talking about shipping something with a 5mb or 50mb default quota, that's a very different story than my grandfather having a 1tb disk that he is never going to use. Even with 50mb (which is about as much freebie quota as I think I am comfortable giving at the moment), you will blow through that quite quickly if you want to sync your email. How did you come up with 50MB? As a user, I would want the application that is gmail to have the same capabilities as the application that is thunderbird, I think. Isn't that our goal? AFAIK most browsers are setting a default quota for storage options that is on the order of megabytes. The thing that makes this worse is that you will blow through it at some random point (as there is no natural installation point from the APIs we have. That's the case for desktop applications too, really -- mostly I run out of disk not when I install uTorrent or Thunderbird, but when I'm trying the Nth linux distro to find one that likes my video card or someone mails me an HD-resolution powerpoint and I'm about to head to the airport. I would personally be in favor of this approach, if only we had a good way to define what it meant to offline the app. Sorry, I was working from that premise, which (I thought!) you stated in your first message: I personally would not expect to browse to a site and then just happen to be able to use it offline, nor do I expect users to have that expectation or experience. Rather, I expect going through some sort of flow like clicking something that says Yes, I want to use Application X offline. Could also be an infobar on first some-kind-of-storage use, which users can click to say yeah, make sure this works offline vs it can use some storage, I guess, but don't let it get in the way of my torrents! I am not a UI designer worth the term, but I *do* believe that the problem is solvable. Yes, but I think there may be uses of things like storage for non-offline uses (pre-fetching email attachments, saving an email that is in a draft state etc.) If it's relatively harmless, like 1mb usage, I don't want to pop up an infobar, I just want to allow it. So, I don't really want to have an infobar each time a site uses one of these features for the first time, I'd like to allow innocuous use if possible. But at the same time, I want apps to be able to say up front, at a time when the user is thinking about it (because they just clicked something on the site, presumably) here's what I am going to need. Mike
[whatwg] Storage quota introspection and modification
As I talk with more application developers (both within Google and at large), one thing that consistently gets pointed out to me as a problem is the notion of the opaqueness of storage quotas in all of the new storage mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the Filesystem API being worked on in DAP, etc). First, without being able to know how large your quota currently is and how much headroom you are using, it is very difficult to plan in an efficient manner. For instance, if you are trying to sync email, I think it is reasonable to ask how much space do I have, as opposed to just getting halfway through an update and finding out that you hit your quota, rolling back the transaction, trying again with a smaller subset, realizing you still hit your quota, etc. I would like to see a method added, for any storage mechanism, something like GetCurrentQuota() and GetCurrentQuotaUsed(). (I specifically don't care what they're called or the details, e.g. whether they need to be callbacks, I just want to see us address this use case.) Secondly, I think we need a better answer for obtaining a larger quota. Let's think for a moment about the use cases -- in most instances, I am going to make a decision that I want to use an application offline. (I personally would not expect to browse to a site and then just happen to be able to use it offline, nor do I expect users to have that expectation or experience. Rather, I expect going through some sort of flow like clicking something that says Yes, I want to use Application X offline. At this point, I want to get any permissioning issues out of the way. I don't want to wait until the data sync to the Web XXX Database starts failing 10 minutes later to pop up an infobar that is no longer in the user's current flow / state of mind, I don't want to then pop up another infobar 30 minutes later saying their Filesystem quota is full, etc. I want to be able to get this out of the way all at once, at a point in time where I believe the user is actually in the mindset / task of deciding that they want to use my web application. I specifically do not want to have to deal with 4 different infobars, potentially at 4 different points in time, to use an application I have decided I want to use. To that point, I would like to see a method added (presumably that can only be called in response to a user action) that would allow my page to request a bundle of permissions. I am going to go out on a limb here and include geolocation in this bundle. Some sort of a callback type API where I pass in a list of permissions that I want, the UA is free to display this to the user in whatever mechanism it determines appropriate (if at all -- e.g. if the user has already denied geolocation and that's being requested again, as a UA i might decide not to present that request). That is, I could pass in something like [LocalStorageQuota, 20*1024*1024 /* 20M */, WebSQLQuota, 1*1024*1024*1024 /* 1GB */, FileSystemQuota, 10*1024*1024*1024 /* 10GB */, Geolocation, true], and the callback could then (as a convenience) indicate the current quota for all of the things that I asked for, so that I could figure out whether the user accepted, denied, or accepted and modified the request and how I can then proceed (or not proceed). Again, I don't care terribly about the details of how the API looks, the above is just meant for illustration. -Ian
Re: [whatwg] api for fullscreen()
I think what I've heard from application developers over and over again is that, while the UA may provide some way to go into full screen from in the browser chrome, it is much more discoverable when that capability exists from within the content area (e.g. people are used to clicking on the full screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian 2009/12/16 Ian Hickson i...@hixie.ch On Wed, 16 Dec 2009, Michael Dale wrote: It would be really nice if the html5 spec supported a javascript call to set a target window to fullscreen. The browser would then issue a security warning at the top of the page (similar to pop-ups) and then the user could grant that domain permission to go full-screen. Why would that be better than the user just telling the UA to make the page full-screen directly? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: I think what I've heard from application developers over and over again is that, while the UA may provide some way to go into full screen from in the browser chrome, it is much more discoverable when that capability exists from within the content area (e.g. people are used to clicking on the full screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. You could tie it to user gestures, e.g. only allow a page to call fullscreen() in response to a user gesture, much as many browsers will block popups that do not result from a user gesture. Not perfect, but a large improvement. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. correct I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? If you can only call fullscreen() in response to a user gesture, and there is some reasonably obvious thing that happens when you go full screen (hopefully a bit more obvious than what Flash currently does), then I'm hoping a sophisticated user who knows about noflash could figure out that they just went into fullscreen. As for the unsophisticated user, they're already at risk by flash, hopefully we could do better than flash, but if not, I think I would be willing to accept being on-par with Flash on this issue. / Jonas
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: I think what I've heard from application developers over and over again is that, while the UA may provide some way to go into full screen from in the browser chrome, it is much more discoverable when that capability exists from within the content area (e.g. people are used to clicking on the full screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. You could tie it to user gestures, e.g. only allow a page to call fullscreen() in response to a user gesture, much as many browsers will block popups that do not result from a user gesture. Not perfect, but a large improvement. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. correct I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? If you can only call fullscreen() in response to a user gesture, and there is some reasonably obvious thing that happens when you go full screen (hopefully a bit more obvious than what Flash currently does), then I'm hoping a sophisticated user who knows about noflash could figure out that they just went into fullscreen. As for the unsophisticated user, they're already at risk by flash, hopefully we could do better than flash, but if not, I think I would be willing to accept being on-par with Flash on this issue. You need to ensure that the user is actively looking at the screen though. If the user is getting back to a screen that is now in fullscreen mode it seems hard to impossible to tell in the general case. Unless you slab a bar at the top screen that constantly says Fullscreen mode, take caution. tie to user gesture, or make it stay until the user actively dismisses it (click an x on it, i dunno). I guess that if you enforced that fullscreen could only happen in response to a click then you are in better shape. I'd say you should try implementing this in chrome :) As for comparisons to flash, one of the goals of the mozilla project is to improve the web, not stay on par with flash ;) yes, I'm all about improving it too. But at some point we need to stop throwing our hands up in the air and saying well, we will provide this safer way, which no one will use, and therefore we've made the web a better place. :) / Jonas
Re: [whatwg] api for fullscreen()
2009/12/16 Robert O'Callahan rob...@ocallahan.org 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com I think what I've heard from application developers over and over again is that, while the UA may provide some way to go into full screen from in the browser chrome, it is much more discoverable when that capability exists from within the content area (e.g. people are used to clicking on the full screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). We are also hearing this. Michael Dale's suggestion of using a passive, opt-in notification for this sounds reasonable to me. Rob I'm not convinced we actually need opt-in, though if we did have opt-in it should allow the user to persist that choice (don't ask me for permission each time i try to fullscreen a youtube video.) I would much rather go for user gesture + opt-out. e.g. you have to cal fullscreen() in response to a user gesture, you immediately get fullscreened, but maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Uploading directories of files
2009/12/11 Anne van Kesteren ann...@opera.com On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) Note that extensions to File should be discussed on public-weba...@w3.org. At least, that's where they have been so far. Anne -- happy to move the File related discussion to public-weba...@. For the sake of wrapping up this thread though, are there there any changes that would need to be made to the HTML spec to allow this behavior (including limited path information in the name that gets sent when the form is posted?) I can't seem to find the actual part of the spec that defines or restricts what characters are valid in context. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Uploading directories of files
Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) 2009/12/11 Jeremy Orlow jor...@chromium.org On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst derer...@gmx.ch wrote: Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. Yes I see Anne's and your points. Anyway I don't see yet how to get _useful_ path information, as the same file can be posted as /a/b/1.jpg, and at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload dialog you did make the start point. Relying on information contained in the uploaded file does not seem to make sense to me, as you might want to upload a new file with the same name in order to replace the old one. The information in the path could be seen as a hint that may or may not be provided. I feel like it'd be difficult security wise to guarantee that the hint will be there and/or consistent from upload to upload. But, once again, some hint is better than none, right? If you as a web developer don't think it's useful, you can ignore it, right?
[whatwg] Uploading directories of files
USE CASE: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) Thoughts?
Re: [whatwg] Uploading directories of files
2009/12/10 Jonas Sicking jo...@sicking.cc 2009/12/10 Ian Fette (イアンフェッティ) ife...@google.com: USE CASE: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) Thoughts? I don't think there is anything in the spec preventing you from doing this right now. The fact that only files in the same folder can be selected is a limitation in the implementation, not a limitation in the spec. The spec does require that only the leaf name, without any paths, are submitted. Is that a problem? Perhaps not a show stopper, but I think it's sub-optimal. E.g. if I am using a client application, I can point it to my My Photos directory and it can infer some album structure from how I've organized my photos. It would be nice if a web photo app could do the same. I guess I'd be ok with changing the spec to allow more of the path to be exposed. However that would mean that there is a mismatch between what name is submitted and what name you'd get from input.files[n].name. I think that the notion of allowing more of the path to be exposed and reconciling that with .name is where the problem lies, and would like to figure out if we could resolve that. I think that there is a case to be made for including the paths -- e.g. if I'm uploading photos to flickr, picasa, or facebook, I may have already organized them locally, there's no reason that I shouldn't be able to maintain that structure when I upload to the web application. The question is then how that gets reconciled with input.files[n].name -- I would think it preferable if .name also were allowed to contain that extra information -- currently we say The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information. [1]. I guess I would propose that be changed to The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList. Again, open to suggestions of how this could be accomplished in a better way. [1] http://www.w3.org/TR/FileAPI/#dfn-name / Jonas
Re: [whatwg] Criticism of pushState (was Global Script proposal)
PushState is also useful for e.g. making sure that the referer header
contains useful information. Not to say that there aren't other ways to
accomplish that, but it is one thing that Global Context won't give you.
2009/9/7 Justin Lebar justin.le...@gmail.com
Dimitri Glazkov wrote:
But more to the point, I think globalScript is a good replacement for
the pushState additions to the History spec.
I'm not sure I agree. pushState lets you change the URI very quickly,
without doing any kind of navigation at all. To emulate a pushSate
with globalScript, you'd have to save and restore the whole document,
and the browser would still have to do at least one network request,
unless you were only changing the hash of the URI.
I am becoming
somewhat convinced that pushState is confusing, hard to get right, and
full of fail. You should simply look at the motivation behind building
JS-based history state managers -- it all becomes fairly clear.
Could you elaborate on these points? It seems to me that pushState
attacks a specific problem and delivers a simple solution which is
much better than the current workarounds (using the URL's hash to
identify a page and store state). Yes, it's nontrivial to develop an
AJAX app which uses pushState and works correctly with bookmarking and
page refreshes. On the other hand, pushState makes this a lot easier
than it would be otherwise.
My big issue with pushHistory is that it messes with the nature of the
Web: a URL is a resource you request from the server. Not something
you arrive to via clever sleight of hand in a user agent.
Like it or not, this ship has already sailed. When I load Gmail, I'm
taken to https://mail.google.com/mail/#inbox, but my browser never
sends #inbox to the server as part of the HTTP request. Pandora and
Facebook do something like this too. Perhaps the new intuition is
that a URL tells you how to get back to where you were.
So, you've managed to pushState your way to
a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks
it. What are you going to do know?
When reading this message in Gmail, my browser shows that I'm at
https://mail.google.com/mail/#label/WhatWG/{guid} . If I bookmark
this page and go back to it, Gmail takes me back to this exact
message. There's no actual resource named #label/WhatWG/{guid} on
Google's servers, but the URL I bookmarked is sufficient to identify
where I was, and Gmail's servers were intelligent enough to take me
there.
Maybe you think that Gmail's URLs should name real resources; maybe
they should look like
https://mail.google.com/mail.cgi?label=WhatWGmessage={guid} or
something. I'm not convinced this is better, but even if it suits
you, pushState still helps you navigate between mail.cgi?label=WhatWG
and mail.cgi?label=Drafts without a page refresh.
I think pushState API is really useful, but what do I know? We're
going to land it in Firefox trunk Real Soon Now, so developers and
members of this list will be able to play with it and decide for
themselves whether it's the right API to solve the problem at hand.
-Justin
Re: [whatwg] Proposal for local-storage file management
I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian 2009/8/27 Jens Alfke s...@google.com [This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a-file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] Proposal for local-storage file management
Not sure I agree with limiting it to the duration of the page. For instance, if I'm Flickr, I want to be able to get access to the My Photos directory and monitor it for new photos being added. Additionally, if I've given you access to the directory once, you can do most of the damage you want with that one-time access. The existing API has a parameter on many of the functions called persistent - I think the challenge is how to surface that in a reasonable UI. I believe though that it is worth trying. From the proposal - The last argument to browseForDirectory is a Boolean argument determining whether the mountpoint is to be made persistent across restarts of the application. If this argument is missing, it is assumed to be present, with a default value of false. If the argument is true then the File object must be marked as persistent. 2009/8/27 Linus Upson li...@google.com I like this proposal. It was what I had in mind with input type=open and input type=save. The only small change I'd make is that the page can only maintain a reference to the file for the life of that page. After that, the user needs to click open again. The open and save dialogs may remember recent files to make it easy for the user. Linus 2009/8/27 Jens Alfke s...@google.com [This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a-file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] Proposal for local-storage file management
Things missing from Arun's File proposal as is, off the top of my head: a) a directory structure (someone would have to build one on top of it... not critical, but not ideal) b) Ability to store it not in localStorage in some hidden directory, but on the part of the filesystem the user is familiar with (e.g. if I edit a picture, I don't want to store it in localStorage tucked away under local settings\user data\..., I want to save it in /home/ifette/photos/blah.jpg). Don't make the browser a silo. c) ability to map in a directory and make sense of that. I want Picasa / Flickr / Facebook to be able to see oh look, there's a new file in /home/ifette/photos/ - let's act on that.) d) Ability to read/update parts of the file. Could be used similar to blob builder for building up a form post that I then send off. Or could be used to manage an offline mail database, assuming I don't want to shove my mail into a sqlite database. For this it's desirable that I be able to efficiently fseek(), fread(), and fwrite() segments of the file. 2009/8/27 Jonas Sicking jo...@sicking.cc 2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com: I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian If we added the ability to create File objects, which could then be stored in localStorage (and WebSQL or whatever will replace it), then wouldn't we basically have the functionality you seek? What's the difference between sticking a File in the foo/bar/bin property on the localStorage object, vs. sicking a File object in the foo/bar/bin directory in some FileSystem object? Note that the latest HTML5 drafts allow for storing File objects in localStorage. / Jonas
Re: [whatwg] Fullscreenable and Mouselockable attributes
I think a lot of the concerns previously re: fullscreen have focused around the notion that a user somehow ends up in the fullscreen mode without knowing it, and is therefore susceptible to spoofing. This proposal leaves the act of going into fullscreen at the discretion of the user agent instead of script (the UA provides some mechanism, presumably, that the user would have to go through), which to me seems to side-step these problems. I know we looked at using CSS to do this previous (media: projection) but as I recall it ended up having a number of issues that in practice caused problems. Peter Kasting looked at it if I recall, he could probably give better background info. 2009/8/4 Henry Bridge hbri...@google.com With the video tag and web games gaining traction, it seems like there should be a way for apps to provide fullscreen and better control schemes to users. Of course, spoofing and clickjacking are major concerns, but I liked Alpha Omega's suggestion a few weeks ago [1] to specify a fullscreenable attribute to certain elements that hint to the UA that the object would be appropriate to consider for fullscreen. Similarly, for content that uses relative mouse motion or requires great precision (like a first-person view), it would be useful to have a mouselockable attribute; upon a UA defined interaction, the mouse would be locked within the particular element and report relative mouse events until the user disengages the lock. I can imagine a variety of ways browsers could expose these features: overloading F11 to gray out all portions of page except those are fullscreenable; pressing F11 repeatedly to cycle through elements; having a right click option on fullscreenable elements, automatic hover borders etc. Any interest or reasons why this wouldn't work? [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020479.html
Re: [whatwg] Installed Apps
2009/7/29 Maciej Stachowiak m...@apple.com On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote: Hello folks - I'm an engineer on the Gmail team. We've been working on a prototype with the Chrome team to make the Gmail experience better. We thought we'd throw out our ideas to the list to get some feedback. THE PROBLEM We would like to enable rich internet applications to achieve feature parity with desktop applications. I will use Gmail and Outlook as examples for stating the problems we hope to solve. I already commented on the security risks of the proposed solution, but I'd also like to examine the use cases more closely. Feature parity with desktop applications is pretty open-ended, and it might be that the actual concrete use cases can be addressed with less general mechanisms. -- Slow startup: When a user navigates to mail.google.com, multiple server requests are required to render the page. The Javascript is cacheable, but personal data (e.g. the list of emails to show) is not. New releases of Gmail that require JS downloads are even slower to load. Caching the code part of GMail, and making loading fast in the face of updates, seems like a problem that can be solved by the HTML5 Application Cache. Maybe it would be more fruitful to study further improvements in startup speed once GMail has adopted AppCache. -- Native apps like Outlook can (and do) run background processes on the user's machine to make sure that data is always up-to-date. -- Notifications: Likewise, Outlook can notify users (via a background process) when new mail comes in even if it's not running. I'm not sure it's justifiable to say these features are required for a native-like experience. The Mail application on Mac OS X only fetches new mail and gives you new mail notifications while it is actually running. Users who want to know about new mail right away keep the app open, and users who would like to free up resources quit it. It seems like GMail can already get rough parity with this experience. Depends on the device. If you're on Android (or I suspect iPhone, although I don't have one), doesn't the device sync your email constantly in the background? If I am a web-based email provider, I would like to have a similar option. Especially on something like the iPhone or Android, where I don't think it's reasonable to expect them to keep the browser open all the time (as the browser will just get closed if some other active app applies memory pressure). That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or status update type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a feed of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server-side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background.
Re: [whatwg] Make Vorbis a baseline codec for audio
Vorbis is the best lossy audio codec - Do you have data to back up this assertion? I am not an expert here, I had the naïve assumption that AAC was better given that major devices (e.g. iPod) use this format over Vorbis. I would love to see some data (other than some studies from 2005 on some forum that Wikipedia links to). Widely adopted ... in portable media players? Really? iPod? Zune? 2009/7/15 Ian Hickson i...@hixie.ch On Thu, 16 Jul 2009, Remco wrote: A few years ago, Vorbis as a baseline codec for audio was dismissed, because it was expected that the audio codec agreed upon to be used with video would also be used with audio. Now that agreement on a codec for video is out of the question, Vorbis can again be considered as a baseline codec for audio. Given the problem we had with the video codec, I would like to request that those of you interested in getting a standard audio codec do so by directly working with the browser vendors to get an agreement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Serving up Theora video in the real world
2009/7/11 Robert O'Callahan rob...@ocallahan.org On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.comwrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. Disagree -- the whole point of candidate rec (which the spec is driving towards) is to find out how implementable the spec is -- not just from the browser side, but from a web author side as well. If a feature turns out to not be implementable / usable in practice, that is certainly valid feedback at this stage. (Not to say it wouldn't be better to have had this conversation earlier, but I definitely don't think that the ship has sailed on this, and in practice some things you only find out once it's implemented and you can actually try using it.) Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 David Gerard dger...@gmail.com 2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: It seems you're rightish. Google, as usual, is having lots of fun with their stable/beta/release distinctions. See if you can decipher http://googlechromereleases.blogspot.com/ . At any rate, video is not supported in Chrome Stable, which is currently 2.0.x. Yep. For these purposes we're only considering release stuff. As Peter said, please don't just block Chrome flat out -- if you must, just block Chrome under version 3. Note that when we push 3 to stable, everyone will be automatically updated. As for how to decipher the releases blog, at the beginning of each post we state which channels this affects (Dev/Beta/Stable). Dev is, as it sounds, the latest and most frequently released to, stable is less frequently updated. Eventually, when we're happy, we take a dev release and call it beta and then stable. Anyone got ideas on the iPhone problem? - d.
Re: [whatwg] Codecs for audio and video
2009/7/1 Jeff McAdams je...@iglou.com timeless wrote: I also don't like how people enjoy a good run of corporation hunting. First you go after Microsoft. Then you go after Google. Then you after Apple. Many (most?) corporations choose to operate under a heavy veil of secrecy (*particularly* Apple). That choice is also a choice to open themselves up these criticisms. These corporations have to take the good with the bad. If they chose to operate with greater transparency, then they would almost certainly come into less criticism. I have exactly zero sympathy for Apple, MS, and Google, for the criticisms they have received. They choose to operate in secrecy, then they choose to be the target of these criticisms. I'm not asking for sympathy, but I also don't think the characterization of Google as operating in secrecy is fair. There's a large number of people from the Google Chrome team participating on WHATWG and trying to contribute openly to these discussions. We're operating as an open source project, and trying to be as open as possible. At the same time, Google is a company whose purpose (as is any company) is to make money. YouTube is a separate team and not an open source project, I don't think it's reasonable to expect all of Google to suddenly release all of its information that has legitimate business reasons for staying company-internal. We've made what statements we can make, and I don't honestly think it reasonable to expect more. Suck it up. -- Jeff McAdams je...@iglou.com
Re: [whatwg] Browser Bundled Javascript Repository
2009/6/15 Joseph Pecoraro joepec...@gmail.com On Mon, Jun 15, 2009 at 1:09 PM, Joseph Pecoraro joepec...@gmail.comwrote: Dion: The problem here is that isn't backwards compatible and thus no-one will really be able to use it. I thought the original idea was backwards compatible. Maybe not the URN Schemes. If the original idea is not, could you point out the issues? The URN schemes isn't compatible. The SHA hash idea is do-able, but as Oliver pointed out is impractical: a) devs will forget to update it, b) looks ugly, c) fun things would happen with a SHA collision! ;) a) Solved by Validation - I can't think of anything much better then that. =( b) Canonical Listing - This shouldn't be too difficult to distribute from a central source or some convention. c) Hehe, I think I detect a hint of sarcasm. If there is a SHA1 collision then you'd probably make a lot of money! C is a serious concern. SHA-1 collisions are now 2^51 - http://eprint.iacr.org/2009/259.pdf Dion: You then also get into the how do I get my library into the browser? Enough widespread usage of a library is a clear indicator for adoption into a browser bundle. Dynamically growing repositories could optimize per computer for the particular user's browsing habits (assuming developers would mark their scripts with the identifiers). You can have the same problem with what libraries will Google include in its CDN. Although it may be easier for Google to host just about any library if it already has a CDN setup. This was a real problem for us. How much is enough ? We started to get inundated with requests for people to put libraries up there. Lets the browsers decide. And I can't make any reasonable suggestions without getting real world data, something I haven't tried to do yet. But yes, this is a good point, something that is extremely flexible / variable. Dion: After mulling this over with the Google CDN work, I think that using HTTP and the browser mechanisms that we have now gives us a lot without any of these issues. I was afraid of this. This is a completely valid point. I guess it sounds like too much work for too little gain? I don't want to stop you from working on these ideas. The core problem that we tend to download the same crap all the time is real, and I look forward to seeing people come up with interesting solutions. Thanks for the support. My thoughts are beginning to look like this: - Javascript Frameworks are downloaded all the time on many domains. This is a special case. - Those who benefit the most are the ones that can't space the extra request or large caches. This makes me think mobile browsers would get the biggest benefit. - I think the iPhone had some special html syntax for its mobile webpages, maybe they can sneak this in if it proves useful to them. - Joe
Re: [whatwg] Browser Bundled Javascript Repository
2009/6/15 Joseph Pecoraro joepec...@gmail.com c) fun things would happen with a SHA collision! ;) c) Hehe, I think I detect a hint of sarcasm. If there is a SHA1 collision then you'd probably make a lot of money! C is a serious concern. SHA-1 collisions are now 2^51 - http://eprint.iacr.org/2009/259.pdf This time I didn't detect sarcasm =) I was actually aware of that paper. I saw it on Reddit this past week, and although they complained about the fact that it has not yet been reviewed I think it could very well be valid. Its been known that SHA1 has been theoretically broken (not perfect 2**80) for some time now: (2005) http://www.schneier.com/blog/archives/2005/02/sha1_broken.html However, its application in this Repository idea is not to be a cryptographically secure hash, it would just be to perform a quick, reliable, hash of the contents and to produce a unique identifier. There would be no security concerns in the impossibly rare chance that two scripts hashes collide. Just add some whitespace to the text somewhere! It would even be easy to debug when with standard tools such as Firefox's Firebug and Webkit's Web Inspector. Hahaha =) In the event of a collision there would be huge issues - imagine running someone else's script in your application. Basically XSS - someone could take over your app, steal passwords, do bank transactions on your behalf, etc. Collisions are made easier in plain text than in certs given that your input is not constrained. Also, Git and Mercurial (distributed version control systems) have been using SHA1 for the exact same purpose for years. I'm more familiar with Git's use of SHA1 and it uses it everywhere in the internals (file contents, directory listings, commit history). There have been a number of threads about that :) Finally, if anyone here is seriously concerned with SHA1 just move to SHA-256 or SHA-512. With a repository unlikely to grow into the thousands, much less the millions, the chances of a collision even in 2**51 (2251799813685248 base 10) is bold thinking ;) The chances assuming everything is random are very low. The chances assuming an active attacker, which is the case we're considering here, are not 1/2^51. 2^51 merely represents how much work needs to be done, or viewed alternately, how close a plausible attack is. I'm not attacking anyone here, I'm just clarifying why I think SHA1 is not a bad choice. Collision will always be an issue when a infinite number of things gets reduced to a finite set of values, but the concern negligible when done right. Cheers - Joe
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
MPEG-1 is not exactly a popular codec on the web if you look at the breakdown of video files on the web. The most popular formats are H.264 and FLV. H.264 currently offers the best performance in terms of image quality and compression (and is already the de-facto choice in a large, and increasing, set of cameras / editing software / ...). I don't think we would be interested in supporting something like MPEG-1 which is, at this point in time, far behind the curve. We have chosen to support H.264 + AAC as well as Ogg (Theora + Vorbis) for video in Google Chrome, mainly because H.264 is what we see as the best performing option and Ogg is (currently) the most viable open alternative. Encouraging everyone to use MPEG-1 would just result in a lesser user experience and more bandwidth consumption, neither of which really interest us. 2009/5/29 jjcogliati-wha...@yahoo.com I propose that a MPEG-1 subset should be considered as the required codec for the HTML-5 video tag. == MPEG-1 Background == MPEG-1 was published as the ISO standard ISO 11172 in August 1993. It is a widely used standard for audio and video compression. Both Windows Media and Apple Quicktime support playing MPEG-1 videos using Audio Layer 2. MPEG-1 provides three different audio layers. The simplest is Audio Layer 1 and the most complicated is Audio Layer 3, usually known as MP3. Since MPEG-1 includes MP3, a full implementation of a MPEG-1 decoder would not be royalty free until either all the essential MP3 patents expire, or a royalty free license is granted for all the essential MP3 patents. == MPEG-1 PRF == I propose the following subset of MPEG-1 as the MPEG-1 Potentially royalty free subset (MPEG-1 PRF): MPEG-1 Video without: forward and backward prediction frames (B-frames) dc-pictures (D-frames) MPEG-1 Audio Layers 1 and 2 only (no Layer 3 audio) This subset eliminates the currently patented MP3 portion of the MPEG-1 Audio. It also eliminates the non-needed B-frames and D-frames because there is less prior art for them and this has the side effect of simplifying MPEG-1 PRF decoding. == Patents == To the best of my knowledge, there are no essential patents on this MPEG-1 PRF subset. I have discussed this on a kuro5hin article, a post on the gstreamer mailing list and the MPEG-1 discussion page at Wikipedia, and no-one has been able to definitively list any patents on this subset. http://www.kuro5hin.org/story/2008/7/18/232618/312 http://sourceforge.net/mailarchive/message.php?msg_id=257198.16969.qm%40web62405.mail.re1.yahoo.com http://en.wikipedia.org/wiki/Talk:MPEG-1#Can_MPEG-1_be_used_without_Licensing_Fees.3F That said, absence of evidence is not evidence of absence. There still may certainly be patents on MPEG-1 PRF. Next I will discuss some prior art that exists for this subset. == Prior Art for MPEG-1 PRF == The H.261 (12/90) specification contains most of the elements that appear in MPEG-1 video with the exception of the B-Frames and D-frames. H.261 however only allows 352 x 288 and 176 x 144 sized video. H.261 is generally considered to be royalty free (such as by the OMS video project). There are no unexpired US patents listed for it on the ITU patent database. http://www.itu.int/rec/T-REC-H.261 http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of As for MPEG-1 Audio Layer 2, it is very close to MASCAM, which was described in Low bit-rate coding of high-quality audio signals. An introduction to the MASCAM system by G. Thiele, G. Stoll and M. Link, published in EBU Technical Review, no. 230, pp. 158-181, August 1988 The Pseudo-QMF filter bank used by Layer 2 is similar to that described in H. J. Nussbaumer. Pseudo-QMF Filter Bank, IBM technical disclosure bulletin., Vol 24. pp 3081-3087, November 1981. The MPEG-1 committee draft was publicly available as ISO CD 11172 by December 6, 1991. There is only a few year window for patents to have been filed before this counts as prior art, and not have expired. This list of prior art is by no means complete, in that there certainly could be patents that are essential for a MPEG-1 PRF implementation, but can not be invalided by this list of prior art. In the US, patents filed before 1995 last the longer of 20 years after they are filed or 17 years after they are granted. They also have to be filed within a year of the first publication of the method. This means that for US patents, most (that is all that took less than three years to be granted) patents that could apply to MPEG-1 will be expired by December 2012 (21 years after the committee draft was published.). == Brief comparison to other video codecs == Motion JPEG with PCM audio is the only codec that I know of that can be played in a stock Windows, Linux and Mac OS X setup. On the other hand, since it is basically a series of JPEG images and a 'WAV' file, the
Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
preface: IANAL. This post is meant to briefly describe what we are doing, not to give any legal guidance or opinions. It is not meant to be authoritative, please look at the source code if you want to verify these things yourself. We are using H.264 in Google Chrome, not in Chromium. We do not have the ffmpeg / h.264 related code in chromium (only the header files for ffmpeg), ffmpeg and h.264 related stuff is a complete external dependency loaded at run time. Chromium is the open source project, Google Chrome is the product we build by taking that open source code [chromium] and adding a few things that we don't make available in chromium (e.g. our artwork, and in this case a binary for ffmpeg / h.264 related stuff that is loaded at run time). 2009/5/29 Benjamin M. Schwartz bmsch...@fas.harvard.edu Ian Fette (イアンフェッティ) wrote: We have chosen to support H.264 + AAC as well as Ogg (Theora + Vorbis) for video in Google Chrome H.264 is heavily patented, and H.264 implementors typically acquire patent licenses from MPEG LA. However, as noted in [1], Chrome's use of ffmpeg for codec support subjects it to the LGPL, which requires that any such licenses be fully transferable and unrestricted. How does Google intend to meet its legal obligations in reference to H.264 (and AAC)? --Ben [1] http://annevankesteren.nl/2009/05/web-video
Re: [whatwg] localStorage behavior when cookies mode is session-only
There's already a giant thread about this topic, I suggest you join that thread. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.htmlPrivate browsing vs. Storage and Databases Cheers, Ian On Thu, Apr 9, 2009 at 2:13 PM, Honza Bambas hon...@allpeers.com wrote: In the W3C spec for localStorage http://dev.w3.org/html5/webstorage/#the-localstorage-attribute is said to present it (the persistent storage) the same way as cookies. There were suggestion to throw DOM_QUOTA_ERROR exception when storing to localStorage in case when cookies are in a session-only mode for a host/page. It makes sense from several reasons. This way web apps may decide or inform user about situation that the page cannot store to localStorage while there is no way for the page to figure out that cookies mode is session-only and web app still may freely read from the storage. My suggestion is then: - allow a page to obtain valid localStorage object - allow read from it - throw DOM_QUOTA_ERROR when storing to it But I don't know what to do in case of call to clear() and removeItem() methods. It would exposes the cookie behavior again when it fails/throws. -hb-
Re: [whatwg] Private browsing vs. Storage and Databases
In Chrome/Chromium, incognito mode is basically a new profile that is in memory (plus or minus... the cache will never get written out to disk, although of course the memory pages could get swapped out and hit the disk that way...). The implication is that, for many of these features, things could just naturally get handled. That is, whilst the session is active, pages can still use a database / local storage / ... / and at the end of the session, when that profile is deleted, things will go away. I personally like that approach, as there may be legitimate reasons to want to use a database even for just a single session. (Perhaps someone wants to edit a spreadsheet and the spreadsheet app wants to use a database on the client as a backing store for fast edits, I don't know...). I just don't like the idea of saying Sorry, incognito/private/... means a class of pages won't work if there's no reason it has to be that way. In short, I would prefer something closest to Option 3. It lets pages just work, but respects the privacy wishes of the user. (AppCache / persistent workers are the one exception where I think Option3 doesn't apply and we need to figure something out.) -Ian On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson beid...@apple.com wrote: A commonly added feature in browsers these days is private browsing mode where the intention is that the user's browsing session leaves no footprint on their machine. Cookies, cache files, history, and other data that the browser would normally store to disk are not updated during these private browsing sessions. This concept is at odds with allowing pages to store data on the user's machine as allowed by LocalStorage and Databases. Surly persistent changes during a private browsing session shouldn't be written to the user's disk as that would violate the intention of a private browsing session. Let's take the specific case of LocalStorage, which is what I am currently working on with WebKit. In attempting to fix this bug I came up with a few possible solutions: 1 - Disable LocalStorage completely when private browsing is on. Remove it from the DOM completely. 2 - Disable LocalStorage mostly when private browsing is on. It exists at window.localStorage, but is empty and has a 0-quota. 3 - Slide a fake LocalStorage object in when private browsing is enabled. It starts empty, changes to it are successful, but it is never written to disk. When private browsing is disabled, all changes to the private browsing proxy are thrown out. 4 - Cover the real LocalStorage object with a private browsing layer. It starts with all previously stored contents. Any changes to it are pretended to occur, but are never written to disk. When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled. 5 - Treat LocalStorage as read-only when private browsing is on. It exists, and all previously stored contents can be retrieved. Any attempt to setItem(), removeItem(), or clear() fail. Option 1 is simple but painful for applications to get such different behavior. Option 2 is only a little more complicated, but also seems unsatisfactory. Option 3 is simple to implement and option 4 would difficult to implement efficiently. Both would lead to bizarre behavior where data that the application thought was saved really wasn't. For now we're going with option 5. setItem() during private browsing will fail with the QUOTA_EXCEEDED_ERR the spec mentions. removeItem() and clear() will silently fail, since the spec assumes they always succeed and doesn't provide a failure mechanism. It seems the same issues apply to all the storage mechanisms, be it LocalStorage, SessionStorage (with optional session resuming), and Databases. I have a few questions I think it would be wise for the spec to address for all of these: 1 - What *should* the specified behavior be? 2 - If read-only ends up being the specified behavior, should we have a mechanism for removeItem() and clear() to demonstrate that they failed? Thanks, ~Brady
Re: [whatwg] Private browsing vs. Storage and Databases
On Tue, Apr 7, 2009 at 5:50 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Apr 7, 2009 at 8:24 PM, Brady Eidson beid...@apple.com wrote: 1 - Disable LocalStorage completely when private browsing is on. Remove it from the DOM completely. 2 - Disable LocalStorage mostly when private browsing is on. It exists at window.localStorage, but is empty and has a 0-quota. 3 - Slide a fake LocalStorage object in when private browsing is enabled. It starts empty, changes to it are successful, but it is never written to disk. When private browsing is disabled, all changes to the private browsing proxy are thrown out. 4 - Cover the real LocalStorage object with a private browsing layer. It starts with all previously stored contents. Any changes to it are pretended to occur, but are never written to disk. When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled. 5 - Treat LocalStorage as read-only when private browsing is on. It exists, and all previously stored contents can be retrieved. Any attempt to setItem(), removeItem(), or clear() fail. How are cookies handled right now? Surely the issues should be pretty much the same? In Chrome, basically like option 3. It's a new profile so it starts with no cookies, cookies can pile up but when the session ends they go away. Option 3 is simple to implement and option 4 would difficult to implement efficiently. Both would lead to bizarre behavior where data that the application thought was saved really wasn't. I certainly can't think of how 3 could ever cause a problem. It should be the same as the user just logging in from a computer they haven't used before, shouldn't it? yes I'm not certain about 4. What would be a concrete case where 4 would break, but normal use from multiple computers would not? I don't think 1, 2, or 5 are good ideas, since they make localStorage semi-usable at best when privacy mode is enabled.
Re: [whatwg] Private browsing vs. Storage and Databases
Yes. An incognito session starts with a blank profile, so no cookies, no cache, ... On Tue, Apr 7, 2009 at 5:52 PM, Brady Eidson beid...@apple.com wrote: That's interesting. I'm not exactly clear what an incognito session starts out with. Does it start without any cookies, for example? ~Brady On Apr 7, 2009, at 5:39 PM, Ian Fette (イアンフェッティ) wrote: In Chrome/Chromium, incognito mode is basically a new profile that is in memory (plus or minus... the cache will never get written out to disk, although of course the memory pages could get swapped out and hit the disk that way...). The implication is that, for many of these features, things could just naturally get handled. That is, whilst the session is active, pages can still use a database / local storage / ... / and at the end of the session, when that profile is deleted, things will go away. I personally like that approach, as there may be legitimate reasons to want to use a database even for just a single session. (Perhaps someone wants to edit a spreadsheet and the spreadsheet app wants to use a database on the client as a backing store for fast edits, I don't know...). I just don't like the idea of saying Sorry, incognito/private/... means a class of pages won't work if there's no reason it has to be that way. In short, I would prefer something closest to Option 3. It lets pages just work, but respects the privacy wishes of the user. (AppCache / persistent workers are the one exception where I think Option3 doesn't apply and we need to figure something out.) -Ian On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson beid...@apple.com wrote: A commonly added feature in browsers these days is private browsing mode where the intention is that the user's browsing session leaves no footprint on their machine. Cookies, cache files, history, and other data that the browser would normally store to disk are not updated during these private browsing sessions. This concept is at odds with allowing pages to store data on the user's machine as allowed by LocalStorage and Databases. Surly persistent changes during a private browsing session shouldn't be written to the user's disk as that would violate the intention of a private browsing session. Let's take the specific case of LocalStorage, which is what I am currently working on with WebKit. In attempting to fix this bug I came up with a few possible solutions: 1 - Disable LocalStorage completely when private browsing is on. Remove it from the DOM completely. 2 - Disable LocalStorage mostly when private browsing is on. It exists at window.localStorage, but is empty and has a 0-quota. 3 - Slide a fake LocalStorage object in when private browsing is enabled. It starts empty, changes to it are successful, but it is never written to disk. When private browsing is disabled, all changes to the private browsing proxy are thrown out. 4 - Cover the real LocalStorage object with a private browsing layer. It starts with all previously stored contents. Any changes to it are pretended to occur, but are never written to disk. When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled. 5 - Treat LocalStorage as read-only when private browsing is on. It exists, and all previously stored contents can be retrieved. Any attempt to setItem(), removeItem(), or clear() fail. Option 1 is simple but painful for applications to get such different behavior. Option 2 is only a little more complicated, but also seems unsatisfactory. Option 3 is simple to implement and option 4 would difficult to implement efficiently. Both would lead to bizarre behavior where data that the application thought was saved really wasn't. For now we're going with option 5. setItem() during private browsing will fail with the QUOTA_EXCEEDED_ERR the spec mentions. removeItem() and clear() will silently fail, since the spec assumes they always succeed and doesn't provide a failure mechanism. It seems the same issues apply to all the storage mechanisms, be it LocalStorage, SessionStorage (with optional session resuming), and Databases. I have a few questions I think it would be wise for the spec to address for all of these: 1 - What *should* the specified behavior be? 2 - If read-only ends up being the specified behavior, should we have a mechanism for removeItem() and clear() to demonstrate that they failed? Thanks, ~Brady
Re: [whatwg] Private browsing vs. Storage and Databases
2009/4/7 Jonas Sicking jo...@sicking.cc 2009/4/7 Ian Fette (イアンフェッティ) ife...@google.com: In Chrome/Chromium, incognito mode is basically a new profile that is in memory (plus or minus... the cache will never get written out to disk, although of course the memory pages could get swapped out and hit the disk that way...). The implication is that, for many of these features, things could just naturally get handled. That is, whilst the session is active, pages can still use a database / local storage / ... / and at the end of the session, when that profile is deleted, things will go away. I personally like that approach, as there may be legitimate reasons to want to use a database even for just a single session. (Perhaps someone wants to edit a spreadsheet and the spreadsheet app wants to use a database on the client as a backing store for fast edits, I don't know...). I just don't like the idea of saying Sorry, incognito/private/... means a class of pages won't work if there's no reason it has to be that way. In short, I would prefer something closest to Option 3. It lets pages just work, but respects the privacy wishes of the user. (AppCache / persistent workers are the one exception where I think Option3 doesn't apply and we need to figure something out.) I do agree that there's still need for storing data while in private browsing mode. So I do think it makes a lot of sense for .sessionStorage to keep working. But I do have concerned about essentially telling a website that we'll store the requested data, only to drop it on the floor as soon as the user exits private browsing mode (or crashes). / Jonas Doesn't the website have to handle that anyways? I mean, I assume that all the browsers are going to allow users some way to manage this stuff, much like cache/cookies - e.g. you have to assume that at some point in time the user is going to blow you away. (Especially on mobile devices where space is more of a premium...) -Ian
Re: [whatwg] Private browsing vs. Storage and Databases
On Tue, Apr 7, 2009 at 6:07 PM, Brady Eidson beid...@apple.com wrote: On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote: How are cookies handled right now? Surely the issues should be pretty much the same? They are unspecified. From this thread I have learned that Chrome and Firefox start with no cookies. Safari starts with a snapshot of cookies at the point where the user entered private browsing mode. I would not be surprised if Opera or IE8 were subtley different from either of these two approaches. Option 3 is simple to implement and option 4 would difficult to implement efficiently. Both would lead to bizarre behavior where data that the application thought was saved really wasn't. I certainly can't think of how 3 could ever cause a problem. It should be the same as the user just logging in from a computer they haven't used before, shouldn't it? I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user. Imagine a scenario where a user has no network connection and unknowingly left their browser in private browsing mode. Email, documents, financial transactions, etc could all be saved locally then later thrown away before they've had a chance to sync to a server. The same argument could be made for retaining cookies set during private browsing ;-) I don't think 1, 2, or 5 are good ideas, since they make localStorage semi-usable at best when privacy mode is enabled. Apparently Firefox plans to implement #2, and so far I'm standing by WebKit choosing #5 for now. Options 1, 2, and 5 all avoid the problem that 3 and 4 have which is that we're lying about saving data we have no intention to save. ~Brady
Re: [whatwg] Private browsing vs. Storage and Databases
FWIW, I think it would be helpful to expose via some manner that the user is in an incognito/private/whatever mode, especially to plugins. (Right now none of us can really control what plugins are doing). If we exposed that fact, a page could check it and decide what it wants to do. To me, that feels a lot better than just saying No, sorry, you don't get XYZ. 2009/4/7 Ian Fette (イアンフェッティ) ife...@google.com On Tue, Apr 7, 2009 at 6:07 PM, Brady Eidson beid...@apple.com wrote: On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote: How are cookies handled right now? Surely the issues should be pretty much the same? They are unspecified. From this thread I have learned that Chrome and Firefox start with no cookies. Safari starts with a snapshot of cookies at the point where the user entered private browsing mode. I would not be surprised if Opera or IE8 were subtley different from either of these two approaches. Option 3 is simple to implement and option 4 would difficult to implement efficiently. Both would lead to bizarre behavior where data that the application thought was saved really wasn't. I certainly can't think of how 3 could ever cause a problem. It should be the same as the user just logging in from a computer they haven't used before, shouldn't it? I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user. Imagine a scenario where a user has no network connection and unknowingly left their browser in private browsing mode. Email, documents, financial transactions, etc could all be saved locally then later thrown away before they've had a chance to sync to a server. The same argument could be made for retaining cookies set during private browsing ;-) I don't think 1, 2, or 5 are good ideas, since they make localStorage semi-usable at best when privacy mode is enabled. Apparently Firefox plans to implement #2, and so far I'm standing by WebKit choosing #5 for now. Options 1, 2, and 5 all avoid the problem that 3 and 4 have which is that we're lying about saving data we have no intention to save. ~Brady
Re: [whatwg] Private browsing vs. Storage and Databases
And as of right now, afaict, a user / user agent can prune a database and not be in violation of the database spec :) On Tue, Apr 7, 2009 at 6:11 PM, Brady Eidson beid...@apple.com wrote: On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ) wrote: I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user. Imagine a scenario where a user has no network connection and unknowingly left their browser in private browsing mode. Email, documents, financial transactions, etc could all be saved locally then later thrown away before they've had a chance to sync to a server. The same argument could be made for retaining cookies set during private browsing ;-) I disagree, as cookies are already specified to be of unspecified persistence. I believe a user agent can - at any time - prune cookies from it's cookie store and not be in violation of the cookies spec. ~Brady
Re: [whatwg] Private browsing vs. Storage and Databases
Yeah, but my argument is more that Incognito / Private / whatever is like starting from a boot cdrom with a filesystem that's in memory. The OS isn't pretending, nobody's lying to the app, that's just the way it is. I think Michael summarized it well - Copying it over and making it read-only violates privacy concerns. Turning it off entirely removes functionality when it could perhaps be useful I think that doing option 3, and perhaps providing a way for the app to know that we're in this mode so it can do whatever is appropriate (saving to the cloud more frequently, just not using localstorage all together, whatever is right for that app) solves those problems. On Tue, Apr 7, 2009 at 6:16 PM, Brady Eidson beid...@apple.com wrote: A user can, at any time, delete application resources from their file system while the application is in use, or before the application's next launch. They will suffer the consequences of their own action. The operating system probably shouldn't chose to do so on its own, the same way the OS shouldn't chose to pretend a file is safely on disk when it's not. ~Brady On Apr 7, 2009, at 6:12 PM, Ian Fette (イアンフェッティ) wrote: And as of right now, afaict, a user / user agent can prune a database and not be in violation of the database spec :) On Tue, Apr 7, 2009 at 6:11 PM, Brady Eidson beid...@apple.com wrote: On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ) wrote: I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user. Imagine a scenario where a user has no network connection and unknowingly left their browser in private browsing mode. Email, documents, financial transactions, etc could all be saved locally then later thrown away before they've had a chance to sync to a server. The same argument could be made for retaining cookies set during private browsing ;-) I disagree, as cookies are already specified to be of unspecified persistence. I believe a user agent can - at any time - prune cookies from it's cookie store and not be in violation of the cookies spec. ~Brady
