Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
* Tab Atkins Jr. wrote:
>Please correct me if I'm missing something, but I don't see any new
>privacy-leak vectors here. Without Shared Workers, 3rdparty.com can
>just hold open a communication channel to its server and shuttle
>information between the iframes on A.com and B.com that way.
That does not seem to be the right way to think about privacy problems.
We know that you "can", in some sense, create cookies that are difficult
to delete through conventional means, like "Evercookie" does, but that's
not really relevant when discussing adding a .cookieLifetime("long") me-
thod that does the same things. For one thing, the former method relies
on very many old and complicated methods with known design flaws, the
other would be a new feature that accomplishes this easily by design.
(You would also seem to be mistaken; holding a connection does not help
if the two iframes cannot share the connection, and traditionally they
cannot do that reliably; the problem is rather a matter of one iframe
generating or obtaining a secret and getting the other iframe to learn
that same secret. As has been noted in the thread, that is possible to
some degree, but that is not much of a metric to judge a design.)
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
RE: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
As we reviewed the actions we [the UA] could take in a variety of scenarios, tying the connect-ability to the top-level domain was the most predictable for web authors. IE9's privacy feature [1] blocks network requests to any domain on a user's "filter list" (Tracking Protection List) when the request is not from a top-level domain (e.g., "first party" domain). In the scenario we're concerned with (involving iframes), having multiple top-level domains involved with a privacy decision (due to shared workers) either interferes with the predictability of the API, or curtails the user's privacy (both of which are bad enough consequences that we cannot implement the spec as-is). Note that our proposed change (to associated shared worker connect-ability to the top-level domain) deliberately breaks scenarios where sub-frame components want to establish and share a connection. As Ian described, if this is a specific desired scenario for shared workers, we would also recommend a more formalized cross-origin shared worker model: On Wed 4/20/2011 9:08 PM, Ian Hickson wrote: >> FWIW, on the long term, I intend to add a feature wherein a page can open a >> shared worker cross-origin >> (assuming the other origin agrees) >>directly, without having to use >> iframes. There's a whole host of >> features that such a mechanism would enable which currently have to be done >> using the awkward iframe >> mechanism you describe. [1] http://blogs.msdn.com/b/ie/archive/2010/12/07/ie9-and-privacy-introducing-tracking-protection-v8.aspx -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, April 20, 2011 6:55 PM To: Andrew Wilson Cc: Tab Atkins Jr.; Travis Leithead; Arthur Barstow; public-webapps-requ...@w3.org; Adrian Bateman; public-webapps Subject: Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21 On Wed, Apr 20, 2011 at 5:58 PM, Andrew Wilson wrote: > On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking wrote: >> That's why we're working on trying to fix fingerprinting. >> >> The point is that privacy is something that we're all working on >> trying to improve (right?), and the WebWorkers spec needs to be >> changed to aid with that. As far as I can see all that's needed is to >> say that a UA is allowed to not share a worker, and ideally point out >> that such sharing could be disabled when the frame-parent chain >> contains cross origin iframes. > > Thanks for the clarification, Jonas. So I'm concerned that a blanket > prohibition would break legitimate use cases (iframe-based widgets on > a page communicating with one another). Let's say we have the following: > Top Level Window - http://a.com > Iframe_one - http://b.com > iframe_two - http://b.com > Top Level Window - http://c.com > iframe_three - http://b.com > If iframe_one, two, and three all create the same shared worker, would > any sharing be allowed in the situation you propose? I would at least > want iframe_one and iframe_two to end up referencing a common > instance, even if privacy policy caused iframe_three to get a separate > instance because the top-level window was pointed at c.com instead of a.com. > This seems reasonable to me - I suspect that's what you (and Travis) > were suggesting, but I wasn't positive. Yes, on the surface it seems to me that this would be ok. Though given that it's a more complex solution than a simple blanket prohibition any time cross-site frames are involved, it's possible that I'm missing some privacy leak vector. / Jonas
RE: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, 20 Apr 2011, Travis Leithead wrote: > > We are concerned about the privacy implications we discovered when > reviewing the current web workers editor's draft in its treatment of > shared workers [1]. Specifically, the spec as currently written allows > for 3rd party content to use shared workers to connect and share > (broker) information between top-level domains as well as make resource > requests on behalf of all connections. For example, a user may visit a > site "A.com" which hosts a 3rd party iframe of domain "3rdParty.com" > which initially creates a shared worker. Then, the user (from a > different page/window) opens a web site "B.com" which also hosts a 3rd > party iframe of domain "3rdParty.com", which (per the spec text below, > and as confirmed several browser's implementations) should be able to > connect to the same shared worker. The end user only sees domains > "A.com" and "B.com" in his or her browser window What sites the user sees in his or her browser window depends entirely on the browser vendor's decisions here, it's a UI issue. There's no reason 3rdparty.com couldn't appear as well. Similarly, whether the same shared worker can actually be obtained by two unrelated iframes is also a decision the user agent has to make. FWIW, on the long term, I intend to add a feature wherein a page can open a shared worker cross-origin (assuming the other origin agrees) directly, without having to use iframes. There's a whole host of features that such a mechanism would enable which currently have to be done using the awkward iframe mechanism you describe. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On 4/20/11 6:57 PM, Tab Atkins Jr. wrote: True, you need some side-channel to link the two iframes for a particular client. You can use something simple like one of the *other* within-domain communication mediums (cookies, localStorage, etc.) Which is why there are options to restrict third-party cookies; I believe there are proposals to apply those to localStorage and the like as well. We already know that you can fingerprint a larger percentage of users Which is why some UA vendors are actively trying to reduce the fingerprintable bits of their UAs that they expose to page JS. In other words, these are problems we're trying to solve. Adding to the list of problems seems counterproductive here. -Boris
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On 4/20/11 3:54 PM, Tab Atkins Jr. wrote: Please correct me if I'm missing something, but I don't see any new privacy-leak vectors here. Without Shared Workers, 3rdparty.com can just hold open a communication channel to its server Unless you have a firewall or proxy that prevents that particular site (via blacklist or whitelist) from doing that. Or unless you have a browser extension that prevents such things. So shared workers are in fact adding a new vector: browser extensions will need to be changed to handle them, and they can't be dealt with at all via wirewalls or proxies. -Boris
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 5:58 PM, Andrew Wilson wrote: > On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking wrote: >> That's why we're working on trying to fix fingerprinting. >> >> The point is that privacy is something that we're all working on >> trying to improve (right?), and the WebWorkers spec needs to be >> changed to aid with that. As far as I can see all that's needed is to >> say that a UA is allowed to not share a worker, and ideally point out >> that such sharing could be disabled when the frame-parent chain >> contains cross origin iframes. > > Thanks for the clarification, Jonas. So I'm concerned that a blanket > prohibition would break legitimate use cases (iframe-based widgets on a page > communicating with one another). Let's say we have the following: > Top Level Window - http://a.com > Iframe_one - http://b.com > iframe_two - http://b.com > Top Level Window - http://c.com > iframe_three - http://b.com > If iframe_one, two, and three all create the same shared worker, would any > sharing be allowed in the situation you propose? I would at least want > iframe_one and iframe_two to end up referencing a common instance, even if > privacy policy caused iframe_three to get a separate instance because the > top-level window was pointed at c.com instead of a.com. > This seems reasonable to me - I suspect that's what you (and Travis) were > suggesting, but I wasn't positive. Yes, on the surface it seems to me that this would be ok. Though given that it's a more complex solution than a simple blanket prohibition any time cross-site frames are involved, it's possible that I'm missing some privacy leak vector. / Jonas
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking wrote: > > > That's why we're working on trying to fix fingerprinting. > > The point is that privacy is something that we're all working on > trying to improve (right?), and the WebWorkers spec needs to be > changed to aid with that. As far as I can see all that's needed is to > say that a UA is allowed to not share a worker, and ideally point out > that such sharing could be disabled when the frame-parent chain > contains cross origin iframes. > Thanks for the clarification, Jonas. So I'm concerned that a blanket prohibition would break legitimate use cases (iframe-based widgets on a page communicating with one another). Let's say we have the following: Top Level Window - http://a.com Iframe_one - http://b.com iframe_two - http://b.com Top Level Window - http://c.com iframe_three - http://b.com If iframe_one, two, and three all create the same shared worker, would any sharing be allowed in the situation you propose? I would at least want iframe_one and iframe_two to end up referencing a common instance, even if privacy policy caused iframe_three to get a separate instance because the top-level window was pointed at c.com instead of a.com. This seems reasonable to me - I suspect that's what you (and Travis) were suggesting, but I wasn't positive.
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 3:57 PM, Tab Atkins Jr. wrote: > On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking wrote: >> On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. wrote: >>> On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking wrote: On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. wrote: > Please correct me if I'm missing something, but I don't see any new > privacy-leak vectors here. Without Shared Workers, 3rdparty.com can > just hold open a communication channel to its server and shuttle > information between the iframes on A.com and B.com that way. Not if the user disables third-party cookies (or cookies completely), right? >>> >>> No, what I described is independent of cookies. You just have to use >>> basic long-polling techniques, so the iframe on A.com sends a message >>> to the server, and the server then passes that message to the iframe >>> on B.com. >> >> But how does the server know to pair the two incoming connections and >> forward data between them? If 50 users visit these sites, all the >> server sees is 100 incoming connections with no idea which are coming >> from the same user. > > True, you need some side-channel to link the two iframes for a > particular client. You can use something simple like one of the > *other* within-domain communication mediums (cookies, localStorage, > etc.) to share a uniqueid, Yes, that's why those features needs to be similarly isolated when 3rd party cookies are disabled to be truly effective. > or you can just pull information out of the > client, which the two windows are likely to share, and use that as the > identifier. We already know that you can fingerprint a larger > percentage of users with only a handful of information sources > available to JS. That's why we're working on trying to fix fingerprinting. The point is that privacy is something that we're all working on trying to improve (right?), and the WebWorkers spec needs to be changed to aid with that. As far as I can see all that's needed is to say that a UA is allowed to not share a worker, and ideally point out that such sharing could be disabled when the frame-parent chain contains cross origin iframes. Which reminds me that I need to add a similar note to IndexedDB. Firefox 4 completely disables use of IndexedDB in iframes which has cross origin frame ancestors. I know we talked about this with the chrome folks, but I don't remember what they ended up doing in this regard. / Jonas
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking wrote: > On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. wrote: >> On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking wrote: >>> On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. >>> wrote: Please correct me if I'm missing something, but I don't see any new privacy-leak vectors here. Without Shared Workers, 3rdparty.com can just hold open a communication channel to its server and shuttle information between the iframes on A.com and B.com that way. >>> >>> Not if the user disables third-party cookies (or cookies completely), right? >> >> No, what I described is independent of cookies. You just have to use >> basic long-polling techniques, so the iframe on A.com sends a message >> to the server, and the server then passes that message to the iframe >> on B.com. > > But how does the server know to pair the two incoming connections and > forward data between them? If 50 users visit these sites, all the > server sees is 100 incoming connections with no idea which are coming > from the same user. True, you need some side-channel to link the two iframes for a particular client. You can use something simple like one of the *other* within-domain communication mediums (cookies, localStorage, etc.) to share a uniqueid, or you can just pull information out of the client, which the two windows are likely to share, and use that as the identifier. We already know that you can fingerprint a larger percentage of users with only a handful of information sources available to JS. ~TJ
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. wrote: > On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking wrote: >> On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. >> wrote: >>> Please correct me if I'm missing something, but I don't see any new >>> privacy-leak vectors here. Without Shared Workers, 3rdparty.com can >>> just hold open a communication channel to its server and shuttle >>> information between the iframes on A.com and B.com that way. >> >> Not if the user disables third-party cookies (or cookies completely), right? > > No, what I described is independent of cookies. You just have to use > basic long-polling techniques, so the iframe on A.com sends a message > to the server, and the server then passes that message to the iframe > on B.com. But how does the server know to pair the two incoming connections and forward data between them? If 50 users visit these sites, all the server sees is 100 incoming connections with no idea which are coming from the same user. / Jonas
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking wrote: > On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. wrote: >> Please correct me if I'm missing something, but I don't see any new >> privacy-leak vectors here. Without Shared Workers, 3rdparty.com can >> just hold open a communication channel to its server and shuttle >> information between the iframes on A.com and B.com that way. > > Not if the user disables third-party cookies (or cookies completely), right? No, what I described is independent of cookies. You just have to use basic long-polling techniques, so the iframe on A.com sends a message to the server, and the server then passes that message to the iframe on B.com. As Drew mentions, cookies are another way to pass this information around, as are multiple other shared-in-a-domain information sources. ~TJ
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. wrote: > On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead > wrote: >> (This time before the deadline :) >> >> Microsoft has the following additional feedback for this Last Call of Web >> Workers. >> >> We are concerned about the privacy implications we discovered when reviewing >> the current web workers editor's draft in its treatment of shared workers >> [1]. Specifically, the spec as currently written allows for 3rd party >> content to use shared workers to connect and share (broker) information >> between top-level domains as well as make resource requests on behalf of all >> connections. For example, a user may visit a site "A.com" which hosts a 3rd >> party iframe of domain "3rdParty.com" which initially creates a shared >> worker. Then, the user (from a different page/window) opens a web site >> "B.com" which also hosts a 3rd party iframe of domain "3rdParty.com", which >> (per the spec text below, and as confirmed several browser's >> implementations) should be able to connect to the same shared worker. The >> end user only sees domains "A.com" and "B.com" in his or her browser window, >> but can have information collected about those pages by way of the third >> party connected shared worker. >> >> Here's the relevant spec text: >> >> SharedWorker constructor steps: >> 7.5. "If name is not the empty string and there exists a >> SharedWorkerGlobalScope object whose closing flag is false, whose name >> attribute is exactly equal to name, and whose location attribute represents >> an absolute URL with the same origin as scriptURL, then let worker global >> scope be that SharedWorkerGlobalScope object." >> >> Given our current position on privacy and privacy technologies in IE9 [2], >> we will not be able to implement shared workers as described above. >> >> We believe it is appropriate to limit the scenarios in which connections to >> existing shared workers are allowed. We propose that connections should only >> be established to existing shared workers when *top-level* domains match >> (rather than when the "location attribute represents an absolute URL with >> the same origin as scriptURL). By limiting sharing to top-level domains, >> privacy decisions can be made on behalf of the top-level page (from the >> user's point of view) with scoped impact to the functionality of the 3rd >> party iframe. >> >> [1] >> http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface >> [2] http://www.w3.org/2011/track-privacy/papers/microsoft-bateman.pdf > > Please correct me if I'm missing something, but I don't see any new > privacy-leak vectors here. Without Shared Workers, 3rdparty.com can > just hold open a communication channel to its server and shuttle > information between the iframes on A.com and B.com that way. Not if the user disables third-party cookies (or cookies completely), right? / Jonas
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. wrote: > > Please correct me if I'm missing something, but I don't see any new > privacy-leak vectors here. Without Shared Workers, 3rdparty.com can > just hold open a communication channel to its server and shuttle > information between the iframes on A.com and B.com that way. Agreed. Even in the absence of a server, wouldn't those iframes also be able to communicate via cookies, or localStorage, or any other common data shared across the domain? I'd be curious about what specific privacy violations this enables that couldn't already be done in other ways that IE9 does support? Also, the PDF you link to describes a DoNotTrack HTTP header/DOM attribute and a filter list for preventing network access to specific domains - I'm not certain how either of those pertain to this issue (other than the fact that said filter lists would equally apply to network connections used from worker context). Can you provide some clarification of your concerns?
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead wrote: > (This time before the deadline :) > > Microsoft has the following additional feedback for this Last Call of Web > Workers. > > We are concerned about the privacy implications we discovered when reviewing > the current web workers editor's draft in its treatment of shared workers > [1]. Specifically, the spec as currently written allows for 3rd party content > to use shared workers to connect and share (broker) information between > top-level domains as well as make resource requests on behalf of all > connections. For example, a user may visit a site "A.com" which hosts a 3rd > party iframe of domain "3rdParty.com" which initially creates a shared > worker. Then, the user (from a different page/window) opens a web site > "B.com" which also hosts a 3rd party iframe of domain "3rdParty.com", which > (per the spec text below, and as confirmed several browser's implementations) > should be able to connect to the same shared worker. The end user only sees > domains "A.com" and "B.com" in his or her browser window, but can have > information collected about those pages by way of the third party connected > shared worker. > > Here's the relevant spec text: > > SharedWorker constructor steps: > 7.5. "If name is not the empty string and there exists a > SharedWorkerGlobalScope object whose closing flag is false, whose name > attribute is exactly equal to name, and whose location attribute represents > an absolute URL with the same origin as scriptURL, then let worker global > scope be that SharedWorkerGlobalScope object." > > Given our current position on privacy and privacy technologies in IE9 [2], we > will not be able to implement shared workers as described above. > > We believe it is appropriate to limit the scenarios in which connections to > existing shared workers are allowed. We propose that connections should only > be established to existing shared workers when *top-level* domains match > (rather than when the "location attribute represents an absolute URL with the > same origin as scriptURL). By limiting sharing to top-level domains, privacy > decisions can be made on behalf of the top-level page (from the user's point > of view) with scoped impact to the functionality of the 3rd party iframe. > > [1] > http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface > [2] http://www.w3.org/2011/track-privacy/papers/microsoft-bateman.pdf Please correct me if I'm missing something, but I don't see any new privacy-leak vectors here. Without Shared Workers, 3rdparty.com can just hold open a communication channel to its server and shuttle information between the iframes on A.com and B.com that way. ~TJ
RE: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
(This time before the deadline :) Microsoft has the following additional feedback for this Last Call of Web Workers. We are concerned about the privacy implications we discovered when reviewing the current web workers editor's draft in its treatment of shared workers [1]. Specifically, the spec as currently written allows for 3rd party content to use shared workers to connect and share (broker) information between top-level domains as well as make resource requests on behalf of all connections. For example, a user may visit a site "A.com" which hosts a 3rd party iframe of domain "3rdParty.com" which initially creates a shared worker. Then, the user (from a different page/window) opens a web site "B.com" which also hosts a 3rd party iframe of domain "3rdParty.com", which (per the spec text below, and as confirmed several browser's implementations) should be able to connect to the same shared worker. The end user only sees domains "A.com" and "B.com" in his or her browser window, but can have information collected about those pages by way of the third party connected shared worker. Here's the relevant spec text: SharedWorker constructor steps: 7.5. "If name is not the empty string and there exists a SharedWorkerGlobalScope object whose closing flag is false, whose name attribute is exactly equal to name, and whose location attribute represents an absolute URL with the same origin as scriptURL, then let worker global scope be that SharedWorkerGlobalScope object." Given our current position on privacy and privacy technologies in IE9 [2], we will not be able to implement shared workers as described above. We believe it is appropriate to limit the scenarios in which connections to existing shared workers are allowed. We propose that connections should only be established to existing shared workers when *top-level* domains match (rather than when the "location attribute represents an absolute URL with the same origin as scriptURL). By limiting sharing to top-level domains, privacy decisions can be made on behalf of the top-level page (from the user's point of view) with scoped impact to the functionality of the 3rd party iframe. [1] http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface [2] http://www.w3.org/2011/track-privacy/papers/microsoft-bateman.pdf -Travis -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Thursday, April 14, 2011 5:42 PM To: ext Jonas Sicking Cc: public-webapps Subject: Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21 On Apr/14/2011 6:39 PM, ext Jonas Sicking wrote: > On Thu, Apr 14, 2011 at 7:31 AM, Arthur Barstow wrote: >> This is a Request for Comments for the March 10 Last Call Working >> Draft of Web Workers: >> >> http://www.w3.org/TR/2011/WD-workers-20110310/ >> >> If you have any comments, please send them to the following list by >> 21 April >> 2011 at the latest: > There are currently two bugs filed against the spec. Do these bugs > count as last call comments? > > http://bit.ly/fl2uSB > Yes, I think both of these bugs should be considered LC comments. (Bug 12067 was submitted between the Feb 12 "is Workers ready for LC?" query [1] and the Feb 28 CfC to publish the LC [2]. As such, it probably should have been considered before publishing the LC.) On March 9, Adrian submitted comments after the CfC closed and those comments should also be considered LC comments: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0877.html -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0536.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0696.html
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Apr/14/2011 6:39 PM, ext Jonas Sicking wrote: On Thu, Apr 14, 2011 at 7:31 AM, Arthur Barstow wrote: This is a Request for Comments for the March 10 Last Call Working Draft of Web Workers: http://www.w3.org/TR/2011/WD-workers-20110310/ If you have any comments, please send them to the following list by 21 April 2011 at the latest: There are currently two bugs filed against the spec. Do these bugs count as last call comments? http://bit.ly/fl2uSB Yes, I think both of these bugs should be considered LC comments. (Bug 12067 was submitted between the Feb 12 "is Workers ready for LC?" query [1] and the Feb 28 CfC to publish the LC [2]. As such, it probably should have been considered before publishing the LC.) On March 9, Adrian submitted comments after the CfC closed and those comments should also be considered LC comments: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0877.html -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0536.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0696.html
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Thu, Apr 14, 2011 at 7:31 AM, Arthur Barstow wrote: > This is a Request for Comments for the March 10 Last Call Working Draft of > Web Workers: > > http://www.w3.org/TR/2011/WD-workers-20110310/ > > If you have any comments, please send them to the following list by 21 April > 2011 at the latest: There are currently two bugs filed against the spec. Do these bugs count as last call comments? http://bit.ly/fl2uSB / Jonas
Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
Original Message Subject:RfC: Last Call Working Draft of Web Workers; deadline April 21 Resent-Date:Fri, 11 Mar 2011 00:37:17 + Resent-From: Date: Thu, 10 Mar 2011 19:34:33 -0500 From: ext Arthur Barstow To: public-webapps This is a Request for Comments for the March 10 Last Call Working Draft of Web Workers: http://www.w3.org/TR/2011/WD-workers-20110310/ If you have any comments, please send them to the following list by 21 April 2011 at the latest: public-webapps@w3.org -Art Barstow
