Thanks, Ian - this was great feedback.<div><br><div class="gmail_quote">On Fri, Mar 20, 2009 at 3:29 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
It is unclear to me why you would need access to the cookies from script<br>
to do cookie-based authentication. Isn't the server the one that sets the<br>
cookie and the one that uses it when it is returned?<br>
<br>
Could you elaborate on how you see the cookie API being used?<br></blockquote><div><br></div><div>Good point. Cookie-based auth is not a great use case, because as you point out, you could just do this by passing credentials to the server via an XHR request and have it set your cookies. I guess the motivation for allowing cookies to be set from workers is the same as the motivation for allowing web-page script to set cookies - perhaps this motivation is deprecated now that we have localStorage but even localStorage doesn't seem to have the nice cross-sub-domain sharing that cookies allow.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
(notifications):<br>
These seem like good use cases, but it's not clear what the user interface<br>
would look like, which is probably the hardest problem here.</blockquote><div> </div><div>Agreed. This will be tricky especially given the restrictions on some platforms - I'm hoping we can do some experiments and come up with something that's compelling.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> Gears had an explicit permissions variable applications could check,<br>
> which seems valuable - do we do anything similar elsewhere in HTML5 that<br>
> we could use as a model here?<br>
<br>
HTML5 so far has avoided anything that requires explicit permission<br>
grants, because they are generally a bad idea from a security perspective<br>
(users will grant any permissions the system asks them for).<br></blockquote><div><br></div><div>The Database spec has a strong implication that applications can request a larger DB quota, which will result in the user being prompted for permission either immediately, or at the point that the default quota is exceeded. So it's not without precedent, I think. Or maybe I'm just misreading this:</div>
<div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-size: 16px; "><span class="Apple-style-span" style="font-style: italic;">User agents are expected to use the display name and the estimated database size to optimize the user experience. For example, a user agent could use the estimated size to suggest an initial quota to the user. This allows a site that is aware that it will try to use hundreds of megabytes to declare this upfront, instead of the user agent prompting the user for permission to increase the quota every five megabytes.</span></span><br>
</div><div><br></div><div>To be clear, are you saying that our philosophy is to leave any permissions granting up to the individual user agent (i.e. not described in the spec)? Or that we're trying to avoid specifying functionality that might be invasive enough to require permissions?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> The namespace for PersistentWorkers are identical to those of<br>
> SharedWorkers - for example, if you already have a PersistentWorker<br>
> named 'core' under a domain and a window tries to create a SharedWorker<br>
> named 'core', a security exception will be thrown, just as if a<br>
> different URL had been specified for two identically-named<br>
> SharedWorkers.<br>
<br>
Why would we not want them to use different namespaces?<br>
<br></blockquote><div><br></div><div>I've rethought this, and I actually agree that they should have different namespaces. </div><div><br></div><div>In fact, I'd go further - I don't think we should even *have* names for persistent workers (the use case for having names is "what if I want to run the same worker multiple times without having to host multiple scripts", which I don't think really applies to persistent workers). Also, one of the things I'd like to experiment with in my implementation is allowing cross-domain access to workers (this is required if you want workers to be able to communicate/share resources across domains, since workers don't have access to any of the cross-domain functionality that window-based script has) - getting rid of the "name" and always having persistent workers identified by their script url helps enable this, and avoids some security issues, such as the ones described in this old Gears proposal I came across: <a href="http://code.google.com/p/gears/wiki/CrossOriginAPI">http://code.google.com/p/gears/wiki/CrossOriginAPI</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I would be very concerned about this getting abused for popups. I don't<br>
think we want to allow arbitrary windows to be opened. I could see<br>
allowing a kind of simple toast popup that pops up a link which, when<br>
clicked, _then_ opens a window; would that work? Something like:<br>
<br>
   void notify(message, url);<br></blockquote><div><br></div><div>That could definitely work. Agreed that we'd want to force some kind of user interaction first to avoid popup spam.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
> Additionally, there's no good way for workers under different domains to<br>
> talk to one another (a window can use the cross-domain messaging<br>
> functionality to talk to other domains, but there's no analog for this<br>
> for workers).<br>
<br>
This has been intentionally delayed while we wait for more implementation<br>
experience.<br></blockquote><div><br></div><div>I'm hoping to experiment with this some (per my earlier comment), so hopefully I'll be able to report back with some interesting data points (or at least my miserable failure will serve as an object lesson for future implementors :). </div>
<div><br></div><div>To give people a more concrete example of one of the use cases that is driving this: A typical Single-Sign-On implementation has the user log in under a single domain (storing auth cookies under that domain) then when the user visits an application domain he is redirected back through the authenticated domain where he is authenticated based on his auth cookies, and some sort of auth token is then returned to the application domain. Web page script has lots of ways to achieve this (using plain old HTTP redirects, doing x-domain requests to the auth domain via iframes, etc), but workers have no way to do this currently short of changing the auth server to allow cross domain requests via an Access-Control-* header.</div>
<div><br></div><div>By enabling cross-domain worker access, there could be a worker running under the auth domain, and persistent workers running under the application domain could authenticate themselves via the auth worker (make a request to the auth worker, the auth worker can make an authentication request to the server on their behalf under the auth domain and return back an appropriate auth token to the app worker).</div>
<div> </div><div>-atw</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888">
</font></blockquote></div><br>
</div>