> NEW FEATURES
> Cookies from browser: Cookies can be automatically extracted from all major web browsers using --cookies-from-browser BROWSER[:PROFILE]
Very nice. Having to manually copy cookies to get past login walls is annoying.
> Cookies from browser: Cookies can be automatically extracted from all major web browsers using --cookies-from-browser BROWSER[:PROFILE]
Very nice. Having to manually copy cookies to get past login walls is annoying.
[1] https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/cookies....
chr_cookies = pycookiecheat.chrome_cookies('https://example.com')
session = requests.Session()
for k, v in cookies.items():
session.cookies.set(k, v, domain='.example.com')Why don't OSes have some sort of system-wide secret store linked to an user's account (like the macOS Keychain) and an application's code-signing certificate? That would at least prevent easy file-dump attacks, moving the barrier to "execute something in the browser process context" instead.
There might be a more modern and streamlined solution for Linux, but in Windows land they also introduced Controlled Folder Access into defender.
Your reasoning makes zero sense. You can keep the platform strong and still keep some information safe, no?
WTF HN
It's enough that I already can't read the data that's being sent and received by my own computer, because of certificate pinning.
2. Once malware is running as your user, how do you expect to protect against that even with a keychain? They can log all your keystrokes, extract certificates and keys from applications running as your user or anything your user has access to, etc.
3. How are you going to support different keychains on different OSes? And what happens when they diverge? Say Apple gets "brave" again and allows only Apple signed binaries to access the keychain with the excuse of "user security", will binaries have to roll their own keychain? Are you going to make apps add another corporate dependency?
A kernel-backed mechanism could enforce that access to the secret decryption syscalls can only be done from untampered signed processes.
Assuming an user has a distinct login password they are not using anywhere else and the public key of the codesign certificate is part of the kernel-side secret, a malware has no chance of getting access to the secret, unless it exploits a code execution vulnerability in the target program.
> How are you going to support different keychains on different OSes?
A minimal interface with three calls: 1) create/delete a kernel-side secret, 2) encrypt a secret using a key derived from the user's keychain and the application's public key, 3) decrypt a secret using said key.
Android brings such an API (KeyStore), macOS' Keychain should support something like that via its ACL feature. Where additional work is needed is Windows (its DPAPI only protects secrets from other users, apps can get other apps' secrets by design to implement SSO) and Linux (which doesn't have any way to verify in the kernel if an application has a code signature).
Browsers and other apps wishing to protect secrets from malware could use an abstraction layer that uses the best available mechanism on each platform, the three operations should be enough for this purpose.
And have a look at AppArmor.