Let me get this right: understanding what a real dictatorship is gets called Very Naive?
Maybe there's hope for you in this world AC, but you'd better work on life instead of just letting it happen or you are screwed.

LOL - It's the long beach power plant at L.A.! It's what a 1960s power station looks like.

You owe me a new keyboard.

What needs to be done, as a minimum, is something like Password Hasher (the firefox plugin) needs to be built into each browser.

That protects against what is probably the least interesting situation—when the user's password to one site is silently compromised by attacking that site, and the user used that same password on another site. First, it assumes that the user's password is weak enough to be readily cracked by someone hammering on the password database (which if it is salted properly, is unlikely). Second, it ignores the reality that most passwords are not compromised by server-side security holes; they're compromised by client-side security holes—keyloggers, etc.

To use a car analogy, this is like putting an un-pickable lock on a car to protect your expensive radio, but leaving the factory glass windows untouched.

I think that Google Authenticator tries to prevent mitm attacks by having any given token usable exactly once in addition to having a very short lifespan.

Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker displays a network error message to the user. The user logs in again to the real Google server, unaware that the first attempt was successful, just for somebody else.

Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker masquerades as a forwarder for Google's server so that the user is completely oblivious.

Elapsed time: tens of milliseconds after the user logs in. And if the service you're logging into works the way most services do, an even simpler attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker steals the cookies that Google stores on the user's system and uses them on another machine.

Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:

1. Attacker compromises the device and steals the private key used to generate the authentication token.
2. Attacker logs in at will. From anywhere. At any time. Forever and ever.

Elapsed time: zero milliseconds after the device is first compromised or GA is first installed.

All four techniques are 100% transparent and are 100% effective attacks against software-generated time-based authentication schemes. The first two are 100% effective against hardware tokens used for time-based authentication, too. In fact, even if Google upped the ante and made the authenticator be interactive, where the Google servers sent a unique nonce that had to be encoded along with the time stamp, this scheme would still not be significantly stronger. The only change required to the first two schemes would be adding one additional step—telling the attacker's server to issue a request to Google and pass that request nonce to the compromised client. And the third and fourth schemes would continue working as-is. This is why time-based authentication is basically worthless unless the endpoint is trusted (and at this point, I'm growing more and more convinced that users should assume that their endpoints are not trusted).

The reality of the matter is that time-based authentication schemes are an anachronism. When they were first conceived by RSA in the mid-1980s, they were not intended for general users. They were intended to protect against precisely one threat—an attacker with a very specific target watching a user type in his or her password from a distance. They work well for that purpose. They can be compromised once by any attacker who gains control over the system where the authentication token is being entered, even if hardware tokens are involved, and they are permanently compromised by any attacker who gains control over the system where the secret key is stored. The reason there haven't been very many new implementations of time-based authentication since the 1990s is that such schemes just aren't particularly useful against modern attacks. They give the illusion of security without actually adding any. Well, unless you're worried about your roommate seeing you enter your password.

Put another way, creating a secure authentication scheme where the endpoint is compromised is fundamentally impossible for precisely the same reason that perfect DRM is fundamentally impossible. Alice is also Eve and Mallory. Food for thought.

Whatever can be said about the Australian government it appears that you don't know enough to comment on it one way or another. Dictatorship? WTF? It's a hung parliment in the balance FFS where a single person changing sides would bring it down. That's about as far from dictatorship as you can get in an elected system.

The very start with the ship underwater set that trend. Why bother with shuttles and transporters if you can just land it anywhere? As for underwater - why not stick drills on it so it can tunnel since it's now already as ridiculous as a flying submarine molemachine battleship out of a Godzilla movie. Add transporting all the way to a distant planet and why do you need starfleet anyway?
Bad science is annoying, but not as annoying as being inconsistant with the bad science so that none of the new magical rules to replace science in the setting actually last the length of a movie. If anything at all can happen and there is no reason for anything then why bother?

Sigh. Ignore the first sentence in the second paragraph. This is what over-editing does.

Yes, lots of weak passwords are guessed by automated bots. This tends to affect websites like Facebook, message boards, etc., where the maximum possible damage is fairly limited and mostly harmless. By contrast, most people's bank account passwords are not "12345".

Not for important accounts, though. For things like banks, the password rules generally are already strong enough to make guessing problematic unless you know your victim, and to some degree, even then. It is far easier to make a virus that compromises millions of machines and looks at what letters the users just typed, or injects spyware into their browsers to detect which of those virtual PIN number pad buttons the user clicked, or whatever. Instead of an attack on a specific person that requires research, you can successfully compromise thousands or even millions of people. Why spend a high amount of effort per target when you can spend almost none and get similar results?

This, of course, ignores attacks on the infrastructure itself (e.g. attacking a credit card processor to steal credit/debit card numbers en masse or installing a card skimmer on an ATM). Those sorts of attacks also seem to be pretty popular, but they don't have much to do with passwords.

However all those episodes done during those two years were probably done within less time in total and were definitely done with a lot less people than the current movie. We expect better. We expect something that at least stands up to a mediocre episode of that original series.

The FIDO stuff sounds like a whole lot of expensive extra technology with no real benefit over a password. A finger swipe is a replayable event just as much as a password or PIN.

The Google Authenticator is conceptually okay in theory, but in practice, AFAIK, it too becomes a gaping security hole as soon as your mobile device gets compromised.

If you want something stronger than passwords, it must have the following criteria:

1. Immune to replay attacks. Done correctly, this means that each authentication request must have a unique ID that must be signed or otherwise combined with some shared secret in a secure way.
2. Immune to man-in-the-middle attacks. Each request for authentication must be signed by the requestor so that the user can be certain that he/she is not agreeing to do something other than what is intended. Each response from the user must include at least a hash of the original request.
3. Immune to device compromise. The most common way that computer security is breached is through password sniffers or other compromise of the user's computer or mobile device. If you cannot trust the device that is performing the authentication, you cannot trust the action being performed, and all security goes out the window, including existing measures for preventing MITM and replay attacks, such as SSL/TLS.

None of these schemes I've seen so far address #3, and as a result, none of them are significantly more secure than typing letters at random and pasting the resulting password into a text file on your Desktop. They try to address problems that don't actually exist, while failing to address the root of the problem, which is that computers, mobile devices, etc. are not inherently secure.

For example, Google Authenticator uses a time-based token. This tries to avoid replay attacks by limiting the period during which an attack is possible. That doesn't work very well, though, unless you can delay an attacker's ability to sniff that token. This means that you have to prevent a MITM attack. As soon as the device is compromised, SSL and TLS are no longer capable of preventing a MITM attack, so the entire scheme falls apart.

Anything short of a non-networked device communicating with your computer over a very simple protocol (think "formal verification" here) is not a major win, IMO. And it can't be something silly like touching a smart card to an RFID reader, either, because the reader could perform more than one transaction, and you would have no way of knowing that you just bought some farmer in Iowa a new tractor alongside that DVD from Amazon. No, you really need a physical screen and a button on the device saying, "Do you agree to transfer $258,000 to Bank of Nigeria?" in order to significantly improve things. Anything short of that is just wasting a lot of time and expense without addressing the real problem—that if you can't trust the endpoint, you can't trust the message. Start by developing a truly trusted endpoint. After that, the entire problem becomes fairly trivial.

They shamelessly copied some scenes from the second trek movie but reversed their polarity, and then rubbed it painfully in your face. Just as well I saw it on a cheap tuesday but I still felt ripped off.

I have to agree, the ship looked like a hipster coffee bar

Apart from the bits that looked like the boiler water treatment plant at a 1960's power station only with the words "inert reactant" stuck on some pipes to show what little they think of the fans. They had a huge budget, why not bother to make the engine room look at least as good as the cheap effects in the first series instead of doing the dirt poor BBC trick of asking a mate at the local power station to let them in for free?

I, for one, am 100% gung-ho about having a 3rd-party in the 'cloud' handling every single one of my packets so that they can balance them between my connections!

There are already lots of third parties handling each of your packets. I'm not sure why one extra router would be a cause for concern.

You are right, it looks like a Cargo Cult namedrop only interpretation where it has even less of what actually made the original go than even some of the fanfaction or parodies. Galaxy Quest, Quark, and Star Wreck had more in common.
While watching both this week I kept thinking the whole thing would have been improved if Spock started cutting the tops of people's heads until somebody saved the cheerleader from him :)