Poll

Would you like for PrivDog to say what it is blocking when click the icon for the extension, instead of only seeing how many of the categories it has blocked?

Yes.
12 (66.7%)
Yes with the added option under the edit.
6 (33.3%)
No.
0 (0%)
Don't care.
0 (0%)

Total Members Voted: 18

Author Topic: Show exactly what is being blocked when clicking the extension.  (Read 6394 times)

Offline Nige_39

  • Comodo's Hero
  • *****
  • Posts: 614
Re: Show exactly what is being blocked when clicking the extension.
« Reply #30 on: June 28, 2013, 09:04:24 AM »
I think it's because I allow ads from trusted sources which means that instead of blocking an ad it will replace it with an address to AdTrustMedia which HTTPS Everywhere does not agree with so HTTPS Everywhere redirects the element to some emediate or something url.

Edit: Yup, just tested with setting PrivDog to block all ads, then I get no conflicts. Heh though I still get conflicts for facebook button for an extension ??? I hate seeing that button in chrome go yellow/orange.


I see where you are coming from now, But it is still a mystery on what is happening on your system

Regards

Nigel 
Win 10 Home 64Bit, Opera Stable, CCAV, Ublock Origin, HTTPS Everywhere, Privacy Badger, Dcentraleyes, UntrackMe, Cookie AutoDelete.

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #31 on: June 28, 2013, 09:50:37 AM »

I see where you are coming from now, But it is still a mystery on what is happening on your system

Regards

Nigel 
I don't think it's that much of a mystery. I assume that PrivDog acts first on the element and redirects the element to point to adtrustmedia and HTTPS Everywhere acts later and tris to redirect the element to the https version of that ad and since it acts later it overrides what PrivDog did, OR it simply just has a higher priority somehow, does PrivDog use the "!important" thingy apparently Chrome has some thing I think it's "!important" and only other applications using "!important" can override an application that uses "!important" so it could be that HTTPS Everywhere uses "!important" and PrivDog does not? I really don't know but I don't think it's a mystery.
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #32 on: June 28, 2013, 12:17:52 PM »
Indeed however if the domain isn't in the list it will take you to the http instead of https site, right? In that case you might want to have something that redirects you to the https site ;)
Perhaps, but it might not be of such great worth and use as one would expect. See these FAQs:
https://www.eff.org/https-everywhere/faq
https://code.google.com/p/kbsslenforcer/wiki/FAQ#Is_it_secure_against_MITM/Firesheep_attacks?
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #33 on: June 28, 2013, 01:18:12 PM »
Perhaps, but it might not be of such great worth and use as one would expect. See these FAQs:
https://www.eff.org/https-everywhere/faq
https://code.google.com/p/kbsslenforcer/wiki/FAQ#Is_it_secure_against_MITM/Firesheep_attacks?
I see, but still if HTTPS Everywhere and HSTS does not have the site registered then it will use the http protocol rather than the https protocol so MITM attacks are still able to happen with HTTPS Everywhere, the only unique problem with KB SSL Enforcer is that it might take you to sites that don't work, for example if it seems like a site supports SSL and it actually doesn't have all the stuff on it. (and the weakness of having to make the first request unencrypted) So then it would be great if you could layer them to first use HTTPS Everywhere system and if it is not registered then try the system KB SSL Enforcer uses since I would argue that using KB SSL Enforcer would be safer than not using anything like that at all, and now couple that with PrivDog and we have a nice extension. :)
« Last Edit: June 28, 2013, 01:20:19 PM by SanyaIV »
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #34 on: June 28, 2013, 03:54:05 PM »
I see, but still if HTTPS Everywhere and HSTS does not have the site registered then it will use the http protocol rather than the https protocol so MITM attacks are still able to happen with HTTPS Everywhere
Not using https automatically does not mean you cannot use https, and I advise anyone to make sure https is used (if available) before exchanging information with a site. And though I think encryption should always be used, the real need for encryption varies depending on how a site is used. It does not matter much if you go to https://www.comodo.com or http://www.comodo.com if all you do is to browse the site. But using https://forums.comodo.com is important, not only when logging in, but also when sending and recieving PMs, for example.
the only unique problem with KB SSL Enforcer is that it might take you to sites that don't work, for example if it seems like a site supports SSL and it actually doesn't have all the stuff on it. (and the weakness of having to make the first request unencrypted)
Indeed make the first request unencrypted. You will probably not even notice that happens, and you will think that encryption was used all the time.
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #35 on: June 28, 2013, 06:10:00 PM »
Not using https automatically does not mean you cannot use https
I wasn't implying otherwise.
Indeed make the first request unencrypted. You will probably not even notice that happens, and you will think that encryption was used all the time.
Okay think about it this way:
Scenario 1: You do not have HTTPS Everywhere or KB SSL Enforcer but you do manually set websites to HTTPS when you visit them, the issue of first making unencrypted requests is there.

Scenario 2: You do have HTTPS Everywhere but not KB SSL Enforcer and you do manually set websites to HTTPS when you visit them, the websites known by HTTPS Everywhere will not make any unencrypted requests but websites not known by HTTPS (or HSTS) will still have the issue of first requesting unencrypted.

Scenario 2.5: You do have HTTPS Everywhere but not KB SSL Enforcer and you don't manually set websites to HTTPS when you visit them, websites known to HTTPS Everywhere will always be encrypted with no "leakage" however sites not known to HTTPS Everywhere will most likely always be HTTP instead of HTTPS which is more damaging than if just a single first requests were unencrypted.

Scenario 3: You do have KB SSL Enforcer but not HTTPS Everywhere, you have the issue of initial unencrypted request.

Scenario 4: You do have an extension like HTTPS Everywhere and KB SSL Enforcer combined, The sites known to support HTTPS would directly connect to that while sites not known would automatically test if HTTPS is supported, the issue of initial unencrypted requests is still there but you won't forget to change the site to HTTPS in either way and anything subsequent will always be via HTTPS if the site allows it.

So by merging them into one, in my opinion you don't really get anything negative, however you do the get positive thing of never forgetting to set the websites that support it to HTTPS.
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #36 on: June 29, 2013, 03:10:34 AM »
By “manually set websites to HTTPS when you visit them” you seem to assume that I would first visit e.g. http://www.polisen.se and then add the heroic s: https://www.polisen.se
Well, I can go straight to https://www.polisen.se, in which case manually using https is more secure than doing it automatically (KB SSL Enforcer-method).
If I’m really cautious, I can make sure a domain (e.g. my bank) is in the HSTS-list before visiting it. Actually it is good to make sure to use strict security for such sites.
Quote
So by merging them into one, in my opinion you don't really get anything negative, however you do the get positive thing of never forgetting to set the websites that support it to HTTPS.
I think it might have the opposite effect, that I forget about https because I count on that someone else does it for me.

Another thing to remember is that HTTP Secure is not always secure. Old cryptographic protocols are insecure and it’s time to move (servers and browsers) to TLS 1.2.

Anyway, Adam Langley (Google) has written some articles you might find interesting: https://www.imperialviolet.org/posts-index.html :)
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #37 on: June 29, 2013, 07:19:10 AM »
By “manually set websites to HTTPS when you visit them” you seem to assume that I would first visit e.g. http://www.polisen.se and then add the heroic s: https://www.polisen.se
Well, I can go straight to https://www.polisen.se, in which case manually using https is more secure than doing it automatically (KB SSL Enforcer-method).
If I’m really cautious, I can make sure a domain (e.g. my bank) is in the HSTS-list before visiting it. Actually it is good to make sure to use strict security for such sites.I think it might have the opposite effect, that I forget about https because I count on that someone else does it for me.

Another thing to remember is that HTTP Secure is not always secure. Old cryptographic protocols are insecure and it’s time to move (servers and browsers) to TLS 1.2.

Anyway, Adam Langley (Google) has written some articles you might find interesting: https://www.imperialviolet.org/posts-index.html :)
Hmm I see, would it not be possible to "hijack" the browser so that when someone tries to go to http://www.polisen.se it never requests that site before trying https://www.polisen.se but if it does not support SSL then fall back on http and display a message that the site does not support SSL and is hence not secure?
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #38 on: June 29, 2013, 03:06:20 PM »
Not in any way I am aware of. http is the default transport protocol for every browser and I guess that behaviour must be changed in the browser-code.

Replacing TCP with the UDP-based and encrypted QUIC will improve the situation.

It is also being discussed whether to make TLS mandatory in the SPDY-based HTTP 2.0 (draft).
« Last Edit: June 29, 2013, 03:29:03 PM by JoWa »
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #39 on: June 29, 2013, 05:35:17 PM »
Not in any way I am aware of. http is the default transport protocol for every browser and I guess that behaviour must be changed in the browser-code.
Shame :-\ however also in a way good from a security point of view on hijacking the browser.
Replacing TCP with the UDP-based and encrypted QUIC will improve the situation.

It is also being discussed whether to make TLS mandatory in the SPDY-based HTTP 2.0 (draft).
I don't know if I would vote yes for a mandatory TLS, however I would vote for it being the default. In my opinion security is more important than speed.
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #40 on: June 30, 2013, 03:13:41 AM »
Indeed, it’s a shame I don’t know everything. ^_^ But I’m working on it. :a0

QUIC and SPDY are meant to increase both security and speed. Speed (low latency) is also very important, especially for mobile networks.
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #41 on: June 30, 2013, 06:44:32 AM »
Indeed, it’s a shame I don’t know everything. ^_^ But I’m working on it. :a0
Oh, sorry I didn't mean to imply that.
QUIC and SPDY are meant to increase both security and speed. Speed (low latency) is also very important, especially for mobile networks.
Standards and protocols take too long. 88) When can we expect QUIC and SPDY to be ready? If any such date is available I mean.
I support privacy and freedom online - eff.org

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5756
  • I believe in doubt.
    • Evolutionary history of life
Re: Show exactly what is being blocked when clicking the extension.
« Reply #42 on: June 30, 2013, 07:25:55 AM »
Oh, I’m sure you did. >:-D

Well, don’t hold your breath while waiting for HTTP 2.0 (you might turn pale while doing so). :-X

SPDY is actually not a formal standard, but a de facto-standard (Wikipedia), and is already in use. Google, Facebook and Twitter use it on their servers, as do many others. Chromium, Firefox and Opera support it, and so does IE11 (source).

QUIC is at a more experimental state:
Quote
Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY.
http://blog.chromium.org/2013/06/experimenting-with-quic.html

QUIC used in Chrome Canary (Google+)
Ubuntu 19.04 | Chrome 74β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Sanya IV Litvyak

  • Comodo's Hero
  • *****
  • Posts: 4214
  • Lurking
Re: Show exactly what is being blocked when clicking the extension.
« Reply #43 on: June 30, 2013, 07:30:15 AM »
Oh, I’m sure you did. >:-D
I didn't!  :'(
Well, don’t hold your breath while waiting for HTTP 2.0 (you might turn pale while doing so). :-X

SPDY is actually not a formal standard, but a de facto-standard (Wikipedia), and is already in use. Google, Facebook and Twitter use it on their servers, as do many others. Chromium, Firefox and Opera support it, and so does IE11 (source).

QUIC is at a more experimental state:http://blog.chromium.org/2013/06/experimenting-with-quic.html

QUIC used in Chrome Canary (Google+)
Oh alright, still I think the interwebs should be changed so HTTPS can be the default protocol instead of HTTP... however one would do that...
I support privacy and freedom online - eff.org

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek