<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I'm pretty concerned about the security/spamming implications of notifications from Workers. A lot of thought has been put into how to make them a good feature for thoughtful, competent Web developers like those at Google. But it seems to me that not as much thought has been put into making the feature resistant to abuse.</div><div><br></div><div>A few specific concerns:</div><div><br></div><div>1) Notifications may appear to the user to come from the Web page they are currently looking at, even if the Worker issuing them was created by a different originating page.</div><div><br></div><div>2) In the case of a SharedWorker, there may not even be an originating page with which to assiciate the notification, and it may not be clear to the user how to make notifications stop.</div><div><br></div><div>3) It appears that Notifications can be used for unwelcome advertising spam, much as pop-up windows before the advent of browser pop-up blocking.</div><div><br></div><br><div><div>On Apr 30, 2009, at 2:05 PM, John Gregg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi WebKit,<div><br></div><div>I'm working on a Notifications API for Web Workers, with the idea that a user agent could receive these from script and route them in a platform-appropriate &amp; user-configurable way (desktop HTML toasts, Growl calls, status bar on mobile browsers, etc.). &nbsp;Permission controls would be similar to popups.</div></blockquote><div><br></div><div>I don't see how that's possible. The default policy used by many WebKit clients (including Safari) is that popups are only allowed in response to explicit user actions, such as clicking a link. But no code running in a Worker is in response to a user action. In addition, as I understand it, the whole point of Notifications is that they are in response to background events, *not* in response to user actions.</div><div><br></div><blockquote type="cite"> <div><br></div><div>I have a prototype working in Chromium but I need some advice as to how I might get the JS API checked in.&nbsp;I opened a bugzilla item here:&nbsp;<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(80, 0, 80); "><a href="https://bugs.webkit.org/show_bug.cgi?id=25463" target="_blank" style="color: rgb(28, 81, 168); ">https://bugs.webkit.org/show_bug.cgi?id=25463</a>, </span><span class="Apple-style-span" style="border-collapse: collapse; ">which links to the design doc I'm using and has a rough draft of the patch I'm proposing. &nbsp;</span></div> <div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">I got some feedback there already, so I thought I would reach out for more advice. &nbsp;Basically it amounts to adding to WorkerContext.idl an attribute&nbsp;WorkerContext.notifications, which notifications object contains methods like createNotification(URL or text+icon). &nbsp;Because of the proposed idea of dynamic routing, I'm inclined not to roll it in to window.open() until we get more experience building apps on it and decide that makes sense. &nbsp;</span></div> <div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">Since this is experimental, it's already behind a compile time flag, but I would be happy to do more to make it further protected (like calling it WorkerContext.chromiumNotifications to indicate it's currently a Chromium experiment). &nbsp;Any other advice on how to proceed?</span></div></blockquote><div><br></div><div>I think we should have a clear design for how this feature will resist abuse by malware before landing it in the WebKit tree. And if we can't find a solid design for that, then we shouldn't implement it. While many of us working on WebKit are greatly interested in extending the capabilities of Web applications, we have to recognize that it's important to proceed carefully and think through how a feature may be abused. In some cases, such as read-write access to the filesystem, there might not be any practical way to make it safe. In other cases, restricting the scope of the feature appropriately may make it safe enough. But I think it's too risky to implement first and figure out the security implications later.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br></div><blockquote type="cite"> <div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">Thanks!</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">&nbsp;-John</span></div> <div><br></div><div><br></div> _______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev<br></blockquote></div><br></body></html>