Weird, looking at the manifest, I see it asks for permission for "socket": [ "tcp-connect::" ], but when I try to use that in my own app, I get the message "socket" permissions are only allowed for packaged apps.
I am quite frustrated by the confusing mix of extensions vs "legacy" apps vs "hosted" apps vs the newfangled "packaged" apps. The chrome web store is extremely confusing and the documentation is all over the place.
I use Teamviewer all the time and find it very useful. I need to spend a little time to look at how the connections are made though—I'm not confident that it's secure since you have to enter an ID and password that are (I'm assuming) authenticated by a different machine controlled by Teamviewer. I wonder if the connection is sent through their computers (to get around router issues) and therefore susceptible to capturing passwords, etc. or if the connection is handed off to the two machines after the ID / password is handled.
Nothing really. It's just a typical freemium model. I used it to fix my parents' computers remotely every now and then. Then a few months later I bought TeamViewer Premium for a network I manage. I didn't even try looking into alternatives because TeamViewer worked so well and it was relatively cheap for what it did. Of course there are tons of free alternatives but it is more expensive (in manhours) to go through the process of vetting, getting, and setting them.
There is also a "LAN connect" option which will not depend on teamviewer servers to broker a connection. If your endpoints are directly addressable and don't have any firewall/NAT complications, the workflow is just like a VNC or RDP.
This really works very well. Its much faster and stable than thinvnc I was using on my chromebook. My only issue would be that I have to scroll a lot. I wish I could resize as the computer I'm connecting to has a much higher resolution (I think is causing the issue)
This kind of thing could be interesting. I've often bemoaned the use of HTML/Javascript as a "poor man's X server" and argued that a browser is not necessarily the best way to remote out a UI. VNC, on the other hand, is designed for pushing user interfaces out remotely, so integrating the two could be a very natural step.
What'll be interesting to see, is if we can get to a point where there's a very natural handoff mechanism between the browser and VNC. Will there be, for example, urls like:
vnc://myhost.com/some_remote_desktop
that will seamlessly start a VNC viewer? If so, that starts to become really cool.
Of course, I freely admit that I don't know well VNC works over public Internet / WAN links. That was always one of the arguments against using X, that the latency of WANs / the public Internet, screwed with it and made it fairly unusable. Not sure if VNC is better in this regard or not.
Why are we still messing around with ancient technology like VNC? Its terrible. It just samples screen output; it does not intelligently understand the underlying GUI so it can't really cache anything or accelerate anything.
If we're going to replace HTML as a "poor man's interface" then we need to do better than VNC. Perhaps NX or RDP.
Still, I'd argue that HTML as a poor man's interface is perfect. I could sit down a write a HTML-based control panel that uses next to no resources. With VNC or whatever, now I need X running on my server, a GUI window manager running, and need to write a desktop app. This isn't progress.
If we're going to replace HTML as a "poor man's interface" then we need to do better than VNC. Perhaps NX or RDP.
Well, I certainly won't argue against that. But at least with VNC it's being used for the purpose it was developed for. Personally I feel like trying to build complex application UIs with HMTL/CSS/Javascript is trying to shoehorn a square peg into a round hole. Browsers are great at, well, browsing hypermedia. I'd like to see that continue and the adoption of something like RDP, NX, or $NOT_INVENTED_YET for remoting interfaces.
But HTML isn't usually "remoting" an interface anymore, it _is_ the interface. This trend will only continue and solutions like VNC, NX will become unnecessary.
I used to use VNC viewer with ssh tunneling, I wonder if there is a way to do that with this extension...
Switched to NX, but didn't set up the web viewer yet, so this would be an easy way to work on the road if could do ssh tunnel.
I'm running Ubuntu 12.10 proper, and my version is 25.0.1364.152. And the update hasn't been in the last couple of days, either; there's already a Portable Chrome build of 25.0.
And unlike Chicken of the VNC, this one actually supports the scrollwheel! (maybe there's some way to get Chicken of the VNC to support the scrollwheel but I didn't find it. I did find "Chicken", a fork of "Chicken of the VNC". It's got various connection bugs.)
No luck with copy and paste from Chrome OSX to Ubuntu 12 but maybe I'm doing it wrong
Google captures greater profits and influence by flogging people its DRM-infested ChromeOS machines for cheap, claiming they are hyper secure.
On the face of it, that may be right, but privacy and independence are lost. Victim buyers discover they can't do anything without either paying more money or being online (ie. under surveillance from the GooglePlex).
To support Netflix and similar Google plans to implement DRM on these platforms. They have expanded their offices in LA over the last few years. They seem to be using not only conventional DRM as a layer of protection, but also a trusted platform module (TPM) protected boot sequence that validates that the environment has not been tampered with prior to executing the DRM-related code. I believe they are also using operating system level containers via LXC, as a more powerful and language-neutral extension of the Java-centric model on their other mobile platform, Android. Finally, the devices do not have any significant local storage, which means you couldn't really pirate content even if you decrypted it: there's nowhere to put it!
Oh OK, I didn't actually read those I was just posting the likely link that popped up on a search. Feel free to do your own research then.
'Developer mode' that disables consumption of things you have paid for on a machine that has virtually no storage? Sounds great. Why do you seem to support them?
Yes, developer mode erases the machine for security reasons.
I don't see to support them, I do support them on this (I actually am not a fan of chromeos in general), because it is still a huge step forward over almost all available newer "locked" machines available.
Your solution is what exactly?
It seems they've done the best pragmatic thing they can do here.
It enables DRM and content for those who want it. Those who don't, can still do what they want with the machine.
If you want to have your cake and eat it to, yell at netflix/et al.
It's not like Google has an real leverage here. They've tried for years to get anywhere with other strategies.
Oh, for security reasons! Whose security? Let's be honest here: the content owners. It's classic DRM: you buy the device and it works for someone else. My solution is to strive to avoid buying, supporting or discussing DRM-crippled devices except to reveal their true nature to the wider community. "Don't be evil!". Puh-lease. Anyone know what Google spends on PR? I'm sure it's either hidden or shocking.
You don't have to cycle between 2 application platforms: the host OS and your browser. If you already use a lot of web apps this is a real frustration. You essentially are running 2 OSes with separate conventions and context switching between those is not pleasant. This is why things like Fluid exist.
I hacked together an open source VNC viewer which can run on the ARM Chromebooks[0] earlier this year. Source code at [1]. It't far from perfect but it did what I needed it to do.
1. Download VNC Viewer for Google Chrome to a Windows, Mac OS X, UNIX, or Linux computer, or to a Chromebook or Chromebox with an Intel processor (support for ARM processors coming soon).
I would like to add this to Chrome just in case I may use it but Chrome already has a 400MB memory footprint on my laptop. So I'll stick to teamviewer...but nice to know this is available if need be.
VNC servers can run on Linux, Windows, OS X. This is more similar to running VNC client as a native binary for your OS, except this lets you do it in Chrome.
The biggest benefit I can tell is if you can run this on Chrome OS now. That, and pushing the technology forward.
I am quite frustrated by the confusing mix of extensions vs "legacy" apps vs "hosted" apps vs the newfangled "packaged" apps. The chrome web store is extremely confusing and the documentation is all over the place.