Not quite. I do own that copy of the information the media contains. Well-established in law: if I own a book, I can sell that copy including all the information it contains even if the copyright holder objects. Well-established with CDs too, as Garth Brooks found out when he tried to demand royalties on resale of his CDs and the judge ruled "No.".
Just because you own the copyright doesn't mean you also own every copy you've made and sold too.
No, but it makes me the owner of that CD. When I buy a book I don't own the copyright on the story but I do own that copy of the book. When I buy a car I don't own the trademark on the car or the design or anything but I do own that car. Same thing. And that is exactly the point: I have certain rights regarding what I can do with my property (that specific copy of the CD), and DRM is designed and intended to interfere with those rights to the benefit of a third party who is not the owner of that copy anymore.
The only difference is that locks on cars give the owner of the car control over access and keep people not authorized by the owner out. DRM is about giving the distributor control and keeping the copy owner out. Imagine a car where the locks were under the control not of the car's owner but the dealership, and one of the explicit features of the lock system was the ability to let the dealership lock passengers out of the car unless they'd paid the dealership for the right to ride in that car. That's DRM.
If you think that's wrong, note the recent statement by the RIAA's attorney that if you've bought and paid for a CD and rip it to an MP3 to use on your own personal MP3 player, not giving copies to anyone else or anything, that's illegal and they need to stop it.
Those incompatibilities all affect only combining code under different licenses into a single application and then distributing that application outside the company. That affects really very few companies. The vast majority only use F/OSS, which means the different licenses don't interact with each other at all.
Actually in many cases they do have the right. Even if they don't have any proof. A lot of license agreements include an audit clause, and the typical terms are "any time, at the software vendor's discretion, and you pay all costs regardless of whether any violations are found or not". Your only recourse is to not have any software whatsoever with that kind of term in the license, and to provide the BSA with documentation to support this right up front. Then be prepared to spend several times what they're asking defending yourself in court. Yes you'll probably win. No you probably won't be able to recover any of the cost of winning.
Possibly, but remember that by the BSA's rules it's irrelevant whether you've paid for the software or not. If you got Microsoft Windows XP included on a computer from Dell, have the COA for the installed copy of XP, have an invoice for the computer but don't have a line item on the invoice for Windows XP, you're a pirate and may get included on this list. Ditto for Adobe. Notice how the same software companies show up on the list of "pirated" software, and the majority of them are companies whose software is included bundled with computers from major makers. How many of those settlements are for real piracy, and how many are just for missing records for bundled software that the BSA knows full well was paid for when the computer was bought but it'll cost the company more to prove it than the BSA is asking in settlement?
How about something effective: don't provide information on when domains were last searched for. Without that information, front-runners don't have any idea what domains are potential targets and can't operate. This'd solve the problem without preventing a legitimate buyer from getting the domain they just checked the availability on from anyone other than NSI.
Elaboration on the hardware: yes, technically there were, even back then, off-the-shelf keycode access systems. Emphasis on "access system". The door controllers were relatively smart devices, access codes were pushed out to them by the central control node and the door controllers then handled the actual code authentication and door locking/unlocking on their own. It could take several minutes for new access codes to make their way out to the door controllers, not acceptable when it might be less than 30 seconds from the time a code was created and assigned to a door until the driver was banging on the keypad wanting his shower. And door controllers were relatively expensive per-unit and had to be configured both locally and at the control node before the system would recognize them, a process that needed a trained technician and could take an hour or two.
So we designed our own hardware based around dumb keypads on an RS-485 loop. The wiring loop ended in a D-sub connector in a junction box, the keypad had a pigtail lead with a matching D-sub connector on it. Replacement involved 4 security-head machine screws and a simple "unplug old, plug in new" and Helpdesk could walk an inexperienced maintenance person through it over the phone in 10-15 minutes. Not that we had to do that often, the keypads were incredibly heavy-duty and usually lasted for several years. And in volume they cost a tenth what the off-the-shelf system's door controller modules cost. We had to poll each keypad in turn in our software, but we had plenty of CPU horsepower for that and even with the maximum number of keypads on a loop we could keep our polling cycle to about 1.6 seconds (1.2 seconds maximum given our normal configuration).
Home-brew beats off-the-shelf for cost, reliability and ease-of-use.
Walk into a Flying J and go look at how they handle showers for the truck drivers. Completely automated. Keycode locks on the doors, tickets issued and assigned by the POS system. All started back in 1995 or so. Was a nice win-win bit of coding: revenues and profitability went up by a factor of 5-10, and wait times for customers went down from an average of an hour to "Can you add a delay between selling a shower and assigning that number a stall? The system's calling it out before we've finished ringing up the customer and giving them their receipt.".
And the last time I checked, it looks like they haven't needed to update the code since the last release I did. They've taken advantage of some of the features I built in, but it looks very much like it hasn't needed any changes since the final bug-fix release I did back in '96. That is the way software should be: sits there, does it's job, can be ignored while programmers go on to other things.
True, but when the back-ups are in-house you have a) people immediately available to the VP to start the recovery process and b) physical access to the majority of the back-ups (off-site storage being primarily for disaster-recovery backups and not the main storage for all volumes). He may still be screwed, but he'll see activity. And the one sure-fire way to convince him that your out-sourced solution is worthless is for him to see the appearance of not doing anything.
As far as banks, yes we out-source that. To institutions that are heavily regulated by the government. I don't think there are solutions to the complaints, at least not without similar heavy government regulation. That's because the basic problem behind every one of those is handing off control without being able to hand off responsibility. That's a double-whammy: the out-source provider has no incentive to do anything special for you because he's not going to have to shoulder the responsibility for failure, while you're going to be held fully responsible and accountable but you won't have the ability to do a single blessed thing about any problems. I was taught long ago that if I was ever offered that kind of position, the correct response is to apologize for not being able to accept it and run away as fast as I could. It's not a new problem, it's several thousand years old at least, and if nobody's found a solution to it in all that time I don't see a solution magically presenting itself tomorrow.
Outsourced e-mail: works fine. Until you run into the problem of how to handle messages which you are contractually not allowed to put in the hands of people who aren't under NDA. And your outsourced e-mail provider isn't willing to put every single one of their employees who might have access to the machines your e-mail is on under your NDA, because your account's just not worth the cost of doing that for hundreds of different NDAs (remember how many different customers they have).
Outsourced file storage and sharing: same problems, but on a much much larger scale. There's also the question of the network connectivity and bandwidth needed to insure 100% reliable access to that data at the same speeds as access to in-house storage.
Outsourced backups: see above. Also, the train wreck when the first senior VP comes along with a file he deleted a while ago and absolutely needs recovered today. No, he's not sure what the exact file name was, and he's not sure which folder it was in. And he's not sure when he deleted it, he had it late last month and he just noticed it gone today. But he's got to have it by 5pm today.
I worked at a truck-stop company (Flying J) working on their point-of-sale system. Which, trust me, covers a multitude more sins than you'd care to imagine. This exchange pretty much sums up why IT in a place like that won't go away:
CEO: "So why can't we just buy off-the-shelf software to do that?" Me: "Because there is no off-the-shelf software that does that. And by the time it's common enough that you can buy it off the shelf, we've had it in production and solid for 5 years."
Example: RFID for transactions. Flying J was starting to do this back in 2000 for the big-rig side of the station. Grab nozzle, fuel, hang up nozzle, take receipt. That was 8 years ago, and you still can't find off-the-shelf systems that do this, let alone that integrate directly into the rest of the POS system.
The GPL doesn't give you that option, copyright law gives you that option. No matter how deep the copyright holder's pockets, they can't ask for what copyright law doesn't give them as a remedy. They can ask for an injunction barring you from distributing their code, they can ask for damages. They can ask that the copies you made, and any equipment used to make them, be seized and forfeited. They can ask for criminal penalties. But nowhere in USC Title 17 Chapter 5 outlining the remedies allowed under copyright law will you find "force the violator to publish their work".
Actually it'd be "You have to release the source code for your product or cease distributing the GPL'd code.". Note that that second is always an option when dealing with the GPL. And if you can document that you got the code from an Apache-licensed codebase, you have a pretty solid good-faith defense there as long as you complied with the terms of the Apache license. The worst that you'll face is having to remove the GPL'd code and replace it with something else, or possibly seeing if the author's willing to take royalty payments in exchange for a more acceptable license.
Note that in this case you shouldn't be looking at which project had the code first, you should be looking at who checked the code in to the Apache-licensed project and what license terms would apply to that check-in. If one of the original authors checked it in to the Apache-licensed project and that project only accepts code under the Apache license, then you can rely on the Apache license terms regardless of whether the code's also licensed under the GPL. If it was checked in by someone other than an original author, or if the project accepts code under compatible licenses, more research will be needed.
Pretty much. If I give someone my unlisted phone number, they can tell anyone else they want about it. I can tell them not to do it all I want, but they've got the physical ability to do it and nothing I can do can stop them if they choose to do it (or even if they just get gullible or careless). So I'm very careful about who I give that kind of information to and how far I can trust them when they promise not to give it out.
One problem with Macafee's contention that the GPL hasn't been tested in court is that it's wrong. Slashdot reported not long ago about Verizon being sued over GPL violations, and they're just the latest in a long line of companies that when faced with the choice between complying with the GPL and being taken to court have settled with the copyright holders. The fact that so far every company faced with the choice has elected to settle and release the source code as required says much about the strength of the GPL. Companies only go to court when they think the license is weak or questionable enough that they've a reasonable chance of winning. So far, every violator seems to have been told by their lawyers "If they take you into court, you will lose. Settle now.". As a creator I'd rather go with a license that strong than one where the violator's lawyers think it's weak enough they've a chance of arguing their case in front of a judge and winning.
Also, since the GPL is a copyright license and not a contract, any suit against a violator won't be for violation of the GPL. It'll be for violation of copyright law (making and distributing copies without a license to do so from the copyright holder). The GPL, if anything, will be a defense raised by the violator in an attempt to show that they do indeed have a license to distribute copies.
And finally, Macafee's not worried that the terms of the GPL are ambiguous. They're worried that the terms aren't ambiguous, and that if someone catches them using GPL'd code they stand no chance of getting away with it if push comes to legal shove.
This isn't a question of who owns the data. Scoble owns the data. It's a question of who controls access to the servers the data's stored on and the services used by the owner to retrieve the data. Scoble doesn't control those, Facebook does. And he's just found out the downside of that. Lesson: don't place your only copy of critical information under the sole control of someone else.
Agreed. Banning spaces in the realm would violate the RFCs and make descriptive realms (eg. "Google Checkout") less feasible. I simply remember that the authentication dialog format isn't under the control of the site, which means that the URL at the end is the URL (technically a prefix) the username and password will be used by. If I see something like his example that appears to imply otherwise, it means the site's trying to play games and I should ignore the implication and trust my browser: the URL at the end is the URL of the site, it's got "at" just before it, and everything from that "at" back to "password for" is the realm specified.
A better presentation would be two lines: Realm: realm string URL: url prefix string
That'd make it impossible to confuse the two.
It's only unencrypted if you're doing Basic authentication. HTTP also defines Digest authentication, in which the password is never sent at all, only a digest to prove to the server that the client knows the password.
Makes address allocation a lot simpler. Most of this comes from the expanded address space having a lot more blocks available for allocation without having to play games with the bits.
Allows the address sub-netting hierarchy to mirror the physical routing structure. This makes the routing tables smaller and simpler, which makes life easier for the routers.
Address prefix independence. Fancy term for not having to reconfigure all your machines just because you've moved to a new netblock. This is part and parcel of the previous item, actually.
Things like IPSec were designed into the protocol from the start, rather than being bolted on afterwards as they were for IPv4. Makes VPNs and such a lot easier to configure and get running. The packet headers were also redesigned based on experience with IPv4, so routers have an easier time handling them and don't have to work so hard to do common things.
Disney wouldn't lose ownership of Mickey Mouse. Mickey's distinctive likeness is under trademark, completely different area of law. What they'd lose is copyright on a single very old cartoon "Steamboat Willy" which was the first appearance of a rat that'd eventually morph into Mickey years later. And Disney knows this. Their use of the "We'd lost ownership of Mickey." argument is a smokescreen. What they really want is simple: a one-way door. They want to be able to use older works (Beauty and the Beast, The Little Mermaid, Treasure Island, etc.) as the basis for their works without any strings attached, but they don't want anybody using their works the same way without paying them handsomely for the privilege. That, after all, maximizes profits (for them, at least).
If the malware can place a binary named "su" in a directory that's in your $PATH before the directory containing the real su program, then yes it can. Of course there's several ways to prevent that from working. The most convenient one in a GUI environment is to use a "root console" icon that doesn't use su but a special SUID wrapper program located in a system directory and uses absolute paths for the executables involved so that $PATH-variable poisoning can't affect which binaries get run. Another one is to place any home-directory-tree additions at the tail end of $PATH so system binaries can't be overridden without changing $PATH in your current environment (alterations in a running program's environment don't propagate back up to the shell's environment, which makes it very difficult for any program other than your shell itself to change your shell's working $PATH).
Note that even if su gets hijacked, you'll notice because either you'll be prompted for the password a second time or you won't get root privileges. And the root password is in general not useful to an outsider. Programs like su that prompt for the root password do their input through the terminal, not through the standard input/output streams, making it very difficult for the malware to stuff the password into the input programmatically, and almost all remote-access services in Unix won't allow root to connect remotely even with the correct password (note that "remotely" in this case includes connections to the machine's own IP addresses including 127.0.0.1).
None of this is accident. The "plant a password-stealing binary somewhere in your victim's $PATH using the same name as a program he regularly uses" trick is ancient, at least 30-35 years old on Unix, and Steps Were Taken after the first spate of pranks based on it.
I'm minded of another line from the same show, by a Mr. A. Bester. It went roughly like this:
"Did you really think I'd just sit back and let a group of evil aliens walk in and enslave Earth? That's my job.". I see certain parallels between China and Bester here.
Won't work. The package manager is running as root, the polling program looking to fake the dialog will be running as your regular user account. Trying to SIGSTOP (or send any other signal to) a process running as a different user will get anyone but root an EPERM error. Likewise trying to use the X facilities to kill the window: you don't have permission to do that to some other user's windows.
This is where the Unix heritage shows compared to the Windows heritage. Windows grew up as a single-user OS, everything running on the box belonged to the same person. Unix grew up with multiple users always logged in, and the requirement from day 1 that it prevent them from messing with each other.
Worse, Google's TOS do not as far as I can tell relieve you of discovery obligations. So if you're sued and Google shuts down or purges your messages after that point, you're still on the hook to produce them. You can't even argue that it wasn't your fault, since you could reasonable have foreseen this (it's right there in the TOS you agreed to) and you failed to take reasonable steps (eg. making your own copies of your messages) to prevent the destruction.
Note that this isn't specific to Google, it's a generic problem when you outsource handling of data or allow anyone outside the company to have control over it's existence. You remember all those corporate e-mail systems that purport to use DRM to allow you to exercise control over what the recipient can do and how long they can keep the message? Turn that around and think about what happens when someone else uses that to time-expire a message that you've a legal obligation to retain.
Slashdot Mirror
Not quite. I do own that copy of the information the media contains. Well-established in law: if I own a book, I can sell that copy including all the information it contains even if the copyright holder objects. Well-established with CDs too, as Garth Brooks found out when he tried to demand royalties on resale of his CDs and the judge ruled "No.".
Just because you own the copyright doesn't mean you also own every copy you've made and sold too.
No, but it makes me the owner of that CD. When I buy a book I don't own the copyright on the story but I do own that copy of the book. When I buy a car I don't own the trademark on the car or the design or anything but I do own that car. Same thing. And that is exactly the point: I have certain rights regarding what I can do with my property (that specific copy of the CD), and DRM is designed and intended to interfere with those rights to the benefit of a third party who is not the owner of that copy anymore.
The only difference is that locks on cars give the owner of the car control over access and keep people not authorized by the owner out. DRM is about giving the distributor control and keeping the copy owner out. Imagine a car where the locks were under the control not of the car's owner but the dealership, and one of the explicit features of the lock system was the ability to let the dealership lock passengers out of the car unless they'd paid the dealership for the right to ride in that car. That's DRM.
If you think that's wrong, note the recent statement by the RIAA's attorney that if you've bought and paid for a CD and rip it to an MP3 to use on your own personal MP3 player, not giving copies to anyone else or anything, that's illegal and they need to stop it.
Those incompatibilities all affect only combining code under different licenses into a single application and then distributing that application outside the company. That affects really very few companies. The vast majority only use F/OSS, which means the different licenses don't interact with each other at all.
Actually in many cases they do have the right. Even if they don't have any proof. A lot of license agreements include an audit clause, and the typical terms are "any time, at the software vendor's discretion, and you pay all costs regardless of whether any violations are found or not". Your only recourse is to not have any software whatsoever with that kind of term in the license, and to provide the BSA with documentation to support this right up front. Then be prepared to spend several times what they're asking defending yourself in court. Yes you'll probably win. No you probably won't be able to recover any of the cost of winning.
Possibly, but remember that by the BSA's rules it's irrelevant whether you've paid for the software or not. If you got Microsoft Windows XP included on a computer from Dell, have the COA for the installed copy of XP, have an invoice for the computer but don't have a line item on the invoice for Windows XP, you're a pirate and may get included on this list. Ditto for Adobe. Notice how the same software companies show up on the list of "pirated" software, and the majority of them are companies whose software is included bundled with computers from major makers. How many of those settlements are for real piracy, and how many are just for missing records for bundled software that the BSA knows full well was paid for when the computer was bought but it'll cost the company more to prove it than the BSA is asking in settlement?
How about something effective: don't provide information on when domains were last searched for. Without that information, front-runners don't have any idea what domains are potential targets and can't operate. This'd solve the problem without preventing a legitimate buyer from getting the domain they just checked the availability on from anyone other than NSI.
Elaboration on the hardware: yes, technically there were, even back then, off-the-shelf keycode access systems. Emphasis on "access system". The door controllers were relatively smart devices, access codes were pushed out to them by the central control node and the door controllers then handled the actual code authentication and door locking/unlocking on their own. It could take several minutes for new access codes to make their way out to the door controllers, not acceptable when it might be less than 30 seconds from the time a code was created and assigned to a door until the driver was banging on the keypad wanting his shower. And door controllers were relatively expensive per-unit and had to be configured both locally and at the control node before the system would recognize them, a process that needed a trained technician and could take an hour or two.
So we designed our own hardware based around dumb keypads on an RS-485 loop. The wiring loop ended in a D-sub connector in a junction box, the keypad had a pigtail lead with a matching D-sub connector on it. Replacement involved 4 security-head machine screws and a simple "unplug old, plug in new" and Helpdesk could walk an inexperienced maintenance person through it over the phone in 10-15 minutes. Not that we had to do that often, the keypads were incredibly heavy-duty and usually lasted for several years. And in volume they cost a tenth what the off-the-shelf system's door controller modules cost. We had to poll each keypad in turn in our software, but we had plenty of CPU horsepower for that and even with the maximum number of keypads on a loop we could keep our polling cycle to about 1.6 seconds (1.2 seconds maximum given our normal configuration).
Home-brew beats off-the-shelf for cost, reliability and ease-of-use.
Walk into a Flying J and go look at how they handle showers for the truck drivers. Completely automated. Keycode locks on the doors, tickets issued and assigned by the POS system. All started back in 1995 or so. Was a nice win-win bit of coding: revenues and profitability went up by a factor of 5-10, and wait times for customers went down from an average of an hour to "Can you add a delay between selling a shower and assigning that number a stall? The system's calling it out before we've finished ringing up the customer and giving them their receipt.".
And the last time I checked, it looks like they haven't needed to update the code since the last release I did. They've taken advantage of some of the features I built in, but it looks very much like it hasn't needed any changes since the final bug-fix release I did back in '96. That is the way software should be: sits there, does it's job, can be ignored while programmers go on to other things.
True, but when the back-ups are in-house you have a) people immediately available to the VP to start the recovery process and b) physical access to the majority of the back-ups (off-site storage being primarily for disaster-recovery backups and not the main storage for all volumes). He may still be screwed, but he'll see activity. And the one sure-fire way to convince him that your out-sourced solution is worthless is for him to see the appearance of not doing anything.
As far as banks, yes we out-source that. To institutions that are heavily regulated by the government. I don't think there are solutions to the complaints, at least not without similar heavy government regulation. That's because the basic problem behind every one of those is handing off control without being able to hand off responsibility. That's a double-whammy: the out-source provider has no incentive to do anything special for you because he's not going to have to shoulder the responsibility for failure, while you're going to be held fully responsible and accountable but you won't have the ability to do a single blessed thing about any problems. I was taught long ago that if I was ever offered that kind of position, the correct response is to apologize for not being able to accept it and run away as fast as I could. It's not a new problem, it's several thousand years old at least, and if nobody's found a solution to it in all that time I don't see a solution magically presenting itself tomorrow.
Except that then you run into some problems:
I worked at a truck-stop company (Flying J) working on their point-of-sale system. Which, trust me, covers a multitude more sins than you'd care to imagine. This exchange pretty much sums up why IT in a place like that won't go away:
CEO: "So why can't we just buy off-the-shelf software to do that?"
Me: "Because there is no off-the-shelf software that does that. And by the time it's common enough that you can buy it off the shelf, we've had it in production and solid for 5 years."
Example: RFID for transactions. Flying J was starting to do this back in 2000 for the big-rig side of the station. Grab nozzle, fuel, hang up nozzle, take receipt. That was 8 years ago, and you still can't find off-the-shelf systems that do this, let alone that integrate directly into the rest of the POS system.
The GPL doesn't give you that option, copyright law gives you that option. No matter how deep the copyright holder's pockets, they can't ask for what copyright law doesn't give them as a remedy. They can ask for an injunction barring you from distributing their code, they can ask for damages. They can ask that the copies you made, and any equipment used to make them, be seized and forfeited. They can ask for criminal penalties. But nowhere in USC Title 17 Chapter 5 outlining the remedies allowed under copyright law will you find "force the violator to publish their work".
Actually it'd be "You have to release the source code for your product or cease distributing the GPL'd code.". Note that that second is always an option when dealing with the GPL. And if you can document that you got the code from an Apache-licensed codebase, you have a pretty solid good-faith defense there as long as you complied with the terms of the Apache license. The worst that you'll face is having to remove the GPL'd code and replace it with something else, or possibly seeing if the author's willing to take royalty payments in exchange for a more acceptable license.
Note that in this case you shouldn't be looking at which project had the code first, you should be looking at who checked the code in to the Apache-licensed project and what license terms would apply to that check-in. If one of the original authors checked it in to the Apache-licensed project and that project only accepts code under the Apache license, then you can rely on the Apache license terms regardless of whether the code's also licensed under the GPL. If it was checked in by someone other than an original author, or if the project accepts code under compatible licenses, more research will be needed.
Pretty much. If I give someone my unlisted phone number, they can tell anyone else they want about it. I can tell them not to do it all I want, but they've got the physical ability to do it and nothing I can do can stop them if they choose to do it (or even if they just get gullible or careless). So I'm very careful about who I give that kind of information to and how far I can trust them when they promise not to give it out.
One problem with Macafee's contention that the GPL hasn't been tested in court is that it's wrong. Slashdot reported not long ago about Verizon being sued over GPL violations, and they're just the latest in a long line of companies that when faced with the choice between complying with the GPL and being taken to court have settled with the copyright holders. The fact that so far every company faced with the choice has elected to settle and release the source code as required says much about the strength of the GPL. Companies only go to court when they think the license is weak or questionable enough that they've a reasonable chance of winning. So far, every violator seems to have been told by their lawyers "If they take you into court, you will lose. Settle now.". As a creator I'd rather go with a license that strong than one where the violator's lawyers think it's weak enough they've a chance of arguing their case in front of a judge and winning.
Also, since the GPL is a copyright license and not a contract, any suit against a violator won't be for violation of the GPL. It'll be for violation of copyright law (making and distributing copies without a license to do so from the copyright holder). The GPL, if anything, will be a defense raised by the violator in an attempt to show that they do indeed have a license to distribute copies.
And finally, Macafee's not worried that the terms of the GPL are ambiguous. They're worried that the terms aren't ambiguous, and that if someone catches them using GPL'd code they stand no chance of getting away with it if push comes to legal shove.
This isn't a question of who owns the data. Scoble owns the data. It's a question of who controls access to the servers the data's stored on and the services used by the owner to retrieve the data. Scoble doesn't control those, Facebook does. And he's just found out the downside of that. Lesson: don't place your only copy of critical information under the sole control of someone else.
Agreed. Banning spaces in the realm would violate the RFCs and make descriptive realms (eg. "Google Checkout") less feasible. I simply remember that the authentication dialog format isn't under the control of the site, which means that the URL at the end is the URL (technically a prefix) the username and password will be used by. If I see something like his example that appears to imply otherwise, it means the site's trying to play games and I should ignore the implication and trust my browser: the URL at the end is the URL of the site, it's got "at" just before it, and everything from that "at" back to "password for" is the realm specified.
A better presentation would be two lines:
Realm: realm string
URL: url prefix string
That'd make it impossible to confuse the two.
It's only unencrypted if you're doing Basic authentication. HTTP also defines Digest authentication, in which the password is never sent at all, only a digest to prove to the server that the client knows the password.
Disney wouldn't lose ownership of Mickey Mouse. Mickey's distinctive likeness is under trademark, completely different area of law. What they'd lose is copyright on a single very old cartoon "Steamboat Willy" which was the first appearance of a rat that'd eventually morph into Mickey years later. And Disney knows this. Their use of the "We'd lost ownership of Mickey." argument is a smokescreen. What they really want is simple: a one-way door. They want to be able to use older works (Beauty and the Beast, The Little Mermaid, Treasure Island, etc.) as the basis for their works without any strings attached, but they don't want anybody using their works the same way without paying them handsomely for the privilege. That, after all, maximizes profits (for them, at least).
If the malware can place a binary named "su" in a directory that's in your $PATH before the directory containing the real su program, then yes it can. Of course there's several ways to prevent that from working. The most convenient one in a GUI environment is to use a "root console" icon that doesn't use su but a special SUID wrapper program located in a system directory and uses absolute paths for the executables involved so that $PATH-variable poisoning can't affect which binaries get run. Another one is to place any home-directory-tree additions at the tail end of $PATH so system binaries can't be overridden without changing $PATH in your current environment (alterations in a running program's environment don't propagate back up to the shell's environment, which makes it very difficult for any program other than your shell itself to change your shell's working $PATH).
Note that even if su gets hijacked, you'll notice because either you'll be prompted for the password a second time or you won't get root privileges. And the root password is in general not useful to an outsider. Programs like su that prompt for the root password do their input through the terminal, not through the standard input/output streams, making it very difficult for the malware to stuff the password into the input programmatically, and almost all remote-access services in Unix won't allow root to connect remotely even with the correct password (note that "remotely" in this case includes connections to the machine's own IP addresses including 127.0.0.1).
None of this is accident. The "plant a password-stealing binary somewhere in your victim's $PATH using the same name as a program he regularly uses" trick is ancient, at least 30-35 years old on Unix, and Steps Were Taken after the first spate of pranks based on it.
I'm minded of another line from the same show, by a Mr. A. Bester. It went roughly like this:
"Did you really think I'd just sit back and let a group of evil aliens walk in and enslave Earth? That's my job.". I see certain parallels between China and Bester here.
Won't work. The package manager is running as root, the polling program looking to fake the dialog will be running as your regular user account. Trying to SIGSTOP (or send any other signal to) a process running as a different user will get anyone but root an EPERM error. Likewise trying to use the X facilities to kill the window: you don't have permission to do that to some other user's windows.
This is where the Unix heritage shows compared to the Windows heritage. Windows grew up as a single-user OS, everything running on the box belonged to the same person. Unix grew up with multiple users always logged in, and the requirement from day 1 that it prevent them from messing with each other.
Worse, Google's TOS do not as far as I can tell relieve you of discovery obligations. So if you're sued and Google shuts down or purges your messages after that point, you're still on the hook to produce them. You can't even argue that it wasn't your fault, since you could reasonable have foreseen this (it's right there in the TOS you agreed to) and you failed to take reasonable steps (eg. making your own copies of your messages) to prevent the destruction.
Note that this isn't specific to Google, it's a generic problem when you outsource handling of data or allow anyone outside the company to have control over it's existence. You remember all those corporate e-mail systems that purport to use DRM to allow you to exercise control over what the recipient can do and how long they can keep the message? Turn that around and think about what happens when someone else uses that to time-expire a message that you've a legal obligation to retain.