Re: [whatwg] Installed Apps
After some internal discussions, I've sent a quite updated proposal which
includes use cases we've looked at ("Global Script"). We've got some
experience of talking with app developers and it seems having a concept of
'application context' or 'global script' is a recurring theme.. The unwanted
serialization and asynchronously in places where developers don't wants them
(think selecting a pice of text in a web application that allows "split
window" view at the document) definitely points that something like a
"Shared Worker" but without a thread and with direct DOM access is a good
idea which compliments the set of building blocks...
On Thu, Aug 13, 2009 at 11:53 AM, Drew Wilson wrote:
>
>
> On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson wrote:
>
>>
>> Maybe I'm mistaken, but I think Drew wanted handling of
>> "live" objects, where each window gets access to the same
>> concrete objects (possibly protected by private proxy
>> objects) so the graph can be walked without cloning.
>
>
> To be honest, I'm not really a good spokesperson for this issue, as most of
> my thinking has been around shared workers which have all the same drawbacks
> for data sharing that WebStorage has.
>
> I was just saying that I understand the problem that the shared context is
> trying to address. I personally think that part of the problem can be
> overcome using the existing tools, although with more effort on the app side
> than a simple shared context solution.
>
>
>>
>> Drew: are you thinking that the same object graph also
>> makes up the data cache between sessions? If not, then
>> persistence is not a must-have for this use case so the
>> area of ideas could well expand outside webstorage.
>
>
> I think ideally serialization would happen only when data needs to be
> persisted. If I have a data structure that I want to share with other open
> windows, I shouldn't have to persist it to accomplish this, and I certainly
> shouldn't have to re-serialize it every time I want to make a minor change.
>
> But, again, I'm just speaking in the abstract - the folks proposing shared
> context (Dmitry) should probably chime in here as they've thought about this
> problem much more than I have.
>
> -atw
>
>
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson wrote: > > Maybe I'm mistaken, but I think Drew wanted handling of > "live" objects, where each window gets access to the same > concrete objects (possibly protected by private proxy > objects) so the graph can be walked without cloning. To be honest, I'm not really a good spokesperson for this issue, as most of my thinking has been around shared workers which have all the same drawbacks for data sharing that WebStorage has. I was just saying that I understand the problem that the shared context is trying to address. I personally think that part of the problem can be overcome using the existing tools, although with more effort on the app side than a simple shared context solution. > > Drew: are you thinking that the same object graph also > makes up the data cache between sessions? If not, then > persistence is not a must-have for this use case so the > area of ideas could well expand outside webstorage. I think ideally serialization would happen only when data needs to be persisted. If I have a data structure that I want to share with other open windows, I shouldn't have to persist it to accomplish this, and I certainly shouldn't have to re-serialize it every time I want to make a minor change. But, again, I'm just speaking in the abstract - the folks proposing shared context (Dmitry) should probably chime in here as they've thought about this problem much more than I have. -atw
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson wrote: > > > Sure, although I'd say that "persistent storage is addressed by the Web > > Storage and Web Database features". Shared state is also addressed, but > > that's not the primary goal. If I have a tree of objects that I'd like > > to share between two pages, telling me to serialize it into name/value > > string pairs, write it into Web Storage, and then have the remote side > > read it out is not a satisfying (or performant) solution. > > Web Storage supports structured data now. > Yeah, the fact that the UA will automatically jsonify my (cycle-free) data structures does not really make this a great solution, for many of the reasons Mike Wilson mentioned. That said, once you've architected your application around having only asynchronous access to your data structures, there are lots of tools available in HTML5 to do sharing (use WebStorage as you describe, push all data access through a SharedWorker, keep duplicate copies of data structures in each page and update them via DB or SharedWorker messages, etc). > A system that displays rich/scripted content on server demand rather than > on user demand is a massive security nightmare. It turns a scripting > security bug and an XSS bug into an instant malware deployment vector. Another name for "a system that displays rich/scripted content on server demand" is "an open web page" :) The only difference is the user has UI to close a web page when he's done interacting with it, while the UI to enable/disable notifications from a domain is probably less obvious. Scriptable notifications are a use case that none of these proposals currently satisfy. I understand the security concerns. I just don't (yet :) share the general belief that they are insurmountable which is why I want to continue experimenting in this area. > > > Additionally, any server-side-feed-based solution has the implication > > that it won't work for offline apps. If I am using a web calendar, I > > want my event notifications regardless of whether I'm online or offline > > (the event may have been added while I'm offline and never synced to the > > server at all). > > I think on the long term we may wish to consider adding a feature to queue > up POSTs for when the UA finds it is back online. That would address a > number of problems, including this one. > I'll just note that to get a narrow subset of the behavior that simple background scripting would provide (static notifications and static data synchronization without client-side reconciliation), we're having to have: 1) A server-controlled push notification stream, as well as infrastructure for applications to insert/remove notifications into the stream for offline use. 2) Some kind of server database push-sync protocol. 3) Some kind of "queued up posts" feature (with assumedly yet more infrastructure to deal with errors/return values from these delayed POSTs). What you really want for #2/#3 is a general-purpose sync protocol, but I don't see how you do it without some form of client-side conflict resolution. I hope that people understand why application scripting seems like a more attractive, general-purpose solution. I'm unable to muster much enthusiasm for a set of convoluted server-and-client-side mechanisms that cover such a narrow set of use cases without any way for client applications to customize this behavior through scripting. > I really don't feel right allowing script to run like that. > > Why can't the server send the data to the client in a near-final form and > let the script figure it out when the user finally opens the app? > What if there are things the application wants to do to act upon this data immediately (add items to the notification stream, for example)? What you're saying is we need to push all of this functionality up to the server, then provide a very narrow set of APIs (essentially, static notifications) that the server can use to act on that functionality. > > What other use cases are there? Those were the ones given. We're very much > use-case-driven here. > I won't claim to understand all of the potential use cases yet, but I have a preference for general-purpose solutions rather than solutions that narrowly target a set of specific use cases, although I recognize that more general-purpose solutions have commensurate security implications. I'd like to just experiment with background scripting/scriptable notifications in a way that people find acceptable (either without persistence, or using extensions for persistence), see how applications actually use them, then continue this conversation. People are certainly welcome to do parallel experimentation with other approaches such as the ones you've outlined above. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`
Re: [whatwg] Installed Apps
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson wrote: > > > Additionally, any server-side-feed-based solution has the implication > > that it won't work for offline apps. If I am using a web calendar, I > > want my event notifications regardless of whether I'm online or offline > > (the event may have been added while I'm offline and never synced to the > > server at all). > > I think on the long term we may wish to consider adding a feature to queue > up POSTs for when the UA finds it is back online. That would address a > number of problems, including this one. It seems like conflict resolution will be more difficult when it can only happen at the server side. In addition, it seems like there'd be more efficient means of syncing rather than many small messages. We don't have to talk about this now since there isn't even a proposal yet, but I'm doubtful this will be a good solution to the problem. > On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > > > > > > I'm not sure XMPP is the protocol I would jump to, but it's certainly > > > an option, yes. > > > > What don't you like about XMPP? > > It's far too complex for people to write and deploy an XMPP server on a > whim. Like HTTP, it requires people to use off-the-shelf software instead > of allowing them to experiment with their own code. This leads to software > monocultures, and prevents easy experimentation. I guess we'll see how the WebSocket protocol works out. I definitely see both pros and cons to this approach.
Re: [whatwg] Installed Apps
Ian Hickson wrote: > > On Tue, 4 Aug 2009, Drew Wilson wrote: > > Sure, although I'd say that "persistent storage is > > addressed by the Web Storage and Web Database > > features". Shared state is also addressed, but that's > > not the primary goal. If I have a tree of objects > > that I'd like to share between two pages, telling me > > to serialize it into name/value string pairs, write > > it into Web Storage, and then have the remote side > > read it out is not a satisfying (or performant) > > solution. > > Web Storage supports structured data now. I'm assuming that you refer to the concept of "structured clone" now added to http://dev.w3.org/html5/webstorage/. This certainly makes life easier for certain scenarios, but I don't think it fully addresses Drew's use case. The problem is that to change the tiniest thing in the object graph, you will have to get a complete copy of the data out from the storage provider, apply the change, and then let it be copied (cloned) back into storage again. With Drew's large mailbox + categories example I think this will be too inefficient. Also, it cannot be divided into chunks stored under individual keys as that breaks object pointers. Maybe I'm mistaken, but I think Drew wanted handling of "live" objects, where each window gets access to the same concrete objects (possibly protected by private proxy objects) so the graph can be walked without cloning. Drew: are you thinking that the same object graph also makes up the data cache between sessions? If not, then persistence is not a must-have for this use case so the area of ideas could well expand outside webstorage. (Minor note: the Introduction still says that structured data needs to be handled manually: "To store structured data in a storage area, you must first convert it to a string.") Best regards Mike Wilson
Re: [whatwg] Installed Apps
On Tue, 4 Aug 2009, Drew Wilson wrote: > On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > > > > It seems like a direct solution to these would be to have a way for > > Web pages to expose a service that clients could subscribe to, which > > could send up database updates and notifications. That way, no script > > runs on the client, but the server can still update the client > > whenever needed. > > Yeah, this is an interesting idea, although I'm envisioning apps that > support offline use requiring what amounts to a sync process with > app-specific conflict resolution, etc - I think this would be difficult > to support with this kind of general platform. But, agreed, this is > better than nothing - at the very least, an application could use it to > sync down changes to a "staging area" for later resolution once the app > itself starts up. Ok. I think this is the direction we should look in to address this use case then. I haven't specced anything yet, but I've noted it as a feature we should look at. If anyone wants to experiment in this space, that would be great. > Sure, although I'd say that "persistent storage is addressed by the Web > Storage and Web Database features". Shared state is also addressed, but > that's not the primary goal. If I have a tree of objects that I'd like > to share between two pages, telling me to serialize it into name/value > string pairs, write it into Web Storage, and then have the remote side > read it out is not a satisfying (or performant) solution. Web Storage supports structured data now. > Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to > notifications (our vision for notifications is that they are scriptable > and more interactive than just a dumb text + icon). A system that displays rich/scripted content on server demand rather than on user demand is a massive security nightmare. It turns a scripting security bug and an XSS bug into an instant malware deployment vector. > Additionally, any server-side-feed-based solution has the implication > that it won't work for offline apps. If I am using a web calendar, I > want my event notifications regardless of whether I'm online or offline > (the event may have been added while I'm offline and never synced to the > server at all). I think on the long term we may wish to consider adding a feature to queue up POSTs for when the UA finds it is back online. That would address a number of problems, including this one. On Tue, 4 Aug 2009, Jeremy Orlow wrote: > > The idea of tying the notification spec to a particular brand of storage > seems like a bad idea...especially at this point in time. We can make this work with all of the mechanisms pretty easily. > On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > > > > I'm not sure XMPP is the protocol I would jump to, but it's certainly > > an option, yes. > > What don't you like about XMPP? It's far too complex for people to write and deploy an XMPP server on a whim. Like HTTP, it requires people to use off-the-shelf software instead of allowing them to experiment with their own code. This leads to software monocultures, and prevents easy experimentation. On Tue, 4 Aug 2009, Dmitry Titov wrote: > > What about the "shared context with DOM access" idea which, even w/o > persistency, seems to resolve some issues for apps like GMail? Like a > shared worker, but with access to DOM. I don't think that such a mechanism will work well given multicore processors, multiprocess UAs, and the way that gadgets end up connecting domains all over the place. > 2. It does rely on 'cooperative' pages to be opened in the same process > but this is easy to implement. I mean, you can't 'guarantee' it (a page > from another domain may have iframe pointing to the app and it will be > in a diff. process) but any reasonable app can be easily structured in a > way to get its views (pages) into a single process. I think this is understating the disadvantages of this model, and overestimating the ease with which one can make it work. > 3. It would help to provide fast (meaning sub-100ms, interactively fast) > UI responses necessary for the seamless operations. Persistent data > storage and parsing/generating HTML (including loading all the code > necessary to do that from the 'pure data') will always present challenge > for sub-100ms UI actions - even in native apps it is a challenge today. > > Here is a typical use case: You compose a message in GMial window. > Halfway through you decide to peek into another mail thread for more > information. You click 'tear-off' button to "disconnect" the compose > window so you can see other mail threads. Today, this opens a new window > and starts loading XXX Kb of script into it. You see the progress > indicator for a few seconds. This script is needed to be able to go to > server and generate a proper UI from the response, as well as have all > the 'controller' lo
Re: [whatwg] Installed Apps
From: John Gregg Sent: Monday, August 10, 2009 2:34 PM Michael Kozakewich wrote: Are notifications really a renderer problem, as opposed to a browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit') Also, I don't know of any notifications (Outlook, Messenger, AVG, TweetDeck, etc.) that require permissions, so I'd argue that requiring permissions for notification would be arguably confusing. It doesn't interrupt flow like alert() does. It's not a renderer 'problem'; the code that would go in WebKit is just to define the API and some basic logic about events flowing back and forth. More work is certainly necessary beyond that (code which I am also writing for Chromium). The idea is that there be a standard notification API which apps can write to and expect the intuitive thing to happen according to the user agent & platform: on Mac these may go to Growl, on Linux to libnotify, on Windows to toasts on the screen, on Mobile to something specific for the device, etc. I think there's a big difference in expectations for an installed native app like those in your list versus a web page. The user grants broad permission when they install an app like that, but when they visit a web page the expectation is very different. The fact that it's not modal like an alert could even make it more necessary to secure: do you want an evil site to spam your desktop with an unbounded # of toasts? Again, I'm talking about a notifications API which is independent of the "installed web app" idea also being discussed in this thread. It certainly might make sense that if there is a way to install a web app in some form with a permissions step, notifications could piggyback on that to avoid confusing prompts. Just in case I need to be set straight, here, I've got a couple questions: If vendors implemented this, they would have to work on their browsers, right? Is it easier for them to work on the rendering engine or on the application, or is there no difference? Do they prefer to add functionality to their rendering engine or to their application, or do they not care? (For these, I'm working from the assumption that it doesn't noticeably affect the UI, such as a new button or bar would.) And last: do they try not to touch the browsers, or do they prefer to delegate upgrades based on where they would be most suitable? I'm not sure I follow the question, but I think it depends on the architecture of the particular browser. Based on what I've proposed, a browser maker would need to build all the pieces necessary to go from script executing "notification.show()" to getting something on the screen. I think answering those questions would help me the most, because at this point I don't know why they'd alter the renderer or JS engine to handle popup JavaScript instead of altering the browser to support what seems like a simple UI addition of pop-ups, but I do feel as though they wouldn't like to change the browser process. (As a final point, it's been mentioned that such a feature would become very popular, so many sites would implement it. It begs the question of which option is best for handling the volume of notifications and potentially abused notifications.) Handling the volume falls on the browser or on the presenter of notifications that the browser may might choose to delegate to (like Growl). I would think queuing based on available space is a reasonable start. Handling potential abuse is exactly why a permissions model is part of the proposal. -John For some reason, I seemed to forget that the call would be made through JavaScript in either case. I only briefly touched on the idea of 3rd-party apps like feed-readers, because I'm really not enamored with the idea. My main thought was that the browser itself would have a notifications process that would be subscribed to, and then the tabs could post messages to it. The browser would police that. (It could automatically register the tab as the first post method was sent, and unregister when that tab was closed). I don't believe such a process would have inherent security concerns, if the process was thought out (all it needs is presentation/layout). In this way, you wouldn't need to install the app to use notifications. I just wonder about policing (give a little notification, like when pop-ups are blocked, with option allowing notifications for the whole site? +Whitelisting?) I admit I worded the browser/renderer questions horribly. I meant the difference of using JavaScript to pop up an HTML message, with a bit of help from the browser; as compared to posting to the browser with JavaScript and having the browser pop up a message with its own (themeable) UI, like what one might expect from an extension. Both need everything to work together, but they have different focuses. I'd imagine (from other WHATWG discussion) the HTML version would have scri
Re: [whatwg] Installed Apps
Michael Kozakewich wrote: > Are notifications really a renderer problem, as opposed to a browser-UI > problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit') > Also, I don't know of any notifications (Outlook, Messenger, AVG, > TweetDeck, etc.) that require permissions, so I'd argue that requiring > permissions for notification would be arguably confusing. It doesn't > interrupt flow like alert() does. > It's not a renderer 'problem'; the code that would go in WebKit is just to define the API and some basic logic about events flowing back and forth. More work is certainly necessary beyond that (code which I am also writing for Chromium). The idea is that there be a standard notification API which apps can write to and expect the intuitive thing to happen according to the user agent & platform: on Mac these may go to Growl, on Linux to libnotify, on Windows to toasts on the screen, on Mobile to something specific for the device, etc. I think there's a big difference in expectations for an installed native app like those in your list versus a web page. The user grants broad permission when they install an app like that, but when they visit a web page the expectation is very different. The fact that it's not modal like an alert could even make it more necessary to secure: do you want an evil site to spam your desktop with an unbounded # of toasts? Again, I'm talking about a notifications API which is independent of the "installed web app" idea also being discussed in this thread. It certainly might make sense that if there is a way to install a web app in some form with a permissions step, notifications could piggyback on that to avoid confusing prompts. > Just in case I need to be set straight, here, I've got a couple questions: > If vendors implemented this, they would have to work on their browsers, > right? Is it easier for them to work on the rendering engine or on the > application, or is there no difference? Do they prefer to add functionality > to their rendering engine or to their application, or do they not care? (For > these, I'm working from the assumption that it doesn't noticeably affect the > UI, such as a new button or bar would.) > And last: do they try not to touch the browsers, or do they prefer > to delegate upgrades based on where they would be most suitable? > I'm not sure I follow the question, but I think it depends on the architecture of the particular browser. Based on what I've proposed, a browser maker would need to build all the pieces necessary to go from script executing "notification.show()" to getting something on the screen. I think answering those questions would help me the most, because at this > point I don't know why they'd alter the renderer or JS engine to handle > popup JavaScript instead of altering the browser to support what seems like > a simple UI addition of pop-ups, but I do feel as though they wouldn't like > to change the browser process. > (As a final point, it's been mentioned that such a feature would become > very popular, so many sites would implement it. It begs the question of > which option is best for handling the volume of notifications and > potentially abused notifications.) > Handling the volume falls on the browser or on the presenter of notifications that the browser may might choose to delegate to (like Growl). I would think queuing based on available space is a reasonable start. Handling potential abuse is exactly why a permissions model is part of the proposal. -John
Re: [whatwg] Installed Apps
From: John Gregg Sent: Monday, August 10, 2009 12:54 PM I think it's appeared on this thread before, but I'm currently working on an API to provide desktop notifications. A patch has been proposed to WebKit at https://bugs.webkit.org/show_bug.cgi?id=25463. I had originally proposed it to this list back in March under the context of persistent workers, which had the same motivation that you describe: background process while the application tab is closed. Now I think it makes more sense to make this API available generically (pages included, as the above WebKit patch does) subject to permissions, so that it will be available to applications regardless of where they end up running. Desktop notifications are pretty useful even when the tab is active but minimized, so it doesn't necessarily need to be wrapped up in a persistent installation process, as long as permission can be established. -John Are notifications really a renderer problem, as opposed to a browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit') Also, I don't know of any notifications (Outlook, Messenger, AVG, TweetDeck, etc.) that require permissions, so I'd argue that requiring permissions for notification would be arguably confusing. It doesn't interrupt flow like alert() does. Just in case I need to be set straight, here, I've got a couple questions: If vendors implemented this, they would have to work on their browsers, right? Is it easier for them to work on the rendering engine or on the application, or is there no difference? Do they prefer to add functionality to their rendering engine or to their application, or do they not care? (For these, I'm working from the assumption that it doesn't noticeably affect the UI, such as a new button or bar would.) And last: do they try not to touch the browsers, or do they prefer to delegate upgrades based on where they would be most suitable? I think answering those questions would help me the most, because at this point I don't know why they'd alter the renderer or JS engine to handle popup JavaScript instead of altering the browser to support what seems like a simple UI addition of pop-ups, but I do feel as though they wouldn't like to change the browser process. (As a final point, it's been mentioned that such a feature would become very popular, so many sites would implement it. It begs the question of which option is best for handling the volume of notifications and potentially abused notifications.)
Re: [whatwg] Installed Apps
> TO SUMMARIZE: > -There are many other existing ways to notify > -I'd suggest browsers have a Notification process with which open tabs > register. > -Registered open tabs could tell the browser to pop up a notification, > perhaps with title text, body text, and image > -Clicking the notification would set focus to the browser and to the > notifying tab. > > To solve the lifetime issue: > -Torn-off tabs run in separate processes > -Processes may be re-skinned to appear as applications, but are really > tabs. > -Minimized/docked Processes taken off the taskbar/dock and into a > notification area or Application Manager > -If the rest of the browser is closed, the main process will stay on until > the application tabs are closed > -Browser's 'Application Manager' in notification area or taskbar/dock (and > as a button in the main browser) holds all open application tabs > > Have I forgotten anything? > Even without the application tabs, the notification process would be great > to implement. > I think it's appeared on this thread before, but I'm currently working on an API to provide desktop notifications. A patch has been proposed to WebKit at https://bugs.webkit.org/show_bug.cgi?id=25463. I had originally proposed it to this list back in March under the context of persistent workers, which had the same motivation that you describe: background process while the application tab is closed. Now I think it makes more sense to make this API available generically (pages included, as the above WebKit patch does) subject to permissions, so that it will be available to applications regardless of where they end up running. Desktop notifications are pretty useful even when the tab is active but minimized, so it doesn't necessarily need to be wrapped up in a persistent installation process, as long as permission can be established. -John
Re: [whatwg] Installed Apps
2009/8/7 Michael Kozakewich > > > TO SUMMARIZE: > -There are many other existing ways to notify > -I'd suggest browsers have a Notification process with which open tabs > register. > -Registered open tabs could tell the browser to pop up a notification, > perhaps with title text, body text, and image > -Clicking the notification would set focus to the browser and to the > notifying tab. > > To solve the lifetime issue: > -Torn-off tabs run in separate processes > -Processes may be re-skinned to appear as applications, but are really > tabs. > -Minimized/docked Processes taken off the taskbar/dock and into a > notification area or Application Manager > -If the rest of the browser is closed, the main process will stay on until > the application tabs are closed > -Browser's 'Application Manager' in notification area or taskbar/dock (and > as a button in the main browser) holds all open application tabs > > Have I forgotten anything? > Even without the application tabs, the notification process would be great > to implement. > One of the reasons I'm a proponent of running application script is the track record of one-size-fits-all, generic push solutions that are able to fulfill a broad range of use cases is fairly poor. If we are going to have the browser manage an incoming feed of push notifications, then I'd say at the very least we should allow web apps to register script handlers for those notifications, rather than try to build in static browser behavior. One could put limits on the execution of this script (perhaps only allow it to run for a limited period of time, for example), and provide UX to the end user such that there is transparency about the script running in the background of their browser. I agree that the UX and Security issues around always-on persistent script are formidable, but I still think it's valuable to experiment in this area to see whether they can be overcome. Regardless, I think it's premature to latch onto a single potential use case for persistent script (static text + icon calendar notifications) and start building extensive alternative mechanisms to satisfy that case. I think the takeaway from this thread is the recommendation that vendors could experiment in this area through the extension mechanism. I think once we've had a chance to build some app functionality on top of this, we'll have a better idea of the real-life use cases, and it would then be appropriate to see how/if those use cases could be satisfied in an alternate manner. -atw
Re: [whatwg] Installed Apps
On Wed, 29 Jul 2009, Michael Kozakewich wrote: > > How many applications do we expect any one user to have open? I would > imagine one would do fine on the Taskbar or in the Notification Area, > like other programs, but a manager would be good if a user had a great > deal of applications running at once. Realistically speaking, users will soon have many applications open if we make this available: Flickr, Mail, Calendar, Facebook, Reddit, Twitter, BBC News, their Bank, Google Voice, ... I would expect hundreds of sites to make use of such a feature. I have to say, I get confused by statements like this. If there are hundreds of sites that would find the feature useful, it sounds like a useful feature to have, one that fits in better with the way application writers understand to write applications. The perspectives I've heard in this thread basically say that 5 years from now, applications should be written such that there's a server in the browser, at which point I have to wonder why don't we go back to getting all the markup from the server and injecting it into the page? a
Re: [whatwg] Installed Apps
From: "Jonas Sicking" Sent: Friday, August 07, 2009 5:07 PM 2009/7/30 Ian Fette : That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or "status update" type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a "feed" of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server-side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background. But it could address a large chunk of the use cases with much less security risk. It addresses some use cases (calendar, perhaps), but I would still like to be able to e.g. keep my email up to date. Do I need the "full power" / "fully general" solution? I don't know, perhaps the push mechanism can be structured in a way that it gets into my database or whatever storage mechanism I am using for offline data storage? For the purpose of notification, it seems we have the following solutions: -Push message -SMS -RSS/Atom feed -Polling (Probably through JavaScript) Which will manifest in the following types of program: -Hidden browser page, Standalone browser tab, Persistent worker, or the browser's main background process, as part of the browser -Extraneous app or device (SMS to phone, or small-footprint desktop feed-reader) Any others you can add to those lists? (You can read the rest, or visit the summary near the bottom.) To go through the methods: RSS/Atom is usable at this very moment, as is JavaScript polling and SMS. SMS can be expensive, but Twitter has proven how useful it can be. I'm not sure what applications support push messages. Deciding where the messages appear is the tricky part: A low-footprint, invisible feed-reader app can be run in the background and pop up messages when they're received. This will require users to install third-party tools, which could integrate themselves with the browsers to open links or manage 'feeds'. Phones could be used to handle SMS notifications or push messages. The browsers could check for updates in a tab, but there are a couple things that need to change before this becomes feasible: 1) Browsers need to be able to pop up a notification in the corner, possibly with a link that sets focus to the notifying tab, 2) Browsers need to get the notifying tab out of the way, either by shrinking it to a notification area or by running it as a background process (where it can be accessed from the browser through some sort of Application Manager), and 3) Hidden tabs need to continue to run when the browser is closed (i.e. the browser's main process continues to run) until the hidden page is exited. It sounds like the browser could have a small background process that manages notifications, and a webapp (such as Gmail) could register with the browser's notification process. That could be separate from the idea of tearing off the webapp
Re: [whatwg] Installed Apps
2009/7/30 Ian Fette (イアンフェッティ) : >> That being said, I think there are valid use cases for out-of-band >> notifications, for example for calendar events or "status update" type >> applications such as Facebook or Twitter. >> >> I'd like to explore whether we can accommodate this notification use case >> without bringing the full power of the Web platform to bear, and thereby >> opening up a lot of attack surface on the client. Here's one rough sketch of >> an idea: >> >> * Notification Feeds * >> >> Often, web applications would like to give users the option to subscribe >> to notifications that occur at specific times or in response to server-side >> events, and for the user to get these UI notifications without a >> prerequisite that the web app is open or that the browser is running. There >> may be a desire to do client-side computation as well, but often just the >> ability to give the user a notification solves the basic user interaction >> problem. >> >> One possible way to address this kind of use case is to let users >> subscribe to a "feed" of notifications. This feed could use standard >> syndication formats, such as RSS or Atom. But instead of being displayed in >> a traditional feed reader, it's displayed in the form of transient >> notifications (along the lines of Growl on Mac OS X) which are posted for >> each new event. To allow some pre-scheduling of events, each item can have a >> date and won't be displayed until that date - this way a calendar can give >> you your feed of upcoming events and you can still get notifications when >> offline. In the case of something like email or Twitter, obviously there's >> no sensible way to get notifications when offline since they depend on >> unpredeictable server-side activity. There could even be a client-side API >> that lets a Web app schedule items on a subscribed notification feed from >> script, to enable scheduling calendar events offline. Each notification >> would have the option to unsubscribe from the notification feed, to reduce >> spam potential. >> >> Notice that this opens up a lot less attack surface. The user has to >> actively opt in to subscribing to the notification feed, just as for an RSS >> feed. This makes it much less likely they end up with a subscription to a >> shady site. And the notifications are passive data items (probably no script >> should be allowed in a notification, if the format is HTML and not just >> plain text), so they open up a lot less security risk. Obviously this is >> less powerful than the ability to run arbitrary code in the background. But >> it could address a large chunk of the use cases with much less security >> risk. > > It addresses some use cases (calendar, perhaps), but I would still like to > be able to e.g. keep my email up to date. Do I need the "full power" / > "fully general" solution? I don't know, perhaps the push mechanism can be > structured in a way that it gets into my database or whatever storage > mechanism I am using for offline data storage? I agree, however I don't think the solution is to allow a background webpage or something similar which has the full power of the web platform, and all the naughty things available to it. Instead I think it'd be great to have a protocol which allowed asynchronous updates to a client-side resource (or set of resources). There's nothing that would prevent this from happening over non-http protocols as well (such as SMS). / Jonas
Re: [whatwg] Installed Apps
On Tue, Aug 4, 2009 at 10:47 AM, Jeremy Orlow wrote: > > Which use case is this related to? If the shared worker is creating UI > elements for the page, then composing HTML and sicking it into a div's > .innerHTML is actually (sadly) the fastest way to go at the moment. Besides > that, I can't think of why you'd have some huge tree of information for the > gmail use case. > OK, imagine your inbox. It contains a set of emails organized into "threads", with various attributes and tags associated with them. Imagine your contacts, which has a set of individual contact entities, with chat status information updated dynamically, as well as group information for subsets of those contacts. I mean, look at the internals of any modern web app - they have data structures of a similar complexity to traditional apps. They aren't just conduits for HTML. > > >> Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to >> notifications (our vision for notifications is that they are scriptable and >> more interactive than just a dumb text + icon). >> > > What if the notification could have embedded links? If you make them too > powerful, you'll definitely see spam/ads/phishing/etc showing up in them. > For spam/ads,I think the problem is identical whether the ad is static or not static - the user has to enable notifications from some source, and when something shows up the user needs to have a way to block it if it's inappropriate. Agreed that scripting potentially enables some phishing exploits, depending on how the user is able to interact with the notification. If the notification can popup and say "Your gmail credentials have expired - please enter them here:" and allow you to type into the notification, then that's a potential phishing exploit. But a scriptable notification with restricted user interaction (i.e. no keyboard input allowed) would seem to be no more phish-able than a static notification. -atw >
Re: [whatwg] Installed Apps
It seems "persistent" and "preloading" aspects of the proposal are very hard to do considering security bounds of web browsing, there are scalability issues and people sometimes don't like the cost/benefit or obscurity (Netscape 6 etc). What about the "shared context with DOM access" idea which, even w/o persistency, seems to resolve some issues for apps like GMail? Like a shared worker, but with access to DOM. 1. It does not have security or "resources" issues since it's only up until the pages of the given app are up (same as shared worker) 2. It does rely on 'cooperative' pages to be opened in the same process but this is easy to implement. I mean, you can't 'guarantee' it (a page from another domain may have iframe pointing to the app and it will be in a diff. process) but any reasonable app can be easily structured in a way to get its views (pages) into a single process. 3. It would help to provide fast (meaning sub-100ms, interactively fast) UI responses necessary for the seamless operations. Persistent data storage and parsing/generating HTML (including loading all the code necessary to do that from the 'pure data') will always present challenge for sub-100ms UI actions - even in native apps it is a challenge today. Here is a typical use case: You compose a message in GMial window. Halfway through you decide to peek into another mail thread for more information. You click 'tear-off' button to "disconnect" the compose window so you can see other mail threads. Today, this opens a new window and starts loading XXX Kb of script into it. You see the progress indicator for a few seconds. This script is needed to be able to go to server and generate a proper UI from the response, as well as have all the 'controller' logic when user starts to interact with such UI. With shared context, you could just take the whole DOM subtree that forms a compose window UI and pass it, as is, into the new and empty window - with even handlers hooked into the shared context. It will just relayout and continue function. You have an 'instant' tear-off. Dmitry
Re: [whatwg] Installed Apps
On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > For example, we could base this on the EventSource mechanism or the > WebSocket mechanism, and define a protocol by which the server can at any > time send up either: > > An INSERT, UPDATE, or DELETE SQL statement > A string and a URL to show in a notification The idea of tying the notification spec to a particular brand of storage seems like a bad idea...especially at this point in time. I definitely like the idea of string based notifications. And I like the idea of having a fairly constrained form of updating state on the machine. On Tue, Aug 4, 2009 at 9:48 AM, Drew Wilson wrote: > > On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > >> >> I don't understand why workers can't reduce latency. What is the latency >> that must be reduced which workers can't help with? >> > > As I understand it, the big problems are 1) loading/parsing/executing > N-hundred K of javascript for an app like gmail is slow, 2) initializing > application data structures from data that must be sent down from the server > (or loaded from the database) is also slow (and by "slow", we may only be > talking on the order of hundreds of milliseconds). Workers don't do much for > either of these, especially when you are launching a web app for the first > time. > It seems like these are things UAs and Moore's law can address. For example, what if the UA was smart enough to cache compiled JavaScript (obviously with very smart invalidation routines...or even hooked into AppCache!). Sure, it's not easy, but there still seems to be a lot of head-room here. Also keep in mind that lots of web applicaitons think they're pretty important. Sure, giving gmail .1% of your system memory seems worth it. But how do you draw the line? What if I have 10 apps that want to do this? (Say...the top 10 sites on the internet.) Well, now I've just given up 1% of my ram. > > >> >> > SharedWorkers are overloaded to provide a way for pages under the same >> > domain to share state, but this seems like an orthogonal goal to >> > "parallel execution" and I suspect that we may have ended up with a >> > cleaner solution had we decided to address the "shared state" issue via >> > a separate mechanism. >> >> Shared state is addressed by the Web Storage and Web Database features; >> the shared workers are intended to provide shared computation. >> >> > Sure, although I'd say that "persistent storage is addressed by the Web > Storage and Web Database features". Shared state is also addressed, but > that's not the primary goal. If I have a tree of objects that I'd like to > share between two pages, telling me to serialize it into name/value string > pairs, write it into Web Storage, and then have the remote side read it out > is not a satisfying (or performant) solution. > Which use case is this related to? If the shared worker is creating UI elements for the page, then composing HTML and sicking it into a div's .innerHTML is actually (sadly) the fastest way to go at the moment. Besides that, I can't think of why you'd have some huge tree of information for the gmail use case. > Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to > notifications (our vision for notifications is that they are scriptable and > more interactive than just a dumb text + icon). > What if the notification could have embedded links? If you make them too powerful, you'll definitely see spam/ads/phishing/etc showing up in them. On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > > On Thu, 30 Jul 2009, Michael Davidson wrote: > > > > Here's a rough sketch of a more far-out idea: What if all browsers were > > XMPP clients and stanzas could be sent to display notifications? The > > attack surface would still be low, but you'd get realtime updates. > > Instead of subscribing to a feed of notifications, the user accepts what > > is essentially a chat invitation from the site. Like normal XMPP > > invitations, this would be revocable at any time. > > I'm not sure XMPP is the protocol I would jump to, but it's certainly an > option, yes. What don't you like about XMPP?
Re: [whatwg] Installed Apps
On Tue, Aug 4, 2009 at 12:48 PM, Drew Wilson wrote: > Yeah, this is an interesting idea, although I'm envisioning apps that > support offline use requiring what amounts to a sync process with > app-specific conflict resolution, etc - I think this would be difficult to > support with this kind of general platform. But, agreed, this is better than > nothing - at the very least, an application could use it to sync down > changes to a "staging area" for later resolution once the app itself starts > up. It could also be resolved server-side, if the requests are allowed to provide info about what data the client already has.
Re: [whatwg] Installed Apps
On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson wrote: > > It seems like a direct solution to these would be to have a way for Web > pages to expose a service that clients could subscribe to, which could > send up database updates and notifications. That way, no script runs on > the client, but the server can still update the client whenever needed. > Yeah, this is an interesting idea, although I'm envisioning apps that support offline use requiring what amounts to a sync process with app-specific conflict resolution, etc - I think this would be difficult to support with this kind of general platform. But, agreed, this is better than nothing - at the very least, an application could use it to sync down changes to a "staging area" for later resolution once the app itself starts up. > > I don't understand why workers can't reduce latency. What is the latency > that must be reduced which workers can't help with? > As I understand it, the big problems are 1) loading/parsing/executing N-hundred K of javascript for an app like gmail is slow, 2) initializing application data structures from data that must be sent down from the server (or loaded from the database) is also slow (and by "slow", we may only be talking on the order of hundreds of milliseconds). Workers don't do much for either of these, especially when you are launching a web app for the first time. > > > SharedWorkers are overloaded to provide a way for pages under the same > > domain to share state, but this seems like an orthogonal goal to > > "parallel execution" and I suspect that we may have ended up with a > > cleaner solution had we decided to address the "shared state" issue via > > a separate mechanism. > > Shared state is addressed by the Web Storage and Web Database features; > the shared workers are intended to provide shared computation. > > Sure, although I'd say that "persistent storage is addressed by the Web Storage and Web Database features". Shared state is also addressed, but that's not the primary goal. If I have a tree of objects that I'd like to share between two pages, telling me to serialize it into name/value string pairs, write it into Web Storage, and then have the remote side read it out is not a satisfying (or performant) solution. > > > So (and forgive me for restating), it seems like hidden page addresses > the > > following problems that gmail and other large web apps are having: > > > > 1) Loading large amounts of Javascript is slow, even from cache. > > The solution is to make loading the JS faster, not to load it and use the > user's resources regardless. > I agree. I don't think that forcing pages to stay resident to reduce JS load times is a good solution. An ideal solution would be for browsers to be inherently faster, to enable this for the entire web, not just for "installed apps". > > > 2) Loading application state from the database is slow. > > I don't see how a hidden window can solve this. Could you elaborate? > The data would be always cached in memory and shared across instances. But, yeah, Netscape 6, etc. My expectation for persistent workers was that these workers would try to have a minimal ram footprint, for exactly that reason (used primarily for generating notifications and keeping the data store in sync with the server, not as a persistent memory cache). > > > 4) There's no way to do things like new mail notifications, calendar > > notifications, local updates of your email inbox, etc when the browser > > is not open. > > It seems a system dedicated to this could solve this problem in a much > simpler and more efficient way than running background windows. > Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to notifications (our vision for notifications is that they are scriptable and more interactive than just a dumb text + icon). But it's possible that a simple static feed may cover some portion of the use cases - hopefully we'll have more real-world use cases once the webkit notification API ships in a browser. Additionally, any server-side-feed-based solution has the implication that it won't work for offline apps. If I am using a web calendar, I want my event notifications regardless of whether I'm online or offline (the event may have been added while I'm offline and never synced to the server at all). -atw
Re: [whatwg] Installed Apps
On Tue, Aug 4, 2009 at 1:08 AM, Mike Wilson wrote: > Michael Nordman wrote: > > On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote: > > > Btw, another reflection is that this mail thread is about > > > introducing a client/server model in the browser. Some > > > mentions of complex code in the background page, f ex building > > > the HTML for the visible window, make me think of traditional > > > server-centric webapps, but inside the browser. I've made > > > the below table to illustrate this, and I mean to point out > > > similarities between traditional server-centric and the new > > > background_page-centric webapps, and between client-centric > > > and visible-centric webapps. Maybe this can inspire some new > > > thoughts. > > > > Yes... client/server model in the browser... good observation... and a > > good way to think about the direction I would like to see things go. > > Incidentally, that line of thinking is my motivation for the > > introduction of script-generated responses in this (HTML5) system > > design. > > Ah, I seem to have missed that. Makes total sense for offline > as it probably makes it a lot easier to port server-centric > apps to the cache, and well, there is already a concept of > serving files (although only static). > > It's not a small thing to add, but if this is taken further I > think coordination should be done with current inititatives > using JS in server-side web platform designs, such as: > ServerJS WSGI https://wiki.mozilla.org/ServerJS/WSGI >(several products pointed to by comparison table) > Joyent Smart http://becoming.smart.joyent.com/index.html > + other stuff using EnvJS, etc... > > This would make it easier to move code between server and > client, simplifying creation of distributed and offline apps. Exactly! (and thnx for the pointers)
Re: [whatwg] Installed Apps
Michael Nordman wrote: > On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote: > > Btw, another reflection is that this mail thread is about > > introducing a client/server model in the browser. Some > > mentions of complex code in the background page, f ex building > > the HTML for the visible window, make me think of traditional > > server-centric webapps, but inside the browser. I've made > > the below table to illustrate this, and I mean to point out > > similarities between traditional server-centric and the new > > background_page-centric webapps, and between client-centric > > and visible-centric webapps. Maybe this can inspire some new > > thoughts. > > Yes... client/server model in the browser... good observation... and a > good way to think about the direction I would like to see things go. > Incidentally, that line of thinking is my motivation for the > introduction of script-generated responses in this (HTML5) system > design. Ah, I seem to have missed that. Makes total sense for offline as it probably makes it a lot easier to port server-centric apps to the cache, and well, there is already a concept of serving files (although only static). It's not a small thing to add, but if this is taken further I think coordination should be done with current inititatives using JS in server-side web platform designs, such as: ServerJS WSGI https://wiki.mozilla.org/ServerJS/WSGI (several products pointed to by comparison table) Joyent Smart http://becoming.smart.joyent.com/index.html + other stuff using EnvJS, etc... This would make it easier to move code between server and client, simplifying creation of distributed and offline apps. > > Remote Background Visible > > server page page > > -- -- --- > > > > Current webapp designs: > > > > server- state > > centric logic > > (bugzilla) gen HTML -> render > > > > client- state -> state > > centric logic > > (gmail) gen/render HTML > > > > New "background page" client-centric designs: > > > > background- state -> state > > centric logic > > gen HTML -> render > > > > visible- state -> state -> state > > centric (logic) logic > > gen/render HTML Best regards Mike
Re: [whatwg] Installed Apps
On Mon, 27 Jul 2009, Michael Davidson wrote: > > -- Slow startup: When a user navigates to mail.google.com, multiple > server requests are required to render the page. The Javascript is > cacheable, but personal data (e.g. the list of emails to show) is not. > New releases of Gmail that require JS downloads are even slower to load. The offline app cache allows you to cache the JS and have new releases be downloaded in the background while the user uses the old version. Client-side databases allow data to be cached client-side. This leaves how to get new data to the client before the client has loaded. > -- Native apps like Outlook can (and do) run background processes on the > user's machine to make sure that data is always up-to-date. That would be one way to update the cached data before the client runs. > -- Notifications: Likewise, Outlook can notify users (via a background > process) when new mail comes in even if it's not running. HTML5 used to have a notifications API, but it was removed due to lack of implementor interest. So there seem to be two problems here: - how to update a client-side database in the background when the app isn't loaded, such that the data is up to date when the page is opened, - how to pop up notifications while the page is not loaded. It seems like a direct solution to these would be to have a way for Web pages to expose a service that clients could subscribe to, which could send up database updates and notifications. That way, no script runs on the client, but the server can still update the client whenever needed. For example, we could base this on the EventSource mechanism or the WebSocket mechanism, and define a protocol by which the server can at any time send up either: An INSERT, UPDATE, or DELETE SQL statement A string and a URL to show in a notification The client would then open a connection to this service whenever it was open, and the server would update the database and send notifications as desired. The UA could then easily show in its UI that a remote server is updating data or showing a notification, and make it trivial for the user to unsubscribe from the relevant feaure. This seems far less problematic than background processes, which have a host of problems: - they have unfortunate implications in multiprocess UAs (see below) - they are extremely susceptible to being co-opted for malware, e.g. using CPU resources for computation without the user's knowledge - the permission UI is unproven - it doesn't really scale when hundreds of sites want to use the feature - it's not a good solution for performance problems (see anecdote about Netscape 6 below) On Mon, 27 Jul 2009, David Levin wrote: > > It sounds like most of the concerns are about the 2nd part of this > proposal: allowing a background page to continue running after the > visible page has been closed. > > However, the first part sounds like it alone would be useful to web > applications like GMail: > > The first, which should begenerally useful, is the ability to have a > hidden HTML/JS page running in the background that can access the DOM of > visible windows. This page should be accessible from windows that the > user navigates to. We call this background Javascript window a "shared > context" or a "background page". This will enable multiple instances of > a web app (e.g. tearoff windows in Gmail) to cleanly access the same > user state no matter which windows are open. As far as I can tell, we can't ever have a scripting context that can access the DOMs of all pages in the same domain, since that would force those pages into the same process, which is an assumption that is already violated by IE (and, I believe, Chrome). Also, since anything in the same browsing context typically has to be in the same process for sanity (accessing the Window object hierarchy is synchronous), and since many sites have s to common sites (e.g. ad networks) you very quickly end up dragging many sites into the same process if you go down this road. So I don't think that's really workable. > + restrict things to the same security origin. > > It sounds similar in concept to a share worker except that it runs in > the main thread and is more concerned with dom manipulation/state while > workers have typically been thought of as allowing background > processing. > > It seems that the lifetime of this could be scoped, so that it dies when > it isn't referenced (in a similar way to how shared worker lifetime is > scoped). It doesn't seem that having a lifetime-limited hidden window would address any of the problems listed at the top of this thread: - how to update a client-side database in the background when the app isn't loaded, such that the data is up to date when the page is opened, - how to pop up notifications while the page is not loaded. On Tue, 28 Jul 2009, Michael Nordman wrote: > > What if a sharedCont
Re: [whatwg] Installed Apps
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote: > Michael Nordman wrote: >> >> On Mon, Aug 3, 2009 at 3:05 AM, Mike >> Wilson wrote: >> > >> > Assuming this shared state doesn't require a full >> > JavaScript global context, and could do with some >> > root object or collection, would it be possible to >> > extend Web Storage to support this task? >> >> A big part of what the Gmail team is interested in sharing is quite a >> lot of javascript (loaded, parsed, jit'd... ready to call functions). >> Along with that, the app can maintian shared state as well, but a big >> part of this feature request is sharing the code itself. In the >> absence of JS languange changes (analogous to DLLs or SOs for JS), I >> think this does call for a full JS context. > > Right, with your scenario, that makes use of all these new > features in the same app, that could make sense. Still, it > would be interesting to look at how each feature could be > implemented on its own, to potentially lessen the overhead > for apps that only use a single feature. > > These are the individual features discussed so far, I think > (did I miss any?): > - "preload" JavaScript code > - share "live" data between multiple pages > - background process with direct access to UI > - background process that outlives browser process > - background process that auto-starts with operating system > - access to notification area > > I can easily imagine separate use of the first two items, > and I think it would be great to address the data handling > in a coherent way with other state handling. It would be > nice to have finer-grained control over data handling than > having to "pop" a new window to use its global context. > > Btw, another reflection is that this mail thread is about > introducing a client/server model in the browser. Some > mentions of complex code in the background page, f ex building > the HTML for the visible window, make me think of traditional > server-centric webapps, but inside the browser. I've made > the below table to illustrate this, and I mean to point out > similarities between traditional server-centric and the new > background_page-centric webapps, and between client-centric > and visible-centric webapps. Maybe this can inspire some new > thoughts. Yes... client/server model in the browser... good observation... and a good way to think about the direction I would like to see things go. Incidentally, that line of thinking is my motivation for the introduction of script-generated responses in this (HTML5) system design. > > Remote Background Visible > server page page > -- -- --- > > Current webapp designs: > > server- state > centric logic > (bugzilla) gen HTML -> render > > client- state -> state > centric logic > (gmail) gen/render HTML > > New "background page" client-centric designs: > > background- state -> state > centric logic > gen HTML -> render > > visible- state -> state -> state > centric (logic) logic > gen/render HTML > > mvh Mike > >
Re: [whatwg] Installed Apps
Michael Nordman wrote: > > On Mon, Aug 3, 2009 at 3:05 AM, Mike > Wilson wrote: > > > > Assuming this shared state doesn't require a full > > JavaScript global context, and could do with some > > root object or collection, would it be possible to > > extend Web Storage to support this task? > > A big part of what the Gmail team is interested in sharing is quite a > lot of javascript (loaded, parsed, jit'd... ready to call functions). > Along with that, the app can maintian shared state as well, but a big > part of this feature request is sharing the code itself. In the > absence of JS languange changes (analogous to DLLs or SOs for JS), I > think this does call for a full JS context. Right, with your scenario, that makes use of all these new features in the same app, that could make sense. Still, it would be interesting to look at how each feature could be implemented on its own, to potentially lessen the overhead for apps that only use a single feature. These are the individual features discussed so far, I think (did I miss any?): - "preload" JavaScript code - share "live" data between multiple pages - background process with direct access to UI - background process that outlives browser process - background process that auto-starts with operating system - access to notification area I can easily imagine separate use of the first two items, and I think it would be great to address the data handling in a coherent way with other state handling. It would be nice to have finer-grained control over data handling than having to "pop" a new window to use its global context. Btw, another reflection is that this mail thread is about introducing a client/server model in the browser. Some mentions of complex code in the background page, f ex building the HTML for the visible window, make me think of traditional server-centric webapps, but inside the browser. I've made the below table to illustrate this, and I mean to point out similarities between traditional server-centric and the new background_page-centric webapps, and between client-centric and visible-centric webapps. Maybe this can inspire some new thoughts. Remote Background Visible server page page -- -- --- Current webapp designs: server- state centric logic (bugzilla) gen HTML -> render client- state -> state centric logic (gmail) gen/render HTML New "background page" client-centric designs: background- state ->state centric logic gen HTML -> render visible-state ->state -> state centric (logic) logic gen/render HTML mvh Mike
Re: [whatwg] Installed Apps
On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilson wrote: > Drew Wilson wrote: >> >> SharedWorkers are overloaded to provide a way for >> pages under the same domain to share state, but >> this seems like an orthogonal goal to "parallel >> execution" and I suspect that we may have ended >> up with a cleaner solution had we decided to >> address the "shared state" issue via a separate >> mechanism. >> >> [...] >> >> 3) Sharing between pages requires going through >> the database or shared worker - you can't just >> party on a big shared datastructure. > > Assuming this shared state doesn't require a full > JavaScript global context, and could do with some > root object or collection, would it be possible to > extend Web Storage to support this task? A big part of what the Gmail team is interested in sharing is quite a lot of javascript (loaded, parsed, jit'd... ready to call functions). Along with that, the app can maintian shared state as well, but a big part of this feature request is sharing the code itself. In the absence of JS languange changes (analogous to DLLs or SOs for JS), I think this does call for a full JS context.
Re: [whatwg] Installed Apps
Drew Wilson wrote: > > SharedWorkers are overloaded to provide a way for > pages under the same domain to share state, but > this seems like an orthogonal goal to "parallel > execution" and I suspect that we may have ended > up with a cleaner solution had we decided to > address the "shared state" issue via a separate > mechanism. > > [...] > > 3) Sharing between pages requires going through > the database or shared worker - you can't just > party on a big shared datastructure. Assuming this shared state doesn't require a full JavaScript global context, and could do with some root object or collection, would it be possible to extend Web Storage to support this task? Best regards Mike Wilson
Re: [whatwg] Installed Apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/30/09 7:26 PM, Michael Davidson wrote: > On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote: >> * Notification Feeds * >> >> Often, web applications would like to give users the option to subscribe to >> notifications that occur at specific times or in response to server-side >> events, and for the user to get these UI notifications without a >> prerequisite that the web app is open or that the browser is running. There >> may be a desire to do client-side computation as well, but often just the >> ability to give the user a notification solves the basic user interaction >> problem. >> >> One possible way to address this kind of use case is to let users subscribe >> to a "feed" of notifications. This feed could use standard syndication >> formats, such as RSS or Atom. But instead of being displayed in a > > This is an interesting idea. The lack of push updates, though, would > make it much less useful than it could be. > > Here's a rough sketch of a more far-out idea: What if all browsers > were XMPP clients and stanzas could be sent to display notifications? > The attack surface would still be low, but you'd get realtime updates. > Instead of subscribing to a feed of notifications, the user accepts > what is essentially a chat invitation from the site. Like normal XMPP > invitations, this would be revocable at any time. > > Lots of issues to work out, but you'd get realtime for free. We're working on that over in the XMPP community... :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpyMTMACgkQNL8k5A2w/vwKNgCg+8q/BEv4jZzKbhMZ7Vz6pDFR iygAnjUJGy0Sn/hA4iTxrX46W6A5VGuf =qetP -END PGP SIGNATURE-
Re: [whatwg] Installed Apps
2009/7/29 Maciej Stachowiak > > On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote: > > Hello folks - >> >> I'm an engineer on the Gmail team. We've been working on a prototype >> with the Chrome team to make the Gmail experience better. We thought >> we'd throw out our ideas to the list to get some feedback. >> >> THE PROBLEM >> >> We would like to enable rich internet applications to achieve feature >> parity with desktop applications. I will use Gmail and Outlook as >> examples for stating the problems we hope to solve. >> > > I already commented on the security risks of the proposed solution, but I'd > also like to examine the use cases more closely. "Feature parity with > desktop applications" is pretty open-ended, and it might be that the actual > concrete use cases can be addressed with less general mechanisms. > > -- Slow startup: When a user navigates to mail.google.com, multiple >> server requests are required to render the page. The Javascript is >> cacheable, but personal data (e.g. the list of emails to show) is not. >> New releases of Gmail that require JS downloads are even slower to >> load. >> > > Caching the code part of GMail, and making loading fast in the face of > updates, seems like a problem that can be solved by the HTML5 Application > Cache. Maybe it would be more fruitful to study further improvements in > startup speed once GMail has adopted AppCache. > > -- Native apps like Outlook can (and do) run background processes on >> the user's machine to make sure that data is always up-to-date. >> -- Notifications: Likewise, Outlook can notify users (via a background >> process) when new mail comes in even if it's not running. >> > > I'm not sure it's justifiable to say these features are required for a > native-like experience. The Mail application on Mac OS X only fetches new > mail and gives you new mail notifications while it is actually running. > Users who want to know about new mail right away keep the app open, and > users who would like to free up resources quit it. It seems like GMail can > already get rough parity with this experience. > Depends on the device. If you're on Android (or I suspect iPhone, although I don't have one), doesn't the device sync your email constantly in the background? If I am a web-based email provider, I would like to have a similar option. Especially on something like the iPhone or Android, where I don't think it's reasonable to expect them to keep the browser open all the time (as the browser will just get closed if some other active app applies memory pressure). > > That being said, I think there are valid use cases for out-of-band > notifications, for example for calendar events or "status update" type > applications such as Facebook or Twitter. > > I'd like to explore whether we can accommodate this notification use case > without bringing the full power of the Web platform to bear, and thereby > opening up a lot of attack surface on the client. Here's one rough sketch of > an idea: > > * Notification Feeds * > > Often, web applications would like to give users the option to subscribe to > notifications that occur at specific times or in response to server-side > events, and for the user to get these UI notifications without a > prerequisite that the web app is open or that the browser is running. There > may be a desire to do client-side computation as well, but often just the > ability to give the user a notification solves the basic user interaction > problem. > > One possible way to address this kind of use case is to let users subscribe > to a "feed" of notifications. This feed could use standard syndication > formats, such as RSS or Atom. But instead of being displayed in a > traditional feed reader, it's displayed in the form of transient > notifications (along the lines of Growl on Mac OS X) which are posted for > each new event. To allow some pre-scheduling of events, each item can have a > date and won't be displayed until that date - this way a calendar can give > you your feed of upcoming events and you can still get notifications when > offline. In the case of something like email or Twitter, obviously there's > no sensible way to get notifications when offline since they depend on > unpredeictable server-side activity. There could even be a client-side API > that lets a Web app schedule items on a subscribed notification feed from > script, to enable scheduling calendar events offline. Each notification > would have the option to unsubscribe from the notification feed, to reduce > spam potential. > > Notice that this opens up a lot less attack surface. The user has to > actively opt in to subscribing to the notification feed, just as for an RSS > feed. This makes it much less likely they end up with a subscription to a > shady site. And the notifications are passive data items (probably no script > should be allowed in a notification, if the format is HTML and not just > plain text), so they open up a lot less security
Re: [whatwg] Installed Apps
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. So lets put that to practice on this particular two-part proposal... > Our proposed solution has two parts. 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. > The first, which should be > generally useful, is the ability to have a hidden HTML/JS page running > in the background that can access the DOM of visible windows. This > page should be accessible from windows that the user navigates to. We > call this background Javascript window a "shared context" or a > "background page". This will enable multiple instances of a web app > (e.g. tearoff windows in Gmail) to cleanly access the same user state > no matter which windows are open. This second part (below) would only be accessible after out-of-band trust and permissioning mechansims got tickled. > Additionally, we'd like this background page to continue to run after > the user has navigated away from the site, and preferably after the > user has closed the browser. This will enable us to keep client-side > data up-to-date on the user's machine. It will also enable us to > download JS in advance. When the user navigates to a web app, all the > background page has to do is draw the DOM in the visible window. This > should significantly speed up app startup. Additionally, when > something happens that requires notification, the background page can > launch a visible page with a notification (or use other rich APIs for > showing notifications). (aside... begs the question... when will that extension mechanism be standardized :) On Thu, Jul 30, 2009 at 1:49 PM, Dmitry Titov wrote: > 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'. > 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. > > 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 :-) > > Dmitry > > > > On Thu, Jul 30, 2009 at 1:23 PM, Drew Wilson wrote: > >> 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". >> 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). >> >> 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). >> >> So arguing "but it's the same UI either way!" is not going to convince >> anyone. >> >> -atw >> >> On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov wrote: >> >>> 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. >>> 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? >>> >>> 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 >>>
Re: [whatwg] Installed Apps
On Thu, Jul 30, 2009 at 3:49 PM, Dmitry Titov wrote: > 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'. > 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. This already exists - I mentioned previously the Firefox Jetpack extension, which is literally a "hidden page" that can play with the DOM of existing pages, and even includes things like jQuery and a couple of popular web service APIs (like Twitter and Gmail) for you. ~TJ
Re: [whatwg] Installed Apps
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'. 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. 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 :-) Dmitry On Thu, Jul 30, 2009 at 1:23 PM, Drew Wilson wrote: > 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". > 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). > > 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). > > So arguing "but it's the same UI either way!" is not going to convince > anyone. > > -atw > > On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov wrote: > >> 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. >> 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? >> >> 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. >> >> 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 :-) >> >> 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. >> >> 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. >> >> But for now, it should be ok to have it 'installed' with a specific >> browser dialog that asks t
Re: [whatwg] Installed Apps
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". 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). 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). So arguing "but it's the same UI either way!" is not going to convince anyone. -atw On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov wrote: > 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. > 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? > > 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. > > 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 :-) > > 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. > > 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. > > 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. > > 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. > > Dmitry > > > On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson wrote: > >> On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote: >> > * Notification Feeds * >> > >> > Often, web applications would like to give users the option to subscribe >> to >> > notifications that occur at specific times or in response to server-side >> > events, and for the user to get these UI notifications without a >> > prerequisite that the web app is open or that the browser is running. >> There >> > may be a desire to do client-side computation as well, but of
Re: [whatwg] Installed Apps
On Thu, Jul 30, 2009 at 3:51 PM, Dmitry Titov wrote: > 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? > 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. 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. 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 :-) > 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. Ojan > > 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. > > 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. > > 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. > > 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. > > Dmitry > > > On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson wrote: > >> On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote: >> > * Notification Feeds * >> > >> > Often, web applications would like to give users the option to subscribe >> to >> > notifications that occur at specific times or in response to server-side >> > events, and for the user to get these UI notifications without a >> > prerequisite that the web app is open or that the browser is running. >> There >> > may be a desire to do client-side computation as well, but often just >> the >> > ability to give the user a notification solves the basic user >> interaction >> > problem. >> > >> > One possible way to address this kind of use case is to let users >> subscribe >> > to a "feed" of notifications. This feed could use standard syndication >> > formats, such as RSS or Atom. But instead of being displayed in a >> >> This is an interesting idea. The lack of push updates, though, would >> make it much less useful than it could be. >> >> Here's a rough sketch of a more far-out idea: What if all browsers >> were XMPP clients and stanzas could be sent to display notifications? >> The attack surface would still be low, but you'd get realtime updates. >> Instead of subscribing to a feed of notifications, the user accepts >> what is essentially a chat invitation from the site. Like normal XMPP >> invitations, this would be revocable at any time. >> >> Lots of
Re: [whatwg] Installed Apps
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. 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? 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. 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 :-) 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. 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. 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. 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. Dmitry On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson wrote: > On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote: > > * Notification Feeds * > > > > Often, web applications would like to give users the option to subscribe > to > > notifications that occur at specific times or in response to server-side > > events, and for the user to get these UI notifications without a > > prerequisite that the web app is open or that the browser is running. > There > > may be a desire to do client-side computation as well, but often just the > > ability to give the user a notification solves the basic user interaction > > problem. > > > > One possible way to address this kind of use case is to let users > subscribe > > to a "feed" of notifications. This feed could use standard syndication > > formats, such as RSS or Atom. But instead of being displayed in a > > This is an interesting idea. The lack of push updates, though, would > make it much less useful than it could be. > > Here's a rough sketch of a more far-out idea: What if all browsers > were XMPP clients and stanzas could be sent to display notifications? > The attack surface would still be low, but you'd get realtime updates. > Instead of subscribing to a feed of notifications, the user accepts > what is essentially a chat invitation from the site. Like normal XMPP > invitations, this would be revocable at any time. > > Lots of issues to work out, but you'd get realtime for free. > > Michael >
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiak wrote: > * Notification Feeds * > > Often, web applications would like to give users the option to subscribe to > notifications that occur at specific times or in response to server-side > events, and for the user to get these UI notifications without a > prerequisite that the web app is open or that the browser is running. There > may be a desire to do client-side computation as well, but often just the > ability to give the user a notification solves the basic user interaction > problem. > > One possible way to address this kind of use case is to let users subscribe > to a "feed" of notifications. This feed could use standard syndication > formats, such as RSS or Atom. But instead of being displayed in a This is an interesting idea. The lack of push updates, though, would make it much less useful than it could be. Here's a rough sketch of a more far-out idea: What if all browsers were XMPP clients and stanzas could be sent to display notifications? The attack surface would still be low, but you'd get realtime updates. Instead of subscribing to a feed of notifications, the user accepts what is essentially a chat invitation from the site. Like normal XMPP invitations, this would be revocable at any time. Lots of issues to work out, but you'd get realtime for free. Michael
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote: Hello folks - I'm an engineer on the Gmail team. We've been working on a prototype with the Chrome team to make the Gmail experience better. We thought we'd throw out our ideas to the list to get some feedback. THE PROBLEM We would like to enable rich internet applications to achieve feature parity with desktop applications. I will use Gmail and Outlook as examples for stating the problems we hope to solve. I already commented on the security risks of the proposed solution, but I'd also like to examine the use cases more closely. "Feature parity with desktop applications" is pretty open-ended, and it might be that the actual concrete use cases can be addressed with less general mechanisms. -- Slow startup: When a user navigates to mail.google.com, multiple server requests are required to render the page. The Javascript is cacheable, but personal data (e.g. the list of emails to show) is not. New releases of Gmail that require JS downloads are even slower to load. Caching the code part of GMail, and making loading fast in the face of updates, seems like a problem that can be solved by the HTML5 Application Cache. Maybe it would be more fruitful to study further improvements in startup speed once GMail has adopted AppCache. -- Native apps like Outlook can (and do) run background processes on the user's machine to make sure that data is always up-to-date. -- Notifications: Likewise, Outlook can notify users (via a background process) when new mail comes in even if it's not running. I'm not sure it's justifiable to say these features are required for a native-like experience. The Mail application on Mac OS X only fetches new mail and gives you new mail notifications while it is actually running. Users who want to know about new mail right away keep the app open, and users who would like to free up resources quit it. It seems like GMail can already get rough parity with this experience. That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or "status update" type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a "feed" of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server- side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background. But it could address a large chunk of the use cases with much less security risk. I'd like us to think along these kinds of lines when expanding the web platform. Often there is a low-power alternative to fully general solutions, which addresses many of the same use cases. By proceeding in this manner, we can extend the power of the web platform without neutering its desirable security properties. Regards, Maciej
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote: > On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote: > >> On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. >> wrote: >> > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson >> wrote: >> >> With a hidden page that's accessible to all Google Finance visible >> >> pages, they could share a connection to the server. Even if the hidden >> >> page is closed when the last Google Finance page is closed, this is a >> >> better situation than we currently have. >> > >> > Can't SharedWorkers do that right now? If all you're doing is polling >> > for data, it seems like you don't need all the extra stuff that these >> > various proposals are offering. >> >> It's my contention that frequently large web apps are doing more than >> just polling for data. They're trying to maintain complex data >> structures that they pass up to the UI. The programming model of >> SharedWorkers makes this difficult. Take the chat client in Gmail, for >> example. It's much more complex than passing stock quotes from a >> worker to the UI. > > > I understand that this isn't helpful for existing web apps like Gmail, but > I think a MVC type model will work pretty nicely with shared workers. It's > just the transition phase that's going to be painful. > > This idea of a hidden page just seems like a big hack to support today's > applications. If it were adapted into the spec, I think 5 years from now > we'd be very sorry that it was. > I disagree. The proposal plays to the strenths of the web platform. HTML parsing, layout, and rendering is very optimized, much more so than programmatic HTML DOM manipulation. The incorporation of stateful script contexts within each page considerably slows page loading. As navigations occur, that statefullness has to be reconstructed from scratch. In addition to creating and populating a new script context with the
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote: > I understand that this isn't helpful for existing web apps like Gmail, but I > think a MVC type model will work pretty nicely with shared workers. It's > just the transition phase that's going to be painful. In most MVC frameworks that I'm aware of, you can make a synchronous call from M up to V or V down to M. It's not just MVC, it's MVC where the C is entirely asynchronous. Michael
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote: > On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. > wrote: > > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: > >> With a hidden page that's accessible to all Google Finance visible > >> pages, they could share a connection to the server. Even if the hidden > >> page is closed when the last Google Finance page is closed, this is a > >> better situation than we currently have. > > > > Can't SharedWorkers do that right now? If all you're doing is polling > > for data, it seems like you don't need all the extra stuff that these > > various proposals are offering. > > It's my contention that frequently large web apps are doing more than > just polling for data. They're trying to maintain complex data > structures that they pass up to the UI. The programming model of > SharedWorkers makes this difficult. Take the chat client in Gmail, for > example. It's much more complex than passing stock quotes from a > worker to the UI. I understand that this isn't helpful for existing web apps like Gmail, but I think a MVC type model will work pretty nicely with shared workers. It's just the transition phase that's going to be painful. This idea of a hidden page just seems like a big hack to support today's applications. If it were adapted into the spec, I think 5 years from now we'd be very sorry that it was. The other APIs we've been talking about that satisfy the requirements that were originally broken out by Drew seem like much more sustainable solutions. J
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. wrote: > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: >> With a hidden page that's accessible to all Google Finance visible >> pages, they could share a connection to the server. Even if the hidden >> page is closed when the last Google Finance page is closed, this is a >> better situation than we currently have. > > Can't SharedWorkers do that right now? If all you're doing is polling > for data, it seems like you don't need all the extra stuff that these > various proposals are offering. It's my contention that frequently large web apps are doing more than just polling for data. They're trying to maintain complex data structures that they pass up to the UI. The programming model of SharedWorkers makes this difficult. Take the chat client in Gmail, for example. It's much more complex than passing stock quotes from a worker to the UI. Michael
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: > Here's something that hidden pages can help with that this solution can't: > > Let's say you're watching ten stocks on Google Finance, each in their > own window. > > Right now, each page has to have its own connection to the server. > Since these are polling connections, the experience is going to be > very bad. > > With a hidden page that's accessible to all Google Finance visible > pages, they could share a connection to the server. Even if the hidden > page is closed when the last Google Finance page is closed, this is a > better situation than we currently have. Can't SharedWorkers do that right now? If all you're doing is polling for data, it seems like you don't need all the extra stuff that these various proposals are offering. ~TJ
Re: [whatwg] Installed Apps
As another data point, the aforementioned Jetpack addon for Firefox actually *does* run in a hidden page. "about:jetpack" is *always* present while the add-on is installed, but hidden if you haven't explicitly pointed a tab at that url. This doesn't allow it to persist outside of the browser, but it does allow it to persist outside of the page. ~TJ
Re: [whatwg] Installed Apps
Here's something that hidden pages can help with that this solution can't: Let's say you're watching ten stocks on Google Finance, each in their own window. Right now, each page has to have its own connection to the server. Since these are polling connections, the experience is going to be very bad. With a hidden page that's accessible to all Google Finance visible pages, they could share a connection to the server. Even if the hidden page is closed when the last Google Finance page is closed, this is a better situation than we currently have. Michael
Re: [whatwg] Installed Apps
From: Drew Wilson
Sent: Wednesday, July 29, 2009 11:56 AM
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich
wrote:
-- Notifications: I don't think I've ever had Outlook notify me of new mail
when it's not running. It usually starts up with Windows, and it runs in the
background. If you turn it off from the tray, it stops.
The way I've envisioned any of these "persistent running workers/pages"
operating is the browser would have a status bar icon which would allow
background apps to display status, and also give the user the opportunity to
exit the browser or (possibly) close down individual apps. So it's a very
similar situation.
Have you ever used Chrome's 'Create Application Shortcuts...'? It's pretty neat
how they work. You get a mini UI with an option button (also the favicon), the
title, and the mimize/maximize/close buttons. The rest is the site itself. It's
actually a modified browser tab, but you'd never know it just by looking at it.
I can close Chrome, and that one modified tab with Google Reader will still be
open. I've sized it to fit in a specific part of my desktop, so it's really
completely separate from the browser (except that, if you look in Task Manager,
the main browser process remains open, invisibly, in the background). It even
keeps my sizing and positioning preferences, so it'll open in the same place
next time I open it. I've got a shortcut to it on my Quick Launch bar, set to a
fancy 'Web 2.0' RSS icon. Every once in a while, I can glance to the title of
the 'application' or my Taskbar, and the number of new feeds is auto-updated
right there. I don't think it can pop up a notification, yet, but I'd love it
to play a sound when it finds more feeds.
If you want, you can also click the favicon (or right click on its taskbar
button) and select "Show as Tab" from the menu, then drag that into the browser
with the rest of your tabs.
The salient bits:
-Browser interface is gone: lets the page have its own navigation/toolbars.
-In the background is a hidden process, which writes the DOM and keeps the
window open.
-That background process isn't a hidden page, but rather the browser process
itself.
-You can open it with a link, which can starts with Windows if put in the
Startup folder.
-It can be given a custom icon.
The problems:
-No notification messages
-No minimization to the notification area
-95% of the web can't use it without switching browsers.
The solution:
-Get other browsers to adopt certain elements from this
-Get everyone to agree on a notification API
-Allow the option of minimizing to notification area ("Hide window when
minimized").
What I'd like is to hear of anything this doesn't solve. Can invisible pages do
anything that the invisible browser can't? An invisible page controlling a
visible page would still need the browser to be open, so we'd actually have one
less page open if it was just the browser and the page. Browsers could also add
an option where they'd secretly stay on in the background, without being any
less secure than it would be to have your browser sitting open right now.
Is it easier that we ask browser vendors to implement these changes, or to
create the whole hidden-page spec?
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 12:54 PM, Drew Wilson wrote: > My understanding (when I looked at Prism a while back) was that it was > essentially no different than a desktop shortcut that ran the page in a > separate profile. Has this changed? It runs a webpage in a separate process, in a special environment with minimal chrome, elevated privileges and a few other changes from a browser. Running in a separate process means that it's not affected by browser closings or crashes. On the wishlist for features is the ability to have a taskbar icon with balloon popups. ~TJ
Re: [whatwg] Installed Apps
My understanding (when I looked at Prism a while back) was that it was essentially no different than a desktop shortcut that ran the page in a separate profile. Has this changed? -atw On Wed, Jul 29, 2009 at 10:21 AM, timeless wrote: > On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote: > > What I'd like, as a user, is some way to pin selected apps to run in the > > background - whether that's something I initiate through the UI myself, > or > > via a prompt from the application is really a matter of UX. > > in my book, you're definitely asking for prism. > > http://labs.mozilla.com/projects/prism/ > https://wiki.mozilla.org/prism > > and here's a prism link for google calendar: > http://starkravingfinkle.org/projects/webrunner/gcalendar.webapp > > there should and will be more documentation about how these bundles are > exposed. >
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote: > What I'd like, as a user, is some way to pin selected apps to run in the > background - whether that's something I initiate through the UI myself, or > via a prompt from the application is really a matter of UX. in my book, you're definitely asking for prism. http://labs.mozilla.com/projects/prism/ https://wiki.mozilla.org/prism and here's a prism link for google calendar: http://starkravingfinkle.org/projects/webrunner/gcalendar.webapp there should and will be more documentation about how these bundles are exposed.
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich <
mkozakew...@icosidodecahedron.com> wrote:
>
>> It sounds like the "hidden page" idea is just the solution you thought up
> to the problem of keeping a page running. How many other reasons are there
> for it?
Not sure what other motivations there may be, but one shouldn't
underestimate the value of keeping a page running. It's one of the major
differences between desktop and web apps.
>
> - Data up-to-date: Even Outlook checks online every X minutes, and has an
> options panel where you can set that value. Google Reader checks for new
> feeds, for me, *if I just leave it open on my desktop.* It works great.
Exactly - but you have to leave it open on your desktop. I can't tell you
how many meetings I've missed because I've inadvertently closed (or crashed
:) my browser, and forgotten to start up my web calendar when I restart.
What I'd like, as a user, is some way to pin selected apps to run in the
background - whether that's something I initiate through the UI myself, or
via a prompt from the application is really a matter of UX.
>
> -- Notifications: I don't think I've ever had Outlook notify me of new mail
> when it's not running. It usually starts up with Windows, and it runs in the
> background. If you turn it off from the tray, it stops.
The way I've envisioned any of these "persistent running workers/pages"
operating is the browser would have a status bar icon which would allow
background apps to display status, and also give the user the opportunity to
exit the browser or (possibly) close down individual apps. So it's a very
similar situation.
>
> If browsers could tear off tabs, minimize them to tray and allow them to
> send pop-up notifications, I think it would solve your main problem. Chrome
> seems to be halfway there, with the "Create Application Shortcuts..."
> option, but I believe only Chrome and Firefox support tear-away tabs. This
> sounds largely like a browser issue. If Chrome does it first, I'm sure the
> others will see and follow along.
Agreed. I like this way of looking at the issue - framed in this manner, it
highlights this as primarily a UX challenge ("how to present the idea of
'pinned' tabs to the user").
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 7:19 AM, Tab Atkins Jr. wrote: > > > Firefox's Jetpack addon (essentially Greasemonkey turned up to 11) > exposes a super-convenient jetpack.notifications.show() function for > doing exactly that. It pops up an attractive notification in the > lower right-hand corner of the screen for a few seconds with a custom > title, text, and icon. I'd like to have something like this as a > general feature. > > ~TJ Something similar to this is in the works for WebKit as well: https://bugs.webkit.org/show_bug.cgi?id=25463 It's experimental and so would be exposed via window.webkitNotifications. In addition to the text+icon functionality, this also enables scripted HTML notifications, to allow things like notifications that display number of unread emails, a dynamic countdown for an event reminder, etc. It sounds like enough people are prototyping in this area (us, mozilla jetpack, Palm) that we might get consensus on a general API at some point. -atw
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 8:32 AM, Michael Kozakewich wrote: > From: "Michael Davidson" > Tuesday, July 28, 2009 11:24 PM >> >> Having some sort of desktop presence is important for parity >> with desktop apps. Perhaps the install UI could look and feel more >> like the UI for installing a native app? >> >> Michael >> > > If you're going to have an installation, why not make it an actual program? > I thought what you wanted was a regular webpage -- and I'd say one of the > most important things about a webpage is that you don't have to install it. > It sounds like the "hidden page" idea is just the solution you thought up to > the problem of keeping a page running. How many other reasons are there for > it? Agreed that having an actual persistent entity separate from the browser is, well, an application separate from the browser. There's probably something useful and cool possible here with a browser window communicating with a separate program. > That being said: > > Pop-up notifications would be a great thing to do, where someone can use > JavaScript similar to an alert() box that pops up in a corner for a few > seconds and displays a message. I think I'll call this one out a few times, > so someone sees it, because it really would be a worthwhile thing to add to > a spec. Firefox's Jetpack addon (essentially Greasemonkey turned up to 11) exposes a super-convenient jetpack.notifications.show() function for doing exactly that. It pops up an attractive notification in the lower right-hand corner of the screen for a few seconds with a custom title, text, and icon. I'd like to have something like this as a general feature. ~TJ
Re: [whatwg] Installed Apps
From: "Michael Davidson" Tuesday, July 28, 2009 11:24 PM Having some sort of desktop presence is important for parity with desktop apps. Perhaps the install UI could look and feel more like the UI for installing a native app? Michael If you're going to have an installation, why not make it an actual program? I thought what you wanted was a regular webpage -- and I'd say one of the most important things about a webpage is that you don't have to install it. It sounds like the "hidden page" idea is just the solution you thought up to the problem of keeping a page running. How many other reasons are there for it? I'll go back to your original problems: -- Slow startup: Besides caching, I can't see anything except a skilled planning and development of the application making things faster -- They HAVE to download it all at some point. Merge requests (sprites, for example). I can't think of how to load new JavaScript quicker, unless you can let them use the cached old version while the new one downloads in the background, then cache it. -- Data up-to-date: Even Outlook checks online every X minutes, and has an options panel where you can set that value. Google Reader checks for new feeds, for me, if I just leave it open on my desktop. It works great. -- Notifications: I don't think I've ever had Outlook notify me of new mail when it's not running. It usually starts up with Windows, and it runs in the background. If you turn it off from the tray, it stops. Another couple things: -- Notifications: Web pages can't pop up a notification, but they CAN play sounds. If you add a sound to Gmail or Reader when it finds new items, that would certainly help me, as a user. (Even without having it as a desktop app, because it'll be open in a tab and I'll be able to hear any sound it makes). Actually, I'd love that feature. -- Clutter: I think this is your main concern: Outlook will minimize to the tray; where you can reach it, but it's not in the way. It's not invisible, and won't persist after shutting down. If browsers could tear off tabs, minimize them to tray and allow them to send pop-up notifications, I think it would solve your main problem. Chrome seems to be halfway there, with the "Create Application Shortcuts..." option, but I believe only Chrome and Firefox support tear-away tabs. This sounds largely like a browser issue. If Chrome does it first, I'm sure the others will see and follow along. That being said: Pop-up notifications would be a great thing to do, where someone can use JavaScript similar to an alert() box that pops up in a corner for a few seconds and displays a message. I think I'll call this one out a few times, so someone sees it, because it really would be a worthwhile thing to add to a spec.
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 8:23 PM, Aryeh Gregor wrote: On Mon, Jul 27, 2009 at 9:39 PM, Maciej Stachowiak wrote: Persistent workers are even more of a security risk, since they are supposed to persist even after the browser has been restarted, or after the system has been rebooted. Persistent workers should be renamed to "BotNet Construction Kit". Surely this proposal also would have the pages run even after the browser has been restarted, or the system rebooted? It was suggested that ideally they'd continue running even when the browser has been shut down! If that's the suggestion, then they are just as dangerous as persistent workers, or maybe more. But I think the point is, I don't think it's generally accepted that persistent workers are safe, so there's no argument by analogy that persistent background pages would be safe. Regards, Maciej
Re: [whatwg] Installed Apps
It feels like this has become a discussion of which dangerous feature is more dangerous Several browsers (or browser like things) have mechanisms for allowing the installation of potentially dangerous things. For example, FireFox has the extension install mechanism. Google Chrome has/must have something for extensions. There is Prism and various html desktop gadget engines. So far, it sounds like many folks are saying these persistent contexts belong more to this domain. Is it interesting discussing the api/behavior for things exposed in that domain? dave On Tue, Jul 28, 2009 at 9:58 PM, Robert O'Callahan wrote: > On Wed, Jul 29, 2009 at 4:47 PM, Michael Davidson wrote: > >> I agree 100%. I'm only trying to argue that from a user perspective, >> access that we currently have acceptable UI for, e.g. camera hardware, >> is about as scary as agreeing to let a web app run in the background. >> The consequences of a malicious app that gets either permission are >> dire. >> > > One difference is that photos of you in your underwear are probably not > easily monetizable, whereas botnets are, so you'll see a lot more > exploitation of features that let you create botnets. > > > Rob > -- > "He was pierced for our transgressions, he was crushed for our iniquities; > the punishment that brought us peace was upon him, and by his wounds we are > healed. We all, like sheep, have gone astray, each of us has turned to his > own way; and the LORD has laid on him the iniquity of us all." [Isaiah > 53:5-6] >
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 4:47 PM, Michael Davidson wrote: > I agree 100%. I'm only trying to argue that from a user perspective, > access that we currently have acceptable UI for, e.g. camera hardware, > is about as scary as agreeing to let a web app run in the background. > The consequences of a malicious app that gets either permission are > dire. > One difference is that photos of you in your underwear are probably not easily monetizable, whereas botnets are, so you'll see a lot more exploitation of features that let you create botnets. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:47 PM, Michael Davidson wrote: > I agree 100%. I'm only trying to argue that from a user perspective, > access that we currently have acceptable UI for, e.g. camera hardware, > is about as scary as agreeing to let a web app run in the background. The whole point is precisely that most users will have _utterly no idea_ what letting an app run in the background means or if it's scary, which is dangerous when combined with the fact that to an actual malware author it's far more valuable than getting access to the camera. I find it highly unlikely this distinction can be explained, or that users should even have to care. I'm not proposing a UI design -- I'm just suggesting that copying existing permissions UIs such as the one Flash uses for camera access may be a poor choice. (My instinct is that, like with Fx extensions or Android apps, users should probably just make an all-or-nothing decision one time, up front, and we should do our best to give them relevant info like ratings.) PK
Re: [whatwg] Installed Apps
Michael Davidson wrote: I didn't realize this. So you think that everything on addons.mozilla.org is vetted enough to not include malware? We try... Note that given the extension model you don't have to put a binary blob in the extension either, since extensions can make HTTP requests and write to files. Do you think the existing FF install dialog gives enough warning that an extension could outlive the browser process? The dialog says "Install add-ons only from authors whom you trust. Malicious software can damage your computer or violate your privacy". I'm not a human-computer interaction expert, so I can't tell you how scary that is to the typical consumer. Probably no more so than any other dialog he sees. :( Really, it sounds like you want something more akin to a Prism app [1] than anything else. You don't _actually_ want to run gmail in a browser window. You just want to deliver it over http:// and leverage a browser-like thing on the other end for rendering it, right? We'd like to not have to maintain two Gmail codebases, one for installed usage and one for everyone else. Ideally the same code can be used in an internet cafe and on the machine of someone who agrees to install Gmail as an app. Prism might be similar to what we'd like. Right; the whole point of Prism is that it needs no changes to the web app, last I checked, while at the same time allowing it to have its own process, window (possibly without the url bar and such, which makes a lot less sense for a window dedicated to a particular web app), and lifetime independent of the browser. -Boris
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:44 PM, Peter Kasting wrote: > On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson wrote: >> >> Personally, I'd rather have my CPU and RAM used to send spam than to >> have pictures of me in my underwear publicly placed on Facebook. > > The rest of the world would rather not receive that spam, and would probably > rather we didn't write systems enabling it on massive scales. I agree 100%. I'm only trying to argue that from a user perspective, access that we currently have acceptable UI for, e.g. camera hardware, is about as scary as agreeing to let a web app run in the background. The consequences of a malicious app that gets either permission are dire. Michael
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:38 PM, Boris Zbarsky wrote: > I don't think it is, no. Taking a picture is a one-time activity; the user > knows exactly what he's getting into. And once the picture is taken, no > more picture-taking until the user says so explicitly. FYI, this is not the case. Flash camera control is per-site, not per-use. (Gmail video chat does not request permission to use the camera every time you do a chat.) > Note that you could write a Firefox extension that outlives the browser > today. Just include a binary component that starts a separate process. I didn't realize this. So you think that everything on addons.mozilla.org is vetted enough to not include malware? Do you think the existing FF install dialog gives enough warning that an extension could outlive the browser process? A whitelist of domains that are allowed to install apps without scary permission dialogs would be okay with me. Vendors could decide whether mail.google.com is trustworthy or not. > Really, it sounds like you want something more akin to a Prism app [1] than > anything else. You don't _actually_ want to run gmail in a browser window. > You just want to deliver it over http:// and leverage a browser-like thing > on the other end for rendering it, right? We'd like to not have to maintain two Gmail codebases, one for installed usage and one for everyone else. Ideally the same code can be used in an internet cafe and on the machine of someone who agrees to install Gmail as an app. Prism might be similar to what we'd like. Michael
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson wrote: > Personally, I'd rather have my CPU and RAM used to send spam than to > have pictures of me in my underwear publicly placed on Facebook. The rest of the world would rather not receive that spam, and would probably rather we didn't write systems enabling it on massive scales. PK
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:34 PM, Peter Kasting wrote: > Not at all. Malware can't set up a darknet using cameras. Your CPU, disk > and RAM are much more valuable to a malicious coder than your camera. Personally, I'd rather have my CPU and RAM used to send spam than to have pictures of me in my underwear publicly placed on Facebook. I suspect I'm not alone among the general internet-using population. ;) What do you think about the idea of making a web app install have the same look-and-feel as a native app install? Michael
Re: [whatwg] Installed Apps
Michael Davidson wrote: - As for persistence beyond browser lifetime, I understand the reticence. However, similar problems have been solved in the past. Flash asks the user for access to hardware like cameras. Surely being able to take pictures of users is as scary as running code after the browser has closed. I don't think it is, no. Taking a picture is a one-time activity; the user knows exactly what he's getting into. And once the picture is taken, no more picture-taking until the user says so explicitly. I, personally, would be hard-pressed to describe the persistence-beyond-browser-lifetime issue to a typical user in a way that would allow him to make an informed decision on it. Heck, I would be hard-pressed to explain it via a browser dialog or the like even to a very intelligent user who happens to not be intimately familiar with the way their computer and the internet happen to work. I could do it in 10-15 minutes of in-person conversation, probably. Or several typed sheets of paper worth of text... For browsers that do have extensions, having the extension outlive the visible browser process doesn't seem like that great a leap in functionality. While this is true, extensions (at least in Firefox) are installed with the following user-facing caveats: 1) You have to explicitly opt-in to the install source, unless it's addons.mozilla.org. 2) You are told that extensions can do anything they want to. Item 1 above is very important. Note that you could write a Firefox extension that outlives the browser today. Just include a binary component that starts a separate process. Perhaps the install UI could look and feel more like the UI for installing a native app? Really, it sounds like you want something more akin to a Prism app [1] than anything else. You don't _actually_ want to run gmail in a browser window. You just want to deliver it over http:// and leverage a browser-like thing on the other end for rendering it, right? -Boris [1] http://prism.mozilla.com/
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson wrote: > These are true, but leave out the part that rewriting large apps to > the worker API is nontrivial. A major advantage of a hidden page (as > you mention below) is that the programming model is well known, and > easy for web developers to adapt to. I don't know enough about this specific case to comment, but in general I am scared of arguments like "Model A would be better, but right now people are using something closer to model B" because it can enshrine for all eternity something that browsers have to support, based on what people happen to be good at at the moment. - As for persistence beyond browser lifetime, I understand the > reticence. However, similar problems have been solved in the past. > Flash asks the user for access to hardware like cameras. Surely being > able to take pictures of users is as scary as running code after the > browser has closed. Not at all. Malware can't set up a darknet using cameras. Your CPU, disk and RAM are much more valuable to a malicious coder than your camera. The rest of your argument may still be true, I'm just not convinced by this analogy. PK
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 4:19 PM, Michael Nordman wrote: > What if a sharedContext isn't gauranteed to be a singleton in the browser. A > browser can provide best effort at co-locating pages and sharedContexts, but > it can't gaurantee that, and the spec respects that. > The lesser gaurantee is that all directly scriptable pages (those from a > given set of related browsing contexts) WILL share the same sharedContext > (should the refer to it). Best effort seems reasonable to me. Also, many large web apps (including Gmail) don't allow themselves to run in an iframe, which makes the problem much simpler. Only toplevel pages of the same domain need to be in the same process. Michael
Re: [whatwg] Installed Apps
Sorry for starting and then dropping out of the discussion for a few days. - I agree with everyone else that there are two parts to the proposal. The first, less controversial part is a shared context that lives inside of the browser. As Aaron points out, this is very similar to Chromium extensions, and shouldn't require user permission beyond that of extensions today. Extensions live as long as the browser, so whatever UI browsers use for extensions should be sufficient. On Tue, Jul 28, 2009 at 10:01 AM, Drew Wilson wrote: > 1) Loading large amounts of Javascript is slow, even from cache. > 2) Loading application state from the database is slow. > 3) Sharing between pages requires going through the database or shared > worker - you can't just party on a big shared datastructure. These are true, but leave out the part that rewriting large apps to the worker API is nontrivial. A major advantage of a hidden page (as you mention below) is that the programming model is well known, and easy for web developers to adapt to. If your app is big enough to need the advantage of a shared page, a user install doesn't seem too big a hoop to jump through. - As for persistence beyond browser lifetime, I understand the reticence. However, similar problems have been solved in the past. Flash asks the user for access to hardware like cameras. Surely being able to take pictures of users is as scary as running code after the browser has closed. For browsers that do have extensions, having the extension outlive the visible browser process doesn't seem like that great a leap in functionality. We could definitely live with same-domain restrictions in hidden pages if it would allay some concerns. Having some sort of desktop presence is important for parity with desktop apps. Perhaps the install UI could look and feel more like the UI for installing a native app? Michael
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 2:12 AM, Jonas Sicking wrote: > On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote: > > > > On Jul 27, 2009, at 10:51 PM, David Levin wrote: > > > > It sounds like most of the concerns are about the 2nd part of this > proposal: > > allowing a background page to continue running after the visible page has > > been closed. > > However, the first part sounds like it alone would be useful to web > > applications like GMail: > > > > The first, which should begenerally useful, is the ability to have a > hidden > > HTML/JS page running > > in the background that can access the DOM of visible windows. This > > page should be accessible from windows that the user navigates to. We > > call this background Javascript window a "shared context" or a > > "background page". This will enable multiple instances of a web app > > (e.g. tearoff windows in Gmail) to cleanly access the same user state > > no matter which windows are open. > > > > + restrict things to the same security origin. > > It sounds similar in concept to a share worker except that it runs in the > > main thread and is more concerned with dom manipulation/state while > workers > > have typically been thought of as allowing background processing. > > It seems that the lifetime of this could be scoped, so that it dies when > it > > isn't referenced (in a similar way to how shared worker lifetime is > scoped). > > > > This idea actually sounds reasonably ok, and I think I once proposed > > something like this as an alternative to shared workers as the way for > > multiple app instances to share state and computation. > > It's really the bit about invisibly continuing to run once all related > web > > pages are closed that I would worry about the security issues. > > The only concern I see with this is that it permanently forces all > windows from the same domain to run in the same process. As things > stand today, if the user opens two tabs (or windows) and navigates to > the two different pages on www.example.com, then a browser could if it > so wished use separate processes to run those two pages. If we enabled > this API the two pages would have to run in the same process, even if > neither page actually used this new API. > > / Jonas There are conflicting requirements along these lines that would need to be resolved... 1) A nested iframe needs to run in the same process as its containing page. 2) A shared context needs to run in the same process as its client pages. ... but what if a nested iframe document in processA connects to a sharedContext that has already been loaded into processB. Somethings gotta give. What if a sharedContext isn't gauranteed to be a singleton in the browser. A browser can provide best effort at co-locating pages and sharedContexts, but it can't gaurantee that, and the spec respects that. The lesser gaurantee is that all directly scriptable pages (those from a given set of related browsing contexts) WILL share the same sharedContext (should the refer to it).
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote: > > On Jul 27, 2009, at 10:51 PM, David Levin wrote: > > It sounds like most of the concerns are about the 2nd part of this > proposal: allowing a background page to continue running after the visible > page has been closed. > > However, the first part sounds like it alone would be useful to web > applications like GMail: > > The first, which should begenerally useful, is the ability to have a > hidden HTML/JS page running > in the background that can access the DOM of visible windows. This > page should be accessible from windows that the user navigates to. We > call this background Javascript window a "shared context" or a > "background page". This will enable multiple instances of a web app > (e.g. tearoff windows in Gmail) to cleanly access the same user state > no matter which windows are open. > > > + restrict things to the same security origin. > > It sounds similar in concept to a share worker except that it runs in the > main thread and is more concerned with dom manipulation/state while workers > have typically been thought of as allowing background processing. > > It seems that the lifetime of this could be scoped, so that it dies when it > isn't referenced (in a similar way to how shared worker lifetime is scoped). > > > This idea actually sounds reasonably ok, and I think I once proposed > something like this as an alternative to shared workers as the way for > multiple app instances to share state and computation. > > It's really the bit about invisibly continuing to run once all related web > pages are closed that I would worry about the security issues. > > Regards, > Maciej > > +1 seperating the "load-at-startup" and "persist-beyond-connected-page-close" from the more generally applicable feature to "connect to a directly scritable shared context from multiple pages". Minus the lifetime questions, I don't think there's anything terribly controversial about this... very similar to an invisible iframe that's must be from the same-origin as the referencing page. I think this could be a very valuable feature in general. Gmail does really want permissions to run in the background... but I think that could be layered on top of the more primitive "shared context" feature. * one way to 'extend' things could be to allow a persistent worker (which has permissions to run in the background) to load a shared context and hold a refernce to it to prevent the shared context from closing (note: the persistent worker wouldn't be able to directly script that shared context, just bootstrap it and keep it alive). * another way to extend things could be to allow an appcache manifest to indicate which resources should be loaded into a shared context
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson wrote: > So (and forgive me for restating), it seems like hidden page addresses the > following problems that gmail and other large web apps are having: > > 1) Loading large amounts of Javascript is slow, even from cache. > 2) Loading application state from the database is slow. > Do we know why 1 and 2 are true? Can it be fixed? > 3) Sharing between pages requires going through the database or shared > worker - you can't just party on a big shared datastructure. > 4) There's no way to do things like new mail notifications, calendar > notifications, local updates of your email inbox, etc when the browser is > not open. Currently, even the most brain-dead shareware desktop calendar app > can display an event notification, while web-based calendars are forced to > rely on the user remembering to keep a browser window open. > > Am I missing any other issues that hidden page is supposed to address? > > A persistent worker could address #4 (perhaps with some limitations on > network access to address security concerns). For #1/#2/#3, are we saying > that web applications *must* install themselves (with the requisite user > flow) just to get fast load times? That seems unfortunate - if I don't care > about #4, I'd really like to be able to get the benefits of #1/2/3 without > jumping through a user install. > Yes, but a background page keeps a lot of state in memory semi-permanently. It's not acceptable for any web page to have the power to use significant system resources even after it's been closed. The most contentious part of this proposal is keeping the page open after all it's parent pages have been closed. #3 only needs background pages to be open as long as it's parent pages are open. #4 can be somewhat solved by this, but there are other less resource intensive solutions to that as well. Something like Aaron's proposal where "the lifetime of the page could be refcounted by pages referencing it" seems reasonable though. It doesn't solve the initial startup problem, but it does solve #3, which would allow for making things like popping out an email to it's own window fast. In addition, putting this behind an install UI like extensions seems fine to fix the startup case and #4, although I agree that you shouldn't need to "install gmail" for it to load quickly. I'd like to understand the underlying reasons for #1 and #2. As Jonas said, there may be alternative solutions that are less prone to abuse of system resources. For example is loading cached JS so slow because it needs to hit disk? That could be solved by an AppCache extension that pins resources in memory if possible. Ojan -atw > > > On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak wrote: > >> >> On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote: >> >> I'm not clear how the UI requirements here are different from >>> persistent workers, though. Those also persist after the user >>> navigates away, right? >>> >> >> Persistent workers are even more of a security risk, since they are >> supposed to persist even after the browser has been restarted, or after the >> system has been rebooted. Persistent workers should be renamed to "BotNet >> Construction Kit". >> >> Regards, >> Maciej >> >> >
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 2:23 PM, Adam de Boor wrote: > > > 2009/7/28 Jonas Sicking >> >> The only concern I see with this is that it permanently forces all >> windows from the same domain to run in the same process. As things >> stand today, if the user opens two tabs (or windows) and navigates to >> the two different pages on www.example.com, then a browser could if it >> so wished use separate processes to run those two pages. If we enabled >> this API the two pages would have to run in the same process, even if >> neither page actually used this new API. >> > This is one of the arguments for layering on the AppCache: the app would > have to take action, through an attribute in the manifest, at a level where > the browser could make the decision whether to join two windows into the > same process. Though I think in most implementations, even by the time you realize that there even is an AppCache manifest, you've already chosen which process to use to run the page. But I agree that it's at least theoretically possible to solve this if you use an AppCache solution. / Jonas
Re: [whatwg] Installed Apps
could the botnet concern be addressed by restricting network access from the background page when there is no foreground page referencing it? e.g. restrict it to requests to the same origin, no matter how those requests are made? wouldn't let gmail precache linked images, when fetching new mail, but that's not a huge concern. a 2009/7/28 Aryeh Gregor > > There's not really a whole lot that a malicious or incompetent > persistent page could do to the user's computer. At worst, it could > interfere with the browser. I guess the botnet concern is justified, > though (for use in DDoS or something). Not sure how to avoid that. >
Re: [whatwg] Installed Apps
2009/7/28 Jonas Sicking > > The only concern I see with this is that it permanently forces all > windows from the same domain to run in the same process. As things > stand today, if the user opens two tabs (or windows) and navigates to > the two different pages on www.example.com, then a browser could if it > so wished use separate processes to run those two pages. If we enabled > this API the two pages would have to run in the same process, even if > neither page actually used this new API. > > This is one of the arguments for layering on the AppCache: the app would have to take action, through an attribute in the manifest, at a level where the browser could make the decision whether to join two windows into the same process. a
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote: > Hello folks - > > I'm an engineer on the Gmail team. We've been working on a prototype > with the Chrome team to make the Gmail experience better. We thought > we'd throw out our ideas to the list to get some feedback. > > THE PROBLEM > > We would like to enable rich internet applications to achieve feature > parity with desktop applications. I will use Gmail and Outlook as > examples for stating the problems we hope to solve. > > -- Slow startup: When a user navigates to mail.google.com, multiple > server requests are required to render the page. The Javascript is > cacheable, but personal data (e.g. the list of emails to show) is not. > New releases of Gmail that require JS downloads are even slower to > load. > -- Native apps like Outlook can (and do) run background processes on > the user's machine to make sure that data is always up-to-date. > -- Notifications: Likewise, Outlook can notify users (via a background > process) when new mail comes in even if it's not running. It sounds like what you need for your use case is for some set of resources to be immediately available when gmail starts. This set of resources is a mixture of "static" resources like JS files (and presumably HTML files), and "dynamic" resources like the list of emails. An alternative solution would be to tell the browser what resources you need, and how to download them (to allow for incremental downloads of just new emails for example). Then the browser can download these resources as it sees fit. On a mobile device this could happen even if the browser is not running, similar to the iPhone push mechanism. This should be significantly easier to secure since you don't allow the full power of the web platform to run in the background. I would think that this can be done using extensions to the AppCache feature. / Jonas
Re: [whatwg] Installed Apps
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. 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. -atw On Tue, Jul 28, 2009 at 10:09 AM, Aryeh Gregor > wrote: > On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson wrote: > > I've been kicking around some ideas in this area. One thing you could do > > with persistent workers is restrict network access to the domain of that > > worker if you were concerned about botnets. > > How would that work for background pages, though? It couldn't include > any files from other domains in any form (image, script, style, etc.)? > But it could still spawn a regular tab and load whatever it wanted in > that. Have it spawn a popunder window, say, quickly open a bunch of > things from foreign sites, and close it before the user notices > anything more than a sudden odd flicker. Or whatever. Workers, if I > understand right (I haven't read the spec . . .), can't do things like > open new tabs, but it's been explicitly stated that these background > pages should be able to do just that. >
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson wrote: > I've been kicking around some ideas in this area. One thing you could do > with persistent workers is restrict network access to the domain of that > worker if you were concerned about botnets. How would that work for background pages, though? It couldn't include any files from other domains in any form (image, script, style, etc.)? But it could still spawn a regular tab and load whatever it wanted in that. Have it spawn a popunder window, say, quickly open a bunch of things from foreign sites, and close it before the user notices anything more than a sudden odd flicker. Or whatever. Workers, if I understand right (I haven't read the spec . . .), can't do things like open new tabs, but it's been explicitly stated that these background pages should be able to do just that.
Re: [whatwg] Installed Apps
I've been kicking around some ideas in this area. One thing you could do with persistent workers is restrict network access to the domain of that worker if you were concerned about botnets. That doesn't address the "I installed something in my browser and now it's constantly sucking up my CPU" issue, but that makes us no different than Flash :-P Anyhow, addressing some of the other comments - I don't think that there's necessarily a problem with the async worker APIs as they stand, and I don't think we can easily retrofit synchronous APIs on top of their current execution model. The issue is that the core problem that Workers solve (parallel execution in a separate context from the page) is different than the problem that large web apps are trying to address (reduced latency). SharedWorkers are overloaded to provide a way for pages under the same domain to share state, but this seems like an orthogonal goal to "parallel execution" and I suspect that we may have ended up with a cleaner solution had we decided to address the "shared state" issue via a separate mechanism. Similarly, the "hidden page" mechanism seems to address a bunch of issues at once, and I'm wondering if we explicitly laid out the problems it's trying to solve, whether we might find a set of distinct smaller solutions that were more generally applicable. I just don't want to make the same design choices that we did with SharedWorkers, and end up with a monolithic solution that doesn't address the individual goals (i.e. cross-page sharing) in a developer-friendly manner. So (and forgive me for restating), it seems like hidden page addresses the following problems that gmail and other large web apps are having: 1) Loading large amounts of Javascript is slow, even from cache. 2) Loading application state from the database is slow. 3) Sharing between pages requires going through the database or shared worker - you can't just party on a big shared datastructure. 4) There's no way to do things like new mail notifications, calendar notifications, local updates of your email inbox, etc when the browser is not open. Currently, even the most brain-dead shareware desktop calendar app can display an event notification, while web-based calendars are forced to rely on the user remembering to keep a browser window open. Am I missing any other issues that hidden page is supposed to address? A persistent worker could address #4 (perhaps with some limitations on network access to address security concerns). For #1/#2/#3, are we saying that web applications *must* install themselves (with the requisite user flow) just to get fast load times? That seems unfortunate - if I don't care about #4, I'd really like to be able to get the benefits of #1/2/3 without jumping through a user install. -atw On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak wrote: > > On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote: > > I'm not clear how the UI requirements here are different from >> persistent workers, though. Those also persist after the user >> navigates away, right? >> > > Persistent workers are even more of a security risk, since they are > supposed to persist even after the browser has been restarted, or after the > system has been rebooted. Persistent workers should be renamed to "BotNet > Construction Kit". > > Regards, > Maciej > >
Re: [whatwg] Installed Apps
Michael Davidson wrote: ... WHY NOT SHARED WORKERS Shared workers and persistent workers are designed to solve similar problems, but don't meet our needs. The key difference between what we're proposing and earlier proposals for persistent workers is that background pages would be able to launch visible windows and have full DOM access. This is different from the model of workers where all interaction with the DOM has to be done through asynchronous message passing. We would like background pages to be able to drive UI in a visible window using the techniques (DOM manipulation, innerHTML) that are common today. We believe that more apps would be able to take advantage of a background page if they didn't require rewriting the app in the asynchronous, message-passing style required by workers. hmmm ... this is the worrying part to me. Sounds like one of the presumed qualities of web workers, ease of use, isn't going to be met with the currently spec'd APIs. Is there some way to framework-ize something around the current APIs to make this easier to use by developers? Or would the addition of a synchronous API help (assuming some non-evil synchronous API)? Or do we need a lot of head shaping around asynchronous message sending? Futher question would be whether there are two issues: dealing with asynchronous messages, and direct DOM API. If we could get over the hurdle of the async, do we still need the direct DOM API? -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Installed Apps
Minimizing to the notification area is about the only thing, I think, that we can't already do in a modern browser. If the page persists, it must be visible (maybe with a user option to make it completely invisible). This way, the user could at any time click the weblication and choose the 'close' option. I'm not sure about the use of making it start automatically on computer restart, unless it was meant that the state of the application would be saved on the computer? It could use an offline-storage solution, and then close itself.
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 3:02 AM, Jonas Sicking wrote: > Google Chrome (and I think other browsers) allow pages to be > "installed" as web applications which run in a separate window. It > would be interesting to look at the UI for that feature. However > installApp allows something even more powerful than that, since it > allows a hidden page that the user can't easily simply close, and so > should probably have an even more restrictive UI. I'm not sure what "an even more restrictive UI" means. I don't think "lots of scary warnings" is a good approach here. (Or elsewhere, but that's a separate issue.) Better to do something like: "https://mail.google.com/ would like to continue running a background page permanently after you browse away. This might make the site faster if you use it a lot, but could use up your computer's resources. Would you like to allow this? You can disable it later from the Add-Ons menu." Then try to think of some obvious forms of disruptive behavior, like using too much CPU, and have some appropriately-calibrated notification if that happens asking the user if he'd like to disable the page. Conceivably a background page could misbehave enough that the user can't easily close it. But this is already true for normal pages, and those can already be persistent if the user has session restore enabled and the tab somehow freezes or crashes the browser so the user can't close it. Browsers should be able to provide UI to handle this (and do, for normal pages, if they provide session restore). There's not really a whole lot that a malicious or incompetent persistent page could do to the user's computer. At worst, it could interfere with the browser. I guess the botnet concern is justified, though (for use in DDoS or something). Not sure how to avoid that.
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 1:38 AM, Maciej Stachowiak wrote: > > On Jul 27, 2009, at 10:51 PM, David Levin wrote: > > It sounds like most of the concerns are about the 2nd part of this proposal: > allowing a background page to continue running after the visible page has > been closed. > However, the first part sounds like it alone would be useful to web > applications like GMail: > > The first, which should begenerally useful, is the ability to have a hidden > HTML/JS page running > in the background that can access the DOM of visible windows. This > page should be accessible from windows that the user navigates to. We > call this background Javascript window a "shared context" or a > "background page". This will enable multiple instances of a web app > (e.g. tearoff windows in Gmail) to cleanly access the same user state > no matter which windows are open. > > + restrict things to the same security origin. > It sounds similar in concept to a share worker except that it runs in the > main thread and is more concerned with dom manipulation/state while workers > have typically been thought of as allowing background processing. > It seems that the lifetime of this could be scoped, so that it dies when it > isn't referenced (in a similar way to how shared worker lifetime is scoped). > > This idea actually sounds reasonably ok, and I think I once proposed > something like this as an alternative to shared workers as the way for > multiple app instances to share state and computation. > It's really the bit about invisibly continuing to run once all related web > pages are closed that I would worry about the security issues. The only concern I see with this is that it permanently forces all windows from the same domain to run in the same process. As things stand today, if the user opens two tabs (or windows) and navigates to the two different pages on www.example.com, then a browser could if it so wished use separate processes to run those two pages. If we enabled this API the two pages would have to run in the same process, even if neither page actually used this new API. / Jonas
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 10:51 PM, David Levin wrote: It sounds like most of the concerns are about the 2nd part of this proposal: allowing a background page to continue running after the visible page has been closed. However, the first part sounds like it alone would be useful to web applications like GMail: The first, which should begenerally useful, is the ability to have a hidden HTML/JS page running in the background that can access the DOM of visible windows. This page should be accessible from windows that the user navigates to. We call this background Javascript window a "shared context" or a "background page". This will enable multiple instances of a web app (e.g. tearoff windows in Gmail) to cleanly access the same user state no matter which windows are open. + restrict things to the same security origin. It sounds similar in concept to a share worker except that it runs in the main thread and is more concerned with dom manipulation/state while workers have typically been thought of as allowing background processing. It seems that the lifetime of this could be scoped, so that it dies when it isn't referenced (in a similar way to how shared worker lifetime is scoped). This idea actually sounds reasonably ok, and I think I once proposed something like this as an alternative to shared workers as the way for multiple app instances to share state and computation. It's really the bit about invisibly continuing to run once all related web pages are closed that I would worry about the security issues. Regards, Maciej
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 5:53 PM, Maciej Stachowiak wrote: > On Jul 27, 2009, at 6:42 PM, Robert O'Callahan wrote: >> On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote: >>> As mentioned in earlier discussions about persistent workers, >>> permissioning UI is a major issue. >> >> Indeed, the most difficult issue here is security and the permissions UI, >> which you haven't addressed at all. >> >> Currently, when you close a browser tab, the application in that tab is >> gone. This is a very important user expectation that we can't just break. > > I share this concern. Violating this expectation seems like it could be a > vector for malware, in a way that a permissions dialog would not > meaningfully address. Agreed. As so often, adding powerful features is the easy part, doing so securely is what's hard. Google Chrome (and I think other browsers) allow pages to be "installed" as web applications which run in a separate window. It would be interesting to look at the UI for that feature. However installApp allows something even more powerful than that, since it allows a hidden page that the user can't easily simply close, and so should probably have an even more restrictive UI. / Jonas
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 9:51 PM, David Levin wrote: > It sounds like most of the concerns are about the 2nd part of this proposal: > allowing a background page to continue running after the visible page has > been closed. > However, the first part sounds like it alone would be useful to web > applications like GMail: Exactly. We have something like this for Chromium extensions (http://dev.chromium.org/developers/design-documents/extensions/background-pages), and it is really useful. The ability to reuse the web platform in the background context turns out to be really great for many little reasons. Like you can just call window.open(). Or include an NPAPI plugin. As a web platform feature, you could just do it like: ... The lifetime of the page could be refcounted by pages referencing it. - a
Re: [whatwg] Installed Apps
It sounds like most of the concerns are about the 2nd part of this proposal: allowing a background page to continue running after the visible page has been closed. However, the first part sounds like it alone would be useful to web applications like GMail: The first, which should begenerally useful, is the ability to have a hidden HTML/JS page running in the background that can access the DOM of visible windows. This page should be accessible from windows that the user navigates to. We call this background Javascript window a "shared context" or a "background page". This will enable multiple instances of a web app (e.g. tearoff windows in Gmail) to cleanly access the same user state no matter which windows are open. + restrict things to the same security origin. It sounds similar in concept to a share worker except that it runs in the main thread and is more concerned with dom manipulation/state while workers have typically been thought of as allowing background processing. It seems that the lifetime of this could be scoped, so that it dies when it isn't referenced (in a similar way to how shared worker lifetime is scoped). Dave On Mon, Jul 27, 2009 at 6:39 PM, Maciej Stachowiak wrote: > > On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote: > > I'm not clear how the UI requirements here are different from >> persistent workers, though. Those also persist after the user >> navigates away, right? >> > > Persistent workers are even more of a security risk, since they are > supposed to persist even after the browser has been restarted, or after the > system has been rebooted. Persistent workers should be renamed to "BotNet > Construction Kit". > > Regards, > Maciej > >
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote: THE PROBLEM feature parity with desktop applications. A SOLUTION hidden HTML/JS page running in the background that can access the DOM of visible windows. KNOWN ISSUES As mentioned in earlier discussions about persistent workers, permissioning UI is a major issue. Isn't this what Google Gears was created to handle? I run Google Reader from my Quick Launch, like an application, and sometimes have it open all day. It notifies me (thought silently) of new items. The only improvement I could see would be to make it minimize to the tray and make popup notifications, as well as improve the offline features. I'm sure web workers are as limited as they are for security concerns.
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 9:39 PM, Maciej Stachowiak wrote: > Persistent workers are even more of a security risk, since they are supposed > to persist even after the browser has been restarted, or after the system > has been rebooted. Persistent workers should be renamed to "BotNet > Construction Kit". Surely this proposal also would have the pages run even after the browser has been restarted, or the system rebooted? It was suggested that ideally they'd continue running even when the browser has been shut down!
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 7:13 PM, Aryeh Gregor wrote: I'm not clear how the UI requirements here are different from persistent workers, though. Those also persist after the user navigates away, right? Persistent workers are even more of a security risk, since they are supposed to persist even after the browser has been restarted, or after the system has been rebooted. Persistent workers should be renamed to "BotNet Construction Kit". Regards, Maciej
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 8:42 PM, Robert O'Callahan wrote: > Indeed, the most difficult issue here is security and the permissions UI, > which you haven't addressed at all. One obvious solution would be to have installation UI like extensions, but somewhat less scary (no signing requirements, countdowns, "this will explode your computer" warnings, etc.). These would effectively be sandboxed browser extensions. So you could view and disable any background windows from the Add-Ons menu or browser equivalent. Even browsers that don't support extensions have some UI already for plugins that could be partially reused. I'm not clear how the UI requirements here are different from persistent workers, though. Those also persist after the user navigates away, right? > Maybe you could have a browser window containing regular tabs, but presented > differently, with just icons and titles in some sort of tray, so users can > see which applications are running "in the background"? So the browser becomes still more of a mini-OS. Tabs already usurped some of the window manager's functionality, and now we're talking about having system trays too. What next, a clock in the corner? :) I'm not saying this is bad, necessarily, but it's something to keep in mind. We have an operating system independent from the browser that provides general-purpose process management for a reason. (Unless maybe you use Chrome OS!)
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 6:42 PM, Robert O'Callahan wrote: On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote: As mentioned in earlier discussions about persistent workers, permissioning UI is a major issue. Indeed, the most difficult issue here is security and the permissions UI, which you haven't addressed at all. Currently, when you close a browser tab, the application in that tab is gone. This is a very important user expectation that we can't just break. I share this concern. Violating this expectation seems like it could be a vector for malware, in a way that a permissions dialog would not meaningfully address. Regards, Maciej
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote: > As mentioned in earlier discussions about persistent workers, > permissioning UI is a major issue. > Indeed, the most difficult issue here is security and the permissions UI, which you haven't addressed at all. Currently, when you close a browser tab, the application in that tab is gone. This is a very important user expectation that we can't just break. Maybe you could have a browser window containing regular tabs, but presented differently, with just icons and titles in some sort of tray, so users can see which applications are running "in the background"? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Installed Apps
On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote: > THE PROBLEM > > > feature parity with desktop applications. > > > A SOLUTION > > > hidden HTML/JS page running > in the background that can access the DOM of visible windows. > > > KNOWN ISSUES > > As mentioned in earlier discussions about persistent workers, > permissioning UI is a major issue. > The thing that rubs me the wrong way about this is not that there would be a permissioning UI, it would be the permission decision I would have to convey through said UI. How do I know that I want to let some site have the same permissions I give Gmail? Do you really, really need this? Gmail is already always running on my desktop.
Re: [whatwg] Installed Apps
> > 2) For multi-process browsers like Chrome, there seem to be limitations as > to what can actually be accessed between processes (direct DOM access across > process boundaries seems problematic for example). Do you have ideas about > how to address this, since assumedly the page calling getInstalledApp() > could be running under some arbitrary process? Even with single-process browsers you would have to handle threading issues in a way that is just not done in all browsers yet. For a) - Having some way to load large amounts of cached javascript quickly > in a new page seems like an issue that would be nice to address in general, > not just for pages that install hidden pages. Are there other approaches > worth trying here? Loading of cached JavaScript isn't really that slow. I think the real issue here is client state. It's often a good idea to have a copy of running scripts in each process for stability anyway. However, cached parsing/pre-compilation (if available) of scripts might be a generally good idea. Perhaps some kind of process cloning like *nix forks? IMHO, this could be solved cleaner and more memory efficient way with some form of persistent workers rather than a "hidden" page. But I might be missing something. On Tue, Jul 28, 2009 at 1:30 AM, Drew Wilson wrote: > This sounds really powerful, and seems like a natural evolution of some of > the stuff we've discussed previously for persistent workers. A few > comments/notes: > 1) It sounds like this background page would act like any other web page > with respect to its processing model (i.e. like other pages, script running > in this page would be limited as to how long it can run, as opposed to > workers which can run for any arbitrary length of time). This seems > reasonable, especially since this page could assumedly still create workers > if it need to do true background processing. It's really more of a "hidden" > page than a "background page"? > > 2) For multi-process browsers like Chrome, there seem to be limitations as > to what can actually be accessed between processes (direct DOM access across > process boundaries seems problematic for example). Do you have ideas about > how to address this, since assumedly the page calling getInstalledApp() > could be running under some arbitrary process? > > 3) This approach has another advantage over something like workers in that > a hidden page can do cross-domain access/sharing via iframes, whereas > workers don't really have any facility for cross-domain access. > > 4) I had a quick question/clarification about the motivation behind this - > aside from the advantages described above, it sounds like the specific > problem you are solving by a hidden page is a) you don't have to load > javascript in a new page (which I'm assuming must be slow), and b) you don't > have to load client state in the new page. > > For a) - Having some way to load large amounts of cached javascript quickly > in a new page seems like an issue that would be nice to address in general, > not just for pages that install hidden pages. Are there other approaches > worth trying here? > > For b) - How much client state are we talking about? If you were to pursue > this approach using workers to maintain client state, how much data would > you expect to be transferred to the client app on startup? We're seeing > fairly low latency for client<->worker communication, so in theory it > shouldn't be a huge source of slowdown. > > I agree that the programming model of the hidden page is much cleaner/more > familiar than rewriting applications to use asynchronous messaging, so that > may be sufficient motivation for this. > > -atw > > > On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote: > >> Hello folks - >> >> I'm an engineer on the Gmail team. We've been working on a prototype >> with the Chrome team to make the Gmail experience better. We thought >> we'd throw out our ideas to the list to get some feedback. >> >> THE PROBLEM >> >> We would like to enable rich internet applications to achieve feature >> parity with desktop applications. I will use Gmail and Outlook as >> examples for stating the problems we hope to solve. >> >> -- Slow startup: When a user navigates to mail.google.com, multiple >> server requests are required to render the page. The Javascript is >> cacheable, but personal data (e.g. the list of emails to show) is not. >> New releases of Gmail that require JS downloads are even slower to >> load. >> -- Native apps like Outlook can (and do) run background processes on >> the user's machine to make sure that data is always up-to-date. >> -- Notifications: Likewise, Outlook can notify users (via a background >> process) when new mail comes in even if it's not running. >> >> A SOLUTION >> >> Our proposed solution has two parts. The first, which should be >> generally useful, is the ability to have a hidden HTML/JS page running >> in the background that can access the DOM of visible windows. This >>
Re: [whatwg] Installed Apps
This sounds really powerful, and seems like a natural evolution of some of the stuff we've discussed previously for persistent workers. A few comments/notes: 1) It sounds like this background page would act like any other web page with respect to its processing model (i.e. like other pages, script running in this page would be limited as to how long it can run, as opposed to workers which can run for any arbitrary length of time). This seems reasonable, especially since this page could assumedly still create workers if it need to do true background processing. It's really more of a "hidden" page than a "background page"? 2) For multi-process browsers like Chrome, there seem to be limitations as to what can actually be accessed between processes (direct DOM access across process boundaries seems problematic for example). Do you have ideas about how to address this, since assumedly the page calling getInstalledApp() could be running under some arbitrary process? 3) This approach has another advantage over something like workers in that a hidden page can do cross-domain access/sharing via iframes, whereas workers don't really have any facility for cross-domain access. 4) I had a quick question/clarification about the motivation behind this - aside from the advantages described above, it sounds like the specific problem you are solving by a hidden page is a) you don't have to load javascript in a new page (which I'm assuming must be slow), and b) you don't have to load client state in the new page. For a) - Having some way to load large amounts of cached javascript quickly in a new page seems like an issue that would be nice to address in general, not just for pages that install hidden pages. Are there other approaches worth trying here? For b) - How much client state are we talking about? If you were to pursue this approach using workers to maintain client state, how much data would you expect to be transferred to the client app on startup? We're seeing fairly low latency for client<->worker communication, so in theory it shouldn't be a huge source of slowdown. I agree that the programming model of the hidden page is much cleaner/more familiar than rewriting applications to use asynchronous messaging, so that may be sufficient motivation for this. -atw On Mon, Jul 27, 2009 at 11:50 AM, Michael Davidson wrote: > Hello folks - > > I'm an engineer on the Gmail team. We've been working on a prototype > with the Chrome team to make the Gmail experience better. We thought > we'd throw out our ideas to the list to get some feedback. > > THE PROBLEM > > We would like to enable rich internet applications to achieve feature > parity with desktop applications. I will use Gmail and Outlook as > examples for stating the problems we hope to solve. > > -- Slow startup: When a user navigates to mail.google.com, multiple > server requests are required to render the page. The Javascript is > cacheable, but personal data (e.g. the list of emails to show) is not. > New releases of Gmail that require JS downloads are even slower to > load. > -- Native apps like Outlook can (and do) run background processes on > the user's machine to make sure that data is always up-to-date. > -- Notifications: Likewise, Outlook can notify users (via a background > process) when new mail comes in even if it's not running. > > A SOLUTION > > Our proposed solution has two parts. The first, which should be > generally useful, is the ability to have a hidden HTML/JS page running > in the background that can access the DOM of visible windows. This > page should be accessible from windows that the user navigates to. We > call this background Javascript window a "shared context" or a > "background page". This will enable multiple instances of a web app > (e.g. tearoff windows in Gmail) to cleanly access the same user state > no matter which windows are open. > > Additionally, we'd like this background page to continue to run after > the user has navigated away from the site, and preferably after the > user has closed the browser. This will enable us to keep client-side > data up-to-date on the user's machine. It will also enable us to > download JS in advance. When the user navigates to a web app, all the > background page has to do is draw the DOM in the visible window. This > should significantly speed up app startup. Additionally, when > something happens that requires notification, the background page can > launch a visible page with a notification (or use other rich APIs for > showing notifications). > > WHY NOT SHARED WORKERS > > Shared workers and persistent workers are designed to solve similar > problems, but don't meet our needs. The key difference between what > we're proposing and earlier proposals for persistent workers is that > background pages would be able to launch visible windows and have full > DOM access. This is different from the model of workers where all > interaction with the DOM has to be done through asynchronous me
