So use an out-of-band extension mechanism to establish trust and permissioning for capabilities that fall out of bounds of the 'regular' web model.<div><br></div><div>So lets put that to practice on this particular two-part proposal...</div>
<div><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">> Our proposed solution has two parts.</span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">This first part (below) falls within the bounds of the 'regular' web model. Would be nice to discuss this on the merits in absense of the 'scary trust permissioning' issues.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">> The first, which should be<br>> generally useful, is the ability to have a hidden HTML/JS page running<br>
> in the background that can access the DOM of visible windows. This<br>> page should be accessible from windows that the user navigates to. We<br>> call this background Javascript window a "shared context" or a<br>
> "background page". This will enable multiple instances of a web app<br>> (e.g. tearoff windows in Gmail) to cleanly access the same user state<br>> no matter which windows are open.<br><br></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; ">This second part (below) would only be accessible after out-of-band trust and permissioning mechansims got tickled. </span></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><br>
> Additionally, we'd like this background page to continue to run after<br>> the user has navigated away from the site, and preferably after the<br>> user has closed the browser. This will enable us to keep client-side<br>
> data up-to-date on the user's machine. It will also enable us to<br>> download JS in advance. When the user navigates to a web app, all the<br>> background page has to do is draw the DOM in the visible window. This<br>
> should significantly speed up app startup. Additionally, when<br>> something happens that requires notification, the background page can<br>> launch a visible page with a notification (or use other rich APIs for<br>
> showing notifications).</span></div><div><br></div><div>(aside... begs the question... when will that extension mechanism be standardized :)<br><br></div><div><br><div class="gmail_quote">On Thu, Jul 30, 2009 at 1:49 PM, Dmitry Titov <span dir="ltr"><<a href="mailto:dimich@google.com">dimich@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I think I almost get this distinction :-) you are saying that HTML+JS could be made more powerful with new APIs, but only if it is done sufficiently far from the 'regular web page browsing' experience (or model). Say, if it is a "browser extension" or a prism-like app it's ok - only (or mostly) because it is outside from the regular process of web browsing that users have been taught is 'reasonably safe'.<div>
<br></div><div>Would this functionality be ok as a part of a browser extension? Lets say you can install an extension that is loaded in background (as Chrome already can do) and that the pages from the same domain are loaded into same process and can exchange DOM with it.</div>
<div><br></div><div>I'm not trying to argue for the proposal, I am just curious how the more-powerful APIs could be added, since this is not the last proposal that tries to do this. Looking at use cases and coming up with narrow API that does not require permissions is understood, but it's interesting how to go beyond this line. Or, as Ojan says, if it's even a goal :-)</div>
<div><br></div><div><font color="#888888">Dmitry</font><div><div></div><div class="h5"><br><div><div><br><br><div class="gmail_quote">On Thu, Jul 30, 2009 at 1:23 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the error here is viewing this as a UX issue - if it were just a UX issue, then the responses from people would be along the lines of "Oh, this sounds dangerous - make sure you wrap it with the same permissions UI that we have for extensions, plugins, and binary downloads".<div>
<br></div><div>The realization I came to this morning is that the core of the objections are not primarily about protecting users (although this is one goal), but more about protecting the current secure web browsing model (Linus explicitly said this yesterday in his email to the list, but I only "got it" when thinking about it today).</div>
<div><br></div><div>This is why people are OK with supporting this via extensions but not OK with supporting this as part of the core HTML APIs even if the UX was exactly the same. It's more about keeping the model pristine. Doing crazy stuff in extensions and plugins are OK because they are viewed as falling outside the model (they are just random scary things that user agents choose to do that don't conform to the specification).</div>
<div><br></div><div>So arguing "but it's the same UI either way!" is not going to convince anyone.</div><div><br></div><div>-atw<br><br><div class="gmail_quote"><div>On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov <span dir="ltr"><<a href="mailto:dimich@google.com" target="_blank">dimich@google.com</a>></span> wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems the biggest concern in this discussion is around "BotNet Construction Kit" as Machej succulently called it, or an ability to run full-powered platform API persistently in the background, w/o a visible 'page' in some window.<div>
<br></div><div>This concern is clear. But what could be a direction to the solution? Assuming one of the goals for html5 is reducing a gap in capabilities between web apps and native apps, how do we move forward with more powerful APIs?</div>
<div><br></div><div>So far, multiple ways exist to gain access to the user's machine - nearly all of them based on some dialog that asks user to make impossible decision - as bad as it is, binary downloads, plugins, browser extensions, axtivex controls or Gears modules are all but a dialog away from the user's computer. Basically, if a malicious dudes are cool to write native apps - they can have their botnet relatively easy. The ongoing fight with malware and viruses will continue - not because the platforms have wrong API, but because it's really hard to give power to the apps and not to the malware, since they, in essence, do the very similar things.</div>
<div><br></div><div>As controversial as it sounds, it might be if a web platform API can't be used to write a botnet, then it can't be used to write a wide class of powerful applications as well :-)</div><div><br>
</div><div>I don't have a botnet example, but when Safari 4 visits the sites in the background (to keep the 'new tab page' site snapshots up-to-date) w/o ever asking my permission - it looks a bit scary, because I'm not sure I want it to visit websites at random time from my IP with I don't know what cookies and then snapshot the result in jpg and store it locally... But I sort of like the feature anyways. Now, how can I make a web app that does this? Some sort of background shared page could be handy. It can pop up the same dialog when installed, live in Applications folder but it should be possible. Now if we make it possible, would it be possible to write a botnet on top of the API? Of course! Same exact way as it's possible to write even better botnet on OSX API in which Safari is written.</div>
<div><br></div><div>Now, what if I want the same feature but implemented not as a native app, but as a web app? We would need to give it specific rights locally, and make the process transparent - not only on 'install' time but when it runs too - so the user could peek into some 'task manager' and clearly see if such thing is running. Browser could periodically download 'malware lists' and kill those web apps that are in it. </div>
<div><br></div><div>But for now, it should be ok to have it 'installed' with a specific browser dialog that asks the user to make a decision the user may not understand - it is not the ideal way but it is the common way today, users know they are asked these questions, admins and IT teaches users what to do when asked, so it's the best we can do now. Having a 'task manager' (as in Chrome) reflecting those things is good too.</div>
<div><br></div><div>Btw, if it only can do window.open() on the url from the same domain, then if it's from Gmail then it can't be used or hijaked. If it is from a site that says install this and I'll show you a pretty picture and user clicks through a dialog, I'd say it's not a new vector for malware.</div>
<div><br></div><font color="#888888"><div>Dmitry</div></font><div><div></div><div><div><br><br><div class="gmail_quote">On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson <span dir="ltr"><<a href="mailto:mpd@google.com" target="_blank">mpd@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak<<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
> * Notification Feeds *<br>
><br>
> Often, web applications would like to give users the option to subscribe to<br>
> notifications that occur at specific times or in response to server-side<br>
> events, and for the user to get these UI notifications without a<br>
> prerequisite that the web app is open or that the browser is running. There<br>
> may be a desire to do client-side computation as well, but often just the<br>
> ability to give the user a notification solves the basic user interaction<br>
> problem.<br>
><br>
> One possible way to address this kind of use case is to let users subscribe<br>
> to a "feed" of notifications. This feed could use standard syndication<br>
> formats, such as RSS or Atom. But instead of being displayed in a<br>
<br>
</div>This is an interesting idea. The lack of push updates, though, would<br>
make it much less useful than it could be.<br>
<br>
Here's a rough sketch of a more far-out idea: What if all browsers<br>
were XMPP clients and stanzas could be sent to display notifications?<br>
The attack surface would still be low, but you'd get realtime updates.<br>
Instead of subscribing to a feed of notifications, the user accepts<br>
what is essentially a chat invitation from the site. Like normal XMPP<br>
invitations, this would be revocable at any time.<br>
<br>
Lots of issues to work out, but you'd get realtime for free.<br>
<font color="#888888"><br>
Michael<br>
</font></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>