unscaled

72 ms·

511.
by unscaled 9y ago
If you are a small shop, you just don't have the money to file a patent claim against Facebook. That's exactly what the parent post told you: patent litigation is expensive. The PATENTS file is red herring. If you're a small
512.
by unscaled 9y ago
Well, if your policy allows installing random apps from the Internet but forbids installing sandboxed and vetted apps, then you're not making any sense, regardless of whether the latter type of apps may still be a risk.
513.
by unscaled 9y ago
OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild
514.
by unscaled 9y ago
Calling MPC-HC just a DirectShow frontend is almost as inaccurate as saying mplayer is just a UNIX frontend. Just as mplayer is using POSIX APIs, MPC-HC is using the DirectShow API to run its filter graphs, but it actually provides a lot of
515.
by unscaled 9y ago
We should be just satisfied with TOTP, to be honest. It's just 6 digits by default, and unless you've got good anti-bruteforce protection, it can be broken in a matter of hours to days by just trying enough combinations. I'm
516.
by unscaled 9y ago
Interesting, I didn't realize that. The JWT ecosystem (or JOSE ecosystem to be exact) offers a lot of other machinery beyond just having a key ID for key rotation like JWK and OpenID Connect discovery, but there's nothing preventi
517.
by unscaled 9y ago
Well, practically every JWT library developer thought otherwise, because they'll all verify the JWT based on the alg field, which means every careful implementation of JWT must validate "alg", but I'm afraid there are to
518.
by unscaled 9y ago
Depending on your situation, you've got only 3 reliable options, as far as I'm concerned. 1. You could just generate random session IDs (UUIDs or 128-bit base64 strings) and store them in your database or in a persistent cache lik
519.
by unscaled 9y ago
I generally agree with your conclusions, but I don't understand why you compare JWT to cookies. These technologies are completely orthogonal. JWT can be stored in cookies and whatever you put in traditional cookies can generally be sto
520.
by unscaled 9y ago
I didn't read the docs in depth, but it seems that the extra safety Pony adds over Go, Java and C# is null-dereference safety, data race safety, exception safety and deadlock safety. Go, Java and C# all suffer from all the problem abov
521.
by unscaled 9y ago
As someone in charge of reviewing all crypto code for a sizable chunk of my company, I've yet to see a single case of someone using encryption primitives correctly by naive developers. To tell the truth, I don't think I've ev
522.
by unscaled 9y ago
If PostgREST was a niche project with a single maintainer, I'd argue you're right - it's too risky to go with if you can't maintain it yourself. But once the project is large and popular enough (and PostgREST arguably is
523.
by unscaled 9y ago
Yes. If nonce reuse is expected and distinguishable messages are considered to be a problem, then you really need a larger nonce. AES-GCM-SIV was designed to be nonce misuse resistant while still supporting short nonces. That's why Cod
524.
by unscaled 9y ago
It's too bad IETF didn't at least specify a standard way to use XChacha20/XSalsa20 with Poly1305 for AEAD. As it is you have to rely on all implementations to: 1. Split the nonce and counter the same way. libsodium uses a 64-
525.
by unscaled 9y ago
As a heavy daytime user of Go, I kind of get what you're getting at. You gave as examples two of the most typical cases of Go boilerplatitis: Error handling and for loops. Of that, error handling definitely gets refactored to set state
526.
by unscaled 9y ago
The point that rand() detractors are trying to make, is that rand() is also bad for non-cryptographic purposes as well. Its badness vary with the implementation, but with the implicit seeding, thread-safety issues and bad distribution on ma
527.
by unscaled 9y ago
It goes without saying the determinism of PRNGs can be a very useful property. But if you need that property, you if can explicitly seed it from a random source, you can also explicitly seed it with 1 if you wanted. The PRNG/RNG distin
528.
by unscaled 9y ago
> Like I said, the objections are practical, not philosophical Russ Cox and Rob Pike keep repeating this mantra, but I don't buy it. No, I don't believe they object the idea of generics itself. And yes, generics pose practical
529.
by unscaled 9y ago
And how would you make sure Wikipedia honors that clear-text URI (instead of a different encrypted URI inside the request)? Even when using SNI (the optional extension that sends the domain name in cleartext), the web server fully entitled
530.
by unscaled 9y ago
No, Elixir is an entirely different language running on the same virtual machine as Erlang. It's as seeing a graph with Java usage going down, while Kotlin or Scala up.
531.
by unscaled 9y ago
It is a suitable alternative, where 'suitability' depends on your needs. For simple session management, it doesn't offer advantage over encoding all your claims as JSON and adding an HMAC-SHA256 MAC. But macaroons come to shi
532.
by unscaled 9y ago
I guess heartbleed gave everybody the wrong image, but most TLS vulnerabilities were vulnerabilities in the spec . The fixes to RC4, BEAST, SWEET32, POODLE, LOGJAM, CRIME, BREACH, BRICK, BORKED, BUSTED and whatever else you could think of
533.
by unscaled 9y ago
The problems with JWT are not related to MITM, XSS or CSRF vulnerabilities. You'll have to address these issues regardless of the type of token you're using. The problems with JWT can be divided into two classes: 1. Too many optio
534.
by unscaled 9y ago
I only made the comparison with NaCl because the OP did (and used the wrong primitive) and brought up Forward Secrecy as a major flaw in JWT. OP also mentioned JWT libraries ignoring embedded X.509 certificates as a problem if we're at
535.
by unscaled 9y ago
Well, if you're using authorization code flow, trust your TLS certification authorities enough, then yeah, it's probably safe, though you'll be definitely violating the spec: http://openid.net/specs/openi
536.
by unscaled 9y ago
Good writeup of what you should be careful with with regards to JWT. There are some inaccuracies there too. First of all, JWT doesn't support encryption at all - it's JWE that does that. It's an important distinction, since m
537.
by unscaled 9y ago
That's how I always implemented JWT, but I'm pretty sure the lazy implementer would get that wrong. I'm with you that a protocol should include some versioning mechanism, but it probably shouldn't have as many knobs as J
538.
by unscaled 9y ago
OpenID Connect is based on JWT: http://openid.net/specs/openid-connect-core-1_0.html#IDToken If JWT is too complicated and confusing, OpenID Connect inherits all that complexity and then adds some more.
539.
by unscaled 9y ago
Joel Spolsky famously praised this policy of backward-compatibility at all costs which he called "The Raymond Chen Camp"[1]. Many agreed with him, but I always thought that Microsoft compatibility ideals were too radical to be rea
540.
by unscaled 9y ago
We can probably blame misguided corporate IT policies for starting this trend, by blocking most of the outgoing ports and migrating many newer protocols to use TLS over port 443 (although it doesn't really have to be HTTP to bypass cor

More ›