I get annoyed when people are warned not to open some attachment. The real problem here is that in 2013 we're still using the flawed language of "opening attachments" -- as if running a native executable with full permissions is an action that belongs in the same category as viewing an image, reading a text file, or listening to music. Well, it doesn't. This is a problem that should have been solved at the level of O…
We only use that language because it's an order of magnitude easier to explain to novice computer users, and because as you stated, the problem still hasn't been fixed at the OS permissions / UI level. A modern OS lets us do that because lots of users are the sole user of their PC and do not understand the idea of permissions.
You’re infected—if you want to see your data again, pay us $300 in Bitcoins
251–260 of 295 posts
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#252Earlier quoted context omitted.
No, it's a required security feature that goes back decades in some operating systems. You need to be able to trust the code that runs on your system, and to do that you want to ensure only admin can install things. Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your p…
Yes, but UAC has the same weakness as Linux permissions - it only protects the OS and programs, not the user-data. Programs can screw with userland data all they like without user permission.
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#253Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#254Earlier quoted context omitted.
Yeah but ... in Linux at least you have to set +x yourself on the downloads. Which is basic sanity check. In windows there are too many ways to get elevated. And only one level of elevation.
not as if users care about watching out before setting +x. After all, there are tons of popular projects requesting users to run "curl http://.. . | sudo sh" and consider that a good idea, too.
I keep trying to teach my nephews that the default answer to that question is no... but of course, "yes" is the way you get anything done.
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#255Earlier quoted context omitted.
Unfortunately lots of stuff runs under there including, but not limited to: GitHub for Windows and dozens of apps it installs in there F.lux Anything installed with ClickOnce Chrome GMVault Xamarin's Android Support Markdownpad SkyDrive Join.me Assuming that everything in there is a virus is too much, I think.
I would think that .Net portable apps are likely also per user executables.. not to mention that there are usually at least one scripting environment even on windows cscript/jscript/vbscript/powershell for example, not to mention Java, Python, Ruby and/or node may be installed.
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#256Earlier quoted context omitted.
Doesn't Google Chrome run under %AppData% in a default (non-MSI) install? Yes, and from a security point of view it should be treated as hostile accordingly. There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism. It's long past time that Google were called out on this one. Not o…
Installing into %AppData% is, iirc, Microsoft's intended approach with ClickOnce installers (which Chrome uses). The difference is that ClickOnce installers have a far more restrictive permissions model than old MSIs. ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail misera…
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#257Earlier quoted context omitted.
> This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet. I'm not sure it does require a different model of access control. It just requires people to actually use the access control mechanisms that exist already. You should not access banking details or any other sensitive information in the same…
Your proposal is OK if accessing sensitive information is something you only do occasionally, but it's not very practical to switch users completely if you deal with sensitive information often, which many people do. On the other hand, if only explicitly authorised applications can create outbound Internet connections at all, and if applications like browsers and e-mail clients need explicit permission to read a gene…
$ sudo -u banking gnucash &
$ firefox &
Done. My banking files and my Firefox session are now separated.Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#258Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#259Earlier quoted context omitted.
On the contrary, after accumulating a certain amount of karma (500 points??) a user gains the ability to downvote comments (but not stories).
Also, downvoting is only available for a certain comment age. Once the comment is X hours old, you lose the ability to downvote, but can still upvote.
Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins
#260Earlier quoted context omitted.
That would cost $25,600 and require 256 valid Social Security or DUNS numbers.
Alternatively, it would require compromising the machines of 256 Apple developers. Guess what kind of person is likely to be capable of doing that.
How many Macs would you have to compromise before you randomly stumble upon a registered developer, let alone a registered Mac developer (of which there are far fewer than iOS developers)? And how much more secure is a developer's machine likely to be, and how much less is the user of such a machine likely to fall for common email attachment-based infection attempts?
At some point, the feasibility is low enough not to bother. That's what all security ultimately is, since nothing is foolproof.