Do features like Chrome Remote Desktop give anyone else goosebumps?
I love that Chrome automatically updates with security and performance updates. But an IT professional and someone who is security conscious, it's concerning that users' web browsers automatically install new attack vectors.
I'm sure the NSA, every other three letter agency, and skillful botnet programmers and hackers are just tickled that Chrome is opening up new avenues for infection.
Here's the how-to if you have some spare Google account credentials:
1. Install Chrome and sign in with target's credentials
2. Enable Chrome extension sync
3. Install Chrome remote access extension
4. Wait
5. ???
6. Profit!
Welp, at least Chrome for Windows has group policies to control (some) of this, but the policies often lag behind the new features. Chrome for Linux users? I guess they're SOL. Hope your company's administrators have init.d locked down or something to prevent Chrome from installing its hooks into your system during a regular apt-get/yum update.
Edited in P.S.: Google, are you there? Are you listening? As a system administrator, what would tickle me would be the ability to freeze the attack surface area of user's machines. i.e.: they can't install new extensions and apps, they won't have any features that add new remote access features enabled, etc. I would like to be able to say, "I trust my ability to lock down Google Chrome 37", configure that, and not have to worry about an automatic update annihilating my security policies.
Finally, automatic extension updates give me the creeps. At any moment, bam, suddenly my users' harmless extension is now owned by Shady Joe's Botnets 'R' Us, and their passwords, web traffic, and safety is compromised.
Extension sync doesn't automatically enable remote access to your machine. User must explicitly enable access on each machine that needs to be accessible (and to do that the user must be administrator).
Also the remoting service needs to be installed separately from chrome - it's not part of the extension. It's not possible to package native binaries with chrome apps/extensions, by design (except for NPAPI plugins, but extensions with NPAPI plugins are not synced and NPAPI support is being removed from Chrome).
On Linux you can disable automatic update both chrome and CRD. Just set repo_reenable_on_distupgrade to false in /etc/default/google-chrome and /etc/default/chrome-remote-desktop
Great to hear back from the team. Do you know if we can expect better stability from this than from hangouts? I'm thinking of: https://code.google.com/p/chromium/issues/detail?id=363358 which I had the displeasure to run into last time I had a conference call scheduled.
Now, I don't fault the hangouts team for encountering a bug -- but it's frustrating (perhaps doubly so for Debian/stable users) when something like hangouts stops working -- and that without there being any obvious reason (eg: new features, important fixes) for why something that used to work, suddenly stop working.
If I could still edit it, I would correct my post to say that a user that has not activated remote desktop does have to enable it manually.
But there is still no way to control Chrome's surface area in the future, and features like this give me the heebie-jeebies. Two things:
1. Users that have already enable Chrome Remote Desktop don't need to authorize the set of computers that can access it remotely. You authorize one endpoint, but not the other. And since Chrome will occasionally install new extensions and apps in its regular updates, there's no notification for a lay user to know why they got "Chrome Remote Desktop". For that matter, anyone with access to a Google account can leverage one Chrome sync feature to gain access to others (mainly: from an extensions into completely owning their machine), allowing them to leverage Google account access into a much greater vulnerability on remote physical machines. Passwords, open tabs, history, form data, credit card information.
Let me walk you through this. Alice is using her computer at work. Eve has obtained Alice's credentials, and sets up a Chrome account on a machine and enables full sync, and installs the Chrome Remote Desktop extension on her computer.
Alice sees a new extension appear on her computer. Why is it there? Alice is never informed, and Google adds new apps and extensions with updates occasionally, so Alice proceeds to install Chrome Remote Desktop. Why not? Chrome seemed to think it was safe to put on her front page or in her app bar. Eve can pin it to her bookmark bar with a title like "Connect from home!", or even install multiple bookmarks to do this:
"Connect from home" "now today" "with Google Chrome" "Remote Desktop!"
Now it's just a matter of time. Eve could also use her access to the account to synchronize new extensions silently and in the background, allowing them to siphon off passwords and credit card numbers, even if Alice disallowed those items from synchronizing. Extensions are simply too powerful and the automatic update feature makes every extension from a third party developer a ticking time bomb.
2. You don't really offer a great way of blocking increases to the attack surface area of Chrome. You offer a way to totally turn off all Google Chrome automatic updates, but woe is the administrator that tries to use your policy tools to lock down Chrome. As Chrome is becoming an operating system unto itself, I find myself at a loss to understand why policies for this new operating system lag behind. Your suggestion doesn't prevent Chrome from automatically updating or synchronizing new extensions, and doesn't provide the average user with protection from a hijacked Chrome account. Disabling Chrome's automatic updates, if anything, makes them less secure.
No, what I want is the ability to lock Chrome's surface area to a particular version, not lock Chrome to the version itself. I want to see ways to limit my liability as an administrator to what I know and understand - and the Chrome team seems to think they know better than I do how to keep lay users safe. I disagree - given the fact that me, the security paranoid user, has already been bit by Chrome's security policies, I have no hope that they will avoid the same fate.
Now it's just a matter of time for what? For Alice to enable remote access on her machine and set the mandatory pin? How does this help Eve?
Moreover, your scenario presupposes that Eve has Alice's Google credentials. At that point, Alice is already owned. Given that most of a user's information is online instead of on a particular device these days, accessing Alice's desktop is not significantly useful. Eve can already pretend to be Alice and send trojans to her friends and then pretend to be Alice's friends and send trojans to her.
I tend to agree with you. But in your hypothetical case, what's different about a someone (the NSA, etc) installing Chrome and enabling the RA extension vs just installing another remote access tool?
Well in the second scenario, they would hypothetically still need to infect you with the RAT. In his scenario, you're already installed version of Chrome will infect you without your knowledge when it silently syncs the new Remote Desktop extension into your existing installation.
Obviously if they have your Google credentials you are in a world of trouble, and I have no doubt if a 3 letter agency wanted to infect me they could, but the scenario he brings up is still troublesome and not at all restricted to highly technical attackers.
I see what you are saying. But the help page basically describes the steps to install a chrome extension. It doesn't say that this extension is specifically prevented from syncing like other extensions. It mentions an authorization dialogue on first run, but it is unclear whether that is the first run per account or the first run per installation of the extension.
I would actually lean towards the latter, as it is in line with extension syncing behavior I have seen in the past. Usually when I am on a new setup of Chrome, and extensions sync and install, they do pop up some sort of installation or setup window notifying you.
Why are we guessing when you can just install Chrome Remote Desktop and try it out?
I've used Chrome Remote Desktop, and the speculation in this thread about automatic extension sync is absolutely baseless: you need someone at the keyboard to actually install the remote desktop features, the extension by itself is not enough.
Is this really the state of HN discussion? It's great that a Google engineer was able to chime in and dispel the wild fears (thanks Sergey), but it shouldn't have been necessary in the first place.
Is the user prompted to understand how the extension can affect them, when it was installed, and where it is syncing from?
To put it another way: if I am a regular end-user and Chrome pops up a dialog asking me to allow the official sounding "Google Remote Desktop App", then why wouldn't I? That doesn't sound scary at all - it's from Google!
You have to install chrome remote desktop on linux and start the service on the machine before you can connect to it elsewhere. I don't see how this is any different than any other remote desktop other than the client is built into chrome now.
Chrome Remote Desktop operates very similarly to LogMeIn, GoToMyPC, etc, in that there's two components: a server, and a client. The server is installed as a standard application on the target machine, completely separate from Chrome. The client is implemented as a Chrome Extension, while competitors use things that don't work on Chromebooks (e.g. Java).
Signing into a target's Google Account won't give you full, unfettered access to their PCs that have the server explicitly installed on them; you must also have a PIN that must be entered before every remote desktop session.
I would appreciate something more advanced than a PIN though. I currently use TeamViewer and I use unique, randomly generated passwords for each node. Downgrading to 4-6 digits doesn't feel very comfortable.
Or perhaps Google could make sure that the PIN also requires a second two part authentication. I mean, the account should already be protected by that in theory, but if someone stumbles upon an active session and the PIN is lying around, at least they'll be stopped by the two part auth.
The technical part of the problem is relying on a commercial 3rd party for authentication. This enables nation-state-level access based on the current laws of the land (the non-technical part of the problem).
that's exactly the problem I thought of. Remote admin programs with any centralized profiles/accounts are pretty problematic, more so if they don't allow alternative login schemes. (Teamviewer, for example, offers password/key/pin OR login.)
Target's google authentication. The user might be using chrome (signed in with google) on a machine that is otherwise used with other authentication domains, and maybe a different (eg: local) email provider. This is why I like Firefox sync much better: they actually support running your own sync server. So you can have your cake and eat it too.
I wish there was a better way for deal with screen resolution. I know that scrolling is a pain, but I'd still prefer it to default to the resolution of the physical display attached to the host computer. (Actually, I'd really prefer it to adopt the resolution of the client machine, a la MS Remote Desktop, but that probably introduces a lot of complexity).
I'd really prefer it to adopt the resolution of the client machine
Even broader: any resolution you want. I genuinely have always wondered what is at the bottom of this problem. Why is it that on an otherwise so versatile and configurable OS it is seemingly so hard to change the resolution when logged in remotely? Is it something in X that makes it like that? Was it originally never meant for headless use? Having used, and cursed the fixed resolution of, VNC for years I still remember the first time I used rdp on Windows, my jaw was like on the floor. That is how it should be: logging in without being bound to a hardware screen, and in a seperate session (latter needs a fix though since the default client on non-server windows doesn't allow it)
There are several versions of VNC that support xrandr resizing. Arch documents this working with TigerVNC [0]. Additionally, you can use xrdp + x11rdp.
> I'd really prefer it to adopt the resolution of the client machine
We have this implemented, but the problem is that the current version of Xvfb doesn't support randr extension. See https://bugs.freedesktop.org/show_bug.cgi?id=26391 . With the patch attached to that bug CRD should resize desktop automatically.
I'm really confused. I've been using this extension to take remote control of my mom's computer, running Ubuntu, for like 2 years or so. And it didn't require to install a .deb besides the extension. Am I missing something?
Finally. Now all 3 of my environments are now supported. I can start downloading games/movies at work and get home to a fully installed game or movie ready to go.
This is the first time I got to know about it from frequenting r/Chrome for help with customization.
Just like all most Google products it looks like it requires both parties to be logged into their Google accounts, so concerns about Google's privacy policies are still valid with it.
Nice to see this was finally added. I remember trying this when I got a Chromebook earlier in the year and was really surprised and puzzled to see the lack of support on Linux. There's even a year+ old thread about it that didn't look good: https://productforums.google.com/forum/#!topic/chrome/VT2_wL... Great to see support now!
I tried it, had issues installing it, here's what I did:
1) Tried sudo dpkg -i chrome-remote-desktop_current_amd64.deb
2) It complained about missing dependencies.
3) I tried aptitude and one of its choices was to remove the Linux kernel, nah.
4) So I ran my trusty Synaptic and it immediately detected the broken package, I clicked Fix, Apply, and it worked fine.
VNC (even the various 'Tight', 'Lite', 'Whatever' variants) is horribly slow -- usable in a pinch, but every UI/UX interaction is just delayed enough that nothing feels 'right'. Chrome Remote is much more responsive, it feels more like Windows Remote Desktop Protocol speeds, perfectly usable almost as if you were local.
Also it does initial connection handshaking so if you login to chrome from machine B and machine A is already set up for Chrome remote you can just connect there via a list of endpoints without having to know the external-facing IP address and/or setting up firewall tunneling.
It probably has its own intermediate proxy with a "lawful" intercept interface (i.e. pies everything to the NSA). Well, I wouldn't be surprised if that conspiracy theory would be true.
Well, I don't know about that, but it is law that services over a certain size have to have a lawful intercept interface (e.g. Skype has one) and it is know that this interface gets abused by secret services.
If you try it out you'll notice that it's just better. I don't know the internals of it, but I suppose it uses more modern codecs for transmitting the screenshare. The experience just feels a lot snappier.
I love that Chrome automatically updates with security and performance updates. But an IT professional and someone who is security conscious, it's concerning that users' web browsers automatically install new attack vectors.
I'm sure the NSA, every other three letter agency, and skillful botnet programmers and hackers are just tickled that Chrome is opening up new avenues for infection.
Here's the how-to if you have some spare Google account credentials:
1. Install Chrome and sign in with target's credentials
2. Enable Chrome extension sync
3. Install Chrome remote access extension
4. Wait
5. ???
6. Profit!
Welp, at least Chrome for Windows has group policies to control (some) of this, but the policies often lag behind the new features. Chrome for Linux users? I guess they're SOL. Hope your company's administrators have init.d locked down or something to prevent Chrome from installing its hooks into your system during a regular apt-get/yum update.
Edited in P.S.: Google, are you there? Are you listening? As a system administrator, what would tickle me would be the ability to freeze the attack surface area of user's machines. i.e.: they can't install new extensions and apps, they won't have any features that add new remote access features enabled, etc. I would like to be able to say, "I trust my ability to lock down Google Chrome 37", configure that, and not have to worry about an automatic update annihilating my security policies.
Finally, automatic extension updates give me the creeps. At any moment, bam, suddenly my users' harmless extension is now owned by Shady Joe's Botnets 'R' Us, and their passwords, web traffic, and safety is compromised.