6 ms·

AFAIK, you can install apps and extensions without going through the Chrome store, and if you have the source, you can certainly hack it to use an alternate sto

AFAIK, you can install apps and extensions without going through the Chrome store, and if you have the source, you can certainly hack it to use an alternate store host. The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend. I don't think forking ChromeOS is as difficult as forking Android.

fidotron 13y ago
That's like arguing that iOS is open since you could all become developers and distribute the ObjC. Not all Chrome apps are web apps ( http://developer.chrome.com/apps/about_apps.html http://developer.chrome.com/apps/about_apps.html ) and you can't distribute those packages trivially to end users, so the whole distinction is almost identical to the iOS situation, by design. Google's Chrome group have a serious case of Apple envy, and this is how it manifests itself. The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
- comex 13y ago
  fwiw, I don't think there is currently anything preventing you from accessing the Chrome Web Store from Chromium, without any kind of API key or proprietary extension. Of course that could theoretically change if someone started commercially distributing a forked Chromium OS, but we shouldn't blame Google for something it hasn't done.
  - fidotron 13y ago
    Irrelevant, since your users would still need a Google account to use that store, and developers would still need to publish through it. The whole problem is duplicating that store.
    - cromwellian 13y ago
      For Chromium, developers do not need to publish apps through the Chrome Store, nor do you need a Google account to use such apps. Chrome has the same side-loading capability of Android allowing install from unknown sources. There are apps that Google refuses from the Web Store that are distributed this way. I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.
      - fidotron 13y ago
        Except Chrome increasingly doesn't implement the standard. For example, Adobe's recent CSS stuff isn't in, and instead an early version of the shadow DOM stuff which even Mozilla doesn't agree with is going in, on top of all the Chrome app API itself. As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
        cromwellian 13y ago
        This is really a red herring grasping for straws. All browsers have proprietary extensions and have differences from the spec. HTML5 for the most part works because people use what's portable. Html5test.com wouldn't need to exist if this weren't true. The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium? Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use. And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence. The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into. That said, locally installed apps can provide services to other apps through multiple techniques: * Background pages (invisible HTML pages running in the background) * Shared Web Workers (spawned process that lives at a known address) * Custom Protocol Handler * Service Workers (intercept HTTP requests for resources) * Chrome Extension content page * WebRTC or local web server * Web Intents/Web Activities (got shelved by Google and Mozilla) From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work. This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
- cromwellian 13y ago
  Almost identical to iOS? Absolutely ridiculous analogy. ChromeOS doesn't compare to iOS at all and Chrome is far more open than Android in terms of development (All new Chromium development is done in the open and new releases happen nightly and every 6 weeks. Do you know what Android 4.5 will have in it yet?) 1. The majority of iOS apps can't be side loaded, are locked to the App Store. Vast majority of ChromeOS apps are not "Chrome Apps", it's a red herring. Plus, Chrome Apps can still be side loaded and are not locked to the Web Store. None of Google's major apps: GMail, Maps, Docs, YouTube, etc are actually "Chrome Apps" in this regard. Then will run on any ChromeOS fork. Chromium today supports side loading any app from the Extensions page without going through the Chrome Store. Simply put, it is not possible to create the kinds of Google-service lock-in agreements for ChromeOS that have been created for Android, because ChromeOS is just a web browser. 2. ChromeOS doesn't need to add hooks for app delivery contrary to your claims. The Chrome equivalent of an APK is a CRX file and CRX files can be self hosted, see "Hosted Apps". In fact, they used to auto-install if you just clicked a link pointing at one, but phishers/hackers took advantage of this, so now you have to go through the Extensions page. Any Web app you build for Chromium will work on any subsequent ChromeOS fork without needing to make any lower level changes, because Web apps don't have huge dependencies on local OS services. Many ChromeOS apps will even work on Firefox because again, the vast majority of Chrome apps don't really depend on local OS privileges like getting access to the USB port. Implementing a different app distribution mechanism is trivial. In practice, Android apps are far more likely to depend on non-AOSP services (like Google Play Services) than Web Apps are to depend on Chrome Web Store required services (of which there is only a tiny few, like push messaging). That's just the facts, so the practical reality is, forking AOSP creates more incompatibility than forking Chromium.
  - fidotron 13y ago
    Nope, look at the docs - you need developer stuff enabled to side load. The rest is being removed "for user safety". This makes it just like iOS, where if I'm a developer I can likewise sideload anything I have the source to. Chrome OS is _not_ just a web browser, as that link to the Chrome Apps stuff very clearly demonstrates. It's not "pure web" at all. This is PR nonsense, when there's a whole extra API. Clearly you don't like it being pointed out, but Chrome OS is Google's walled garden.

fidotron 13y ago

That's like arguing that iOS is open since you could all become developers and distribute the ObjC. Not all Chrome apps are web apps ( http://developer.chrome.com/apps/about_apps.html http://developer.chrome.com/apps/about_apps.html ) and you can't distribute those packages trivially to end users, so the whole distinction is almost identical to the iOS situation, by design. Google's Chrome group have a serious case of Apple envy, and this is how it manifests itself. The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.

comex 13y ago
fwiw, I don't think there is currently anything preventing you from accessing the Chrome Web Store from Chromium, without any kind of API key or proprietary extension. Of course that could theoretically change if someone started commercially distributing a forked Chromium OS, but we shouldn't blame Google for something it hasn't done.
- fidotron 13y ago
  Irrelevant, since your users would still need a Google account to use that store, and developers would still need to publish through it. The whole problem is duplicating that store.
  - cromwellian 13y ago
    For Chromium, developers do not need to publish apps through the Chrome Store, nor do you need a Google account to use such apps. Chrome has the same side-loading capability of Android allowing install from unknown sources. There are apps that Google refuses from the Web Store that are distributed this way. I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.
    - fidotron 13y ago
      Except Chrome increasingly doesn't implement the standard. For example, Adobe's recent CSS stuff isn't in, and instead an early version of the shadow DOM stuff which even Mozilla doesn't agree with is going in, on top of all the Chrome app API itself. As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
      - cromwellian 13y ago
        This is really a red herring grasping for straws. All browsers have proprietary extensions and have differences from the spec. HTML5 for the most part works because people use what's portable. Html5test.com wouldn't need to exist if this weren't true. The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium? Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use. And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence. The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into. That said, locally installed apps can provide services to other apps through multiple techniques: * Background pages (invisible HTML pages running in the background) * Shared Web Workers (spawned process that lives at a known address) * Custom Protocol Handler * Service Workers (intercept HTTP requests for resources) * Chrome Extension content page * WebRTC or local web server * Web Intents/Web Activities (got shelved by Google and Mozilla) From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work. This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
cromwellian 13y ago
Almost identical to iOS? Absolutely ridiculous analogy. ChromeOS doesn't compare to iOS at all and Chrome is far more open than Android in terms of development (All new Chromium development is done in the open and new releases happen nightly and every 6 weeks. Do you know what Android 4.5 will have in it yet?) 1. The majority of iOS apps can't be side loaded, are locked to the App Store. Vast majority of ChromeOS apps are not "Chrome Apps", it's a red herring. Plus, Chrome Apps can still be side loaded and are not locked to the Web Store. None of Google's major apps: GMail, Maps, Docs, YouTube, etc are actually "Chrome Apps" in this regard. Then will run on any ChromeOS fork. Chromium today supports side loading any app from the Extensions page without going through the Chrome Store. Simply put, it is not possible to create the kinds of Google-service lock-in agreements for ChromeOS that have been created for Android, because ChromeOS is just a web browser. 2. ChromeOS doesn't need to add hooks for app delivery contrary to your claims. The Chrome equivalent of an APK is a CRX file and CRX files can be self hosted, see "Hosted Apps". In fact, they used to auto-install if you just clicked a link pointing at one, but phishers/hackers took advantage of this, so now you have to go through the Extensions page. Any Web app you build for Chromium will work on any subsequent ChromeOS fork without needing to make any lower level changes, because Web apps don't have huge dependencies on local OS services. Many ChromeOS apps will even work on Firefox because again, the vast majority of Chrome apps don't really depend on local OS privileges like getting access to the USB port. Implementing a different app distribution mechanism is trivial. In practice, Android apps are far more likely to depend on non-AOSP services (like Google Play Services) than Web Apps are to depend on Chrome Web Store required services (of which there is only a tiny few, like push messaging). That's just the facts, so the practical reality is, forking AOSP creates more incompatibility than forking Chromium.
- fidotron 13y ago
  Nope, look at the docs - you need developer stuff enabled to side load. The rest is being removed "for user safety". This makes it just like iOS, where if I'm a developer I can likewise sideload anything I have the source to. Chrome OS is _not_ just a web browser, as that link to the Chrome Apps stuff very clearly demonstrates. It's not "pure web" at all. This is PR nonsense, when there's a whole extra API. Clearly you don't like it being pointed out, but Chrome OS is Google's walled garden.