161–170 of 180 posts
Earlier quoted context omitted.
Chrome's Flash Player uses PPAPI (Pepper), not NaCl. Pepper Flash is still running Adobe's native code, not NaCl code.
So it's using the NaCl sandbox and interface without the bytecode parts?
Another reason to switch to Iridium Browser. It has Google search disabled by default and even if you switch search to Google, Voice search and hot-words stay off until you manually enable it. https://iridiumbrowser.de/
another one is "Iron browser"
Earlier quoted context omitted.
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)....…
>Granted many are not as feature rich, but they'll still be HTML5 compliant. 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.
And if you want to get pedantic about HTML5 being a moving target, technically it's not. People often lump the other web front end components (CSS, SVG, EMCAScript, etc) under the HTML5 heading - those components will obviously have their own specification enumerations. Furthermore, a lot of the tertiary technologies that are a moving target are either experimental features / proposed drafts (ie not part of the final specification) or browser specific extensions. Most sites tend to avoid using these without fallback code for non-supporting browsers (demo sites being the obvious exception).
Earlier quoted context omitted.
> 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…
> In all seriousness though, what are your options: 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) a…
I'd already addressed that. In fact you quoted it when you posted your condescending reply. An explanation is worthless if the code cannot be reviewed. Such a feature should either be opt-in and/or open source.
I couldn't care less what explanation Google give, I just don't want this built into my browser.
> It's normal to have a collection of patches in the package file / port.
It is, but then you're relying on your package maintainers to patch Chromium (or compile the software yourself). Thus personally I think it's easier just to use another browser which doesn't need to be patched to remove an unwanted feature.
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.
You just described PNaCl, not NaCl. NaCl is architecture specific and already sandboxed (ie the SFI part of NaCl), whereas PNaCl is not.
Earlier quoted context omitted.
Is this true of Chrome as well? If so, I will never run it again.
They are sandboxed "machine independent" binary blobs that chrome translates into the local architecture, see https://developer.chrome.com/native-client for details. Javascript isn't far off binary in terms of readability nowadays with the level of packing/minification, so legibility isn't a deciding factor. Therefore if you can't trust the native client sandbox, why trust javascript, or even HTML from third parties?…
NaCl is not PNaCl. NaCl blobs don't require translation and aren't machine independent at all.
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.
Both NaCl and the plugins are running native code. NaCl is not PNaCl.
The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a. This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it…
I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not need to trust Google engineers to tell you this; the open source Chromium code has the logic to decide whether to run the plugin.
I have posted a detailed response (including the link to the place in the Chromium source code where the module gets run) on our bug tracker at http://crbug.com/500922#c6.
The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a. This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it…
Hi, I'm an engineer from Google responsible for the hotword module. I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not…