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

Please auto-whitelist based on site policies / permissions #43

Closed
rmenessec opened this issue Jun 13, 2017 · 18 comments
Closed

Please auto-whitelist based on site policies / permissions #43

rmenessec opened this issue Jun 13, 2017 · 18 comments
Labels
browserbug/limitation Currently not fixable due to browser API limitations

Comments

@rmenessec
Copy link

I would love to use this, but it appears to be missing a crucial feature that Self-Destructing Cookies appears to have: the ability to whitelist / ignore sites based on the site preferences.

(Mozilla documentation refers to this as 'policies', 'preferences' and 'permissions'. The actual site data appears to be stored in permissions.sqlite in the user profile director(ies).)

To clarify: my default Firefox cookie policy is to allow only session cookies, and then I use Cookie Controller to grant some individual sites permission to set long-term cookies. In other words, I treat cookie policy like a deny-by-default firewall with individual exceptions. Alternately, it's like using NoScript, but for cookies.

I don't know whether the Firefox WebExtensions API allows access to read or set site permissions. I know that it's been possible to view the data in the past; for example, with the Site Preferences addon, and I thought that there was a Firefox-internal UI for viewing this, but I can't find it right now.

Any idea whether it's possible to add this ability? If so, this would negate any need or want to import SDC's whitelist; Firefox already has a whitelist for nearly the same purpose, and I'd prefer simply to keep using that, instead of reinventing the wheel.

Thanks!

@B00ze64
Copy link

B00ze64 commented Jun 14, 2017

Funny, I installed Cookie-AutoDelete in Chrome, looking for something like SDC. Immediately I opened a bug here, requesting that Cookie-AutoDelete use the WhiteList built inside Chrome, rather than keep its own list of exceptions (if you add uMatrix that makes 3 lists to maintain!) Unfortunately, this was not possible in Chrome. Mrdokenny said there was no API for that, and of course, cannot do anything without WebExtensions giving you explicit methods to do so. I'm hoping Firefox will be more flexible, but if the Author wants to keep the extension as generic as possible so it works unmodified with both FF and Chrome then he may elect to keep his own separate WhiteList...

@ke-d
Copy link
Member

ke-d commented Jun 14, 2017

Mostly what @B00ze64 said.

I'm trying to make the extension core as browser agnostic as possible. In addition, implementing my own whitelist allowed me to implement Containers Mode and also allow me to implement #20 in the future.

Also to my knowledge, Firefox and Chrome do not have an easy way of exporting those whitelist that is built into them. Where in Cookie AutoDelete, you can export the whitelists and its useful for when you need to refresh the profile, use another computer, or even switch browsers. :)

@ke-d ke-d added the wontfix/cantfix This will not be worked on label Jun 14, 2017
@rmenessec
Copy link
Author

rmenessec commented Jun 14, 2017

@mrdokenny , I think you may have misunderstood. I'm not asking for import/export—I'm asking if the Firefox implementation can take the existing Firefox per-site cookie policies into account when deciding whether to auto-clean cookies for a given site.

Very simply, using pseudocode:

if site.cookiePolicy != LONG_TERM then expungeExpiredCookies(site)

Instead of deciding to destroy a site's cookies based solely on a timer and an extension-specific whitelist, I'm asking if you can add one more test—an existing list already maintained by Firefox—when deciding when and whether to destroy the cookies. That existing list doesn't need to be extracted or transformed; merely read and considered. Your extension wouldn't need to modify, edit, write to, or otherwise maintain the list.

What I'm trying to say is that Firefox, on its own, can already do almost exactly what your extension proposes to do. The only significant difference—the reason I'd like to use your extension—is that your method of dealing with cookies means I can expire cookies faster, and without shutting down or restarting Firefox.

@ke-d
Copy link
Member

ke-d commented Jun 14, 2017

@rmenessec No, there's no WebExtension APIs for that as far as I know. If they ever add such an API, it would be a nice addition.

Personally I only use Cookie AutoDelete's whitelist and don't bother with the built in.

@rmenessec
Copy link
Author

Well, I'd submit a bug to request the API be extended for this, but the Mozilla developers only respond to requests from actual extension developers like you. 😉

@ke-d
Copy link
Member

ke-d commented Jun 14, 2017

Sure but they probably won't consider it until after FF 57 since they apparently have a lot to do now till 57.

@ke-d ke-d added browserbug/limitation Currently not fixable due to browser API limitations and removed wontfix/cantfix This will not be worked on labels Jul 2, 2017
@cb474
Copy link

cb474 commented Nov 8, 2017

I'm not sure if I understood everything in this thread. But it would be nice at least when first installing Cookie-AutoDelete to have it import the already white listed cookies from Firefox's "exceptions" options in the preferences. It's frustrating to have to redo years worth of whitelisting. This was something, for whatever reason, that Self-Destruction Cookies didn't have a problem with. I understand the desire to make the exstension browser agnostic. But that can also lead to some lowest common denominator type of solutions.

@welwood08
Copy link

At first glance, it appears the webext API that would enable reading and setting per-site cookie policy is contentSettings.
Firefox implementation doesn't exist yet.

@cb474
Copy link

cb474 commented Nov 9, 2017

@welwood08 Maybe we're not talking about the same thing? Because what I'm thinking of and described above Self-Destructing Cookies had no problem doing. And the Firefox bug you link to was first posted for Firefox 47, well before legacy addons like Self-Destructing Cookies became incompatible with Firefox.

@welwood08
Copy link

@cb474 SDC had no problem doing the things it did because it was a type of extension that had full access to Firefox internal functions. When Firefox 57 is released an a few days, all the older extension types will be disabled and the only thing allowed will be webextensions.

@cb474
Copy link

cb474 commented Nov 9, 2017

Oh, okay. Thanks for the explanation.

@ElectricFeet
Copy link
Contributor

Not a coder (not much of one anyway), but from a Firefox user perspective:

Firefox — in its "Preferences > Cookies > Exceptions" panel allows you to add sites and give them a status of "Allow" or "Allow for session", while blocking all other sites from storing cookies at all.

This built-in status was read / set by other cookie managers — @rmenessec mentions Self-Destructing Cookies ; I used Cookie Monster.

While I understand that you want to make Cookie-AutoDelete browser agnostic, it would be great if at least there were some way to do a one-time import of statuses already stored in Firefox.

I like the look of Cookie-AutoDelete, but the idea of re-doing all the whitelisting for my favourite sites for Cookie-AutoDelete is daunting, to say the least — especially for time-critical/reload-sensitive stuff like payment gateways, which cannot be done on the fly without hitting problems.

Does the API allow read-only access to this info, so it can be imported once?

Thanks!

@Johann-Tree
Copy link

I was able to do a manual import but for non advanced users it would be nice if there would exist an automatic option.
This is how I did it: Using SQLiteManager I exported the database permissions.sqlite from the Firefox profile to CSV. Then I filtered for lines containing cookie as type (third row). Then I removed the protocol-prefixes (https:// and https://), deleted all rows except 2 and 4, removed unique lines, and then generated the json file according to #238. This was done by replacing
(.*),1 with

{
       "expression": "$1",
       "listType": "WHITE"
     },

and
(.*),[89] with

     {
       "expression": "$1",
       "listType": "GREY"
     },

.
After that I just removed the last comma, added

{
   "default": [

to the beginning of the file and

  ]
}

at the end.

Then I was able to import that json-file!

@ElectricFeet
Copy link
Contributor

That’s exactly what I did. So it’s good to know that what I thought was an overly-tedious export/import process was as good as it gets!

Glad the .json file format helped you skip some of my trial and error :)

@endlos99
Copy link

I also vote for removing white/greylisting from the extension entirely and using the built-in cookie settings instead.

@gwvr
Copy link

gwvr commented Nov 24, 2017

There seem to be two issues here:

  1. Firefox 57 doesn't support the WebExt API functionality required to read and write cookie handling exceptions
  2. Firefox cookie exceptions dialog doesn't permit wildcards

IDK if Chrome supports wildcard cookie exceptions, but it'd be great if the Firefox developers could implement both wildcards, and the WebExt API functionality required to set them.

@rmenessec
Copy link
Author

@gwvr , not so much # 2. Cookie exceptions through at least Firefox 56 take the form—or are displayed in the form—"https?://domain", where the domain can be a TLD. For example: "http://github.com". This example allows cookies to be set for sites matching the regex "http://.*.github.com".

I'm reviewing my cookie exceptions, and there are zero subdomains below the TLD level, out of an exception list built over many years. The exceptions were set with a mix of the native Firefox dialog and various cookie-handling extensions. From memory, entering a subdomain by itself results in an entry that's prefixed with "https?://domain", at least visually.

There is, however, a mix of https:// and http:// sites. I don't know whether or not Firefox enforces HttpOnly and/or Secure flags based on the URLs. I would assume that the URL prefix will determine whether the cookie exception is allowed over HTTP or HTTPS.

Also, yes, Chrome natively supports some form of regex matching. I don't know if it's safe to assume full regex, or whether it's JavaScript-flavored. If you switch Chrome to default-deny mode for cookies and tell it to create an exception for the current site, the regex would look like "https://[.]www.example.com" as saved and displayed, if the current site is www.example.com. At least, that's the way it's worked in the past, some versions ago. I'm on a machine with Chrome set to default-accept mode, and the newer browser chrome is pre-filling the exception dialog with "[.]example.com" as a suggestion.

@kennethtran93
Copy link
Member

As this issue is blocked by browser limitations, I'm going to close this issue. If and when extensions can access site policies / permissions, then feel free to revive this or start a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browserbug/limitation Currently not fixable due to browser API limitations
Projects
None yet
Development

No branches or pull requests

10 participants