Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 7:17 PM, Shawn Wilsher wrote: > On 4/20/2010 4:11 AM, Mark Seaborn wrote: > >> 1) It doesn't allow a web app to ask for a storage allocation up front, >> before it starts to consume the storage. >> > Why does that matter? > It doesn't support the use cases that I suggested at the start of the thread: "* An e-mail web app requests an amount of storage that is large enough to store all your current e-mail, plus your e-mail for the next year at projected rates. As this runs out, it can request more. * A backup web app requests an amount that is large enough to store your data." Suppose I leave an e-mail web app running on my laptop while I'm not using it, expecting it to sync my mail. Then I take the laptop somewhere where there's no network connectivity. I don't want to find that the e-mail app failed to fetch my e-mail because it ran out of storage and was stuck while the browser displayed a prompt that I wasn't there to see. The same goes for the backup example. I wouldn't want to find that the backup app has failed to back up my data because it got stuck at a prompt. This wouldn't happen if the backup app had the ability to request, up front, the amount of storage that it knows it will need. This request might happen at the point where the user specifies what files they want the app to copy. > 2) In Opera, the quota can only be increased in multiples of about 15, so >> it >> takes three prompts to get up into the range of gigabytes. >> > But there is an unlimited option, yeah? > True, but it would be better not to have to give the web app carte blanche. However, it is a minor point because it is easily fixable. > 3) The web app can't choose when the question is put to the user. >> 4) The web app doesn't know how much storage has been allocated, so it >> doesn't know when a question will be asked. >> 5) In Opera, if the user chooses "Reject", they don't get prompted again. >> This means that asking the user at an appropriate time is important for >> the >> continued functioning of the web app. Prompting the user at the wrong >> time >> will interrupt them with a page-modal dialog which they might want to get >> rid of with "Reject", which would potentially break the web app by leaving >> it unable to get more storage. >> > These all feel like user-agent specific worries on how the user agent wants > to bring this to the attention of the user. > It's not user agent specific if the fix involves adding or changing a programmatic interface, or involves defining behaviour that web apps are likely to rely on to function correctly. Regards, Mark
[widgets] Draft agenda for 22 April 2010 voice conf
Below is the draft agenda for the April 22 Widgets Voice Conference
(VC).
** NOTE ** if we make reasonable progress via the mail list on item
#3 below (and let's please try to do so!), this meeting will be
canceled. **
Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged (as it can result in a shortened
meeting). Please address Open/Raised Issues and Open Actions before
the meeting:
http://www.w3.org/2008/webapps/track/products/8
Minutes from the last VC:
http://www.w3.org/2010/04/15-wam-minutes.html
-Regards, Art Barstow
Agenda:
1. Review and tweak agenda
2. Announcements
a. Call for Implementations: WARP Candidate Recommendation
http://www.w3.org/TR/2010/CR-widgets-access-20100420/
b. LCWD of Digital Signatures; deadline for comments is May 6
http://www.w3.org/TR/2010/WD-widgets-digsig-20100415/
c. LCWD of View Mode Media Feature; deadline for comments is May 18
http://www.w3.org/TR/2010/WD-view-mode-20100420/
d. No call on April 29; next call is May 6
e. Use www-style for technical discussions re CSSOM spec
3. View Modes Interfaces spec:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
a. Dependencies and timeframe for CSSOM spec; for context, see:
http://lists.w3.org/Archives/Public/public-hypertext-cg/2010AprJun/
0004.html
4. AOB
Logistics:
Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00
Boston; 06:00 Seattle
Duration: 90 minutes max
Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152
PIN: 9231 ("WAF1");
IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/
member-bin/irc/irc.cgi
Confidentiality of minutes: Public
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:05 PM, Anne van Kesteren wrote:
> On Wed, 21 Apr 2010 03:47:06 +0900, Maciej Stachowiak
> wrote:
>
>> I kinda hate the boolean argument. I would rather have a syntax where the
>> intent is obvious from the source code. A boolean is not very
>> self-documenting. In fact I can't even remember right now whether true or
>> false is the value that gives you anonymous XHR. Possibilities:
>>
>> - Separate AnonXMLHttpRequest constructor
>> - Constructor parameter takes an enum value, so you write new
>> XMLHttpRequest(ANON) or something like that.
>> - Constructor parameter takes a string value, so you write new
>> XMLHttpRequest("anon") or ("anonymous") or whatever.
>>
>
> I guess a separate constructor is the easiest way to go then. I wasn't sure
> whether it was worth it as it clutters the global object some more.
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place identifying info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>
--
Cheers,
--MarkM
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > wrote: > >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? >> > > Because I've yet to receive detailed feedback / proposals on CORS on what > needs changing. How are "Why can't it be made exactly like UMP?" and "Ideally, I'd like UMP to be folded into CORS by reference rather than by value, ..." not a detailed proposal? It's not a long proposal, because the proposal is simple enough to be clear and short. > In another thread Maciej asked you whether you would like to file the > appropriate bugs and the he would do so if you did not get around to it. I > have not seen much since. > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > > -- Cheers, --MarkM
Re: [IndexedDB] Granting storage quotas
On Tue, 20 Apr 2010 14:37:33 -0700 Michael Nordman wrote: > I think ericu is baking in a distinction in between 'permanent' and > 'temporary' in the FileSystem API he's working on. Some harmony across all > flavors of local storage could be good. He is: http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#using-localfilesystemsync I haven't seen ericu pop up in this thread but I guess he's reading it. Either way, it's certainly an approach that I'd be happy to see fine-tuned to be more or less consistent across various local storage mechanisms. -- Robin Berjon - http://berjon.com/
Re: [IndexedDB] Granting storage quotas
On Apr 21, 2010, at 2:27 AM, Mark Seaborn wrote: > > "* An e-mail web app requests an amount of storage that is large enough to > store all your current e-mail, plus your e-mail for the next year at > projected rates. As this runs out, it can request more. > * A backup web app requests an amount that is large enough to store your > data." > > Suppose I leave an e-mail web app running on my laptop while I'm not using > it, expecting it to sync my mail. Then I take the laptop somewhere where > there's no network connectivity. I don't want to find that the e-mail app > failed to fetch my e-mail because it ran out of storage and was stuck while > the browser displayed a prompt that I wasn't there to see. > > The same goes for the backup example. I wouldn't want to find that the > backup app has failed to back up my data because it got stuck at a prompt. > This wouldn't happen if the backup app had the ability to request, up front, > the amount of storage that it knows it will need. This request might happen > at the point where the user specifies what files they want the app to copy. Is there a precedent to such behavior, say in the desktop land? These applications require a fair amount of reliability of behavior and 1. I don't know if they create a large enough file before starting to bring data over. 2. I wonder what happens when they run out of space they had originally reserved. Nikunj
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 23:37:54 +0900, Mark S. Miller
wrote:
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place identifying
info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
Since you still work with the XMLHttpRequest object I think it should be
in the name of the constructor as well. "Uniform" doesn't tell you much
about what it is doing. "Anon" is much clearer in that sense. The user
agent will keep the request anonymous. That the author can put identifying
information on top of that is up to the author.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 23:50:40 +0900, Mark S. Miller wrote: On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close wrote: Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? Because I've yet to receive detailed feedback / proposals on CORS on what needs changing. How are "Why can't it be made exactly like UMP?" and "Ideally, I'd like UMP to be folded into CORS by reference rather than by value, ..." not a detailed proposal? It's not a long proposal, because the proposal is simple enough to be clear and short. Implementors are interested in an integrated solution (i.e. by value). I personally think it would also be of significantly less overhead and make it much more clear where the problems are. In another thread Maciej asked you whether you would like to file the appropriate bugs and the he would do so if you did not get around to it. I have not seen much since. As I pointed out we were already on the way to fixing this; I'm not sure why you want to revisit that discussion yet again. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 8:57 AM, Anne van Kesteren wrote: > "Uniform" doesn't tell you much about what it is doing. The term "uniform" in Uniform Messaging Policy (UMP) is used in the same sense as it is used in Uniform Resource Identifier (URI). In particular, the following from RFC 3986 is most relevant: "URIs have a global scope and are interpreted consistently regardless of context, ..." The UMP defines a way to produce an HTTP request regardless of context. Today, browsers can only produce requests that are entangled with the user-agent's local context and this is the key to enabling CSRF-like vulnerabilities. Well formed, legitimate Web content that expresses an HTTP request might be harmless when viewed from an attacker's user-agent, but if the exact same content is viewed through a victim's user-agent, there is a successful attack. The difference between the two requests is simply the change of context. The well-known CSRF attack is not the only way to cause mischief by switching the local context of an HTTP request. There is a whole family of similar attacks that use the same pattern, called Confused Deputy. The UMP enables web content to avoid this whole family of attacks by making requests from the global scope, rather than from the user-agent's local context. Today, requesting content is interpreted differently depending on context. The UMP makes this interpretation uniform, and so the produced HTTP request is the same no matter where it is produced from. This uniformity allows web content to avoid the built-in Confused Deputy vulnerabilities in the user-agent. Uniformity is the crux of what the UMP does. As MarkM noted, uniformity is not the same as anonymity. I can compose web content that produces a request that declares my identity. Using the UMP, I can ensure that the produced request is the same, no matter where the request is issued from. The produced request still declares my identity and so is not anonymous. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [IndexedDB] Bug/enhancement requests
Nikunj, On Apr 20, 2010, at 2:29 AM, ext Nikunj Mehta wrote: In order to have a sane process around processing feedback and keeping track of progress, may I request you to please use the W3 issue tracking system [1], when possible? This will greatly assist all of us in our efforts to improve IndexedDB and track the editor's processing of your feedback. I am not sure what the W3C process is for processing feedback, but I will endeavor to collect everything there and process it accordingly. WebApps uses both Trackbot [Trackbot] and Bugzilla [W3C-Bugzilla]. The choice is somewhat arbitrary but generally, Trackbot is used for all of the specs that did not move to WebApps from the HTML WG. Anyhow, WebApps' Trackbot includes two related Products: IndexedDB and WebSimpleDB. If you are going to use [1] instead of Trackbot, I will delete these two "products" (FYI, no issues were added to either of these products). OK? -Art Barstow [Trackbot] http://www.w3.org/2008/webapps/track/ [W3C-Bugzilla] http://www.w3.org/Bugs/Public/query.cgi Regards, Nikunj [1] http://www.w3.org/Bugs/Public/enter_bug.cgi? product=WebAppsWG&component=WebSimpleDB
Re: [IndexedDB] Bug/enhancement requests
On Apr 21, 2010, at 1:18 PM, ext Nikunj Mehta wrote: Let's use Bugzilla for all the spec bugs and enhancement requests on IndexedDB. Once we decide to track "issues" and find independent resolution, we could use TrackBot. OK, that works for me. -Art Barstow
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren wrote: > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > wrote: >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > Because I've yet to receive detailed feedback / proposals on CORS on what > needs changing. In another thread Maciej asked you whether you would like to > file the appropriate bugs and the he would do so if you did not get around > to it. I have not seen much since. The email you refer to listed several specific problems with CORS. As you've noted, Maciej agreed these were problems. Now you're telling us that as editor for the WG you have decided to ignore this detailed feedback because it is not yet filed as official Issues against CORS. Instead, you are choosing to ignore UMP and press ahead trying to gain implementer support for the mechanism defined in CORS, even though you know there are agreed problems with it. A different approach, would be to recognize the value of all the work and analysis the WG has put into UMP and so explore how CORS could reference and leverage this work. I am happy to collaborate with you on this task if you'd like to make the attempt. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [IndexedDB] Bug/enhancement requests
Art, Let's use Bugzilla for all the spec bugs and enhancement requests on IndexedDB. Once we decide to track "issues" and find independent resolution, we could use TrackBot. Nikunj On Apr 21, 2010, at 10:11 AM, Arthur Barstow wrote: > Nikunj, > > On Apr 20, 2010, at 2:29 AM, ext Nikunj Mehta wrote: > >> In order to have a sane process around processing feedback and keeping track >> of progress, may I request you to please use the W3 issue tracking system >> [1], when possible? >> >> This will greatly assist all of us in our efforts to improve IndexedDB and >> track the editor's processing of your feedback. >> >> I am not sure what the W3C process is for processing feedback, but I will >> endeavor to collect everything there and process it accordingly. > > WebApps uses both Trackbot [Trackbot] and Bugzilla [W3C-Bugzilla]. The choice > is somewhat arbitrary but generally, Trackbot is used for all of the specs > that did not move to WebApps from the HTML WG. > > Anyhow, WebApps' Trackbot includes two related Products: IndexedDB and > WebSimpleDB. > > If you are going to use [1] instead of Trackbot, I will delete these two > "products" (FYI, no issues were added to either of these products). OK? > > -Art Barstow > > [Trackbot] http://www.w3.org/2008/webapps/track/ > [W3C-Bugzilla] http://www.w3.org/Bugs/Public/query.cgi > > >> Regards, >> Nikunj >> >> [1] >> http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=WebSimpleDB >
Re: [IndexedDB] Granting storage quotas
FWIW, the "transient" vs. "permanent" storage support is exactly why I eagerly await an implementation of EricU's Filesystem API. Being able to guarantee that the UA will not discard potentially irreplaceable data is of paramount importance to web apps that want to work in an offline mode. I also find that the current arbitrary quota limit of 5MB per domain makes local storage APIs unusable for all but the most rudimentary apps (e.g., sticky note demo apps). There is an asymmetric distribution of local storage needs out there that no one is yet addressing (e.g., a photo- or video-related app might need GBs of local storage, an offline mail app might need tens or hundreds of MB, a TODO list app might only need kilobytes, etc.). I wholeheartedly support any effort to coordinate quota management among all of the various local storage APIs. The issue of quota limits is something that browser vendors will need to address soon enough, and it's probably best left up to them. The need for "permanent" storage across all local storage APIs, though, is something that in my opinion should come out of the standardization process. --mike clement
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 8:57 AM, Anne van Kesteren wrote:
On Wed, 21 Apr 2010 23:37:54 +0900, Mark S. Miller
wrote:
I dislike "AnonXMLHttpRequest" because the request is not necessarily
anonymous. For example, the requestor may very well place
identifying info
in the body '{"from": "j...@example.com", ...}'.
I like constructor name already shown at <
http://dev.w3.org/2006/waf/UMP/#ump-api-name>: "UniformRequest".
Since you still work with the XMLHttpRequest object I think it
should be in the name of the constructor as well. "Uniform" doesn't
tell you much about what it is doing. "Anon" is much clearer in that
sense. The user agent will keep the request anonymous. That the
author can put identifying information on top of that is up to the
author.
I agree that "Anonymous" or "Anon" is more clear as to the purpose
than "Uniform". I understand why UMP uses that term but I don't think
it will be obvious to authors reading code.
Regards,
Maciej
Re: [IndexedDB] Granting storage quotas
On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement wrote: > FWIW, the "transient" vs. "permanent" storage support is exactly why I > eagerly await an implementation of EricU's Filesystem API. Being able to > guarantee that the UA will not discard potentially irreplaceable data is of > paramount importance to web apps that want to work in an offline mode. > > I also find that the current arbitrary quota limit of 5MB per domain makes > local storage APIs unusable for all but the most rudimentary apps (e.g., > sticky note demo apps). There is an asymmetric distribution of local > storage needs out there that no one is yet addressing (e.g., a photo- or > video-related app might need GBs of local storage, an offline mail app might > need tens or hundreds of MB, a TODO list app might only need kilobytes, > etc.). > I wholeheartedly support any effort to coordinate quota management among all > of the various local storage APIs. The issue of quota limits is something > that browser vendors will need to address soon enough, and it's probably > best left up to them. The need for "permanent" storage across all local > storage APIs, though, is something that in my opinion should come out of the > standardization process. > Here's a stab at defining programming interfaces that make a distinction between "transient" vs "permanent" for the storage mechanisms. If we make additions like this, we should use the same terminology across the board. // WebSqlDBs, also could work for IndexedDBs window.openDatabase(...); // temporary window.openPermanentDatabase(...); // AppCaches, embellish the first line of the manifest file CACHE MANIFEST CACHE MANIFEST PERMANENT // FileSystem, see the draft, i've change the terms a little here window.requestFilesystem(...);// evictable window.requestPermanentFilesystem(...) // LocalStorage window.localStorage;// purgeable window.permanentLocalStorage;
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 10:39 AM, Tyler Close wrote: > On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren > wrote: > > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close > > wrote: > >> > >> Why can't it be made exactly like UMP? All of the requirements in UMP > >> have been discussed at length and in great detail on this list by some > >> highly qualified people. The current UMP spec reflects all of that > >> discussion. By your own admission, the CORS spec has not received the > >> same level of review for these features. Why hasn't CORS adopted the > >> UMP solution? > > > > Because I've yet to receive detailed feedback / proposals on CORS on what > > needs changing. In another thread Maciej asked you whether you would like > to > > file the appropriate bugs and the he would do so if you did not get > around > > to it. I have not seen much since. > > The email you refer to listed several specific problems with CORS. As > you've noted, Maciej agreed these were problems. Now you're telling us > that as editor for the WG you have decided to ignore this detailed > feedback because it is not yet filed as official Issues against CORS. > Instead, you are choosing to ignore UMP and press ahead trying to gain > implementer support for the mechanism defined in CORS, even though you > know there are agreed problems with it. > > A different approach, would be to recognize the value of all the work > and analysis the WG has put into UMP and so explore how CORS could > reference and leverage this work. I am happy to collaborate with you > on this task if you'd like to make the attempt. I've been watching the CORS/UMP debate from the sidelines. Here's how it looks to me: 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) be easier to implement and ship sooner. 2) Browser vendors intend to implement CORS. They don't want to have two similar but slightly different stacks for making requests, either in implementation or in what's exposed to developers. So, having UMP as a separate spec doesn't make sense if it's intended to be a subset (or even mostly a subset) of CORS. Mozilla might be willing to implement UMP with some API modifications and Microsoft hasn't voiced an opinion. Is that an accurate summary? Are there other advantages to keeping UMP a separate spec other than concerns of ship dates? Given the lack of vendor support, it doesn't seem like ship date is really a good argument since the ship date is dependent on vendors actually implementing this. Ojan
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 1:29 PM, Ojan Vafai wrote: > I've been watching the CORS/UMP debate from the sidelines. Here's how it > looks to me: > 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) > be easier to implement and ship sooner. We want to keep it a separate specification for two main reasons: a) The simpler, shorter UMP spec is easier for web developers to understand than a combined spec would be. b) We believe there are significant technical issues with CORS that should prevent it from being standardized in its current form. I suspect implementation of UMP features is independent of whether or not there are two documents or one, or whether its called CORS or UMP/CORS. I suspect implementers will move ahead if they think it's a good idea with a stable specification. For example, I don't think the number of documents used to specify the formerly more monolithic HTML5 has affected implementation plans. > 2) Browser vendors intend to implement CORS. They don't want to have two > similar but slightly different stacks for making requests, either in > implementation or in what's exposed to developers. So, having UMP as a > separate spec doesn't make sense if it's intended to be a subset (or even > mostly a subset) of CORS. Mozilla might be willing to implement UMP with > some API modifications and Microsoft hasn't voiced an opinion. > Is that an accurate summary? > Are there other advantages to keeping UMP a separate spec other than > concerns of ship dates? Given the lack of vendor support, it doesn't seem > like ship date is really a good argument since the ship date is dependent > on vendors actually implementing this. AFAICT, there is good implementer support for the technical features defined in UMP. Both Maciej and Anne indicated the features might be implemented, but under the name CORS rather than UMP. AFAICT, that constraint can be met by having CORS reference and extend UMP. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [IndexedDB] Granting storage quotas
On Wed, Apr 21, 2010 at 1:03 PM, Michael Nordman wrote: > > > On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement wrote: > >> FWIW, the "transient" vs. "permanent" storage support is exactly why I >> eagerly await an implementation of EricU's Filesystem API. Being able to >> guarantee that the UA will not discard potentially irreplaceable data is of >> paramount importance to web apps that want to work in an offline mode. >> >> I also find that the current arbitrary quota limit of 5MB per domain makes >> local storage APIs unusable for all but the most rudimentary apps (e.g., >> sticky note demo apps). There is an asymmetric distribution of local >> storage needs out there that no one is yet addressing (e.g., a photo- or >> video-related app might need GBs of local storage, an offline mail app might >> need tens or hundreds of MB, a TODO list app might only need kilobytes, >> etc.). >> > I wholeheartedly support any effort to coordinate quota management among >> all of the various local storage APIs. The issue of quota limits is >> something that browser vendors will need to address soon enough, and it's >> probably best left up to them. The need for "permanent" storage across all >> local storage APIs, though, is something that in my opinion should come out >> of the standardization process. >> > > Here's a stab at defining programming interfaces that make a distinction > between "transient" vs "permanent" for the storage mechanisms. If we make > additions like this, we should use the same terminology across the board. > > // WebSqlDBs, also could work for IndexedDBs > window.openDatabase(...); // temporary > window.openPermanentDatabase(...); > > // AppCaches, embellish the first line of the manifest file > CACHE MANIFEST > CACHE MANIFEST PERMANENT > > // FileSystem, see the draft, i've change the terms a little here > window.requestFilesystem(...);// evictable > window.requestPermanentFilesystem(...) > > // LocalStorage > window.localStorage;// purgeable > window.permanentLocalStorage; > I think Tab's right that permanent space should only be initiated based on user gesture, not by some JS API.
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 1:49 PM, Tyler Close wrote: > On Wed, Apr 21, 2010 at 1:29 PM, Ojan Vafai wrote: >> I've been watching the CORS/UMP debate from the sidelines. Here's how it >> looks to me: >> 1) UMP folk want to keep UMP a separate spec so that it can (theoretically) >> be easier to implement and ship sooner. > > We want to keep it a separate specification for two main reasons: > a) The simpler, shorter UMP spec is easier for web developers to > understand than a combined spec would be. > b) We believe there are significant technical issues with CORS that > should prevent it from being standardized in its current form. > > I suspect implementation of UMP features is independent of whether or > not there are two documents or one, or whether its called CORS or > UMP/CORS. I suspect implementers will move ahead if they think it's a > good idea with a stable specification. For example, I don't think the > number of documents used to specify the formerly more monolithic HTML5 > has affected implementation plans. > >> 2) Browser vendors intend to implement CORS. They don't want to have two >> similar but slightly different stacks for making requests, either in >> implementation or in what's exposed to developers. So, having UMP as a >> separate spec doesn't make sense if it's intended to be a subset (or even >> mostly a subset) of CORS. Mozilla might be willing to implement UMP with >> some API modifications and Microsoft hasn't voiced an opinion. >> Is that an accurate summary? >> Are there other advantages to keeping UMP a separate spec other than >> concerns of ship dates? Given the lack of vendor support, it doesn't seem >> like ship date is really a good argument since the ship date is dependent >> on vendors actually implementing this. > > AFAICT, there is good implementer support for the technical features > defined in UMP. Both Maciej and Anne indicated the features might be > implemented, but under the name CORS rather than UMP. AFAICT, that > constraint can be met by having CORS reference and extend UMP. > I believe UMP suffers from the perception that it is Yet Another Spec, as in some people will look at it and think "we're already doing CORS, why do we need to implement Yet Another Spec"? Whatever you can do to fix that impression will be in your interest. Similarly, if it is really your intent to stop CORS from getting implemented, you're going to have to sell that harder, because (to switch metaphors), if that ship hasn't already sailed, it is at least boarding. -- Dirk (Not speaking on behalf of the Chromium team)
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 2:43 PM, Dirk Pranke wrote: > Similarly, if it is really your intent to stop CORS from getting > implemented, you're going to have to sell that harder, because (to > switch metaphors), if that ship hasn't already sailed, it is at least > boarding. I'd like to check the status of this discussion with the WG. I believe I've made a strong case that using CORS in a natural way can result in CSRF-like (Confused Deputy) vulnerabilities. There are several ways in which the pattern can manifest, but one of the simplest is A makes a request to B and includes some of the received data in a subsequent request to C. If credentials are used, A is applying all of its authority to identifiers selected by B. If B might be an attacker, there's a Confused Deputy vulnerability. There's nothing C can do to detect the attack server-side. Do WG members understand and accept the above? My impression from the discussion is yes, but people think it's a problem for Web developers to deal with and CORS has no responsibility here. Is that accurate? If so, can I convince WG members that we have a responsibility to provide easy-to-use *and* safe APIs to Web developers? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: [IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)
On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta wrote: > > On Mar 15, 2010, at 10:45 AM, Jeremy Orlow wrote: > > On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow wrote: > >> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta wrote: >>> >>> On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: >>> >> 2) In the spec, dynamic transactions and the difference between static >>> and dynamic are not very well explained. >>> >>> >>> Can you propose spec text? >>> >> >> In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first >> paragraph, adding a sentence would probably be good enough. "If the scope >> is dynamic, the transaction may use any object stores or indexes in the >> database, but if another transaction touches any of the resources in a >> manner that could not be serialized by the implementation, a RECOVERABLE_ERR >> exception will be thrown on commit." maybe? >> > > By the way, are there strong use cases for Dynamic transactions? The more > that I think about them, the more out of place they seem. > > > Dynamic transactions are in common place use in server applications. It > follows naturally that client applications would want to use them. > There are a LOT of things that are common place in server applications that are not in v1 of IndexedDB. > Consider the use case where you want to view records in entityStore A, > while, at the same time, modifying another entityStore B using the records > in entityStore A. Unless you use dynamic transactions, you will not be able > to perform the two together. > ...unless you plan ahead. The only thing dynamic transactions buy you is not needing to plan ahead about using resources. > The dynamic transaction case is particularly important when dealing with > asynchronous update processing while keeping the UI updated with data. > > > > Background: Dynamic and static are the two types of transactions in the > IndexedDB spec. Static declare what resources they want access to before > they begin, which means that they can be implemented via objectStore level > locks. Dynamic decide at commit time whether the transaction was > serializable. This leaves implementations with two options: > > 1) Treat Dynamic transactions as "lock everything". > > > This is not consistent with the spec behavior. Locking everything is the > static global scope. > I don't understand what you're trying to say in the second sentence. And I don't understand how this is inconsistent with spec behavior--it's simply more conservative. > > > 2) Implement MVCC so that dynamic transactions can operate on > a consistent view of data. (At times, we'll know a transaction is doomed > long before commit, but we'll need to let it keep running since only > .commit() can raise the proper error.) > > Am I missing something here? > > > If we really expect UAs to implement MVCC (or something else along those > lines), I would expect other more advanced transaction concepts to be > exposed. If we expect most v1 implementations to just use objectStore locks > and thus use option 1, then is there any reason to include Dynamic > transactions? > > J > > Can you please respond to the rest? I really don't see the point of dynamic transactions for v1.
Re: [IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)
On Apr 21, 2010, at 5:11 PM, Jeremy Orlow wrote: > On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta wrote: > > On Mar 15, 2010, at 10:45 AM, Jeremy Orlow wrote: > >> On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow wrote: >> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta wrote: >> On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: >>> 2) In the spec, dynamic transactions and the difference between static and >>> dynamic are not very well explained. >> >> Can you propose spec text? >> >> In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first >> paragraph, adding a sentence would probably be good enough. "If the scope >> is dynamic, the transaction may use any object stores or indexes in the >> database, but if another transaction touches any of the resources in a >> manner that could not be serialized by the implementation, a RECOVERABLE_ERR >> exception will be thrown on commit." maybe? >> >> By the way, are there strong use cases for Dynamic transactions? The more >> that I think about them, the more out of place they seem. > > Dynamic transactions are in common place use in server applications. It > follows naturally that client applications would want to use them. > > There are a LOT of things that are common place in server applications that > are not in v1 of IndexedDB. > > Consider the use case where you want to view records in entityStore A, while, > at the same time, modifying another entityStore B using the records in > entityStore A. Unless you use dynamic transactions, you will not be able to > perform the two together. > > ...unless you plan ahead. The only thing dynamic transactions buy you is not > needing to plan ahead about using resources. And why would planning ahead be required? We don't require programmers using the IndexedDB or users of libraries built on IndexedDB to be capable of planning ahead, do we? > > The dynamic transaction case is particularly important when dealing with > asynchronous update processing while keeping the UI updated with data. > >> >> >> Background: Dynamic and static are the two types of transactions in the >> IndexedDB spec. Static declare what resources they want access to before >> they begin, which means that they can be implemented via objectStore level >> locks. Dynamic decide at commit time whether the transaction was >> serializable. This leaves implementations with two options: >> >> 1) Treat Dynamic transactions as "lock everything". > > This is not consistent with the spec behavior. Locking everything is the > static global scope. > > I don't understand what you're trying to say in the second sentence. And I > don't understand how this is inconsistent with spec behavior--it's simply > more conservative. If the spec requires three behaviors and you support two, that translates to non-compliance of the spec, in my dictionary. > > >> >> 2) Implement MVCC so that dynamic transactions can operate on a consistent >> view of data. (At times, we'll know a transaction is doomed long before >> commit, but we'll need to let it keep running since only .commit() can raise >> the proper error.) >> >> Am I missing something here? >> >> >> If we really expect UAs to implement MVCC (or something else along those >> lines), I would expect other more advanced transaction concepts to be >> exposed. If we expect most v1 implementations to just use objectStore locks >> and thus use option 1, then is there any reason to include Dynamic >> transactions? >> >> J > > Can you please respond to the rest? I really don't see the point of dynamic > transactions for v1.
Re: [IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)
On Wed, Apr 21, 2010 at 5:30 PM, Nikunj Mehta wrote: > > On Apr 21, 2010, at 5:11 PM, Jeremy Orlow wrote: > > On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta wrote: > >> >> On Mar 15, 2010, at 10:45 AM, Jeremy Orlow wrote: >> >> On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow wrote: >> >>> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta wrote: On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: >>> 2) In the spec, dynamic transactions and the difference between static and dynamic are not very well explained. Can you propose spec text? >>> >>> In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first >>> paragraph, adding a sentence would probably be good enough. "If the scope >>> is dynamic, the transaction may use any object stores or indexes in the >>> database, but if another transaction touches any of the resources in a >>> manner that could not be serialized by the implementation, a RECOVERABLE_ERR >>> exception will be thrown on commit." maybe? >>> >> >> By the way, are there strong use cases for Dynamic transactions? The more >> that I think about them, the more out of place they seem. >> >> >> Dynamic transactions are in common place use in server applications. It >> follows naturally that client applications would want to use them. >> > > There are a LOT of things that are common place in server applications that > are not in v1 of IndexedDB. > > >> Consider the use case where you want to view records in entityStore A, >> while, at the same time, modifying another entityStore B using the records >> in entityStore A. Unless you use dynamic transactions, you will not be able >> to perform the two together. >> > > ...unless you plan ahead. The only thing dynamic transactions buy you is > not needing to plan ahead about using resources. > > > And why would planning ahead be required? We don't require programmers > using the IndexedDB or users of libraries built on IndexedDB to be capable > of planning ahead, do we? > > > >> The dynamic transaction case is particularly important when dealing with >> asynchronous update processing while keeping the UI updated with data. >> >> >> >> Background: Dynamic and static are the two types of transactions in the >> IndexedDB spec. Static declare what resources they want access to before >> they begin, which means that they can be implemented via objectStore level >> locks. Dynamic decide at commit time whether the transaction was >> serializable. This leaves implementations with two options: >> >> 1) Treat Dynamic transactions as "lock everything". >> >> >> This is not consistent with the spec behavior. Locking everything is the >> static global scope. >> > > I don't understand what you're trying to say in the second sentence. And I > don't understand how this is inconsistent with spec behavior--it's simply > more conservative. > > > If the spec requires three behaviors and you support two, that translates > to non-compliance of the spec, in my dictionary. > > > >> >> >> 2) Implement MVCC so that dynamic transactions can operate on >> a consistent view of data. (At times, we'll know a transaction is doomed >> long before commit, but we'll need to let it keep running since only >> .commit() can raise the proper error.) >> >> Am I missing something here? >> >> Can you please respond to this? If you don't have a good answer, then I don't intend on implementing Dynamic transactions as specced because the feature would clearly not be worth the implementational effort. I would simply treat a dynamic transaction as a static one that wants to lock the world. It's completely possible that I'm missing something major here. But in order for me to know that, you'll need to explain it to me. Terse, sarcastic responses don't help anyone. > >> >> If we really expect UAs to implement MVCC (or something else along those >> lines), I would expect other more advanced transaction concepts to be >> exposed. If we expect most v1 implementations to just use objectStore locks >> and thus use option 1, then is there any reason to include Dynamic >> transactions? >> >> J >> >> Can you please respond to the rest? I really don't see the point of > dynamic transactions for v1. > > >
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: > I agree that "Anonymous" or "Anon" is more clear as to the purpose than > "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. > I understand why UMP uses that term but I don't think it will be obvious to > authors reading code. > > "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: I agree that "Anonymous" or "Anon" is more clear as to the purpose than "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. Your mail client automatically adds identifying info, as do any mail relays in the delivery path. If that were not the case, I would think it's fair to say the message is sent anonymously based on the envelope being anynymous. That's so even if the message contents include a claim or proof of your identity. I understand why UMP uses that term but I don't think it will be obvious to authors reading code. "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). I agree, but (a) that ship has sailed; and (b) dropping those from the name only in the anonymous/uniform/whatever version would probably be more confusing than helpful, at least if the API ends up being roughly similar. XMLHttpRequest has brand value, and it's worth building on author awareness even if the X and the H are more historical than meaningful at this point. Cheers, Maciej
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak wrote: > > On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: > > On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: > >> I agree that "Anonymous" or "Anon" is more clear as to the purpose than >> "Uniform". > > > In the same say this email is anonymous. Sure, I say it is from MarkM, but > my browser doesn't add any identifying info that you can see. Even if I > included MarkM's PGP signature, by your criteria, it would still be > anonymous. > > > Your mail client automatically adds identifying info, as do any mail relays > in the delivery path. If that were not the case, I would think it's fair to > say the message is sent anonymously based on the envelope being anynymous. > That's so even if the message contents include a claim or proof of your > identity. > Ok, so a request is non-anonymous if the identifying information is added by at least: 1) a browser (cookies, etc) 2) a mail client 3) any mail relays in the delivery path. What other software counts? Why does PGP not count? If the mail client in question is JavaScript running in a web page sending a uniform message, is it still non-anonymous? > > >> I understand why UMP uses that term but I don't think it will be obvious >> to authors reading code. >> >> > "XML" is also a misnomer. And "Http" is confusing as well, since these > requests can (and should) generally be carried over https. At least we agree > on "Request" ;). > > > I agree, but (a) that ship has sailed; and (b) dropping those from the name > only in the anonymous/uniform/whatever version would probably be more > confusing than helpful, at least if the API ends up being roughly similar. > XMLHttpRequest has brand value, and it's worth building on author awareness > even if the X and the H are more historical than meaningful at this point. > Funny, I don't recall anyone objecting that the proposed JSONRequest should have been called JSONXmlHttpRequest. I also don't recall anyone suggesting that Microsoft rename XDomainRequest to XDomainXmlHttpRequest. Surely the same argument holds for these? > > Cheers, > Maciej > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 7:09 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 6:45 PM, Maciej Stachowiak wrote: On Apr 21, 2010, at 6:23 PM, Mark S. Miller wrote: On Wed, Apr 21, 2010 at 12:24 PM, Maciej Stachowiak wrote: I agree that "Anonymous" or "Anon" is more clear as to the purpose than "Uniform". In the same say this email is anonymous. Sure, I say it is from MarkM, but my browser doesn't add any identifying info that you can see. Even if I included MarkM's PGP signature, by your criteria, it would still be anonymous. Your mail client automatically adds identifying info, as do any mail relays in the delivery path. If that were not the case, I would think it's fair to say the message is sent anonymously based on the envelope being anynymous. That's so even if the message contents include a claim or proof of your identity. Ok, so a request is non-anonymous if the identifying information is added by at least: 1) a browser (cookies, etc) 2) a mail client 3) any mail relays in the delivery path. What other software counts? Why does PGP not count? If the mail client in question is JavaScript running in a web page sending a uniform message, is it still non-anonymous? I'm not trying to draw a bright line here between categories of software, rather I am looking into the reason this proposed API would exist. The purpose is to avoid passively including any credentials that would identify the user, identify the requesting site, or otherwise convey ambient authority. Right? So what's a good word to express that? Maybe "Anonymous" is not the best word to capture that concept, but "Uniform" does not seem to capture it either. I don't think most people would make the leap that "Uniform" means, "please, browser, don't add any credentials". Whereas I think "Anonymous" does convey that intent. There may be an even better words, but I think "Anonymous" is a really good fit. Consider Tor. Tor calls itself "a distributed, anonymous network", and most would agree that is a fair label. However, no one assumes that Tor will prevent you from typing your real name or other indentifying information into a Web page, or stop you from uploading a file that includes a PGP signature. What it does try to do is ensure that such information is not conveyed to anyone passively. That seems to match the intent of UMP (and the UMP-like subset of CORS) - no identifying information is passively added, but the sender is free to explicitly add it themselves. I understand why UMP uses that term but I don't think it will be obvious to authors reading code. "XML" is also a misnomer. And "Http" is confusing as well, since these requests can (and should) generally be carried over https. At least we agree on "Request" ;). I agree, but (a) that ship has sailed; and (b) dropping those from the name only in the anonymous/uniform/whatever version would probably be more confusing than helpful, at least if the API ends up being roughly similar. XMLHttpRequest has brand value, and it's worth building on author awareness even if the X and the H are more historical than meaningful at this point. Funny, I don't recall anyone objecting that the proposed JSONRequest should have been called JSONXmlHttpRequest. I also don't recall anyone suggesting that Microsoft rename XDomainRequest to XDomainXmlHttpRequest. Surely the same argument holds for these? This Working Group also did not agree to standardize those APIs, though both were proposed. We have no say in what names third parties use in nonstandard APIs. In addition, they both of these APIs gratuitously different from XMLHttpRequest in ways other than security policy. I would suggest that we not do that with the proposed new constructor. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Wed, Apr 21, 2010 at 7:40 PM, Maciej Stachowiak wrote: > I'm not trying to draw a bright line here between categories of software, > rather I am looking into the reason this proposed API would exist. The > purpose is to avoid passively including any credentials that would identify > the user, identify the requesting site, or otherwise convey ambient > authority. Right? So what's a good word to express that? Maybe "Anonymous" > is not the best word to capture that concept, but "Uniform" does not seem to > capture it either. I don't think most people would make the leap that > "Uniform" means, "please, browser, don't add any credentials". Whereas I > think "Anonymous" does convey that intent. There may be an even better > words, but I think "Anonymous" is a really good fit. > > Consider Tor. Tor calls itself "a distributed, anonymous network", and most > would agree that is a fair label. However, no one assumes that Tor will > prevent you from typing your real name or other indentifying information > into a Web page, or stop you from uploading a file that includes a PGP > signature. What it does try to do is ensure that such information is not > conveyed to anyone passively. That seems to match the intent of UMP (and the > UMP-like subset of CORS) - no identifying information is passively added, > but the sender is free to explicitly add it themselves. > > Thanks, the Tor example is clarifying. Tor attempts to actually provide anonymity, by attempting to hide all information that might be inadvertently identifying, like IP address, traffic patterns, or other side channels. The threat model includes an attacker that may be trying to identify the user despite the absence of any purposely included identifying information. UniformRequests provide no such protection, and so should not seem to promise such. Since authorizing decisions only rely on overt information, prevention of CSRF-like vulnerabilities need only be concerned about overt information. Suppressing side channels is *much* harder. Q: "I sent my messages using AnonXmlHttpRequest. How did the secret police know I was a dissident?" A: "The name 'AnonXmlHttpRequest' was chosen to clarify the security property it provides: absence of CSRF-like vulnerabilities. Why did you think it provided anonymity?" > This Working Group also did not agree to standardize [JSONRequest and XDR], > though both were proposed. We have no say in what names third parties use in > nonstandard APIs. > > In addition, they both of these APIs gratuitously different from > XMLHttpRequest in ways other than security policy. I would suggest that we > not do that with the proposed new constructor. > On that we agree. > > > Regards, > Maciej > > > > -- Cheers, --MarkM
Re: UMP / CORS: Implementor Interest
Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Adam On Wed, Apr 21, 2010 at 8:29 PM, Mark S. Miller wrote: > On Wed, Apr 21, 2010 at 7:40 PM, Maciej Stachowiak wrote: >> >> I'm not trying to draw a bright line here between categories of software, >> rather I am looking into the reason this proposed API would exist. The >> purpose is to avoid passively including any credentials that would identify >> the user, identify the requesting site, or otherwise convey ambient >> authority. Right? So what's a good word to express that? Maybe "Anonymous" >> is not the best word to capture that concept, but "Uniform" does not seem to >> capture it either. I don't think most people would make the leap that >> "Uniform" means, "please, browser, don't add any credentials". Whereas I >> think "Anonymous" does convey that intent. There may be an even better >> words, but I think "Anonymous" is a really good fit. >> Consider Tor. Tor calls itself "a distributed, anonymous network", and >> most would agree that is a fair label. However, no one assumes that Tor will >> prevent you from typing your real name or other indentifying information >> into a Web page, or stop you from uploading a file that includes a PGP >> signature. What it does try to do is ensure that such information is not >> conveyed to anyone passively. That seems to match the intent of UMP (and the >> UMP-like subset of CORS) - no identifying information is passively added, >> but the sender is free to explicitly add it themselves. > > Thanks, the Tor example is clarifying. Tor attempts to actually provide > anonymity, by attempting to hide all information that might be inadvertently > identifying, like IP address, traffic patterns, or other side channels. The > threat model includes an attacker that may be trying to identify the user > despite the absence of any purposely included identifying information. > UniformRequests provide no such protection, and so should not seem to > promise such. Since authorizing decisions only rely on overt information, > prevention of CSRF-like vulnerabilities need only be concerned about overt > information. Suppressing side channels is *much* harder. > Q: "I sent my messages using AnonXmlHttpRequest. How did the secret police > know I was a dissident?" > A: "The name 'AnonXmlHttpRequest' was chosen to clarify the security > property it provides: absence of CSRF-like vulnerabilities. Why did you > think it provided anonymity?" > > >> >> This Working Group also did not agree to standardize [JSONRequest and >> XDR], though both were proposed. We have no say in what names third parties >> use in nonstandard APIs. >> In addition, they both of these APIs gratuitously different from >> XMLHttpRequest in ways other than security policy. I would suggest that we >> not do that with the proposed new constructor. > > On that we agree. > >> >> Regards, >> Maciej >> >> > > > > -- > Cheers, > --MarkM >
Re: UMP / CORS: Implementor Interest
On Thu, 22 Apr 2010 14:36:50 +0900, Adam Barth wrote: Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Simon suggested XMLHttpRequestNoContext in #whatwg. Seems relatively clear and works nicely with indexes and autocomplete. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)
On Apr 21, 2010, at 5:11 PM, Jeremy Orlow wrote: > On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta wrote: > > On Mar 15, 2010, at 10:45 AM, Jeremy Orlow wrote: > >> On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow wrote: >> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta wrote: >> On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: >>> 2) In the spec, dynamic transactions and the difference between static and >>> dynamic are not very well explained. >> >> Can you propose spec text? >> >> In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first >> paragraph, adding a sentence would probably be good enough. "If the scope >> is dynamic, the transaction may use any object stores or indexes in the >> database, but if another transaction touches any of the resources in a >> manner that could not be serialized by the implementation, a RECOVERABLE_ERR >> exception will be thrown on commit." maybe? >> >> By the way, are there strong use cases for Dynamic transactions? The more >> that I think about them, the more out of place they seem. > > Dynamic transactions are in common place use in server applications. It > follows naturally that client applications would want to use them. > > There are a LOT of things that are common place in server applications that > are not in v1 of IndexedDB. > > Consider the use case where you want to view records in entityStore A, while, > at the same time, modifying another entityStore B using the records in > entityStore A. Unless you use dynamic transactions, you will not be able to > perform the two together. > > ...unless you plan ahead. The only thing dynamic transactions buy you is not > needing to plan ahead about using resources. > > The dynamic transaction case is particularly important when dealing with > asynchronous update processing while keeping the UI updated with data. > >> >> >> Background: Dynamic and static are the two types of transactions in the >> IndexedDB spec. Static declare what resources they want access to before >> they begin, which means that they can be implemented via objectStore level >> locks. Dynamic decide at commit time whether the transaction was >> serializable. This leaves implementations with two options: >> >> 1) Treat Dynamic transactions as "lock everything". > > This is not consistent with the spec behavior. Locking everything is the > static global scope. > > I don't understand what you're trying to say in the second sentence. And I > don't understand how this is inconsistent with spec behavior--it's simply > more conservative. > > >> >> 2) Implement MVCC so that dynamic transactions can operate on a consistent >> view of data. (At times, we'll know a transaction is doomed long before >> commit, but we'll need to let it keep running since only .commit() can raise >> the proper error.) MVCC is not required for dynamic transactions. MVCC is only required to open a database in the DETACHED_READ mode. Since locks are acquired in the order in which they are requested, a failure could occur when an object store is being opened, but it is locked by another transaction. One doesn't have to wait until commit is invoked. >> >> Am I missing something here? >> >> >> If we really expect UAs to implement MVCC (or something else along those >> lines), I would expect other more advanced transaction concepts to be >> exposed. What precisely are you referring to? Why are these other more advanced transaction concepts required? >> If we expect most v1 implementations to just use objectStore locks and thus >> use option 1, then is there any reason to include Dynamic transactions? Why do you conclude that most implementations just use object store locks? >> >> J > > Can you please respond to the rest? I really don't see the point of dynamic > transactions for v1. There has been previous discussions on this DL about the need for dynamic locking [1], MVCC [2] and incremental locking [3] . Did you have anything new to add to that discussion? [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0197.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0322.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1080.html
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 11:11 PM, Anne van Kesteren wrote: On Thu, 22 Apr 2010 14:36:50 +0900, Adam Barth wrote: Unfortunately "ambient" doesn't have any good antonyms: http://www.synonym.com/antonym/ambient/ Simon suggested XMLHttpRequestNoContext in #whatwg. Seems relatively clear and works nicely with indexes and autocomplete. Other ideas (also suffix variants instead of prefix variants): - GuestXMLHttpRequest Suggested by Mark originally. We now envision more use cases than guest code, however, "guest" is also the traditional name for an unprivileged account. - UnprivilegedXMLHttpRequest (or abbreviate to NoPrivs) - NoAuthorityXMLHttpRequest (or abbreviate to NoAuth, though that may seem like "no authentication") - NoCredentialsXMLHttpRequest (or abbreviate to NoCred) Can anyone else think of ideas? I tried to mentally fill in sentences like, "I don't want to do this as root, I want to use a/an ___ account" or "I don't want to be logged into site X, I want to be when I visit it." Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Apr 21, 2010, at 8:29 PM, Mark S. Miller wrote: Thanks, the Tor example is clarifying. Tor attempts to actually provide anonymity, by attempting to hide all information that might be inadvertently identifying, like IP address, traffic patterns, or other side channels. The threat model includes an attacker that may be trying to identify the user despite the absence of any purposely included identifying information. UniformRequests provide no such protection, and so should not seem to promise such. Since authorizing decisions only rely on overt information, prevention of CSRF-like vulnerabilities need only be concerned about overt information. Suppressing side channels is *much* harder. Considering the Tor example, would you agree that the possibility of explicitly including identifying information in message content does not invalidate the term "anonymous"? Side channels are an interesting issue, but separate from the original issue you raised of explicitly added identifying information. I tend to think that side channels also do not disqualify the word "anonymous". For example, it's common (or at least stereotypical) for employers or public places of business to have an "anonymous comment box". However, typically when someone leaves a comment their fingerprints will be all over the piece of paper, so in theory it could be traced back to them. But we don't generally think this invalidates the use of the word "anonymous". Similarly, it's common for blogs to allow anonymous comments (although some make a point of explicitly saying that they "don't allow anonymous comments", in almost those exact words). But "anonymous" comment systems take no measures to hide side-channel fingerprints, such as the IP address from which the commenter is posting. Thus, I conclude that in normal use and even in the context of information technology, the common meaning of the term anonymous can be applied to systems that do not prevent identification through side channels. I think this addresses both of your objections so far to the term "Anonymous". That being said, I'm totally open to a name that conveys the same meaning with less perceived ambiguity. I just don't think "Uniform" is it. It doesn't get across the main idea very well at all. We need a phrase that says "the browser won't automatically add any credentials, identifying information or ambient authority". Regards, Maciej
