To clarify - I said that *persistent workers* could restrict x-domain network access. I didn't mean to imply that you could apply this same reasoning to hidden pages - I haven't thought about hidden pages enough to comment about the implications of that, since as you mention there are many more network access methods for hidden pages.<div>
<br></div><div>You do have a good point, though, and that is that if hidden pages *or* persistent workers need to be able to display UI to the user (for example, to prompt the user to enter their gmail credentials when they first start up their computer), it has some implications for popup spam.<br>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Tue, Jul 28, 2009 at 10:09 AM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson<<a href="mailto:atwilson@google.com">atwilson@google.com</a>> wrote:<br>
> I've been kicking around some ideas in this area. One thing you could do<br>
> with persistent workers is restrict network access to the domain of that<br>
> worker if you were concerned about botnets.<br>
<br>
</div>How would that work for background pages, though? It couldn't include<br>
any files from other domains in any form (image, script, style, etc.)?<br>
But it could still spawn a regular tab and load whatever it wanted in<br>
that. Have it spawn a popunder window, say, quickly open a bunch of<br>
things from foreign sites, and close it before the user notices<br>
anything more than a sudden odd flicker. Or whatever. Workers, if I<br>
understand right (I haven't read the spec . . .), can't do things like<br>
open new tabs, but it's been explicitly stated that these background<br>
pages should be able to do just that.<br>
</blockquote></div><br></div></div>