Isn't this akin to the DEA informing a grocery store that they can't have a parking lot, because a lot of drug deals are taking place there at night?
No... at least the DEA is part of the government.
This is akin to the MADD threatening real estate developers that they cannot offer land for sale on a street named "Bar Street", without addressing certain concerns, or they will escalate (probably to a zoning authority), because there is a chance that some business developers might have bars built on the street, some of the bars built might have alcohol available for sale, there is a chance that some tenants of those bars could go there and be encouraged to imbibe, and some of them might try to take their alcohol with them on the road.
Slashdot users debunk this scheme as stupid in 5... 4... 3...
Cmd+Apple+Shift+3 / Cmd +Apple+Shift+4 / Alt+PrtScrn / PrtScrn / Evernote clip rectangle or Window / Screenshotting tool of choice.
Alternatively... hook DVI out cable of computer to frame grabber... view image, push snapshot button.
Alternatively.... reverse engineer plugin, develop new plugin that requests the key, saves the image, and uploads it to a competing "image server" where the image will never expire; optionally posts link in reply to anyone using the 'expiring images' service.
On the internet? That would be like the US government trying to charge for a breath of fresh air.
Oh wait...
[*] Alternative scenario 1:
Porn? Sorry... that's an un-word. Unclothed pics are outlawwed. Unclothed pics have always been outlawwed. [See 1984/Apple-style censorship... porn is disallowed; it simply does not exist.]
[*] Alternative scenario 2:
Without porn, there would be only a small number of comcast subscribers. What is the number one thing people connect to the internet to do? Hint: it's not to watch sports
For such a "senior" developer, they should really grow up and learn that just being older or being a dev there for longer
is no guarantee of success, prestige, or more money. Wishful thinking at best... in an ideal world, where everything goes your way,
your pay goes up and up and up. If you don't keep up with the latest fancy tech, it goes down and down and down (in real terms).
(That is: anything less than annual 15% increase is going down in real terms, due to inflation -- same number of dollars earned per time = fewer things you can do with them.)
The only advantage age has given them is they could study the newest technologies full time, since they did not have a job to do.
Otherwise, they are at a disadvantage, probably fewer resources saved up, less on-the-job experience.
As a senior developer, you learned less about new stuff; it's a calculated tradeoff -- the more time you are working for an employer,
the less time it is possible for you to spend studying and learning new things about a continuously changing field.
The only thing that was certain was you gained experience, probably in the old technology.
Experience that is useless unless it helps you adapt and continue to perform well, or makes you good at guiding others and making longer term viable recommendations.
E.g. management material
If the younger person has more experience with a technology the company needs, then yes, his experience might have a higher market value, sometimes sufficient to outweigh seniority.
If that is the case, the senior dev should plan to drop everything and learn the hot new technology, or attempt to graduate from senior dev to management, assuming highest possible pay is what is wanted.
Gain the knowledge the younger dev has, OR become his manager, and then complain or make an offer to do more/different work if you are not compensated commesurately.
No whining to project managers about a "newb" getting more pay, without making yourself more valuable; trying to get more pay for value you don't deliver is a road towards being officially declared obsolete.
I'm not so sure even that will do it... do you have any idea how many dating site domain names
Gotham dating partners runs?
I suppose the more branded dating sites the more signups they'll get... hell, tomorrow they could have a million typo domains as separate "dating sites"
I suppose it's possible they all share one database, and if you register/ delete/opt out of one you opt out of them all.
The cynic in me suggests if you register and provide additional information, the additional info will show up in them all together with your public records info.
And that if you want to delete/opt-out, you'll have to manually delete from each site as it was completely different.
And they could add more web properties in the future that you'll have to opt out of separately
When hundreds of thousands (literally) cross every year, we don't need sensors on the border. Just stand there and some are sure to cross your path.
Yeah.... any sensor network needs to be augmented with physical methods, such as Nethack-style sleeping gas traps, Foothold traps, and fluidizing solid mantraps.
People who bring their own tools are called contractors, not employees.
Execellent cost saving idea... let the employees all bring their own phones, computers, and office supplies, but reclassify them all as contractors.
1099 instead of W-2. No social security paid by the company for the compensation (contractor gets to pay twice). No unemployment fees, overtime, wages, etc to worry about, since contractors don't get those.
Instead employees now contractors get "bi-weekly advance based on portion of the work completed"; they get to pay for their own training, insurance, and since everything's a contract, instead of annual performance reviews, annual contract renewals, no demands for more $$$ on either side until contract renewal, AND no negative connotations associated with negotiating a lower price for the work.
Anything I can think of is 100% lethal if something else doesn't kill the animal first.
Yep... even water. Come to think of it... 100% of animals that were alive and then died ingested some water during their lifetime. This makes water some pretty dangerous stuff.
I suppose the computer equivalent to throwing prions into the air is pointing a fan at a fully powered up computer with open case running full blast, and dumping a 5 pound bag of copper and iron filings across the path of the fan, so they go everywhere.
I disagree, though not for Windows. On Linux, it's pretty common practice to install software locally to a user. For example I have a newer version of Python installed on my webserver than the stock, and it's just in my home directory.
You might not favor the practice for your own reasons, you may even have extenuating circumstances that indicate the practice should not be undertaken.
It is best common practice to have separate filesystems for various labels, and among them/home,/var, and/tmp.
It is best common practice for/home/var/tmp and similar filesystems to be mounted noexec and nosuid.
If users are to be authorized to install software, that might be a justifiable
reason to provide them access to a filesystem that's not noexec.
However, on other large unix systems where users are only expected to run software installed by a sysadmin (small allowance of disk space, etc), the ability to execute programs presents huge unnecessary risks.
given that NTFS does not allow unlinking an exectuable when it is running, having it in %AppData% for the time being is the next best option.
No.. a next best option is versioning the program executable. Possibly launching the current version (real executable) from a "stub"/launcher executable that rarely/never changes.
Wait, so if I instruct chrome to download an application, it shouldn't go in $USER/Downloads because executables aren't suppose to be in data folders?
It is expected to be saved in Downloads like other downloads, but not to be executable from a data directory.
In fact, how the heck is any updater supposed to work in this case?
By downloading the file and telling the user they need to run it.
Or by allowing the user to specify a working directory that should be used for deploying the updates, rather than just assuming that their roaming profile directory is an OKAY place to stash program files.
Even Firefox downloads an executable to %appdata%\Temp\ and then launches the process.
Then Firefox's updater is broken, if it did not prompt the user to choose this path as working directory for update deployment.
What you've described isn't best common practice, it's slavish attention to distinctions that are made for the sake of convenience
Actually, it is enforcement of distinctions, that when not made create an unnecessary risk.
What's more, given that placing roadblocks to updating causes a huge decrease in user compliance, it's not even clear that such draconian measures even improve security. Having those 16 browser vulnerabilities patched as promptly as possible is far more important than adhering to whatever practices seem best in the abstract.
Actually: it is not clear that it is better to have those 16 security patches, than it is to have a strategy to mitigate the risk at a lower level.
It just takes ONE security vulnerability to result in compromise; nobody can really ever update fast enough to never be vulnerable.
Some of the most widely exploited vulnerabilities were 0day and widely exploited before a patch was available.
Sufficiently thorough mitigation methods can mean that instead of being exploited by the 1 security vulnerability that you haven't patched yet, the vulnerability IS exploited, but the isolation / code execution prevention technique reduces the damage and compromise done by the exploit to (essentially) zero.
Then I guess I should have phrased the question as follows: What is the procedure for a user to request authorization to install a given piece of software?
Well, that will depend on who owns the system and who they want installing things on their computer.
For enterprises, that will generally include the system administrators, and people who have been trained and shown competence/understanding in the company's security policies and any special compliance requirements to make a decision to accept a user's request to install something, and in some cases, that might require business management involvement.
The procedure will probably depend on whether the software came from, and if the company purchased it, or if this is some freebie download of limited value as far as the company is concerned.
For homes, someone or some people will make decisions about what software to be installed; when those who own the machine agree, or agree on the requirements/criteria prior to running a program, and those requirements are followed, then install gets authorized.
That's a question of not only security, but also consumption of shared resources (especially for resident background applications/system tray apps that all users will have to put up with); then there are network resources, which apps such as BitTorrent can chew up.
For third parties using a machine someone else owns, it's up to the owner to specify the conditions, and whether/not they will authorize introducing or updating software; to make a rational decision they have to be informed of any negative side effects to them -- benefits to other people are most likely secondary.
In home environments at least, the 'install directory' may be just open to all users. This still provides a security benefit, and is what I would normally do, however, in that you can be sure explicit action will be required to run an installer program.
In an enterprise environment, the 'install directory' might be read-only to all users except admins and power users who have adequate training and familiarity with the security policies.
It's soft security, because anyone who knows what subdirectory to put the the file under can still run programs.
But all software restriction policies based on this method are soft security; someone with physical access can use a boot CD and run any program they want (even against policy).
So software restriction is just a second line of defense (after user avoidance of downloading harmful software), really.
Many malware programs are introduced through accidental downloads or accidental program execution, when the user did not even intend to install anything. So when specific deliberate action is required, mistakes are less likely.
Safety nets are useful.
No e-mailed virus is going to tell you "OK, right click the attachment; click save"
Now open explorer, copy that file C:\FAMILYNAMEHERE\CustomPrograms\InstallerFiles
Press F2, rename x.zip to x.exe, now double click, and you will see the instructions to receive your million $$.
Realistically, the only way software restriction will be defeated on a workstation is (1) intentional actor with legitimate login access or (2) vulnerability in e-mail or browser allowing exploit code to run malicious payload inside the application software; however, developing a malicious payload able to defeat policy and deploy software once the browser has been closed [across user sessions] could be quite a challenge.
Software restrict is a non-default config, so most malware (targetting naive users in unmanaged environmens) will not be taylored for that.
Also, the vast majority of malware relies on user error (which setting defaults do not mitigate), or exploits that simply will not work if programs in the browser/Adobe downloads/cache file directories cannot be executed.
Then what is the procedure for a user to request that a program's installer be placed into one of these "designated paths for placing executables in manually"?
Assuming the user is authorized to install software, they open explorer, navigate to the file they downloaded (or their USB drive/external media), CUT/COPY the File, navigate to the installation files directory, and PASTE the file, then run the file.
Is that updates take place silently and promptly without any user intervention even on systems with UAC activated (a copy is installed to %appdata%).
Hm.. that idea wouldn't work on any systems I setup.
Software restriction policy all systems, Policy default: deny.
Programs can be executed from the default allowed directories.
%programfiles% , %systemroot%\system32, etc,
and some designated paths for placing executables in manually, in order to install them.
User profile directories including appdata are specifically excluded, because this is best common practice. Programs/executables don't belong in any user's profile or appdata folder (Especially not in any folder used as a default download directory for saving files or temporary directory used by a mail application for opening attachments in a viewer). Contents of appdata is a data folder, and all of a user's profile are data folders, not program folders.
I like your style. Perhaps as a Facebook display picture in hopes of getting some "likes" from potential femina mates
I am afraid Google would run into the same problems Knuth and others did.
When people post images of checks online, various scammers, the scum of the internet, find images of the checks online, make fake checks, or initiate fraudulent ACH transactions.... result: the account has to be closed.
Remember folks... checks are legal instruments and contain confidential bank account numbers printed on them, which (due to our insecure banking system) can easily be abused by scammers to steal lots of money. Never post an image for public consumption of a check someone else wrote to you.
1) Convince Microsoft to adopt similar bug strategy.
If Microsoft adopted a similar strategy... I could make a slight change of profession and retire in a few months, a billionaire, at least on paper (M$ lawyers would probably have a 100 page document ripe with escape hatches to ensure M$ never had to pay a single bounty)....
Would have to do it quickly though, before Microsoft management realized what a mistake it is to have a security bug bounty on such a piece of software
"My current boss asked me what I thought of asking all employees to work 10-11 hour days until the company is profitable."
It is possible to suddenly ask for 10-11 hours, but expect to pay employees an increased amount for adding additional hours to the conditions of employment, which is a wage reduction otherwise, if you are forcing additional hours on them without repayment.
Since they are only salaried, the pay is their only compensation, and the thing compensated for is the amount of work they do and the number of hours spent working.
This is basically the same as asking employees to agree to take a pay cut, for the sole benefit of providing the owner(s) with more money.
Except it is even worse, because working 10-11 hours a day implies reduction in family time, increased stress, sleep deprivation, possibly resulting in more illnesses/health problems, reduced amount of time for people to get things done that they need to get done in their own lives --- things that are required for them to be well-maintained individuals who can continue to do effective work.
Just because people are working more hours does not mean they get more useful work done. And there may be more bugs or flaws in their work that the work conditions cause. People who are sleep deprived or under more stress/pressure are more likely to make mistakes, and if forced to do so, they really won't be responsible for those mistakes; yes, management can be responsible for increased number of bugs in code, both through dictating conditions of employment, and/or demanding too many features at too quick a dev pace.
Think about it. More man hours for fewer dollars. Assuming just as much gets done during the additional hours (a very shaky assumption), a clear win for the company (at the workers' expense), at least in theory. After such a move, the only reason for workers to stay would be they can't get a deal sufficiently comparable to what they had before elsewhere, or they are so loyal that they will not.
After all, they could switch employers, and the new employer could do something similar as well, so for an employee, there are measures of risks involved; however, if going from 8hour days to 11 hour days, that's essentially a 35% increase in work duration,
AKA a 35% cut in average pay per hour worked.
That is probably a large enough disparity to eventually tip the scales for a fair number of people.
How willing would you be to switch employers if someone offered you slightly better pay to work 29 hours a week, instead of 40?
Employee morale will also suffer, and probably loyalty as well, unless you can do something to promise employees
their extra hours commitments will be worth it to them.
Otherwise.. to improve profitability of the company -- why would they want to?
Employees are paid to do their job, which requires skills that have a market value.
To survive all companies must be profitable eventually, but workers' skills are transferrable,
and without skin in the game, employees are really just mercenaries with little major to gain
(or lose) in the long run based on profitability... the best mercenaries are liable to find another army to join.
Employees, especially engineers are usually not paid directly to work on company profitability,
except certain employees who are managers paid to allocate resources.
So overall company "profitability" is a very poor measure of most employees' performance.
If the employer does not make recompensation or flexibility obvious for such a demand, expect the employees with the best resumes (the ones that can most easily find work elsewhere quickly) to leave when the boss suddenly demands more hours; possibly without the courtesy of advance notice, if the employer is changing the condition of employment by immediately adding many hours they have to work without additional pay, they have a right to do so, as their former boss dishonoring their conditions of employment, and th
cheaper or not, taxpayers don't need to be paying for a DMV clerk's cell phone. There are a few that it makes sense for, people in upper management positions, emergency response chain members, or project leaders that need to be reached off-hours and on-site, etc, but that's a very small percentage of the crowd.
I would say provide a cell for anyone who has a non-personal reason that it would be more efficient for them to be able to be reached immediately when not at a desk, AND sufficiently more efficient that the cost of the cell phone will be covered. For anyone else, voicemail should suffice.
If voicemail doesn't suit their needs for personal reasons only, then the use of the cell phone would be part of their pay, as well as the cost of the plan MINUS that attributable to use for official business; in other words, an employee perk. The government would probably also save money if it opted to stop paying its employees, or forced them to work without electricity, using solely pen and paper for all paperwork and crank-driven equipment for any needs.
For example, if the choice is between hire another employee to fill in or do the impossible and get a cell phone, then get a cell phone.
If the choice is between get a cell phone VS use voicemail and delay response to a non-emergency call for a couple of hours, then no cell phone, use voicemail.
Anyone who might need to be reached for assistance if there is an emergency definitely should have one.
It might look bad to extend a web server outage by 15 minutes, because the IT person took his break and cannot hear the desk phone from the snack room.
Then again, I suppose it will cost less, as long as the site going down is not tax/fee collection related.
For example, anyone who frequently goes out on the road or to remote offices for more than an hour a day, could probably be more efficient with a cell phone.
It is less expensive to buy one cell phone than to buy them 5 desk phones, if they are responsible for facilities at multiple of the department's offices.
Management should probably have cell phones, to ensure reachability. It's not like government departments can have 5 CFOs, for example.
You Android fanboys are cute. The first thing that comes to mind for most people is the Android App Store???? L O fucking L.
No... the first thing that comes to mind is the store that sells "Apps".
Probably a button on their phone or computer labelled App Store, which is but a navigational command.
It should probably be noted that the "App Store" is an exclusive product, as in Apple's App Store is only for iPhone users.
And the only place iPhone users can get apps is Apple's app store
Google's App store is only for Android users, etc.
The "App store" is so strongly bound to the platform, and the platform so bound to a specific App store, that there is no consumer choice, and therefore, no potential for customer confusion; specifically, it is not as if users of an iPhone could be confused into visiting another App store besides Apple's.
Slashdot Mirror
Isn't this akin to the DEA informing a grocery store that they can't have a parking lot, because a lot of drug deals are taking place there at night?
No... at least the DEA is part of the government.
This is akin to the MADD threatening real estate developers that they cannot offer land for sale on a street named "Bar Street", without addressing certain concerns, or they will escalate (probably to a zoning authority), because there is a chance that some business developers might have bars built on the street, some of the bars built might have alcohol available for sale, there is a chance that some tenants of those bars could go there and be encouraged to imbibe, and some of them might try to take their alcohol with them on the road.
So I guess if you smuggle one of those penta(hahaha)lobular screwdrivers into USA you'll be an OUTLAAAW!
Did the senate ratify ACTA already?
Slashdot users debunk this scheme as stupid in 5... 4... 3...
Cmd+Apple+Shift+3 / Cmd +Apple+Shift+4 / Alt+PrtScrn / PrtScrn / Evernote clip rectangle or Window / Screenshotting tool of choice.
Alternatively... hook DVI out cable of computer to frame grabber... view image, push snapshot button.
Alternatively.... reverse engineer plugin, develop new plugin that requests the key, saves the image, and uploads it to a competing "image server" where the image will never expire; optionally posts link in reply to anyone using the 'expiring images' service.
no charge for porn? i approve of this merger!
On the internet? That would be like the US government trying to charge for a breath of fresh air.
Oh wait...
[*] Alternative scenario 1: Porn? Sorry... that's an un-word. Unclothed pics are outlawwed. Unclothed pics have always been outlawwed. [See 1984/Apple-style censorship... porn is disallowed; it simply does not exist.]
[*] Alternative scenario 2: Without porn, there would be only a small number of comcast subscribers. What is the number one thing people connect to the internet to do?
Hint: it's not to watch sports
lacks the resources to circumvent a blacklist of government IP space.
Hell, the Iranian gov't probably can easily circumvent a blacklisting of all Iranian IP space. How? Ever heard of a tunnel or VPN?
Needs work: you should disguise those so they look like government fees and/or taxes....
That's easy, just replace every instance of 'access surcharge' with 'regulatory fee' and refer to 'sections' of a mythical ISP regulations manual
Wikileaks.org access, sec 2693.4 regulatory fee: $99,000
Slashdot.org access, sec 2646.5 regulatory fee: (priceless)
Amount due: +Infinity$
Hm.. no that's too short and readable by a mere mortal.
There, fixed it for ya..
For such a "senior" developer, they should really grow up and learn that just being older or being a dev there for longer is no guarantee of success, prestige, or more money. Wishful thinking at best... in an ideal world, where everything goes your way, your pay goes up and up and up. If you don't keep up with the latest fancy tech, it goes down and down and down (in real terms). (That is: anything less than annual 15% increase is going down in real terms, due to inflation -- same number of dollars earned per time = fewer things you can do with them.)
The only advantage age has given them is they could study the newest technologies full time, since they did not have a job to do. Otherwise, they are at a disadvantage, probably fewer resources saved up, less on-the-job experience. As a senior developer, you learned less about new stuff; it's a calculated tradeoff -- the more time you are working for an employer, the less time it is possible for you to spend studying and learning new things about a continuously changing field. The only thing that was certain was you gained experience, probably in the old technology.
Experience that is useless unless it helps you adapt and continue to perform well, or makes you good at guiding others and making longer term viable recommendations. E.g. management material
If the younger person has more experience with a technology the company needs, then yes, his experience might have a higher market value, sometimes sufficient to outweigh seniority. If that is the case, the senior dev should plan to drop everything and learn the hot new technology, or attempt to graduate from senior dev to management, assuming highest possible pay is what is wanted.
Gain the knowledge the younger dev has, OR become his manager, and then complain or make an offer to do more/different work if you are not compensated commesurately. No whining to project managers about a "newb" getting more pay, without making yourself more valuable; trying to get more pay for value you don't deliver is a road towards being officially declared obsolete.
I'm not so sure even that will do it... do you have any idea how many dating site domain names Gotham dating partners runs? I suppose the more branded dating sites the more signups they'll get... hell, tomorrow they could have a million typo domains as separate "dating sites"
I suppose it's possible they all share one database, and if you register/ delete/opt out of one you opt out of them all.
The cynic in me suggests if you register and provide additional information, the additional info will show up in them all together with your public records info.
And that if you want to delete/opt-out, you'll have to manually delete from each site as it was completely different.
And they could add more web properties in the future that you'll have to opt out of separately
When hundreds of thousands (literally) cross every year, we don't need sensors on the border. Just stand there and some are sure to cross your path.
Yeah.... any sensor network needs to be augmented with physical methods, such as Nethack-style sleeping gas traps, Foothold traps, and fluidizing solid mantraps.
People who bring their own tools are called contractors, not employees.
Execellent cost saving idea... let the employees all bring their own phones, computers, and office supplies, but reclassify them all as contractors.
1099 instead of W-2. No social security paid by the company for the compensation (contractor gets to pay twice). No unemployment fees, overtime, wages, etc to worry about, since contractors don't get those.
Instead employees now contractors get "bi-weekly advance based on portion of the work completed"; they get to pay for their own training, insurance, and since everything's a contract, instead of annual performance reviews, annual contract renewals, no demands for more $$$ on either side until contract renewal, AND no negative connotations associated with negotiating a lower price for the work.
Anything I can think of is 100% lethal if something else doesn't kill the animal first.
Yep... even water. Come to think of it... 100% of animals that were alive and then died ingested some water during their lifetime. This makes water some pretty dangerous stuff.
I suppose the computer equivalent to throwing prions into the air is pointing a fan at a fully powered up computer with open case running full blast, and dumping a 5 pound bag of copper and iron filings across the path of the fan, so they go everywhere.
I disagree, though not for Windows. On Linux, it's pretty common practice to install software locally to a user. For example I have a newer version of Python installed on my webserver than the stock, and it's just in my home directory.
You might not favor the practice for your own reasons, you may even have extenuating circumstances that indicate the practice should not be undertaken.
It is best common practice to have separate filesystems for various labels, and among them /home, /var, and /tmp.
/home /var /tmp and similar filesystems to be mounted noexec and nosuid.
It is best common practice for
If users are to be authorized to install software, that might be a justifiable reason to provide them access to a filesystem that's not noexec.
However, on other large unix systems where users are only expected to run software installed by a sysadmin (small allowance of disk space, etc), the ability to execute programs presents huge unnecessary risks.
given that NTFS does not allow unlinking an exectuable when it is running, having it in %AppData% for the time being is the next best option.
No.. a next best option is versioning the program executable. Possibly launching the current version (real executable) from a "stub"/launcher executable that rarely/never changes.
Wait, so if I instruct chrome to download an application, it shouldn't go in $USER/Downloads because executables aren't suppose to be in data folders?
It is expected to be saved in Downloads like other downloads, but not to be executable from a data directory.
In fact, how the heck is any updater supposed to work in this case?
By downloading the file and telling the user they need to run it.
Or by allowing the user to specify a working directory that should be used for deploying the updates, rather than just assuming that their roaming profile directory is an OKAY place to stash program files.
Even Firefox downloads an executable to %appdata%\Temp\ and then launches the process.
Then Firefox's updater is broken, if it did not prompt the user to choose this path as working directory for update deployment.
What you've described isn't best common practice, it's slavish attention to distinctions that are made for the sake of convenience
Actually, it is enforcement of distinctions, that when not made create an unnecessary risk.
What's more, given that placing roadblocks to updating causes a huge decrease in user compliance, it's not even clear that such draconian measures even improve security. Having those 16 browser vulnerabilities patched as promptly as possible is far more important than adhering to whatever practices seem best in the abstract.
Actually: it is not clear that it is better to have those 16 security patches, than it is to have a strategy to mitigate the risk at a lower level.
It just takes ONE security vulnerability to result in compromise; nobody can really ever update fast enough to never be vulnerable. Some of the most widely exploited vulnerabilities were 0day and widely exploited before a patch was available.
Sufficiently thorough mitigation methods can mean that instead of being exploited by the 1 security vulnerability that you haven't patched yet, the vulnerability IS exploited, but the isolation / code execution prevention technique reduces the damage and compromise done by the exploit to (essentially) zero.
Then I guess I should have phrased the question as follows: What is the procedure for a user to request authorization to install a given piece of software?
Well, that will depend on who owns the system and who they want installing things on their computer.
For enterprises, that will generally include the system administrators, and people who have been trained and shown competence/understanding in the company's security policies and any special compliance requirements to make a decision to accept a user's request to install something, and in some cases, that might require business management involvement. The procedure will probably depend on whether the software came from, and if the company purchased it, or if this is some freebie download of limited value as far as the company is concerned.
For homes, someone or some people will make decisions about what software to be installed; when those who own the machine agree, or agree on the requirements/criteria prior to running a program, and those requirements are followed, then install gets authorized.
That's a question of not only security, but also consumption of shared resources (especially for resident background applications/system tray apps that all users will have to put up with); then there are network resources, which apps such as BitTorrent can chew up.
For third parties using a machine someone else owns, it's up to the owner to specify the conditions, and whether/not they will authorize introducing or updating software; to make a rational decision they have to be informed of any negative side effects to them -- benefits to other people are most likely secondary.
In home environments at least, the 'install directory' may be just open to all users. This still provides a security benefit, and is what I would normally do, however, in that you can be sure explicit action will be required to run an installer program.
In an enterprise environment, the 'install directory' might be read-only to all users except admins and power users who have adequate training and familiarity with the security policies.
It's soft security, because anyone who knows what subdirectory to put the the file under can still run programs. But all software restriction policies based on this method are soft security; someone with physical access can use a boot CD and run any program they want (even against policy).
So software restriction is just a second line of defense (after user avoidance of downloading harmful software), really.
Many malware programs are introduced through accidental downloads or accidental program execution, when the user did not even intend to install anything. So when specific deliberate action is required, mistakes are less likely. Safety nets are useful.
No e-mailed virus is going to tell you "OK, right click the attachment; click save" Now open explorer, copy that file C:\FAMILYNAMEHERE\CustomPrograms\InstallerFiles
Press F2, rename x.zip to x.exe, now double click, and you will see the instructions to receive your million $$.
Realistically, the only way software restriction will be defeated on a workstation is (1) intentional actor with legitimate login access or (2) vulnerability in e-mail or browser allowing exploit code to run malicious payload inside the application software; however, developing a malicious payload able to defeat policy and deploy software once the browser has been closed [across user sessions] could be quite a challenge.
Software restrict is a non-default config, so most malware (targetting naive users in unmanaged environmens) will not be taylored for that.
Also, the vast majority of malware relies on user error (which setting defaults do not mitigate), or exploits that simply will not work if programs in the browser/Adobe downloads/cache file directories cannot be executed.
Now with "headset port" removed, integrated w/ dock port 3.0.
<EG>
Then what is the procedure for a user to request that a program's installer be placed into one of these "designated paths for placing executables in manually"?
Assuming the user is authorized to install software, they open explorer, navigate to the file they downloaded (or their USB drive/external media), CUT/COPY the File, navigate to the installation files directory, and PASTE the file, then run the file.
or just redact the numbers from the image.
Only Slashdot readers can be trusted to redact numbers from images.
Other people (esp. if they are government employees) will manage to screw up the redaction in some manner that makes the information recoverable
Is that updates take place silently and promptly without any user intervention even on systems with UAC activated (a copy is installed to %appdata%).
Hm.. that idea wouldn't work on any systems I setup.
Software restriction policy all systems, Policy default: deny.
Programs can be executed from the default allowed directories. %programfiles% , %systemroot%\system32, etc, and some designated paths for placing executables in manually, in order to install them.
User profile directories including appdata are specifically excluded, because this is best common practice. Programs/executables don't belong in any user's profile or appdata folder (Especially not in any folder used as a default download directory for saving files or temporary directory used by a mail application for opening attachments in a viewer). Contents of appdata is a data folder, and all of a user's profile are data folders, not program folders.
I've heard that h.264 support is broken in an upcoming release.
And what makes this bug security related? :)
I like your style. Perhaps as a Facebook display picture in hopes of getting some "likes" from potential femina mates
I am afraid Google would run into the same problems Knuth and others did. When people post images of checks online, various scammers, the scum of the internet, find images of the checks online, make fake checks, or initiate fraudulent ACH transactions.... result: the account has to be closed.
Remember folks... checks are legal instruments and contain confidential bank account numbers printed on them, which (due to our insecure banking system) can easily be abused by scammers to steal lots of money. Never post an image for public consumption of a check someone else wrote to you.
1) Convince Microsoft to adopt similar bug strategy.
If Microsoft adopted a similar strategy... I could make a slight change of profession and retire in a few months, a billionaire, at least on paper (M$ lawyers would probably have a 100 page document ripe with escape hatches to ensure M$ never had to pay a single bounty)....
Would have to do it quickly though, before Microsoft management realized what a mistake it is to have a security bug bounty on such a piece of software
"My current boss asked me what I thought of asking all employees to work 10-11 hour days until the company is profitable."
It is possible to suddenly ask for 10-11 hours, but expect to pay employees an increased amount for adding additional hours to the conditions of employment, which is a wage reduction otherwise, if you are forcing additional hours on them without repayment. Since they are only salaried, the pay is their only compensation, and the thing compensated for is the amount of work they do and the number of hours spent working. This is basically the same as asking employees to agree to take a pay cut, for the sole benefit of providing the owner(s) with more money. Except it is even worse, because working 10-11 hours a day implies reduction in family time, increased stress, sleep deprivation, possibly resulting in more illnesses/health problems, reduced amount of time for people to get things done that they need to get done in their own lives --- things that are required for them to be well-maintained individuals who can continue to do effective work.
Just because people are working more hours does not mean they get more useful work done. And there may be more bugs or flaws in their work that the work conditions cause. People who are sleep deprived or under more stress/pressure are more likely to make mistakes, and if forced to do so, they really won't be responsible for those mistakes; yes, management can be responsible for increased number of bugs in code, both through dictating conditions of employment, and/or demanding too many features at too quick a dev pace.
Think about it. More man hours for fewer dollars. Assuming just as much gets done during the additional hours (a very shaky assumption), a clear win for the company (at the workers' expense), at least in theory. After such a move, the only reason for workers to stay would be they can't get a deal sufficiently comparable to what they had before elsewhere, or they are so loyal that they will not. After all, they could switch employers, and the new employer could do something similar as well, so for an employee, there are measures of risks involved; however, if going from 8hour days to 11 hour days, that's essentially a 35% increase in work duration, AKA a 35% cut in average pay per hour worked. That is probably a large enough disparity to eventually tip the scales for a fair number of people.
How willing would you be to switch employers if someone offered you slightly better pay to work 29 hours a week, instead of 40?
Employee morale will also suffer, and probably loyalty as well, unless you can do something to promise employees their extra hours commitments will be worth it to them.
Otherwise.. to improve profitability of the company -- why would they want to? Employees are paid to do their job, which requires skills that have a market value. To survive all companies must be profitable eventually, but workers' skills are transferrable, and without skin in the game, employees are really just mercenaries with little major to gain (or lose) in the long run based on profitability... the best mercenaries are liable to find another army to join.
Employees, especially engineers are usually not paid directly to work on company profitability, except certain employees who are managers paid to allocate resources.
So overall company "profitability" is a very poor measure of most employees' performance.
If the employer does not make recompensation or flexibility obvious for such a demand, expect the employees with the best resumes (the ones that can most easily find work elsewhere quickly) to leave when the boss suddenly demands more hours; possibly without the courtesy of advance notice, if the employer is changing the condition of employment by immediately adding many hours they have to work without additional pay, they have a right to do so, as their former boss dishonoring their conditions of employment, and th
cheaper or not, taxpayers don't need to be paying for a DMV clerk's cell phone. There are a few that it makes sense for, people in upper management positions, emergency response chain members, or project leaders that need to be reached off-hours and on-site, etc, but that's a very small percentage of the crowd.
I would say provide a cell for anyone who has a non-personal reason that it would be more efficient for them to be able to be reached immediately when not at a desk, AND sufficiently more efficient that the cost of the cell phone will be covered. For anyone else, voicemail should suffice. If voicemail doesn't suit their needs for personal reasons only, then the use of the cell phone would be part of their pay, as well as the cost of the plan MINUS that attributable to use for official business; in other words, an employee perk. The government would probably also save money if it opted to stop paying its employees, or forced them to work without electricity, using solely pen and paper for all paperwork and crank-driven equipment for any needs.
For example, if the choice is between hire another employee to fill in or do the impossible and get a cell phone, then get a cell phone. If the choice is between get a cell phone VS use voicemail and delay response to a non-emergency call for a couple of hours, then no cell phone, use voicemail.
Anyone who might need to be reached for assistance if there is an emergency definitely should have one. It might look bad to extend a web server outage by 15 minutes, because the IT person took his break and cannot hear the desk phone from the snack room. Then again, I suppose it will cost less, as long as the site going down is not tax/fee collection related.
For example, anyone who frequently goes out on the road or to remote offices for more than an hour a day, could probably be more efficient with a cell phone. It is less expensive to buy one cell phone than to buy them 5 desk phones, if they are responsible for facilities at multiple of the department's offices.
Management should probably have cell phones, to ensure reachability. It's not like government departments can have 5 CFOs, for example.
You Android fanboys are cute. The first thing that comes to mind for most people is the Android App Store???? L O fucking L.
No... the first thing that comes to mind is the store that sells "Apps".
Probably a button on their phone or computer labelled App Store, which is but a navigational command.
It should probably be noted that the "App Store" is an exclusive product, as in Apple's App Store is only for iPhone users. And the only place iPhone users can get apps is Apple's app store
Google's App store is only for Android users, etc.
The "App store" is so strongly bound to the platform, and the platform so bound to a specific App store, that there is no consumer choice, and therefore, no potential for customer confusion; specifically, it is not as if users of an iPhone could be confused into visiting another App store besides Apple's.