I feel like people don't take the Chromium monopoly seriously. Sure, Brave is great, but it's still chromium, making Google have outsized say over how the web behaves. Manifest V3 was the proof, every Chromium browser had to live with it. If this helps Firefox gain ground, I'm all for it.
I'm working on a demanding project that has performance as a fundamental requirement. Unfortunately Firefox turned out to be disappointing: audio/video codecs not supported or supported badly, and decidedly poor performance. Chrome instead is decidedly on another level. My opinion is that firefox prefers the road of features, neglecting the care of performance, and maybe this also depends on the fact that Mozilla doesn't have a big company behind it like chrome has google. It's a big problem, because on this road I don't see a great future for firefox, and we would end up on a road of de facto monopoly, which is not good for anyone.
Always happy to get bug reports about audio/video playback issues or performance gaps. We have a built-in profiler that makes it very likely we can narrow down the cause and fix it: https://firefox-source-docs.mozilla.org/performance/reportin... ... IF someone actually submits a bug with a profile.
I've been trying to use the Firefox profiler and no matter what I did it always throws a "SyntaxError: JSON.parse: unexpected non-digit at line 1 column 1018761 of the JSON data" Only errors when I'm trying to profile MY web application, which primarily uses three.js. Couldn't find anything relating to issues with the Firefox profiler online, but I found your comment so here's me going straight to the source.
Can you please file a bug in Bugzilla with all the details? A colleague who works on this feature may be able to help get any relevant logging out of it to pinpoint the bug.
If the site is public and the issue happens in a fresh profile, just a link here would likely do the trick.
I didn't use new versions of firefox because the system has to run on the current stable version of debian. On android it's simple: there chrome works perfectly, firefox I had to discard it because WebCodecs is missing completely, a whole class of features. Anyway I'm available to do a test campaign and give detailed information
Hi, I ran a test campaign on my machine to measure the differences between the various versions of firefox and chrome. The results are available on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=2081675
You're an edge case. To the average user, one who has never used extensions before, the experience of using the web with Firefox and uBO is an order of magnitude better and, yes, faster than anything they have experienced before.
This is great, question though, since you support coding agents like Claude Code and Codex, they run MCP servers, plugins, web search/fetch and their own telemetry from the dev's machine. Do you give customers guidance or controls for that side, or is it out of scope for the gateway?
To build on this: a gateway controls where the model request goes, but with coding agents the data often leaves another way. A tool result can include file contents, and then the model can be steered into putting that data into a web fetch URL or a call to some third-party MCP server. That traffic never goes through the gateway, because it starts from the client machine. So the real boundary has to include an egress allowlist on the developer's machine or in its sandbox, not just the model endpoint. I'd be curious whether Consus ships a recommended client-side configuration, or treats that as the customer's job.
We had a lot of problems letting finding a balance giving technical coworkers acces to live data and AI tools. And there are multiple companies in this space that solve things in multiple ways, we happen to use https://gluondb.com which is what you describe plus BI.
Food for thought, tool and MCP calls run locally, but every request carries the tool list and every response carries the model's tool calls, both of which pass through you. You could strip non-approved tools from the request and block calls to them in the response, based on an org allowlist. That gives you org-approved MCP/tool calls without touching the dev's machine.
Great call. We already block certain tool schemas and flag URLs in tool-call arguments, and since we enforce org allowlists for models on every request, extending that to tools/MCP is a natural next step.
GH reliability has been a regular question mark lately, and many time issues are not reported publicly too.
In the past 2 months I've seen 3+ instances where GH action were not triggered on commit pushes, leading to silent workflow failures, and seeing GH merge queue being stuck for 3+ hours for production product facing repos
