Chrome Apps to be deprecated

[tanx]

See http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html

[yzrmn]

Maybe relevant: https://developer.mozilla.org/en-US/Add-ons/WebExtensions

WebExtensions are a cross-browser system for developing browser add-ons. To a large extent the system is compatible with the extension API supported by Google Chrome and Opera. Extensions written for these browsers will in most cases run in Firefox or Microsoft Edge with just a few changes.

[tanx]

Yeah. Either an extension or an electron app seem to be the alternatives: http://electron.atom.io

[aaronraimist]

An extension seems to make a lot of sense Signal desktop if going to stay connected to a browser (instead of going to a standalone app). Since a few things are going to have to be rewritten anyway, lets try to add support for Firefox. See #871 (comment)

[cowlicks]

It'd be nice to see some designs for how signal would look as an extension before diving into it. I'm happy to help with this effort.

[Integral]

Why don't you want to try electron app? It's very much like browser app, but wrapped with different platforms apis, so you can build menus, bind to keyboard events etc. But eventually you get standalone app and not the browser extension which is a bit annoying. Look at the slack app or atom editor!

[r-a-y]

Why don't you want to try electron app?

Electron bundles the Chromium engine. This makes things inefficient if you were already using the Signal Chrome App with Google Chrome or Chromium since you will have to download a separate program that will bundle Chromium again.

That's why I would prefer a Chrome extension instead (this would also make porting to Firefox or Edge potentially easier as well). Just my two cents.

[Integral]

Well, it's true that electron's app bundle not a very tiny thing. It will add couple of dozens mbs to your app. But still, it will be app.
If you are using chrome as your browser, would you use firefox or edge just to run your app?
Regarding porting i think it's equally. There are number of chrome things here like notifications etc which should be ported anyways.

[yzrmn]

Electron bundles the Chromium engine. This makes things inefficient if you were already using the Signal Chrome App with Google Chrome or Chromium since you will have to download a separate program that will bundle Chromium again.

This. I really don't understand why ppl are trying to build an application using web technology in the first place. Yes, there are advantages because most of the resources are available offline. But this wouldn't be a problem with WebExtensions, cmiiw
I would prefer an extension, too, it just feels "more" right to me.

If you are using chrome as your browser, would you use firefox or edge just to run your app?

You don't need to, WebExtension are designed to be cross-browser :)

[rodneyrod]

WebExtensions doesn't even provide all the interfaces needed to implement Signal since it goes beyond what would be considered an 'extension', so that unfortunately cannot happen.

[anatomism]

I so much more prefer a dedicated app. Not everyone uses Chrome and some of my users actively forced closed Chrome (on OS X) when they saw it was open (they use Safari) thereby killing Signal... Maybe Electron isn't the answer long term, but I do like it as a short term fix

[DKhalil]

I would also much prefer an Electron (or however implemented standalone app).
As far as I know, the WhatsApp desktop client is also an Electron app

[sha-265]

IMHO, web extension is inconvenient, because of the fact that the extension running within the browser window.
Anyway NW.js have full chrome API support, and they declare they will continue support Chrome apps:

NW.js can run Chrome Apps directly and we'll continue supporting it. Chrome App developers can redistribute their application after packaging with NW.

Staring from version 0.13, NW.js brings most features in the Chromium browser, including Chrome Apps support, chrome. platform APIs. We support all chrome. API in the Chrome App platform.

Moreover the changes that will need to be made are minor (I thought about an independent updater for example, any other ideas?). I already build NW.js version of Signal Desktop (with this guide), with only one change I had to do in scss file, and it's working great.
As far as I know Electron is not fully support Chrome API, therefore it will be need more changes.

Edit: Now I noticed, after closing the Signal NW.js app and reopen, the app has been reset and you need to reconfigure it, But I think it's easy to solve. And other minor bugs.

[smonsays]

Maybe I am out of the loop, but why isn't it possible to build a proper webapp in the first place? Those who want a browser extension would be happy and for those, who want a desktop app, a framework like electron could be used.

[Marenz]

One thing that I read on the mailing list that the developers consider important is the update process.
With chrome apps, google takes care of

• Authenticity
• Distribution
• Notification

All that are non-trivial things to solve if you need to do them yourself which they apparently want to avoid if possible.

[Marenz]

Mind you, we didn't have any input from the main committer @liliakai in here yet

[Marenz]

Judging from other responses in other tickets, discussion should probably happen at https://whispersystems.discoursehosting.net/t/google-to-retire-chrome-apps-what-will-be-with-signal-desktop/469

See also https://lists.riseup.net/www/arc/whispersystems/2016-08/msg00023.html

[ghostsynth]

Maybe I am out of the loop, but why isn't it possible to build a proper webapp in the first place? Those who want a browser extension would be happy and for those, who want a desktop app, a framework like electron could be used.

I absolutely agree. In fact, the Chromium page even suggests migrating Chrome apps to web apps..

This would make the most sense to me since a big goal of using Chrome apps / app store distribution method is to ensure that users have a safe and secure method of distribution. It also makes it far more accessible than just packaging via Electron.

I think the WhatsApp Web version is probably a good template to learn from: https://web.whatsapp.com/

[sha-265]

It's not making any kind of sense if you want a secure, private and open source encrypted messaging application, to run it from remote server.

[peacememories]

Since I haven't seen it proposed here already, I personally believe a good direction to take would be a Progressive Web App. This seems to also be the direction Google is taking to replace their Chrome Apps, and while it would work alright "immediately", it would get better over time, with more integrations arriving in the browsers.

Edit: While I realise most current "native" integrations of PWAs are meant for mobile, Chrome Beta currently supports installation and I've heard Microsoft is working on integrating them into their store experience (link)

[davidmyersdev]

@Bitim I don't think they are saying that the application is going to be run from the server. With modern web app capabilities, the entire application could run in the client (and possibly even communicate via a p2p protocol such as WebRTC). I personally think that another solution (at least during migration) could be to use Electron Chrome. It's wraps most of the Chrome App APIs so that migration from a current Chrome App is incredibly simple. Thoughts?

[sha-265]

@Drm2 even if the code running locally from your own browser (that is, in fact, not so safe), the problem is that you download the application's code from remote server automatically every time. If this remote server hacked and the attacker add malicious code to the application, your browser will download this code automatically, run it and can compromise you data. That's what WhatsApp do.

[davidmyersdev]

@Bitim I definitely see your point. If progressive web apps gained full desktop support, it wouldn't be much of an issue. I guess the only great solutions are to use something like Electron Chrome (to make migration easy) or to build a native desktop app.

[peacememories]

@Bitim I fully agree that security is of utmost importance for this app. And while I would like to point out that with code served over tls at least users could be sure they are getting the code from the correct source, I agree that code should not update without the users consent. Luckily, no "full desktop support" for progressive web apps is needed to provide this. Service Workers allow indefinite caching of source code on the client, with update prompts displayed, so users can opt in to version changes.
Two problems remain, then.

• For browsers that do not support the Service Worker API yet, I believe a warning should be displayed that the application may change at any time.
• I do not quite have the expertise to speak to the security problems of running crypto in JavaScript, but it seems to mostly concern code delivery, which I discussed above. Other than that, the same concerns should apply to the current Chrome App and possible future Electron apps, leaving only native applications as a secure alternative.

[smichel17]

Seems like even without indefinite caching, if the website delivers signed code, a browser extension that automatically verifies the signatures, version #, etc would solve many of the issues raised in this thread.

[ryanleesipes]

Would much prefer an Electron app.

[Beanow]

@smichel17 I think requiring an extension for the code delivery creates a security vs ubiquity situation. And I think that's not the space Signal tries to operate in. And then you're also just shifting the problem to how to securely deliver that extension. Manual signature verification?

Likewise @ryanleesipes Electron doesn't seem to do that great a job at being unilaterally secure and straightforward with delivery either, for example from the auto updater section:

Linux
There is no built-in support for auto-updater on Linux, so it is recommended to use the distribution’s package manager to update your app.

Ideally this is something that gets fixed in web standards.

[Beanow]

And while I would like to point out that with code served over tls at least users could be sure they are getting the code from the correct source, [...]

@peacememories there are at least two major differences from the app/play store model though. And I think especially in areas like cryptocurrencies with cold vs hot wallets, this difference has been quite obvious.

In a store, the app is:

• Signed by keys that the software maintainer owns and can (potentially) keep entirely offline.
• Delivered from a predictable, highly scrutinized and preconfigured distributor. (Google / Apple)
• Signature verification is enforced by the client depending on local settings.

Compared to a TLS resource from a webserver, which is:

• Signed by keys that the web server owns and must keep online.
• Delivered from wherever their DNS tells them to request it, assuming they made no spelling errors and there are no phishing links involved.
• Signature verification is enforced by the client depending on the server's response like HSTS instructions.

Am I missing some capabilities here that allow you to do this in a browser?

[ghost]

Here is a recent article talking about the possible migration from Chrome to Firefox : http://mckay.pub/2016-11-18-webextensions/
Hope it will be possible someday.

[joelweinberger]

Hi everyone! This is a great thread and raises some great use cases that we over at Chromium haven't considered too closely before. We definitely have a very explicit goal to make the open web as useful and safe as Chrome Apps, so it would be great to leverage this use case to extend the web so that Signal can safely exist there. So if any of you are up for it, I'd highly encourage you to think about what the web platform would need to make this possible, because we can (and do!) extend the web platform all the time. In short, if we can't implement Signal securely as a web app, then the web is broken, and we should fix it.

In particular, on Chromium, I work on the Open Web Platform Security Team, where we work on exactly the types of features that we're discussing here (and our friends over at Mozilla have a very similar team as well). If you're interested in making suggestions or starting discussions, emailing [email protected] or [email protected] are fantastic places to start.

Some specific places that we've been working on ideas that might be relevant here include:

• Subresource Integrity: This is a spec that allows developers to specify a hash for resources that are about to be loaded and guarantees that the resource is going to match said hash. This is already implemented and available in Firefox, Chrome, and Opera. This is not what is needed for this project, but it's on the way there :-) Specifically, we've been talking about adding signature verification in addition tohash verification, which is getting closer to what I think is desired here. If that's somehow implanted into and cached with the web manifest, we're getting really close to App parity for verification. If someone is interested in filing a bug and suggestion for this for the Subresource Integrity spec, I think that would go a long way in pushing it forward.
• The other big difference here that's not discussed is that Chrome Apps have a separate cookie jar and are not web accessible by other web apps. That's huge because it means that XSS, CSRF, and other web attacks are much, much less of a concern. This is one reason we're brainstorming a Isolation feature for the web, so that highly sensitive apps can indicate to the user agent that they probably shouldn't be open web accessible. Again, comments on that doc would be very, very welcome.

What other features are needed to bring web parity for Signal? What can user agents do to make the web better for security-sensitive apps like Signal? Personally, WhatsApp is much more useful to me because of https://web.whatsapp.com, but I understand that it opens security issues that Signal is trying to avoid, so I'd love to try to fix these issues.

As a side note, I would argue that the distributor case mentioned above as a difference between the web and apps isn't very compelling and shouldn't be considered a security boundary for what you're concerned about. It wouldn't be hard to sneak a minor piece of code past either Apple or Google in your app that subtly leaks client keys, for example. And even if this is caught eventually, you'd still be sad if it ever reached any client. In general, I believe it is a large mistake for developers to rely on the app review process as strong security boundary.

P.S. I'm actually on paternity leave right now, so my apologies if I take a while to respond to anything.

[tajnymag]

How about using the phone itself as a server? Similar to https://web.whatsapp.com/ but completely without the public server.

[nils-werner]

Hosting the webchat on the phone is not a good idea, as it would...

• Require the phone being reachable from the PC. Depending on your network layout and the phone being in WiFi or not, that might not be the case.
• Open the phone to the internet, if you want access when phone not in WiFi.
• Require the user to know the phone IP/hostname. Most people probably don't. And it would be very hard to create TLS certificates for the phone, making it very prone to MITM attacks.
• Require the phone to be able to start a webserver. Apparently that's possible, but port 80 usually requires root. Keeping the server open might be tricky as Android tries to have as few app services running as possible.
• Probably waste battery quickly.

[strugee]

@nils-werner not to mention the absolutely huge amount of complexity that would introduce.

[Beanow]

@metromoxie glad to see you're on top of it as well!

I didn't mean to imply that a 3rd party app review held any security benefit preventing malicious code. What I meant to suggest was that having a store greatly reduces spoofing methods. After all, in a sense you could say that Google / Apple play a role similar to a certificate authority. The thoroughness of authentication varies, but you're a lot less likely to end up with the wrong content as opposed to using self-signed certificates or straight up public keys.

Also you are provided with much more information to see if the app you're about to install will be the one you intended to install. Something you will find in a store, but not find doing a web search:

• Install numbers
• Ratings and comments
• The developers' name
• "Top developer", official status / endorsement of high profile developers' accounts

And the scrutiny bit was more about the platform itself rather than the app review. For example if Google finds a major security flaw in their Play store, major tech news channels would pick this up the same day Google sends out a notification.

---

Anyway, $5 wrench attack methods aside. Here are some things that I believe are missing in an HTTPS delivered application, that are noteworthy for new web standards. Not claiming to be an expert though, so hopefully other participants will pitch in on this.

• Signed resources, like you mentioned as well.

  • Packaging / bundling because there is no sensible way to guarantee your app is as-intended when different file versions can be mixed and matched. An all-or-nothing approach should prevent issues like race conditions during uploading.
  • Offline private keys are critical here. Otherwise there's no benefit over HTTPS certificates.
  • Matching keys by default. Once a web app is "installed", browsers should throw a security error if updated resources do not originate from the expected identity (pub key / certificate) of the publisher they originally installed from.
  • Identity management. The role which is currently pushed onto CA's and stores. Securely yet transparently revoking and updating certificates for the developers. Because lost or compromised keys will happen.

• Installation flow, which is what progressive web apps are doing. But could use an extension.

  • Require signed resources by default, on top of any HTTPS requirements, the above identities and signatures should also be the default. Not doing so is simply begging for attackers to turn off signature verification on compromised servers. Any new installations will be completely without validation (assuming existing installations will detect this and throw security errors). Alternatively you could go for the alert style "this is dangerous, do you know what you're doing?" like self-signed HTTPS certificates.

• Extensions, add-ons and plug-ins. Although this is more in the realm of browser implementations than web standards.

  • App-level control, normally I would use extensions exactly to protect my privacy and security. For example if I had installed a news feed app with social buttons, analytics and ads, a blocker can help prevent leaking data about my reading habits. For Signal though I would take the opposite stance, as there is nothing to block, it can only serve as a new attack vector and given their permissions, I'd think they are more likely to exfiltrate my messages and keys than anything.
  • Local over server setting. This probably goes without saying. Imagine the $_$ signs in people's eyes when they hear eliminating browser extensions can be done now. The user must be the one in control for disabling extensions for all / certain apps.
  • Opt-in during installation (opinionated). Using extensions I think deserves an opt-in per installation, as a blocking step at installation time. If you need to dig into settings to disable them, your Signal keys might already be compromised by then. If you need to dig into settings to enable them, the news feed has already started pulling in 3rd party trackers. Also thinking again about hypothetical moms and aunts again, they wouldn't have a clue that they should be poking around in the settings to make this choice.

Some issues that I don't expect to see resolved using standards or browsers alone:

• Finding apps safely. As opposed to curated, centralized and pre-configured ubiquitous stores. The beauty of the web is in it's decentralization. Unfortunately that makes it inherently more risky. Some band-aid solutions may be, asking search engine giants to offer web app searches with comments and ratings, and extending the browser-integrated malicious sites service to web apps.

• Teaching users to do the right thing. Security is as good as the weakest point. If that weakest point is users being unaware of the correct approach to securing themselves, it's a pretty big deal for overall security, especially in a communications app where the external party might lose your shared conversations. For most stores this is already dealt with for us, with the web I'm happy when people even know what the green lock is. These are the $5 wrench approaches I meant. Typo domain names, phishing, public QR code shenanigans. There's an array of well known and sometimes simple attacks that in theory have mitigations or solutions but go wrong all the time anyway.

[fde31]

Interesting read here. I just recently switched to Signal and scratched my head around the possibility of having a dedicated Electron/NW.js/YouNameIt build/installer to run it on a Desktop. I've been using WhatsApp and Telegram b4 and must say (leaving security, tech stack etc aside now) that the dedicated app approach works much much better for personal use-case instead of running web.whatsapp.com with being forced to have my phone on/WA running etc.

Of course this kinda ignores the discussion of moving to an extension for now. I guess that's mainly due to the lack of experience I have in using but also writing WebExtensions so far. So while I do appreciate the nicely layed out arguments by @Beanow above I don't consider 3rd party store distribution an increase security tech-wise but more from a clear user communication/distribution standpoint (he refers to it as $5 wrench approaches). So I wonder how we could reduce this in a move to a WebExtension.

Another experience I'd like to share is comparing the Telegram Desktop vs. Hangouts experience. Not from a security but more from a user experience perspective. I might be a bit too picky but f.e. I get annoyed by the Chrome style notifications in Hangouts compared to the Telegram ones that integrate neatly with the OS, which also gives me a clear, distinct way of changing the prefs/settings for these etc instead of starting to dive deep in the Chrome settings etc. Taking this as an example (although definitely not an important one) I think it might be interesting to have a more layed out comparison of what feature sets would be possible with a WebExtension approach compared to an Electron one etc.

Not having too much insight into the WebExtension API so far I wonder what @rodneyrod meant when he stated that the WebExtension API doesn't offer the feature set necessary for Signal.

Either way, I'd be happy to support, help and investigate on this matter.

[rkoesters]

As a Linux user, I would say the Electron apps do a much better job of integrating with the Linux desktop than Chrome Extensions. I know most of this discussion has been about the security behind each decision, but it might be a good idea to consider user experience of using the app (although it probably won't be the first priority, it is still important).

[urbaniak]

I'm also voting for electron. It's adding some overhead but with much more native "feeling". It gives native notifications, menu bar support and separate application (UIApplication) on mac (so you can switch using cmd+tab from any app instead of switching to chrome and cmd+`).

[ghost]

Hi, as a user I think that a simple web app, with the crypto code running locally, would make more sense. It could be used by anyone with just a browser, without even needing to install something else, which is one of the reasons services like Facebook are so successful.

Of course I understand that there are security problems to overcome, but I find the web app more future-proof.

[pedzed]

without even needing to install something else, which is one of the reasons services like Facebook are so successful.

You are comparing apples to oranges. Social media is not meant to be a native desktop application (it does not even feel right). An IM app on the other hand is meant to be native. A browser version could be a plus, but a native app is definitely a must-have.

[strugee]

@pedzed

Social media is not meant to be in the browser (it does not even feel right).

I don't follow - did you perhaps mean to say that it is meant to be in the browser?

In any case, the above statement as well as this one:

An IM app on the other hand is meant to be native.

are both opinions presented as facts. IM apps aren't "meant" to be anything in particular. It's up to the creators and designers of the software to figure out what their product "should" be.

[pedzed]

@strugee Yeah, haha. I made a mistake (and corrected my comment accordingly).

In regards to my thoughts about social media not supposed to be a native desktop application, I base it on facts. Although I did not do research, it is obvious that sites such as MySpace, Twitter and Facebook would have never been a success if every person had to download a piece of software.

[ghost]

it is obvious that sites such as MySpace, Twitter and Facebook would have never been a success if every person had to download a piece of software

Of course, and Signal is no exception. IM is a key feature of social networks, so we can't really dissociate the two.

Signal will never be widely used if it's not accessible through the Web. I know nobody who would even consider a messaging service that asks him to install a desktop app to use it on a computer.

[pedzed]

Signal will never be widely used if it's not accessible through the Web. I know nobody who would even consider a messaging service that asks him to install a desktop app to use it on a computer.

My friend, you need a SIM card... And remember that I did not exclude web.

[rkoesters]

Signal will never be widely used if it's not accessible through the Web. I know nobody who would even consider a messaging service that asks him to install a desktop app to use it on a computer.

Is that really the use case though? Correct me if I'm wrong, but a vast majority of people that use Signal use the smartphone app (I mean, it uses a phone number as an identifier). The desktop app isn't really a users first time using Signal, it is more a supplemental piece of software.

Also understand that some people feel differently, for example: my personal preference is for a local app instead of a website. That is just my opinion and there isn't exactly any merit behind it.

[pedzed]

@ag-n as I said, and @rkoesters, @urbaniak and others confirmed, a native desktop app is preferred, but if time permits, we could have both. I do not however think that that is realistic. It just requires too many resources (i.e. time, knowledge, etc.).

I wonder though, what about ChromeOS? And how many people (would) use ChromeOS?

[ghost]

I understand the lack of resources and the technical difficulty, it's just a solution that I would prefer, and that would (I think) make it easier for most people to switch to Signal.

I wonder though, what about ChromeOS? And how many people (would) use ChromeOS?

I don't think it's popular enough to dedicate resources to it ; a Windows/Mac/Linux app would be way more useful. Maybe later, if the market changes.

[moxie0]

Thanks everyone, but we try not to use GitHub for discussion. I think we have all the information we need in this issue, if you'd like to continue discussion please see the online forums. Thanks!