Skype Linux Reads Password and Firefox Profile 335
mrcgran writes "Users of Skype for Linux have just found out that it reads the files /etc/passwd, firefox profile, plugins, addons, etc, and many other unnecessary files in /etc. This fact was originally discovered by using AppArmor, but others have confirmed this fact using strace on versions 1.4.0.94 and 1.4.0.99. What is going on? This probably shows how important it is to use AppArmor in any closed-source application in Linux to restrict any undue access to your files."
Shadow passwords FTW (Score:5, Insightful)
Re:Shadow passwords FTW (Score:5, Informative)
Corollary: dont use passwords vulnerable to dictionary attacks...
Re: (Score:3, Insightful)
ls has a valid reason to read these -- you want to see uids/gids as user names, not numeric values
I don't use Skype, and don't have my own strace, so I don't have context. I'd be interested to see the whole strace. Perhaps it's checking $HOME, perhaps it's as this guy [slashdot.org] points out. Either way, /etc/passwd is world-readable. The stupid title of "Skype reads password[s]..." is nonsensical at best.
As for the Firefox jazz, did they allow the default install of the Skype Firefox plugin? If so, why wouldn't it poke around in ~/.mozilla?
There's lots of information we don't have, and sensationalist crap ensues.
Re: (Score:3, Interesting)
Re:Shadow passwords FTW (Score:4, Insightful)
Re:Shadow passwords FTW (Score:5, Funny)
Re:your a queer (Score:5, Informative)
Debian uses shadow passwords. It's one of the questions in the installer.
Re:your a queer (Score:5, Informative)
First: NetBSD isn't a Linux distro.
Second: Debian uses shadow passwords.
Third: There's nothing wrong with reading /etc/passwd. POSIX even has an API for accessing it in user code. See the man pages for getpwuid, getpwnam, getpwent, setpwent and endpwent. For example, everytime you do "ls -l", it uses information from /etc/passwd.
In any case, there's really no excuse for not using shadow passwords.
Re:your a queer (Score:4, Informative)
Actually, there is, but for the entirely opposite reason. If you read passwd you'll miss any network based users, such as users authorized over LDAP, kerberos, or others.
getpwent and company, on the other hand, will get you those. As would getent or similar command line utility.
Re:your a queer (Score:4, Insightful)
Re:your a queer (Score:5, Insightful)
Re:your a queer (Score:4, Interesting)
Is there? Is there not? How should I know?
In an open source project, one could take the source and if it's FUD, debunk it immediately. Maybe there is a legit reason to read the passwd, maybe there is not. Do I know? No. Can I find out? No. It's closed source. I just know that it does. But what does it do with my passwords? Nobody knows but Skype's makers.
That's the core problem with closed source. I cannot trust it. Maybe it has a good reason to access the passwd file. But do you expect the best or worst? As a security expert, I expect the worst by default until proven wrong. Everything else is playing russian roulette with your system security. You can't just trust a program intrinsically until proven wrong, because when you're proven wrong, it usually is too late.
Re:your a queer (Score:4, Informative)
leen@debian64:~$ cat
4.0
leen@debian64:~$ ls -lA
-rw-r----- 1 root shadow 1171 2007-08-17 01:41
Re:But...More Secure? At least smarter! (Score:2)
You are an idiot; the argument has always been that because more people can see the source code there is a higher chance that bugs and exploits will be caught (which I think we can all agree happens effectively in the Open Source community) - not that open source stops all of these attack vectors.
Go back to spreading your FUD to the twelve
Re:But...More Secure? (Score:5, Funny)
That, sir, is a very good point. In fact it's such a good point, it makes me wonder why no one has ever suggested such a thing before, here on Slashdot.
Fortunately, there is a simple fix, readily suggested by the exemplary record set by The Microsoft Corporation. All we need to do is change the file "/etc/passwd" to be "/etc/.passwd". That way, the file will no longer show up on directory listings. And, since no one on earth is clever enough to think of running "ls -a", that means that no one will know where the password file is, so no one will be able to break in. Security Through Obscurity FTW!
Furthermore, if we apply this policy rigorously throughout the whole of the Linux operating system, I'm sure we can make Linux' security record every bit a good as Windows in no time at all.
Re: (Score:3, Insightful)
Oh, wait, it isn't, they aren't, and they are.
Wait, who said no one is writing exploits for Linux? People write exploits for everything. No software is 100% secure, and anyone who claims the opposite is a fool.
In fact, with all that open source, isn't it easier to see what is going on so I can write a better exploit?
Open code allows anyone to do security audits to patch vulnerabilities before they can be exploited. P
Re: (Score:3, Informative)
Except that /etc/shadow is only readable by root. A userland application can't access it.
Why.. (Score:5, Insightful)
Re:Why.. (Score:5, Insightful)
When I use Open Source apps, I do so knowing that there are many developers and hobbyists that have looked over the code, so I know that there aren't any glaring security flaws.
Imagine this had been an Open Source product for a minute... instead of an article just saying that it read
Re:Why.. (Score:5, Interesting)
Of course it would be easier to see the hows and whys in an open source application, but once you know, you know, and that's really at the core of the matter.
Re: (Score:3, Interesting)
BTW, it makes me wonder what we don't know about Skype for Windows where you do not have as many tools for monitoring file-access and stuff.
Re:Why.. (Score:5, Interesting)
Interesting you should say that - did you read the linked thread on the Skype forum? Here's a later post (emphasis added):
Pidgin nee Gaim is GPL. A quick search on one of its mailing lists shows no useful hits forRe:Why.. (Score:5, Informative)
Just checking your own identity in unix requires a call to getpwnam, getpwent or their equivalent, which means that a function call in glibc has to read the password file. Practically every unix program does that... It reads in the whole file in memory and looks for you, unless you're using the db source, yp, nis+ or an external module: nss_ldap, nss_mysql, nss_pgsql. It's doing that to find YOU out... That's normal, system-wide behaviour, and not sinister at all(that's also why there's a nscd daemon to cache those results, to prevent your machine from grinding to a halt if you have 200k+ entries in that file.
Now unless the legacy api gets redesigned to NOT do a line by line scan, anyone using strace/ltrace/dtrace/tusc needs to filter out these internal "housekeeping" calls, which are perfectly normal, needing to find out if _you_ can open up your own log file...
The
Re:Why.. (Score:5, Informative)
This is why a shadow password file was invented in the first place.
Re:Why.. (Score:5, Informative)
Flawed logic (Score:5, Interesting)
Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone. The people who read the code have to be honest for this to work.
Third you assume that anyone other than the developer even bothers to look at the code. Not always a valid assumption, just because the code if you there doesn't mean anyone gives a shit. Maybe it is too complicated, maybe they just don't care, regardless the code being open is no guarantee that someone looked.
Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries. That the checksums differed wouldn't be of any note, since it could just be that different compile options were used, or even a different compiler (for example using ICC since it generates more efficient binary code). As such no source audit would ever turn up the problems.
Finally, even if you compile your own, you assume that nothing else is in on it. I'll refer you to the classic Ken Thompson story http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]. Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.
Really, what it comes down to is open source may give you a warm, fuzzy feeling but it isn't actually proof everything is on the level. Really, you have to test what the software actually does when it is run. You can't say "Well the source is open so it can't do anything evil," because you just don't know that. It's far more useful to analyze how the program acts on a system, than to look over the code.
After all, if looking at the code revealed everything, OSS would never have any bugs. You'd look at the code, see all the bugs, they'd all get fixed. Yet it does, nasty ones. My favourite is the BIND flaw discovered back around 2000 that was in essentially every version of BIND ever. Despite the fact that many people had looked at the code, nobody had ever noticed this. There was no ill intent, no conspiracy, it just wasn't something people saw.
As such the same could be done for something evil. Hide it well enough in the code, and nobody will notice it.
Re:Flawed logic (Score:5, Insightful)
This sort of "evil" is very transparent. You can code a hidden buffer overflow/exploit/backdoor in such a way that it's not obvious (= instead of == for example, caught in the Linux kernel once). But how do you hide an access to say, /proc/interrupts? You need to spell out the filename, and there's got to be an open or fopen for it somewhere. Any attempt to encode the filename is going to be weird and suspicious. Plus, file parsing would be quite a bit than a single line of code, so it's hard not to notice something is being read, stored, etc.
Uh huh. Such a thing would be an outright admission of evildoing. Depending on what is being done it might be enough for a lawsuit, and definitely enough for mass publication all over the web to ruin the developer's name. Slashdot had a story on some Mac developer who claimed there was an anti-piracy check that'd delete the user's documents folder. Just the claim (which the developer says wasn't real and intended to scare people off) resulted in such outrage he's probably unemployable for years now.
No, anybody with any brains would deny any wrongdoing and claim a hacked server, or pretend that no mail is arriving at all.
But 99% of Linux software is delivered by the distribution, with the package maintainer often being completely unrelated to the developer. While it's not impossible for something weird to be going on, those distribution maintainers do things like patching the source and dealing with its bugs. You can bet that eg, the Debian maintainer of Firefox looked at the source.
That's a tricky one, but you can use a different compiler. Compile gcc with icc for instance. For OSS I think this approach is unlikely due to the frequence with which somebody decides "let's rewrite this part". It's easy to make a compiler that hiddenly changes some well known part of the source, but it's much harder to deal with a complete reorganization of it. To keep it up would need updates
Re:Flawed logic (Score:4, Insightful)
Ok, if you're so clever, provide an example of code that reads a file without making it easy to tell what it's doing, while avoiding looking suspicious.
Don't change subject. The original post was about a developer releasing "evil" code, then turning somebody who finds it to their side. Now you're talking about people submitting patches with somethind hidden in them. Completely different scenarios.
Most OSS projects don't blindly accept patches. Certainly not the ones in widespread usage. You might sneak a buffer overflow in, but to sneak an outright trojan would be seriously challenging. The submitter's anonymity isn't a problem if source is being examined.
Stupidity exist everywhere of course, can't be eliminated 100%. But while for Linux users perhaps 1% of all software comes from unverified sources, for Windows users it's 99%. Just why exactly do you trust that say, Trillian isn't doing anything strange? Nobody but its developers really knows what's there.
Not all of it, but there are many distributions, which each look at different parts of the source. To sneak something in you'd need to be really sure that part won't get looked at by anybody, and that's hard. Developers watch mailing lists, talk to people who work on the project and use 'svn diff'.
First you build gcc with icc. This is icc_gcc.
Then you build another copy of gcc with gcc. This is gcc_gcc.
Now you have two gccs with different code generated by different compilers.
So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy.
You can easily this with more compilers and multiple versions.
Well, I still think it can't be defined that the OSS approach is superior. It's not impossible to sneak something in. But in doing so you must take a very high risk of being found out, and if somebody tracks that back to you, well, chances are you're going to have to look for a new carreer. People with a known record of coding nasty things aren't very liked in the software world.
Re: (Score:3, Insightful)
Right. And that bit of code looks obviously harmless. You'd obviously scroll right by it if you saw it in some package's source, because there's
Underhanded C contest (Score:3, Informative)
Re:Flawed logic (Score:4, Interesting)
The more obfuscated it is, the more likely it is that the open source community would just rewrite that chunk of code for being too difficult to understand.
The challenge is not only to make it impossible to see what the code is doing, but to make it possible to think you know what the code is doing, and still miss what it's really doing. And at the end of the day, it has to spell out /etc/passwd in the code somewhere, or it has to have code that generates it, and it would take a LOT of work to write code which generates '/etc/passwd' while also never spelling it and looks innocent.
(Ditto for any other way you'd do this. There are standard library functions to access passwd, and those would be just as hard to hide.)
You only need one whistleblower developer to end that charade. And that one whistleblower would bring in hundreds or thousands of developers who'd never bothered to look at the code, who would read it and say "Yep. Looks evil."
Compare that to proprietary software -- it takes someone actively trying to reverse-engineer the software in some way; here, running it in a restricted environment. Even once you have someone doing that, it can be a lot less trivial than "just look at the source" for someone else to verify it.
Well, this is Skype we're talking about. It's popular enough that someone would have looked.
Also, consider the person making such "evil" software -- would they really be ballsy enough to assume no one would read the source? True, there could be some open projects with "evil" code in them that nobody's bothered to read, but anyone doing that is taking the chance that someone, somewhere, would read it and discover what they're doing.
And then there's the question of what happens when they discover it. Like right now, no one has a clue why Skype would be reading passwd. We assume it's evil, but we don't really know. Were it open source, we could just go read the code, and instantly see if there's a legitimate reason. If there wasn't, we could patch the "evil" bits out and keep using Skype as if nothing happened.
As the sibling post says, in general, most distros compile from source. So if you trust Ubuntu, say, you don't have to trust a hypothetically open source Skype in this respect -- the Ubuntu people would have compiled it from source themselves, and cryptographically signed the binaries.
That kind of rules out it being Skype's fault, then, for
Re: (Score:2)
First of all, it is rare that only one person reads the source for any commercial software product. Code reviews are standard in most organizations, and even if not, there are many developers at work maintaining that code.
Second, with open source apps, you really don't know that. It is perfectly possible for someone to submit a bad patch and no one bothers to really look at it in depth (at least not as in depth as you would need to catch a well disguised security breach). A lot of people use software
Well... (Score:2)
And not everyone will use a tool to check what their closed source application is actually doing either. When using popular open source software there's a good chance that someone has already scanned the entire source and therefore a good chance that mischief would have been uncovered.
With closed source the chance that someone will uncover mischief, which they can only
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
For example, I work on the Second Life source, and I and other people read quite big chunks of it. You can bet that the moment somebody noticed something fishy there'd be blog entries about it all over the web, and dozens of people looking at that and other parts of the source. And it'd have happened much earlier than if it was found by chance by some admin stracing or checking the logs.
In fact pret
Re:Why.. (Score:5, Informative)
This is somewhat silly anyway. The Firefox plugins, OK, I don't know why they'd read that, maybe they're checking for a Skype plugin, but who cares? As for /etc/passwd, it's not /etc/shadow. Not only that, but they don't even have to write code that reads /etc/passwd. Try changing the "passwd: compat" line in /etc/nsswitch.conf to "passwd: nis" or something like that, chances are your read of /etc/passwd will go away. It's probably just doing something like getting your real name. Calm down and get some real evidence of wrongdoing like a packet capture of private information going out over the wire before you cry wolf.
Re: (Score:3, Informative)
Re: (Score:2)
It's probably better to simply getenv("HOME") to find $HOME. It's already in your process; why bother asking a file (or possibly a remote database)?
But yes, there are other mundane and valid reasons for reading /etc/passwd.
Re: (Score:2)
Because it's not at all possible if they're being sneaky enough to read files they really shouldn't be reading in the first place, they wouldn't ever dare encrypt it before they sent it back to a central server. Oh no, that'd be faaar too clever.
Possible rational reasons for stupidity and violation of trust don't cut it when it comes to privacy. "Oh, the governm
Re: (Score:2)
This is more like, "Oh, the government can get look op your name from your social security number. Don't worry, that's one of the reasons the social security number exists. Well, no, I can't say that the government hasn't used that information to also find my address and dispatch a highly trained team of assassins to brutally slay me, my family, everyone with a drop of my blood in their veins, and everyone I've ever loved or has loved me."
Re:Why.. small reality check! (Score:2)
However, the poin
Re: (Score:2)
Well, the private information going out over the wire is kind of encrypted...
But think about the big picture. Aren't the guys making Skype the same guys that put the malware in Kazaa? It's the opposite of crying wolf -- when you say "I'm innocent!" for long enough when it's not true, no one will believe you're innocent even when you are.
People wonder why we don't tru
Re: (Score:2)
So decrypt it. What? You don't have the keys? Well, that's what you get for using closed source. I don't use Skype, but if I did I wouldn't worry about it. If you're that paranoid, maybe you should stick with GPL-3 software.
Re: (Score:2)
Additionally (and perhaps more importantly) -- in the case of OSS, the individual programmer is putting their public reputation on the line. In the case of proprietary software, the credit and blame generally goes to a faceless corporation.
Re: (Score:2)
Re:Why.. (Score:5, Informative)
"/etc/passwd" is a misnomor (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
They work by reading the password file sequentially and then returning the corresponding data structure.
You could try obscufating this information under some kernel or system method (eg. windows registry) but that would just make it easier for someone to hide a root kit.
Re: (Score:2)
Re: (Score:2)
/etc/password (Score:5, Insightful)
What's it doing? Well, what libraries is it linked with? Perhaps it's converting your UID into a name among other things.
Re: (Score:2, Insightful)
The only thing that stands out is when it checks the Mozilla profile, but I'll bet that it's doing that to make sure that the "skype:" URL handler is enabled and adding it if it isn't.
In other words, this is a complete non-story.
Re: (Score:3, Insightful)
Re: (Score:2)
Re:/etc/password (Score:4, Informative)
I am not suprised (Score:5, Interesting)
What a load of FUD (Score:5, Insightful)
Example:
strace on ls -laF immediately gives
open("/etc/passwd", O_RDONLY) = 4
Followed by quite a few reads out of it. So by the logic of the poster ls -laF is a horrible application doing horrible things to your system.
Unless you have read the source or single-stepped trhough the app with a debugger, examined the data and found that it does something nefarious like sending skype the whole of your
Re:What a load of FUD (Score:4, Interesting)
Re: (Score:3, Insightful)
Now what exactly does skype need to know my or anybody else's account name for? I've got no clue, but I'd be very interested to find out.
Re:What a load of FUD (Score:5, Insightful)
Um, because it wanted to refer to you as using real name, which is the entire damn point of having the field in /etc/passwd? Or even your username?
Without looking in /etc/passwd all it would know is your UID.
Or perhaps it's not even the thing doing it, perhaps it's using a shell script to see if the skype: handler is registered in Skype, and that script does 'ls -l' to check file sizes.
What I'd be interested in figuring out is exactly the fuck confidential information people think is hanging out in /etc/password? We all know that there are actually no passwords in that file, right?
And everyone know that programs access it all the time, right? Which is why it's deliberately world-readable?
Seriously, this entire article was made by someone who knows how to use strace but hasn't bothered running it on other programs, and has no idea what /etc/passwd is for.
Re: (Score:2, Troll)
Why would it need to? Skype has its own accounts, if it wants to refer to me by name it can use whatever I entered in my account info.
That'd be a stupid way of doing it, and I think Ap
Re: (Score:2)
So that it can fill in sensible defaults in the 'register account' dialog. Having sensible defaults is good usability.
Re: (Score:2)
But it doesn't do that. I just made a new user account, ran skype, and starting creating a new skype account. Skype leaves the full name field blank.
Re: (Score:2)
Re: (Score:2)
Re:What a load of FUD (Score:4, Funny)
Try ltrace, which is similar to strace but lists library calls [man section 3] instead of system calls [section 2]. Running your same example with ltrace, one will see:
getpwuid(1000, 0xbfaa1073, 0xbfaa0d08, 1000, 0x805c088) = 0xb7f8c9b8
where 1000 is my uid and the rest of the params are pointers to memory locations.
So yes, it's possible to distinguish, just not using strace. Proper tool for the job and all that.
Of course all this would be moot if we had access to the source, which is the underlying issue being debated here.
Re: (Score:2)
Lots of output, but no getpw or open in it, and before starting skype says "Binary file corrupted. Please reinstall skype". So can't get very far with ltrace.
Either ltrace screws something up, or skype intentionally makes it not work.
Re: (Score:2)
Re: (Score:2)
Re:What a load of FUD (Score:5, Insightful)
This article looks like guerilla advertising for SuSE/AppArmor, a Novell product.
It's a fine example of why people who don't understand the C Library and Linux/BSD/POSIX SDK and how to disassemble the application should not be relying much on AppArmor to tell them what's good and evil.
The trouble is the library does it, not the application, and a few reads of some files can't tell you the application's intent, or show whether the information is being encrypted and sent out to the software maker or not.
This reminds me of folks that spend day and night reading firewall logs and mailing out hundreds of complaints to networks if a host so much as pinged them or tried to make a port 25 connection.
Sure, they could be a spammer or hacker, but just because you set alarms -- a connection attempt doesn't say that anything evil is being attempted. I'd be far more concerned if someone said Skype read something from /etc/shadow, then the
very next thing it did was to make a port 80 connection to Skype's servers and send a
HTTP POST submission with lots of binary jibberish.
Any program that needs to do so much as lookup the user's shell, home directory, username attribute, or real name needs to examine /etc/passwd.
Most non-trivial applications need the user's home directory to load their user preference files. Some internal shell script of Skype may even need the user and group names, in order to establish appropriate file permissions.
Sure, there are environment variables that popular distributions' shells use; however for an application like Skype to be portable, it may not be able to rely on a particular environment variable like 'HOME' being set -- it may be safest just to getpwuid() the user and lookup their home directory that way.
In any case, the SOFTWARE DEVELOPER would have the option of using getpwuid() instead of getenv("HOME"). It's the developers' choice.
Applications can accomplish things in fairly boneheaded ways sometimes, but that doesn't indicate anything malicious or evil.
hard to avoid (Score:2, Informative)
In any case, you don't need AppArmor to find what files something opens, just use strace.
shadows (Score:2)
Why /etc/passwd access is benign (Score:2, Insightful)
Second: Any modern Linux system will use a shadow password file, its been years since I've seen a system use a regular password file.
Er, maybe it's getpwent or getpwnam? (Score:2)
Paranoia without understanding how UNIX works is inappropriate.
Re: (Score:2, Interesting)
reading /etc/passwd is normal (Score:4, Informative)
It is via /etc/passwd that you convert a UID to a user name.
I've discovered even worse Linux privacy problems (Score:5, Funny)
1989 called... (Score:4, Interesting)
They want their critical Unix vulnerability back.
Darn - all I have to do is cat /etc/passwd from a regular account... let's see... gee, the sysadmin on this machine is a dumbass - what sort of root password is "x"?
OMG its on Mac OS as well - the root password here is '*' - well, at least they've used a non-alphabetic character.
What's that you say Mr Sock... /etc/passwd is a public file and no security-conscious distro has actually stored passwords in there since the encryption was cracked (at least for dictionary words) sometime in the 80s?
Wake me up if Skype actually emails a readable copy of /etc/passwd to the black hats - even then, it shouldn't be enough to compromise a system (although a list of usernames might be handy).
But what's going out? (Score:2)
The real question is ... (Score:2)
The list (Score:5, Informative)
This is a realtime app (Score:2)
Regarding
To me, the oddest part is the wholesale reading of mozilla and firefox profiles.
Re: (Score:2)
Why isn't it looking in /proc/cpuinfo then? /proc/interrupts doesn't contain any indication of how many interrupts can be serviced, nor the time it takes to service one, or the load caused by the interrupt, so it seems quite pointless performance-wise.
Best harmless use that comes to mind: Skype knows that device X and device Y cre
It's "ensuring contract compliance" (Score:2)
I really hope this turns out to be wrong (Score:2)
Please (Score:5, Informative)
Please, before you submit (or accept) an article about security to (or on) slashdot, make sure you understand rudimentary unix programming. There is no way any non-trivial unix program is going to NOT read /etc/passwd. /etc/passwd needs to be read for almost any trivial thing to be accomplished, such as finding out your home-directory so that .skype can be read, or for displaying ownership of files in a file-dialog.
Now, as to why skype needs to read firefox configuration files, I have no idea. I haven't used skype, so I don't know what it does. But most likely this is done, because some users asked for a certain "integration" feature, whether it's bookmarks or plugins, or whatever...
Not a big deal - /etc/passwd is local public info (Score:2)
I'd suggest that anyone with concern about skype on linux si
Firefox (Score:2)
Not an issue (Score:2)
Symmary: Nothing to see here, except some people tha
Skype is due to be replaced (Score:2, Informative)
http://forum.skype.com/index.php?showtopic=93068 [skype.com]
Since then I have found that there are already standards based open source replacements for Skype, mainly SIP and Ekiga. In contrast to Skype they got video conferencing and you can get a public telephone number for free.
Also I started to think about what would be needed for the german "Bundestrojaner" and compare it to Skype:
- it is installed on a majority of s
Skype Shows How Not to Trust (Score:2)
It shows how important it is to secure your system, whether Linux, Windows, or any other, against trusting any app too much with resources not created by, or explicitly granted to, the trusted app.
It also shows that it's too hard to trust closed source apps on any platform, even when closed source is the default status.
It also shows that AppArmor can protect you from u
It's the 1990 Prodigy scare all over again (Score:3, Interesting)
Incorrect (Score:4, Informative)
It is true that the same people were the main creators of Kazaa and Skype. However, those creators had nothing to do with the introduction of spyware into Kazaa. They are not to blame for what others did. The introduction of the spyware was included in Kazaa first after the program was sold from the creators.
And you are a troll (Score:2)
You cannot deny the user to give away his own password in any system.
Re: (Score:2)
Re: (Score:2)
SIP sucks (Score:2)
I believe there's something else you can use instead, some Asterisk-specific but somewhat widely-supported protocol, a bit simpler, only requires one port. There's also Jabber/Gtalk -- I know Kopete supports that now, among other clients. I don't know exactly how the voice works, but it is nice to be able to have one or more central servers to connect to