Consider disabling push #1
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.jsfor an empty profile with the following contents:and the connection was not made anymore.
I also tested with only
dom.webnotifications.serviceworker.enabledordom.webnotifications.enabledinstead (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
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.
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.enabledin 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.Additionally, we could make it easier for users to toggle
dom.push.enabledvia the LibreWolf specific settings panel.Edit:
Seems to be circumventable: instead of setting
dom.push.enabledto false, settingdom.push.connection.enabledto false results in PushManager still being available in the window properties, while the connection is not initiated.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.
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).
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:
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".
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).
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.
dom.push.enabledtodom.push.connection.enabledYup, thanks 😄
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.
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:
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.
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.
Haha I was hoping to prevent a reply like this with
...but I guess it didn't work 😉
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 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?Security is no issue here, so I assume this is a more general statement. I think opt-in is not terrible if:
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
the service used to be disabled anyway and it is disabled in the only other Firefox-based browser that is adamant about fingerprinting
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)
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:
That would be great!
Not where they are hosted (this may even change in the future), but mentioning
push.services.mozilla.comandautopush.prod.mozaws.netmakes 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.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.
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...
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.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 :-)
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.
Got it!
Fair enough.
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
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 😎😅
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... 😛
Right, of course! I knew that 🙈 Well, we'll cross that bridge when we get there 😉