Read and apply existing user settings at install time (was "Completely Reversed Previous Settings")

[7ranceaddic7]

Hi, I just install the chrome extension and it reversed all my previous setting. Sites that I trust (Malwarebytes, Bleeping Computer, et al.) have had all of the settings reverse from allow to block. Also, some sites that I have conditional 'Ask Me' (I like the site but am not completely convinced to trust) were granted full permissions.

Any ideas? Until this can be resolved I've removed and WILL NOT recommend.

[7ranceaddic7]

ScreenCaps here:

https://plus.google.com/photos/100817669061399840558/albums/5929952371402078769?authkey=CKjL86zWjKr1twE

[gorhill]

Regarding "all of the settings reverse from allow to block": Yes, I don't read the user's settings at install time, and the default is to block mostly everything unless allowed by the user through the matrix. I should read the user's settings and prime the whitelist/blacklist with these settings. I will open a bug for this.

Regarding "some sites that I have conditional 'Ask Me' were granted full permissions": This is strange, as all is blocked by default (except images for graylisted sites), thus I don't see how stuff could be allowed without the user explicitly requesting it. This unexpected behavior needs to be investigated, can you give me a snapshot of the matrix for a site which has the problem you mention (it's possible with GIMP's "create from snapshot" feature along with a delay)?

[gorhill]

Ok regarding cookies, I did found some cookies with setting 'allow' on my computer for sites which are blocked. Now if I enter the site name in the address bar, the said cookies turn to 'block'.

I really need to make clearer to the user that if cookies are blacklisted for a domain by HTTPSB, whether directly or indirectly, no cookie will ever leave your computer for that domain, because HTTPSB doesn't primarily rely on Chromium block/allow settings for blocking cookies, but primarily rely on removing these cookies from the headers before they leave your browser. The block/allow status is used only on an opportunistic basis, i.e. if the user visit explicitly the domain from which the cookie originate.

So in short, cookies are for sure blocked for blacklisted sites, the only problem is the reporting of the block status in chromium which is not perfectly in sync with the block status in HTTPSB. I will enter a bug in order to ensure that chromium visual status is well synchronized with that of HTTPSB.

So rest assured that whatever HTTPSB said is blocked, it is indeed really blocked, as I don't rely primarily on chromium to prevent untrusted cookies from being sent.

[gorhill]

I will use this entry for the bug "Read and apply existing user settings at install time". Current default is to block everything at install time, except images. Changed the title accordingly.

[gorhill]

Given more thoughts to this "issue", and I rather not read pre-existing user settings to mirror them in HTTPSB, who knows pre-existing whitelist is not bloated given the chrome UI to manage white/blacklisting certainly not optimal in my opinion. With HTTPSB, whitelisting a whole site is only a few clicks away, far more simpler than going through chromium's different UI for cookies, plugins, scripts. etc. So let the user starts with a blank slate which default to all safe.