But if you are at the phishing site they can easily pass the information to your real bank and MITM the response back to you. I've written reverse proxy filters that do this kind of thing for some of the internal 3rd party services I manage at my work. This kind of thing stops the really easy to make phishing sites (such as form service based phishing or phishing from compromised web pages) but anyone who is paying even the slightest amount of attention will see that these aren't the real banking site to begin with.
Indeed, also many of these fixes can also be/are already backported to older releases. The manufactures just don't care enough to build and test them and if they did the carriers don't want to send a patch through QA and the side deals for many branded phones don't let the manufactures publish updates directly.
Digital signatures in android are mostly self signed (you can use a notarized certificate but it has to be issued as valid for 20 years to be on the play store, so good luck). They are for use in verifying updates automatically by the system for installed packages with the same name and for packages requesting to run with shared code or data as another package (upgrade key packages or feature modules for instance).
If you want to verify the source you check the hash or only download from a trusted location. I'm not saying that I agree with the way android is using signatures... it could have been much better... but your signatures in android are not at all the same as a signature for a windows app. Also of note, android has no way of displaying the signature that signed an apk.
That ratio is always true but misleading when used like that because none of those values are fixed in a circuit. If I have a 1.5v AA battery connected to a 0.1 Ohm circuit (say a short length of wire) it should try and provide 15A of power. However, a single AA battery can't provide 15A of power, so the internal resistance of the battery goes up and the voltage output from the battery drops until it is within the range that the battery can provide. That's why electrical load rating is either measured in volt-amps, Watts or x amps at y volts.
Compressed air has some major losses due to heat. As you compress the air it heats up considerably after it cools the heat energy is lost. Pumped storage can also be deployed on a much larger scale given the right geological layout.
As has been said already, you're confusing the interface with the application. An OS shell (an application) should be able do all those things (GUI or CLI) a search engine should not.
As someone who is well versed in "the art of computer interface design" I would typically call the Google search interface a command line interface (you give commands on a single line when prompted). I've seen many CLIs from 80s mainframe terminal systems that function almost exactly like that. The fact that your commands are free-form strings and it auto-corrects and performs fuzzy searching for you don't change the interface. It would also be entirely possible for Google to implement searching via alternative interfaces (they do for things like YouTube and image search).
Note that browsing the results is actually a different interface than searching.
Dummy data wouldn't be good for things like contact info unless you pulled it from known invalid data. What if you get someone's real phone number or email address with random data? Succeeding with no data or reliable fake data is usually better. Evented failures (like no net access available or gps failed to find location) where possible are better. All of these can be detected with enough effort on the developer's part in much the same way that some web developers are detecting ad blocking and script blocking.
Most users will continue to grant all access to everything that asks for it without even reading or wondering why it is needed.
Some custom builds have this feature on android (CM7 for one) but revoking permissions often leads to the app crashing when it tries to do something it expects to work and doesn't check for failure. I've revoked contact, gps, and/or network permissions for apps that I don't use those features on with no ill effects unless the feature is used.
That was the incident I was referring to. In that case valgrind points it out rightfully as uninitialized memory, a patch to initialize it was reviewed by the OpenSSL team in 2003 and rejected with the stated reason that the PRNG used the uninitialized data as part of the entropy (they even have an FAQ entry for it). The Debian maintainer for OpenSSL proceed to patch the code in their build script later in 2006 by actually removing the call to the function! So in this case the bad patch wasn't reviewed by anyone who was familiar enough with the code to see the error (I couldn't find any place where the maintainer tried to send the patch upstream), that is why the bug was only on Debian based systems. Most of the people reviewing OpenSSL/OpenSSH were reviewing the source tree not the internal Debian patches.
On PRNGs: I've only coded PRNGs for my algorithms class years ago and only 1 of 3 algorithms was required to gather entropy so I wouldn't consider myself an expert on the topic. I do recall the math being exceeding simple however, no more than a few lines of code for the sequence generator itself (most of the work in the assignment was verifying the random distribution). I would doubt that one could hide a flaw in one from eyes that knew the algorithm properly. This is of course the main flaw with the many eyes claim - It's not the number of eyes that matter but rather the quality of the eyes (more eyes just increases the chance for quality).
The algorithms for RNGs are quite simple and hardly easy to program in a flaw that would survive a review at that level. Entropy gathering, that's more complex but entropy is usually assumed to be non-uniform so we have some nice simple methods for converting it to be uniform. Also non-uniform RNGs would be detected in scientific work rather quickly and it's quite easy to test for statistical flaws by making a few hundred thousand random numbers.
Now, some package maintainer commenting out the line in OpenSSH that actually makes the numbers random, that could be a while...
It's also an issue with the way the question was asked. For instance I would always have to answer no to "Have you used all of your vacation time this year?" I don't earn vacation time on an annual basis but rather it accrues monthly for me with a cap. I like to keep a week or so "saved up" in case something happens and I need some payed time off. Do I let my time roll over the cap and cost me earned time off? No and I'm not expected to do so.
Also statistics can be quite misleading. I know people in sales who schedule meetings with prospective clients while they are on vacation, they earn commission on those sales however so it works in their favor.
Lies, dammed lies, statistics and surveys. Remember, it's all about how you ask the question. Also note that the polling was done before December 15th at my work most people take a week or so off around the 25th.
I would like to see said federal law, I have doubts to it's existence. The only federal regulation that I know of that has anything to do with university communications (not involving specific dept of education programs with their own rules) is FERPA and it only involves granting 3rd parties access to student records.
At my work we have a simple one strike rule. If you want admin access to your PC, fine. If you get a user-initiated malware infection, install unlicensed software or otherwise abuse your admin rights you go back to making requests for changes. It's worked well for us as the power users/devs don't need to bug IT for changes all the time and we don't end up spending a bunch of time fixing problems either.
We use a WSUS server and Local Update Publisher at work. It has been a bit of a pain sometimes, Adobe isn't fond of sticking to MSI standards and has published stuff with bad MSI applicability rule content (windows installer would still install it but you had to edit the xml so WSUS could validate it). They also only publish MSI files for the ActiveX version of flash player so we have to deploy the exe version of the mozilla plugin (WSUS can deploy exe, msi and msp files but msp files are the easiest).
It takes about 1 hour for us to write and test the deployment rules for each update. We test against both WinXP-32bit and Win7-64bit targets as they will sometimes need different applicability rules. Then we let the clients check-in to see if they mark the update as applicable. After we are satisfied that all of the clients that need it and only the clients that need the update will try to install it (we have had issues with this in the past) we mark the update as ready to install and the clients will install it in the next cycle.
This usually means that an update is out for 1-2 days before our clients have it installed so if there is an exploit being used broadly we will sometimes force clients to update via our inventory tool that can have it done in 1 hour. We have had systems where the user has been hit by these type of scareware drive-by-installs before the patch was even out.
We are planning on using a few for remote UPS monitors. Sure we could buy a UPS with SNMP but these are both cheaper ($300-600 for most SNMP add-on cards) and offer more flexibility.
In my experience, almost any IT admin who is actually qualified to make that choice (i.e., expert in both) would prefer Ubuntu, because it's easier, cheaper, and takes less time.
I agree, I've done both. By far the worst however are the systems where the user insists on dual booting.
Real Disadvantages: You risk data loss with any application that stores critical data using either (1) a truncate/write method or (2) a write/rename method without a asking the OS to sync it's data. I think that far fewer than 95% of applications fall under (2) and every filesystem will have issues with (1).
For (1) there is nothing the OS can do for the application, just about any file system would loose data in this case depending on how long it caches the writes in memory and if the application has a chance to finish writing all of the data. (1) is clearly bad application code at fault. Ext4 does increase the write-delay for the data but any way you use (1) is asking for problems if the system crashes/the disk fills up/etc.
For (2) the file system could implement atomic rename operations but that would be at a slight performance loss when the application didn't need this atomic operation. This is more of a do-what-I-mean-not-what-I-say workaround as I don't see too many situations where (2) would be used without expecting atomic operation. If the application didn't care about possible data loss in the file (1) works well. The real fix however is to call sync() in the application code in this situation, it makes the code more portable across posix filesystems.
If reliability was the only concern they would likely use ATM. Speed is a major concern due to SAR bottlenecks. Also, ATM networks are expensive, difficult to implement, and inefficient at bulk data transfers.
There was a patch (not by S3) for the XFree86 driver that disabled VESA mode probing. It would make S3 chipsets "work" with VESA drivers if you got your mode lines just right in the config file. Even then there were some other bugs, you had to start the kernel in framebuffer mode and you could not go back to a console once X was started.
The stated reason from S3 for not supporting VESA probing was that it was used in the past to obtain firmware from the chipset and that Windows (9x) did not probe for VESA modes (even when using VESA drivers).
I like to think that linux support from manufactures has come a long way since then but it looks like some still don't care.
The flaw with this is that he would still be legally allowed to keep his own transcript of the performance, just not make copies. Oh, and live performances can not technically be copyrighted in the US (but you still need permission from the artist to distribute to avoid the anti-bootlegging provisions). Copyright only exists (in the US) for something placed on tangible media.
Quite frankly, yes. AFIAK most waste in the US is sold to Areva for reprocessing into usable material. Most uranium mines have been non-operational for several years due to the low price of uranium on the market, this might change in the near future however. In the US the NEC is quite strict on tracking where waste is shipped.
Full disclosure: I work in Richland, WA where Hanford is located. I do not work at Hanford myself but I know people who do.
I sent a wire 3 week ago using firefox (on windows).
On a related note, I still have not received my 100 thousand US dollars for facilitating getting the prime minister of finance in Nigeria's scheme to get money out of his country. (j/k)
If the thermometer was in the radiator then you would see this. The thermostat will shut off most of the water cycling through the radiator and cycle it internally through the engine only. This keeps the engine running at optimal temp and gets it warm faster when it is cold out. The dash thermometers in older injection cars are not coupled to the thermal sensor that controls fuel mixture but rather to the water temperature in either the radiator or the engine (found this out myself when my thermal sensor went bad).
If it was extremely cold out you might be able to cool off the engine significantly while it was running downhill at idle. The result would be that the fuel mixture would run a bit richer than normal for a short bit while the engine warmed back up. A normal engine has a fairly high heat capacitance and doesn't have that high of surface area, it would take quite a bit of cold moving air to cool it down.
CAs don't have, nor have they ever had, the private keys (well, most CAs anyway). The private keys are generated on the client side (the client being the webserver in many cases) and the public keys are signed by the CA.
Now, if the FBI/NSA/Whatever wanted access to the encrypted traffic they could do a man-in-the-middle by getting the CA to issue a signed cert saying that they were the webserver in question but it would have a different set of keys (not that the client would notify the user of this).
Slashdot Mirror
But if you are at the phishing site they can easily pass the information to your real bank and MITM the response back to you. I've written reverse proxy filters that do this kind of thing for some of the internal 3rd party services I manage at my work. This kind of thing stops the really easy to make phishing sites (such as form service based phishing or phishing from compromised web pages) but anyone who is paying even the slightest amount of attention will see that these aren't the real banking site to begin with.
Oh, and backup with Carbonite. Unless this is a trivial gaming machine, your data are more valuable than your hardware.
That's OK. The NSA has a "backup" of your data too.
Indeed, also many of these fixes can also be/are already backported to older releases. The manufactures just don't care enough to build and test them and if they did the carriers don't want to send a patch through QA and the side deals for many branded phones don't let the manufactures publish updates directly.
Digital signatures in android are mostly self signed (you can use a notarized certificate but it has to be issued as valid for 20 years to be on the play store, so good luck). They are for use in verifying updates automatically by the system for installed packages with the same name and for packages requesting to run with shared code or data as another package (upgrade key packages or feature modules for instance).
If you want to verify the source you check the hash or only download from a trusted location. I'm not saying that I agree with the way android is using signatures... it could have been much better... but your signatures in android are not at all the same as a signature for a windows app. Also of note, android has no way of displaying the signature that signed an apk.
More info: http://developer.android.com/tools/publishing/app-signing.html
That ratio is always true but misleading when used like that because none of those values are fixed in a circuit. If I have a 1.5v AA battery connected to a 0.1 Ohm circuit (say a short length of wire) it should try and provide 15A of power. However, a single AA battery can't provide 15A of power, so the internal resistance of the battery goes up and the voltage output from the battery drops until it is within the range that the battery can provide. That's why electrical load rating is either measured in volt-amps, Watts or x amps at y volts.
Compressed air has some major losses due to heat. As you compress the air it heats up considerably after it cools the heat energy is lost. Pumped storage can also be deployed on a much larger scale given the right geological layout.
As has been said already, you're confusing the interface with the application. An OS shell (an application) should be able do all those things (GUI or CLI) a search engine should not.
As someone who is well versed in "the art of computer interface design" I would typically call the Google search interface a command line interface (you give commands on a single line when prompted). I've seen many CLIs from 80s mainframe terminal systems that function almost exactly like that. The fact that your commands are free-form strings and it auto-corrects and performs fuzzy searching for you don't change the interface. It would also be entirely possible for Google to implement searching via alternative interfaces (they do for things like YouTube and image search).
Note that browsing the results is actually a different interface than searching.
Dummy data wouldn't be good for things like contact info unless you pulled it from known invalid data. What if you get someone's real phone number or email address with random data? Succeeding with no data or reliable fake data is usually better. Evented failures (like no net access available or gps failed to find location) where possible are better. All of these can be detected with enough effort on the developer's part in much the same way that some web developers are detecting ad blocking and script blocking.
Most users will continue to grant all access to everything that asks for it without even reading or wondering why it is needed.
Some custom builds have this feature on android (CM7 for one) but revoking permissions often leads to the app crashing when it tries to do something it expects to work and doesn't check for failure. I've revoked contact, gps, and/or network permissions for apps that I don't use those features on with no ill effects unless the feature is used.
That was the incident I was referring to. In that case valgrind points it out rightfully as uninitialized memory, a patch to initialize it was reviewed by the OpenSSL team in 2003 and rejected with the stated reason that the PRNG used the uninitialized data as part of the entropy (they even have an FAQ entry for it). The Debian maintainer for OpenSSL proceed to patch the code in their build script later in 2006 by actually removing the call to the function! So in this case the bad patch wasn't reviewed by anyone who was familiar enough with the code to see the error (I couldn't find any place where the maintainer tried to send the patch upstream), that is why the bug was only on Debian based systems. Most of the people reviewing OpenSSL/OpenSSH were reviewing the source tree not the internal Debian patches.
On PRNGs: I've only coded PRNGs for my algorithms class years ago and only 1 of 3 algorithms was required to gather entropy so I wouldn't consider myself an expert on the topic. I do recall the math being exceeding simple however, no more than a few lines of code for the sequence generator itself (most of the work in the assignment was verifying the random distribution). I would doubt that one could hide a flaw in one from eyes that knew the algorithm properly. This is of course the main flaw with the many eyes claim - It's not the number of eyes that matter but rather the quality of the eyes (more eyes just increases the chance for quality).
The algorithms for RNGs are quite simple and hardly easy to program in a flaw that would survive a review at that level. Entropy gathering, that's more complex but entropy is usually assumed to be non-uniform so we have some nice simple methods for converting it to be uniform. Also non-uniform RNGs would be detected in scientific work rather quickly and it's quite easy to test for statistical flaws by making a few hundred thousand random numbers.
Now, some package maintainer commenting out the line in OpenSSH that actually makes the numbers random, that could be a while...
It's also an issue with the way the question was asked. For instance I would always have to answer no to "Have you used all of your vacation time this year?" I don't earn vacation time on an annual basis but rather it accrues monthly for me with a cap. I like to keep a week or so "saved up" in case something happens and I need some payed time off. Do I let my time roll over the cap and cost me earned time off? No and I'm not expected to do so.
Also statistics can be quite misleading. I know people in sales who schedule meetings with prospective clients while they are on vacation, they earn commission on those sales however so it works in their favor.
Lies, dammed lies, statistics and surveys. Remember, it's all about how you ask the question. Also note that the polling was done before December 15th at my work most people take a week or so off around the 25th.
I would like to see said federal law, I have doubts to it's existence. The only federal regulation that I know of that has anything to do with university communications (not involving specific dept of education programs with their own rules) is FERPA and it only involves granting 3rd parties access to student records.
At my work we have a simple one strike rule. If you want admin access to your PC, fine. If you get a user-initiated malware infection, install unlicensed software or otherwise abuse your admin rights you go back to making requests for changes. It's worked well for us as the power users/devs don't need to bug IT for changes all the time and we don't end up spending a bunch of time fixing problems either.
We use a WSUS server and Local Update Publisher at work. It has been a bit of a pain sometimes, Adobe isn't fond of sticking to MSI standards and has published stuff with bad MSI applicability rule content (windows installer would still install it but you had to edit the xml so WSUS could validate it). They also only publish MSI files for the ActiveX version of flash player so we have to deploy the exe version of the mozilla plugin (WSUS can deploy exe, msi and msp files but msp files are the easiest).
It takes about 1 hour for us to write and test the deployment rules for each update. We test against both WinXP-32bit and Win7-64bit targets as they will sometimes need different applicability rules. Then we let the clients check-in to see if they mark the update as applicable. After we are satisfied that all of the clients that need it and only the clients that need the update will try to install it (we have had issues with this in the past) we mark the update as ready to install and the clients will install it in the next cycle.
This usually means that an update is out for 1-2 days before our clients have it installed so if there is an exploit being used broadly we will sometimes force clients to update via our inventory tool that can have it done in 1 hour. We have had systems where the user has been hit by these type of scareware drive-by-installs before the patch was even out.
We are planning on using a few for remote UPS monitors. Sure we could buy a UPS with SNMP but these are both cheaper ($300-600 for most SNMP add-on cards) and offer more flexibility.
In my experience, almost any IT admin who is actually qualified to make that choice (i.e., expert in both) would prefer Ubuntu, because it's easier, cheaper, and takes less time.
I agree, I've done both. By far the worst however are the systems where the user insists on dual booting.
Real Disadvantages: You risk data loss with any application that stores critical data using either (1) a truncate/write method or (2) a write/rename method without a asking the OS to sync it's data. I think that far fewer than 95% of applications fall under (2) and every filesystem will have issues with (1).
For (1) there is nothing the OS can do for the application, just about any file system would loose data in this case depending on how long it caches the writes in memory and if the application has a chance to finish writing all of the data. (1) is clearly bad application code at fault. Ext4 does increase the write-delay for the data but any way you use (1) is asking for problems if the system crashes/the disk fills up/etc.
For (2) the file system could implement atomic rename operations but that would be at a slight performance loss when the application didn't need this atomic operation. This is more of a do-what-I-mean-not-what-I-say workaround as I don't see too many situations where (2) would be used without expecting atomic operation. If the application didn't care about possible data loss in the file (1) works well. The real fix however is to call sync() in the application code in this situation, it makes the code more portable across posix filesystems.
If reliability was the only concern they would likely use ATM.
Speed is a major concern due to SAR bottlenecks. Also, ATM networks are expensive, difficult to implement, and inefficient at bulk data transfers.
There was a patch (not by S3) for the XFree86 driver that disabled VESA mode probing. It would make S3 chipsets "work" with VESA drivers if you got your mode lines just right in the config file. Even then there were some other bugs, you had to start the kernel in framebuffer mode and you could not go back to a console once X was started.
The stated reason from S3 for not supporting VESA probing was that it was used in the past to obtain firmware from the chipset and that Windows (9x) did not probe for VESA modes (even when using VESA drivers).
I like to think that linux support from manufactures has come a long way since then but it looks like some still don't care.
The flaw with this is that he would still be legally allowed to keep his own transcript of the performance, just not make copies. Oh, and live performances can not technically be copyrighted in the US (but you still need permission from the artist to distribute to avoid the anti-bootlegging provisions). Copyright only exists (in the US) for something placed on tangible media.
All those things (and many more) are just tales?
Quite frankly, yes. AFIAK most waste in the US is sold to Areva for reprocessing into usable material. Most uranium mines have been non-operational for several years due to the low price of uranium on the market, this might change in the near future however. In the US the NEC is quite strict on tracking where waste is shipped.
Full disclosure: I work in Richland, WA where Hanford is located. I do not work at Hanford myself but I know people who do.
I sent a wire 3 week ago using firefox (on windows).
On a related note, I still have not received my 100 thousand US dollars for facilitating getting the prime minister of finance in Nigeria's scheme to get money out of his country. (j/k)
If the thermometer was in the radiator then you would see this. The thermostat will shut off most of the water cycling through the radiator and cycle it internally through the engine only. This keeps the engine running at optimal temp and gets it warm faster when it is cold out. The dash thermometers in older injection cars are not coupled to the thermal sensor that controls fuel mixture but rather to the water temperature in either the radiator or the engine (found this out myself when my thermal sensor went bad).
If it was extremely cold out you might be able to cool off the engine significantly while it was running downhill at idle. The result would be that the fuel mixture would run a bit richer than normal for a short bit while the engine warmed back up. A normal engine has a fairly high heat capacitance and doesn't have that high of surface area, it would take quite a bit of cold moving air to cool it down.
CAs don't have, nor have they ever had, the private keys (well, most CAs anyway). The private keys are generated on the client side (the client being the webserver in many cases) and the public keys are signed by the CA.
Now, if the FBI/NSA/Whatever wanted access to the encrypted traffic they could do a man-in-the-middle by getting the CA to issue a signed cert saying that they were the webserver in question but it would have a different set of keys (not that the client would notify the user of this).