Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: cookie api #1802

Closed
simonzack opened this issue Sep 7, 2013 · 8 comments
Closed

Feature Request: cookie api #1802

simonzack opened this issue Sep 7, 2013 · 8 comments
Milestone

Comments

@simonzack
Copy link

I propose a cookie api. The motivation is to remove the "NID" cookie at google.com to reduce tracking, while leaving the "PREF" cookie intact. The problem with document.cookie is that it is only shows the "PREF" cookie and nothing else, since the "NID" cookie belongs to ".google.com". Firefox also doesn't seem to support this functionality natively, and is only to disable on a per-domain basis.
Some api, possibly with restrictions to which domains can be accessed, will be helpful in this case.

@arantius
Copy link
Collaborator

arantius commented Sep 8, 2013

The NID is not visible in document.cookie because it is httponly=true. I bet you can override it with your own dummy value though.

@arantius arantius closed this as completed Sep 8, 2013
@simonzack
Copy link
Author

I could override it on the current domain, but not on the google.com domain. So I believe that this can still be considered, since cookies are often used to track users.

@simonzack
Copy link
Author

Can this issue be re-opened? Even if I were to override the cookie, there is, say, no way to list cookies on the current page. Userscript access to http cookies can solve this, say for example by using a GM_cookie() api.

@arantius
Copy link
Collaborator

Of course it can in theory. But Greasemonkey's philosophy for some time now has been to embrace the forward progress the web itself has been making as a platform, to encourage usage of "HTML5" APIs and discourage custom APIs (grandfathering some in). A strong case would help.

(IMO sites don't use HttpOnly by accident, it is an intentionally implemented security feature. So the case would probably be hard to make. And nothing stops you from making a site specific extension if you need access to lower-level APIs and are willing to be Firefox only as a result.)

@Kagami
Copy link

Kagami commented Mar 19, 2016

Sorry for commenting in such old issue.

I bet you can override it with your own dummy value

I tried it and seems like it's not possible. While browser keeps some cookie with HttpOnly flag, you can't neither access nor overwrite it from JS.

A strong case would help

Not sure how strong such case is, but I need to remove cookie from userscript in order to avoid meaningless redirection at one specific site. And currently it's not possible because it is set by serverside with HttpOnly flag.

@bombledmonk
Copy link

I'll put up a weak example scenario. I'm scripting on a page on which there is a whole host of cookies. One cookie causes the entire website to render differently due to some weird design choice; the cookie is set by logging into a certain part of the website without the ability to logout anywhere. Given this cookie is set with an httponly flag I cannot fix using the standard document.cookie method. It would be nice to have a GM_cookie or something similar to be able to set/override/delete cookies that are otherwise protected via httponly.

@arantius arantius reopened this Aug 4, 2016
@arantius
Copy link
Collaborator

arantius commented Aug 4, 2016

I've run into a few situations where I'd like to do cookie manipulation that document.cookie wasn't sufficient for, also. There's a lot of things to consider for how to do this well...

@arantius arantius added this to the 3.10 milestone Aug 4, 2016
@janekptacijarabaci
Copy link
Contributor

janekptacijarabaci commented Aug 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants