Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



I was recently looking for a library that did this and couldn't find anything nice. I was surprised but also slightly disappointed to see that yt-dlp has essentially rolled their own (cookies.py [1]).

[1] https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/cookies....


I've used pycookiecheat successfully with Chrome on Ubuntu: https://pypi.org/project/pycookiecheat/

    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')


It’s open source so you could theoretically pull it out and generalize it… idk if anyone wants to manage that project (seems like a ton of work even for an open source project) but I’m sure it be interesting.


There's https://github.com/richardpenman/browsercookie. Also at least for firefox it's quite easy to implement in like 5 strings or so.


As much as I like this feature, it is scary on the other side how easy it is to essentially steal cookies - what yt-dlp can, so can malware.

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.


Oh yes, that's what I need as a user: files on my drive that I can't read.

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.


Linux does right? I believe this is how android works but you can set something up manually by creating a seperate user and changing the permissions on the browser cache/data folder, then run the browser as one user and yt-dlp as a seperate one.

There might be a more modern and streamlined solution for Linux, but in Windows land they also introduced Controlled Folder Access into defender.


1. Other OSes (at least linux) have user keychains.

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?


> 2. Once malware is running as your user, how do you expect to protect against that even with a keychain?

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.


If you really need security through isolation, have a look at Qubes OS.


Run browser under different user.

And have a look at AppArmor.


It’s annoying that this has been downvoted because having your identity in easily-readable files on your computer is literally worse than saving passwords in a text file: Passwords will prompt 2FA, notifications and whatnot; Cookies might just work, albeit temporarily.


While I see the problem with malicious applications pillaging your users home directory, let's not forget that being able to tinker and hack together things is also one of the greatest strengths of the desktop platform.


Yes please keep storing your passwords on the desktop just because the desktop platform is so great.

Your reasoning makes zero sense. You can keep the platform strong and still keep some information safe, no?

WTF HN


Availability is a fundamental part of security - if the information you wish to access is made unavailable to you, that is a security failure. If the only goal was confidentiality, we would turn the computers off and bury them in concrete.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: