The ability to take my critical secret information into a huge, buggy, extensible, unaudited, complex and constantly changing browser environment! Who could resist?
This will also inspire innovators world-wide. Look at it this way: we can now find novel ways to steal passwords, secret keys, log sessions, access servers, sneak in trojans.
It is unfair to label this poor quality, the author clearly describes a problem with moving a security tool like SSH into the browser.
Despite Chrome being speedily updated when known security problems are discovered, the attack surface compared to a dedicated client is huge: the 2-decade-old /usr/bin/ssh + /usr/bin/xterm combo has no concept of a DOM, does not share computing interfaces available to untrusted users (e.g. shared web workers), cannot receive messages from untrusted frames (postMessage()), cannot even be addressed by untrusted content (chrome://path/to/trusted/script), does not almost transparently expose ring0 drivers (OpenGL), does not have thousands of LOC on subsystems with little battle testing (WebRTC) and so on.
Of course these features are thought to be secure, until they are discovered in the midst of a Stuxnet type scenario and suddenly everyone is patching like crazy. Wasn't Java considered invulnerable only 2 weeks ago? Look at what changed - somebody noticed it wasn't long after tens of thousands of infections already occurred, and today it is on every browser's plug-in blacklist. I can't recall the last I read about xterm in the Pwn2Own contest, or any 0-day in the past decade, nor can Google accidentally DoS my xterm because their sync service is down (happened last month).
Following from the truism that the fastest, most bug-free code is code that doesn't exist, the easiest way to reduce exposure to unknown attacks is to minimize the amount of code running. Security design 101. Using something with the complexity of a web browser to render an 80x25 vector used to administer potentially hundreds of thousands of machines is almost the antithesis of good protocol.
Do most people run ssh and xterm on a bare-bones OS, or are they running on a full OS stack?
An OS that they may or may not update frequently.
An OS that they may or may not be logged into as an admin.
An OS that may have a keylogger running on it.
I think running SSH (or Chrome Remote Desktop) from a Chromebox is a pretty good way to have that minimal OS that is updated frequently, without admin privileges, with a lower risk of a keylogger. That I have to use two-factor to log into, even if my device is stolen.
"It is unfair to label this poor quality, the author clearly describes a problem with moving a security tool like SSH into the browser."
Yes, I agree. The grandparent does point out a valid problem. However I believe the parent was referring to the sarcastic tone and negativity, which I also believe should be out of place here on Hacker News.
Just a quick note, but implicitly asserting that xterm is a very secure program will weaken your argument. From http://st.suckless.org/ :
xterm is bloated and unmaintainable. Here’s an excerpt from the README:
Abandon All Hope, Ye Who Enter Here
This is undoubtedly the most ugly program in the distribution. It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs. We are trying to
clean things up as we go, but there is still a lot of work to do.
Needless to say things have not changed, it’s still ugly. It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternative, rxvt has only 32K lines of code. This is just too much for something as simple as a terminal emulator; it’s yet another example of code complexity.
And I am saddened by the not-so-recent yet constant Reddit-bashing over aspects of discussion that appear on HN and not necessarily at all on most programming-related subreddits. Those, in my experience, have a level of discussion quite comparable to HN[0].
[0] in a technical sense, the startup focus is quite unique to HN. or maybe I don't subscribe to startup-related subreddits (since startup news is not really the reason I read HN either)
You will find many sarcastic comments in HN. This has nothing to do with Reddit. However, I do appreciate when HNers add in a "/s" or something alike to make it clear that sarcasm was used.
You can find quality conversations in Reddit but, more than likely, not in the default subreddits.
People have been complaining that Reddit was taking over years ago and will continue to. Strangely while people posting cat pictures is downvoted for not being productive conversation comments like this get upvoted when it contributes just as much. Heck its even in the guideline:
If your account is less than a year old, please don't submit comments saying that HN is turning into Reddit. (It's a common semi-noob illusion.)
Although I know you have been around for more then a year.
To be fair, 90% of the Google SWE interns last summer were given chromebooks (instead of MBP) as their laptops (to supplement their workstations). They were extremely disliked.
Come now. The interns weren't given nice computers, but they were still liked. And FWIW, the only real problem with Chromebook as corporate dumb terminal is the tiny screen resolution.
My answer was sarcastic, but there were real issues behind. Call it "informed sarcasm". Having used ssh since 1995 (on systems like SunOS 4.2 and UNICOS) I felt entitled to a bit of sarcasm.
I thought it would be obvious to most readers how a tty environment is easier to control than a browser (really, just consider the number and pace of updates to your kernel/windowing system/terminal and your web browser), so I did not bother with lengthy explanations.
Even that has some security utility because it can enable SSL certificate pinning and prevent phishing. I don't know if they're using it that way, but it makes it possible.
The banks operate on the assumption that their user's machines will be compromised and have undertaken plenty of steps to manage their risk e.g. two factor auth, transfer limits etc.
> The banks operate on the assumption that their user's machines will be compromised and have undertaken plenty of steps to manage their risk e.g. two factor auth, transfer limits etc.
I've written about this before at length, but I'll say it again here: the security practices of most major banks in the US are laughable. This applies to both online and offline banking.
In addition to, and IMO more important than, the technical efforts that banks dedicate to online security, there are the business practices that they dedicate to security. These include tracking and predicting loss, budgeting to cover and recover from those losses, purchasing adequate insurance to cover their risk, detailed record-keeping internally, and detailed communication with their customers.
Let's say your online banking browser session was hijacked and the bad guys transfered $100,000 out of your account. First of all the bank is likely to flag that transaction for closer review since it is probably a big departure from your usual behavior. Second, they are going to confirm its accuracy with you, at the very least in a printed or emailed statement to you that it occurred. If they are good, they will call to make sure you meant to do it. Third, they are going to keep records of what happened--the IP address that was connected when the transfer was requested, the time of day, where the money was transferred to, etc.
If it becomes clear that the transfer was a theft, then the bank will cover it as loss and you will get your money back. This is why online banking is not security-critical. Because there are numerous online and offline processes that mitigate the risks associated with online banking.
Now compare to managing your own webserver. The webserver is a dumb machine, not an intelligent counterparty like a bank. If your access to your webserver is hijacked, the webserver will not do a thing to detect, protect, or recover from whatever the bad guys do. Or more specifically, it will do only what you have specifically set it up to do.
By analogy, the lock on the front door of your house is "more important" than the lock on the front door of the police station--because there's no one behind your front door but you, while the police station has dozens of armed and trained officers behind their front door.
Chromium is open source, the extension is open source and it runs on nativeclient which itself is open source and was designed and audited to be secure and sandboxed. Making it secure and sandboxed was part of the initial goal of both Chromium and nativeclient, and again, they and the extension are all open source and audited daily by Google engineers and tons of security companies.
It is perfectly possible that Google is doing all sorts of Evil Stuff (TM) in the binaries that they ship out. I don't think it's likely, because a fair few people will be examining the packets it sends -- but it is possible.
The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.
Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides.
With Chrome, that isn't possible. It is based on Chromium, but includes non-open source code, and so you cannot immediately build it.
However, in the end, they're just executables. Looking at assembly isn't quite the same as looking at source code, but we could examine the additional components and try to identify any malicious parts. At least in theory -- the work involved would be quite big.
All non-open source code in chrome should be in plugins (or otherwise separate DLL's), not chrome's main binary.
If you know of a case where this isn't true, please let me know.
You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
That's true. I know profile-guided-optimization is used for Windows builds; unsure on other platforms.
Actually, this sounds like a fairly interesting project to me: Given a tool chain and a source code base, can we prove this was a possible compilation? In the case of deterministic compilers this is trivial, but as you highlight, not all optimizers are.
I'm fairly certain that PGO is used for all of the official binaries. I do know that Arch Linux's package (which is from source, not official binaries) is compiled with PGO, so the support is definitely there.
Theoretically, you should be able to compile a bit-identical release. Practically, you won't. (Or at least, I'd be very surprised)
Re-creating bit-identical copies is hard when you _try_ to make it happen for your project, and I can't see any active efforts for that in most OSS projects.
Timestamps in .o/.lib files, use of system libraries, optimization heuristics, exact versions of the entire toolchain, and many more "fun" issues prevent that from happening, usually.
Do you really think open source and security audits actually means much ? You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them.
>You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them.
Yes, and your point is? Security audits do mean much, that's why they are done. Open source means a lot as well, it means that if I don't trust a software, I can check it if I want to, rather than accepting what a company is telling me.
There's a reason why cryptographic stuff is almost exclusively open source, it's because security through obscurity doesn't work.
That said, the amount of exploits for open and closed source software is more of less equivalent, but the time to fix is usually shorter for open source code.
Oh right... because putting your critical secret information into a huge, buggy, extensible, unaudited, complex, and constantly changing operating system is so much better!
Or, from another point of view, an attacker has to bypass Linux and OpenSSH security in one case or bypass Linux, OpenSSH and Chrome security mechanisms in the other case..
I understand what you mean, but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve.
And more so if, for example, address space randomization is offered by the OS. In this case the security model is reinforced, rather than weakened.
but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve
You're making no sense. The previous attack vectors don't go away when you put your keys into Chrome. Chrome becomes an additional option for the attacker, not an additional "step".
A house with two doors is less secure than the same house with one door.
I'm a bit baffled to what degree some people here try to deny the obvious.
Yes, you can use ssh-agent with chrome (if they have that implemented, I don't know). Yet you are still in trouble when the chrome sandbox gets compromised, because all your keystrokes are passing through it.
From what I know they don't impement ssh-agent. Do you consider ssh-agent as another attack vector or additional security?
If the sandbox is compromised to have file system access, a process can read your keys from ~/.ssh as well as chrome storage files.
Otherwise a webpage has to escape its own sandbox, bypass the native client's sandbox (in a different process) composed of the inner and outer sandbox and then access the native client.
I'm not saying that it's impossible, I'm saying that using a simple analogy as "a house with two doors" might not be the best.
Otherwise a webpage has to escape its own sandbox, bypass the native client's sandbox (in a different process) composed of the inner and outer sandbox and then access the native client.
Or there could be just some really dumb bug that somehow enables cross-process access. With javascript. You know, one of these silly brown-paper-bag bugs that are not supposed to happen.
Either way, this is the second door. It may be a shiny steel door, but it's an additional door.
The other process might as well be ssh itself at this point. Anyway, we are just speculating, also the wall is another door if you smash through it. Just don't use it then.
Can I phrase the same objection in a more HN-y manner?
SSH terminals are high-sensitivity software. We frequently use them, with very sensitive credentials, to log into secured servers. There are two zones of trust involved: we trust that our local machine is not rooted, and we trust that the server is not rooted. The magic of SSL means that no matter how foul everything is between those two zones of trust, we can't get compromised.
If we embed the SSH terminal in the browser, we now have four zones of trust: our local machine, the browser, the SSH terminal extension, and the server we connect to.
This is a very scary broadening of our attack surface. While the terminal app siting on your machine is decades old and has been tested extensively, the browser extension almost certainly has not. The browser extension, in addition to possibly having vulnerabilities itself, is executing in the context of the browser. The browser is a very scary place to be, because its whole mission in life is connecting to the untrusted, infected cesspool of the Internet and then doing what the Internet tells it to. By grace of God and Google engineers, we generally assume that our browsers aren't going to crack out of the sandbox surrounding the sandbox surrounding the sandbox that all that evil Internet stuff is executing in, but we expect that, in the normal course of operation, those inner sandboxes are going to fall into the hands of the enemy, repeatedly.
It therefore seems to be an exceptionally bad idea to take our holiest-of-holy credentials and move them inside the sandbox, closer to the attackers.
This is particularly true in terms of a risk/benefit analysis, since the risks are incredible and the only benefit is "Saves you from having to do a single key chord to pop open an additional terminal on your machine."
This is moot if you have total confidence in the Chrome and Native Client teams to never have a mistake which lets someone, e.g., read arbitrary process memory. That's happened before -- Mark Dowd et al found it. That would be pretty sucky if it happened on a browser you logged into your bank, because the attacker can probably grab your cookie and banking session. It would be much worse, though, if it happened on a machine used by a bank sysadmin who unwisely decided to use a terminal within his browser, because why steal one session when you can just steal the bank? (n.b. Note how this is possible without causing Chrome to execute arbitrary code or defeating the OS's protections against Chrome doing stuff outside the Chrome-box.)
Additionally, the Secure Shell application follows a strict Content SecurityPolicy that does not allow access to the JavaScript 'eval' function. This helps lower the risk that a terminal exploit could run arbitrary JavaScript.
Translation: Don't worry, if the bad guys already own your server/local machine, it's less likely they'll be able to go from owning your server/local machine to owning your browser, because we make them have to jump through a few hoops to execute arbitrary Javascript.
I'm having one of those rare, weird moments where I disagree with someone I enormously respect in a field, on that field, and think -- even after reflecting -- that even with the "They're so smart about this they're probably seeing something you aren't" modifier the words that are coming out of their mouth are, in fact, not right.
Edit to add: I previously used the language "batshit crazy", but on reflection you could envision an attack like "Attacker gets arbitrary content written into a web server log; if we cat this in the JS context, we turn totally harmless text that wasn't executing on the server or the local terminal into executable Javascript." But I still really think that is less likely and less severe than bootstrapping a browser, NativeClient, or extension bug into "Root all the boxes."
It is possible to use this sensibly - e.g. I don't really see the problem with using this to play a MUD/roguelike/etc. In that context, their security worries make complete sense.
On the other hand, for certain environments, browser access is game over anyway. I'd expect that snarfing your customers' credit card info out of your admin consoles would get an attacker 99% of the value (s)he'd get from completely rooting you - just how careful are you about separating the internet and your admin consoles? Just how careful is the average HN user? (Note that your admin consoles would need a custom attack, though, while "open a reverse shell when logging in" would be considerably more general.)
But yes, for many, many people, this is really scary.
I tend to agree with you, as most folks would. But perhaps this approach is being driven by the "Chrome as Operating System" approach and the Chromebook.
Google is a big enough company that the thought process is being driven the by internal needs and wants, not necessarily by what the rest of the universe is doing.
It hurts my head to see people refer to a "sandbox" as if the term means anything in isolation. Sandboxing is a strategy that covers a broad spectrum of implementation quality. Take Java's "sandbox," which is just its VM layer employing a complicated stack inspection based permission model. In practice it's very porous, and has a very poor security history at various levels.
You also mentioned Flash, which has a VM "sandbox" for Actionscript, with a simpler, mostly origin-based security model. Depending on the platform there's also an outer Flash sandbox using OS-based security primitives to various degrees. Since Adobe built their own NPAPI sandbox on Windows (mostly for Firefox), it's a good one to point to. It prevents write-level access to most objects, and relies on a broker process to manage those actions. Most objects are readable from inside the sandbox, and various low-privilege objects can be directly controlled as well. Historically, Flash has a better security track record than Java, but has still had its share of issues.
Then there's the Chrome sandbox. Once again, there's a VM level "sandbox" for JavaScript and one for NaCl nexes, both using a strict origin-based security model. Then there's an outer sandbox using the OS-based primitives that deny access to all objects, requiring all resource access to be routed through a broker process. Chrome is generally considered to be very good on the security front, and has yet to be hit with an exploit in the wild.
I could actually into very deep detail on how these differ, and the effectiveness of each sandbox implementation, but I think the broad descriptions convey my point.
And guess what, they're also two of the most widely installed software.
The truth is that sandboxes are effective in mitigating the attacks, because they add another level of security. Even safari added a sandbox a couple years ago.
Building an SSH client as a Chrome app doesn't introduce attack surface from web content. The SSH client and web content run in different sandboxed processes and don't share resources. For the web content (or another Chrome app) to break into the SSH client, it would need arbitrary unsandboxed code execution, which means it could manipulate any process running in the user's context. So, the threat model doesn't change from a standalone SSH client.
The bugs Mark found in NaCl several years ago don't alter the threat model for a standalone SSH client either. And for context, Mark's work was done while NaCl was in alpha development, years before it shipped in Chrome; were performed as part of a Google sponsored contest and later a Google paid audit; and applied to the NaCl validator sandbox, not the outer process isolation sandbox. So, even the more nebulous threat you're implying is grossly misstated.
For the web content (or another Chrome app) to break into the SSH client, it would need arbitrary unsandboxed code execution
Respectfully, I think you might be limiting the attack space here in a fashion that attackers are not restricted to doing. For example, there appear to me to be opportunities for side channel attacks which do not require the bad guys to totally break your sandbox model for them to be able to guess at what another Chrome process is doing. Given that they'll have a local vantage point to do the timing measurements, and consequently very high precision, it's at least possible that they can guess things about the operation of the SSH process. If the guess the right things, they don't need to cause the SSH process to execute any code at all. (If memory serves me, that's previously been used to time OpenSSL's encryption/decryption itself, but there's probably other vectors if that isn't an option these days, like timing I/O operations with sufficient precision to guess what they were.)
There's an interesting question on whether moving the SSH into a Chrome process makes it more vulnerable vis-a-vis other Chrome processes to timing attacks than it would be just by being on the same box with a Chrome process. I would not trust myself to say "That is definitely more of a risk" with the level of research I've done, but I think it is highly unlikely that it gets less risky.
I don't mean to be rude, but you seem fundamentally confused. The argument you've strung together here isn't in any way specific to an SSH client built as a Chrome app--and is a just a nebulous claim that applies to any execution contexts sharing the same system.
What if the attacker compromised the GPU process without compromising the entire sandbox? If hardware compositing is on, they could snoop on the SSH window contents. (Then again, they might be able to do that even with a separate application...)
Yeah, the GPU process can do this regardless due to the way Windows forces any accellerated GPU app to work. I'm not sure if you dug into this before, but the GPU does run as low-integrity for UIPI purposes on the interactive desktop (lower for other object access). Unfortunately, the desktop window, screen, and display state are still exposed at that level. We're digging into AppContainers to see if tighter restrictions are possible on Win8, but usage is still so low that it's not a priority.
Sorry I focused solely on Windows, but to my knowledge all platforms we support have similar architectural niggles in terms of the GPU process being able to read anything that's displayed.
What about the traditional SSH client as a zone of trust? It's unfair to ignore the client in the traditional case but count the browser and extension as two additional zones of trust in the Chrome case.
Client-side exploits in SSH clients have happened before[1]. The scope of such exploits is arguably reduced when running a sand-boxed application in a browser compared to a regular application on the local machine.
That being said, I agree with your general point that using a browser as an SSH terminal dramatically increases the attack surface, compared to a small dedicated client.
Multiple integer overflows in the (1) sftp_pkt_getstring and (2) fxp_readdir_recv functions in the PSFTP and PSCP clients for PuTTY 0.56, and possibly earlier versions, allow remote malicious web sites to execute arbitrary code via SFTP responses that corrupt the heap after insufficient memory has been allocated.
They call out to your existing SSH client, so if it's vulnerable, wrapping it in NativeClient means it is still vulnerable. By comparison, my SSH client doesn't go to Chrome and say "Hey guys, apropos of nothing, please hang onto these SSH keys so we have something to give anyone who successfully is able to read memory from any one of fivish subsystems in your under-constant-attack product."
[Edit: On re-reading, I think I misunderstood this, and the comment beneath this one is substantially correct regarding them bundling OpenSSH. I still think this is substantially more attack surface than however you're consuming OpenSSH code currently.]
As I read it the whole SSH client is an OpenSSH port running in the NativeClient sandbox, which does make it safer in terms of SSH client exploits, in the sense that the exploit doesn't give you immediate control of the local machine.
Secure Shell is a Chrome Application that combines the "ssh" command (see http://openssh.org/ for details) ported to NativeClient with the "hterm" terminal emulator to provide a secure shell client for the Chrome browser.
I'm not familiar enough with the multiple sandboxing levels of Chrome to judge the risks of one malicious website accessing the memory of the Secure Shell extension. I guess you have a point, although I would expect the "each tab in a separate process" model to mitigate this concern?
we generally assume that our browsers aren't going to crack out of the sandbox surrounding the sandbox surrounding the sandbox that all that evil Internet stuff is executing in, but we expect that, in the normal course of operation, those inner sandboxes are going to fall into the hands of the enemy, repeatedly.
Why? The whole model of Chrome is that there's a multi-process conglomerate with clearly defined interfaces between them and OS enforced boundaries otherwise.
Why would it be easier for a malicious JS payload running on Process A to attack the Chrome SSH extension running on Process B than to attack the terminal or openssh processes?
Hard to suppress my smile reading this; this post would also have been appropriate when businesses were transitioning their LOB data-entry apps from VB6 to being web-based. Just for your sake I hope an issue is found so you can point back to your prescience, in all its chicken-little-style glory.
Thanks for the reminder that new software is less secure than old, and that new technologies often widen attack surfaces. There is little doubt in my mind that this is just the beginning of Chrome native apps, and they have to start somewhere.
It's a word coined by pg that's sort of a term-of-art for the depressing tendency of the top HN comment to be something which pooh-poohs the company/topic/idea in the submission, doesn't add anything to the discussion, but (crucially) is worded convincingly enough to not just end up on the bottom of the thread.
e.g. "Lol that suckz because Google can steal ur passwerdz!" would not end up at the top of the thread. We wouldn't be terribly worried if someone actually said "Wait, I just audited NativeClient and it turns out you can achieve arbitrary code execution. Maybe you should avoid this software." The danger zone is comments which sound like the second but, on reflection, only tell you about as much as the first.
Ironically the concept of a "middlebrow dismissal" seems to me to enable what it condemns--e.g. HN'ers can now just post "hey that's a middlebrow dismissal" instead of a detailed statement of why a particular response falls short.
Basically I think pg made it worse by giving it a catchy name.
This makes sense, but it makes me think that (in the interest of having a good top post) you should have top-leveled your in-depth comment rather than responding to olalonde's as you did. Your comment then could have (and probably would have) been voted up to the top.
I don't see that the whole source is published, exactly like the whole source of Chrome is not being published (Chromium is Chrome minus "the souce", e.g. additional code (for what?), installers etc). I haven't even seen any analysis of all the stuff Google does in the pieces of the code that aren't published. It can be done, somebody should just really want to do that.
Disclaimer: I avoid Chrome browser exactly because I don't have enough information to know if they really "aren't evil." I don't claim there isn't such information somewhere, just that I don't know about it. My worries are exactly because their installers install more like a malware than like clean projects ("no we aren't going to let you to simply download executables, just click here, give us administrative privileges and enjoy when we download what we want and change on your machine what we like").
Just use Chromium instead. You can audit every single line of code and build it from scratch on your own machine with your own reflections-on-trusting-trust-safe-compiler. Or you can install Debian's version.
Never heard of this. I just read it twice to understand it. Great explanation of a widely unknown problem I guess. From now on I will never ever tell people an application is safe if you can look into the source code. Thank you so much!!
And yet having the ability to look at source-code yields the greatest level of safety there is.
Apps without source-code cannot be trusted by default, unless you have a contract with the company providing it that stipulates a relief agreement that's reasonable for you in case anything goes wrong. And only enterprise software does that, depending on how you negotiate nonetheless, otherwise for consumers the EULAs are doing the exact opposite. And even with enterprise software guarded by good contracts, even then you need the source-code.
There is some additional food for thought in it when you realize that all life forms* are basically self-replicating DNA compilers. That is, compilers compiling compilers, which in turn compile more compilers. Thus, there's a chance some crucial information is actually stored "nowhere", i.e. is bolted in by complier which builds another compiler.
For more abstract take on this topic, I direct to Gödel, Escher, Bach; Hofstadter elaborates there on the fact that the distinction between what is data storage (e.g. music CD) and reading device (e.g. music player) is somewhat arbitrary, and in fact the information itself is "stored" in the combination of "data storage" and "data reader".
Your suggestion is exactly the opposite of the information I'm looking for. I'm interested what's there in the code that they don't publish but that is behind the "download now" links, that's what 99.99% of people are going to use anyway.
It's certainly reasonable to admit that you lack the time and/or expertise to evaluate a piece of software, but I don't understand how you translate that into a justification for obvious FUD like "their installers install more like a malware than like clean projects."
The additional code for Chrome should be separated into plugins or otherwise dynamically loaded things.
Again, if someone knows of cases where this is not true, let me know.
And we would never know that the wifi program they used had kept logs unless they told us. The very first mention of the problem was a press release by Google.
In the same press release they said they fixed the problem and would be deleting the logs, but many governments quickly stopped them from deleting the logs so they could investigate.
That's probably why they announced they would delete them before they actually did. And the investigations found that Google was not at fault for accidentally recording unencrypted publicly transmitted data. ;)
This is basically false.
As I've said, at least on desktop platforms, if you were to remove the extra shipped plugins from Chrome, you should end up with something you can build from chromium source
Great point regarding private keys. Even if you trust the extension (no reason not to, really), a future bug in chrome could expose local storage to sites you visit, other extensions etc. /paranoid
I don't troll interwebz from my terminal/putty, so I'd say there's a smaller risk of that happening there.
I'm not about to install that extension and find out myself as that could cause some... serious problems... but that was my first thought as well. What's to stop this from doing something nefarious? Its sandboxing privileges are not remotely clear from what's in the app store, and I don't see of any reasonable way to contain what it can and cannot do.
Granted this is equally a problem with any terminal emulator that you didn't compile yourself after examining the source code, but I have quite a bit more faith in Apple and the various Linux repo maintainers than some random guy publishing to the chrome app store. I don't know if Google even claims to vet its contents, but if they do I know they do a terrible job because I've ripped open some extensions to confirm they're doing some sketchy stuff (nothing insecure or worrying, more like adding affiliate links to your entire browsing experience)
Not only that, it's an official part of our Oncall toolkit. I've got coworkers for whom a chromebook is now the primary (and only) laptop, even when oncall.
Nothing that matters; Everyone needs to carry around their corporate laptop, one-time-password token, and have configured VPN and ssh clients. The rest varies by team and job role.
I've been using this for quite some time, and there are basically two use-cases: a)alternate to putty for windows and b)an actual shell in your browser (You press Alt+1 instead of Alt-tab).
Gave it a try. I find the interface to be very confusing. For example, the opening screen has a button with text "[Del] Delete", but hitting the Delete key instead takes me back to the previous page instead of deleting anything, and clicking it doesn't do anything.
It took me a while to figure out how to get it to try to make a connection - even though it says "Enter" you actually have to press Enter twice.
It then took me to a page with a link to the FAQ, which I tried to click on, but the link was not clickable. Also, the clipboard behavior is incredibly irritating: selecting any text automatically copies it to the clipboard with a giant SELECTION COPIED popup. It's also inconsistent: double clicking anywhere flashes the same SELECTION COPIED, which turns out to be a lie. It doesn't actually modify my clipboard in this latter case. And when I actually hit Cmd-C, it unselects my selection (WHY?)
(The FAQ claims I can "disable this by setting the copy-on-select preference to false, but I wasn't easily able to find a place for preferences. After some hunting, I found that I have to control click on the app from Chrome's "Apps" page to disable this.)
Anyways it's been hung at "Loading NaCl plugin..." for the last ten minutes. Either it takes a long time to load, or I don't have the NaCl plugin installed, and so it just decided to hang instead of tell me. I tried to install it by googling "NaCl", and found the link https://developers.google.com/native-client/. Clicking "Get Started" tells me to download an SDK and work through the "Getting Started Tutorials." All this for an SSH connection?
Anyways, it was overall a frustrating and confusing experience. I've now got four identical connection entries, none of which I can figure out how to delete, and none of which ever successfully connected to anything. Argh.
I'm thinking of writing some kind of p2p as a webapp that would be universal but right now it seems my best option is webRTC that, if I understand what I've read correctly, will require a complete handling of the streams on a server...
EDIT:
Or how does NaCl differ from FirefoxOS goals and why?
I played with this API for a few days and here are my conclusions:
1. the socket.listen can not handle much concurrency. It's very easily DoS'd
2. javascript String and ArrayBuffer is PITA to mess with. I tried to write a partially working HTTP/1.1 server, all the encodings and string parsing made me give up.
For me the link redirects to the front page of the Chrome Web Store, so I guess that's what's happening to you, too. But by entering "secure shell" in the search box I can view the screenshots, description and reviews of the app being discussed. Firefox 18 on Linux.
Often I want to repeatedly swap between a terminal and a web browser tab - for example, when developing a web application.
Having them in the same tabbed window might make the workflow, and division of my windows, more natural.
Another example - I use mutt for email in a terminal. So if I'm writing an email about a web page, I might prefer it to be in the same window (different tab) as the web page.
If it's easier to have your terminal in a browser tab than for it to be a separate application, that is a major failing on the part of your window manager (or at least your understanding of it).
how different is the actual security here from running chrome on a machine with the same private keys? is the sandboxing any less secure protecting extensions from each other as from the native os underneath chrome?
Seems like it doesn't override the browser's basic keyboard shortcuts, some of which are heavily used in a terminal (ctrl+w for instance). I'd probably give it a run in place of putty if it werent for this.
I don't know if this is the case for this particular extension. However, for most Chrome extensions, they can only use those shortcuts if they are opened in a separate window. You can select this option by right clicking on the app in the new tab page. I know that Chrome Remote Desktop can only use Ctrl-W in a separate window, but it works fine once it is in a separate window.
The browser is for documents that have ... many supporting files, a dynamic scripting language, access to native OS features, access to the GPU, ability to blit bitmapdata at highspeed, and more. "Documents" doesn't cover it ... I think its fair to say that these days the browser is for software.
I usually have multiple PuTTY windows open to a couple different servers. I wish it was easier to have multiple SSH sessions going with this extension.
I realize this is convenient for people running Chrome on OS X but...
The way I surf is simple: Chrome is installed from the .tgz and certainly not from the rpm or deb files (simply put: I don't need to be root to install Chrome and Chrome is confined to a single user account).
The account I use for surfing is separated from the account from which I use SSH to access SSH servers.
Should someone "root" Chrome while I surf the Web, he'd still need to find what is called a "local root exploit" to access what's in the other user accounts (for example, but not limited to, SSH keys).
I think there's no way that, for me, moving SSH inside the browser would provide me more security than having Chrome not doing SSH and being in a separate (throwaway) user account. It seems to be, once again, trading conveniency in the name of security. I don't doubt it fits Google's plan to make Chrome the OS that said and so they'll of course tell you: "Nothing to see here, move along".
Another concerning thing, depending on how it's done, it's that the potential to mount a "mocking bird" attack may be strong on this one. Mocking birds attack tend to not work well when you use MagicSysRQ to emit a keypress bypassing X, sending you to a text console, and doing your SSH magic.
I realize security is a pain, but it would be great if people could still criticize quite critical security issues on HN without having everyone downplaying the ones criticizing as "redditers" (is that an insult?), contrarians, etc.
I love HN. I love entrepreneurship. But I do love Bruce Schneier too and I consider security to be something very important.
Yet here everytime an app that does "one master online password to store all your passwords" gets upvoted like mad just because it's a "startup" and just because it "runs on a smartphone".
I understand that some of you may not like the "tone" of people using sarcasm to make a point but... They're still making a point and, very often, it's a valid point.
So it would be great if people could come up with better arguments than simply name-calling the ones pointing out the security implications of apps / plugins / etc.
I don't see how installing from an archive is safer than using a package, can you develop ?
From my understanding, Chrome is obviously not chrooted, so a local root exploit will be required in either case to access to the other accounts (since it will run with your current privileges).
And actually it seems easier to corrupt a chrome extracted in the home directory, since an intruder would not require root credentials to inject some code into your chrome (and replacing every bank front page with fishing pages, for example).
RPMs / dpkgs require root to install to the machine-global database. Both package formats have mechanisms called "triggers" which allow the package to run arbitrary shell script at install or uninstall time. Since install/uninstall are run as root, this means arbitrary root code execution on install.
Vs: a non-root user extracting a tgz and then running some file, root is never involved.
I'm not in agreement with OP about this being a concern worth his or her mitigation strategy, but the logic is sound.
The ability to take my critical secret information into a huge, buggy, extensible, unaudited, complex and constantly changing browser environment! Who could resist?
This will also inspire innovators world-wide. Look at it this way: we can now find novel ways to steal passwords, secret keys, log sessions, access servers, sneak in trojans.
Count me in.