Consider disabling push #1558

librewolf-bot commented 2023年08月02日 20:13:50 +02:00 (Migrated from gitlab.com)

Following the topic https://old.reddit.com/r/LibreWolf/comments/15bgn04/librewolf_connecting_to_google/ I decided to have a look at this.

Using Wireshark, I see that LibreWolf makes a DNS request for the domain push.services.mozilla.com, which leads to CNAME autopush.prod.mozaws.net, which results in IP address 34.117.65.55.

If you do a reverse look-up for this IP address, you'll get the domain 55.65.117.34.bc.googleusercontent.com.

I don't know for sure if you could then conclude that the Mozilla's push services are run on Google servers, but it could be the case.

I thought it might be fixed with push disabled, so I created a user.js for an empty profile with the following contents:

user_pref("dom.push.connection.enabled", false); // Changed 2023年08月07日 from dom.push.enabled

and the connection was not made anymore.

I also tested with only dom.webnotifications.serviceworker.enabled or dom.webnotifications.enabled instead (following https://support.mozilla.org/en-US/questions/1140439), but then the connection was still made.

I would be a in favor of disabling web push notifications by default, to be honest, especially when it leads to connections to Google servers for everyone.

References

• https://old.reddit.com/r/LibreWolf/comments/15bgn04/librewolf_connecting_to_google/
• https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv4vxrk/
  • Reply: https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv5z70i/
• https://old.reddit.com/r/LibreWolf/comments/15hs76o/outgoing_connection_bc_googleusercontent_com/
• https://gitlab.com/librewolf-community/settings/-/issues/115
• https://gitlab.com/librewolf-community/browser/source/-/issues/76
• https://gitlab.com/librewolf-community/browser/source/-/issues/105

Following the topic https://old.reddit.com/r/LibreWolf/comments/15bgn04/librewolf_connecting_to_google/ I decided to have a look at this. Using Wireshark, I see that LibreWolf makes a DNS request for the domain **push.services.mozilla.com**, which leads to CNAME **autopush.prod.mozaws.net**, which results in IP address **34.117.65.55**. If you do a reverse look-up for this IP address, you'll get the domain **55.65.117.34.bc.googleusercontent.com**. I don't know for sure if you could then conclude that the Mozilla's push services are run on Google servers, but it could be the case. I thought it might be fixed with push disabled, so I created a `user.js` for an empty profile with the following contents: ``` user_pref("dom.push.connection.enabled", false); // Changed 2023年08月07日 from dom.push.enabled ``` and the connection was **not made anymore**. I also tested with only `dom.webnotifications.serviceworker.enabled` or `dom.webnotifications.enabled` instead (following https://support.mozilla.org/en-US/questions/1140439), but then the connection was still made. I would be a in favor of disabling web push notifications by default, to be honest, especially when it leads to connections to Google servers for everyone. #### References - https://old.reddit.com/r/LibreWolf/comments/15bgn04/librewolf_connecting_to_google/ - https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv4vxrk/ - Reply: https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv5z70i/ - https://old.reddit.com/r/LibreWolf/comments/15hs76o/outgoing_connection_bc_googleusercontent_com/ - https://gitlab.com/librewolf-community/settings/-/issues/115 - https://gitlab.com/librewolf-community/browser/source/-/issues/76 - https://gitlab.com/librewolf-community/browser/source/-/issues/105

librewolf-bot commented 2023年08月02日 21:08:59 +02:00 (Migrated from gitlab.com)

We already had a very heated discussion about that yesterday on the Matrix channel with somebody who probably also saw that Reddit thread. It was also already discussed in the original issue about it a year ago. Our current stance I think is that we are ok with Mozilla hosting the push server on Google Cloud, because Google is just acting as hosting provider in this case.

We already had a very heated discussion about that yesterday on the Matrix channel with somebody who probably also saw that Reddit thread. It was also already discussed [in the original issue about it](https://gitlab.com/librewolf-community/settings/-/issues/115) a year ago. Our current stance I think is that we are ok with Mozilla hosting the push server on Google Cloud, because Google is just acting as hosting provider in this case.

librewolf-bot commented 2023年08月02日 21:36:15 +02:00 (Migrated from gitlab.com)

Thx for the quick reply. I have seen that issue before, there doesn't seem to be any mention of the fact that it's hosted by Google, but maybe that was discussed elsewhere.

I think Mozilla's choice to actually choose Google's hosting for something privacy sensitive like this, which sets up continuous connections to that server while the browser is running, is peculiar to say the least, and it does generate some understandable confusion for users as well, but I guess the amount of control you can have over services like this has to end somewhere.

That being said, I think push notifications are very rarely useful, and most people will only have experience with them by turning them on by accident and then being bombarded by rarely useful information, or ads.

If turning push services off by default is out of the question, I think it would be a good idea to suggest the dom.push.enabled in the FAQ item about the connections made by LW, in addition to explicitly telling the users which connection for what purpose are made. Currently, it is not very informative without explicitly listing the connections imho.

Thx for the quick reply. I have seen that issue before, there doesn't seem to be any mention of the fact that it's hosted by Google, but maybe that was discussed elsewhere. I think Mozilla's choice to actually choose Google's hosting for something privacy sensitive like this, which sets up continuous connections to that server while the browser is running, is peculiar to say the least, and it does generate some understandable confusion for users as well, but I guess the amount of control you can have over services like this has to end somewhere. That being said, I think push notifications are _very_ rarely useful, and most people will only have experience with them by turning them on by accident and then being bombarded by rarely useful information, or ads. If turning push services off by default is out of the question, I think it would be a good idea to suggest the `dom.push.enabled` in the FAQ item about the connections made by LW, in addition to explicitly telling the users which connection for what purpose are made. Currently, it is not very informative without explicitly listing the connections imho.

librewolf-bot commented 2023年08月04日 09:07:26 +02:00 (Migrated from gitlab.com)

Additionally, we could make it easier for users to toggle dom.push.enabled via the LibreWolf specific settings panel.

Edit:

toggling dom.push.enabled will add/remove PushManager from window properties
So YES it can be fingerprinted despite what y'all like to believe after using a single online test that doesn't mean much

Seems to be circumventable: instead of setting dom.push.enabled to false, setting dom.push.connection.enabled to false results in PushManager still being available in the window properties, while the connection is not initiated.

Additionally, we could make it easier for users to toggle `dom.push.enabled` via the LibreWolf specific settings panel. __Edit__: >> toggling dom.push.enabled will add/remove PushManager from window properties > So YES it can be fingerprinted despite what y'all like to believe after using a single online test that doesn't mean much Seems to be circumventable: instead of setting `dom.push.enabled` to false, setting `dom.push.connection.enabled` to false results in PushManager still being available in the window properties, while the connection is not initiated.

librewolf-bot commented 2023年08月05日 13:20:20 +02:00 (Migrated from gitlab.com)

Hey @ltguillaume happy to see you active here on Codeberg too! (even tho I'm the one late to the party lulz).

Generally speaking I'm against the idea of adding stuff to the UI just to stop outgoing connections, unless the outgoing connection is going to a service that is bloatware or privacy invasive, which we decided was not the case in this instance. Frankly speaking I don't think an outgoing connection per-se can ever be a privacy issue for a browser to directly address, but rather we should evaluate its scope and the implementation offered: in this case it looks solid. I say this because I believe the IP address should be protected with a VPN and the browser has not business in this aspect unless it also implements some kind networking service (eg. Tor deamon or if we bundled a VPN).

For reference (not specifically for you guys since you already know), I shared extra stuff on outgoing connections in this issue.

Hey @ltguillaume happy to see you active here on Codeberg too! (even tho I'm the one late to the party lulz). Generally speaking I'm against the idea of adding stuff to the UI just to stop outgoing connections, unless the outgoing connection is going to a *service* that is bloatware or privacy invasive, which we decided was not the case in this instance. Frankly speaking I don't think an outgoing connection per-se can ever be a privacy issue for a browser to directly address, but rather we should evaluate its scope and the implementation offered: in this case it looks solid. I say this because I believe the IP address should be protected with a VPN and the browser has not business in this aspect unless it also implements some kind networking service (eg. Tor deamon or if we bundled a VPN). For reference (not specifically for you guys since you already know), I shared extra stuff on outgoing connections [in this issue](https://gitlab.com/librewolf-community/browser/source/-/issues/76).

librewolf-bot commented 2023年08月05日 15:23:05 +02:00 (Migrated from gitlab.com)

Hey @ltguillaume happy to see you active here on Codeberg too! (even tho I'm the one late to the party lulz).

Hehe, so I should welcome you then 😉 I've migrated my repos to Codeberg around January. It was primarily triggered by not wanting to have LibreWolf WinUpdater self-update via GitHub. That didn't feel right (and it never happened: self-updating was implemented after the migration to Codeberg).

Generally speaking I'm against the idea of adding stuff to the UI just to stop outgoing connections, unless the outgoing connection is going to a service that is bloatware or privacy invasive

Aye, there's the rub. When is a service bloatware or causing privacy concerns? When is it okay to set up connections to an American service provider (and all the hops in between) before the user has even considered whether they would want to make use of it, let alone is made aware of it?

My take:

• No outside connections should be made by default, as long as the user hasn't explicitly opted to use the service.
• There is no security benefit to allowing these connections (a reason that is mentioned for allowing other connections, such as uBlock Origin's list updates).
• The permanent connection (websocket?) that is initiated to the push server for as long as the browser is running inherently leaks some metadata to 3rd parties, including the user's ISP, Google as hosting company (and potentially MITM parties or potentially malicious VPN services, but let's not focus on that).
• Google has the kind of a track record that should not allow you to trust any kind of privacy policy stating hosted services aren't tracked (if there is any, I have not checked).

which we decided was not the case in this instance. Frankly speaking I don't think an outgoing connection per-se can ever be a privacy issue for a browser to directly address,

This is a service that's embedded into the browser. It is part of the browser's ecosystem, so to say. As such, my take on it is that it is the browser's responsibility to both inform the user of the connections made and to allow the user to opt in.

For me, only the outgoing connections initiated by the user (by visiting pages and/or installing extensions) are among those outside connections not to be "directly addressed as a privacy issue by the browser".

but rather we should evaluate its scope and the implementation offered: in this case it looks solid.

An implementation might sound good, but you'll never have actual insight into what is running on the server, nor do you know how privacy-friendly the infrastructure around the service is. I realize this can be viewed as too untrustworthy ("this way you can't use any service"), but the key point I'm trying to make here is that the user has no choice in the matter from the start (and is insufficiently informed about it, which has caused all these threads and comments with concern and misinformation on Reddit of late).

I say this because I believe the IP address should be protected with a VPN and the browser has not business in this aspect unless it also implements some kind networking service (eg. Tor deamon or if we bundled a VPN).

Same thing here, I suppose: a user makes the trade-off between exposing their IP to the website and associated services when they open a page, but not when it comes to the permanent connection to the Google-hosted Mozilla push server. I think it's well beyond our power to make this decision for them.

And let's not forget that the lack of clarity on this issue and the (understandable) proliferation of wrong conclusions about it have in fact harmed LibreWolf's trustworthiness in the eyes of those who came across the threads dealing with it. I think it would be best to prevent such outcomes from the get-go by not enabling such services by default and to provide more info, such as the DNS queries I posted above, in related FAQ items.

> Hey @ltguillaume happy to see you active here on Codeberg too! (even tho I'm the one late to the party lulz). Hehe, so I should welcome you then 😉 I've migrated my repos to Codeberg around January. It was primarily triggered by not wanting to have LibreWolf WinUpdater self-update via GitHub. That didn't feel right (and it never happened: self-updating was implemented after the migration to Codeberg). > Generally speaking I'm against the idea of adding stuff to the UI just to stop outgoing connections, unless the outgoing connection is going to a *service* that is bloatware or privacy invasive Aye, there's the rub. When is a service bloatware or causing privacy concerns? When is it okay to set up connections to an American service provider (and all the hops in between) before the user has even considered whether they would want to make use of it, let alone is made aware of it? My take: - No outside connections should be made by default, as long as the user hasn't explicitly opted to use the service. - There is no security benefit to allowing these connections (a reason that is [mentioned](https://gitlab.com/librewolf-community/browser/source/-/issues/76) for allowing other connections, such as uBlock Origin's list updates). - The _permanent_ connection (websocket?) that is initiated to the push server for as long as the browser is running inherently leaks some metadata to 3rd parties, including the user's ISP, Google as hosting company (and potentially MITM parties or potentially malicious VPN services, but let's not focus on that). - Google has the kind of a track record that should not allow you to trust any kind of privacy policy stating hosted services aren't tracked (_if_ there is any, I have not checked). > which we decided was not the case in this instance. Frankly speaking I don't think an outgoing connection per-se can ever be a privacy issue for a browser to directly address, This is a service that's embedded into the browser. It is part of the browser's ecosystem, so to say. As such, my take on it is that it _is_ the browser's responsibility to both _inform_ the user of the connections made and to allow the user to opt _in_. For me, only the outgoing connections initiated by the user (by visiting pages and/or installing extensions) are among those outside connections _not_ to be "directly addressed as a privacy issue by the browser". > but rather we should evaluate its scope and the implementation offered: in this case it looks solid. An implementation might sound good, but you'll never have actual insight into what is running on the server, nor do you know how privacy-friendly the infrastructure around the service is. I realize this can be viewed as too untrustworthy ("this way you can't use _any_ service"), but the key point I'm trying to make here is that the user has no choice in the matter from the start (and is insufficiently informed about it, which has caused all these threads and comments with concern and misinformation on Reddit of late). >I say this because I believe the IP address should be protected with a VPN and the browser has not business in this aspect unless it also implements some kind networking service (eg. Tor deamon or if we bundled a VPN). Same thing here, I suppose: a user makes the trade-off between exposing their IP to the website and associated services when they open a page, but _not_ when it comes to the permanent connection to the Google-hosted Mozilla push server. I think it's well beyond our power to make this decision for them. And let's not forget that the lack of clarity on this issue and the (understandable) proliferation of wrong conclusions about it have in fact harmed LibreWolf's trustworthiness in the eyes of those who came across the threads dealing with it. I think it would be best to prevent such outcomes from the get-go by not enabling such services by default and to provide more info, such as the DNS queries I posted above, in related FAQ items.

librewolf-bot commented 2023年08月07日 16:53:04 +02:00 (Migrated from gitlab.com)

• Changed dom.push.enabled to dom.push.connection.enabled
• Added https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv4vxrk/ (and reply https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv5z70i/) to references

- Changed `dom.push.enabled` to `dom.push.connection.enabled` - Added https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv4vxrk/ (and reply https://old.reddit.com/r/LibreWolf/comments/15j09aa/should_push_notifications_be_disabled_by_default/jv5z70i/) to references

librewolf-bot commented 2023年08月07日 18:13:44 +02:00 (Migrated from gitlab.com)

so I should welcome you then

Yup, thanks 😄

No outside connections should be made by default, as long as the user hasn't explicitly opted to use the service.

to allow the user to opt in

We decided long ago this is not a reasonable stance, this was actually around the time I reworked the settings from scratch, so years ago. I don't see the issue with outgoing connections other than the IP address, and even then just use a VPN, there's nothing we can do about it. This applies to every single connection you make btw: you cannot know in advance every CDN you'll connect to, or where the content is hosted, or who owns the metal and the cable path that you pass to reach an endpoint. It completely lacks a threat model and it is a losing game which benefit are doubtful other than this "zero-connection status".

Preventing all outgoing connections is just a fixation some websites have (neocities, unix sheik etc.) and it is just silly, there's seriously no benefit. Not even Tor Browser cares about that. Making it opt-in is terrible: users are going to shy away and miss out on features and security (which by definition should be a default and not opt-in), so it is out of the equation imo. It also sends a terrible message which we decided we do not want associated to the project.

An implementation might sound good, but you'll never have actual insight into what is running

Again this applies to almost anything server-side. I don't think Mozilla has ever been caught red-handed and we trust them for far more critical infrastructures: the code of the browser, certificate revocation, blocking lists. These are all far more critical, some of them are hosted on AWS btw. In the case of push, since we trust encryption Google is out of the equation other than the IP data point, which I addressed above.

We could update the documentation to mention it is a WebSocket for push and not a periodic connection, but other than that I wouldn't do anything about push. Why would we even mention where it is hosted? Should we do this for everything? Does any website you use mention this and does it even matter? Seriously, it is a waste of time that leads to nothing just to make a noisy part of our community happy about their paranoid view of things and lack of threat model. I feel uncomfortable with this approach, when possible we should try to send the right message and educate.

I see two cases with their relative threat model:

• you need to protect your IP address so you use a VPN and there's no issue with this or any other connection to services that may log IP addresses;
• you don't need to protect your IP address so this issue is out of your threat model and you're happy with your day.

Removing the connection (and by that extent the feature) is kind of absurd. We don't have any telemetry so we don't know if people rely on push or not, some people opened issues in the past about wanting it and not having it (because SWers were disabled as they were not partitioned, which is the only reason why push was ever disabled, at least on my end).

For completeness, as I mentioned on Reddit disabling the API is fingerprintable, even tho we are now discussing a different pref as mentioned above.

> so I should welcome you then Yup, thanks 😄 > No outside connections should be made by default, as long as the user hasn't explicitly opted to use the service. > to allow the user to opt in We decided long ago this is not a reasonable stance, this was actually around the time I reworked the settings from scratch, so years ago. I don't see the issue with outgoing connections other than the IP address, and even then just use a VPN, there's nothing we can do about it. This applies to every single connection you make btw: you cannot know in advance every CDN you'll connect to, or where the content is hosted, or who owns the metal and the cable path that you pass to reach an endpoint. It completely lacks a threat model and it is a losing game which benefit are doubtful other than this "zero-connection status". Preventing all outgoing connections is just a fixation some websites have (neocities, unix sheik etc.) and it is just silly, there's seriously no benefit. Not even Tor Browser cares about that. Making it opt-in is terrible: users are going to shy away and miss out on features and security (which by definition should be a default and not opt-in), so it is out of the equation imo. It also sends a terrible message which we decided we do not want associated to the project. > An implementation might sound good, but you'll never have actual insight into what is running Again this applies to almost anything server-side. I don't think Mozilla has ever been caught red-handed and we trust them for far more critical infrastructures: the code of the browser, certificate revocation, blocking lists. These are all far more critical, some of them are hosted on AWS btw. In the case of push, since we trust encryption Google is out of the equation other than the IP data point, which I addressed above. We could update the documentation to mention it is a WebSocket for push and not a periodic connection, but other than that I wouldn't do anything about push. Why would we even mention where it is hosted? Should we do this for everything? Does any website you use mention this and does it even matter? Seriously, it is a waste of time that leads to nothing just to make a noisy part of our community happy about their paranoid view of things and lack of threat model. I feel uncomfortable with this approach, when possible we should try to send the right message and educate. I see two cases with their relative threat model: * you need to protect your IP address so you use a VPN and there's no issue with this or any other connection to services that may log IP addresses; * you don't need to protect your IP address so this issue is out of your threat model and you're happy with your day. Removing the connection (and by that extent the feature) is kind of absurd. We don't have any telemetry so we don't know if people rely on push or not, some people opened issues in the past about wanting it and not having it (because SWers were disabled as they were not partitioned, which is the only reason why push was ever disabled, at least on my end). For completeness, as I mentioned on Reddit disabling the API is fingerprintable, even tho we are now discussing a different pref as mentioned above.

librewolf-bot commented 2023年08月07日 18:24:42 +02:00 (Migrated from gitlab.com)

Just to kind of make sense of it all: Bitwarden is (or at least was) hosted on Microsoft Azure. Does it make Bitwarden privacy invasive? You get the idea, this is privacy theater at its finest, overblowing stuff like this out of proportion is hurting the message that privacy matters to feed some weird obsession with absolute control over everything even if it leads to nothing.

Since we have kind of a big platform let's propose a sane threat model, that's how I see it.

Just to kind of make sense of it all: Bitwarden is (or at least was) hosted on Microsoft Azure. Does it make Bitwarden privacy invasive? You get the idea, this is privacy theater at its finest, overblowing stuff like this out of proportion is hurting the message that privacy matters to feed some weird obsession with absolute control over everything even if it leads to nothing. Since we have kind of a big platform let's propose a sane threat model, that's how I see it.

librewolf-bot commented 2023年08月07日 19:00:06 +02:00 (Migrated from gitlab.com)

Haha I was hoping to prevent a reply like this with

I realize this can be viewed as too untrustworthy ("this way you can't use any service"), but the key point I'm trying to make here is that the user has no choice in the matter from the start (and is insufficiently informed about it, which has caused all these threads and comments with concern and misinformation on Reddit of late).

...but I guess it didn't work 😉

I don't see the issue with outgoing connections other than the IP address

My reasoning was that having a constant connection to a fixed address for the entire duration of having the browser running is a reasonably accurate metric for e.g. ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser.

Just to clarify my stance in this, imho this is not about any fixation on a "zero connection status", or all the whataboutisms of the further infrastructure the user can't be in control of. To me it's about a program making use of a service that most don't even make use of and not informing the user (correctly) of the side effect: a permanent connection that to some extent exposes the use of the browser.

Not even Tor Browser cares about that.

Not sure if you meant "preventing all outgoing connections" in general or also mentioned Tor browser in relation to this issue in specific, but I just downloaded the Tor browser, installed it on a clean VM and checked the default settings:

image

So, the default setting in Tor browser is dom.push.enabled = false. Then again, this may have to do with the fact that it also disables service workers?

Making it opt-in is terrible: users are going to shy away and miss out on features and security

Security is no issue here, so I assume this is a more general statement. I think opt-in is not terrible if:

1. the service is of little use for your end users: LibreWolf clears cookies on exit by default, so push notifications for services will be reset on every start in the default conditions anyway

2. the service used to be disabled anyway and it is disabled in the only other Firefox-based browser that is adamant about fingerprinting

3. LibreWolf is already making an opt-in out of other services where that arguably does mean that the user misses out on security (Safe Browsing, but all right, that's a whataboutism to some extent)

4. some people opened issues in the past about wanting it

   I have found zero requests for enabling push notifications in GitLab issues. In contrast, there have been at least 7 GitLab issues specifically related to the connections made to the push server:

   • https://gitlab.com/librewolf-community/settings/-/issues/127
   • https://gitlab.com/librewolf-community/browser/arch/-/issues/88
   • https://gitlab.com/librewolf-community/browser/source/-/issues/70
   • https://gitlab.com/librewolf-community/browser/source/-/issues/105
   • https://gitlab.com/librewolf-community/browser/windows/-/issues/243
   • https://gitlab.com/librewolf-community/browser/windows/-/issues/342
   • https://gitlab.com/librewolf-community/browser/windows/-/issues/318

We could update the documentation to mention it is a WebSocket for push and not a periodic connection

That would be great!

Why would we even mention where it is hosted?

Not where they are hosted (this may even change in the future), but mentioning push.services.mozilla.com and autopush.prod.mozaws.net makes a lot of sense to me. If people then want to check their connections, then they at least have something to compare the IP addresses/ranges against.

Should we do this for everything?

No, but it would make sense for connections to a service the user probably doesn't know about (and that Tor browser also disables by default, for what it's worth).

Plus, these specific connections are the only explicit ones I see initiated if you fully firewall LibreWolf, apart from the request to install uBlock Origin. So they tend to stand out for people who have a look.

Haha I was hoping to prevent a reply like this with > I realize this can be viewed as too untrustworthy ("this way you can't use any service"), but the key point I'm trying to make here is that the user has no choice in the matter from the start (and is insufficiently informed about it, which has caused all these threads and comments with concern and misinformation on Reddit of late). ...but I guess it didn't work 😉 > I don't see the issue with outgoing connections other than the IP address My reasoning was that having a constant connection to a fixed address for the entire duration of having the browser running is a reasonably accurate metric for e.g. ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser. Just to clarify my stance in this, imho this is not about any fixation on a "zero connection status", or all the whataboutisms of the further infrastructure the user can't be in control of. To me it's about a program making use of a service that most don't even make use of _and_ not informing the user (correctly) of the side effect: a permanent connection that to some extent exposes the use of the browser. > Not even Tor Browser cares about that. Not sure if you meant "preventing all outgoing connections" in general or also mentioned Tor browser in relation to this issue in specific, but I just downloaded the Tor browser, installed it on a clean VM and checked the default settings:  So, the default setting in Tor browser is `dom.push.enabled` = `false`. Then again, this may have to do with the fact that it also disables service workers? > Making it opt-in is terrible: users are going to shy away and miss out on features and security Security is no issue here, so I assume this is a more general statement. I think opt-in is not terrible if: 1. the service is of little use for your end users: LibreWolf clears cookies on exit by default, so push notifications for services will be reset on every start in the default conditions anyway 1. the service used to be disabled anyway and it is disabled in the only other Firefox-based browser that is adamant about fingerprinting 1. LibreWolf is already making an opt-in out of other services where that arguably _does_ mean that the user misses out on security (Safe Browsing, but all right, that's a whataboutism to some extent) 1. > some people opened issues in the past about wanting it I have found zero requests for enabling push notifications in GitLab issues. In contrast, there have been at least 7 GitLab issues specifically related to the connections made to the push server: - https://gitlab.com/librewolf-community/settings/-/issues/127 - https://gitlab.com/librewolf-community/browser/arch/-/issues/88 - https://gitlab.com/librewolf-community/browser/source/-/issues/70 - https://gitlab.com/librewolf-community/browser/source/-/issues/105 - https://gitlab.com/librewolf-community/browser/windows/-/issues/243 - https://gitlab.com/librewolf-community/browser/windows/-/issues/342 - https://gitlab.com/librewolf-community/browser/windows/-/issues/318 > We could update the documentation to mention it is a WebSocket for push and not a periodic connection That would be great! > Why would we even mention where it is hosted? Not where they are hosted (this may even change in the future), but mentioning `push.services.mozilla.com` and `autopush.prod.mozaws.net` makes a lot of sense to me. If people then want to check their connections, then they at least have something to compare the IP addresses/ranges against. > Should we do this for everything? No, but it would make sense for connections to a service the user probably doesn't know about (and that Tor browser also disables by default, for what it's worth). Plus, these specific connections are the only explicit ones I see initiated if you fully firewall LibreWolf, apart from the request to install uBlock Origin. So they tend to stand out for people who have a look.

librewolf-bot commented 2023年08月07日 20:07:53 +02:00 (Migrated from gitlab.com)

ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser.

1. Traffic towards the server is encrypted so again other than the IP address there is nothing else that these middle-man can see. The IP address is the ONLY data point.
2. We are back to the IP address and again: non-issue for LibreWolf, use a VPN etc...

What is being exposed exactly? It's not whataboutism, if anything it's a real world look in an effort to understand what we can and cannot achieve, and what we should or should not care about.

This outgoing connections stuff is all philosophical BS, because once again: what is the data point? IP address. What is the threat model? You tell me, and you take actions if needed, otherwise you're good to go. It doesn't get much more precise and factual than this honestly...

Not sure if you meant "preventing all outgoing connections"

Yup.

Instead speaking of push in TB, as you said they also flip dom.serviceWorkers.enabled. TB doesn't even use dFPI on that matter, so partitiong is different from LW.

the service is of little use for your end users

the service used to be disabled

We do not have data about this, but either way why wouldn't we support it? It is an IETF specification, the code exists and we don't have to do anything. It was disabled for different reasons as I said.

I swear somebody asked back then, I don't know where but it was asked a few times. And I personally don't care if users are complaining about outgoing connections if I might be painfully honest: all those issues are people screaming "ON HO BAD CONNECTION BUUU" and bringing nothing to the table, they could open 100k of these issue and it wouldn't make their stance correct honestly.
Users are not entitled to get what they think it's correct only because the project is open source. I understand others might disagree and I'm kind of strict when it comes to this kind of stuff, so don't feel offended by my wording which might come off as strong, I apologize in advance if that's the case. But I believe we should operate with some standards regardless of the community nature of the project, did I make sense?

As for the documentation part, I'll write something more precise soon.

PS: safe browsing is a completely different matter. We lack the keys sadly, I've been rather vocal in saying we should enable local checks and I already know I will re-iterate some of the things I'm saying today when the day comes :-)

> ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser. 1. Traffic towards the server is encrypted so again other than the IP address there is nothing else that these middle-man can see. The IP address is the ONLY data point. 2. We are back to the IP address and again: non-issue for LibreWolf, use a VPN etc... What is being exposed exactly? It's not whataboutism, if anything it's a real world look in an effort to understand what we can and cannot achieve, and what we should or should not care about. This outgoing connections stuff is all philosophical BS, because once again: what is the data point? IP address. What is the threat model? You tell me, and you take actions if needed, otherwise you're good to go. It doesn't get much more precise and factual than this honestly... > Not sure if you meant "preventing all outgoing connections" Yup. Instead speaking of push in TB, as you said they also flip `dom.serviceWorkers.enabled`. TB doesn't even use dFPI on that matter, so partitiong is different from LW. > the service is of little use for your end users > the service used to be disabled We do not have data about this, but either way why wouldn't we support it? It is an IETF specification, the code exists and we don't have to do anything. It was disabled for different reasons as I said. I swear somebody asked back then, I don't know where but it was asked a few times. And I personally don't care if users are complaining about outgoing connections if I might be painfully honest: all those issues are people screaming "ON HO BAD CONNECTION BUUU" and bringing nothing to the table, they could open 100k of these issue and it wouldn't make their stance correct honestly. Users are not entitled to get what they think it's correct only because the project is open source. I understand others might disagree and I'm kind of strict when it comes to this kind of stuff, so don't feel offended by my wording which might come off as strong, I apologize in advance if that's the case. But I believe we should operate with some standards regardless of the community nature of the project, did I make sense? As for the documentation part, I'll write something more precise soon. PS: safe browsing is a completely different matter. We lack the keys sadly, I've been [rather vocal in saying we should enable local checks](https://gitlab.com/librewolf-community/settings/-/issues/126) and I already know I will re-iterate some of the things I'm saying today when the day comes :-)

librewolf-bot commented 2023年08月07日 21:09:36 +02:00 (Migrated from gitlab.com)

ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser.

1. Traffic towards the server is encrypted so again other than the IP address there is nothing else that these middle-man can see. The IP address is the ONLY data point.
2. We are back to the IP address and again: non-issue for LibreWolf, use a VPN etc...
   What is being exposed exactly? It's not whataboutism, if anything it's a real world look in an effort to understand what we can and cannot achieve, and what we should or should not care about.

This outgoing connections stuff is all philosophical BS, because once again: what is the data point? IP address. What is the threat model? You tell me, and you take actions if needed, otherwise you're good to go. It doesn't get much more precise and factual than this honestly...

Yeah there's no payload to intercept, that's true. But there isn't ONLY IP address as data point. There is a shitload of metadata due to the fact that there is a longlasting connection, so we're talking about that IP in relation to all the timestamps and durations as datapoints.

Not sure if you meant "preventing all outgoing connections"

Yup.

Instead speaking of push in TB, as you said they also flip dom.serviceWorkers.enabled. TB doesn't even use dFPI on that matter, so partitiong is different from LW.

Got it!

the service is of little use for your end users

the service used to be disabled

We do not have data about this, but either way why wouldn't we support it? It is an IETF specification, the code exists and we don't have to do anything. It was disabled for different reasons as I said.

Fair enough.

I swear somebody asked back then, I don't know where but it was asked a few times.

And I personally don't care if users are complaining about outgoing connections if I might be painfully honest: all those issues are people screaming "ON HO BAD CONNECTION BUUU" and bringing nothing to the table, they could open 100k of these issue and it wouldn't make their stance correct honestly.

I'm sorry you've become a bit sour with respect to these kinds of things. Personally, I think it's only good that users question these things and check for themselves, because the simple fact is the entirety of this is so complex that mistakes are easily made. They can potentially "not be found out" for a very long time if people aren't encouraged to confront devs about it. The tone in which they do that is a different matter, true.

To prevent this kind of thing, it does help to be as specific as possible in the docs/FAQ. I think a good example of this is https://divestos.org/pages/network_connections

Users are not entitled to get what they think it's correct only because the project is open source. I understand others might disagree and I'm kind of strict when it comes to this kind of stuff, so don't feel offended by my wording which might come off as strong, I apologize in advance if that's the case. But I believe we should operate with some standards regardless of the community nature of the project, did I make sense?

In general about these kinds of things, absolutely.

For this specific issue, I'm sure more specific info can help prevent further similar requests... and the best way to resolve it once and for all would be to go the opt-in way + adding a toggle to the LW settings pane 😎😅

As for the documentation part, I'll write something more precise soon.

Thanks, that'd be great! 🙂 Also, once there is, you have a better pre-conceived answer to link to for the next incarnation of this issue... 😛

PS: safe browsing is a completely different matter. We lack the keys sadly, I've been rather vocal in saying we should enable local checks and I already know I will re-iterate some of the things I'm saying today when the day comes :-)

Right, of course! I knew that 🙈 Well, we'll cross that bridge when we get there 😉

> > ISP, malicious VPN and potential MITM or CDN with regard to how often, at what times and how long a specific user (IP) is making use of a (Firefox-based) browser. > > 1. Traffic towards the server is encrypted so again other than the IP address there is nothing else that these middle-man can see. The IP address is the ONLY data point. > 2. We are back to the IP address and again: non-issue for LibreWolf, use a VPN etc... > What is being exposed exactly? It's not whataboutism, if anything it's a real world look in an effort to understand what we can and cannot achieve, and what we should or should not care about. > > This outgoing connections stuff is all philosophical BS, because once again: what is the data point? IP address. What is the threat model? You tell me, and you take actions if needed, otherwise you're good to go. It doesn't get much more precise and factual than this honestly... Yeah there's no payload to intercept, that's true. But there isn't ONLY IP address as data point. There is a shitload of metadata due to the fact that there _is_ a longlasting connection, so we're talking about that IP in relation to all the timestamps and durations as datapoints. > > Not sure if you meant "preventing all outgoing connections" > > Yup. > > Instead speaking of push in TB, as you said they also flip `dom.serviceWorkers.enabled`. TB doesn't even use dFPI on that matter, so partitiong is different from LW. Got it! > > the service is of little use for your end users > > > the service used to be disabled > > We do not have data about this, but either way why wouldn't we support it? It is an IETF specification, the code exists and we don't have to do anything. It was disabled for different reasons as I said. Fair enough. > I swear somebody asked back then, I don't know where but it was asked a few times. >And I personally don't care if users are complaining about outgoing connections if I might be painfully honest: all those issues are people screaming "ON HO BAD CONNECTION BUUU" and bringing nothing to the table, they could open 100k of these issue and it wouldn't make their stance correct honestly. I'm sorry you've become a bit sour with respect to these kinds of things. Personally, I think it's only good that users question these things and check for themselves, because the simple fact is the entirety of this is so complex that mistakes are easily made. They can potentially "not be found out" for a very long time if people aren't encouraged to confront devs about it. The tone in which they do that is a different matter, true. To prevent this kind of thing, it does help to be as specific as possible in the docs/FAQ. I think a good example of this is https://divestos.org/pages/network_connections > Users are not entitled to get what they think it's correct only because the project is open source. I understand others might disagree and I'm kind of strict when it comes to this kind of stuff, so don't feel offended by my wording which might come off as strong, I apologize in advance if that's the case. But I believe we should operate with some standards regardless of the community nature of the project, did I make sense? In general about these kinds of things, absolutely. For this specific issue, I'm sure more specific info can help prevent further similar requests... and the best way to resolve it once and for all would be to go the opt-in way + adding a toggle to the LW settings pane 😎😅 > As for the documentation part, I'll write something more precise soon. Thanks, that'd be great! 🙂 Also, once there is, you have a better pre-conceived answer to link to for the next incarnation of this issue... 😛 > PS: safe browsing is a completely different matter. We lack the keys sadly, I've been [rather vocal in saying we should enable local checks](https://gitlab.com/librewolf-community/settings/-/issues/126) and I already know I will re-iterate some of the things I'm saying today when the day comes :-) Right, of course! I knew that 🙈 Well, we'll cross that bridge when we get there 😉

librewolf-bot commented 2023年08月14日 22:15:19 +02:00 (Migrated from gitlab.com)

moved from settings#1

moved from settings#1

librewolf-bot commented 2023年08月16日 22:02:16 +02:00 (Migrated from gitlab.com)

This issue was migrated from Codeberg/Settings#1

This issue was migrated from [Codeberg/Settings#1](https://codeberg.org/librewolf-archive/settings/issues/1)

fxbrit commented 2023年08月26日 02:39:52 +02:00

In a pull request I added the WebSocket detail to the FAQ so that it is clearer. If we want to document more stuff about outgoing connections in the future it can be discussed elsewhere I believe.

PS: push notifications cannot be exploited for spam in LW because they require a cookie exception (service workers).

In a pull request I added the WebSocket detail to the FAQ so that it is clearer. If we want to document more stuff about outgoing connections in the future it can be discussed elsewhere I believe. PS: push notifications cannot be exploited for spam in LW because they require a cookie exception (service workers).