Browsers are just mini OSs at this point. It’s probably best just to accept it. Honestly in some respects (security, isolation, resource management) they do a better job than the operating system they run on top of.
Even as a user I don’t there’s a good reason to love cert pinning. If you’re going up against adversaries that can compromise web pki they also probably have some other exploits up their sleeve to pwn you.
Cert pinning pretty much serves to protect companies from people reversing their protocols and little else imo.
As a westerner I can only speak for others a little bit, but this is a very western perspective. Even Kazakhstan has been caught doing sketchy stuff with their CA.
If it’s managed well, certificate pinning takes the web PKI out of the implicit trust envelope for your app.
From a pure security perspective, why trust someone you don’t have to trust? The web PKI CA bundle is great for cases where it’s hard to have a unique trust root for your application - like you’re running in a browser with no privileges - but if you’re distributing code then you’ve already solved that problem.
Managed well, it should be completely transparent to users as well. Managed poorly and it can be catastrophic (your app is dead until users upgrade it).
i agree, feels sort of like "we have a walled garden dont anybody else use it cuz our stuff is super secret and secure, trust us(tm)"; it's a layer of obscurity for their "security" - in reality its the app on a users pc that both has this "secrecy" as well a the "handshake" to open it
Write access to .bashrc is plenty to very sneakily get sudo access tho.
alias sudo='./.my-evil-sudo-binary'
And wait till the next time the user authenticates, they wont see anything amiss and you just silently delete the alias after you’ve got the sudo password.
Also even without root dumping .ssh and the browser’s cookie jar is probably plenty to achieve lateral movement and you don’t need root for that.
Hahahahaha. Yeah, sure cryptocurrency never comes crashing down. It certainly would never lose 60% of its value in 6 months. That would never happen. What a perfect store of value. /s
The math used in AES (Rijndael) utilize operations in GF(2^8) tho, so you're doing operations using Galois fields whether your utilizing GCM or CBC. I don't really see how adding the GCM mode utilizing GF(2^128) on top is significantly more difficult or error prone than implementing the AES block cipher itself. You should still be familiar with operations over Galois fields regardless if you've for some reason (foolishly imo) decided you want to implement AES cryptographic primitives on your own.
Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
The library used in this Javascript widget has AES already implemented, but not GCM mode.
> Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
I think that's generally the preferred solution, yes.
The fact that any Xorg client can become a key logger without any user input or authentication is a pretty big security hole imo.
By design Xorg has no isolation between clients so they can all read each others input, control others windows, and inject keystrokes into other applications. That’s unacceptable in the modern age and makes any attempt at sandboxing or separation of privileges for GUI applications completely pointless.
> The fact that any Xorg client can become a key logger without any user input or authentication is a pretty big security hole imo.
This "hole" doesn't exist. For an X client to capture input, it must be authenticated by either the unix user permission or by an access control list (where the default is to deny). Individual clients can also be marked untrusted which sandboxes them to some extent (though not as much as using a separate X server of course).
I'll grant that in practice, most the time these restrictions are very lax... in part because they can break some applications. But at the same time, in practice, it doesn't seem to matter that much since either you're running things you trust anyway or if a malicious application has access to your X connection they also have access to all your other files so you're in trouble anyway.
Apologies for not answering your question directly, but I'm pretty sure this is what XWayland does to allow for compatibility of X apps ontop of wayland.
Even when applying to companies that are LGBTQ friendly? I sometimes self identify on applications if the company has a good reputation with that kind of thing because I’d expect It would give me some diversity points. But maybe that’s not the best idea.
> Even when applying to companies that are LGBTQ friendly? I sometimes self identify on applications if the company has a good reputation with that kind of thing because I’d expect It would give me some diversity points. But maybe that’s not the best idea.
Pretending to be LBGTQ friendly is a good PR while changing actual company culture is hard, expensive and takes time. So don't get fooled by PR stunts and changed policies because they will always be eaten by real company culture.
reply