151–160 of 180 posts
Note that although this bug report was forcibly closed, the fix is "This change adds an "enable_hotwording" build flag that is enabled by default , but can be disabled at compile time." Consider what this backdoor does. It listens to any conversation in the vicinity of the phone and reports it to a remote site. You can't see its keyword list. You can't tell when it's transmitting to the mothership. Has anyone filed a…
https://projects.archlinux.org/svntogit/packages.git/commit/...
thanks to the maintainer and the FOSS community in general.
Earlier quoted context omitted.
Licensing is not the issue. Microsoft could not add NaCL to IE in the same sense that it could not add Firefox' DevTools to IE. It would require a major rewrite and cost tremendous heaps of money.
I've gotta raise an eyebrow on that one. If it's a major rewrite to support a new plugin authoring language, your plugin architecture was a terrible mess to begin with. Given that we're supposed to believe that New Internet Explorer was pretty much a from-the-ground-up rewrite, I can't imagine that their plugin architecture is a terrible mess.
Earlier quoted context omitted.
I didn't even know this "native client sandbox" existed! Why the hell should I trust it, or anything executed inside it? I'm tentatively willing to believe that Chrome is probably not trying to pwn my box, because I don't think Google has a compelling reason to do that which would outweigh the flak they would get if they were caught. Allowing them to run arbitrary compiled executables on my machine, however, would re…
In some instances when served with an NSL (or some other mechanism we don't even yet know about), they can be forced through legal policy to cooperate in building something that pwns your box. Google's compelling reason is that they are under the jurisdiction of the American government. Though I share your tentative belief that Chrome/ium isn't necessarily a "pwn vector" per se, I am 100% willing to believe that they…
Basically lean on "Never attribute to malice that which is adequately explained by stupidity" as much as possible to fly under the radar as long as possible.
Earlier quoted context omitted.
> That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with. Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code. It's highly suggestive. > If you're really that paranoid about closed source components within Google Chrome then the…
> Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code. It's highly suggestive. Indeed. But that doesn't change my statement. > Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up? Because you'd still have the same browser choices if you did move :p In all seriousne…
An obvious one, getting an explanation from the vendor / upstream before we proceed to any decision.
Vendors do tend to care about us.
> 1. fork Chromium and remove the closed components
It's normal to have a collection of patches in the package file / port.
> 2. use another browser > 3. moan on the internet
Issue trackers (such as one in the aforementioned posts) allow attachments / patches. They tend to be constructive.
Earlier quoted context omitted.
No, he means Chromium (like Android) in practice are read-only, hostile projects that respond only to Google's needs. Yes, you are free to create a fork. In reality, it's nearly impossible to keep up with Google's development pace and their behavior of dumping huge changesets and lack of documentation and communication wears everyone out. If you have some exposure to biology/ecology you'll recognize the behavior as v…
Unlike Android, Chromium is mostly developed in the open. As someone who has contributed to both projects, I wouldn't say Chromium is any less welcoming to contributors than Firefox. Mozilla is a lot better at presenting themselves in a positive light. Firefox even has similar automated downloaded of binary blobs like the EME plugin.
You're far more likely to have hidden discussions about features or get patches obsolete due to code drops out of the blue when trying to upstream to Chromium.
>Firefox even has similar automated downloaded of binary blobs like the EME plugin.
Mozilla's EME stuff was widely discussed, announced in advance, and coordinated with distros.
Not quite in the same league as this.
Earlier quoted context omitted.
The problem is that a browser does really want access to a whole lot of stuff as it's almost an OS. But no, Chromium doesn't run as root afaik, the rootkit stuff is complete bullshit.
The sandbox binary uses setuid root if user namespaces aren't available, but that's a necessity for making the empty chroot and process/network namespaces used to sandbox tabs. The layer-2 sandboxing code (seccomp-bpf) doesn't require anything like that, but they're meant to be complementary (although both are strict enough that they could act as a meaningful sandbox alone).
Earlier quoted context omitted.
While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.
Chrome's Flash Player uses PPAPI (Pepper), not NaCl. Pepper Flash is still running Adobe's native code, not NaCl code.
Earlier quoted context omitted.
It does, and I enjoy mp4 videos and I'm not bothered much by DRM on Netflix either, but should a component like NaCl implying a binary blob be part of an open source software.. by default? Feels weird to have it included with Chromium by default. Weren't Chrome and Chromium originally separated in order to make one compatible with open source distributions, so that this sort of thing would be avoided? A conflict with…
NaCl doesn't imply proprietary any more than a JavaScript engine does. The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. It's not substantially different from a freedom perspective than code compiled to asm.js or just minified JavaScript. Both are usually proprietary and require reverse engineering work to decipher.
Earlier quoted context omitted.
>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful. The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".
There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany). Konquorer was still kHTML last time I checked, but there are with webkit ports as well if that's really what you want. Then there's Opera, which on some platforms (eg Linux) is still using it's older renderer rather than Blink (see footnote); and Otter as well. There's quite a few Firefox forks too (eg Palemoon)....…
This is a meaningless statement. HTML5 is a moving target. And on top of that, webpage design has deteriorated to the levels we saw around 2000 again: to be usable, your browser has to mirror the most popular engines well enough that sites work.