mantrax4

You're underestimating the work that's been done in secure password managers in the last few years.

Check the whitepaper Apple published regarding their iCloud Keychain mechanism.

It generates secure passwords, locks them with a passphrase, but also makes them available on all your devices, not just one (which, if it breaks, you're locked out of all your services).

Using hardware for tokens is secure and simple, but it shows a severe lack of imagination. I only see hardware tokens as useful for very high security logins, like bank accounts, where the apparent inconvenience is at least justified.

Scenario Heartbleed 2

- People heed the advice of this author, and soon all passwords are abolished, replaced with email auth.

- Of course, emails still have a password, as you can't email auth an email.

- Heartbleed 2 happens, hackers focus on Heartbleeding email services.

- For every email password you get, now you have complete control over this person's life, as all services are linked to it for auth.

- Security experts start proposing that you have a separate email for every email auth service, and every email has a separate password, so you can isolate damage.

- Result: previously you had N passwords for N services and 1 email. Now you have N passwords for N services and N emails.

Yay for "improvement"!

The problem is that getting email or SMS and having to type that code in every time, then deleting that email/SMS, manually is less convenient that using a password manager.

You can have an "authentication email manager" just like password managers, but then what have we solved exactly? Nothing.

Except that emails, when used as mass-authentication device, will become an even more attractive target to hackers. In most cases accounts are exploited namely via their email password recovery, not via their password.

Email/SMS are an ok layer when used as a second factor, but on their own, they are less secure than a strong password. While logins are HTTPS, email is plain text, so is SMS.

Heartbleed is an exception. Dropping passwords over Heartbleed is precisely the same type of overreaction we had after 9/11 when suddenly flying became a nightmare (and still is).

The proper reaction here is: Heartbleed is fixed, and we better put some resources towards vetting and fixing OpenSSL so this doesn't happen again.

No need to build towers of nonsense that assume it'll be Heartbleed every week now for the next 20 years.

> I fail to see how his process has this problem and yours magically doesn't. You're making a lot of hay out of whether his "reactive" events or your "imperative" messages are better or worse, but they're the same thing: sending messages. The only difference is whether broadcast is better than a direct message sent to a unit.

No, that's not the only difference. Notice that I have 4 actors, only one is burdened with knowing how the process works. Here's what the other 3 actors see from their PoV:

- PaymentActor gets "process payment" event.

- FraudCheckActor gets "check for fraud" event.

- CancelOrderActor gets "cancel order" event.

This is what I call decoupling. 3/4 of your system is completely isolated from each other and reusable in different business processes. And the one actor who is "burdened" with knowing about the process (OrderActor) is in fact, responsible for the process (and you can open its code in one place, read it, reason about it, and change it in one place, not all over the graph).

And his model:

- PaymentActor gets "new order" event.

- FraudCheckActor gets "payment complete event" event.

- CancelOrderActor gets "fraud detected" event.

Those 3 processes are coupled with each other, as they need to interpret each other's events.

If you want to move to another system where the fraud check doesn't happen right after the payment, you need to edit the FraudCheckActor's "reaction" to that event.

In my case FraudCheckActor is only reacting to the "check for fraud" event and so it doesn't have to have its reaction code edited.

There's nothing "magical" about it, just better concern isolation. If you still see this as the same, that's all I could do to explain things :)

Everyone has to know about the business process logic to me is the opposite of decoupling.

I'd rather limit coupling to a single actor, and let the other actors be reusable.

You can't avoid someone being in charge. It's an argument as old as the universe. Do companies need a CEO? Do we need a government?

Well, someone with an imperative role always emerges sooner or later. Even in nature, only the simplest of animals don't have a centralized nervous system. The subscription model described in the article won't survive complexity, because it's an anarchy. As nature and business shows, imperative is not a bad thing. It allows concern separation.

It's not CancelOrderActor's concern why the order is canceled. The reasons for this may be hundreds. CancelOrderActor's concern is how to cancel the order. And sure, if CancelOrderActor was A.I. we could chat about why OrderActor's practice is good, but until that changes, CancelOrderActor just takes orders. It doesn't decide what's good for the order, as it's not its job.

Someone once said to me "good software design is about separating things that change a lot, from the things that don't change a lot".

Business process changes a lot. Would you rather update all actors' bindings when this happens, or just one supervisor?

Well I might be naive, but I prefer things this way: the business process changes? I change the business process actor. The payment method changes? I change the payment actor.

And not... The business process changes? Change all the things! Because it's not just a matter of whether CancelOrderActor is bound to the FraudEvent by subscription.

It's what the CancelOrderActor does as a result of that event, and that's still defined inside that actor. And in the real world, the options are many, because no one creates an actor for just the purpose of canceling an order anyway. It's mindless boilerplate. An actor has a domain. And how that domain changes in reaction to unrelated events depends on a lot of things.

You actually said it, which is funny, but the right word for this is "validating".

Here's the chain:

1. Get raw input.

2. Validate it (number, not number, in range, not in range?)

3. Optionally format it to canonical format (i.e. trim whitespace etc.)

... later....

4. Encode it for where you want to use it (SQL, HTML etc.).

Sometimes steps 2 and 3 are done in the opposite order, or as an atomic single operation, but point is, we have perfectly reasonable words for all that: validating, formatting, encoding.

No form should accept just "HTML" if you don't want just any "HTML" in your form.

I was actively trying to talk about his script example and instead I had to second-guess his parser to get past the validator (I eventually resigned and replaced < and > with [ and ]).

If you want to support some tags, have your parser be an HTML-like DSL language with those tags supported. Don't disallow perfectly good input.

1. Paste <script>alert("I am a hacker.")</script> in TFA's comment box

2. Select Anonymous from the auth options.

3. Click Submit.

4. Laugh your heart out.

This is why I just call it encoding and decoding. Proper words, and assume context (encoding for what... decoding from what).

I can't post a comment containing <script> in this comment form, because it's "disallowed", instead of just escaping it as plain text.

The thick, thick irony of a guy who can't even follow his own advice.

Actually, shouting in the office means you coupled the FraudCheckActor to a PaymentCompleteEvent, and you coupled CancelOrderActor to FraudDetectedEvent.

Your lower level actors are still coupled with each other, through quite specific events, and on top of that, dependent on a subscriber setup.

Instead of declaring your own protocol and accepting messages in that protocol, now you need to understand everyone else's protocol (in the form of their event types) and react to it if you're subscribed to it.

It's the worst of both worlds.

Now, sure, you're right. Actors aren't like people in an office. Actors can't complain when you entangle them in a hot mess, they just carry on with whatever they're told to do.

But the more experience I gain, the more I see the systems of the "real world" are in fact exactly like the systems of the "computer world". If something makes no sense in an organization made of people, then almost inevitably it'll make developers cry when having to figure out the sequence of events when implementing the same organization as a set of actors.

Take it as a useful heuristic and humor my analogies. You might find a nugget of gold there.

Also, there's nothing blasphemous if my supervisor can be implemented as synchronous imperative code. When people hear about a new paradigm, they believe they have to abandon everything and do things differently for no reason. No. Find some balance, what you knew still works, don't throw it out, just add the new benefits Actor offers to you.

I.e. while Actors mean we can have objects that do things that you can't do in imperative/synchronous fashion, this doesn't mean we should never use actors for something that might be done in imperative/synchronous fashion. 90% of the interactions between actors still look like a request/response pattern. But those 10% when things don't look like a request/response really matter when you need that ability.

Also keep in mind Actors don't care how far its subordinates are. In synchronous programming things have to happen fast, or the thread blocks. With actors a request may be sent this week, and you may get an answer next month. Things can happen very fast, or very slow, the model is not biased. How fast is fast enough is now entirely up to your app's domain logic.

Also, some Actors implement persistence (which is far more trivial than trying to persist the callback graph or call stack in "normal" code), so they don't even care if the system shuts down and it has to start over from its last state.

Imagine OrderActor sends a call to FraudCheckActor and then the system crashes, or (if it's a business workflow process) it's just powered down for the night. When the system is restarted, OrderActor is already waiting for that answer from FraudCheckActor.

Do that with imperative/synchronous code.

This guy seems uneasy with Actors. His example is wrong and then he tries to solve it with a solution that's worse than the problem he thinks he has.

Let's untangle that stuff. Actors are about conversations between folks organized, like you would find in a good company. So let's use the conversation metaphor.

His example of "classical" actors:

- PaymentActor (to herself): Someone told me to process a payment from this order. I'm done.

- PaymentActor: Hey, FraudCheckActor, check if this order I'm giving you is a fraud.

- FraudCheckActor (to herself): Damn, this is a fraud.

- FraudCheckActor: Hey, CancelOrderActor, cancel that order I'm giving you!

- CancelOrderActor (to himself): I canceled the order.

Now I see an immediate problem here. This is anarchy. No one is in charge of the whole process, everyone runs to talk to someone else, and passing around that order data and there's no conversation happening here. Would someone in a real company organize things this way? Not in a good company, for sure!

Let's see what his solution is:

- PaymentActor (to herself): Someone told me to process a payment for this order.

- PaymentActor (screaming): Everyone! Payment is complete for this order! (screams the order info to everyone)

- FraudCheckActor (to herself): I heard that, I'll check it. Damn, this is a fraud.

- FraudCheckActor (screaming): Everyone! This order is a fraud! (screams the order info to everyone)

- CancelOrderActor (to himself): I heard that, I'll cancel that order.

- CancelOrderActor (to himself): I cancelled it.

Now I see an even bigger problem here. It's still a god damn anarchy, but now also everyone is screaming at everyone, including the entire order data, or talking to themselves. How is this better again?

Plus notice, there's still state in the system - the subscription setup. The only thing achieved here is that it'll be nearly impossible to reason about how this thing works once it becomes more like a real-world scenario.

Here's how you design it with Actors, once you have some experience:

- OrderActor: Hey, PaymentActor, process this payment and tell me what happened.

- PaymentActor: Hey, OrderActor, I processed it. It's good!

- OrderActor: Hey, FraudCheckActor, check this order for fraud and tell me what you found.

- FraudCheckActor: Hey, OrderActor, damn! This is a fraud!

- OrderActor: Hey, CancelOrderActor, cancel that order and tell me when done.

- CancelOrderActor: Hey, OrderActor, I canceled it!

Now what do we see here? We see structure. We see clear responsibilities. We see teamwork. No screaming and no chaos. Only OrderActor has the entire order data. He's passing along only the needed bits to each actor according to their responsibilities.

And best of all, PaymentActor, FraudCheckActor and CancelOrderActor are not coupled to each other. They just respond to their events, limited to their own responsibilities.

Good job OrderActor & co.

OrderActor is a supervising actor (that's an actual term). In my example, he's managing the workflow and he is stateful and as you see it's not that scary and out-of-order as the author is telling you. After all, he needs to know the payment went through, and then remember to ask for a fraud check and know what to do after that.

(Note: technically the supervisor in this example doesn't have to have state, he can just react to the events by Payment, FraudCheck, and Cancel, but this only works in this very simple example. Real world scenarios never fit into a completely stateless world. We're talking about the order state here!)

The other actors have no state (that is seen in this example). So proper design isolates concerns, and may have stateless actors, but stateful actors are essential to the model.

Of course, the linked article demonstrates how you can shoot yourself in the foot even with the best model out there. I find it ironic that the author was unhappy with over-complications and coupling, yet coupled everything in a complicated way with his "subscriptions" model, instead of simply using a supervisor.

The irony of building a game for iOS which is a clone of a JavaScript game which a clone of an iOS game doesn't escape me.

Well, don't worry, malware writers will generate enough bitcoins to sustain the system.

The cost of mining to them is practically zero.

Internet outrage - one the most promising resources of the 21st century.

It's cheap, it's renewable, and the Internet is producing more of it than we can handle.

If we could figure out how to power engines with Internet outrage, we'd solve all of our world's problems.

Right now it's mostly producing angry tweets and protest pages, but I'm sure if we work together we'll figure it out, eventually.

Until then, keep the outrage coming! I believe in outrage!

Well I'll give you this example.

If Facebook would release 3 Facebook apps, where each has mostly the same features, but slightly different, and on top of that each requires a different user/login, that's definitely fragmentation.

Say, you can argue WhatsApp and Facebook Messenger, or Instagram and Facebook picture posting represent fragmentation for Facebook, as they do mostly the same thing, but are each in their own space and with their own APIs and their own users etc.

Another example. iOS having lots of apps in one App Store is not "app store fragmentation". But Android having many separate app stores, many apps in each being the same (but tweaked or different versions) is "app store fragmentation".

Fragmentation is having multiple incompatible versions of the same thing, namely, two apps which both have a Facebook chat.

Now there'll be one app with Facebook chat and one Facebook app without chat. No fragmentation.

This is why the description is good.

Sure, it tests whether you can write a set of statements a computer can understand.

But it also tests whether you can understand the intent behind a set of statements a human would make, without going on a diatribe about how the definition is not good enough.

After all, if English was a formal strict language where only one right way existed to express something, we wouldn't need programmers, would we?

I realize it, right.

But I hoped you'd see beyond the direct comparison of lambdas with Objective C's blocks.

I'm saying that short code doesn't automatically translate to more readable or better code, Objective C's message syntax is the proof (if I have to be painfully specific about it).

I write a lot of JS and typing out "function" or "return" was never on the list of things I found a problem, despite I also work in C#, which uses the short => variation.

So, I don't get what the fuss is about. It port scans users, and does nothing interesting with it.

But on the other hand, we're talking about Slashdot. I've forgotten it exists. Maybe that was the purpose of all the hot air.

There's no honest attempt to explain the philosophy behind every language with real-world examples in Python. It's just childish jokes.

It's the equivalent of saying "Ze fish in le river" is "Frenchish English". Ha ha, stupid French people, right?

It's easy to make fun of programming languages like this, but what does that teach us? Aside from to mock what is different than what we use right now?

So what's if it's shorter. You'll run out of screen? You'll wear down your keyboard?

If you don't like typing it, have a macro. Otherwise, as Objective C shows, the verbosity of code is not relevant at all. It's what it says and what it does, which is.

Just like people believed the Universe revolves around Earth, they still have this naive believe that they're the center of intelligence in the Universe. Any other display of intelligence is explained as a combination of simple chemical, mechanical and electrical processes. But don't be quick to judge humans, though, after all, their brains are built on a combination of simple chemical, mechanical and electrical processes themselves.

Yeah, pleading ignorance was a neat way to word it, I admit.

The guy is a sleaze-bag, who chose to attack an open source browser (with an important role for the future of the internet, and the work of thousands) through his business for the benefit of getting positive PR for his business.

I wonder if Brendan Eich had this mentality, how he'd spin it. "Oh, I apologize, I thought Prop 8 was about supporting the gays, damn. I didn't do my research!".

But he doesn't have this mentality. So he instead chose to abandon the work of his life in order to preserve it, a rather painful action, as his spin-skills and spin-will were insufficient.

It basically means that those of us who are willing to...

1) Attack others for their political actions for PR reasons.

2) Engage in the same type of political actions.

3) Lie they were ignorant about it.

4) Say "sorry" without feeling any guilt.

... have a huge edge on those honest people who just say things as they are, without spinning things.

Damn, no wonder sociopaths are ruling the world, huh?

You had to Godwin this, didn't you!

But I wouldn't hurry to pile on Hitler before I know if he apologized. What if he had apologized? That really changes things.

I think we can safely stop thinking about the morality and legality of our actions, as long as we just apologize regularly.

Here we have two people who have both performed actions which are both indirectly anti-gay. But one is let go due to an apology, and the other wasn't due to no apology.

Apologizing is like a mark-and-sweep garbage collection approach to our past perceived sins.

Accountability (and reference counting) is boring and takes a lot of resources.

So we should just apologize.

BTW, I apologize for everything.

I also sincerely apologize for this post. Forgive me.

In short, private virtual addressing is legacy cruft from a time when this was the only way to organize things due to a constrained memory block identifier namespace.

Think about it like IPv4 vs. IPv6, i.e. hacks like NAT, vs. "everything has its own IP address in a single flat address space of IPs".

It's the same, but with computer memory. And it has the same benefits.

It's typical for crypto algorithms to generate an endless (or extremely large) "keystream" by permutating a much shorter secret key with other data somehow.

The fact they're not using the term "keystream" for this concept is a bit of a warning that they might've reinvented something every cipher algo already does, but more inefficient (from skimming through the paper).

Just guessing though. Not judging. I'm not a cryptographer, I just read about crypto as a hobby (and to know what I'm doing while using someone else's crypto primitives in my code).

The quote actually goes back much earlier, to the days where writing a program meant writing machine code routines.

And it's also highly misunderstood, because it's used as a mantra, out of context.

Good development is not mantra-driven.