Slashdot Mirror

" IE was a problem because it did a bunch of random shit that wasn't a standard or was entirely proprietary"

just like Chrome
https://developer.chrome.com/a...

there wouldn't be a distinction between the differing browsers if they were universal, like it or not Chrome is the new IE its just a shame that dickwad n00b developers chose to standardize on one made by a fucking NYSE listed surveillance company.

I'd still want an ad blocker. It's optional anyways. Don't like the performance? Don't install the extension.

It should be pointed out that the new API being proposed will actually make adblocking more efficient. The new API allows extensions to configure Chrome with a set of rules that specify what URLs to block. These rules would be evaluated by Chrome, in native code. In contrast, the method currently used by adblockers is an API that simply calls a snippet of extension-provided Javascript on each network request. While this can be fast if the adblock extension author codes it well, it clearly will never be as efficient as matching rules implemented in native code.

The source of the controversy is that the new API has an upper bound on the number of rules that can be provided: 30K So an adblocker could not add more than 30K adblocking rules. The message from Devlin Cronin (lead engineer for the extensions team) implies that they think that should be enough for good adblocking, if rules are managed properly. He cites research which finds that 90% of the 60K EasyList rules aren't useful, which implies that the same adblocking benefit would be achieved with 6K rules. Clearly, huge rule lists will be slower than small rule lists. Cronin says the rule list size limit will be increased, though there will still be a limit.

For anyone interested in the technical details, here's the documentation of the new API: https://developer.chrome.com/e... and of the existing API: https://developer.chrome.com/e...

I'd still want an ad blocker. It's optional anyways. Don't like the performance? Don't install the extension.

It should be pointed out that the new API being proposed will actually make adblocking more efficient. The new API allows extensions to configure Chrome with a set of rules that specify what URLs to block. These rules would be evaluated by Chrome, in native code. In contrast, the method currently used by adblockers is an API that simply calls a snippet of extension-provided Javascript on each network request. While this can be fast if the adblock extension author codes it well, it clearly will never be as efficient as matching rules implemented in native code.

The source of the controversy is that the new API has an upper bound on the number of rules that can be provided: 30K So an adblocker could not add more than 30K adblocking rules. The message from Devlin Cronin (lead engineer for the extensions team) implies that they think that should be enough for good adblocking, if rules are managed properly. He cites research which finds that 90% of the 60K EasyList rules aren't useful, which implies that the same adblocking benefit would be achieved with 6K rules. Clearly, huge rule lists will be slower than small rule lists. Cronin says the rule list size limit will be increased, though there will still be a limit.

For anyone interested in the technical details, here's the documentation of the new API: https://developer.chrome.com/e... and of the existing API: https://developer.chrome.com/e...

I think you're right. First, looking at the new specs for declarativeNetRequest, I see no indication that the webRequest api is going away. Each API has pros and cons, from what I can see.

I do see changes happening to webRequest. It now requires host permissions. That means the end user can limit where an extension is used - or not limit it. Starting in Chrome 72 it will also be harder to modify referrers or cookies. But nothing webRequest does now is being entirely forbidden (unless the end-user requests it.)

I think you're right. First, looking at the new specs for declarativeNetRequest, I see no indication that the webRequest api is going away. Each API has pros and cons, from what I can see.

I do see changes happening to webRequest. It now requires host permissions. That means the end user can limit where an extension is used - or not limit it. Starting in Chrome 72 it will also be harder to modify referrers or cookies. But nothing webRequest does now is being entirely forbidden (unless the end-user requests it.)

The declarativeNetRequest API only allows extensions to block or redirect requests. The webRequest api is more flexible as compared to the declarativeNetRequest API because it allows extensions to evaluate a request programmatically.

Seems to say all that needs to be said.

And while chrome OS can be locked down just as much by IT admins, it's not mandatory and you can install from third parties, and yes, you can run competing web browsers as a native app and even configure it as the default browser.

How does that work? I thought Chrome OS had only two ways to run native applications other than Chrome itself:

A. Native Client (NaCl), which requires applications to be ported and made available through Chrome Web Store. I'm not aware of any third-party browsers that have been, and I'm not even sure whether it allows JavaScript JIT. Besides, Google has deprecated Native Client in favor of Emscripten, which compiles C++ to JavaScript or WebAssembly.
B. Developer mode, which causes the firmware to display prominent self-destruct instructions for 30 seconds (to the effect "Press Space then Enter for a factory reset") during the boot process.

  you had to be in developer mode to use any native application other than Chrome, and developer mode caused the firmware to display prominent self-destruct instructions for 30 seconds during the boot process. Or what competing

And while chrome OS can be locked down just as much by IT admins, it's not mandatory and you can install from third parties, and yes, you can run competing web browsers as a native app and even configure it as the default browser.

How does that work? I thought Chrome OS had only two ways to run native applications other than Chrome itself:

A. Native Client (NaCl), which requires applications to be ported and made available through Chrome Web Store. I'm not aware of any third-party browsers that have been, and I'm not even sure whether it allows JavaScript JIT. Besides, Google has deprecated Native Client in favor of Emscripten, which compiles C++ to JavaScript or WebAssembly.
B. Developer mode, which causes the firmware to display prominent self-destruct instructions for 30 seconds (to the effect "Press Space then Enter for a factory reset") during the boot process.

  you had to be in developer mode to use any native application other than Chrome, and developer mode caused the firmware to display prominent self-destruct instructions for 30 seconds during the boot process. Or what competing

I need to learn where all the tools

It sounds like you haven't explored the Google dev tools in-depth.

https://developer.chrome.com/d...

What's not there natively is available as an extension that will still work after Google updates chrome. While FF or QF extensions will have to be re-patched by the extension developer before they can be used again.

In some cases after an update to FF I had to manually remove the extension before FF would even load.

I doubt that's the case.

The Chrome for iOS User-Agent string is not the same as the Mobile Safari User-Agent string.

That page even shows how the two differ. Chrome's contains a "CriOS" component.

Organizations that specialize in collecting browser market share information are surely aware of that and take it into account when compiling their statistics.

The more plausible answer is that Firefox for iOS has, from a statistical perspective, essentially no users. Firefox for Android is barely recognized. Firefox for iOS probably can't, for all intents and purposes, even be seen in a meaningful way.

The difference between Java/C# and C/FORTRAN/etc. is when the transformation from AST to machine code happens.

unless you are using Chrome's PNaCl, and then it happens at the same place, even for C++.

Since Chrome allows memory access

To which API are you referring? Google chrome javascript memory access returned nothing relevant. There is chrome.system.memory , but that's available only in extensions that declare the system.memory permission, not to scripts in an HTML document. Or are you referring to rowhammer?

Has Google announced plans to port the Chrome app titled "NaCl Development Environment" to "standards-compliant HTML5 / NaCl"? Because that's the only way I know of to develop software in any language other than JavaScript on an unmodified Chromebook. Let's say I use NaCl Development Environment on a Chromebook and another IDE on a desktop computer to work on the same project: the Chromebook while I'm riding transit or the desktop computer at home or at work. How would I go about synchronizing the project between both applications? I had assumed that if NaCl Development Environment were available on both the Chromebook and the desktop computer, I could use Google's sync. But once NaCl Development Environment can no longer run on a desktop computer, that option is off the table.

Our company is increasingly getting work done in the cloud.

That's great provided you're willing to pay your employees' cellular data bills so that they can VNC or RDP into your application server while away from a desk. Otherwise, your users will have to stick to Chrome apps specifically designed for offline use. If you have programmers, for example, Google's in-browser NaCl IDE is no perfect substitute for Linux- or Windows-based IDEs. Google warns: "to develop a substantial application for Native Client / Portable Native Client, we recommend you use the Native Client SDK" which is designed for Windows, macOS, and X11/Linux.

Is this Native Client?

Yes.

Can C++ Chrome apps be built directly on the device, or must they be cross-compiled?

They can be built directly on the device using the NaCl Development Environment, available in the Chrome Web Store for free.

Here's the description from the Chrome Web Store:

In-browser development environment for Native Client

Native Client In-browser Development Environment.
Bash, make, git, gcc, python, ruby, lua, in the browser. Online or offline.
Limited arm supported (interpreters, but no compiler).
(Beta)
https://developer.chrome.com/n...
http://gonacl.com/fire

Disclaimer: I've never used it--it might suck. ;-)

Firefox for Android supports extensions, and the top 3 extensions are privacy related:

https://addons.mozilla.org/en-US/android/

Chrome for Android does NOT support extensions.

Does Chrome for Android support apps and extensions?
        Chrome apps and extensions are currently not supported on Chrome for Android. We have no plans to announce at this time.

https://developer.chrome.com/multidevice/faq

"Writing VLC in JavaScript and other Web technologies, as Chrome OS requires, is not an easy task by any stretch."

No... ChromeOS has ways to write native and semi-native apps:

NaCL - https://developer.chrome.com/n... and PNaCL

That said, if you already have a functional Android app, ARC is probably easier. Works great for Quasseldroid if you remove one socket configuration call (TCP_KEEPALIVE socket option) currently not supported by ARC.

Yes with ARC welder from Google, I can run Android apps on my Linux machine and possibly others.

Also, I disabled Chrome.

Uh, yes, but it doesn't work that way. I'm pretty sure that Dolphin uses webview to display webpages on android (I think almost every browser except Firefox and Opera do -- most 3rd party browsers just write a simple GUI wrapper for webview) ... and all versions of Android starting from KitKat include the v8 javascript engine as part of webview:

https://developer.chrome.com/m...

More concerningly, if you're using KitKat, webview won't be updated without a system update (it got moved to an APK in lollipop). So that exploit is probably good forever ... :( (For lollipop and above I'd assume that the exploit will get fixed in webview the same time as it gets fixed in chrome.)

From the scant details I would guess that this affects more than just users of the Chrome for Android browser. The exploit is in v8 (or at least in how Chrome uses v8), which is in both Chromium and Chrome. Since Android 4.4, WebView is based on the same code as Chrome for Android. So I would think any Chromium-based browser for Android or any apps using WebView would be vulnerable.

Of course, not a lot of information was given so who knows. I have an e-reader and it feels great knowing it's not connected to the internet so I'm not being spied on, tracked, and that no one can remotely hack and break my device (or delete books or otherwise mess with my experience). I actually feel more free and at ease using it. Sigh.

Native messaging support is on Microsoft's radar. If they don't do something like that, IE is likely to be around for a very long time. Or companies will just Chrome instead.

https://twitter.com/shimonamit...
https://developer.chrome.com/e...

WebKit and Safari are not the same thing. You seem to be falsely conflating the two. I suggest you read Google's own FAQ about this:

Chrome seems slower when handling Javascript compared to Safari.
Rendering and the Javascript engine are provided by iOS through UIWebView. Because Chrome does not have access to Safari’s Nitro engine, Chrome may have slower javascript performance.

What are the differences between UIWebView and Safari?
Mobile Safari uses the Nitro JS engine, which is often faster than the one in the UIWebView. UIWebView scrolling may appear slower, since it renders on the main thread, while Mobile Safari renders in a background thread. There are other differences, some of which are described in this StackOverflow question.

Gentoo is a distribution of Linux (or GNU/Linux or whatever you want to call it) probably best known for its method of software updates where source is compiled on-the-fly to binary as part of the "portage" update system.

ChromeOS is Google's linux (kernel)-based operating system which essentially has a Chrome browser act as the entire user-facing operating system. Apps are written in HTML5/Javascript, etc.

NaCl (Native Client) is a new feature of Chrome that lets you run native (or in PNaCl, ie Portable Native Client, it's a platform-agnostic format that is quickly converted to native binary before running) code from within the browser, all in a sandboxed environment. You can actually get a shell within the browser and compile and run binary apps inside the browser as well. See the Google IO video about this.

The app code is all running on top of the Chrome platform, specifically inside of Native Client. In this way the ARC (Android Runtime for Chrome) apps run in the same environment as other apps you can download from the Chrome Web Store, even though they are written on top of standard Android APIs.

The runtime probably includes some modified version of the entire android framework, etc. meant to be wrapped up by a Chrome browser window and interact with Chrome's input/output, etc.

I don't see how this WON'T be ported quickly to Linux by someone, though it'll likely need Chrome/Chromium. Nothing has stopped Android source from being ported to regular ol' linux except that no one has done it yet. But this work by Google will probably make it easier to include in Chrome.

Incidentally, on Ubuntu, NaCl isn't compiled in, so you may want to get a version in which it is. You can turn it on by following the instructions here.

Gentoo is a distribution of Linux (or GNU/Linux or whatever you want to call it) probably best known for its method of software updates where source is compiled on-the-fly to binary as part of the "portage" update system.

ChromeOS is Google's linux (kernel)-based operating system which essentially has a Chrome browser act as the entire user-facing operating system. Apps are written in HTML5/Javascript, etc.

NaCl (Native Client) is a new feature of Chrome that lets you run native (or in PNaCl, ie Portable Native Client, it's a platform-agnostic format that is quickly converted to native binary before running) code from within the browser, all in a sandboxed environment. You can actually get a shell within the browser and compile and run binary apps inside the browser as well. See the Google IO video about this.

The app code is all running on top of the Chrome platform, specifically inside of Native Client. In this way the ARC (Android Runtime for Chrome) apps run in the same environment as other apps you can download from the Chrome Web Store, even though they are written on top of standard Android APIs.

The runtime probably includes some modified version of the entire android framework, etc. meant to be wrapped up by a Chrome browser window and interact with Chrome's input/output, etc.

I don't see how this WON'T be ported quickly to Linux by someone, though it'll likely need Chrome/Chromium. Nothing has stopped Android source from being ported to regular ol' linux except that no one has done it yet. But this work by Google will probably make it easier to include in Chrome.

Incidentally, on Ubuntu, NaCl isn't compiled in, so you may want to get a version in which it is. You can turn it on by following the instructions here.

It's still the goal of PNaCl variant of Native Client ( https://developer.chrome.com/n... ). But I haven't heard of anyone actually using this.

From the Chrome Developer page:

1. Unzip the .crx file
2. Go to chrome://extensions
3. Tick on Developer Mode
4. Click Load Unpacked Extension...
5. Select and install.

If Google was actually interested in pushing the limits of the Web as a platform, they'd find a way to provide local file access from JavaScript.

Google could even call it something like chrome.fileSystem or File API.

I bought a Nexus 10 and was horrified to learn that it had no out-of-the-box capability to access local files of any kind

Then you didn't try plugging your into a Windows PC to copy files on and off it using MTP. (On Linux, recent versions of gvfs have added MTP support, and it should land in Ubuntu LTS next year.) The other way is to go to Google Play Store and download Rhmsoft File Manager. I use it on my first-generation Nexus 7 tablet to browse SMB shares over Wi-Fi, copy files to the device's internal memory, and launch them on the device.

it can't even display something as simple and universal as a PDF file on a USB flash drive.

I'm over 98 percent sure that the USB flash drive came formatted in a file system on which Microsoft owns one or more United States patents. Google and ASUS don't want to pay more royalties to Microsoft than they have to, which is why a lot of devices have been dropping support for microSD cards and USB flash drives. Use MTP over USB or SMB over Wi-Fi to copy local files onto your device.

This is due to Chrome's webrequest extension API: http://developer.chrome.com/extensions/webRequest.html

Thank you for this! Was looking for a reference to it.

This is due to Chrome's webrequest extension API: http://developer.chrome.com/extensions/webRequest.html

Here you go.

Chrome OS/Chromium OS is [...] way different than the easy to use grandma friendly linux desktop. Not everyone only needs to surf the net or check their mail,f,y,t* account .

What does such a user do other than read web pages, watch Dailymotion and YouTube, edit Google Docs, or check webmail, Facebook, and Twitter? If you could name a few things that she would expect to do on a computer that can't be done as web applications or as packaged applications that use the Chrome APIs, that'd help me understand exactly why you consider Chromium OS "way different than the easy to use grandma friendly linux desktop".

I use the AmazonMP3Downloader plugin so when I purchase music from Amazon it gets added to my music library immediately.

AFAIK PPAPI (and NaCl) can't implement that because they need to save the music to places outside the sandbox.

AmazonMP3Downloader could be split into a part that runs inside Chrome and a separate process that downloads the file, and the two parts would communicate with Chrome native messaging. It's like when Windows Vista came out: applications that needed to run in the background with administrative privileges needed to be split into an elevated service and a not-elevated GUI.

I've been browsing more and more in Incognito mode... at least (in theory) my Google searches don't trigger a rash of new ads. I've a family member on my wife's side who needs medical treatment, and i make sure I hit incognito mode with the searches for info for them.

I hate that my searches on my phone now show up on my desktop. I hate that a joke query on my ipad for a porn site that happens to be close in name to a place i wanted to visit now ends up on my desktop google. I hate that google tried to tie desktop and browser with games and not mention their ulterior motive.

At my work, we were given a book "From Good to Great". Google is going "From Good to Corporate". Forget "Don't be evil".. try "Don't be a typical corporation"

Wrong. Since I follow the situation closely, let me explain.

The HTML5 Web Notifications API is in Chrome since forever under webKitNotifications.

The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up.
Chrome implemented both, extension authors happily started using it.

Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.

Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.

However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.

But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.

Wrong. Since I follow the situation closely, let me explain.

The HTML5 Web Notifications API is in Chrome since forever under webKitNotifications.

The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up.
Chrome implemented both, extension authors happily started using it.

Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.

Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.

However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.

But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.

Those who recommend a Chromebook - they don't consider that there will be times when you have no internet connectivity and want to use your tablet.

How should that stop anyone from choosing Chrome apps designed with offline first?

but with all the thousands of Android apps ported to Chrome

How exactly does this work, apart from applications built with Cordova or its predecessor PhoneGap? Android applications are written in the Java programming language or an NDK language or both, not JavaScript, which is what Chrome apps use. So how are Android apps ported to Chrome?

I really want to see Packaged Apps take off across all browsers, mobile and desktop. I'm willing to take a little performance hit to have apps available across all platforms.