Skip to content
This repository has been archived by the owner on Nov 15, 2017. It is now read-only.

Allow matching rules to HTTPS #43

Closed
insanitybit opened this issue Nov 11, 2013 · 19 comments
Closed

Allow matching rules to HTTPS #43

insanitybit opened this issue Nov 11, 2013 · 19 comments

Comments

@insanitybit
Copy link

Go to https://github.com (or any other https website)

Whitelist it.

Go to chrome://settings/contentExceptions#javascript

"github.com"

It should be "https://github.com".

This may be annoying so perhaps it would make sense to have matching be an option to be enabled by users?

Thanks.

@gorhill
Copy link
Owner

gorhill commented Nov 11, 2013

Hmm, that's an interesting point, which deserve more thinking. I didn't build the infrastructure to support protocol when looking up hostnames from white and blacklist.

Your particular example could be adressed using per-page permission:

  • Go to https://github.com
  • Click per-page persmission
  • Whitelist github.com

Result: github.com is whitelisted only when visiting a page starting exactly with https://github.com.

Another idea I had a while ago was to enforce the protocol of whatever the protocol of the top-page is (I don't see this requiring scary major change to the core of the code):

If visiting https://github.com and github.com is whitelisted, block all requests from the page which are not https. That would be a switch of course.

What do you think?

@insanitybit
Copy link
Author

How does one access the 'per-page permission'?

"If visiting https://github.com and github.com is whitelisted, block all requests from the page which are not https. That would be a switch of course."

A switch for this is essentially what I would imagine to be the simplest solution.

@insanitybit
Copy link
Author

Well, in retrospect that's the default behavior. If a page is HTTPS and a third party is trying to load HTTP content on it, a 'shield' appears in the URL bar.

This case is instead saying "If I whitelist HTTPS://github.com, the rules for https://github.com should not apply to http://github.com" not "If I whitelist HTTPS://github.com, do not allow non HTTPS content to load."

@gorhill
Copy link
Owner

gorhill commented Nov 11, 2013

Ok, in that case this is what the per-page permission currently does. It's the top-left icon in the popup menu.

It allows to create permissions which apply only to pages starting exactly with {protocol}://{hostname}. So if you are on https://github.com[...] and create per-page permissions, the permission will apply only to pages which URL starts exactly with https://github.com. I suppose per-prefix permission would be more accurate.

Permissions specific to a page prefix will never apply globally, and vice versa. When a per-page scope is created/removed, it is automatically persisted, no padlock required.

There is a visual cue when per-page permissions are in use: the top of the popup menu is blue, and so is the icon badge (that's the best I could come up with, I am no designer :-)

@insanitybit
Copy link
Author

Is there simply a way to make the default behavior site-specific permissions?

@gorhill
Copy link
Owner

gorhill commented Nov 25, 2013

In the current state of the code, that would be problematic, as when a page site-scope is created, it is automatically persisted, so going page site-scope by default would litter the storage I am afraid. But I certainly see you point, the nice thing with page site-scope is to confine whatever rules created for experiment purpose to that sole page site.

I really need to think more about this. At some point I had the idea of also offering the padlock semantic for the page site scope but I chose the simple on/off approach. I struggle a lot with UI considerations often, and here is also the case. In the current case I picture the user being completely confused as to why he needs to lock down the page site-scope. I don't know.. When I am unsure, I use the wait-and-see approach to think more about the issues.

@insanitybit
Copy link
Author

That's fair. It's not really a big deal.

For something like youtube, I would want it allowed on all pages because of embedded videos. But then for something like Facebook I really only want it to be allowed on https://facebook.com, and that seems to be the case more often than not for me. I use Google Plus for video chat, so I need to allow it, but I again use a per-site permission because I don't want Plus loading on every other site that it tries to load on.

It's not critical. Right now I'm just clicking the button a lot, but that's hardly a big deal.

@gorhill
Copy link
Owner

gorhill commented Nov 25, 2013

Just to be sure we are talking about the same thing.. As it is now, pagesite-scopes are always of the form [scheme]://[hostname], meaning the rest (path, query, fragment) is discarded. So if you pagesite-scope https://plus.google.com, the specific rules will be used for all requests made by a page starting with https://plus.google.com, you don't need to create a pagesite-scope for all single page on https://plus.google.com, it automatically applies to all pages on https://plus.google.com.

@insanitybit
Copy link
Author

Yep, I'm clear on that.

@denis-sokolov
Copy link

I really need this feature to be able to safely browse on insecure WiFi networks.
I want to allow cookies only on HTTPS protocol.

I can't find the feature mentioned in this issue, per-page permission.
This is how my popup looks:
screen shot 2014-07-04 at 13 35 12

What do I click to get per-page permissions? I tried github.com in the top left corner, but it did not work. GitHub uses HSTS, but with a website that's accessible on http and https after logging in over https, I was logged in on http as well.

@gorhill
Copy link
Owner

gorhill commented Jul 4, 2014

Per-page doesn't exist, it's per-site or per-domain.

How about HTTPS Everywhere? I tried to support scheme in scopes and this was just a mess, code and UI-wise. I don't plan to go back to that mess.

@denis-sokolov
Copy link

Your own comment, @gorhill, mentiones per-page. Perhaps that's gone.

HTTPS everywhere uses a predefined list of websites, which is dumb.
What about a website that's not on the list? I still want to prevent data leakage over http.
What about a website that doesn't have HTTPS? I'd much rather not be able to access logged in area than leak authorization over http. =7

@gorhill
Copy link
Owner

gorhill commented Jul 4, 2014

Per-page was my mistake.

Taking the scheme into account for scoping was a nightmare.

If you had a per-scope switch to enforce https, would that be useful to you? (When I say "enforce", I mean discard all requests which are not https, I wouldn't want to redirect blindly -- as it may not work etc).

@denis-sokolov
Copy link

Yes, that would solve it indeed.

@insanitybit
Copy link
Author

HTTPS-Everywhere already supports adding sites that aren't on its list, btw.

@gorhill
Copy link
Owner

gorhill commented Jul 4, 2014

Found this too: http://www.paulspoerry.com/2012/how-to-force-https-chrome/

Apparently you can force a website to always use HTTPS or nothing: chrome://net-internals/#hsts

@ghost
Copy link

ghost commented Jul 5, 2014

@denis-sokolov

I want to allow cookies only on HTTPS protocol.

This can be done within the browsers native controls, rather than an extension. Set it to block all cookies and then add the following rule in the exceptions.

cookies-nq8

@gorhill I believe that interface is only for testing. It's quite tedious to use and won't persist across closing and opening the browser, (the last time I checked anyway).

@denis-sokolov
Copy link

HTTPS-Everywhere already supports adding sites that aren't on its list, btw.
Apparently you can force a website to always use HTTPS or nothing: chrome://net-internals/#hsts

Both useful, but still not secure. They imply a manual check before going to each website. In that case I might as well check for protocol myself.

This can be done within the browsers native controls, rather than an extension. Set it to block all cookies and then add the following rule in the exceptions.

This is a great idea, thank you! This works.

@gorhill
Copy link
Owner

gorhill commented Jul 5, 2014

@maxrmp

This can be done within the browsers native controls, rather than an extension. Set it to block all cookies and then add the following rule in the exceptions

Nice elegant solution, and native in the browser. Thanks for the tip.

@gorhill gorhill closed this as completed Jul 5, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants