Activate the persistence of the tabs between sessions also in always incognito mode

[uazo]

Is your feature request related to privacy?

Yes, improving the always incognito mode

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

I am able to enable to keep tabs between sessions in always incognito mode, and the idea is to connect it to the "Enable History" flag

Describe alternatives you have considered

currently the "normal" tabs are saved in an unencrypted file in the data directory, while the "anonymous" ones in encrypted mode with a key that changes each time the browser is started.
the latter mode does not allow me to reread the content after each browser reboot.
since I don't want to change that logic, I would prefer that the tabs are saved unencrypted only if both flags are active.
from the point of view of privacy I see no problems, since the history itself is kept in unencrypted mode.
the patch will have to obey the will not to save tabs if the "Close tabs on exit" flag is active.

[uazo]

@csagan5 the patch is very simple, and it pretty much builds on that

diff --git a/chrome/browser/tabpersistence/android/java/src/org/chromium/chrome/browser/tabpersistence/TabStateFileManager.java b/chrome/browser/tabpersistence/android/java/src/org/chromium/chrome/browser/tabpersistence/TabStateFileManager.java
--- a/chrome/browser/tabpersistence/android/java/src/org/chromium/chrome/browser/tabpersistence/TabStateFileManager.java
+++ b/chrome/browser/tabpersistence/android/java/src/org/chromium/chrome/browser/tabpersistence/TabStateFileManager.java
@@ -108,6 +108,9 @@ public class TabStateFileManager {
      * @return TabState that has been restored, or null if it failed.
      */
     private static TabState readState(FileInputStream input, boolean encrypted) throws IOException {
+        boolean isEncrypted = encrypted;
+        if (useCrypto == false) encrypted = false;
+
         DataInputStream stream = null;
         if (encrypted) {
             Cipher cipher = CipherFactory.getInstance().getCipher(Cipher.DECRYPT_MODE);
@@ -177,7 +180,7 @@ public class TabStateFileManager {
                         "Failed to read shouldPreserve flag from tab state. "
                                 + "Assuming shouldPreserve is false");
             }
-            tabState.isIncognito = encrypted;
+            tabState.isIncognito = isEncrypted;
             try {
                 tabState.themeColor = stream.readInt();
             } catch (EOFException eof) {
@@ -227,6 +230,8 @@ public class TabStateFileManager {
      * @param encrypted Whether or not the TabState should be encrypted.
      */
     public static void saveState(File file, TabState state, boolean encrypted) {
+        encrypted = false;
+
         if (state == null || state.contentsState == null) return;
         long startTime = SystemClock.elapsedRealtime();
 
@@ -349,4 +354,9 @@ public class TabStateFileManager {
     public static void setChannelNameOverrideForTest(String name) {
         sChannelNameOverrideForTest = name;
     }
+
+    static private boolean mUseCrypto = true;
+    public static void setDoNotUseCrypto(boolean useCrypto) {
+        mUseCrypto = useCrypto;
+    }
 }

already tried and it works, but the frills are missing, before I go on I would like to know what you think.
EDIT: note, only the list of tabs is kept, cookies storage etc are deleted at each reboot.

[csagan5]

already tried and it works, but the frills are missing, before I go on I would like to know what you think.

I think that there is risk we might miss something present in current Chromium incognito mode design that makes this less safe from privacy perspective; this applies to both this feature and the history-in-incognito one. When we were discussing that I mentioned that there are lots of URLs nowadays that contain user-identifying data in the URL.

You can continue developing this, although I see a slippery slope here:

note, only the list of tabs is kept, cookies storage etc are deleted at each reboot.

What will you say when there is a feature request about keeping cookies?

[uazo]

I think that there is risk we might miss something present in current Chromium incognito mode design that makes this less safe from privacy perspective

in your opinion, what should I check?

I mentioned that there are lots of URLs nowadays that contain user-identifying data in the URL.

Certain.
it would probably be better then to show the full link from the history page, as well as make it possible to clean up the url, although probably most users would not know what to do.
I also wonder if the referral is kept in the history record and what is allowed to do with window.history

What will you say when there is a feature request about keeping cookies?

as I am, I would say ok, there are use cases for which it would make sense, such as accessing corporate sites.
from a technical point of view, however, it is extremely complex, the points to be touched in the code would be too many and it would become unmaintainable.

[csagan5]

I think that there is risk we might miss something present in current Chromium incognito mode design that makes this less safe from privacy perspective

in your opinion, what should I check?

I do not know, it is the risk of the "unknown". Unfortunately we do not have access to the design docs of the incognito feature and they might be outdated anyways; the source code is the only truth.

it would probably be better then to show the full link from the history page, as well as make it possible to clean up the url,

The former is hard because of the display small size, the latter cannot be done by a browser, the querystring can simply be obfuscated.

Feel free to continue with the PR, but I would probably also not go further e.g. no cookies in future.

[csagan5]

@uazo would you like to submit a PR for this? However we should not save also cookies, the modified incognito mode with history and keeping tabs has dangerously become too similar to the normal browsing mode.

[uazo]

would you like to submit a PR for this?

yes, I'm working on it.

the idea is

• understand what information remains on disk between reboots (partially covered by this)
• create a new native page opened by the code that regenerates the tabs at startup by presenting the url of the previous session + a button that opens the page. I'm still undecided whether to add an option to delete the parameters from the url
• add a quick button to close all tabs

probably the new page can also be called up from the history page

[csagan5]

• I'm still undecided whether to add an option to delete the parameters from the url

Bromite is neutral in regards to user navigation, it cannot do this.

• create a new native page opened by the code that regenerates the tabs at startup by presenting the url of the previous session + a button that opens the page.

This sounds horribly complex. I am not so sure anymore about this feature.

[uazo]

Bromite is neutral in regards to user navigation, it cannot do this.

I told you, I'm undecided too

This sounds horribly complex

no it is not.

[csagan5]

Incognito mode has always been "ephemeral", in the sense that nothing is written to disk permanently when browsing.

This concept was already attacked successfully the first time with the addition of history, recents and offline pages.

Persisting tabs is something going 100% against the "ephemeral" nature of incognito sessions so - complex or not - I do not think this should be added to Bromite.

This would basically create the functionality of "delete everything on exit", just in a different form.

[uazo]

Incognito mode has always been "ephemeral", in the sense that nothing is written to disk permanently when browsing.

let's talk about this (I thought I already said that): for me it is not like that. for me the (always) incognito is a way to be ephemeral with the sites, not with the device, which is mine and I manage it best.
that is, I am not interested in not having (none at all) tracks on disk, but I am interested that the tracks are not written by the sites I browse.
then, if you can have both, it's better, but I don't set it as a goal.
my goal is rather to have a "normal" browser (with all functions, therefore also keep the history) that guarantees me (science fiction :) that there is no way to connect between sessions (and for this issue, the problem is the url parameters)

This would basically create the functionality of "delete everything on exit", just in a different form.

no, it is not the same thing, because in addition the chromium developers minimize the data exposure with the incognito mode.

[csagan5]

Once you have tabs, history, recents and offline pages in incognito mode what is the difference with non-incognito mode from the perspective of sites?

I am looking specifically at:

• cookies
• tracking tokens in URLs
• incognito-stored data (this would still be ephemeral across browser restarts)

[uazo]

trick question? I do not understand...

[csagan5]

No, I am referring to "no way to connect between sessions": what information do sites have? What is the practical difference between incognito mode with even tabs restored vs "delete everything on exit"?

[uazo]

No, I am referring to "no way to connect between sessions": what information do sites have?

I understand, in addition to those we save to disk and which could be deleted at startup? nothing else, assuming that everything is really erased. because the difference is that in incognito it is not really written

What is the practical difference between incognito mode with even tabs restored vs "delete everything on exit"?

the help of the chromium/blink team who disable some privacy issues before us with incognito mode.

[csagan5]

I am not sure about that, because incognito mode was designed to not have tab states restored. For example as you also mentioned: what is the point of erasing certain information on restart if the tab state contains it? (cookies, submitted user data etc)

Whatever improvements are made in incognito mode by design are null and void once we start adding these "features" that in reality will fool the users thinking that they are somewhat more protected in terms of privacy.

[uazo]

the tab state contains it

the status of the tab is not resumed, only the navigation link.

these "features" that in reality will fool the users thinking that they are somewhat more protected in terms of privacy.

why do you say so, it's not true. browsing anonymously covers privacy issue by not saving anything on disk, and anything unsaved is not recoverable from the sites

[csagan5]

these "features" that in reality will fool the users thinking that they are somewhat more protected in terms of privacy.

why do you say so, it's not true. browsing anonymously covers privacy issue by not saving anything on disk, and anything unsaved is not recoverable from the sites

That is only 1 feature and it protects from someone stealing or finding your phone, turning it off, opening it and then attaching a device to the memory soldered on your phone and extracting the content (assuming that you do not have Android device encryption enabled, see also: https://source.android.com/security/encryption/full-disk).

There are also other features related to online browsing, and those can be affected by changing functionality like it has been done so far and planned to be done in this issue.

the tab state contains it

the status of the tab is not resumed, only the navigation link.

Ok, so the only persisted information is what is present in URL.

[uazo]

There are also other features related to online browsing, and those can be affected by changing functionality like it has been done so far and planned to be done in this issue.

because you are optimistic and you think we find them all ...
I would take advantage of the policy that chromium developers must follow, that is, do not save in incognito mode (never!).
then, if you read the various TAG review, there is a specific question for how a (new/modified) feature should work in incognito mode.

Ok, so the only persisted information is what is present in URL.

yes, or so it will be.

[csagan5]

because you are optimistic and you think we find them all ...
I would take advantage of the policy that chromium developers must follow, that is, do not save in incognito mode (never!).
then, if you read the various TAG review, there is a specific question for how a (new/modified) feature should work in incognito mode.

No, I am saying that we cannot find them all and thus we are changing things we do not understand: the policy you want to take advantage from is only valid if some prerequisites are met, and these changes will violate that. There is not just "do not save in incognito mode", there are also other changes in place that increase privacy when in incognito mode.

[uazo]

There is not just "do not save in incognito mode", there are also other changes in place that increase privacy when in incognito mode.

sure. but the original question was "way to connect between sessions": without data exchanged there is no way, let's say, in an "active mode", correct?
exploiting bugs or flaws in the code, and then passively providing the information, is another matter, and some of them are blocked directly at birth (with incognito).

thus we are changing things we do not understand

an example?

[csagan5]

There is not just "do not save in incognito mode", there are also other changes in place that increase privacy when in incognito mode.

sure. but the original question was "way to connect between sessions": without data exchanged there is no way, let's say, in an "active mode", correct?

The functionality we have enabled or now would enable (tabs restore) was not designed with incognito in mind, so it is a matter of not assuming that there is none and proving it instead.

thus we are changing things we do not understand

an example?

I am referring to everything else which is not about storing in the profile data.
As an example of functionality which has nothing to do with not storing files on the device, see https://github.com/bromite/bromite/blob/99.0.4844.77/build/patches/Disable-smart-selection-by-default.patch

You can search the code for any check "is incognito?" and see whether it is about storing something in the profile data or a more general privacy concern of something that should not happen when in incognito.

[uazo]

so it is a matter of not assuming that there is none and proving it instead.

you can't help but foresee the incognito mode, in the chromium code it is too tied to basic concepts like profile or partitionstorage. and I have never found in the code assumptions of the type, if the history is active then you are not in incognito mode, but if I find it surely I will tell you.
furthermore, with some experience in reading the code, I have seen that the team develops it with the privacy first logic, and where it is not possible they declare it by writing it, the problem is to read everything

As an example of functionality which has nothing to do with not storing files on the device, see https://github.com/bromite/bromite/blob/99.0.4844.77/build/patches/Disable-smart-selection-by-default.patch

are you telling me that the function that activates that patch does it have any impact on how incognito mode works?
I don't know that patch, but if the smart selection need to send the url of the page, rest assured that it should be necessary to prevent the incognito mode at least one dcheck would be present.
communication via network involves the request for a context that comes from the profile, the need to save to disk is foreseen either in the preferences (subjected to the storagepartition connected to the profile) or with sql/proto (also them). in incognito mode the storage partition does not provide for any saving.
but there are exceptions that I am finding here and gradually removing it.

[csagan5]

As an example of functionality which has nothing to do with not storing files on the device, see https://github.com/bromite/bromite/blob/99.0.4844.77/build/patches/Disable-smart-selection-by-default.patch

are you telling me that the function that activates that patch does it have any impact on how incognito mode works?

We have already had this conversation, see #695 (comment) (related: chromium/chromium@48d4ae5)

so it is a matter of not assuming that there is none and proving it instead.

you can't help but foresee the incognito mode, in the chromium code it is too tied to basic concepts like profile or partitionstorage. and I have never found in the code assumptions of the type, if the history is active then you are not in incognito mode, but if I find it surely I will tell you. furthermore, with some experience in reading the code, I have seen that the team develops it with the privacy first logic, and where it is not possible they declare it by writing it, the problem is to read everything

The question is: how to make sure that the tabs restore will not conflict with existing other functionality that protects privacy in incognito? The example I made is smart selection that is disabled in Chromium in incognito mode because it would leak some information. There are other cases where a functionality is disabled only in incognito and the reason is (more or less) documented in code or commits.
My position is: we should not assume that it is always safe to change something in incognito but rather verify it. It is the same as saying: I will not change this code until I understand it. Understanding it fully is a daunting and probably impossible task, but doing some checks is not.

[uazo]

The question is: how to make sure that the tabs restore will not conflict with existing other functionality that protects privacy in incognito

if linked to always incognito, a control must be present to validate it.
in this way you will never touch normal incognito browsing, and therefore that will always be faithful to the original implementation.
in the always mode, at most it is behaving like normal navigation, in the functions that are activated, which seems to me a good compromise. then the evaluation is always in the patch as you say, and bugs must be fixed once found

[csagan5]

The question is: how to make sure that the tabs restore will not conflict with existing other functionality that protects privacy in incognito

if linked to always incognito, a control must be present to validate it. in this way you will never touch normal incognito browsing, and therefore that will always be faithful to the original implementation.

The setting gives the user the choice but user 100% expects that privacy and security are not diminished even when toggling this.

in the always mode, at most it is behaving like normal navigation, in the functions that are activated, which seems to me a good compromise.

It is a re-definition of always-incognito mode; perhaps it is time to create a wiki page for it, explaining everything about what always-incognito means in Bromite and what happens with all these options?

then the evaluation is always in the patch as you say, and bugs must be fixed once found

No, I also expect that you look into what you are changing; as you remember we have disagreed on what constitutes a privacy leak before, so you cannot propose a change without checking the impact, it effectively leaves the task to me (which I will do anyways) but if you have also looked into the parts you are changing from design perspective that helps.

It is a situation of "make the minimal change so that the feature works" vs "make the change and also look how code works to understand if there are any privacy or security problems involved"; I prefer the latter and I never know if you have done that investigation or not because the PRs or patches do not contain much information.

[csagan5]

As an example of functionality which has nothing to do with not storing files on the device, see https://github.com/bromite/bromite/blob/99.0.4844.77/build/patches/Disable-smart-selection-by-default.patch

are you telling me that the function that activates that patch does it have any impact on how incognito mode works?

We have already had this conversation, see #695 (comment) (related: chromium/chromium@48d4ae5)

Have you seen this old conversation? The answer to your question is: yes. Chromium developers disable smart selection when in incognito because it would leak information. Do you understand what I am talking about when saying "everything which is not about the storage"?

[csagan5]

I will wait for your replies to the above comments; meanwhile I have checked the codebase (to the best that I could) and could not find anything which would become less privacy-safe with the feature. Will check again the specific parts if you submit a PR.

[uazo]

The setting gives the user the choice but user 100% expects that privacy and security are not diminished even when toggling this.

the user expects badly, 100% cannot be assured, bugs are always present. we do our best, but it's not always easy.

explaining everything about what always-incognito means in Bromite and what happens with all these options?

simple, the activation of those functions even in incognito, done.
obviously always respecting privacy but not excluding bugs that could affect it, like all other patches.

No, I also expect that you look into what you are changing;

Of course I do.

It is a situation of "make the minimal change so that the feature works" vs "make the change and also look how code works to understand if there are any privacy or security problems involved"; I prefer the latter and I never know if you have done that investigation or not because the PRs or patches do not contain much information.

we have no way today, for sure, to declare that our changes do not impact privacy or security, aside from our own subjective checks.
either or we find an objective way to proceed, or even you can't assure for every single change you've made with your patches.

f you have done that investigation or not because the PRs or patches do not contain much information.

just ask me. I try to verify every possible path modified by my interventions, but I have no way to describe it in the best possible way.

are you telling me that the function that activates that patch does it have any impact on how incognito mode works?

The answer to your question is: yes.
Chromium developers disable smart selection when in incognito because it would leak information.

and it always is, with or without that patch https://source.chromium.org/chromium/chromium/src/+/main:content/public/android/java/src/org/chromium/content/browser/selection/SmartSelectionClient.java;l=66;drc=7fb345a0da63049b102e1c0bcdc8d7831110e324
you have activated the function (let's say the ui) but the rest remains so and there are no leaks in incognito

[csagan5]

The setting gives the user the choice but user 100% expects that privacy and security are not diminished even when toggling this.

the user expects badly, 100% cannot be assured, bugs are always present. we do our best, but it's not always easy.

I wrote that user expects fully that privacy and security are not diminished when toggling a specific feature of this always-incognito mode. Incognito mode cannot be "less incognito" when something is enabled or disabled.
You are referring to software with no bugs, that is not what I wrote.

explaining everything about what always-incognito means in Bromite and what happens with all these options?

simple, the activation of those functions even in incognito, done. obviously always respecting privacy but not excluding bugs that could affect it, like all other patches.

I have a different consideration for the necessary level of quality and statements like this are showing it more evidently.
I don't think it's simple: they require more scrutiny & research.

It is a situation of "make the minimal change so that the feature works" vs "make the change and also look how code works to understand if there are any privacy or security problems involved"; I prefer the latter and I never know if you have done that investigation or not because the PRs or patches do not contain much information.

we have no way today, for sure, to declare that our changes do not impact privacy or security, aside from our own subjective checks. either or we find an objective way to proceed, or even you can't assure for every single change you've made with your patches.

The only thing I can do is to call for more scrutiny and do more scrutiny, and that is what I am doing. The goal is to avoid bugs like #1942 (and worse) as best as we can; there is no individual blame but there must be responsibility, any PR cannot be merged in a reckless fashion.

if you have done that investigation or not because the PRs or patches do not contain much information.

just ask me. I try to verify every possible path modified by my interventions, but I have no way to describe it in the best possible way.

That's what I ask in every PR when I cannot figure out the changes.

are you telling me that the function that activates that patch does it have any impact on how incognito mode works?

The answer to your question is: yes.
Chromium developers disable smart selection when in incognito because it would leak information.

and it always is, with or without that patch https://source.chromium.org/chromium/chromium/src/+/main:content/public/android/java/src/org/chromium/content/browser/selection/SmartSelectionClient.java;l=66;drc=7fb345a0da63049b102e1c0bcdc8d7831110e324 you have activated the function (let's say the ui) but the rest remains so and there are no leaks in incognito

In the patch description there is a reference to this Chromium commit that says:

Since OEM could modify the implementation of TextClassifier to send privacy data via network, we disable Smart Text Selection under Incognito mode.

Back then when I developed this patch I concluded that web search is disabled in incognito for the same reason, however I cannot find any clue about this. It could be either by design (incognito searches are not trackable so detrimental from product perspective) or because back then there was some other technical reason to do this. The git history leads to the source being imported from SVN so we will never know.

The intent of the patch was:

1. allow again web search in incognito, which without further changes would pass the selected text to the Android TextClassifier
2. since smart selection is disabled by default with a feature, (1) is now safe

However it looks like nothing is passed to the TextClassifier in incognito so the above was misled.

In conclusion: please open a PR for this issue as well and we will discuss the technical details there.

[uazo]

I have a different consideration for the necessary level of quality and statements like this are showing it more evidently.
I don't think it's simple: they require more scrutiny & research.

I like the way you work, and although we don't get along sometimes, we are a team with the same goals and different visions

The only thing I can do is to call for more scrutiny and do more scrutiny, and that is what I am doing

we should seriously invest in test cases, and maybe in the future we will have enough time to do so.
I'll get there, but first, personally, I have set myself some priority objectives:

• simplify the rebase
• eliminate bulky patches at the base, where the best would be to propose a patch to upstream (but at the moment I am not capable of it)
• automate the search for functions to be checked by means of an automatic check of the flags and above all of runtime_enabled_features
• simply to have more time to check, disable unauthorized communications through a filter on NetworkTrafficAnnotationTag, assuming that it is better to start disabled and then eventually activate them
• somehow exploit HighEntropy annotations in idls

In conclusion: please open a PR for this issue as well and we will discuss the technical details there.

sure I will

[csagan5]

I have a different consideration for the necessary level of quality and statements like this are showing it more evidently.
I don't think it's simple: they require more scrutiny & research.

I like the way you work, and although we don't get along sometimes, we are a team with the same goals and different visions

Sure, I am very happy of your contributions and would like more people to join as well! As for the different visions: in some cases, like for the non-privacy-related patches, I would love to have more of that but in the boundaries of this project I am forced to stick to the project mission about privacy.

• simplify the rebase

For this purpose I have developed some new tooling and I am thinking when to release it because it would open the door to not just support requests about the browser but also about the building process. I am trying to figure out if it will be beneficial for browser freedom in general (with more open source work on browsers like Bromite) or just a drain of free support.

• eliminate bulky patches at the base, where the best would be to propose a patch to upstream (but at the moment I am not capable of it)

Which patches do you have in mind, maybe I can help? Do you refer to safe browsing and binary blobs patches perhaps? Upstream decided long ago to remove all build flags related to that...

• simply to have more time to check, disable unauthorized communications through a filter on NetworkTrafficAnnotationTag, assuming that it is better to start disabled and then eventually activate them

I remember you mentioned this earlier; Iridium browser was also using a similar approach. Does all traffic have these tags?

• somehow exploit HighEntropy annotations in idls

Slightly related: the audio fingerprinting mitigation patch breaks rendering of sites like this one: https://persepolis.getty.edu/
It should be redone like the canvas one (adding random sound noise) but haven't had time to look at it.

[uazo]

and would like more people to join as well!

magari...

As for the different visions: in some cases, like for the non-privacy-related patches, I would love to have more of that but in the boundaries of this project I am forced to stick to the project mission about privacy.

are you referring to the bottom toolbar? I've already told you, I'll take care of keeping it updated (as I'm actually doing). you might even make some exceptions, every now and then :) but that's okay, don't worry

I am trying to figure out if it will be beneficial for browser freedom in general (with more open source work on browsers like Bromite) or just a drain of free support.

unfortunately I don't know how to help you in the decision, but you can always do as the webview (no support), personally I would not see anything wrong with it.

Do you refer to safe browsing and binary blobs patches perhaps?

yes

Upstream decided long ago to remove all build flags related to that...

I didn't know it

Does all traffic have these tags?

yes, and they are introducing it also on the java side. among other things, the development of such a filter doesn't even seem that complex

Slightly related: the audio fingerprinting mitigation patch breaks rendering of sites like this one: https://persepolis.getty.edu/
It should be redone like the canvas one (adding random sound noise) but haven't had time to look at it.

I have seen the implementation of brave, I have developed a small utility to see the changes directly in the chromium code.
by the way simple to carry in bromite. slowly I bring them all.

[csagan5]

As for the different visions: in some cases, like for the non-privacy-related patches, I would love to have more of that but in the boundaries of this project I am forced to stick to the project mission about privacy.

are you referring to the bottom toolbar? I've already told you, I'll take care of keeping it updated (as I'm actually doing). you might even make some exceptions, every now and then :) but that's okay, don't worry

I sent you a message about this on Reddit. In short: yes, exceptions can be made, you can submit the PR.

I am trying to figure out if it will be beneficial for browser freedom in general (with more open source work on browsers like Bromite) or just a drain of free support.

unfortunately I don't know how to help you in the decision, but you can always do as the webview (no support), personally I would not see anything wrong with it.

I would like more people to build Chromium/Bromite, but I also do not want to open a "Discord for building Chromium for newbies" place.

Upstream decided long ago to remove all build flags related to that...

I didn't know it

For safe browsing: yes. For binary blobs: maybe there never was such a build flag.

Does all traffic have these tags?

yes, and they are introducing it also on the java side. among other things, the development of such a filter doesn't even seem that complex

That's interesting; we have already discussed this in the past and my concern was/is also that the code might go into crazy loops trying to send traffic that we block via tags. But it could indeed be used as a second protection and/or to find new privacy-invasive features.

Slightly related: the audio fingerprinting mitigation patch breaks rendering of sites like this one: https://persepolis.getty.edu/
It should be redone like the canvas one (adding random sound noise) but haven't had time to look at it.

I have seen the implementation of brave, I have developed a small utility to see the changes directly in the chromium code. by the way simple to carry in bromite. slowly I bring them all.

👍

[uazo]

I sent you a message about this on Reddit

ah! notifications NEVER arrive... ok!

but I also do not want to open a "Discord for building Chromium for newbies" place.

uao, does that mean you made it extremely simple? I'm curious...

But it could indeed be used as a second protection and/or to find new privacy-invasive features.

exactly. and maybe we could also remove the seek and replace patch ...

[csagan5]

but I also do not want to open a "Discord for building Chromium for newbies" place.

uao, does that mean you made it extremely simple? I'm curious...

Nothing miraculous but if you have the necessary hardware it should be quite well automated when using the official build automation (both for builds and patches maintenance).

But it could indeed be used as a second protection and/or to find new privacy-invasive features.

exactly. and maybe we could also remove the seek and replace patch ...

The URLs reached from JavaScript would not be covered though.

[uazo]

The URLs reached from JavaScript would not be covered though.

which url? do you mean by the user's navigation?
because I meant those generated by the browser

about a way to block url from javascript I'm researching on tensorflow (although I don't understand that much), but I also found

https://github.com/polcak/jsrestrictor
https://github.com/seclab-ucr/ShadowBlock
https://arxiv.org/pdf/2008.04480.pdf

[csagan5]

The URLs reached from JavaScript would not be covered though.

which url? do you mean by the user's navigation? because I meant those generated by the browser

The browser has some HTML and JS files that are used on some pages (similar to the Proxy UI one) that also contain domains that are replaced automatically by that patch. In fact you can check that a lot of the files replaced there are not java or C++ files.

about a way to block url from javascript I'm researching on tensorflow (although I don't understand that much), but I also found

I think this would be too complex/invasive to integrate.

[uazo]

In fact you can check that a lot of the files replaced there are not java or C++ files.

if you are referring to the webui it is only on the desktop side
I will check, but I am not aware that the browser communicates externally via some javascript code (in android)

[uazo]

(NOTE for me) check about:
(WontFix) https://bugs.chromium.org/p/chromium/issues/detail?id=1310228
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/profiles/profile_impl.cc;l=1170;drc=671dadddfc2fbc7f077c56df93cf3934e4e42865

[uazo]

understand what information remains on disk between reboots

I found where (and what) persists between sessions: blink::PageState in encoded_page_state

way to remove out:

diff --git a/chrome/browser/tab/web_contents_state.cc b/chrome/browser/tab/web_contents_state.cc
index ab761c606a..48a5b6cde3 100644
--- a/chrome/browser/tab/web_contents_state.cc
+++ b/chrome/browser/tab/web_contents_state.cc
@@ -29,6 +29,8 @@
 #include "content/public/browser/web_contents.h"
 #include "content/public/common/referrer.h"
 #include "services/network/public/cpp/shared_url_loader_factory.h"
+#include "chrome/common/pref_names.h"
+#include "components/prefs/pref_service.h"

 using base::android::ConvertUTF16ToJavaString;
 using base::android::ConvertUTF8ToJavaString;
@@ -283,6 +285,11 @@ bool ExtractNavigationEntries(
       if (!nav.ReadFromPickle(&tab_navigation_pickle_iterator))
         return false;  // If we failed to read a navigation, give up on others.

+      Profile* profile = ProfileManager::GetActiveUserProfile();
+      if (profile->GetOriginalProfile()->GetPrefs()->GetBoolean(prefs::kIncognitoTabHistoryEnabled)) {
+        LOG(INFO) << "---ExtractNavigationEntries ";
+        nav.set_encoded_page_state("");
+      }
       navigations->push_back(nav);
     }
   }

source

or like StripReferrerFromPageState

[csagan5]

I am glad you found this, but this is for me evidence that there is too much surface for bugs if this functionality is added. Incognito mode should not be made more similar to normal mode, and normal mode should not be made more similar to incognito mode.

I know that we have some functionality in these directions but it's not useful for the users when it diminishes their privacy or security.

[uazo]

but this is for me evidence that there is too much surface for bugs if this functionality is added

as you can see I am checking very carefully, I have not yet prepared any patches, but the intention is that when I'm safer.
after two years (or three?) I am learning to read the chromium code better, and it is very stratified and in compartments, you can act being careful not to introduce bugs.

it's not useful for the users when it diminishes their privacy or security.

for me, the use of the regular mode decreases the user's privacy, you know i think always incognito should be the default in bromite.

Surely the lack of tests is very frustrating and unfortunately very serious for a browser :(. I'm working on this too, I also saw that wchen342 has made progress

[csagan5]

This feature would store the tabs state unencrypted on the device; incognito mode has always had the feature to not store that on the device.

How is this an improvement of incognito mode?

[uazo]

How is this an improvement of incognito mode?

maybe we don't understand each other because it's the wrong word, let's try to call it in another way, for example, "bromite mode".

lately I rely on this, surely you know https://2019.www.torproject.org/projects/torbrowser/design/
at chapter 4.3 (bold is mine):

4.3. Disk Avoidance
Design Goal:
The User Agent MUST (at user option) prevent all disk records of browser activity. The user SHOULD be able to optionally enable URL history and other history features if they so desire.

and I think it can be done, however it is really a choice of field (scelta di campo, si dice così?)
(among other things I really like that document, it would be nice to have a specific one of bromite)

my idea is:

• remove all disk writes, including the gpu cache if possible
• activate the recording of the history but only of the canonical url taken from the page, if they exist, otherwise do not record anything
• add an intermediate page on restart, which for each page shows the url that would be reopened (a bit like "The marvellous suspender"), with the possibility to modify it or to open the homepage of the site

so could it be an improvement of always incognito?