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.

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.