This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Invisible Requests? #112
Description
I have whitelisted every request for accounts.google.com , yet I still can not log into services until I turn HTTPSB off. Once I've logged in the issue doesn't persist. But when trying to go to a new google service it happens.
First time it happened I was trying to log into Google+, then again when trying to log into play.google.com.
Activity
gorhill commentedon Dec 31, 2013
I did try the above and it worked. But I have this recipe:
When you log into Google, I think there is a lot of redirections etc., so for the sake of simplicity, I think in the case of Google, whitelisting Google domain when on a page matching
*.google.comis the best, I doubt most users will want to go that granular.If you look into Statistics page, you might be able to track the key request which was blocked.
insanitybit commentedon Dec 31, 2013
Is there perhaps a way for HTTPSB to detect a redirect, and show the requests for the redirected page?
The rule you provided could work. I'll use it.
gorhill commentedon Jan 1, 2014
I would have to do some experiments, and if I find I can, I could report these redirects into the log in the Statistics page?
insanitybit commentedon Jan 1, 2014
That would be an improvement, though it would then require manual rules added by the user since it wouldn't be reflected by the matrix.
gorhill commentedon Jan 15, 2014
Given the saga of the Window Resizer extension, whereas a user was deceived and tricked into having his requests redirected to a third-party web site, I really need to try to figure a way for the user to be informed when such thing happens.
I am trying now to find a way to report the redirect into the matrix of the final landing page. The difficulty is to associate the redirect request to the landing page. This will require a journal to keep track of such redirect requests, and when a tab is finally bound to a landing page, there would need to be a reverse lookup for all redirects which occurred for that tab.
Now to report this, I see only the
othercolumn... At least, the hostname will be reported and this information no longer hidden from user's view.gorhill commentedon Jan 15, 2014
Reporting in the
othercolumn is no good, a user would expect aothercolumn in block mode to actually block the redirects if these are reported in this column. And forcing a user to whitelist theothercolumn to allow redirects is no good either because it will also whitelist everything else which is currently reported in theothercolumn.There is a better way to report redirects which fits perfectly in the current model: in none of the column. A redirect can easily be seen as a top
main_framerequest, only that the result was short-lived.Top
main_framerequests are actually handled in the matrix by the hostname cell: If a hostname is blacklisted (to not confuse with "blocked"), the request for the topmain_frameis aborted (the whole page is redirected to HTTPSB's replacement frame). If it is not blacklisted, the request for themain_framegoes through.So redirects will be reported as top
main_framerequests, meaning when one occurs, the user will see, for example,www.ecosia.orgin the matrix, just with all child (type) cells empty, which will mean there was a redirect towww.ecosia.org.In the request log, using the above example,
http://www.ecosia.org/blahblahblah?blahblahblahwill be reported as amain_frametype of request.better fix to #112, needed to report all redirections, not just last one