Software can be usable but 'incomplete', in the same way that stools and Aerons are both usable, but stools weren't an unfinished technology. If your bug count is low and your software has features, it's already done.
It seems like your suggestion is a little backwards -- computer science is its own thing, and for some reason, people started thinking that computer scientists are ideal software developers. Since that clearly isn't the case, employers should look for some other certification that's more in line with what they require from an employee.
That book was created before many alternatives came out; now if you are working in a team project you should look at JavaScript the same way you look at assembler, you know it will be the final thing but you shouldn't be creating it directly, but instead "compiling" from TypeScript, ELM, etc. (langs with no implicit conversions, strong typing, etc)
Those alternatives are nice in startup land, in enterprise consulting land, we get to use what the customer IT department sanctions as allowed programming languages and tools installed on computers for external consultants.
Isn't the idea of network neutrality to prevent discriminating between traffic sources, not quantities? I.e. providers can still charge an arm and a leg for heavy users, and allow 'light' users to pay significantly less (maybe based on some non-linear scale?)
Yeah, but anti-neutrality people tend to try to create the other narrative. Popular metaphor I've seen is "net neutrality is like telling the post office they have to charge the same for a large heavy package and an envelope". Which is not true, you have to charge the same for each heavy package regardless of what is in it, but you can still charge more than an envelope.
So this is definitely down to how you define the word, but by the above definition, shouldn't Globally Unique Identifiers be called Globally Distinctive Identifiers?
Also, because my brain has been damaged by modern programming languages, it seems like uniqueness should be defined as (please excuse my rusty logic syntax):
R = resumes, r \in R, unique(r) -> (\forall s \in R-{r}, r != s) (for some definition of equality).
Still learning about this, but couldn't you:
1. Sign a cookie.
2. Store revocations in a database (remove after session expiry time).
3. Use a distributed bloom filter to avoid db hits for every request.
?
Yes you could, but you still end up with this dependence on a lookup when you store revocations.
Once you do that you lose the stateless benefit of cryptographically signing the object, and at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.
A table of unexpected revocations will be smaller and less write-intensive than a full table of sessions. Should be by a very large margin. And eventual consistency is fine.
So that could be the difference between whatever you're using for storage, and a tiny, fully replicated in-memory structure. Depending on your overall scale, of course.
> at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.
Only if the collision of lookup IDs (accidental or malicious) is effectively impossible. If it's possible to generate a collision, then you've thrown away your security.
This would also effectively give every server the ability to issue auth tokens (and mutate them in the DB), which is not a great choice if you care about security. But if you're handing out unsigned lookup IDs, you probably don't.
What purpose could signing a lookup ID possibly serve? Are you worried that someone might correctly guess the 128 bytes of the identifier and hoping they won't guess the 32 of the signature?
And actually, yes, if I were using 128 byte identifiers for some reason, I would still be concerned about malicious parties being able to cause collisions. Securely generating random numbers does not seem easier than authenticating.
Just to chime in since I'm the OP of this subcomment.
Generating 128 byte identifiers is ridiculously overkill. I can safely say if you generate 128 byte identifiers securely, the earth will cease to exist before a collision is found.
You would be safe generating cryptographically secure 128 bit identifiers and looking them up. It is trivial to generate IDs that will not collide.
Depends entirely on how well you generate your IDs. Yes, if you generate cryptographically strong IDs of sufficient length, then you don't need to sign.
Signing avoids the need to generate secure IDs, though, and can also avoid hitting to the DB for expired tokens. (Load from expired tokens is probably not a major concern, though.)
