On 11/27/13, 1:11 PM, "cowwoc" <cowwoc@bbs.darktech.org> wrote: > > > On 27/11/2013 12:10 PM, Justin Uberti wrote: > > >> >> The publisher of the extension can control which domains can talk to it. See >> http://developer.chrome.com/extensions/manifest/externally_connectable.html. >> This would allow you to make your extension available to yourcompany.com >> <http://yourcompany.com> , as well as development machines on >> *.corp.yourcompany.com <http://corp.yourcompany.com> . (Note that *.com and >> other wide-reaching wildcards are not permitted.) >> >> >> >> >> >> There is also the Chrome flag parameter to force on the screen-sharing >> feature for testing purposes >> (chrome://flags/#enable-usermedia-screen-capture). >> >> >> >> > > So you're saying we will never be able to implement "help your mom with her > computer" style applications in WebRTC? Those kind of apps have no way of > knowing ahead of time which websites they will navigate to. Actually, to really implement ³help your mom with her computer², or ³help your computer science student debug his program², you need remote control ‹ the ability to grant a remote user the ability to inject mouse and keyboard events. This kind of control has been key to educational applications in particular ‹ and earlier in the thread it was mainly dismissed. Otherwise, the best you can get is seeing what¹s happening, and then having to go through the very painful process of operating the computer by vocally directing the person in front of it where to click, drag, type, etc. After reading through some more of this thread, allowing remote keyboard mouse events doesn¹t actually seem that much more dangerous than allowing an app which can view the screen to also be able to operate the browser (the case of navigating to the bank, and capturing the display). -SteveK
Received on Wednesday, 27 November 2013 18:39:05 UTC