# A virus for Linux?

## The_Great_Sephiroth

Been a while since I read anything about Linux viruses, but I saw this today amd thought I would share it. I have never, to my knowledge, had a virus bother me in Linux. This includes Redhat 7 (from 2001), Debian 2 through 7, Gentoo, amd PCLinuxOS. How would this thing even get onto a system and execute itself?

Nasty new Linux virus

----------

## proteusx

How does it get in your machine?

The article is probably native advertising for DrWeb.

----------

## CooSee

 *proteusx wrote:*   

> How does it get in your machine?
> 
> The article is probably native advertising for DrWeb.

 

agree - don't believe the hype.

----------

## pjp

Sounds nasty, but yeah, the article is pretty sketchy.

Based on other coin mining references, it probably arrives via javascript.

----------

## 1clue

There's plenty of malware for Linux. Viruses, not so much. This seems aimed at Windows users and possibly uneducated Linux users. Real malware articles are less cute in their wording and more correct on exactly what type of malware is involved.

----------

## Ant P.

“over 1000 lines of code” is meaningless buzzword-babble but does reveal that this isn't particularly competent malware, since it's not a binary payload.

Stripping the BS away, they're possibly referring to the cryptominer in the latest npm-js disaster which - surprise - would run just as well on Windows.

----------

## pjp

What's interesting are the claims about how it behaves on Linux outside of the mining.

----------

## mrbassie

https://www.zdnet.com/article/new-linux-crypto-miner-steals-your-root-password-and-disables-your-antivirus/

Look up the cve's.

Also

https://www.itwire.com/security/85406-linux-malware-of-no-use-unless-it-gains-access-through-ssh.html

----------

## bunder

 *mrbassie wrote:*   

> https://www.zdnet.com/article/new-linux-crypto-miner-steals-your-root-password-and-disables-your-antivirus/
> 
> Look up the cve's.
> 
> Also
> ...

 

yawn, ssh bots have been around for forever.  overhyped for mass hysteria.   :Rolling Eyes: 

also, what antivirus...  i've never used one on linux, except for amavis/clamav for email.

edit: honestly this looks no worse than mirai.

----------

## mrbassie

Yep. Proteusx called it, click bait ad for dr.web.

----------

## Jaglover

 *mrbassie wrote:*   

> Yep. Proteusx called it, click bait ad for dr.web.

 

+1

Every serious virus description contains information about the vulnerability which is exploited. This one is for people who think computer virus is like a flu virus that just comes and infects you.

----------

## The_Great_Sephiroth

I thought it was odd, but wanted to be sure. I've never had a problem with Linux outside of occasional portage issues which the members here can help with, and prior to that maybe some odd conflicts with drivers on Debian. I also don't install Java at all, but not sure about JS. I believe many sites still need it to function correctly.

----------

## Hu

The JavaScript infection is spreading, not retreating.  Ever more websites use it when they should not, and fail horribly when script is not executed.  Even worse, ever more sites are deliberately sourcing Javascript from third party servers, often without Subresource Integrity tags, making it ever more dangerous to allow scripts, and ever harder to block dangerous scripts without completely breaking the intended site.

Running Javascript is theoretically safe, if you trust your browser to implement the Javascript sandbox correctly, and you run a browser with all the latest workarounds for CPU vulnerabilities, and a kernel with all its latest workarounds for those vulnerabilities.

----------

## pjp

 *Hu wrote:*   

> Running Javascript is theoretically safe, if you trust your browser to implement the Javascript sandbox correctly, and you run a browser with all the latest workarounds for CPU vulnerabilities, and a kernel with all its latest workarounds for those vulnerabilities.

  On a related note, Google & Mozilla are apparently working on persistent access to local storage.

----------

## Muso

The real security issues with Linux are not viruses, but exploitable programs.   Dirty CoW (copy on write) is mostly an issue with older kernels.   Shell Shock has been more or less mitigated.   But there's always the dangers of XSS, SQLi, Sticky bits, and unpatched vulnerable applications.   Staying updated keeps you rather secure, as the package maintainers (in general) pay attention to the security alerts.

Zero days are another matter.

----------

## 1clue

 *Hu wrote:*   

> The JavaScript infection is spreading, not retreating.  Ever more websites use it when they should not, and fail horribly when script is not executed.  Even worse, ever more sites are deliberately sourcing Javascript from third party servers, often without Subresource Integrity tags, making it ever more dangerous to allow scripts, and ever harder to block dangerous scripts without completely breaking the intended site.
> 
> Running Javascript is theoretically safe, if you trust your browser to implement the Javascript sandbox correctly, and you run a browser with all the latest workarounds for CPU vulnerabilities, and a kernel with all its latest workarounds for those vulnerabilities.

 

Given that html5 has javascript in the spec, don't plan on this issue going away anytime soon.

There are 2 equally valid sides to the issue, and the "right" answer depends somewhat on who you ask, but in reality is a balance between having enough features to give a webapp a desktop feel, and having a web page be secure enough to keep your system and your data safe.

----------

## Yamakuzure

 *https://www.itwire.com/security/85406-linux-malware-of-no-use-unless-it-gains-access-through-ssh.html wrote:*   

> Asked about how the malware could gain access to systems, Vurasko responded, "In the first place it works like this: somebody searches for servers with [the] SSH port open; he is trying to brute [force] servers he found; if the brute force attack was successful, he connects to the compromised server using brute-forced credentials and starts the malware."

 So key-auth only and fail2ban. Case closed.   :Laughing: 

----------

## 1clue

 *Yamakuzure wrote:*   

>  *https://www.itwire.com/security/85406-linux-malware-of-no-use-unless-it-gains-access-through-ssh.html wrote:*   Asked about how the malware could gain access to systems, Vurasko responded, "In the first place it works like this: somebody searches for servers with [the] SSH port open; he is trying to brute [force] servers he found; if the brute force attack was successful, he connects to the compromised server using brute-forced credentials and starts the malware." So key-auth only and fail2ban. Case closed.  

 

That's ridiculous.

----------

## krinn

So it's no more than just a script kiddy that brute force ssh password?

And once it have the password, it install another crap to mine bitcoin or whatever.

People would get more money by selling the root password instead

Agree with mrbassie about click bait, using the term virus for something that doesn't replicate itself was made for that, from what i know, it's called a virus when it replicate itself (to spread), a trojan when it show itself as another "safe" program, a malware when its task is to bug user with publicity or whatever, a ransomware when its task is to query money from user.

And script kiddy is a dumb brute force task where no action or skill from its user is need (hence why the "kiddy" term, as even a kid could use it).

----------

## Hu

 *1clue wrote:*   

> Given that html5 has javascript in the spec, don't plan on this issue going away anytime soon.

 I fully recognize that the problem will get far worse before it gets any better.  Developers who do not deserve that title have gotten a taste of power and will not soon yield it.

 *1clue wrote:*   

> There are 2 equally valid sides to the issue, and the "right" answer depends somewhat on who you ask, but in reality is a balance between having enough features to give a webapp a desktop feel, and having a web page be secure enough to keep your system and your data safe.

 I am specifically looking at sites that can serve their purpose perfectly well with no script, but are deliberately written to be broken with NoScript.  For example, sites that use Javascript to implement their links to other internal pages, even though those pages have distinct URLs that could be bookmarked and loaded successfully; sites that use Javascript to drop open menus; sites that use Javascript to submit forms instead of using a dedicated submit element.  I grant that there are some sites, sometimes even useful ones, which cannot reasonably be implemented without use of Javascript.  I may not like some of them, but they are not the ones I consider to be an example of abuse.  The abuse is in those sites that would work as well, if not better, if rewritten without mandatory Javascript.

----------

## 1clue

@Hu,

I understand and I know there are many sites like you describe.

I build apps for enterprise financial use. We use webapps, and we use JavaScript to give grids much of the spreadsheet feel, and context-sensitive menus and other things that make the users' lives easier. 

All our apps are used internally, inside a firewall. They link internally or to one of our other apps, or perhaps to some middleware or a third-party app being designed into their work flow.

Without the exact functionality being discussed on this thread with such angst, our apps would be required to be Windows-only, baked into the Microsoft paradigm. Instead we can have Windows, Mac, Linux, Android and iOS.

That's another thing: Mobile devices rely much more heavily on JavaScript than PCs do. There are entire apps written in essentially JavaScript. Not Java. There are other apps written in Java, but that's not what we're talking about here.

I'd like discussion to be aimed at securing JavaScript in web applications rather than simple JavaScript hate.

FWIW I think there are many online sites which would not be nearly so easy to use if there were no JavaScript. It could be argued that any site could be made without any client-side scripting, but the truth is they'd be much more difficult and cumbersome to use.

----------

## Hu

I don't hate Javascript, and your internal use sounds like a decent one (though I dislike things which override context menus).  I hate the design patterns that lead to a site which is completely unusable when the client does not implement and permit all the latest script toys.  I further despise the design pattern that reloading the page can meaningfully change its state, since I often get stuck performing reloads while trying to figure out the minimal set of things to unblock to work around the previous design anti-pattern.  In my opinion, the first step to securing Javascript is to mandate much of the currently optional security hygiene: require that cross-site <script> tags use SRI (by rejecting any that lack it); require TLS for active content (by refusing to fetch out-of-line scripts served over HTTP, and refusing to execute inline scripts served over HTTP); require sites to serve a Content Security Policy that describes the limitations on active content.  At a social level, discourage using a Content Security Policy that permits anything not required for correct operation.  (For example, if the site only sources Javascript from a.b.example.com, don't whitelist *.example.com.)  Wherever possible, deprecate using inline active content in any page that also includes any user-controlled text.  Such text can be handled safely, but is easy to handle unsafely, so except where a high quality framework is responsible for inserting the text with appropriate quoting, it's better just to avoid the problem entirely by saying either active content or user content, but not both.

Securing Javascript at the browser level is hard, in part because of the proliferation of outdated software that will be months, if not years, behind on getting improvements.  Mozilla has greatly exacerbated this problem with their WebExtensions stunt.  Look at how many people are deliberately using pre-Quantum Firefox (which is now unsupported, has known vulnerabilities, and definitely will not receive any further security improvements) because post-Quantum breaks all their extensions.

I recognize that some sites which use Javascript are more useful for it, and I have no problem with that.  However, I believe that if the default install of NoScript makes your site unusable and the site could reasonably be written in a way where NoScript does not make the site completely unusable, then the site is abusing Javascript.  Going to your example, I don't see how what you do could be reasonably done without Javascript (as you suggest, if the Javascript-free version worked at all, it would probably be much more cumbersome), so I don't consider that an abuse, even though it is probably totally broken under NoScript.  Sites that use Javascript for predictive searching, but which still work under NoScript at the expense of no prediction, are not an abuse, because they are still functional, even if they are somewhat cumbersome.  Sites which hide all their content in Javascript variables, then generate an essentially static page through dynamic DOM addition are an abuse.  Sites that use <a href="javascript:window.open(...)"> are an abuse.  (They should point the href to the document, then use a Javascript event handler to suppress the event and run the window.open if the user uses an unmodified left-click, so that the user can usefully use Open in New Tab or Copy Link Location.)

----------

## Maitreya

Recently bought eset for linux.

The reason not really protecting my own machine but maybe other windows/mac boxes on my network.

I was skeptic at first, so  I downloaded the trial. Decent installer. Correct placement. 

Overall I was surprised for a commercial product to behave so decently, so I bought it.

Neatly intercepts CARS downloads so I'm pleasantly surprised.

Is this in anyway a security enhancement? To my opinion not a very big one. Rather have proper design than hindsight fixing (what antivirus basically is)

----------

## 1clue

@Hu,

I'd have to think about those suggestions to work out how it would affect our app. Most of what you say wouldn't affect us because our apps generally only reference internally to the same web application, with possible configurations to reference some other web application. Certainly nothing the customer doesn't pay for.

The key issue I have is with your active content vs user content. If you mean that to be animations then we're OK, but if you mean it to be widgets like grid-cell-based context menus then we would be broken.

It occurs to me that the things you're talking about come down to a limited number of things.

Bling.

Money.

Bad code practices in general

Bling is just that. Animations or some sort of graphic art to make the page stand out.

It seems that most of the rest of what you're talking about are mechanisms by which sites make money. The idea that the app stays safe on one server and all the third-party banners are stored elsewhere. For us, the customer pays for an app which is used internally, so there are no ads because the only users are employees, and every bit of screen real estate is used for the task at hand.

The part where the entire site is generated inside a variable is just bad coding practices. It's not especially maintainable either.

All that said, in order for there to be true control of JavaScript one would need to ensure that the site designers are working ethically and carefully, and that both the site and the browser are using a "correct" implementation of JavaScript which works within the security framework. Without adding some sort of cryptographic signing of an app I'm not sure how you'd go about that. Even then, JavaScript is a dynamic language, which makes securing that type of code difficult.

----------

## pjp

 *1clue wrote:*   

> All that said, in order for there to be true control of JavaScript one would need to ensure that the site designers are working ethically and carefully, and that both the site and the browser are using a "correct" implementation of JavaScript which works within the security framework. Without adding some sort of cryptographic signing of an app I'm not sure how you'd go about that. Even then, JavaScript is a dynamic language, which makes securing that type of code difficult.

 

 *1clue wrote:*   

> I'd like discussion to be aimed at securing JavaScript in web applications rather than simple JavaScript hate.

  Given these comments, is it possible to secure JavaScript (or any dynamic language)?

----------

## 1clue

 *pjp wrote:*   

> ... Given these comments, is it possible to secure JavaScript (or any dynamic language)?

 

If it were easy something would have been proposed and likely implemented already.

A few years back, JavaScript worked differently across browser vendors, operating systems and even versions of a browser on a single OS. It took them more than a decade to get a handle on just that.

It took Java awhile to get traction too, and the consensus was to abandon Java in a web browser entirely even though the signed code concept worked pretty well. The truth is that Java is too heavy for a browser, and the ways that it needs to interact with the client means it's difficult to secure just by the requirements. Over the years Java has gained consistency and security by leaps and bounds, but still has a distance to go for some types of applications. Some of that work (e.g. signed applications and libraries) has trickled into bare-metal operating systems and applications, and may possibly work for a dynamic scripted language like JavaScript, but there are qualifications.

First, the same use cases that caused Java to be so difficult to secure in a browser will also make JavaScript (or any other scripted language) difficult to secure, and their importance to functionality will be the same too. Some of the problem is the nature of the requirements.

Second, the fact of JS being an interpreted script where it's possible to put code into a variable and execute it adds its own complications.

Third, while tests can exist to pass or fail certain functionality in a JS implementation, and they DO exist, the truth is that each vendor will do something extra to make their implementation better. So there will likely continue to be a core set of standard features but there will absolutely be significant differences between one implementation and the next. It's the nature of the beast. It's also how browsers and languages and whatever else improve over time, so it's both a good thing and a bad thing.  But the hard part of this is knowing how to secure those new features.

----------

## 1clue

I think it's indisputable that a universal client needs some sort of programmability for complex sites. I think it's also indisputable that many things could be done without programmability, without any loss of function or convenience.

I don't believe it's possible for a markup language like html to support enough functionality to satisfy the type of apps I build. It's not like what I do is so complicated, but what I do is significantly different from what the next guy, with a completely different type of app, is going to want.

----------

## jonathan183

The ability to use a simple browser such as Links in graphic mode is desirable, and for me preferred particularly for online banking activities. While I used to be able to do this with one of my banks I am no longer able to do so.

I'd trade convenience for security for most sites ... unfortunatley more and more sites seem to be moving away from the option of using a simple browser like links  :Sad: 

----------

## pjp

 *1clue wrote:*   

> If it were easy something would have been proposed and likely implemented already.

  Obviously :). Thanks for your detailed reply. I was mainly getting to the point of "hate." I think it is more about a lack of ability to secure an environment. Which as your comments point to, is not yet possible. The practice of relying on third party sites seems to be the worst offender. Next, for me, would be the ability for code to be injected into a site. And the third issue is with browsers themselves. Instead of being the most sandboxed and locked down piece of software, their creators seem intent on creating more holes (I only half-joking wonder if that is sponsored).

Unfortunately, all of the effort behind web apps seems horribly misplaced. I have yet to personally use a web based application I would call worth using. The internet ought to be more about data than presentation. It is so bad that I'd prefer plain text email, news groups and maybe gopher (never actually used the last one). I understand the economics of a single platform, but it really seems like a race to the bottom.

----------

## 1clue

pjp,

Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app. Or maybe have a certified development group do it, where the code is publicly reviewed and the developer is publicly rated for the quality and safety of their (open) code. This would have to go hand in hand with signatures on each piece of code/each ad.

Code injection can be dealt with, but at this point it's a small PITA for the developer, so it tends to not get done every single time. IMO this is something that can be addressed at the organizational level, with some sort of a unit test.

Browser security, that's a tough one. I suppose an uninvolved third party could rate all the browsers by a standard test harness and release the scores publicly? But each test would need to be wired into each version of the browser as changes happen, and some magical all-knowing test writer would need to be able to write tests for new features for that browser.

Webapps: They're the logical extension of CGI. Online banking, online shopping, surely something like Amazon or YouTube qualifies as worthy webapps. A video site could probably do without scripting if the HTML is consistent between browsers, but I submit that an online banking app without client-side code is probably not desirable. Webapps bring consistent security, better session management, better transactional integrity and a host of other things to the table that CGI always had trouble with, or that you had to struggle to keep straight as a developer.

I'm sure you know that. But my point is that if you accept the idea of functionality on a web site, then webapps are the best available tool.

I haven't seen any public webapps with the sort of information density that you see on a major accounting package. Some of the larger companies need to process millions of transactions per day, and some of the payments have thousands of line items. Maybe 80-95% of that can be handled automatically depending on the company, so there is still a relatively large group of humans who need to see each batch, each payment associated with it, and each line item associated with each check all at the same time so they can make sense of it. And it's not just one person working the data, it's dozens or hundreds, and they may not all be in the same country.

With different countries and branch offices having different requirements for hardware and network and whatever else, you can't rely on keeping every user on the same hardware, let alone the same updates. A webapp is the only feasible approach IMO.

----------

## pjp

 *1clue wrote:*   

> pjp,
> 
> Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app. Or maybe have a certified development group do it, where the code is publicly reviewed and the developer is publicly rated for the quality and safety of their (open) code. This would have to go hand in hand with signatures on each piece of code/each ad.
> 
> Code injection can be dealt with, but at this point it's a small PITA for the developer, so it tends to not get done every single time. IMO this is something that can be addressed at the organizational level, with some sort of a unit test.
> ...

  Does dealing with code injection in that way have a "name"? I'm curious to read more about it. But the main issue with all three of those scenarios (3rd party, injection, browsers), is that all of those solutions are not enforceable. Which effectively means no change from the status quo.

 *1clue wrote:*   

> Webapps: They're the logical extension of CGI. Online banking, online shopping, surely something like Amazon or YouTube qualifies as worthy webapps. A video site could probably do without scripting if the HTML is consistent between browsers, but I submit that an online banking app without client-side code is probably not desirable. Webapps bring consistent security, better session management, better transactional integrity and a host of other things to the table that CGI always had trouble with, or that you had to struggle to keep straight as a developer.
> 
> I'm sure you know that. But my point is that if you accept the idea of functionality on a web site, then webapps are the best available tool.
> 
> I haven't seen any public webapps with the sort of information density that you see on a major accounting package. Some of the larger companies need to process millions of transactions per day, and some of the payments have thousands of line items. Maybe 80-95% of that can be handled automatically depending on the company, so there is still a relatively large group of humans who need to see each batch, each payment associated with it, and each line item associated with each check all at the same time so they can make sense of it. And it's not just one person working the data, it's dozens or hundreds, and they may not all be in the same country.
> ...

  From a theoretical perspective, I agree that post-CGI web apps are "better." But not in practice. For Amazon, yes, because that's mostly the only option. For daily, "use it all day long" apps, absolutely not. They cause far more stress trying to get work done than they're worth (obviously business badger don't care).

I don't think either Amazon or Youtube are particularly good. They're usable in the sense that alternatives are non-existent or worse. To be fair to Amazon, I don't think the silver bullet has been found for shopping UIs. Selecting filters is fairly bad, particularly if it isn't in the short list of checkbox items. Then there's the issue of clicking those and applying to search terms already entered, or new searches negating selections, etc. A lot of that feels directly related to it being web based. And that says nothing about their Video service (although the Roku interface to Video was worse).

I no longer remember the original Youtube, but it seems like the main problem there is attempting to monetize it with autoplay, suggestions and other similar "improvements." I often find those approaches to interfere with basic use of the site (watching a video).

For denser apps, a good example (of how not to do it) is the VMWare client. One I'm glad I haven't seen if it exists yet is NetBackup. Their thick clients weren't great. But I can't for the life of me imagine how they could make a usable web version, particularly if they relied on the same designers. Other examples include the employee view of HR software. Just to manage time off and hours worked is a nightmare in the ones I've had to use. That my PII is stored in an internet accessible nightmare like that is horrifying. But there's nothing I can do about it. 

Online banking? Most likely never again in my lifetime. I used it briefly, but the client side seems to have too much inherent risk. I just hope I'm not completely screwed in the event of their being hacked.

----------

## krinn

 *pjp wrote:*   

> I just hope I'm not completely screwed in the event of their being hacked.

 

If your account hold those 650 millions, i'm up to test your account security ; for free!

 :Smile: 

----------

## krinn

 *1clue wrote:*   

> Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app.

 

You see many insecure javascript usage in all-in-one menu or similar tool, instead of adding the script itself within the website, a lot of devs are using the script directly from the original location.

With the "good" effect that when any bug is found and fix, the website need no update to get the fixes.

And the "bad" effect, if anyone hack the webiste holding the script: all websites that use it from the source are fucked up good.

Nobody would do an "ln -s http://kernel.og/libc.so.6 /lib64/libc.so.6" ; but that's what many websites do with javascript.

I think you have all seen this no? 

```
m = s.getElementsByTagName(o)[0]; a.async = 1; a.src = g; m.parentNode.insertBefore(a, m)

    })(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');
```

----------

## 1clue

 *pjp wrote:*   

> ... Does dealing with code injection in that way have a "name"? I'm curious to read more about it.
> 
> 

 

Not sure if there's a name for it, specifically. I would try to go about it the HTMLEncode way. It would likely be more difficult for code, but if you take all user input and transform it so that it cannot be JS, then that would at least reduce the attack surface right? I haven't seen anyone actually do this, but it seems to be a workable approach.

 *Quote:*   

> 
> 
> But the main issue with all three of those scenarios (3rd party, injection, browsers), is that all of those solutions are not enforceable. Which effectively means no change from the status quo.
> 
> 

 

Absolutely correct. The same way that code signing is entirely optional, but works anyway. Or the little lock on the browser next to the URL box, saying that the site is in https and that the certificate is trusted. In my mind, the tasks are listed in order from easiest to hardest.

The primary site (the one you went to) certifies that all content is written by 'trusted' sources who will put their name on it.

The authors and site certify that all editable content is injection-proof by all known techniques.

The browsers use only certified script engines and prevent known exploits.

Let me reiterate that the last item I have no idea how to go about, and that item number 2 is my personal ruminations on how to prevent injection by making everything "not script".

 *Quote:*   

> From a theoretical perspective, I agree that post-CGI web apps are "better." But not in practice. For Amazon, yes, because that's mostly the only option. For daily, "use it all day long" apps, absolutely not. They cause far more stress trying to get work done than they're worth (obviously business badger don't care).
> 
> 

 

You can't just push a button and everything is better. You have to start somewhere, try an idea and see if it makes an improvement. Then go on to something else.

 *Quote:*   

> 
> 
> I don't think either Amazon or Youtube are particularly good. They're usable in the sense that alternatives are non-existent or worse. To be fair to Amazon, I don't think the silver bullet has been found for shopping UIs. Selecting filters is fairly bad, particularly if it isn't in the short list of checkbox items. Then there's the issue of clicking those and applying to search terms already entered, or new searches negating selections, etc. A lot of that feels directly related to it being web based. And that says nothing about their Video service (although the Roku interface to Video was worse).
> 
> 

 

Speaking from experience with some of the accounting packages that big businesses use, the people using the app likely have difficulty understanding and/or/xor/not or other logic, and complex logic would be even more difficult. We've tried that before, and the best we could get to was 'amount >= 1000.00' or 'dueDate < yesterday'. The people who call you to collect a debt or who apply money in big organizations likely don't have a degree at all, and may not have a diploma.

 *Quote:*   

> 
> 
> I no longer remember the original Youtube, but it seems like the main problem there is attempting to monetize it with autoplay, suggestions and other similar "improvements." I often find those approaches to interfere with basic use of the site (watching a video).
> 
> 

 

I think you're right.

 *Quote:*   

> 
> 
> For denser apps, a good example (of how not to do it) is the VMWare client. One I'm glad I haven't seen if it exists yet is NetBackup. Their thick clients weren't great. But I can't for the life of me imagine how they could make a usable web version, particularly if they relied on the same designers. Other examples include the employee view of HR software. Just to manage time off and hours worked is a nightmare in the ones I've had to use. That my PII is stored in an internet accessible nightmare like that is horrifying. But there's nothing I can do about it. 
> 
> 

 

VMware client could largely be a webapp, but the virtual console is definitely not.

 *Quote:*   

> 
> 
> Online banking? Most likely never again in my lifetime. I used it briefly, but the client side seems to have too much inherent risk. I just hope I'm not completely screwed in the event of their being hacked.

 

I'm not listing things I'd recommend people use, I'm listing things that people use. Lots of people use online banking.

----------

