[whispersystems] People want a standalone version of Signal for Desktop.

[Greg]

I ran a poll, and with 15 votes the results are in:

https://twitter.com/taoeffect/status/684064118974763008

13 for standalone.
2 for Chrome extension.

As some personal feedback, in my circle of friends and family many use the standalone Signal for mobile app, and only one person said they even tried the browser extension. Also, most of my family does not use Chrome but either Firefox or Safari.

Cheers,
Greg

[Josh]

Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.

It is magnitudes of effort easier to create and maintain one cross-platform
chrome app than to create three separate projects for linux, osx, and
windows. I believe that the core devs realize that many people would prefer
a standalone app, but have chosen to focus their efforts on making one
well-designed chrome app and bringing it to market instead of taking extra
time to write separate native apps. It's the same reason that they haven't
created a windows phone app and don't support encrypted SMS: there are more
important things for them to be working on right now.

Josh

Post by Greg
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many use the
standalone Signal for mobile app, and only one person said they even tried
the browser extension. Also, most of my family does not use Chrome but
either Firefox or Safari.
Cheers,
Greg

[c***@mailbox.org]

Your answer makes it sound like there were no way (apart maybe from
Java) to create a secure cross-platform binary. This is simply wrong.
With eg. Go it's pretty simple to cross-compile for all OSes. Go also
has many other features a security-focused tool like Signal could
benefit from. For example whole classes of memory management related
bugs simply don't exist.

Even ignoring both Chrome overreporting in the desktop use case due to
Android 4.4 and upwards using it as the default browser and Firefox
underreporting due to DOM-caching, Chrome has only around 50% of global
market share. This means the possible userbase for "Signal Browser"
isn't even every second desktop user. Advanced users also generally
favor Firefox over Chrome due to it's abundance of Addons.

In the long run the libaxolotl library for instant messenger programs
will improve this situation.

Can someone with more knowledge on the internal workings of Chrome apps
vs addons report on the possibility of an easy port over to Firefox,
once the addon API has officially changed to be compatible to Chrome?

Kind regards

curve25519

Post by Josh
Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.
It is magnitudes of effort easier to create and maintain one
cross-platform chrome app than to create three separate projects for
linux, osx, and windows. I believe that the core devs realize that many
people would prefer a standalone app, but have chosen to focus their
efforts on making one well-designed chrome app and bringing it to market
instead of taking extra time to write separate native apps. It's the
same reason that they haven't created a windows phone app and don't
support encrypted SMS: there are more important things for them to be
working on right now.
Josh
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many
use the standalone Signal for mobile app, and only one person said
they even tried the browser extension. Also, most of my family does
not use Chrome but either Firefox or Safari.
Cheers,
Greg

[Greg]

It has been pointed out in other threads on this mailing list (and elsewhere) that it would be fairly trivial to package the existing code (with minor modifications) by using one of the following:

http://electron.atom.io/
http://nwjs.io/

The security properties of doing so, as far as I can tell, would be at least the same, and most likely would be better since you would have more control of the code that’s running alongside Signal for Desktop.

Cheers,
Greg

Post by c***@mailbox.org
Your answer makes it sound like there were no way (apart maybe from
Java) to create a secure cross-platform binary. This is simply wrong.
With eg. Go it's pretty simple to cross-compile for all OSes. Go also
has many other features a security-focused tool like Signal could
benefit from. For example whole classes of memory management related
bugs simply don't exist.
Even ignoring both Chrome overreporting in the desktop use case due to
Android 4.4 and upwards using it as the default browser and Firefox
underreporting due to DOM-caching, Chrome has only around 50% of global
market share. This means the possible userbase for "Signal Browser"
isn't even every second desktop user. Advanced users also generally
favor Firefox over Chrome due to it's abundance of Addons.
In the long run the libaxolotl library for instant messenger programs
will improve this situation.
Can someone with more knowledge on the internal workings of Chrome apps
vs addons report on the possibility of an easy port over to Firefox,
once the addon API has officially changed to be compatible to Chrome?
Kind regards
curve25519

Post by Josh
Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.
It is magnitudes of effort easier to create and maintain one
cross-platform chrome app than to create three separate projects for
linux, osx, and windows. I believe that the core devs realize that many
people would prefer a standalone app, but have chosen to focus their
efforts on making one well-designed chrome app and bringing it to market
instead of taking extra time to write separate native apps. It's the
same reason that they haven't created a windows phone app and don't
support encrypted SMS: there are more important things for them to be
working on right now.
Josh
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many
use the standalone Signal for mobile app, and only one person said
they even tried the browser extension. Also, most of my family does
not use Chrome but either Firefox or Safari.
Cheers,
Greg

[Alice Pote]

nw.js has first-class support for chrome apps, so many chrome apps can be
run as native applications using nw.js with zero modification.

I tried this with the signal chrome extension and got a certificate related
error - but I imagine someone more familiar with the codebase would have a
fairly easy time of it.

Post by Greg
It has been pointed out in other threads on this mailing list (and
elsewhere) that it would be fairly trivial to package the existing code
http://electron.atom.io/
http://nwjs.io/
The security properties of doing so, as far as I can tell, would be at
least the same, and most likely would be better since you would have more
control of the code that’s running alongside Signal for Desktop.
Cheers,
Greg
Your answer makes it sound like there were no way (apart maybe from
Java) to create a secure cross-platform binary. This is simply wrong.
With eg. Go it's pretty simple to cross-compile for all OSes. Go also
has many other features a security-focused tool like Signal could
benefit from. For example whole classes of memory management related
bugs simply don't exist.
Even ignoring both Chrome overreporting in the desktop use case due to
Android 4.4 and upwards using it as the default browser and Firefox
underreporting due to DOM-caching, Chrome has only around 50% of global
market share. This means the possible userbase for "Signal Browser"
isn't even every second desktop user. Advanced users also generally
favor Firefox over Chrome due to it's abundance of Addons.
In the long run the libaxolotl library for instant messenger programs
will improve this situation.
Can someone with more knowledge on the internal workings of Chrome apps
vs addons report on the possibility of an easy port over to Firefox,
once the addon API has officially changed to be compatible to Chrome?
Kind regards
curve25519
Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.
It is magnitudes of effort easier to create and maintain one
cross-platform chrome app than to create three separate projects for
linux, osx, and windows. I believe that the core devs realize that many
people would prefer a standalone app, but have chosen to focus their
efforts on making one well-designed chrome app and bringing it to market
instead of taking extra time to write separate native apps. It's the
same reason that they haven't created a windows phone app and don't
support encrypted SMS: there are more important things for them to be
working on right now.
Josh
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many
use the standalone Signal for mobile app, and only one person said
they even tried the browser extension. Also, most of my family does
not use Chrome but either Firefox or Safari.
Cheers,
Greg

[Ismail Khoffi]

I agree that a standalone app would be great. But I also think
whispersystem did a great job so far and choosing a (first) simple
multiplatform solution approach (chrome app) was a good, efficient
choice. Anyways, I am also very curious now and I also have a lot of
friends who do not use chrome (spoiler: it works without *any*

Post by Alice Pote
I tried this with the signal chrome extension and got a certificate related
error - but I imagine someone more familiar with the codebase would have a
fairly easy time of it.

Short version (if you already have the chrome app):
I'm quite sure that this (the certificate err) should only happen if
you cloned the code and did not do anything else. For instance, this
will not happen if you download the app (or ask someone for a copy if
you refuse to use chrome) and use nw.js and the app dir (chrome stores
the apps/extensions here:
https://productforums.google.com/d/msg/chrome/6EVtjeaWObs/4MsUmcCnFsUJ).
In my case (mac os) this was two commands:

$ cp -r ~/Library/Application\ Support/Google/Chrome\
Canary/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.1.6_0 ~/
# one line, not two ...
$ nw ~/0.1.6_0 # voilà, you should see the startpage :-) no coding
required, only commandline

Tested with the latest beta of nw.js on mac os. In whispersytems'
defense: I'm sure when whispersystems started on the desktop app it
wasn't already so advanced that you can simply run (all?) chrome
apps...

From source version (5 instead of 2 commands, still no coding neccessary ;-)
# This assumes you have node/npm and nw.js properly installed ...
$ git clone https://github.com/WhisperSystems/Signal-Desktop.git
$ cd Signal-Desktop
$ npm install
$ grunt
$ nw ./dist

As I mentioned before, the certificate error might have occurred
because you just cloned the repo and tried to run it with nw.js. The
src code uses a staging server with a self-signed certificate:
$ openssl s_client -connect
textsecure-service-staging.whispersystems.org:443 -showcerts

The grunt command replaces the staging server with the real servers
(which have CA signed certs):
https://github.com/WhisperSystems/Signal-Desktop/blob/592ddc673be29f165b5c89412fdff73866e8d545/Gruntfile.js#L129-L133

As I said, I was just very curious if it's really that easy (and with
easy I mean maximum one/two hours of changing few lines and doing some
research). It is even easier than that... You do not need chrome and
you can easily 'compile' the app yourself (no registration for the
beta needed).
I would be curious if this works also on linux/windows (anyone?).

Cheers,
Ismail

On Tue, Jan 5, 2016 at 5:39 AM, Alice Pote

Post by Alice Pote
nw.js has first-class support for chrome apps, so many chrome apps can be
run as native applications using nw.js with zero modification.
I tried this with the signal chrome extension and got a certificate related
error - but I imagine someone more familiar with the codebase would have a
fairly easy time of it.

Post by Greg
It has been pointed out in other threads on this mailing list (and
elsewhere) that it would be fairly trivial to package the existing code
http://electron.atom.io/
http://nwjs.io/
The security properties of doing so, as far as I can tell, would be at
least the same, and most likely would be better since you would have more
control of the code that’s running alongside Signal for Desktop.
Cheers,
Greg
Your answer makes it sound like there were no way (apart maybe from
Java) to create a secure cross-platform binary. This is simply wrong.
With eg. Go it's pretty simple to cross-compile for all OSes. Go also
has many other features a security-focused tool like Signal could
benefit from. For example whole classes of memory management related
bugs simply don't exist.
Even ignoring both Chrome overreporting in the desktop use case due to
Android 4.4 and upwards using it as the default browser and Firefox
underreporting due to DOM-caching, Chrome has only around 50% of global
market share. This means the possible userbase for "Signal Browser"
isn't even every second desktop user. Advanced users also generally
favor Firefox over Chrome due to it's abundance of Addons.
In the long run the libaxolotl library for instant messenger programs
will improve this situation.
Can someone with more knowledge on the internal workings of Chrome apps
vs addons report on the possibility of an easy port over to Firefox,
once the addon API has officially changed to be compatible to Chrome?
Kind regards
curve25519
Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.
It is magnitudes of effort easier to create and maintain one
cross-platform chrome app than to create three separate projects for
linux, osx, and windows. I believe that the core devs realize that many
people would prefer a standalone app, but have chosen to focus their
efforts on making one well-designed chrome app and bringing it to market
instead of taking extra time to write separate native apps. It's the
same reason that they haven't created a windows phone app and don't
support encrypted SMS: there are more important things for them to be
working on right now.
Josh
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many
use the standalone Signal for mobile app, and only one person said
they even tried the browser extension. Also, most of my family does
not use Chrome but either Firefox or Safari.
Cheers,
Greg

[Alice Pote]

I'll try it on Debian when I get home! Awesome that its that easy.

Post by Ismail Khoffi
I agree that a standalone app would be great. But I also think
whispersystem did a great job so far and choosing a (first) simple
multiplatform solution approach (chrome app) was a good, efficient
choice. Anyways, I am also very curious now and I also have a lot of
friends who do not use chrome (spoiler: it works without *any*

Post by Alice Pote
I tried this with the signal chrome extension and got a certificate

related

Post by Alice Pote
error - but I imagine someone more familiar with the codebase would have

a

Post by Alice Pote
fairly easy time of it.

I'm quite sure that this (the certificate err) should only happen if
you cloned the code and did not do anything else. For instance, this
will not happen if you download the app (or ask someone for a copy if
you refuse to use chrome) and use nw.js and the app dir (chrome stores
https://productforums.google.com/d/msg/chrome/6EVtjeaWObs/4MsUmcCnFsUJ).
$ cp -r ~/Library/Application\ Support/Google/Chrome\
Canary/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.1.6_0 ~/
# one line, not two ...
$ nw ~/0.1.6_0 # voilà, you should see the startpage :-) no coding
required, only commandline
Tested with the latest beta of nw.js on mac os. In whispersytems'
defense: I'm sure when whispersystems started on the desktop app it
wasn't already so advanced that you can simply run (all?) chrome
apps...
From source version (5 instead of 2 commands, still no coding neccessary ;-)
# This assumes you have node/npm and nw.js properly installed ...
$ git clone https://github.com/WhisperSystems/Signal-Desktop.git
$ cd Signal-Desktop
$ npm install
$ grunt
$ nw ./dist
As I mentioned before, the certificate error might have occurred
because you just cloned the repo and tried to run it with nw.js. The
$ openssl s_client -connect
textsecure-service-staging.whispersystems.org:443 -showcerts
The grunt command replaces the staging server with the real servers
https://github.com/WhisperSystems/Signal-Desktop/blob/592ddc673be29f165b5c89412fdff73866e8d545/Gruntfile.js#L129-L133
As I said, I was just very curious if it's really that easy (and with
easy I mean maximum one/two hours of changing few lines and doing some
research). It is even easier than that... You do not need chrome and
you can easily 'compile' the app yourself (no registration for the
beta needed).
I would be curious if this works also on linux/windows (anyone?).
Cheers,
Ismail
On Tue, Jan 5, 2016 at 5:39 AM, Alice Pote

Post by Alice Pote
nw.js has first-class support for chrome apps, so many chrome apps can be
run as native applications using nw.js with zero modification.
I tried this with the signal chrome extension and got a certificate

related

Post by Alice Pote
error - but I imagine someone more familiar with the codebase would have

a

Post by Alice Pote
fairly easy time of it.

Post by Greg
It has been pointed out in other threads on this mailing list (and
elsewhere) that it would be fairly trivial to package the existing code
http://electron.atom.io/
http://nwjs.io/
The security properties of doing so, as far as I can tell, would be at
least the same, and most likely would be better since you would have

more

Post by Alice Pote

Post by Greg
control of the code that’s running alongside Signal for Desktop.
Cheers,
Greg
Your answer makes it sound like there were no way (apart maybe from
Java) to create a secure cross-platform binary. This is simply wrong.
With eg. Go it's pretty simple to cross-compile for all OSes. Go also
has many other features a security-focused tool like Signal could
benefit from. For example whole classes of memory management related
bugs simply don't exist.
Even ignoring both Chrome overreporting in the desktop use case due to
Android 4.4 and upwards using it as the default browser and Firefox
underreporting due to DOM-caching, Chrome has only around 50% of global
market share. This means the possible userbase for "Signal Browser"
isn't even every second desktop user. Advanced users also generally
favor Firefox over Chrome due to it's abundance of Addons.
In the long run the libaxolotl library for instant messenger programs
will improve this situation.
Can someone with more knowledge on the internal workings of Chrome apps
vs addons report on the possibility of an easy port over to Firefox,
once the addon API has officially changed to be compatible to Chrome?
Kind regards
curve25519
Keep in mind that the signal chrome app is still in beta, and I believe
that it takes some technical ability to get up and running. And chromium
has the most market share, so it makes sense to develop a chrome app
instead of a firefox extension.
It is magnitudes of effort easier to create and maintain one
cross-platform chrome app than to create three separate projects for
linux, osx, and windows. I believe that the core devs realize that many
people would prefer a standalone app, but have chosen to focus their
efforts on making one well-designed chrome app and bringing it to market
instead of taking extra time to write separate native apps. It's the
same reason that they haven't created a windows phone app and don't
support encrypted SMS: there are more important things for them to be
working on right now.
Josh
https://twitter.com/taoeffect/status/684064118974763008
13 for standalone.
2 for Chrome extension.
As some personal feedback, in my circle of friends and family many
use the standalone Signal for mobile app, and only one person said
they even tried the browser extension. Also, most of my family does
not use Chrome but either Firefox or Safari.
Cheers,
Greg

[Tyler]

I got this working on Arch GNU/Linux using the steps above.

It looked from the binary installation of nwjs that nwjs had binary
blobs that were required. Hmm.

If anybody has the time, I'd like to know if someone can put the app
under wireshark/tcpdump/whatever and see what network calls it makes -
specifically, does the chrome app phone home to big brother Google or
not? One of the very satisfying things about the websockets build is not
having to have gplay or GCM on my device...

Thanks to all who worked hard on this, and all worked easy on this.

Post by Alice Pote
I'll try it on Debian when I get home! Awesome that its that easy.

[Raphael Arias]

Thank you, Ismail, for summarizing this process!

Building and running from source works like a charm on Debian (jessie).
For completeness: sass is a dependency, too. So you'll need to
$ gem install sass
or
$ sudo gem install sass

Awesome work, everyone!

Tyler, I haven't had a chance to look at any network traffic yet. Not
sure if I will have time in the near future...

So long,
Raphael

Post by Tyler
I got this working on Arch GNU/Linux using the steps above.
It looked from the binary installation of nwjs that nwjs had binary
blobs that were required. Hmm.
If anybody has the time, I'd like to know if someone can put the app
under wireshark/tcpdump/whatever and see what network calls it makes -
specifically, does the chrome app phone home to big brother Google or
not? One of the very satisfying things about the websockets build is not
having to have gplay or GCM on my device...
Thanks to all who worked hard on this, and all worked easy on this.

Post by Alice Pote
I'll try it on Debian when I get home! Awesome that its that easy.

[Joshua Lund]

People seem to be completely forgetting about initial download integrity
and ongoing security updates, which are quite important for an
application like this. Chrome Packaged Apps make this seamless and easy
for users.

Until NW.js natively supports some kind of secure update process, it's
not really ready for this use case. If you find yourself thinking things
like "But Open Whisper Systems could come up with their own bespoke
distribution and update process!" then you should also quickly start to
realize that this is not a "fairly trivial" problem, especially for a
team of their size.

Asking Signal's target demographic to download a zip file, verify its
GPG signature or checksum, and manually keep their installation up to
date on a consistent basis? This is the same type of wishful thinking
that led to GPG's terrible user experience. The current approach is both
easier and more secure.

A sample size of fifteen entire people might sound really impressive,
but in order for mass surveillance to become a thing of the past we will
need millions. In my opinion, Signal has millions of users precisely
because the development team has made incredibly deliberate and smart
decisions that balance security with usability. In the meantime, simple
workarounds are available, and the Axolotl protocol will also continue
to spread into more esoteric packages that are "ideologically pure."
Some of them are even written in Go! :)

[Michael Hellwig]

People seem to be completely forgetting about initial download integrity and
ongoing security updates, which are quite important for an application like
this. Chrome Packaged Apps make this seamless and easy for users.

curious about that bit: When I look at the "extensions" menu in my
Chrome, I see Signal as version 0.1.5 is installed. I then click
"details" and "view in store" and there, the version offered is "0.1.6".
How _does_ one get the ongoing updates mentioned above? There is no
"update" button to be seen and the app doesn't seem to auto-update (as
evidenced by the fact that it didn't).

[Ismail Khoffi]

Post by Michael Hellwig
curious about that bit: When I look at the "extensions" menu in my
Chrome, I see Signal as version 0.1.5 is installed. I then click
"details" and "view in store" and there, the version offered is "0.1.6".
How _does_ one get the ongoing updates mentioned above? There is no
"update" button to be seen and the app doesn't seem to auto-update (as
evidenced by the fact that it didn't).

When you go to chrome://extensions/ you will find a checkbox on the
top-right labeld 'Developer-Mode'. Make sure it is checked and then
you'll find a button 'Update Extensions Now'. Very convenient and
automatic ;-)
See https://developer.chrome.com/extensions/autoupdate for details.

Happy updating,
Ismail

[c***@mailbox.org]

If Chrome/Chromium really don't update Signal by default I don't see how
this can be the official "update path" when most non-technical users
will probably never receive a single one. This seems unreasonable even
for a beta. Or is unskippable information about the procedure to
activate updates via developer mode part of becoming a beta user?

On another note, this gives the the criticism regarding F-Droid (nearly
all of which has been remediated by now) a bad aftertaste as it is still
a much better solution than not getting any updates at all.

Kind regards,

curve25519

Post by Ismail Khoffi

Post by Michael Hellwig
curious about that bit: When I look at the "extensions" menu in my
Chrome, I see Signal as version 0.1.5 is installed. I then click
"details" and "view in store" and there, the version offered is "0.1.6".
How _does_ one get the ongoing updates mentioned above? There is no
"update" button to be seen and the app doesn't seem to auto-update (as
evidenced by the fact that it didn't).

When you go to chrome://extensions/ you will find a checkbox on the
top-right labeld 'Developer-Mode'. Make sure it is checked and then
you'll find a button 'Update Extensions Now'. Very convenient and
automatic ;-)
See https://developer.chrome.com/extensions/autoupdate for details.
Happy updating,
Ismail

[#359]

Of course Chromium/Chrom updates apps by itself. When I got Signal
Desktop it was 0.1.1 (i think) and now it's 0.1.6.
--
- jure

Post by c***@mailbox.org
If Chrome/Chromium really don't update Signal by default I don't see how
this can be the official "update path" when most non-technical users
will probably never receive a single one. This seems unreasonable even
for a beta. Or is unskippable information about the procedure to
activate updates via developer mode part of becoming a beta user?
On another note, this gives the the criticism regarding F-Droid (nearly
all of which has been remediated by now) a bad aftertaste as it is still
a much better solution than not getting any updates at all.
Kind regards,
curve25519

Post by Ismail Khoffi

Post by Michael Hellwig
curious about that bit: When I look at the "extensions" menu in my
Chrome, I see Signal as version 0.1.5 is installed. I then click
"details" and "view in store" and there, the version offered is "0.1.6".
How _does_ one get the ongoing updates mentioned above? There is no
"update" button to be seen and the app doesn't seem to auto-update (as
evidenced by the fact that it didn't).

When you go to chrome://extensions/ you will find a checkbox on the
top-right labeld 'Developer-Mode'. Make sure it is checked and then
you'll find a button 'Update Extensions Now'. Very convenient and
automatic ;-)
See https://developer.chrome.com/extensions/autoupdate for details.
Happy updating,
Ismail

[Alexander Dietrich]

It looks like you need to be logged in with your Google account for the
autoupdate to work.

Best regards,
Alexander
---
PGP Key: https://dietrich.cx/pgp | 0x727A756DC55A356B

Post by #359
Of course Chromium/Chrom updates apps by itself. When I got Signal
Desktop it was 0.1.1 (i think) and now it's 0.1.6.
--
- jure

Post by c***@mailbox.org
If Chrome/Chromium really don't update Signal by default I don't see how
this can be the official "update path" when most non-technical users
will probably never receive a single one. This seems unreasonable even
for a beta. Or is unskippable information about the procedure to
activate updates via developer mode part of becoming a beta user?
On another note, this gives the the criticism regarding F-Droid (nearly
all of which has been remediated by now) a bad aftertaste as it is still
a much better solution than not getting any updates at all.
Kind regards,
curve25519

Post by Ismail Khoffi

Post by Michael Hellwig
curious about that bit: When I look at the "extensions" menu in my
Chrome, I see Signal as version 0.1.5 is installed. I then click
"details" and "view in store" and there, the version offered is "0.1.6".
How _does_ one get the ongoing updates mentioned above? There is no
"update" button to be seen and the app doesn't seem to auto-update (as
evidenced by the fact that it didn't).

When you go to chrome://extensions/ you will find a checkbox on the
top-right labeld 'Developer-Mode'. Make sure it is checked and then
you'll find a button 'Update Extensions Now'. Very convenient and
automatic ;-)
See https://developer.chrome.com/extensions/autoupdate for details.
Happy updating,
Ismail

[c***@mailbox.org]

Hi Josh,

nice to hear someone from the official OWS team chime in!

Post by Joshua Lund
People seem to be completely forgetting about initial download integrity
and ongoing security updates, which are quite important for an
application like this. Chrome Packaged Apps make this seamless and easy
for users.
Until NW.js natively supports some kind of secure update process, it's
not really ready for this use case. If you find yourself thinking things
like "But Open Whisper Systems could come up with their own bespoke
distribution and update process!" then you should also quickly start to
realize that this is not a "fairly trivial" problem, especially for a
team of their size.

According to Moxie, this has been ready to go (at least for the Android
version) for close to two years now:

https://github.com/WhisperSystems/Signal-Android/issues/127#issuecomment-36066056

Yet nothing has been released, with Moxie actually saying at some point
that an official Gapps-free version might never happen because of some
changes in Android 6.

Post by Joshua Lund
Asking Signal's target demographic to download a zip file, verify its
GPG signature or checksum, and manually keep their installation up to
date on a consistent basis? This is the same type of wishful thinking
that led to GPG's terrible user experience. The current approach is both
easier and more secure.

At this point people can go full dev and compile their own/JavaJens
modified version from scratch, getting the source code unsigned and only
TLS-protected from Github. The amount of people beeing able to AND
willing to do this for every update is negligible. The security
properties are also not great, because x509 is broken beyond comparison.
Also JavaJens seems to be a great guy and contributer, but any
additional party in the distribution process greatly increases the
possibility of introduced weaknesses.

Or your just download the GCM-free version on F-Droid by xmikos with
similar problems.

Could you elaborate why OWS prefers to ignore those problems instead of
rolling out the apparently finished distribution and update mechanism in
a "websocket only" build and plastering the app and distribution point
with "BATTERY HUG WITH DELAYED MESSAGES, PLEASE USE GCM VERSION FROM
PLAY STORE"?

Apparently it wouldn't be much additional work AND it siginficantly
reduces the attack surface of those currently using third party builds.

Average users with GCM will likely never end up at this distribution
point and if they do, they can be easily convinced with clear wording to
use the channel intended for them.

Post by Joshua Lund
A sample size of fifteen entire people might sound really impressive,
but in order for mass surveillance to become a thing of the past we will
need millions. In my opinion, Signal has millions of users precisely
because the development team has made incredibly deliberate and smart
decisions that balance security with usability. In the meantime, simple
workarounds are available, and the Axolotl protocol will also continue
to spread into more esoteric packages that are "ideologically pure."
Some of them are even written in Go! :)

The current approach works only for the newbies it's intended to. It
doesn't work for the important demographic of either very advanced and
busy users or kinda advanced but sophomoric users. Those are generally
the ones advocating for their non-technical friends to use tools like
Signal in the first place. And they would of course also like to be able
to interact with their friends on their own terms (FOSS all the way). If
Signal continues to deny them a way to do so, they'll either continue
using less secure distribution and update mechanisms or less secure
alternative apps, driving their friends away from Signal or not
introducing them to it at all.

I guess what I'm asking for is: do you have any knowledge if it is still
planned to implement the "ready to go" distribution and update mechanism
at some point?

An official roadmap would probably alleviate many such requests.

Kind regards,

curve25519

[Joshua Lund]

I want to make sure that this is very clear: Although I am huge
supporter of their mission and have done a lot of volunteer work for
Open Whisper Systems in the past, I am not an employee, nor am I
speaking on their behalf. My opinions are mine alone.

OK, phew.

An Android-specific update/distribution platform (that appears to no
longer be technically viable) is quite different from a Desktop solution
that works on Linux, OS X, and Windows. As people have already pointed
out, even though the desktop version is still in beta, users are quickly
(and automatically) receiving updates across all platforms.

I live in a world where every single conversation that I have with my
friends and family is end-to-end encrypted. That's a reality for me
today. This world exists because people have finally started to realize
that the mid-90's strategy of catering exclusively to paranoid power
users wasn't accomplishing anything. I would rather see development
efforts continue to be directed towards the masses who are affected by
mass surveillance, especially when the ideologically pure workarounds
are so easy.

[c***@mailbox.org]

Hi Josh,

Post by Joshua Lund
I want to make sure that this is very clear: Although I am huge
supporter of their mission and have done a lot of volunteer work for
Open Whisper Systems in the past, I am not an employee, nor am I
speaking on their behalf. My opinions are mine alone.

Yeah I understand. The thing is: your private opinion is currently the
closest thing to an official answer from OWS one can get. I tried to
meet up with Jake at 32C3 and failed. People asking about updates on
these core problems and future plans are generally ignored on this
"official" mailing list.

Post by Joshua Lund
An Android-specific update/distribution platform (that appears to no
longer be technically viable) is quite different from a Desktop solution
that works on Linux, OS X, and Windows.

I never meant to imply that it is the same or can be used on other
platforms without modification. Can you go into more detail as to why
the old solution isn't viable with current Android versions anymore?

Post by Joshua Lund
As people have already pointed
out, even though the desktop version is still in beta, users are quickly
(and automatically) receiving updates across all platforms.

Thanks for confirming that.

Post by Joshua Lund
I live in a world where every single conversation that I have with my
friends and family is end-to-end encrypted. That's a reality for me
today. This world exists because people have finally started to realize
that the mid-90's strategy of catering exclusively to paranoid power
users wasn't accomplishing anything. I would rather see development
efforts continue to be directed towards the masses who are affected by
mass surveillance, especially when the ideologically pure workarounds
are so easy.

While it's obviously true that focusing on power users, of which at
least half are not as advanced as they think they are, is stupid and
wrong, that's absolutely not what I wrote or asked for.

What I'm trying to say is that OWS currently explicitly excludes them,
ignoring the fact that those are a strong multiplier to reach more
average users through support, recommendations and PRs.

The issues causing this are really really old and haven't been updated
in an eternity. It's extremely difficult to even find out that the old
plan to solve this has apparently been abandoned. This together with the
in other regards similarly lacking communication with the greater
community drives many long-term contributors as well as potential
contributors away from the project.

If older plans to implement a certain feature are beeing abandoned
people don't have to waste their time hoping/waiting for it. But this
isn't communicated. Without something like a rough draft in which order
features are planned, there is no way to tell if Signal will ever meet
ones requirements. ATM OWS are simply wasting everybodys time and have
done so for over a year. And I'm sure they themselves are sick and tired
to answer the same questions again and again after someone has been able
to get a hold of them.

Sorry about the sour tone, I mean to be constructive and support the
whole Signal project. I'm simply a bit frustrated that there hasn't been
even a single update in over a year and there is nothing apart from "I
have no idea what they plan for the future" I can tell the ~60 people
regularly asking me about this and other issues.

[Tim Kuijsten]

Post by c***@mailbox.org
people don't have to waste their time hoping/waiting for it.

Isn't more time wasted by people asking others to write their favorite
feature?

I would say that if you ask something from the devs of an open source
project, make sure you attach a patch or are at least willing to do the
bulk of the work yourself. Otherwise, don't waste *their* time.

(not specifically at curve25519, but at the general user vs. dev
mentality in open source projects)

[Samat K Jain]

Post by c***@mailbox.org

Post by Joshua Lund
An Android-specific update/distribution platform (that appears to no
longer be technically viable) is quite different from a Desktop solution
that works on Linux, OS X, and Windows.

I never meant to imply that it is the same or can be used on other
platforms without modification. Can you go into more detail as to why
the old solution isn't viable with current Android versions anymore?

On Android 6.0, the "Doze" power saving feature means apps can only wake
the phone up when they receive a GCM message.

If you had Doze enabled, and your phone's screen is off (i.e. in your
pocket), you won't get notifications about new messages. You'd get them
next time you pulled the phone out of our pocket and turned the screen
on. That's pretty horrible UX.

[Patrick Connolly]

fwiw, `lib-supplychain` (the alt distribution library) was apparently more
of a priority for Flock, OWS's encrypted webDAV-based contact and calendar
sync app. Non-Play distribution was apparently seen as more of a priority
for the sorts of users who wanted to avoid syncing data to Google. It also
probably helped that GCM push messaging isn't needed for contact/calendar
syncing. (You can find the library packaged in the old Flock APKs, if
you're curious and want to poke around -- there weren't yet any public
repos that I could find.)

Flock was discontinued, as building on the cruft of webDAV was seen as a
dead-end by its maintainer. There are some issues in their tracker about
possible alternative protocols.

If someone were interested in moving things forward for non-Google support
in general, it might be worth reviving the Flock efforts. The Flock
encryption scheme is vetted by them and pretty well documented. Presumably,
private contact sync is still important to folks at OWS. Just my 2 cents.

And +1 Tim

- patcon

EDIT: Just realized that all the public Flock APKs are gone, so I pushed a
local copy of libsupplychain that I had lying around:
https://github.com/patcon/libsupplychain


--------------------------------------------
Q: Why is this email [hopefully] five sentences or less? | A:
http://five.sentenc.es

*NOTE* that my emails are delayed from arriving in my inbox until 5pm daily
(Pacific Time). If urgent, please use another way of getting in touch.
#slowwebmovement <http://www.musubimail.com/gmail_timer.html>

Post by Samat K Jain

Post by c***@mailbox.org

Post by Joshua Lund
An Android-specific update/distribution platform (that appears to no

Post by Joshua Lund
longer be technically viable) is quite different from a Desktop solution
that works on Linux, OS X, and Windows.

I never meant to imply that it is the same or can be used on other
platforms without modification. Can you go into more detail as to why
the old solution isn't viable with current Android versions anymore?

On Android 6.0, the "Doze" power saving feature means apps can only wake
the phone up when they receive a GCM message.
If you had Doze enabled, and your phone's screen is off (i.e. in your
pocket), you won't get notifications about new messages. You'd get them
next time you pulled the phone out of our pocket and turned the screen on.
That's pretty horrible UX.
--
Samat K Jain • GPG: 0x4A456FBA • Pump.IO: https://identi.ca/samatjain
Web: https://samat.org/ • Twitter: https://twitter.com/SamatJain
This e-mail is: [ ] shareable [x] ask first [ ] private

[Steffen Märcker]

An intermediate step might be to build extensions for other browsers as
well and deploy them via the trusted stores. E.g., Vivaldi and Opera are
able to run most of the Chrome extensions unmodified. Firefox will likely
require more work.

Best, Steffen

Post by Ismail Khoffi
I agree that a standalone app would be great. But I also think
whispersystem did a great job so far and choosing a (first) simple
multiplatform solution approach (chrome app) was a good, efficient
choice. Anyways, I am also very curious now and I also have a lot of
friends who do not use chrome (spoiler: it works without *any*

Post by Alice Pote
I tried this with the signal chrome extension and got a certificate related
error - but I imagine someone more familiar with the codebase would have a
fairly easy time of it.

I'm quite sure that this (the certificate err) should only happen if
you cloned the code and did not do anything else. For instance, this
will not happen if you download the app (or ask someone for a copy if
you refuse to use chrome) and use nw.js and the app dir (chrome stores
https://productforums.google.com/d/msg/chrome/6EVtjeaWObs/4MsUmcCnFsUJ).
$ cp -r ~/Library/Application\ Support/Google/Chrome\
Canary/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.1.6_0 ~/
# one line, not two ...
$ nw ~/0.1.6_0 # voilà, you should see the startpage :-) no coding
required, only commandline
Tested with the latest beta of nw.js on mac os. In whispersytems'
defense: I'm sure when whispersystems started on the desktop app it
wasn't already so advanced that you can simply run (all?) chrome
apps...
From source version (5 instead of 2 commands, still no coding neccessary ;-)
# This assumes you have node/npm and nw.js properly installed ...
$ git clone https://github.com/WhisperSystems/Signal-Desktop.git
$ cd Signal-Desktop
$ npm install
$ grunt
$ nw ./dist
As I mentioned before, the certificate error might have occurred
because you just cloned the repo and tried to run it with nw.js. The
$ openssl s_client -connect
textsecure-service-staging.whispersystems.org:443 -showcerts
The grunt command replaces the staging server with the real servers
https://github.com/WhisperSystems/Signal-Desktop/blob/592ddc673be29f165b5c89412fdff73866e8d545/Gruntfile.js#L129-L133
As I said, I was just very curious if it's really that easy (and with
easy I mean maximum one/two hours of changing few lines and doing some
research). It is even easier than that... You do not need chrome and
you can easily 'compile' the app yourself (no registration for the
beta needed).
I would be curious if this works also on linux/windows (anyone?).
Cheers,
Ismail
On Tue, Jan 5, 2016 at 5:39 AM, Alice Pote

Post by Alice Pote
nw.js has first-class support for chrome apps, so many chrome apps can be
run as native applications using nw.js with zero modification.
I tried this with the signal chrome extension and got a certificate related
error - but I imagine someone more familiar with the codebase would have a
fairly easy time of it.

<---Schnitt--->