<div class="gmail_quote">On Thu, Jul 30, 2009 at 3:51 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;">
<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></div></blockquote><div><br></div><div>Giving web pages exactly the same power as native applications is not, and should not be, the goal. The goal is to enable many of the the same use-cases. Native apps can do anything they want and installing them is very risky. It is one of the benefits of the web that web pages you navigate to do *not* have that sort of power.</div>
<div><br></div><div>Installing native apps from untrusted sources is scary. Visiting web pages should never be scary, especially since the average user stumbles upon many more web pages in a given day than native apps they would install. The desktop has no equivalent to the lightweight step of visiting a web page. Giving "installed" web pages (e.g. extensions) more power is much safer than silently giving all web pages that power.</div>
<div><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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>
</blockquote><div><br></div><div>I don't yet see any evidence that this is true. Certainly, enabling botnet-like power would enable a wider class of powerful applications. However, the corollary may not be true. It may be possible that we can add all the power we need to the web without enabling botnets if we are use-case driven and think of more constrained APIs that meet the same needs.</div>
<div><br></div><div>Ojan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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 class="h5"><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><br>