[Android] Warn the user when changing ip

uazo commented 3 weeks ago

Preliminary checklist

[X] I have read the README
[X] I have searched existing issues for my feature request. This is a new issue (NOT a duplicate) and is not related to another issue.
[X] I have searched wont fix issues and this request is not among them
[X] This is a feature request for the Cromite browser; not the website nor F-Droid nor anything else.

Is your feature request related to privacy?

Yes

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

I would like to understand whether it is possible, without using resources on the internet, to intercept the ip change in android and alert the user requesting for a restart. The underlying assumption is that by having the automatic deletion active, the user may be induced to exploit the change of network to untie different sessions: comments on this point are welcome, I don't think of myself as an expert, so constructive discussion is welcome.

I have already analysed the possibilities and come up with this:

the android api doesn't seem to give me the option of telling me the ip on the external interface (i.e. the one on the mobile phone) but only on the internal one (wifi). however the network change is intercepted, and the event is sent even if the app is in the background, the moment it becomes foreground.
to ensure that the new IP is not intercepted by open sites, it is necessary to block the execution of javascript. in chromium there are different methods, all to be verified:
- via the content settings, but it seems that, at least for service workers, once actived it is no longer checked
- by freezing the page, but there is a nice DCHECK that prevents freezing the visible page, to be checked if it is because it is really not possible to freeze the current page or just because it is not logically correct
- acting directly on blink's execution context, but in this case there is no mojo pipe that can be used to communicate the block, and adding a new mojo api is always risky

Of course, the limit of this idea is that re-opening the same url between different sessions might make it possible to hang up on the user, because there may be user-related information in the url. but it would be useful to me, since I use cromite in android basically for unrelated searches, and the urls of the pages that are always open are checked. therefore, the patch should be considered as a test and should only be done if it takes little time to write it.

Describe alternatives you have considered

none

uazo commented 3 weeks ago

by freezing the page, but there is a nice DCHECK that prevents freezing the visible page, to be checked if it is because it is really not possible to freeze the current page or just because it is not logically correct

explanation: https://issues.chromium.org/issues/40590208

uazo commented 3 weeks ago

I summarise what I found.

it is possible to take advantage of the chromuim offlinedector to see if the network has changed. unfortunately for now the assumption is that it also works with the ip change, because trying it only with the emulator does not allow me to try it. if there is someone who also tries it with vpn (which I don't use) I would be pleased.

when the network change is detected I activate the following things:

I shut down all service workers, this is because javascript is informed of the freeze with an event and the page still has the possibility to send messages. the service workers can always access the network via the fetch background api, which I would not like to disable because it is often used for streaming.
block the execution of all media api, because, the code predicts that the freeze cannot be activated if a stream is active, for example, for video conferencing, whether or not it is the visible page.
I perform the freeze of all tabs, in random order. the javascript code related to the onfreeze event is executed. I did not remove this possibility because, according to the specification, it is time for the page to free up occupied resources, but page has only access to the network for fetch later, which is disabled by another patch. one would need to understand whether some situation might occur whereby the page, during onfreeze, alerts another page of a different browsing context, but that is another issue.

I have deliberately left the sending of ui messages by the browser on, although this can, in some cases, lead to the failure of some dchecks at unfreeze: sending the messages allows me to understand that indeed javascript execution is being blocked. execution resumes if the user responds to the message without selecting restart or uses one of the browser functions or launches navigation to a new url.

along with this patch I also disabled by default the auto-reconnect of quic connections (excluding those to the provider doh), otherwise it would have been all useless :)

uazo commented 2 weeks ago

~It seems to be working~, ip change is detected in the mobile phone network, I really didn't expect it :) ~next step, add the setting and activate it by default.~

no, the change is not detected if the browser is in the background.

@PF4Public do you detect any drawbacks?

PF4Public commented 2 weeks ago

@PF4Public do you detect any drawbacks?

Does everything you wrote here also apply for desktop? I'm afraid I wouldn't be able to test it on Android.

uazo commented 2 weeks ago

Does everything you wrote here also apply for desktop?

unfortunately, only android. it is actually written in the chromium code that there is no API to exploit on desktop platforms.

uazo / cromite