rl3

60 ms·

721.
by rl3 6y ago
The problem I have is they're attempting to sound authoritative via way of medical and scientific expertise while in fact having none, in addition to having a financial interest in pushing supplements. It severely impugns the credibili
722.
by rl3 6y ago
Sadly their planning is coherent and logical. This move will in turn support its goal of AI leadership by 2030.[0] I don't want to live in a world where such a dictatorship has a technological advantage so large they become the new sup
723.
by rl3 6y ago
> Lee Know, ND, is a licensed naturopathic doctor based out of Canada, and the recipient of several awards. Known by his peers to be a strategic and forward-thinking entrepreneur and researcher, he has held positions as medical advisor,
724.
by rl3 6y ago
> This would bug me less if their big ideas weren't Pocket and a VR chatroom. It's probably just Pocket; developers working on the latter were hit with layoffs today, too.
725.
by rl3 6y ago
Yeah, I completely agree equity is no replacement for proper salary. Just saying it's a really effective tool when combined with ideological motivation to fend off the unlimited pockets of FAANG-scale companies.
726.
by rl3 6y ago
Thanks for that, it's encouraging to hear. While I've no experience in the corporate world proper, as a solo founder 7 years into the same project I've a similar game plan with respect to talent, and just hope one day to have
727.
by rl3 6y ago
That's where equity comes in. However, equity is only worth something in any practical sense if it's fair and the employee truly believes in what they're doing. Most startups offer joke equity that's subject to dilution
728.
by rl3 6y ago
My experience in daily use of Firefox post-Servo is that all page loads have essentially been instantaneous. This is of course subjective based in part on hardware, so I'm not disputing your assessment. As far as I'm aware, Servo
729.
by rl3 6y ago
Surreal. Even the Servo team was disbanded. Mozilla Research effectively no longer exists. That alone says everything. This is a dark day for the open web.
730.
by rl3 6y ago
Can you elaborate on this? Because I remember the day Firefox became fast with an incredible amount of fondness, and that moment owed in large part to Servo.
731.
by rl3 6y ago
Being on the receiving end of poaching is simply a failure to compete in arenas beyond compensation. Not only must you compensate your talent at the top of the market and then some (including generous equity), but you must give your employe
732.
by rl3 6y ago
The first screenshot reminds me of Fleet Defender (1994): https://www.gog.com/game/fleet_defender_the_f14_tomcat_simul... Now of course supplanted by DCS: F-14.
733.
by rl3 6y ago
> You have responded in the wrong place. I'd say it was the correct place. > If the client-side hashing were not performed at all, it would still be impossible to correlate user passwords with other passwords in database dumps.
734.
by rl3 6y ago
> What are you talking about? The utility of client-side hashing. > No, this is just gibberish you made up to put in my mouth. It was actually a good faith attempt to frame your argument.
735.
by rl3 6y ago
> With the server-side hash already blocking this attack, the client-side hash is adding absolutely nothing. We're saying that the protection afforded by server hashing schemes can in some cases be completely bypassed by raw user p
736.
by rl3 6y ago
> A hash algorithm is not a supernatural function which changes the metaphysical character of data. Again with the condescension. > And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent
737.
by rl3 6y ago
> The Truth Is Paywalled But The Lies Are Free Claims the article not behind a paywall.
738.
by rl3 6y ago
Not necessarily. There's things that should've existed decades ago that still do not exist. It often isn't a matter of technology, so much as the vision and will to bring something into existence. Bill English was instrumenta
739.
by rl3 6y ago
> Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. Yet it does help, because if your server is exploited, the attacker can potentially read th
740.
by rl3 6y ago
> If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2 ... By your own words it's already been run through one hash algorithm. Even considering it's being hashed again on the
741.
by rl3 6y ago
> Don’t forget about the main point: hashing and salting on the client side does not replace doing the same thing on the server side. Per my original, top-level comment: "For that reason, it's a good idea to salt and hash pass
742.
by rl3 6y ago
> If you compromise the server, you’re well past caring about the individual passwords anyway because you can just serve a version of the client code that doesn’t hash on the client side. What if the client files are delivered via CDN,
743.
by rl3 6y ago
Thanks. That was a really clear and concise explanation.
744.
by rl3 6y ago
> You, rl3, are just misunderstanding what a password is. On the contrary. I also suggest sparing the theatrics next time. > ... then the user's plaintext password is 200820e3227815ed1756a6b531e7e0d2. "In cryptography, pla
745.
by rl3 6y ago
> The only threat model this would actually address is a threat from the user himself. Incorrect. Please refer to other comments in reply to you.[0][1] > It doesn't introduce a weakness, but it's a sign that you don't
746.
by rl3 6y ago
> You're assuming that the attacker controls the connection with the user. I am making no such assumptions. > Such an attacker is free to serve a login page that sends the unhashed password, and read that. Depending on the natu
747.
by rl3 6y ago
> This is literally impossible to avoid. Whatever the server receives, that's what the password is. Hence why I specified no knowledge of the plaintext password, which is absolutely possible to avoid sending over the wire.
748.
by rl3 6y ago
> What's the threat model you have in mind for salting and hashing on the client? If your server is compromised, you don't want it handling plaintext/raw password input from your users.
749.
by rl3 6y ago
> ... why they’re not hashing passwords inside of their database? Sending passwords plaintext over the wire isn't good either, even with TLS. You don't want your server to have any knowledge of the plaintext password. For that
750.
by rl3 6y ago
One side effect of the traditional funding model is that it allows FAANG-scale companies to exist in perpetual monopoly, because it gives them the luxury of crushing, copying or acquiring any potential threats early on. Both vision and basi

More ›