1) All products have security holes. Often near identical ones, especially if it's an implementation detail no one ever considered before. (I remember, in the old days, OS after OS kept getting hit with TCP/IP attacks using various malformed packets.)
2) Microsoft takes way too long to fix their security holes.
He's talking about data-bound controls, where a text field or something is linked to a field in the DB. (And hence he can't run it through any sort of conversion on the way in.)
For example, my work laptop is encrypted with TrueCrypt.
TrueCrypt has, on startup, a clever feature where it can pretend be a disk error. Instead of a prompt, it can say 'Missing operating system' or something. And it doesn't respond at all unless you put in the correct password. I turned this on.
Any fool who looks at the hard drive can tell that the first sector or whatever are TrueCrypt, no matter what it says. But, at that point, after someone learns that, it's protected by actual working encryption.
Meanwhile, some loser who steals it who boots up the laptops he steals to see if there's anything obvious on them, is going to say 'Oh, it's broken, time to reformat'.
Yes, it's extremely unlikely that that person would actually be able to get in if, instead, they were presented with a 'Type in your password' prompt. But who knows, maybe I'm still being held at gunpoint or something and they want my password. It cannot but help.
Using security by obscurity is stupid. Using security with obscurity is not.
Use a well-known and tested encryption algorithm, but feel free not to label it, and to XOR the result with 'asgf12' so that someone has to figure that out and customize any cracking code to undo that first.
And, yes, this really only applies to non-mass produced systems. Anything that could have automated attack tools written for it is pointless to hide anything.
I know what you're saying, and you're entirely right, I was just trying to dumb it down for gold fools who have no damn idea how the money supply actually works, or why we have inflation, and that it's a feature, not a bug.
Most people really don't understand that the size of the economy and the amount of 'money' in the economy will become the same. Too much money vs. the economy, money becomes worth less to match. Too little, money becomes worth more to match.
I think that is simple enough and logical enough that I can beat it into people's head.
And then they'll realize that, fix the currency to a set value, and actually accomplish that, and you'd lock the economy in place also.
Although, as you point out, if we switch to gold, we'd just inflate gold instead, so that wouldn't actually happen. However, gold fools seem to be under the impression that gold currency somehow is not subject to inflation.
Oh, that's not the bad thing of switching to gold.
The money supply is supposed to match the economy. Economists don't agree on much, but that's one area where they they don't differ at all. You need roughly the same amount of money chasing each transaction.
When the economy grows and the money supply doesn't, you get deflation. Vis versa, you get inflation.
And the economy is always going to grow on average. Simply because there are more actual people each year who work and purchase stuff.
Hence, with an essentially fixed currency like gold, we'd suffer deflation, unless something went horribly wrong with the world population.
Now, deflation doesn't sound as bad as inflation, but that's because no one here remembers any instances of it, and it's very easy to avoid with a variable money supply. When the Fed prints slightly more money than need, causing inflation, they're doing it to avoid the worse problem of deflation.
Yes, all your savings go up in value faster, but the economy sorta breaks, as everyone constantly puts off actually spending any money. Not because they are scared they might need it later, like in a recession caused be shrinking economy, but because they know it will be worth more next week.
This will cause a real recession as hoarding continues. But it's not really a 'recession', it's more an 'economic contraction'. With deflation, the economy will match the money supply, like it or not.
The people starving to death because the economy couldn't expand to feed them probably won't like it.
You know what a fun question to ask gold standard supporters is? How much the money supply grew under the gold standard, from the start of this country until we switched from it?
Most of them will either assume it grew randomly, or not at all, and be totally ignorant of the fact it mostly matched the economy, and when it was oversupplied, we had inflation until the economy matched did, and when it was undersupplied the reverse happened.
We finally decided to stop letting some totally random variable, the gold supply, dictate the size of the economy!
The example I know of is GetRightToGo, which my company uses to hand people a stub program which will then download a larger installer to launch. It can do torrents if you set up a torrent.
It can even do torrents and capped straight download, at the same time, so you can say 'This person can download from us at 50k a second, and download at whatever speed via the torrents.'. (My company does not use the torrent feature, though, so I just know what the documentation says.)
It would be nice if MS would start doing this, and then show up in Congress talking about how ISPs need to stop overcommitting their network and randomly restricting services because of that.
You can almost send a CD for under $2 by hand, in the smallest increments possible.
The 6x8 'photo sleeve' mailers cost about $1.20 if purchased one at a time and the mailing of them costs about $0.80. With about $0.10 per CD and $0.02 for the CD sleeve.
If you're buying in bulk, you can get photo mailers for about $0.30, and the CD mailers cost about $0.25 in bulk. (And by 'bulk', I mean 'a hundred', they're even cheaper if you're sending out MS-levels of product.) And if you actually buy the smaller CD mailers, you can get mail them for cheaper, too. And the CD will be cheaper if made in bulk.
It would totally blow my mind if Microsoft or HP or whoever could not get 10,000 CDs to people's doors for under $10,000, with almost all the money going to the post office.
Netflix, as has been pointed out, has a plan that charges essentially $5 a month that has four DVD mailings built in, so $1.25 a shipment, including, presumably, some actual profit for Netflix. (Also, not everyone uses all exchanges every month.) They don't have to burn new DVD, but, OTOH, they don't get to take advantage of the post office's reduced rates for pre-sorted mail either.
As the license cost probably already includes the price of a disk you didn't get, it seems a sorta stupid quibble.
But, more importantly, software distribution over torrent has always made more sense than straight downloading. Before anyone asserts that 'torrents are too complicated', I am, in fact, talking about a download program that does torrenting internally, not handing people a.torrent file.
Erm, so MS would instead give out a stub program that people download in ten second and then launches, which then downloads, in the background, the ISO, and when it's downloaded burns it to a CD.
Of course, it should first check to make sure there's a CD-R in the system, and possibly even make people insert a blank CD to prove they have one. (So some fool doesn't try to use an AOL CD.)
Of course, for experts, they could have a torrent with just the ISO. (Or even use a torrent system in their downloader, and just let other people access it directly.)
Try reading my post again. I said attackers portscanning the system wouldn't work against port-knocking security, but would work against moving ssh to another port.
But people actually portscanning you to find what port you're running SSH on are very rare, and 99% of ssh attacks are automated port-22 attacks.
So for slightly less security than port knocking, which requires special programs both on the client and server, you can instead simply move to another port and get most of the benefit and none of the hassle.
And, as an added bonus, you know any ssh attacks that logwatch reports are actual people attempting to break in specifically to your server, and have probably attacked you other ways. As opposed to actual people being lost amidst the noise of automated attacks.
Does PuTTY? Probably not. If it does, that's probably 90% of ssh protocol users. Either PuTTY or the command line tools with it, or ssh or libssh in some manner.
I had completely forgotten SRV records even existed. It is a shame they aren't used more often.
Actually, what's a shame is that SRV records can't work like MX records too. Where you could say 'POP3 service for this domain is on this computer over here, on this port, with priority 10.'.
Well, it's not so much the Microsoft absence as the router absence that's the problem, and the total lack of anything converting back and forth midtransmission.
But, anyway, I'm not sure you're right. Last time I played around with IPv6 on Linux, you could run services on an IPv4 address but not the 'same' IPv6 address, and vis versa.
You even needed to upgrade an application to IPv6 to make it listen on an IPv6 that was mapped to a as an IPv4 one, instead of it just magically doing both like it should have.
They aren't treated the same, internally, but as two separate addresses. Obviously, there are API differences for programmers, and applications needed to upgrade if they wanted to specify the entire IPv6 range as opposed to the IPv4 subset. And you might need some weird NATing if an address outside the IPv4 range connected to a service that thought it was still speaking IPv4, but that's easily doable. (It's much easier than a lot of the NATing that's in Linux. Hell, it's easier than FTP NATing!)
But the upgrade path could have been smoother if the IPv4 applications could have said 'I want to listen on 10.0.0.1', and also ended up listening on::ffff:10.0.0.1, and that was actually, you know, routed in some manner.
Except 'also' is the wrong word, because those two addresses should have been indistinguishable. You say it one way in IPv6, or the other way in IPv4, and you're free to convert it back and forth at any time, because they should literally be the same address. IPv4 systems would just need it 'dumbed down'.
Instead, we have this nonsense, where 'mapped' IPv4 address in IPv6 are not the same thing as actual IPv4 addresses, and nothing converts back and forth. So if at any point of your journey doesn't support IPv6, you can't use it at all, even to connect to supposed IPv4 addresses over it.
Basically, all the mapped range did was give everyone at least one IPv6 address...which doesn't work because to reach the internet, it has to travel over some IPv4 network. Yeah, thanks for that, that was useful.
rsync is a protocol and library to transfer small amounts of file changes. The rather simple program included with it named rsync, can, indeed, only go in one direction at once. Because to do anything else, it would need to keep track of changes in files, which means it would need to keep track of what you've done before.
Like the program named 'dsync' does, in fact. Or Microsoft's 'SyncToy' does.
As for RAID1, that rather disproves your point.
Under your definition of sync being one-way, RAID1 would work by constantly have one drive's content copied to the other. And you could only replace the second drive, not the first. Which obviously isn't even vaguely how RAID1 works.
No, a 'resync' is because sane sync implementation won't copy failed data off one of the things it's syncing. In addition to noticing changes and propagating them across, they also notice total failure. And instead of idiotically thinking 'Well, I guess the guy erased all the data on this drive by putting in a new one, let me erase the data on the other drive, too', they copy the data to new drive.
That is what is commonly called a 'resync', when the system notices that a specific sync location has totally invalid data, or no data, on it, and hence needs all data rewritten there. The fact that RAID is smart enough not to copy information off a new drive does not make it one-way. This happens in RAID1, you will notice, with either drive, aka, it's bidirectional.
And a TV sync signal has exactly one item of data, and hence both ends cannot change it. More importantly, it is a timekeeping data. All time synchronization is one-way, hence no one needs to specify it. Timekeeping data is brand new and hence one end cannot 'change' it, while the other end 'keep it the same', hence two-way sync can never make any sense.
Whereas computer file synchronization and computer data synchronization both can be either one way or two way. If you mean 'two-way', you normally say 'sync'. If you mean 'one-way', you normally say something else, like 'mirror', or 'one-way sync'. Read this and notice that they say it's technically either kind, but they're talking about two-way. That's what everyone does, and uses specifics if talking about unidirectional. See also this, and note 'and vis versa'.
And, perhaps more important for this discussion, iTune sync with an iPod or iPhone is always two-way sync, and hence when people are talking about having third party devices syncing with iTunes, they are talking about the same thing.
And 'merge', incidentally, does not mean 'two way sync'. If I merge in changes to a file in a versioning system, I end up with a file that has both my changes and someone else...but they still have just their changes. Likewise, in Windows Vista, if I copy a directory to another location where one with that name already exists, I can 'merge' that directory into the other...but that won't do anything to the location I copied it from.
Merge is, generally, when two sets of changes end at one location, which is usually accomplished by copying all changes from one place and inserting them into another, hence one way. Although sometimes, instead, 'merge' means two-way but only 'add' and not 'delete'.
I can't think of any use where merge means propagation back and forth of all changes.
You can get 99% of the port knocking benefit by simply running ssh on another port.
Almost all ssh attacks are automated, and if you're not running something on port 22, you won't be attacked.
So essentially you're left with people who are specifically targeting you, and portscan the system. Those are the sole people that port-knocking protects against.
Here's a simple test: run John overnight on your shadow file. If it can't guess your password, nobody's ever going to get in via ssh by guessing your root password. Ever. John tries passwords by the THOUSANDS per second...
Seriously. Brute force of actual good passwords is not a foreseeable option.
If it worries you that much, it's pretty easy to implement something to make the system even slower. For example, I've previously used iptables to only let each IP make three new ssh connections every minute. ssh also has that option, and it can only count failed attempts.
I turned it off because I realized that was utterly pointless, and no one was going to break in in any reasonable amount of time.
Although I've recently considered messing around with iptables on our mail server and making repeated failed ssh attempts block access to the email server, as obviously they are either malicious, or their machine is controlled by a virus, and either way, any mail from that IP is probably spam. I need to run some intersect of the spamming IPs with ssh attempts and see if there's any overlap first.
Except, at this point, there are no legacy hosts to any degree. 99.9% of the computers out there either can already do IPv6, or do it with a minor upgrade. Legacy hosts are not the problem.
The problem is the fact that IPv6 was built in an incredibly fucking stupid way.
It should have been set up as a transparent change, where every person who had an IPv4 address magically had an IPv6 address that worked, and whenever an IPv6 stack, be it either your computer or some router halfway down the road, determined it was talking to IPv4, converted it into IPv4. And no connection should have handled both....you speak IPv6 if the other end understands it, you speak IPv4 otherwise.
Please notice that the link-level protocol of Ethernet can actually specify IPv4 or IPv6, so devices can immediately talk the correct protocol, without even sending out a DHCP packet. And wifi has pseudo-ethernet link level (In addition to the actual wifi link-level), so it works there too. And I bet it wouldn't be too hard to cobble something together for ATM connections and whatnot, if they don't already have such a thing.
So every IPv6 device, when hooked up to whatever, could instantly say 'Can I talk IPv6, or do I need to talk IPv4?' on each plug. It can talk IPv6 in one direction, and IPv4 in the other, and convert. (Or, at least, most devices. Your cheap-ass DSL router, probably not, it might flip into IPv6 mode only if all connections were IPv6 so it didn't have to convert.)
In other words, all packets, as they flowed across the internet, would be IPv4 on legacy networks, and IPv6 on newer ones, and converted back and forth at any (almost) router that went from new to old or old to new. And every router would at least flip to IPv6 when both sides spoke it.
As devices were slowly replaced, more and more of the entire path would be IPv6, and eventually people would be talking to the backbone entirely using IPv6. You could even include a bit in the IPv6 packet that meant 'originated as IPv6', which packet senders would set, but would be dropped during conversion and back, and then could statistically determine, at any point on the internet, how much of the traffic had reached there entirely via IPv6, and ARIN could have some sort of percentage trigger to start making IPv6-only addresses via beyond beta testing.
And eventually, everyone would switch, and 95% of the people would return their IPv4, leaving they few remaining IPs for actual non-upgradable devices, which would mainly be embedded systems, along those sites that said devices need to contact to, which they would do unknowingly over mostly IPv6.
Instead, we have this stupid-ass situation where we're facing incompatibility as we upgrade.
Yeah, I knew there were ways to control iTunes from the outside.
I was just taking issue with people talking about 'sync' and the XML file like they had anything to do with each other. You can't do anything with that list.
And you're right. I'm not actually seeing the point of anyone bothering to attempt copy non-metadata changes back to iTunes. Even play-count information is in the file metadata. The only things I could think of were altering playlists, and putting songs on the device somewhere else that you then want to show up in iTunes. It's absurd to even try to bother with those.
But, regardless of how much sense it makes to actually do, that is what people are talking about when they talk about hardware 'syncing' with iTunes.
But random people here misunderstood that to mean 'syncing the mp3 files', and, for some reason, think that has something to do with the XML file. This is doubly stupid, as syncing back the mp3 files put on a third-party mp3 player, by a third-party app, is trivially easy and obviously wouldn't involve iTunes at all, in any way, even if the file is also in iTunes. Just update the damn files, and, tada, iTunes is updated when it starts, or at least when it refreshes. (I have an iPhone, but I hate iTunes player interface, and don't use it to manage my music, so don't actually know how often it rereads metadata.)
And I have no idea why Palm is trying to use iTunes to sync, instead of just syncing the mp3 files, and then sending the (very few) pieces of data that iTunes needs to iTunes using their interface, to say 'Here's the new playlist, and also add these music file to your library that we just copied off the device into this location'.
Okay, a lot of people here don't know what 'sync' is.
Sync, when used by itself, implies bidirection.
To demonstrate this fact, I will launch SyncToy 2.0, by Microsoft, which takes two directories and movies files between them. It has three options for this, one called Synchronize, in which all changes in either directory are propagated into the other one, and two other things not named synchronize which only move changes one way.
Likewise, when people sync things from an iPod, they're also getting a two-way sync in iTune. If you change your contacts in Outlook, and on your iPhone, the changes go both directions.
Got it?
Okay, let us explain this XML thing. iTunes, when started, writes an XML file with the location of all its music. Other applications can read this.
This is not 'syncing'. Hell, it's not actually a one-way sync either, it's simply providing a damn giant playlist of all files which third-party software can read to know where all iTune music files are.
Although I'm at a lost to know why third party software would even slightly need to do that to 'sync'. It would be smart, at startup, to import that list of music, so the application doesn't need to scan for music. Sorta an 'import your bookmarks' type thing. It could even run each startup to find new music fils, so you have a 'one-way' sync of that application from iTunes.
But that has nothing to do with syncing hardware. If a third party player puts a file on a device, it should actually store the location of that file somewhere locally so it can sync them. I.e., the application itself is going to know that X.mp3 on the device came from C:\blah\X.mp3, because it stored that location in a database when it put the file on the device. So it can copy file changes back and forth.
It's not going to have any interaction with iTune at all for this, so the iTunes XML isn't useful for syncing hardware devices at all. But we're not talking about syncing 'music files' anyway.
We're talking about syncing hardware players with iTunes. Making iTunes reflecting things that changed on that device, like editing playlists and downloading music from other computers or whatever. You cannot do that via the XML file, for the simply matter that iTunes does not, in any way, read that file. iTunes just writes it.
Now, you can probably get metadata changes back off your device and into iTunes, although that's mostly by accident...your third-party player would sync the file back off the device, and I think iTunes would pick up the metadata change when it started next, or possibly when it next opened the file to play it. Can anyone confirm this?
I agree about iTunes. Seriously, this is supposed to be good software?
And I say that as someone with an iPhone, which is a pretty amazing piece of hardware. I'm not an Apple hater.
But you, like me, don't have to use iTune unless you want to purchase from their store, except to backup and sync your phone. You can turn off music and video sync and just sync contacts. (And even that is damn stupid....hey, I don't want to sync my notes with Outlook, how about you stop bitching that I 'haven't set up an account in Outlook' even though that sync is turned off? Or, even better, how about you make a damn directory of text files containing my 'notes'!)
There are plenty of apps that can sync music and videos to iTune. I use foobar2000. Yes, it can sync videos, if you put them in. (Annoyingly, it appears they've currently overlooked syncing ringtones.)
If you use some sort of podcast downloader, there are foobar extensions that can include pull directories in playlists at startup, although I admit I'm still using iTunes for podcast downloading.
Before anyone attempts to claim I said foobar 2000 was better than iTunes, I was not. That would be a stupid claim considering they're aimed at entirely different audiences, and foobar is just a audio player. I was just using that as an example of something that can sync iPods and iPhones. iTunes is shitty when compared to other media players aimed at the same novice-to-medium level users. It's the bare minimum player, and it has a lot of stupid design decisions. Even fricking Windows Media Player is better. Winamp is better, and I hate winamp!
Frequent escalation prompts are almost completely an application level issue.
Yes, but Linux has less applications running privileged. (At least, Linux desktops.) Less applications with root privs=less escalation exploits.
It's an application problem, not a Windows problem.
At this point, all Windows problems are third-party problems. Either application problems or driver problems. The actual code written by MS is fairly good.
That does not actually change anything, nor does it mean that Linux is not better designed in those areas, or at least better designed than Windows was previously designed, and has to continue to support that stupid design.
In short, Windows pre-NT was incredibly stupidly designed. NT and later, the design is fine, in fact, the design is arguably better than Linux.
However, in practice, it had to support all the older apps, so was the new design was constantly ignored in favor of everyone running as Admin. And because everyone ran as admin, apps continued to come out that required it, even as late as present day!
They really needed UAC on XP, and not let people run as Admin. It's going to take an entire software generation, call it 5-10 years, of UAC and software being forced to do actual correct privilege separation, or be very annoying if they aren't doing it, before Windows is anywhere near as secure as Linux was a decade ago.
That's not what the advisories on secunia.com would suggest.
Most of those are for things desktop users would not be running, and, just as importantly, almost all applications on Linux systems are provided via the distribution, and hence can be quickly upgraded by the distribution. Silently, in the background.
Except that won't be what happens, nor is there any reason to think it is.
If malware is stuck as a user, there are a limited numbers of places it can reasonable put itself. There's probably a better place than.bashrc like some obscure gnome config file, but the program files themselves are also limited essentially to ~
UAC behaves identically to sudo prompts in Linux distros like Ubuntu, and OS X. It prompts in the same scenarios and for the same reasons.
Oh, I'm not in any way trying to say that the sudo prompts in Linux are correct way to do it. We're not talking about now, where most users of Linux are either expert users, or locked-out non-admin users who can't do anything anyway.
I'm talking about a hypothetical future where Linux and MS have, let's say, 50% markeshare, with roughly the same people running them, and as many virus target Linux as Windows. (The comment that started all this was 'If Linux becomes the place where the people and money are, Linux will have its own legion of malware writer') Linux distros could do sudo correctly, and would if they got viruses that did sudo prompts.
Of course, first I should point out that Linux applications don't commonly need admin privs and prompt users at launch. Usually, any program that does that has some logical reason for it, as opposed to some Window game that wants direct access to the CD because of DRM or something.
As for changes, I'd suggest: Stop prompting to install, or uninstall, signed application software from the distribution channel. Just go ahead and do it, unless they user's been blocked from that by admin. Distros would have to decide what is 'application' vs. what is 'system', but they already do that.
Considering that 90% of 'prompting to install malware' on Windows is when users know they're installing something, if you have users normally install things by going into the 'Add/Remove Applications' and just clicking on them and poof, installed, they are going to be somewhat hesitant to download something, mark it executable, and launch it, and then type in their root password.
Whereas Window users do that (mostly) all the time. Heck, now what Linux us
Typically because the user allows it to ("Click Continue to see porn ? Sure I will.").
This is why you don't allow privilege escalation without a root password, and you don't commonly have parts of the system that need it. Even stuff like installing out of repositories can be done without escalating the user.
If users only typed that in their root password once a month or less, users are unlikely to type it in in some random circumstance. You just have to have a moderately intelligent sort of 'sudo'.
How do you know the malware hasn't used a local escalation exploit, spread itself throughout the whole system, and possibly even into things like the MBR or BIOS ?
Because local escalation exploits of vanishingly rare on Linux, and so common on Windows that they essentially cannot be called 'exploits' anymore, but actual features of the OS.
And many applications out there have to run as admin anyway, making any sort of 'exploit' pointless. Window's inability to actually practice any sort of account separation is the problem here. (No matter which is better or worse 'in theory'.)
Yes, if Linux got more popular, more malware would be written for it, but user malware is easy to fix. System malware is not. Thanks to the dominate OS making the first incredibly easy to become the latter, the PC security community has mostly failed to realize or understand these two entities are not the same thing. (Like your 'nuke the machine' recommendation.) Hence their constant statement of 'If Linux was popular, viruses would be targeted at it', which is true, but irrelevant...viruses are easy to fix when the antivirus is root, and the virus is not. Malware is easy to find when it's launching itself from.bashrc and is a normal process.
Now, of course, privilege escalation exploits would, in fact, show up on Linux, and viruses would use them until they were fixed. That can't be stopped. But occasional weaknesses are not the same as Windows constant inability to get it right ever, along with, ironically as they fix that, their dumb new UAC system, which teaches users to allow processes to do whatever they want.
OTOH, Linux systems are still easier to recover from even a system infection, as almost every executable file will be from a known package with a known digital signature, and a boot CD could just download and reinstall all those files that have incorrect signatures, check each document file, and nuke everything else. Windows systems are impossible to repair because you can't verify every file...but you can verify 99% of them on a Linux system, and leave the system mostly intact.
It's irrelevant until you need to fix the problem.
Windows malware, all too often, totally breaks the system, somehow managing to escape from the user account.
I have no idea how this happens, but it does. The entire system gets broken. Antivirus gets broken quickly before definition updates come in. People have system-wide IE problems, and their hosts file is rewritten, and there's a damn ring-zero network driver running.
Linux, however, has actual account separation. Yes, malware could get in, and horrible infect an account, turning the machine into some virus spewing monster.
But it couldn't break the antivirus, which would update and catch the problem. It couldn't some people from booting up as some other user, or even some sort of automated recovery tool that move all files somewhere else and then copies 'known safe' files back to the account, running chmod -x on documents, and general fixing everything. A fricken shell script could get rid of viruses!
Running as normal users on an OS with actual account separation, and users who don't generally type in a root password is not 'safer' in the sense that infection is less likely. It is not less likely.
But it's much better in that you, or even antivirus software, can actually fix infections.
Hell, you could fix the system by installing antivirus after the infection, which is near impossible on Windows.
Oh, and incidentally, rereading 'You are required to turn 'mislaid property' over the owner of the premise it's found on. Aka, the owner of the car.' I am not actually 100% sure that's true.
I'm pretty certain if you find mislaid items in a vehicle, the owner (or operator) of the vehicle is who you need to turn it in to, according to the law. Like if you find a coat draped over the back of a bus seat, you should turn it over to the driver. As opposed to turning it into the state government whose road you're on or convenience store whose parking lot you happen to be in at the time of discovery, which would make no sense.
I am not sure this works for things found on a vehicle, though. If I walk out of a concert and find someone's coat laying on my car, I don't need to take the damn thing with me, the coat owner is hardly going to be able to find me. It should be turned into the property owner. (Or, in practice, just moved out of the way so I can leave.)
So the law may make a distinction there, where only things 'in' vehicles should remain with vehicles, and thing 'on' vehicles should remain with the property owner.
Now, logically, the tracking device was attached to the car, so logically, the place the owners who 'mislaid' it are going to look for it is with the car. Likewise, it logically is 'within' the car's body at least, although not inside the passenger compartment.
However, 'logically' and 'the law' are not always the same thing. The last thing you want to do is get tripped up in some technicality, and believe me the police will try to invent one when they realize you've taken their expensive GPS device and they didn't claim it within the legal deadline and you're refusing to give it back.
So either check the law, or just be sure to discover the device when your car is on your own property, (Why are you looking under your car anywhere else, anyway?) so either way it's you it should be turned in to and you who ends up owning it if the owner does not show up.
Oh, and don't feel too bad if they do show up to get it. It's still pretty damn funny, especially as you have the legal obligation to have them prove ownership before turning it over. Be sure to ask them to describe it, and when they think they mislaid it, and can they describe the car they mislaid it under?
Slashdot Mirror
No kidding.
This \0 nonsense demonstrates two things:
1) All products have security holes. Often near identical ones, especially if it's an implementation detail no one ever considered before. (I remember, in the old days, OS after OS kept getting hit with TCP/IP attacks using various malformed packets.)
2) Microsoft takes way too long to fix their security holes.
He's not talking about when you pull from the DB.
He's talking about data-bound controls, where a text field or something is linked to a field in the DB. (And hence he can't run it through any sort of conversion on the way in.)
Exactly.
For example, my work laptop is encrypted with TrueCrypt.
TrueCrypt has, on startup, a clever feature where it can pretend be a disk error. Instead of a prompt, it can say 'Missing operating system' or something. And it doesn't respond at all unless you put in the correct password. I turned this on.
Any fool who looks at the hard drive can tell that the first sector or whatever are TrueCrypt, no matter what it says. But, at that point, after someone learns that, it's protected by actual working encryption.
Meanwhile, some loser who steals it who boots up the laptops he steals to see if there's anything obvious on them, is going to say 'Oh, it's broken, time to reformat'.
Yes, it's extremely unlikely that that person would actually be able to get in if, instead, they were presented with a 'Type in your password' prompt. But who knows, maybe I'm still being held at gunpoint or something and they want my password. It cannot but help.
Using security by obscurity is stupid. Using security with obscurity is not.
Use a well-known and tested encryption algorithm, but feel free not to label it, and to XOR the result with 'asgf12' so that someone has to figure that out and customize any cracking code to undo that first.
And, yes, this really only applies to non-mass produced systems. Anything that could have automated attack tools written for it is pointless to hide anything.
I know what you're saying, and you're entirely right, I was just trying to dumb it down for gold fools who have no damn idea how the money supply actually works, or why we have inflation, and that it's a feature, not a bug.
Most people really don't understand that the size of the economy and the amount of 'money' in the economy will become the same. Too much money vs. the economy, money becomes worth less to match. Too little, money becomes worth more to match.
I think that is simple enough and logical enough that I can beat it into people's head.
And then they'll realize that, fix the currency to a set value, and actually accomplish that, and you'd lock the economy in place also.
Although, as you point out, if we switch to gold, we'd just inflate gold instead, so that wouldn't actually happen. However, gold fools seem to be under the impression that gold currency somehow is not subject to inflation.
Oh, that's not the bad thing of switching to gold.
The money supply is supposed to match the economy. Economists don't agree on much, but that's one area where they they don't differ at all. You need roughly the same amount of money chasing each transaction.
When the economy grows and the money supply doesn't, you get deflation. Vis versa, you get inflation.
And the economy is always going to grow on average. Simply because there are more actual people each year who work and purchase stuff.
Hence, with an essentially fixed currency like gold, we'd suffer deflation, unless something went horribly wrong with the world population.
Now, deflation doesn't sound as bad as inflation, but that's because no one here remembers any instances of it, and it's very easy to avoid with a variable money supply. When the Fed prints slightly more money than need, causing inflation, they're doing it to avoid the worse problem of deflation.
Yes, all your savings go up in value faster, but the economy sorta breaks, as everyone constantly puts off actually spending any money. Not because they are scared they might need it later, like in a recession caused be shrinking economy, but because they know it will be worth more next week.
This will cause a real recession as hoarding continues. But it's not really a 'recession', it's more an 'economic contraction'. With deflation, the economy will match the money supply, like it or not.
The people starving to death because the economy couldn't expand to feed them probably won't like it.
You know what a fun question to ask gold standard supporters is? How much the money supply grew under the gold standard, from the start of this country until we switched from it?
Most of them will either assume it grew randomly, or not at all, and be totally ignorant of the fact it mostly matched the economy, and when it was oversupplied, we had inflation until the economy matched did, and when it was undersupplied the reverse happened.
We finally decided to stop letting some totally random variable, the gold supply, dictate the size of the economy!
You do realize that you are factually incorrect, right? That no matter how clever you think you are, all diabetics do not, in fact, have health care?
I don't know how Blizzard does it.
The example I know of is GetRightToGo, which my company uses to hand people a stub program which will then download a larger installer to launch. It can do torrents if you set up a torrent.
It can even do torrents and capped straight download, at the same time, so you can say 'This person can download from us at 50k a second, and download at whatever speed via the torrents.'. (My company does not use the torrent feature, though, so I just know what the documentation says.)
It would be nice if MS would start doing this, and then show up in Congress talking about how ISPs need to stop overcommitting their network and randomly restricting services because of that.
You can almost send a CD for under $2 by hand, in the smallest increments possible.
The 6x8 'photo sleeve' mailers cost about $1.20 if purchased one at a time and the mailing of them costs about $0.80. With about $0.10 per CD and $0.02 for the CD sleeve.
If you're buying in bulk, you can get photo mailers for about $0.30, and the CD mailers cost about $0.25 in bulk. (And by 'bulk', I mean 'a hundred', they're even cheaper if you're sending out MS-levels of product.) And if you actually buy the smaller CD mailers, you can get mail them for cheaper, too. And the CD will be cheaper if made in bulk.
It would totally blow my mind if Microsoft or HP or whoever could not get 10,000 CDs to people's doors for under $10,000, with almost all the money going to the post office.
Netflix, as has been pointed out, has a plan that charges essentially $5 a month that has four DVD mailings built in, so $1.25 a shipment, including, presumably, some actual profit for Netflix. (Also, not everyone uses all exchanges every month.) They don't have to burn new DVD, but, OTOH, they don't get to take advantage of the post office's reduced rates for pre-sorted mail either.
As the license cost probably already includes the price of a disk you didn't get, it seems a sorta stupid quibble.
But, more importantly, software distribution over torrent has always made more sense than straight downloading. Before anyone asserts that 'torrents are too complicated', I am, in fact, talking about a download program that does torrenting internally, not handing people a .torrent file.
Erm, so MS would instead give out a stub program that people download in ten second and then launches, which then downloads, in the background, the ISO, and when it's downloaded burns it to a CD.
Of course, it should first check to make sure there's a CD-R in the system, and possibly even make people insert a blank CD to prove they have one. (So some fool doesn't try to use an AOL CD.)
Of course, for experts, they could have a torrent with just the ISO. (Or even use a torrent system in their downloader, and just let other people access it directly.)
It's not rocket science.
EPIC FAIL
Try reading my post again. I said attackers portscanning the system wouldn't work against port-knocking security, but would work against moving ssh to another port.
But people actually portscanning you to find what port you're running SSH on are very rare, and 99% of ssh attacks are automated port-22 attacks.
So for slightly less security than port knocking, which requires special programs both on the client and server, you can instead simply move to another port and get most of the benefit and none of the hassle.
And, as an added bonus, you know any ssh attacks that logwatch reports are actual people attempting to break in specifically to your server, and have probably attacked you other ways. As opposed to actual people being lost amidst the noise of automated attacks.
Wow, does ssh actually do that correctly? Cool.
Does PuTTY? Probably not. If it does, that's probably 90% of ssh protocol users. Either PuTTY or the command line tools with it, or ssh or libssh in some manner.
I had completely forgotten SRV records even existed. It is a shame they aren't used more often.
Actually, what's a shame is that SRV records can't work like MX records too. Where you could say 'POP3 service for this domain is on this computer over here, on this port, with priority 10.'.
Well, it's not so much the Microsoft absence as the router absence that's the problem, and the total lack of anything converting back and forth midtransmission.
But, anyway, I'm not sure you're right. Last time I played around with IPv6 on Linux, you could run services on an IPv4 address but not the 'same' IPv6 address, and vis versa.
You even needed to upgrade an application to IPv6 to make it listen on an IPv6 that was mapped to a as an IPv4 one, instead of it just magically doing both like it should have.
They aren't treated the same, internally, but as two separate addresses. Obviously, there are API differences for programmers, and applications needed to upgrade if they wanted to specify the entire IPv6 range as opposed to the IPv4 subset. And you might need some weird NATing if an address outside the IPv4 range connected to a service that thought it was still speaking IPv4, but that's easily doable. (It's much easier than a lot of the NATing that's in Linux. Hell, it's easier than FTP NATing!)
But the upgrade path could have been smoother if the IPv4 applications could have said 'I want to listen on 10.0.0.1', and also ended up listening on ::ffff:10.0.0.1, and that was actually, you know, routed in some manner.
Except 'also' is the wrong word, because those two addresses should have been indistinguishable. You say it one way in IPv6, or the other way in IPv4, and you're free to convert it back and forth at any time, because they should literally be the same address. IPv4 systems would just need it 'dumbed down'.
Instead, we have this nonsense, where 'mapped' IPv4 address in IPv6 are not the same thing as actual IPv4 addresses, and nothing converts back and forth. So if at any point of your journey doesn't support IPv6, you can't use it at all, even to connect to supposed IPv4 addresses over it.
Basically, all the mapped range did was give everyone at least one IPv6 address...which doesn't work because to reach the internet, it has to travel over some IPv4 network. Yeah, thanks for that, that was useful.
Um, no.
rsync is a protocol and library to transfer small amounts of file changes. The rather simple program included with it named rsync, can, indeed, only go in one direction at once. Because to do anything else, it would need to keep track of changes in files, which means it would need to keep track of what you've done before.
Like the program named 'dsync' does, in fact. Or Microsoft's 'SyncToy' does.
As for RAID1, that rather disproves your point. Under your definition of sync being one-way, RAID1 would work by constantly have one drive's content copied to the other. And you could only replace the second drive, not the first. Which obviously isn't even vaguely how RAID1 works.
No, a 'resync' is because sane sync implementation won't copy failed data off one of the things it's syncing. In addition to noticing changes and propagating them across, they also notice total failure. And instead of idiotically thinking 'Well, I guess the guy erased all the data on this drive by putting in a new one, let me erase the data on the other drive, too', they copy the data to new drive.
That is what is commonly called a 'resync', when the system notices that a specific sync location has totally invalid data, or no data, on it, and hence needs all data rewritten there. The fact that RAID is smart enough not to copy information off a new drive does not make it one-way. This happens in RAID1, you will notice, with either drive, aka, it's bidirectional.
And a TV sync signal has exactly one item of data, and hence both ends cannot change it. More importantly, it is a timekeeping data. All time synchronization is one-way, hence no one needs to specify it. Timekeeping data is brand new and hence one end cannot 'change' it, while the other end 'keep it the same', hence two-way sync can never make any sense.
Whereas computer file synchronization and computer data synchronization both can be either one way or two way. If you mean 'two-way', you normally say 'sync'. If you mean 'one-way', you normally say something else, like 'mirror', or 'one-way sync'. Read this and notice that they say it's technically either kind, but they're talking about two-way. That's what everyone does, and uses specifics if talking about unidirectional. See also this, and note 'and vis versa'.
And, perhaps more important for this discussion, iTune sync with an iPod or iPhone is always two-way sync, and hence when people are talking about having third party devices syncing with iTunes, they are talking about the same thing.
And 'merge', incidentally, does not mean 'two way sync'. If I merge in changes to a file in a versioning system, I end up with a file that has both my changes and someone else...but they still have just their changes. Likewise, in Windows Vista, if I copy a directory to another location where one with that name already exists, I can 'merge' that directory into the other...but that won't do anything to the location I copied it from.
Merge is, generally, when two sets of changes end at one location, which is usually accomplished by copying all changes from one place and inserting them into another, hence one way. Although sometimes, instead, 'merge' means two-way but only 'add' and not 'delete'.
I can't think of any use where merge means propagation back and forth of all changes.
You can get 99% of the port knocking benefit by simply running ssh on another port.
Almost all ssh attacks are automated, and if you're not running something on port 22, you won't be attacked.
So essentially you're left with people who are specifically targeting you, and portscan the system. Those are the sole people that port-knocking protects against.
Here's a simple test: run John overnight on your shadow file. If it can't guess your password, nobody's ever going to get in via ssh by guessing your root password. Ever. John tries passwords by the THOUSANDS per second...
Seriously. Brute force of actual good passwords is not a foreseeable option.
If it worries you that much, it's pretty easy to implement something to make the system even slower. For example, I've previously used iptables to only let each IP make three new ssh connections every minute. ssh also has that option, and it can only count failed attempts.
I turned it off because I realized that was utterly pointless, and no one was going to break in in any reasonable amount of time.
Although I've recently considered messing around with iptables on our mail server and making repeated failed ssh attempts block access to the email server, as obviously they are either malicious, or their machine is controlled by a virus, and either way, any mail from that IP is probably spam. I need to run some intersect of the spamming IPs with ssh attempts and see if there's any overlap first.
Except, at this point, there are no legacy hosts to any degree. 99.9% of the computers out there either can already do IPv6, or do it with a minor upgrade. Legacy hosts are not the problem.
The problem is the fact that IPv6 was built in an incredibly fucking stupid way.
It should have been set up as a transparent change, where every person who had an IPv4 address magically had an IPv6 address that worked, and whenever an IPv6 stack, be it either your computer or some router halfway down the road, determined it was talking to IPv4, converted it into IPv4. And no connection should have handled both....you speak IPv6 if the other end understands it, you speak IPv4 otherwise.
Please notice that the link-level protocol of Ethernet can actually specify IPv4 or IPv6, so devices can immediately talk the correct protocol, without even sending out a DHCP packet. And wifi has pseudo-ethernet link level (In addition to the actual wifi link-level), so it works there too. And I bet it wouldn't be too hard to cobble something together for ATM connections and whatnot, if they don't already have such a thing.
So every IPv6 device, when hooked up to whatever, could instantly say 'Can I talk IPv6, or do I need to talk IPv4?' on each plug. It can talk IPv6 in one direction, and IPv4 in the other, and convert. (Or, at least, most devices. Your cheap-ass DSL router, probably not, it might flip into IPv6 mode only if all connections were IPv6 so it didn't have to convert.)
In other words, all packets, as they flowed across the internet, would be IPv4 on legacy networks, and IPv6 on newer ones, and converted back and forth at any (almost) router that went from new to old or old to new. And every router would at least flip to IPv6 when both sides spoke it.
As devices were slowly replaced, more and more of the entire path would be IPv6, and eventually people would be talking to the backbone entirely using IPv6. You could even include a bit in the IPv6 packet that meant 'originated as IPv6', which packet senders would set, but would be dropped during conversion and back, and then could statistically determine, at any point on the internet, how much of the traffic had reached there entirely via IPv6, and ARIN could have some sort of percentage trigger to start making IPv6-only addresses via beyond beta testing.
And eventually, everyone would switch, and 95% of the people would return their IPv4, leaving they few remaining IPs for actual non-upgradable devices, which would mainly be embedded systems, along those sites that said devices need to contact to, which they would do unknowingly over mostly IPv6.
Instead, we have this stupid-ass situation where we're facing incompatibility as we upgrade.
Yeah, I knew there were ways to control iTunes from the outside.
I was just taking issue with people talking about 'sync' and the XML file like they had anything to do with each other. You can't do anything with that list.
And you're right. I'm not actually seeing the point of anyone bothering to attempt copy non-metadata changes back to iTunes. Even play-count information is in the file metadata. The only things I could think of were altering playlists, and putting songs on the device somewhere else that you then want to show up in iTunes. It's absurd to even try to bother with those.
But, regardless of how much sense it makes to actually do, that is what people are talking about when they talk about hardware 'syncing' with iTunes.
But random people here misunderstood that to mean 'syncing the mp3 files', and, for some reason, think that has something to do with the XML file. This is doubly stupid, as syncing back the mp3 files put on a third-party mp3 player, by a third-party app, is trivially easy and obviously wouldn't involve iTunes at all, in any way, even if the file is also in iTunes. Just update the damn files, and, tada, iTunes is updated when it starts, or at least when it refreshes. (I have an iPhone, but I hate iTunes player interface, and don't use it to manage my music, so don't actually know how often it rereads metadata.)
And I have no idea why Palm is trying to use iTunes to sync, instead of just syncing the mp3 files, and then sending the (very few) pieces of data that iTunes needs to iTunes using their interface, to say 'Here's the new playlist, and also add these music file to your library that we just copied off the device into this location'.
I wasn't trying to say you couldn't change iTunes stuff from outside iTunes.
I was just saying the XML file is completely useless for this.
Okay, a lot of people here don't know what 'sync' is.
Sync, when used by itself, implies bidirection.
To demonstrate this fact, I will launch SyncToy 2.0, by Microsoft, which takes two directories and movies files between them. It has three options for this, one called Synchronize, in which all changes in either directory are propagated into the other one, and two other things not named synchronize which only move changes one way.
Likewise, when people sync things from an iPod, they're also getting a two-way sync in iTune. If you change your contacts in Outlook, and on your iPhone, the changes go both directions.
Got it?
Okay, let us explain this XML thing. iTunes, when started, writes an XML file with the location of all its music. Other applications can read this.
This is not 'syncing'. Hell, it's not actually a one-way sync either, it's simply providing a damn giant playlist of all files which third-party software can read to know where all iTune music files are.
Although I'm at a lost to know why third party software would even slightly need to do that to 'sync'. It would be smart, at startup, to import that list of music, so the application doesn't need to scan for music. Sorta an 'import your bookmarks' type thing. It could even run each startup to find new music fils, so you have a 'one-way' sync of that application from iTunes.
But that has nothing to do with syncing hardware. If a third party player puts a file on a device, it should actually store the location of that file somewhere locally so it can sync them. I.e., the application itself is going to know that X.mp3 on the device came from C:\blah\X.mp3, because it stored that location in a database when it put the file on the device. So it can copy file changes back and forth.
It's not going to have any interaction with iTune at all for this, so the iTunes XML isn't useful for syncing hardware devices at all. But we're not talking about syncing 'music files' anyway.
We're talking about syncing hardware players with iTunes. Making iTunes reflecting things that changed on that device, like editing playlists and downloading music from other computers or whatever. You cannot do that via the XML file, for the simply matter that iTunes does not, in any way, read that file. iTunes just writes it.
Now, you can probably get metadata changes back off your device and into iTunes, although that's mostly by accident...your third-party player would sync the file back off the device, and I think iTunes would pick up the metadata change when it started next, or possibly when it next opened the file to play it. Can anyone confirm this?
I agree about iTunes. Seriously, this is supposed to be good software?
And I say that as someone with an iPhone, which is a pretty amazing piece of hardware. I'm not an Apple hater.
But you, like me, don't have to use iTune unless you want to purchase from their store, except to backup and sync your phone. You can turn off music and video sync and just sync contacts. (And even that is damn stupid....hey, I don't want to sync my notes with Outlook, how about you stop bitching that I 'haven't set up an account in Outlook' even though that sync is turned off? Or, even better, how about you make a damn directory of text files containing my 'notes'!)
There are plenty of apps that can sync music and videos to iTune. I use foobar2000. Yes, it can sync videos, if you put them in. (Annoyingly, it appears they've currently overlooked syncing ringtones.)
If you use some sort of podcast downloader, there are foobar extensions that can include pull directories in playlists at startup, although I admit I'm still using iTunes for podcast downloading.
Before anyone attempts to claim I said foobar 2000 was better than iTunes, I was not. That would be a stupid claim considering they're aimed at entirely different audiences, and foobar is just a audio player. I was just using that as an example of something that can sync iPods and iPhones. iTunes is shitty when compared to other media players aimed at the same novice-to-medium level users. It's the bare minimum player, and it has a lot of stupid design decisions. Even fricking Windows Media Player is better. Winamp is better, and I hate winamp!
Frequent escalation prompts are almost completely an application level issue.
Yes, but Linux has less applications running privileged. (At least, Linux desktops.) Less applications with root privs=less escalation exploits.
It's an application problem, not a Windows problem.
At this point, all Windows problems are third-party problems. Either application problems or driver problems. The actual code written by MS is fairly good.
That does not actually change anything, nor does it mean that Linux is not better designed in those areas, or at least better designed than Windows was previously designed, and has to continue to support that stupid design.
In short, Windows pre-NT was incredibly stupidly designed. NT and later, the design is fine, in fact, the design is arguably better than Linux.
However, in practice, it had to support all the older apps, so was the new design was constantly ignored in favor of everyone running as Admin. And because everyone ran as admin, apps continued to come out that required it, even as late as present day!
They really needed UAC on XP, and not let people run as Admin. It's going to take an entire software generation, call it 5-10 years, of UAC and software being forced to do actual correct privilege separation, or be very annoying if they aren't doing it, before Windows is anywhere near as secure as Linux was a decade ago.
That's not what the advisories on secunia.com would suggest.
Most of those are for things desktop users would not be running, and, just as importantly, almost all applications on Linux systems are provided via the distribution, and hence can be quickly upgraded by the distribution. Silently, in the background.
Except that won't be what happens, nor is there any reason to think it is.
If malware is stuck as a user, there are a limited numbers of places it can reasonable put itself. There's probably a better place than .bashrc like some obscure gnome config file, but the program files themselves are also limited essentially to ~
UAC behaves identically to sudo prompts in Linux distros like Ubuntu, and OS X. It prompts in the same scenarios and for the same reasons.
Oh, I'm not in any way trying to say that the sudo prompts in Linux are correct way to do it. We're not talking about now, where most users of Linux are either expert users, or locked-out non-admin users who can't do anything anyway.
I'm talking about a hypothetical future where Linux and MS have, let's say, 50% markeshare, with roughly the same people running them, and as many virus target Linux as Windows. (The comment that started all this was 'If Linux becomes the place where the people and money are, Linux will have its own legion of malware writer') Linux distros could do sudo correctly, and would if they got viruses that did sudo prompts.
Of course, first I should point out that Linux applications don't commonly need admin privs and prompt users at launch. Usually, any program that does that has some logical reason for it, as opposed to some Window game that wants direct access to the CD because of DRM or something.
As for changes, I'd suggest: Stop prompting to install, or uninstall, signed application software from the distribution channel. Just go ahead and do it, unless they user's been blocked from that by admin. Distros would have to decide what is 'application' vs. what is 'system', but they already do that.
Considering that 90% of 'prompting to install malware' on Windows is when users know they're installing something, if you have users normally install things by going into the 'Add/Remove Applications' and just clicking on them and poof, installed, they are going to be somewhat hesitant to download something, mark it executable, and launch it, and then type in their root password.
Whereas Window users do that (mostly) all the time. Heck, now what Linux us
Typically because the user allows it to ("Click Continue to see porn ? Sure I will.").
This is why you don't allow privilege escalation without a root password, and you don't commonly have parts of the system that need it. Even stuff like installing out of repositories can be done without escalating the user.
If users only typed that in their root password once a month or less, users are unlikely to type it in in some random circumstance. You just have to have a moderately intelligent sort of 'sudo'.
How do you know the malware hasn't used a local escalation exploit, spread itself throughout the whole system, and possibly even into things like the MBR or BIOS ?
Because local escalation exploits of vanishingly rare on Linux, and so common on Windows that they essentially cannot be called 'exploits' anymore, but actual features of the OS.
And many applications out there have to run as admin anyway, making any sort of 'exploit' pointless. Window's inability to actually practice any sort of account separation is the problem here. (No matter which is better or worse 'in theory'.)
Yes, if Linux got more popular, more malware would be written for it, but user malware is easy to fix. System malware is not. Thanks to the dominate OS making the first incredibly easy to become the latter, the PC security community has mostly failed to realize or understand these two entities are not the same thing. (Like your 'nuke the machine' recommendation.) Hence their constant statement of 'If Linux was popular, viruses would be targeted at it', which is true, but irrelevant...viruses are easy to fix when the antivirus is root, and the virus is not. Malware is easy to find when it's launching itself from .bashrc and is a normal process.
Now, of course, privilege escalation exploits would, in fact, show up on Linux, and viruses would use them until they were fixed. That can't be stopped. But occasional weaknesses are not the same as Windows constant inability to get it right ever, along with, ironically as they fix that, their dumb new UAC system, which teaches users to allow processes to do whatever they want.
OTOH, Linux systems are still easier to recover from even a system infection, as almost every executable file will be from a known package with a known digital signature, and a boot CD could just download and reinstall all those files that have incorrect signatures, check each document file, and nuke everything else. Windows systems are impossible to repair because you can't verify every file...but you can verify 99% of them on a Linux system, and leave the system mostly intact.
It's irrelevant until you need to fix the problem.
Windows malware, all too often, totally breaks the system, somehow managing to escape from the user account.
I have no idea how this happens, but it does. The entire system gets broken. Antivirus gets broken quickly before definition updates come in. People have system-wide IE problems, and their hosts file is rewritten, and there's a damn ring-zero network driver running.
Linux, however, has actual account separation. Yes, malware could get in, and horrible infect an account, turning the machine into some virus spewing monster.
But it couldn't break the antivirus, which would update and catch the problem. It couldn't some people from booting up as some other user, or even some sort of automated recovery tool that move all files somewhere else and then copies 'known safe' files back to the account, running chmod -x on documents, and general fixing everything. A fricken shell script could get rid of viruses!
Running as normal users on an OS with actual account separation, and users who don't generally type in a root password is not 'safer' in the sense that infection is less likely. It is not less likely.
But it's much better in that you, or even antivirus software, can actually fix infections.
Hell, you could fix the system by installing antivirus after the infection, which is near impossible on Windows.
Oh, and incidentally, rereading 'You are required to turn 'mislaid property' over the owner of the premise it's found on. Aka, the owner of the car.' I am not actually 100% sure that's true.
I'm pretty certain if you find mislaid items in a vehicle, the owner (or operator) of the vehicle is who you need to turn it in to, according to the law. Like if you find a coat draped over the back of a bus seat, you should turn it over to the driver. As opposed to turning it into the state government whose road you're on or convenience store whose parking lot you happen to be in at the time of discovery, which would make no sense.
I am not sure this works for things found on a vehicle, though. If I walk out of a concert and find someone's coat laying on my car, I don't need to take the damn thing with me, the coat owner is hardly going to be able to find me. It should be turned into the property owner. (Or, in practice, just moved out of the way so I can leave.)
So the law may make a distinction there, where only things 'in' vehicles should remain with vehicles, and thing 'on' vehicles should remain with the property owner.
Now, logically, the tracking device was attached to the car, so logically, the place the owners who 'mislaid' it are going to look for it is with the car. Likewise, it logically is 'within' the car's body at least, although not inside the passenger compartment.
However, 'logically' and 'the law' are not always the same thing. The last thing you want to do is get tripped up in some technicality, and believe me the police will try to invent one when they realize you've taken their expensive GPS device and they didn't claim it within the legal deadline and you're refusing to give it back.
So either check the law, or just be sure to discover the device when your car is on your own property, (Why are you looking under your car anywhere else, anyway?) so either way it's you it should be turned in to and you who ends up owning it if the owner does not show up.
Oh, and don't feel too bad if they do show up to get it. It's still pretty damn funny, especially as you have the legal obligation to have them prove ownership before turning it over. Be sure to ask them to describe it, and when they think they mislaid it, and can they describe the car they mislaid it under?