I'm not as concerned with the Hello integration. With both features, I'd like to know more on the technical details.

For Hello, I think Mozilla (but actually unsure who's servers?) is only involved in initial discovery and, if needed, WebRTC NAT traversal. In terms of code bloat, I think Hello is just a bit of extra javascript on top of functionality already built into the web platform.

But I admit I haven't look that much into it. I don't know how or if crypto is used. I haven't used the feature yet either and would want to know more before using it in a corporate or privacy sensitive situation.

I guess the same goes for Pocket, I probably don't need to worry about it if I'm not using it. However, for me personally, it just seems to be such a stark contrast with their position on Sync. On top of that, the browser UI is _mine_! Nobody - not even Mozilla - should be adding something to the primary interface of _my browser_ without a very good reason. And this is where I feel my trust has been betrayed for the first time.

Hello uses Telefonica servers. My guess is that Mozilla's partnership with Telefonica is the reason why Hello was added to Firefox.

Not really. Hello was added in order to offer an alternative to Skype/FaceTime that uses open Web technologies and does not require you to create accounts or upload contacts. The partnership with Telefonica made it more convenient since they host the server side.

What's your beef with Hello, exactly? The whole point of Hello is to offer an alternative to Skype/FaceTime that uses open Web technologies and does not require you to create accounts or upload contacts. How does that not appeal to the privacy-conscious?

Because it doesn't belong within the core browser framework. A browser should not tie to your "internet identity", whether it's an account or a cookie fingerprint. That actually is the business of a service to manage.

Because it wasn't a choice I made to install it, and since it's not something I'll use, it's useless for me. I do use pocket, but I'd much rather use it as an extension vs a special integration with who-knows-what different permissions / sandboxing / control vs an extension.

Both features have near-negligible overhead if you don't use them. But having them in the product makes them accessible to the wide userbase, many of whom don't know what addons are or how to install them.

Therefore it seems reasonable to add them to Firefox.

I'd much prefer them to improve the memory and performance reporting features over adding some features that goes against their core values. right now I have a firefox that uses tons of ram and slows down to a halt very frequently but there are no decent tools to diagnose what addin/plugin/webpage/bug might be causing trouble. it's very, very frustrating.

edit: I am talking about multiple gigs of memory for firefox and multiple gigs of memory in the kernel task allocated for who knows what. stop firefox and it lowers the kernel memory to a reasonable level and (obviously) removes the memory usage of firefox.

I see this argument all the time in the form of "why are they working on the UI instead of the backend?" Well, because UI engineers and backend engineers are different people and don't share one-another's competencies, is why. The people who are adding these things probably don't know how to improve Firefox's performance. They're probably networked-multimedia engineers scratching their own itch.

(And it's not like Firefox's performance has any low-hanging fruit left; there have been years of performance improvements already, and only someone versed in those would know how to take them further.)

The ui for about:memory is bad and not very useful in tracking down where the memory is going or leaking. That's something the ui engineers can do to help Firefox with this.

It's useful to Gecko engineers, ie. the people who actually have to fix it.

There are a lot of people working on performance - it's just less press-worthy than new features, so less noticed I guess. But bugs do exist, of course. Do you see anything odd in about:memory that can help diagnose your specific issue?

Sorry to say that, but about:memory is useless to me. When memory runs low and system starts swapping (slowing down to a crawl) my first priority is to get computer running again, so I have to close firefox. That helps, but about:memory no longer has the data that would lead to the culprit.

Even if I could look at histotic data, the UI of about:memory is just plain awful. Charts anyone? My main question is how the consumption of memory for each tab is changing through time and I haven't found a nice way to see that yet.

Also, browser should protect me from pages which use too many resources. Why should some random page be able to stop my computer from working? I am seriously considering running firefox inside docker container just so I can limit its resources.

Note that I am a huge fan of ff and use it everywhere, but this has been a sore point for me for ages.

I agree that it's a tough problem and they have smart engineers working on it. The about:memory anonymizer makes the output useless to the engineers looking at the bug. A better way would be to anonymize it but still keep it identifiable if you have the key. Say make each page a uuid or something so that the engineer can say, "search for this uuid in your in anonymous report and that's leaking memory"

It seems that the tools to diagnose what has been the most criticized series of bugs in Firefox are still lacking. Ideally it should list the plugins used and the memory of each along with a way to identify the heavy pages etc.

If that's the intention, they failed horribly. Not because the lack of adoption, but because a propietary server is involved. Only the client is open.