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: publish new Working Draft of Indexed Database API; deadline April 16
On Tue, Apr 19, 2011 at 6:41 PM, Eliot Graff wrote: > Thanks for the feedback. Moving forward, I will track changes and resolution > of these suggestions in bug 9379 [1]. ok > Appreciate the time you've spent on this. here's next next part, note that i drafted it a while ago and am just sending it to flush my mailbox. > http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html part two... > The transaction mode determines both which operations are allowed > to be performed during the transaction, as well whether two transactions > can run concurrently or not. The transaction mode controls whether or not multiple transactions can run currently and which operations may be performed during the transaction. > Which operations are allowed be be performed are The allowed operations are > defined in detail below, > but in general transactions opened in READ_ONLY mode are only allowed > to perform reading operations which does not change data. s/reading // s/does/do/ -- this defines read, and operations are plural.. if you really want to define it perhaps stick some quotes around reading? > READ_WRITE transactions are allowed to > perform reading and writing transactions to existing object stores, s/perform reading and writing/read from and write/ > where as VERSION_CHANGE transactions are allowed to perform any operations, > including ones that delete and create object stores and indexes. > As long as the VERSION_CHANGE transaction, the implementation s/transaction/transaction is pending/ ? > MUST wait with starting any other transactions against the same s/with/before/ > database until the VERSION_CHANGE transaction is finished. > There are a number of ways that an implementation ensure this. s/ensure/ensures/ > It can prevent READ_WRITE transactions whose scope overlap s/prevent/stall/ ? (you don't prevent them from ever existing, you at best prevent them from starting which seems more like stalling or delaying) s/overlap/overlaps/ > the scope of the READ_ONLY transaction from starting until the > READ_ONLY transaction is finished. s/is finished/finishes/ > Or it can allow the READ_ONLY transaction to see a snapshot of the > contents of the object stores which is taken when the READ_ONLY > transaction is started. s/is // > Similarly, implementations MUST ensure that a READ_WRITE transaction is only > affected by changes to object stores that are made using the transaction > itself. I.e. the implementation MUST ensure that another transaction does not > modify the contents of object stores in the READ_WRITE transactions scope. I don't think starting a sentence with "i.e." is a good idea... s/transactions/transaction's/ > The implementation MUST also ensure that if the READ_WRITE transaction > completes successfully, that the changes written to object stores using the s/, that / / > transaction can be committed to the database without merge conflicts. i find "can be" here problematic, i know it's only meaningful with the next sentence, but i don't think it works well. > An implementation MUST NOT abort a transaction due to merge conflicts. > An implementation MUST NOT start any transaction until all other > READ_WRITE transactions with overlapping scope have completed. doesn't this prevent merge conflicts? > When multiple transactions are eligible to be started, older transactions > should be started first. should 'should' be written as an RFC word? > User agents MUST ensure a reasonable level of fairness across transactions to > prevent starvation. > For example if multiple READ_ONLY transaction are started one after another > the implementation MUST ensure that that doesn't indefinitely prevent a > pending READ_WRITE transaction from starting. This MUST doesn't seem testable, and sticking a MUST into an example seems wrong. > Transaction objects implement Each transaction object will implement either > the IDBTransaction or the IDBTransactionSync > interfaces. interface. -- this is a style change and applies to other objects in this document. I'm assuming that an object only ever implements one of the two interfaces and thus should be singular and you should spell out that it's exclusive. If it isn't, I'd like to know how/why. > Every request also has a result and an errorCode, neither of which are > accessible until the done flag is set to true. does 'are accessible' mean "will throw an exception if poked"? > Finally, requests have a request transaction. When a request is created, it > is always placed against a transaction using either the steps to a > asynchronously execute a request or the steps to a synchronously execute a > request. It would be really helpful if things like were links > This sets the request transaction to be that request. s/This sets/Those steps set/ > The only exceptions to this are the request returned from a IDBFactory.open > call and the request returned from a IDBDatabase.setVersion call, which > create re
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: CfC: WebApps testing process; deadline April 20
First, thanks to Art for pulling all this content together. We're looking forward to a more structured process for testing as various specifications in the WebApps increase in maturity. I have a couple of small comments related to the issues Aryeh raised. Apologies for the lateness of these comments; I spent time sharing this process with a number of teams at Microsoft before responding. 1. Early approval of tests We think that waiting for Last Call or Candidate Recommendation before approving tests loses some of the value of tests in driving ambiguity out of the specification. The CSS WG found many issues in CSS 2.1 as a consequence of tests and some of these issues we substantive enough that the spec went back to Working Draft status. Avoiding this by reviewing test cases earlier in the process will help to improve spec quality. I think of this in the following way: a bug filed against the spec requesting a change represents someone's view that the spec is wrong. On the other hand, an approved test with consensus of reviewers in the working group helps to identify more stable sections of the spec. It doesn't mean it can't change but it does mean the spec has had additional review on the assertions made in the test and that's useful. 2. Calls for Consensus When a contributor submits a set of tests, hopefully members of the public-webapps-testsuite list will review them. When the contributor believes they have addressed all of the feedback on the tests, we think they should be able to put the tests forward for a Call for Consensus on approving them. The WG may choose to issue such a call on a regular schedule for tests that have had sufficient time for review if the number of submissions makes doing this "on demand" too cumbersome. This call may just be made to the testsuite mailing list. A full WG consensus shouldn't be necessary until document transition. 3. Test suite maintainer It's not clear from the discussion below what the role of the maintainer is and whether there's one per spec or one for the group. This seems like largely an administrative role in ensuring that the appropriate tests are moved into the approval folder at the correct time and that the status of the test suite is accurately recorded. Perhaps members of the working group could volunteer to help with this or maybe the Team could help. Microsoft would be willing to contribute here too. Thanks, Adrian. On Tuesday, April 19, 2011 9:22 AM, Arthur Barstow wrote: > I agree the need for clear test suite status is implied and should be > explicit. I've added a new requirement for this to [1]. As to how this > requirement is addressed, perhaps we should adopt/re-use some existing > good practice; otherwise perhaps we can use a Status/Readme file in each > .../tests/ directory. > > Besides "WG Approval", you see the need for "maintainer approval". > Additionally, you think there will be scenarios where multiple > submissions make it difficult to know which tests have been reviewed > (e.g. by the maintainer). This could be addressed by the maintainer > creating a separate directory (e.g. "reviewed") and the maintainer would > use it to place copies of test cases (e.g. from submissions directories) > she reviewed (and possibly edited and approved). I don't think the > process as currently defined would preclude the maintainer from doing > something like this and if it becomes a common/good practice, we could > document it. In the case of a single contributor, it's probably not > something that would be needed (but wouldn't necessarily be harmful). > > -Art Barstow > > [1] http://www.w3.org/2008/webapps/wiki/Testing#Testing_Goals > > On Apr/17/2011 7:06 PM, ext Aryeh Gregor wrote: > > On Wed, Apr 13, 2011 at 10:02 AM, Arthur Barstow > wrote: > >> I have updated WebApps' testing process documents to reflect comments > >> submitted to the initial draft process [1]. As such, this is a Call > for > >> Consensus to agree to the testing process as described in: > >> > >> http://www.w3.org/2008/webapps/wiki/Testing > >> http://www.w3.org/2008/webapps/wiki/Submission > >> http://www.w3.org/2008/webapps/wiki/Approval > >> http://www.w3.org/2008/webapps/wiki/Harness > > Sorry for the lateness of this review -- I was swamped with work and > > didn't find the time to respond earlier. I still have a few issues > > with the proposed approval procedure. The way it sounds is that tests > > can either be non-approved, or approved. Non-approved tests sound > > like (I'm not totally clear on this) they're supposed to live in > > per-contributor submission/ directories, without anyone else > > necessarily having any say over them. Approved tests, on the other > > hand, only exist at LC or later, and can't be changed without Working > > Group approval. (Which means what? I'm not sure.) > > > > The problem I've seen with the submission/ vs. approved/ approach in > > the HTMLWG is that there's no distinction between tests in submission/ > > that ar
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: [IndexedDB] Spec Question on IDBFactory open method
On Wed, Apr 20, 2011 at 1:33 PM, Israel Hilerio wrote:
> The open method description in the IDBFactory talks about setting the source
> of the IDBRequest to "no source". What does "no source" means ("undefined",
> "null", other)?
>
> In addition, what should be the value of the transaction property in the
> IDBRequest object returned from the open method? It seems this should be
> either "undefined" or null.
It's (almost) just an internal property, so it doesn't really matter.
There is no way to check.
However we should make sure that IDBRequest.source returns null when
the source is set to "no source".
/ 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: > 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: [IndexedDB] Sync API for setVersion Changes
Looks great to me. Remember that we need to make both .transaction and .setVersion throw if called within the callback from either of them. / Jonas On Mon, Apr 18, 2011 at 11:22 AM, Israel Hilerio wrote: > I've created a bug to outline a potential change to the Sync API to handle > the context for setVersion transaction inside a callback method. I wanted to > follow up with the group to see what other people's thought about this > change. The Bug has all the details for the proposed change. The bug# is > 12438 [1]. > > Thanks, > > Israel > > [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12438 > > >
Re: [IndexedDB] Exceptions in IDB and the DOMException
Actually, I think we should abandon codes entirely and use the new mechanism that WebIDL uses. I honestly have a bit of a hard time understanding the WebIDL spec, but I believe the idea is to implement the proposal made in [1]. Basically rather than having .code we'd have .type, along with interface names for the various exceptions. If we did that then it should be very easy to share not just identifier with DOMException, but in fact use the exact same exception. For what it's worth, DATA_CLONE_ERR is already a DOMException per spec. I've been planning on filing bugs and start editing the spec to do this once I dig through and understand the necessary WebIDL here. [1] http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html / Jonas On Tue, Apr 19, 2011 at 11:13 PM, Pablo Castro wrote: > This came up today that I didn't remember having a conversation about it with > folks. > > We currently have IDBDatabaseException with a some error codes as constants > and code/message properties. Looking at DOMException as defined in DOM Core > [1], it turns out that a) the pattern of the class is identica, but instead > of code/message it has code/name and b) there are some errors present in both > or that are very close (e.g. NOT_FOUND_ERR, DATA_CLONE_ERR, > QUOTA_EXCEEDED_ERR). > > Would it be worth it trying to use the constants of DOMException when there's > one already there that matches the need? If that was the case, would be it > the constants that we would be reusing or would be have to throw a > DOMException instead of an IDBDatabaseException? > > Separately, in reference to a) above, should we change > IDBDatabaseException.message to IDBDatabaseException.name for consistency? > > Thanks > -pablo > > [1] http://www.w3.org/TR/2010/WD-domcore-20101007/#exception-domexception > > >
[XHR2] Blobs, names and FormData
Hi All, When a Blob is appended to a FormData, the XHR2 spec currently says that the filename used should be the empty string unless the Blob is also a File. If such a FormData is later submitted using XMLHttpRequest, this will result in a request that contains something similar to: Content-Disposition: form-data; name="myblob"; filename="" Unfortunately there appears to be some servers that are unable to deal with the filename parameter being empty. See details and examples in [1]. Chrome apparently already disregards the specification here and generates a seemingly random value for the filename parameter. Unless someone comes up with a reason otherwise, I suspect we need to change the spec here. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=649150 / Jonas
Re: [IndexedDB] Spec Question on IDBFactory open method
On 4/20/2011 1:33 PM, Israel Hilerio wrote:
The open method description in the IDBFactory talks about setting the source of the IDBRequest to "no
source". What does "no source" means ("undefined", "null", other)?
In addition, what should be the value of the transaction property in the IDBRequest
object returned from the open method? It seems this should be either
"undefined" or null.
I think undefined makes sense for both of these.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
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: [IndexedDB] Spec Question on IDBFactory open method
The open method description in the IDBFactory talks about setting the source of
the IDBRequest to "no source". What does "no source" means ("undefined",
"null", other)?
In addition, what should be the value of the transaction property in the
IDBRequest object returned from the open method? It seems this should be
either "undefined" or null.
Thanks,
Israel
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
[IndexedDB] Sync API for setVersion Changes
I've created a bug to outline a potential change to the Sync API to handle the context for setVersion transaction inside a callback method. I wanted to follow up with the group to see what other people's thought about this change. The Bug has all the details for the proposed change. The bug# is 12438 [1]. Thanks, Israel [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12438
