It probably would. Assuming that the company had more of that model of laptop, or that the manufacturer was still making that model with the same internal hardware. But the company doesn't have any spares of that model and the manufacturer doesn't make it anymore, so you can see the obvious problem.
Or worse, said Executive Director stores information on that drive that's relevant to a lawsuit. And when you have to tell the court that you've lost evidence because of this, you end up facing the possibility of losing some points in the case (or even the entire case) as sanction for spoliation of evidence. Even if the evidence would have exonerated your company. We won't even discuss the fun if it's tax- or SEC-related.
Transferring media to new systems. I've already seen a case at work where an encrypted laptop drive was fully intact and working, but the laptop it was in was dead and had to be replaced. The drive was a complete loss, because it couldn't be used as the boot drive in the new laptop (different manufacturer) and there wasn't any software that could be used to supply the boot password to the drive when connected by any other method.
Suspend/hibernate. We've found that a lot of the laptop models where I work don't correctly handle returning from a suspend and/or hibernate state. The most common case is that the laptop simply returns to normal operation from the suspend state without requiring re-entry of passwords. Most users simply put their laptop into suspend state rather than powering it down, which means anyone stealing the laptop can completely ignore the drive encryption. Standard Windows screen locking doesn't help much, once the laptop's unsuspended it's network interface is active and it can be remotely compromised and the screen lock disabled.
Law enforcement. If the drive encryption is truely secure, LEOs will insist on having a back-door to let them decrypt a suspect's drive to search for evidence even if the suspect won't give them the passwords. If such a back-door exists, it'll quickly be broken and software produced to gain access to an encrypted drive through that channel rendering the encryption useless.
#2 can be dealt with going forward in the hardware and OS. #1 can be dealt with going forward with standardized encryption and hardware protocols. #3... is intractable.
I believe Mozilla already implements the IBrowser interface. That's the same API that IE was touted as using back when MS introduced the whole idea of a browser component. All Microsoft has to do is follow their own recommended practices for creating and using IBrowser objects to render HTML pages.
Of course, MS is never going to do that because it'd enable exactly what they touted the IBrowser interface as being good for: letting people transparently replace one Web browser with another.
This sounds like the ability to "remove" IE from Windows XP: it removes the desktop icon and sets the preferred-application setting to not default to IE, but IE remains completely installed, active and used by certain system components.
I'd consider that "waive rights to confidentiality" part completely reasonable. In fact, it should be part of the law right now. The doctor's not allowed to make the patient's confidential treatment information public, but if the patient makes it public the information's no longer confidential and the doctor's not bound to keep it confidential anymore. Though I would limit it to the matters the patient made public, things not related to those remain confidential. So the last part of your response about the gonorrhea would be out of bounds, the rest would be entirely legitimate since the patient brought it up in public first.
Oh, it could certainly store the files. But how's it going to run the P2P software to share them out? These things aren't desktop PCs where you can install any software you want on them, they're embedded systems running out of on-board firmware that can't be updated except by a factory tech (because if the customer could update it they could unlock features they aren't paying for, and we can't have that now can we). Smaller printers like LaserJets are more amenable to being hacked, but they lack the storage. It's like every molecule in the hostess's dress simultaneously jumping 3 feet to the left: theoretically possible, but really reeeeeeally unlikely.
Bear in mind that MediaSentry has accused a laser printer of sharing music files. Not just alleged, stated that they had proof positive of that laser printer serving up MP3s via a P2P network. That alone suggests to me that their "evidence" is shaky at best.
Oppenheim shows up, the judge accepts him as a principal with full authority. If he refuses to settle, the judge holds the plaintiffs to that refusal. He's their principal, he had full authority to do that, they can't back out and settle later. If he settles, the judge holds the plaintiffs to the terms of that settlement. They can't claim Oppenheim didn't have authority, not without stating on the record that they willfully disobeyed the judge's order to send someone with authority. And if he at any point says "I'll have to check with my superiors to see whether I can agree to that or not.", the judge gets to say "I'm sorry, that's not the correct answer." or the legal equivalent. I can see an annoyed judge letting a plaintiff and their attorneys dig themselves into that hole and then not letting them climb back out.
The reason it's hard to grok null-reference-free languages is because "a reference to nothing" is a natural concept. For instance, you want to find an object in a list. What's the result when the object you want isn't in the list? A language that can't express that concept leaves the programmer scratching their head.
The problem I run into's usually two-fold. First, programmers who don't really think about the failure case. They go looking for something, and skip the check for whether they found it. Sometimes it's just that they're lazy, sometimes it's that handling that case will be really hard, and sometimes it's because they've been told what they're looking for has to always exist so the operation can't fail. Second, compilers often treat null references/pointers as valid. Combined with the "initialize everything, always" coding style it yields nasty failures. The compiler doesn't gripe about using uninitialized variables because the variable was initialized, and neither the compiler nor the run-time gripe about using a null reference/pointer because it's considered valid. Solving those problems doesn't involve eliminating the null reference, though.
True, but if it's open-source and you've got the source, it's at least possible. It's up to you whether it's worth the cost to move things forward, put together the neccesary team, throw sufficient money at developers to code for you. But you do get to ask and answer that question for yourself.
With closed-source code, you don't even get to ask the question. If you have the team, if you have the money, if it's worth it for you to take over the project yourself because it's just that critical to your business... YOU CAN'T! You're stuck.
Certainly those software developers who still have jobs will likely spend less time on open-source projects, they'll be spending more of their time picking up the load as their employers lay other developers off and try to get more work from fewer people. But developers who're out of work will have more time to work on their own projects, even allowing for time spent hunting for work. And open-source projects make for good resume fodder: things to fill out a resume and provide code they can show to prospective employers to demonstrate actual ability. And as the economy gets worse, employers are only going to be more interested in candidates who can show actual working code over candidates with only paper qualifications. And open-source will be in more demand by employers who'll be interested in software that can do the same job as their expensive commercial stuff without the high license fees and support and upgrade headaches.
I don't see where there'll be any value lost. I doubt my local paper's web site will stop carrying AP wire stories, nor will CNN or any of the other national news sites. So if the AP doesn't want me viewing those stories through them, it'll make not a bit of difference to me. I don't think this state of affairs is new either, IIRC it's how the AP worked for decades. It's only very recently that they tried to become a news brand in and of themselves, rather than be a supplier to others.
The AP needs to remind itself of a statement JMS made that I think is true. He said, effectively, that the readers/viewers aren't the publisher/network's customers. The advertisers are the customers, the readers/viewers are the product being sold. The content is just the bait needed to keep the product happy and hanging around to be sold, since this product has legs and can walk away any time they choose to.
As far as I'm concerned when it comes to severance, the question of whether I should return money comes down to one question: is the amount paid to me in excess of what the documents I received when I left said I was to be paid? When I leave, I confirm with the company rep that the amount those documents give is accurate and we both sign things off. After that, their miscalculations are No Longer My Problem. They've agreed that's the amount they're to pay me, I expect them to abide by their agreement just as they expect me to abide by mine. If they cut a check for more than the agreement said, they get their money back. If the amount of the check matches the agreement, they can ask all they want but I'm not inclined to change the agreement without getting something in return for the changes.
Consider this: your name, address and who you work for are hardly personal, private information (in most cases, at least). The first two anybody can find by opening the phone book. The last probably isn't instantly available to J. Random Passerby but generally isn't something you keep too private. I'd guess most of your friends know where you work, as does anybody they talk to about you. So I'm personally not too concerned about that information being on places like Facebook, Linkedin and the like. I actually put it up there myself so somebody else doesn't impersonate me or get mistaken for me (or if they do, I can point whoever's making the mistake at my page and point out that their mistake wasn't for my lack of having the correct entry up there).
Now, I'm not going to put details of my personal life up on those sites. It's strictly name, address, current employer, and a pointer to my Web site and resume. More than that, is not those social-networking sites are for as far as I'm concerned.
Users: if you're trusting your data to someone else, you need to insure one of two things. Either you need a signed, iron-clad written contract guaranteeing service with nasty penalty clauses requiring the service to compensate you fully for all the costs of data loss (and sufficient insurance and/or confidence that the service has the wherewithall to pay those penalties and not just flee into bankruptcy leaving you holding the bag anyway), or you need a backup of your data under your own control and in a form where you can upload it to another service if you need to change services. If you don't have one or the other, you will end up being caught in something like this. The only question is when it'll happen. And I can pretty much tell you that no service you can afford will give you the first option. So you'd better evaluate the cost of backing up your data yourself and the costs of losing it and decide which one you're going to pay.
If it were just a power outage, I can see someone thinking that at least the pump control electronics would be on a UPS along with the computers and the pumps should work to some degree (although they'd just give a "Cannot authorize" or other error or would authorize but not actually pump fuel). But after having a tornado hit? Anything related to pumping gas other than "Has someone hit the emergency shutoff switch yet?" ought to be waaaaay far down on the list of things to worry about.
You'll never succeed at this. The Army has a test for officers in one of their advanced programs. The officer is given a mission and has to write out a set of orders for that mission. Those orders are then given to a unit to carry out, with one addition: the soldiers are to do their best to fail to carry out the assigned mission without disobeying those orders (technicalities are perfectly fine as long as no order is actually disobeyed). If the soldiers manage to fail to carry out the mission, the officer fails the test.
I believe this test has a completely unblemished record: no officer has ever managed to pass it.
Sometimes the fault does lie with the person carrying out the instructions. Every set of instructions assumes some minimum level of skill and/or intelligence from the person carrying them out. If you don't think so, remember that even a character-by-character walk-through of logging on assumes that the person knows to turn the computer on first. The instructions on how to turn it on assume that the computer's plugged in or the person knows where the cord and plug are and how to plug them in, and that either the instructions are written for one particular revision of a particular model of computer or the person knows how to find the power switch on an unfamiliar computer. I happen to have personal experience with just how bad it can get. Helpdesk call from one of our midwest truck stops, reporting that their pumps weren't working. It finally got escalated to me as the developer who wrote the pump-control software, since nobody on helpdesk could figure out why the pumps weren't responding. I went through a few basic checks, then told the manager to go out to the pump island, gave him a walk-through of the internal self-test of the pump, and asked him to run the self-test and tell me what codes it reported. His response: "I can't go out there. A tornado came through and tore the islands up, and the main electrical line's laying on the ground out there sparking.". Turns out that, besides the pumps being physically damaged, the power was completely down and the computers were running on UPS batteries. One would think that any reasonable person would've connected a tornado tearing the pumps half off the islands with the pumps suddenly failing to work correctly, but apparently not.
This system isn't working with Caller ID data. It's working with the ACI data used for call accounting and billing, and that's always available to the phone system.
We know them as rules lawyers: the people who try and find convoluted, novel ways to evade the rules without exactly breaking them. Courts are real familiar with them, and over the centuries have developed lots of ways to deal with them. The easiest response to this I see is "Since the cat's acting at your behest, you've authorized them to agree to the contract for you. Since you authorized them, you don't get to argue whether or not they're capable of doing what you authorized.".
To offer a slightly different perspective: If he felt that management was going to misuse the passwords to compromise the security of the network, he was best off sticking to his guns, as it would have come back on him, not management, if the security was compromised. Corruption at the top levels is not unheard-of. It just doesn't sound like that's what happened.
And I'd note further that, when he did give the passwords to city authorities, they followed up by putting a list of account names and their passwords in a public court document for all the world to see. His grounds for refusing to give them the passwords was, IIRC, that they couldn't be trusted to keep those passwords secure, and their first action was to demonstrate that his opinion was in fact entirely correct. One fact that the city keeps omitting is that, although it's technically their network, they were holding him responsible for any failures in it. It's not reasonable to hold someone responsible while simultaneously demanding that they not do what's neccesary to meet those responsibilities.
That depends. Are you still holding me solely responsible for keeping the unit secure, and responsible for anything that happens to the contents? If you are, then no you aren't going to get the keys to make copies to hand out. The only way you get the keys to give to other people outside my control is if you no longer wish me to be responsible for the unit, at which point you get all the keys and all responsibility and I no longer have any access. And you'll sign a paper saying you've accepted the keys and checked them and all copies you gave me are present and accounted for.
No, this isn't a theoretical situation. It's my SOP for turning in keys, access cards and the like when I leave an employer. I follow a similar procedure for passwords: if access hasn't already been disabled, a responsible party (manager or HR rep) will be present as I reset the passwords on my accounts and they will select and enter a new password which I will not know. Either way, there's also a piece of paper listing every account and they'll indicate on it how access was disabled and sign it certifying I no longer have access to those accounts. That all insures I have solid documentation of when my access ended if anything happens after I've left. Part of being a professional is not being made a convenient scapegoat.
NB: there's generally at least one account on my list that the company had forgotten they'd given me access to, leading to inevitable drama and my pulling out the e-mail documenting when they gave me the access.
If you need to enter your password or otherwise elevate privileges that often, your system design's irrevocably broken. On my Linux system I only need to gain root privileges maybe once a week or so. Mostly that's when I'm updating packages or installing new ones, and occasionally when I'm doing something like reconfiguring printers or messing with server configurations. 98% of the software simply doesn't require special privileges once it's been installed properly, and any occurrence of that password-prompt dialog when I wasn't doing one of the very few things that I know will require it triggers an immediate red flag and an automatic press of the "Cancel" button until I've figured out exactly what was doing something it shouldn't've been.
In contrast, you can do very little with UAC active without having to answer a prompt. That constant stream of prompts just trains users to accept them and "just click OK". And that automatic acceptance of the prompt as a normal thing is exactly the cause of so many security issues in Windows.
It's not meant to stop installers from setting the execute bit. They're supposed to do that. It's to stop.desktop files not put in place by an installer (eg. from a saved e-mail attachment) from being treated as executable without additional user intervention.
NB: installers sent as e-mail attachments are already protected this way, when you save them they end up without execute permissions and won't run until the user sets the execute bit manually.
Slashdot Mirror
It probably would. Assuming that the company had more of that model of laptop, or that the manufacturer was still making that model with the same internal hardware. But the company doesn't have any spares of that model and the manufacturer doesn't make it anymore, so you can see the obvious problem.
Or worse, said Executive Director stores information on that drive that's relevant to a lawsuit. And when you have to tell the court that you've lost evidence because of this, you end up facing the possibility of losing some points in the case (or even the entire case) as sanction for spoliation of evidence. Even if the evidence would have exonerated your company. We won't even discuss the fun if it's tax- or SEC-related.
Three problems with the idea:
#2 can be dealt with going forward in the hardware and OS. #1 can be dealt with going forward with standardized encryption and hardware protocols. #3... is intractable.
I believe Mozilla already implements the IBrowser interface. That's the same API that IE was touted as using back when MS introduced the whole idea of a browser component. All Microsoft has to do is follow their own recommended practices for creating and using IBrowser objects to render HTML pages.
Of course, MS is never going to do that because it'd enable exactly what they touted the IBrowser interface as being good for: letting people transparently replace one Web browser with another.
This sounds like the ability to "remove" IE from Windows XP: it removes the desktop icon and sets the preferred-application setting to not default to IE, but IE remains completely installed, active and used by certain system components.
I'd consider that "waive rights to confidentiality" part completely reasonable. In fact, it should be part of the law right now. The doctor's not allowed to make the patient's confidential treatment information public, but if the patient makes it public the information's no longer confidential and the doctor's not bound to keep it confidential anymore. Though I would limit it to the matters the patient made public, things not related to those remain confidential. So the last part of your response about the gonorrhea would be out of bounds, the rest would be entirely legitimate since the patient brought it up in public first.
Oh, it could certainly store the files. But how's it going to run the P2P software to share them out? These things aren't desktop PCs where you can install any software you want on them, they're embedded systems running out of on-board firmware that can't be updated except by a factory tech (because if the customer could update it they could unlock features they aren't paying for, and we can't have that now can we). Smaller printers like LaserJets are more amenable to being hacked, but they lack the storage. It's like every molecule in the hostess's dress simultaneously jumping 3 feet to the left: theoretically possible, but really reeeeeeally unlikely.
Bear in mind that MediaSentry has accused a laser printer of sharing music files. Not just alleged, stated that they had proof positive of that laser printer serving up MP3s via a P2P network. That alone suggests to me that their "evidence" is shaky at best.
Brer Rabbit and the tar baby.
Oppenheim shows up, the judge accepts him as a principal with full authority. If he refuses to settle, the judge holds the plaintiffs to that refusal. He's their principal, he had full authority to do that, they can't back out and settle later. If he settles, the judge holds the plaintiffs to the terms of that settlement. They can't claim Oppenheim didn't have authority, not without stating on the record that they willfully disobeyed the judge's order to send someone with authority. And if he at any point says "I'll have to check with my superiors to see whether I can agree to that or not.", the judge gets to say "I'm sorry, that's not the correct answer." or the legal equivalent. I can see an annoyed judge letting a plaintiff and their attorneys dig themselves into that hole and then not letting them climb back out.
The reason it's hard to grok null-reference-free languages is because "a reference to nothing" is a natural concept. For instance, you want to find an object in a list. What's the result when the object you want isn't in the list? A language that can't express that concept leaves the programmer scratching their head.
The problem I run into's usually two-fold. First, programmers who don't really think about the failure case. They go looking for something, and skip the check for whether they found it. Sometimes it's just that they're lazy, sometimes it's that handling that case will be really hard, and sometimes it's because they've been told what they're looking for has to always exist so the operation can't fail. Second, compilers often treat null references/pointers as valid. Combined with the "initialize everything, always" coding style it yields nasty failures. The compiler doesn't gripe about using uninitialized variables because the variable was initialized, and neither the compiler nor the run-time gripe about using a null reference/pointer because it's considered valid. Solving those problems doesn't involve eliminating the null reference, though.
Go read Cyberbooks by Ben Bova. 20 years ago and he got it pretty right.
True, but if it's open-source and you've got the source, it's at least possible. It's up to you whether it's worth the cost to move things forward, put together the neccesary team, throw sufficient money at developers to code for you. But you do get to ask and answer that question for yourself.
With closed-source code, you don't even get to ask the question. If you have the team, if you have the money, if it's worth it for you to take over the project yourself because it's just that critical to your business... YOU CAN'T! You're stuck.
Which would you rather have?
Certainly those software developers who still have jobs will likely spend less time on open-source projects, they'll be spending more of their time picking up the load as their employers lay other developers off and try to get more work from fewer people. But developers who're out of work will have more time to work on their own projects, even allowing for time spent hunting for work. And open-source projects make for good resume fodder: things to fill out a resume and provide code they can show to prospective employers to demonstrate actual ability. And as the economy gets worse, employers are only going to be more interested in candidates who can show actual working code over candidates with only paper qualifications. And open-source will be in more demand by employers who'll be interested in software that can do the same job as their expensive commercial stuff without the high license fees and support and upgrade headaches.
I don't see where there'll be any value lost. I doubt my local paper's web site will stop carrying AP wire stories, nor will CNN or any of the other national news sites. So if the AP doesn't want me viewing those stories through them, it'll make not a bit of difference to me. I don't think this state of affairs is new either, IIRC it's how the AP worked for decades. It's only very recently that they tried to become a news brand in and of themselves, rather than be a supplier to others.
The AP needs to remind itself of a statement JMS made that I think is true. He said, effectively, that the readers/viewers aren't the publisher/network's customers. The advertisers are the customers, the readers/viewers are the product being sold. The content is just the bait needed to keep the product happy and hanging around to be sold, since this product has legs and can walk away any time they choose to.
As far as I'm concerned when it comes to severance, the question of whether I should return money comes down to one question: is the amount paid to me in excess of what the documents I received when I left said I was to be paid? When I leave, I confirm with the company rep that the amount those documents give is accurate and we both sign things off. After that, their miscalculations are No Longer My Problem. They've agreed that's the amount they're to pay me, I expect them to abide by their agreement just as they expect me to abide by mine. If they cut a check for more than the agreement said, they get their money back. If the amount of the check matches the agreement, they can ask all they want but I'm not inclined to change the agreement without getting something in return for the changes.
Consider this: your name, address and who you work for are hardly personal, private information (in most cases, at least). The first two anybody can find by opening the phone book. The last probably isn't instantly available to J. Random Passerby but generally isn't something you keep too private. I'd guess most of your friends know where you work, as does anybody they talk to about you. So I'm personally not too concerned about that information being on places like Facebook, Linkedin and the like. I actually put it up there myself so somebody else doesn't impersonate me or get mistaken for me (or if they do, I can point whoever's making the mistake at my page and point out that their mistake wasn't for my lack of having the correct entry up there).
Now, I'm not going to put details of my personal life up on those sites. It's strictly name, address, current employer, and a pointer to my Web site and resume. More than that, is not those social-networking sites are for as far as I'm concerned.
Users: if you're trusting your data to someone else, you need to insure one of two things. Either you need a signed, iron-clad written contract guaranteeing service with nasty penalty clauses requiring the service to compensate you fully for all the costs of data loss (and sufficient insurance and/or confidence that the service has the wherewithall to pay those penalties and not just flee into bankruptcy leaving you holding the bag anyway), or you need a backup of your data under your own control and in a form where you can upload it to another service if you need to change services. If you don't have one or the other, you will end up being caught in something like this. The only question is when it'll happen. And I can pretty much tell you that no service you can afford will give you the first option. So you'd better evaluate the cost of backing up your data yourself and the costs of losing it and decide which one you're going to pay.
I restrained myself.
If it were just a power outage, I can see someone thinking that at least the pump control electronics would be on a UPS along with the computers and the pumps should work to some degree (although they'd just give a "Cannot authorize" or other error or would authorize but not actually pump fuel). But after having a tornado hit? Anything related to pumping gas other than "Has someone hit the emergency shutoff switch yet?" ought to be waaaaay far down on the list of things to worry about.
You'll never succeed at this. The Army has a test for officers in one of their advanced programs. The officer is given a mission and has to write out a set of orders for that mission. Those orders are then given to a unit to carry out, with one addition: the soldiers are to do their best to fail to carry out the assigned mission without disobeying those orders (technicalities are perfectly fine as long as no order is actually disobeyed). If the soldiers manage to fail to carry out the mission, the officer fails the test.
I believe this test has a completely unblemished record: no officer has ever managed to pass it.
Sometimes the fault does lie with the person carrying out the instructions. Every set of instructions assumes some minimum level of skill and/or intelligence from the person carrying them out. If you don't think so, remember that even a character-by-character walk-through of logging on assumes that the person knows to turn the computer on first. The instructions on how to turn it on assume that the computer's plugged in or the person knows where the cord and plug are and how to plug them in, and that either the instructions are written for one particular revision of a particular model of computer or the person knows how to find the power switch on an unfamiliar computer. I happen to have personal experience with just how bad it can get. Helpdesk call from one of our midwest truck stops, reporting that their pumps weren't working. It finally got escalated to me as the developer who wrote the pump-control software, since nobody on helpdesk could figure out why the pumps weren't responding. I went through a few basic checks, then told the manager to go out to the pump island, gave him a walk-through of the internal self-test of the pump, and asked him to run the self-test and tell me what codes it reported. His response: "I can't go out there. A tornado came through and tore the islands up, and the main electrical line's laying on the ground out there sparking.". Turns out that, besides the pumps being physically damaged, the power was completely down and the computers were running on UPS batteries. One would think that any reasonable person would've connected a tornado tearing the pumps half off the islands with the pumps suddenly failing to work correctly, but apparently not.
This system isn't working with Caller ID data. It's working with the ACI data used for call accounting and billing, and that's always available to the phone system.
We know them as rules lawyers: the people who try and find convoluted, novel ways to evade the rules without exactly breaking them. Courts are real familiar with them, and over the centuries have developed lots of ways to deal with them. The easiest response to this I see is "Since the cat's acting at your behest, you've authorized them to agree to the contract for you. Since you authorized them, you don't get to argue whether or not they're capable of doing what you authorized.".
To offer a slightly different perspective: If he felt that management was going to misuse the passwords to compromise the security of the network, he was best off sticking to his guns, as it would have come back on him, not management, if the security was compromised. Corruption at the top levels is not unheard-of. It just doesn't sound like that's what happened.
And I'd note further that, when he did give the passwords to city authorities, they followed up by putting a list of account names and their passwords in a public court document for all the world to see. His grounds for refusing to give them the passwords was, IIRC, that they couldn't be trusted to keep those passwords secure, and their first action was to demonstrate that his opinion was in fact entirely correct. One fact that the city keeps omitting is that, although it's technically their network, they were holding him responsible for any failures in it. It's not reasonable to hold someone responsible while simultaneously demanding that they not do what's neccesary to meet those responsibilities.
That depends. Are you still holding me solely responsible for keeping the unit secure, and responsible for anything that happens to the contents? If you are, then no you aren't going to get the keys to make copies to hand out. The only way you get the keys to give to other people outside my control is if you no longer wish me to be responsible for the unit, at which point you get all the keys and all responsibility and I no longer have any access. And you'll sign a paper saying you've accepted the keys and checked them and all copies you gave me are present and accounted for.
No, this isn't a theoretical situation. It's my SOP for turning in keys, access cards and the like when I leave an employer. I follow a similar procedure for passwords: if access hasn't already been disabled, a responsible party (manager or HR rep) will be present as I reset the passwords on my accounts and they will select and enter a new password which I will not know. Either way, there's also a piece of paper listing every account and they'll indicate on it how access was disabled and sign it certifying I no longer have access to those accounts. That all insures I have solid documentation of when my access ended if anything happens after I've left. Part of being a professional is not being made a convenient scapegoat.
NB: there's generally at least one account on my list that the company had forgotten they'd given me access to, leading to inevitable drama and my pulling out the e-mail documenting when they gave me the access.
If you need to enter your password or otherwise elevate privileges that often, your system design's irrevocably broken. On my Linux system I only need to gain root privileges maybe once a week or so. Mostly that's when I'm updating packages or installing new ones, and occasionally when I'm doing something like reconfiguring printers or messing with server configurations. 98% of the software simply doesn't require special privileges once it's been installed properly, and any occurrence of that password-prompt dialog when I wasn't doing one of the very few things that I know will require it triggers an immediate red flag and an automatic press of the "Cancel" button until I've figured out exactly what was doing something it shouldn't've been.
In contrast, you can do very little with UAC active without having to answer a prompt. That constant stream of prompts just trains users to accept them and "just click OK". And that automatic acceptance of the prompt as a normal thing is exactly the cause of so many security issues in Windows.
It's not meant to stop installers from setting the execute bit. They're supposed to do that. It's to stop .desktop files not put in place by an installer (eg. from a saved e-mail attachment) from being treated as executable without additional user intervention.
NB: installers sent as e-mail attachments are already protected this way, when you save them they end up without execute permissions and won't run until the user sets the execute bit manually.