Isn't the shared worker tied to the SOP? If so, then it seems to me that you would want the secure status to change just as if the parent window had done the request directly.
If I think I'm on a secure page, I certainly don't want my app doing insecure activities behind my back. I almost feel the same about PostMessage(), but since that is explicitly designed to cross domains, it may be different. -- Dirk On Wed, Dec 9, 2009 at 3:53 PM, Adam Barth <aba...@chromium.org> wrote: > In principle, the correct thing to do is keep track of the mixed > content state of the shared worker and infect whichever windows > interact with the worker. However, I suspect this is one of those > cases where the perfect is the enemy of the good. For the time being, > I'm fine with having the SharedWorker not trigger the mixed content > indicator. These sorts of attacks are much less severe than an HTTPS > page executing an HTTP script. In the latter case, an active network > attacker can completely control the HTTPS page. In the case of a > SharedWorker, the attacker doesn't get nearly as much leverage. > > Adam > > > On Wed, Dec 9, 2009 at 1:47 PM, Drew Wilson <atwil...@chromium.org> wrote: >> I'm trying to get my head around how our HTTPS status display (lock icon) >> should work now that we support cross-window/cross-domain communication and >> SharedWorkers. >> Currently, if an HTTPS page loads a worker and that worker subsequently does >> a non-HTTPS network operation, the parent window's UI updates to reflect the >> new non-secure state, just as if the page itself had performed a non-secure >> network op. With SharedWorkers, you may have a number of parent windows - it >> seems likely that all of those windows should update their state. >> However, SharedWorkers can accumulate new parents over time. Should a >> SharedWorker that has made an insecure connection in the past be permanently >> tainted (meaning that if a page connects to a tainted worker, it should >> immediately lose its own secure status, regardless of whether that worker >> ever makes another insecure connection)? Do we have any mechanisms currently >> in place that would facilitate implementing this behavior? >> Similarly, we can now exchange messages between windows (even across >> domains) using window.postMessage() - if my window posts/receives a message >> with an insecure window, does that affect my window's HTTPS status? Does >> this somehow cascade to other windows I may have exchanged messages with in >> the past? This situation seems directly analogous to SharedWorkers, since >> essentially a SharedWorker is just another execution context that multiple >> windows can communicate with via postMessage(). >> Finally, now that multiple pages share things like local storage, it seems >> like loading an insecure resource in one page could impact every page in the >> same origin (if my secure page is storing stuff in localstorage, but some >> other page in the same origin is compromised from loading an insecure >> resource, then it seems like my secure storage is compromised). >> Anyhow, people have been thinking about these issues far longer than I have >> - have we come to any conclusions about how our lock icon should work in >> these various situations? >> -atw >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
