Re: Re: Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Wednesday, April 25, 2012 04:26:28 PM Dawit A wrote: On Wed, Apr 25, 2012 at 1:05 PM, Alex Fiestas afies...@kde.org wrote: On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote: On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. I will try to provide a patch, thanks for the support ! If you wait a litte while I am going to fix this issue once and for all since I want to add proper support for Private browsing mode in kwebkitpart. I am sure the reKonq guys/gals will appreciate that as well. Oookz ! Why unnecessarily waste memory ? I personally do not like this idea. For every application that starts its own private browsing mode there will be a separate instance of kcookiejar ? That is completely unwarranted. Plus there will most definitely be unforeseen consequences for having multiple instances of kcookiejar running. For example, you cannot predict how the cookie management dialog would behave under such circumstances. I don't know the details of KCookieJar so no, I don't know what problems such things could have. Nonetheless when it comes to privacity and security being able to have your own KCookieJar separated completely from the one where the global cookies are stored can come handy, anyway this is up to you/KCookieJar maintainer not me :p
Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... Regards, Dawit A.
Re: Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote: On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. I will try to provide a patch, thanks for the support ! However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... I have been willing to do a small app to load a single KDED for months now,though I wanted to do it for ease the development of a KDED that very same app could be used to execute another instance of KCookieJar. Flow should be something like: 1-User actiavte's private browsing 2-rekonq executes a custom KCookieJar -This could be done automatically within kdewebkit but we are in freeze -Once we fix the Be able to use custom CookieJars with KWebkit rekonq could write one to use this custom KCookieJar instance 3-Once private browsing is deactiavted, the small app is closed deleting all its content. Something I really like from that approach is that we keep things phisically separated, kded4 will handle real cookies while the new instance will handle private-browsing cookies. At the same time, if wanted we should be able to have multiple private browsing sessions.
Re: Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Wed, Apr 25, 2012 at 1:05 PM, Alex Fiestas afies...@kde.org wrote: On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote: On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas afies...@kde.org wrote: After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Well actually it is a little bit simpler than that to get to what you want. Keeping only the portion of my patch that deals with disabling cookie handling in kio_http along with you setting your own custom cookiejar through QWebPage::networkAccessManager()-setCookieJar should be sufficient for what you are trying to do. I will try to provide a patch, thanks for the support ! If you wait a litte while I am going to fix this issue once and for all since I want to add proper support for Private browsing mode in kwebkitpart. I am sure the reKonq guys/gals will appreciate that as well. However, to properly fix the issue of private browsing mode for more complex scenarios like allowing two separate instances of web browsers to share cookies as it is done in other browser implementations (I checked Chromium) requires a little bit more involved fix. We would need to use the cookiejar and that means we need a way to mark such cookies as private to the cookiejar. The trick is to do that without having to modify any of the KDE cookiejar code. I will see what I can do about that... I have been willing to do a small app to load a single KDED for months now,though I wanted to do it for ease the development of a KDED that very same app could be used to execute another instance of KCookieJar. Flow should be something like: 1-User actiavte's private browsing 2-rekonq executes a custom KCookieJar -This could be done automatically within kdewebkit but we are in freeze -Once we fix the Be able to use custom CookieJars with KWebkit rekonq could write one to use this custom KCookieJar instance 3-Once private browsing is deactiavted, the small app is closed deleting all its content. Something I really like from that approach is that we keep things phisically separated, kded4 will handle real cookies while the new instance will handle private-browsing cookies. Why unnecessarily waste memory ? I personally do not like this idea. For every application that starts its own private browsing mode there will be a separate instance of kcookiejar ? That is completely unwarranted. Plus there will most definitely be unforeseen consequences for having multiple instances of kcookiejar running. For example, you cannot predict how the cookie management dialog would behave under such circumstances. I personally believe there are easier ways to deal with this without having to change any code in kcookiejar. However, I won't be able to know that for sure until I try it and see if it passes all test cases. I will do that soon as I want to have this functionality in for KDE 4.9 at least.
Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
On Monday, April 23, 2012 07:38:16 PM Dawit A wrote: None of this is necessary. What should happen in private browsing mode is the cookies metadata should be set to manual to disable cookie handling kio_http. The KIO::Integration::AccessManager can be modified to send its own cookie header instead. This would give you want you want. I have attached an untested patch that does just that. Test it and let me know if it works okay for you. Wow! kdelibs is full of awesomess, I get how this work now. The only question I have and which the patch does not address is whether or not cookies stored outside of the private-browsing mode should be used (read: sent back to the server) during private browsing mode. Reading the up on the definition of private browsing mode, it seems to me that we should only stop saving information once in private browsing mode, not stop sending data that was previously stored before private browsing mode was initiated. Actually we should not send any data we currently have stored since that data can be used to identify the user and that will break any hope of private browsing. Perfect example is a cookie that authenticate the user with a web service such gmail or evil Google tracking what searches we do. Chromium, Firefox and Opera have this behavior as well (they start with an empty cookiejar). Going to take a look at your patch and try to figure something out. Big Thanks !
Re: Re: Re: KIO / KWebView and PrivateBrowsing (Cookies)
After reading the patch and understanding a little bit more how this work I reached the following conclusion (potentially wrong as before :p). storageDisabled should work as it does right now (without the patch), it does disable any storage and allow reading, which imho it is exactly what you expect from disable storage. So, how do we enable Private Browsing in AcessManager? By setting a different CookieJar, the default Qt implementation will do the job perfectly storing all the cookies in memory until the jar is destroyed (Private Browsing disabled). Right now any new CookieJar set via QNetworkAccessManager::setCookieJar will be ignored by Integration::AccessManager since at the end kio_http will use the auto cookie mode. So, the solution should be: -Fix the support for external QNetworkCookieJar's, this will have to be done anyway since Integration should have support for it. -Fix KWebPage to set a custom CookieJar when private browsing is activated. What do you think? does it make any sense at all this time? Thanks !
