[whispersystems] what will happen to Signal Desktop?

[Alexander Kayumov]

What will happen to Signal Desktop now that Google is retiring Chrome apps???

[h***@tutamail.com]

maybe it is possible to use Firefox?or something else?

.-.-.-.-.-.-.-.-.-.-.-.-.-.-
IkFyZ3VpbmcgdGhhdCB5b3UgZG9uJ3QgY2FyZSBhYm91dCB0aGUgcmlnaHQgdG8gcHJpdmFjeSBiZWNhdXNlIHlvdSBoYXZlIG5vdGhpbmcgdG8gaGlkZSBpcyBubyBkaWZmZXJlbnQgdGhhbiBzYXlpbmcgeW91IGRvbid0IGNhcmUgYWJvdXQgZnJlZSBzcGVlY2ggYmVjYXVzZSB5b3UgaGF2ZSBub3RoaW5nIHRvIHNheSI=

Post by Alexander Kayumov
What will happen to Signal Desktop now that Google is retiring Chrome apps???

[Johan Wevers]

Post by Alexander Kayumov
What will happen to Signal Desktop now that Google is retiring Chrome apps???

AFAIK it will cease to work in 2018.

Building something on a non-mainstream Google product is always
dangerous, they have a history of dropping products.

Time to build a decent desktop program than. With a good design much
non-GUI code can be shared between Linux, Windows and OSX. If it will be
written in Java and C++ maybe a lot of the Android code could be reused.

[Emiliano Heyns]

Or if it is ported to Electron, much of the javascript code of the chrome
app can be re-used? Plus it wouldn't require people to install Java.

Post by Alexander Kayumov

Post by Alexander Kayumov
What will happen to Signal Desktop now that Google is retiring Chrome

apps???
AFAIK it will cease to work in 2018.
Building something on a non-mainstream Google product is always
dangerous, they have a history of dropping products.
Time to build a decent desktop program than. With a good design much
non-GUI code can be shared between Linux, Windows and OSX. If it will be
written in Java and C++ maybe a lot of the Android code could be reused.
--
Met vriendelijke groet,
Johan Wevers

[Michel Le Bihan]

[Johan Wevers]

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.

[Emiliano Heyns]

Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Sam Lanning]

Exactly,

Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.

Take the atom text editor, and the brave web browser for example.

What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.

That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.

Sam.

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Luka Perčič]

Not really, you can always tell the difference between electron and native
apps. Also libraries. World needs more c++ libraries.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free
to experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Alice Pote]

It's possible to run the signal desktop chrome application in nw.js
(project similar to electron) with very minimal modification. I think
electron doesn't have built in chrome app support (as nw.js does) so
probably slightly more modification would be needed there, but it would
probably take a developer familiar with the codebase just a couple days to
do so. Security auditing might take longer.

If there's an existing clean JavaScript codebase it wouldn't make much
sense to me to just scrap it in order to rewrite the whole app in native
GUI toolkits.

Post by Luka Perčič
Not really, you can always tell the difference between electron and native
apps. Also libraries. World needs more c++ libraries.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free
to experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

["Ahmad Youssef" (via whispersystems Mailing List)]

Post by Johan Wevers
AFAIK it will cease to work in 2018.

Any news on this ? I was just about to abandon other messaging protocols
and stick with Signal.

[Joel Whitehouse]

Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps platform
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.

Consider what happens after you discover a bug that affects the privacy
of 50 million users. How do you get it to them? Distributing an update
is a non-trivial problem that is fraught with its own security concerns.
OWS chose the Chrome Apps framework because it addresses those concerns
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's Google.
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user *thinks*
they're protected by Signal, they actually are.

There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and if
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other
programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different
programming
language, perhaps as suggested using Java.
Sam.
On 20 Aug 2016 9:53 a.m., "Emiliano Heyns"

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Sam Lanning]

+1 Well said!

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;

several folks on the mailing list are hopeful that this is an opportunity
for it to be ported to their favorite language, even as a native app. But
before suggesting a language or framework to replace js/Chrome Apps, let's
consider why OWS selected the Chrome Apps platform in the first place. Did
they just prefer javascript over c++? Actually, the language has little to
do with it.

Post by Joel Whitehouse
Consider what happens after you discover a bug that affects the privacy

of 50 million users. How do you get it to them? Distributing an update is
a non-trivial problem that is fraught with its own security concerns. OWS
chose the Chrome Apps framework because it addresses those concerns and
more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google. Who
defends servers against DDoS attacks, updates the software that pushes
updates, including the PKI authentication so that the update delivery
protocol itself isn't hijacked to harm users? That's Google. Who protects
Signal's brand against app store typo squatting? Google again. Together,
all of these measures ensure that when a user *thinks* they're protected by
Signal, they actually are.

Post by Joel Whitehouse
There would be no signal-desktop without Chrome Apps, so casually

suggesting that OWS should port it to c++, java, or

Post by Joel Whitehouse
"electron" isn't much help. With the sunset of Chrome Apps,

signal-desktop is in need of a new secure distribution channel, and if that
channel prefers javascript, c# or even perl, so be it. But any discussion
that neglects the distribution problem is unhelpful.

Post by Joel Whitehouse

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.
On 20 Aug 2016 9:53 a.m., "Emiliano Heyns" <

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Alexander Kayumov]

This is partially so. But!

(First of all, 50 million users for Signal seems like a gross exaggeration!.. Unfortunately.)

Second, desktop security is different in character from mobile security. Your logic fully applies to and works for mobile security. I've read Moxie defend the developers' decision not to distribute Signal via platforms other than Google Play Store for Android, for example. And I do indeed agree with all the arguments that he made and that you have rehashed.

However, in my opinion, porting all these arguments over to the desktop side is a bit ridiculous. It's simply not how desktop security works. NO DESKTOP APP does this, other than Signal Desktop. ALL other desktop security apps use other models, which somehow seem to more or less work. Tor, Tails, TrueCrypt and other FDE software, password managers, and so on and so forth - all use other, "traditional" desktop distributions models.

You host your distribution on a secure server, you notify users of updates, you let them check hashes and digital signatures, etc.

A.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps platform
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the privacy
of 50 million users. How do you get it to them? Distributing an update
is a non-trivial problem that is fraught with its own security concerns.
OWS chose the Chrome Apps framework because it addresses those concerns
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's Google.
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user *thinks*
they're protected by Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and if
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

[Stephen Michel]

From what I've seen Moxie write elsewhere, I think his response to this would be along the lines of, "Yes, and the mobile security model is much better; we should be trying to make desktop security more like it, not regressing to the old paradigms."

Obvious but necessary disclaimer: I'm not speaking for him; this is just my (potentially flawed) understanding of his view.

Post by Alexander Kayumov
This is partially so. But!
(First of all, 50 million users for Signal seems like a gross
exaggeration!.. Unfortunately.)
Second, desktop security is different in character from mobile
security. Your logic fully applies to and works for mobile security.
I've read Moxie defend the developers' decision not to distribute
Signal via platforms other than Google Play Store for Android, for
example. And I do indeed agree with all the arguments that he made and
that you have rehashed.
However, in my opinion, porting all these arguments over to the desktop
side is a bit ridiculous. It's simply not how desktop security works.
NO DESKTOP APP does this, other than Signal Desktop. ALL other desktop
security apps use other models, which somehow seem to more or less
work. Tor, Tails, TrueCrypt and other FDE software, password managers,
and so on and so forth - all use other, "traditional" desktop
distributions models.
You host your distribution on a secure server, you notify users of
updates, you let them check hashes and digital signatures, etc.
A.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps

platform

Post by Joel Whitehouse
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the

privacy

Post by Joel Whitehouse
of 50 million users. How do you get it to them? Distributing an

update

Post by Joel Whitehouse
is a non-trivial problem that is fraught with its own security

concerns.

Post by Joel Whitehouse
OWS chose the Chrome Apps framework because it addresses those

concerns

Post by Joel Whitehouse
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's

Google.

Post by Joel Whitehouse
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user

*thinks*

Post by Joel Whitehouse
they're protected by Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and

if

Post by Joel Whitehouse
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

[Johan Wevers]

Post by Stephen Michel
From what I've seen Moxie write elsewhere, I think his response to this
would be along the lines of, "Yes, and the mobile security model is much
better; we should be trying to make desktop security more like it, not
regressing to the old paradigms."

That's what MS is doing now with its forced patches: "up"grade to
windows 10 and only put it in the windows store. And lose most of your
users in the process.

The official Android client already expires, this is doing it twice.

P.s.: I am on the mailing list, no need to CC me too.

[Luka Perčič]

" And lose most of your users in the process."

Not really, people like to complain, but at the end, they don't switch
(they just wait until malware gets piled up on their machines).

Each platform is rolling out their own "app model". UWP for windows .appx
(pc, xbox, phone, holo...), snappy for linux .snap , .pkg for osx...

You get better sandboxing and autoupdates through system "app store". And
yes, whisper systems gets to update your apps with their golden keys
(keeping you generally safer but also exposed if the key gets stolen at the
same time).

Anyhow, this is still a better way to sandbox and distribute your apps, if
you want your users to actually "set and forget".

Post by Johan Wevers

Post by Stephen Michel
From what I've seen Moxie write elsewhere, I think his response to this
would be along the lines of, "Yes, and the mobile security model is much
better; we should be trying to make desktop security more like it, not
regressing to the old paradigms."

That's what MS is doing now with its forced patches: "up"grade to
windows 10 and only put it in the windows store. And lose most of your
users in the process.
The official Android client already expires, this is doing it twice.
P.s.: I am on the mailing list, no need to CC me too.
--
Met vriendelijke groet,
Johan Wevers

[Johan Wevers]

Post by Luka Perčič
Not really, people like to complain, but at the end, they don't switch
(they just wait until malware gets piled up on their machines).

The difference is that Signal is open source. When they dropped sms
encryption it was forked, and if current developmend speed stays as low
as it has been the past 4 months (i.e. effectively 0) forks will arise
with more than a small number of users.

I build Signal myself because the refusal to bring back encrypted
backups and voice memos on Android. Upgrading to a self-built version
without loosing ones data requires root and a patch to disable signature
verification in the Android updater (or manually copying all data over)
but the later can be deactivated again when the update is done.

Post by Luka Perčič
Each platform is rolling out their own "app model". UWP for windows
.appx (pc, xbox, phone, holo...), snappy for linux .snap , .pkg for osx...

Most unfortunately. Security at the cost of freedom is not my preferred
model. It's what our entire society seems to be doing: more security
theater at the cost of freedom. :-(

Post by Luka Perčič
Anyhow, this is still a better way to sandbox and distribute your apps,
if you want your users to actually "set and forget".

Post by Stephen Michel
From what I've seen Moxie write elsewhere, I think his response to this
would be along the lines of, "Yes, and the mobile security model is

much

Post by Stephen Michel
better; we should be trying to make desktop security more like it, not
regressing to the old paradigms."

That's what MS is doing now with its forced patches: "up"grade to
windows 10 and only put it in the windows store. And lose most of your
users in the process.
The official Android client already expires, this is doing it twice.
P.s.: I am on the mailing list, no need to CC me too.
--
Met vriendelijke groet,
Johan Wevers

[Stephen Michel]

From what I've seen Moxie write elsewhere, I think his response to this would be along the lines of, "Yes, and the mobile security model is much better; we should be trying to make desktop security more like it, not regressing to the old paradigms."

Obvious but necessary disclaimer: I'm not speaking for him; this is just my (potentially flawed) understanding of his view.

Post by Alexander Kayumov
This is partially so. But!
(First of all, 50 million users for Signal seems like a gross
exaggeration!.. Unfortunately.)
Second, desktop security is different in character from mobile
security. Your logic fully applies to and works for mobile security.
I've read Moxie defend the developers' decision not to distribute
Signal via platforms other than Google Play Store for Android, for
example. And I do indeed agree with all the arguments that he made and
that you have rehashed.
However, in my opinion, porting all these arguments over to the desktop
side is a bit ridiculous. It's simply not how desktop security works.
NO DESKTOP APP does this, other than Signal Desktop. ALL other desktop
security apps use other models, which somehow seem to more or less
work. Tor, Tails, TrueCrypt and other FDE software, password managers,
and so on and so forth - all use other, "traditional" desktop
distributions models.
You host your distribution on a secure server, you notify users of
updates, you let them check hashes and digital signatures, etc.
A.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps

platform

Post by Joel Whitehouse
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the

privacy

Post by Joel Whitehouse
of 50 million users. How do you get it to them? Distributing an

update

Post by Joel Whitehouse
is a non-trivial problem that is fraught with its own security

concerns.

Post by Joel Whitehouse
OWS chose the Chrome Apps framework because it addresses those

concerns

Post by Joel Whitehouse
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's

Google.

Post by Joel Whitehouse
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user

*thinks*

Post by Joel Whitehouse
they're protected by Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and

if

Post by Joel Whitehouse
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

[Jeff R]

Think about how desktop is moving towards the same distribution model
though. Windows has an app store, as does Mac OS X. Deploying something
inside an app store model is an option, even outside of browser app stores
(like what Chrome has). So it's worth considering.

The paranoid and/or experts can always manually compile, hash check, etc.

Is Signal Desktop in use on more than traditional computers? I don't know
of any other environments that allow Chrome plug-ins, although Chrome is
obviously used on more than desktop devices.

Post by Alexander Kayumov
This is partially so. But!
(First of all, 50 million users for Signal seems like a gross
exaggeration!.. Unfortunately.)
Second, desktop security is different in character from mobile security.
Your logic fully applies to and works for mobile security. I've read Moxie
defend the developers' decision not to distribute Signal via platforms
other than Google Play Store for Android, for example. And I do indeed
agree with all the arguments that he made and that you have rehashed.
However, in my opinion, porting all these arguments over to the desktop
side is a bit ridiculous. It's simply not how desktop security works. NO
DESKTOP APP does this, other than Signal Desktop. ALL other desktop
security apps use other models, which somehow seem to more or less work.
Tor, Tails, TrueCrypt and other FDE software, password managers, and so on
and so forth - all use other, "traditional" desktop distributions models.
You host your distribution on a secure server, you notify users of
updates, you let them check hashes and digital signatures, etc.
A.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps platform
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the privacy
of 50 million users. How do you get it to them? Distributing an update
is a non-trivial problem that is fraught with its own security concerns.
OWS chose the Chrome Apps framework because it addresses those concerns
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's Google.
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user *thinks*
they're protected by Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and if
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

[Johan Wevers]

Post by Jeff R
Think about how desktop is moving towards the same distribution model
though. Windows has an app store,

Only windows 10, which is a minority of the windows installations.

[Alexander Kayumov]

<html><head><title>Re[2]: [whispersystems] what will happen to Signal Desktop?</title>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 10pt;">Well, maybe Windows really is moving in that direction, but the day Windows forces users to use its app store (which is bound to be a parody of Apple and Android app stores, as always) will be the day I switch to another OS. I am currently running Windows 7 and have not yet used Windows app store ONCE in my entire life.<br>
<br>
I don't think one has to be paranoid and/or an expert to install software on Windows: just download it from a trustworthy source (e.g. SourceForge, FossHub, etc.) that uses https and check the installer's digital signature before clicking "ok" in the dialogue.<br>
<br>
A.<br>
<br>
<br>
You wrote on Sunday, August 21, 2016 at 6:13:47 PM:<br>
<br>
</span><table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td width=1151><span style=" font-family:'courier new'; font-size: 10pt;">Think about how desktop is moving towards the same distribution model though. Windows has an app store, as does Mac OS X. Deploying something inside an app store model is an option, even outside of browser app stores (like what Chrome has). So it's worth considering.<br>
The paranoid and/or experts can always manually compile, hash check, etc.<br>
Is Signal Desktop in use on more than traditional computers? I don't know of any other environments that allow Chrome plug-ins, although Chrome is obviously used on more than desktop devices.<br>
<br>
On Aug 21, 2016 02:20, "Alexander Kayumov" &lt;</span><a style=" font-family:'courier new'; font-size: 10pt;" href="mailto:alexander-***@yandex.ru">alexander-***@yandex.ru</a><span style=" font-family:'courier new'; font-size: 10pt;">&gt; wrote:<br>
This is partially so. But!<br>
<br>
(First of all, 50 million users for Signal seems like a gross exaggeration!.. Unfortunately.)<br>
<br>
Second, desktop security is different in character from mobile security. Your logic fully applies to and works for mobile security. I've read Moxie defend the developers' decision not to distribute Signal via platforms other than Google Play Store for Android, for example. And I do indeed agree with all the arguments that he made and that you have rehashed.<br>
<br>
However, in my opinion, porting all these arguments over to the desktop side is a bit ridiculous. It's simply not how desktop security works. NO DESKTOP APP does this, other than Signal Desktop. ALL other desktop security apps use other models, which somehow seem to more or less work. Tor, Tails, TrueCrypt and other FDE software, password managers, and so on and so forth - all use other, "traditional" desktop distributions models.<br>
<br>
You host your distribution on a secure server, you notify users of updates, you let them check hashes and digital signatures, etc.<br>
<br>
A.<br>
<br>
<br>
You wrote on Sunday, August 21, 2016 at 3:40:59 AM:<br>
<br>
&gt; Chrome Apps, home of signal-desktop, will being shut down next year;<br>
&gt; several folks on the mailing list are hopeful that this is an<br>
&gt; opportunity for it to be ported to their favorite language, even as a<br>
&gt; native app. &nbsp;But before suggesting a language or framework to replace<br>
&gt; js/Chrome Apps, let's consider why OWS selected the Chrome Apps platform<br>
&gt; in the first place. &nbsp;Did they just prefer javascript over c++?<br>
&gt; Actually, the language has little to do with it.<br>
<br>
&gt; Consider what happens after you discover a bug that affects the privacy<br>
&gt; of 50 million users. &nbsp;How do you get it to them? &nbsp;Distributing an update<br>
&gt; is a non-trivial problem that is fraught with its own security concerns.<br>
&gt; &nbsp; OWS chose the Chrome Apps framework because it addresses those concerns<br>
&gt; and more importantly, it externalizes all the effort that goes into<br>
&gt; maintenance. &nbsp;Who maintains the CDN servers to host the app? &nbsp;Google.<br>
&gt; Who defends servers against DDoS attacks, updates the software that<br>
&gt; pushes updates, including the PKI authentication so that the update<br>
&gt; delivery protocol itself isn't hijacked to harm users? &nbsp;That's Google.<br>
&gt; Who protects Signal's brand against app store typo squatting? &nbsp;Google<br>
&gt; again. &nbsp;Together, all of these measures ensure that when a user *thinks*<br>
&gt; they're protected by Signal, they actually are.<br>
<br>
&gt; There would be no signal-desktop without Chrome Apps, so casually<br>
&gt; suggesting that OWS should port it to c++, java, or<br>
&gt; "electron" isn't much help. &nbsp;With the sunset of Chrome Apps,<br>
&gt; signal-desktop is in need of a new secure distribution channel, and if<br>
&gt; that channel prefers javascript, c# or even perl, so be it. &nbsp;But any<br>
&gt; discussion that neglects the distribution problem is unhelpful.<br>
</td>
</tr>
</table>
<br><br>
<br>
<span style=" font-family:'arial'; font-size: 10pt; color: #008080;"><i>--&nbsp;<br>
<br>
Kind regards,<br>
Alexander Kayumov.<br>
<br>
Email:&nbsp;</i></span><a style=" font-family:'arial'; font-size: 10pt;" href="mailto:alexander-***@yandex.ru">alexander-***@yandex.ru</a><span style=" font-family:'arial'; font-size: 10pt; color: #008080;"><i>,&nbsp;</i></span><a style=" font-family:'arial'; font-size: 10pt;" href="mailto:***@gmail.com">***@gmail.com</a></body></html>

[Stephen Michel]

Unfortunately, while you and I will, the average user simply isn't going to check a signature unless they are both guided & required to do so.

Post by Alexander Kayumov
Well, maybe Windows really is moving in that direction, but the day
Windows forces users to use its app store (which is bound to be a
parody of Apple and Android app stores, as always) will be the day I
switch to another OS. I am currently running Windows 7 and have not yet
used Windows app store ONCE in my entire life.
I don't think one has to be paranoid and/or an expert to install
software on Windows: just download it from a trustworthy source (e.g.
SourceForge, FossHub, etc.) that uses https and check the installer's
digital signature before clicking "ok" in the dialogue.
A.
Think about how desktop is moving towards the same distribution model
though. Windows has an app store, as does Mac OS X. Deploying something
inside an app store model is an option, even outside of browser app
stores (like what Chrome has). So it's worth considering.
The paranoid and/or experts can always manually compile, hash check, etc.
Is Signal Desktop in use on more than traditional computers? I don't
know of any other environments that allow Chrome plug-ins, although
Chrome is obviously used on more than desktop devices.
On Aug 21, 2016 02:20, "Alexander Kayumov"
This is partially so. But!
(First of all, 50 million users for Signal seems like a gross
exaggeration!.. Unfortunately.)
Second, desktop security is different in character from mobile
security. Your logic fully applies to and works for mobile security.
I've read Moxie defend the developers' decision not to distribute
Signal via platforms other than Google Play Store for Android, for
example. And I do indeed agree with all the arguments that he made and
that you have rehashed.
However, in my opinion, porting all these arguments over to the desktop
side is a bit ridiculous. It's simply not how desktop security works.
NO DESKTOP APP does this, other than Signal Desktop. ALL other desktop
security apps use other models, which somehow seem to more or less
work. Tor, Tails, TrueCrypt and other FDE software, password managers,
and so on and so forth - all use other, "traditional" desktop
distributions models.
You host your distribution on a secure server, you notify users of
updates, you let them check hashes and digital signatures, etc.
A.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps

platform

Post by Joel Whitehouse
in the first place. Did they just prefer javascript over c++?
Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the

privacy

Post by Joel Whitehouse
of 50 million users. How do you get it to them? Distributing an

update

Post by Joel Whitehouse
is a non-trivial problem that is fraught with its own security

concerns.

Post by Joel Whitehouse
OWS chose the Chrome Apps framework because it addresses those

concerns

Post by Joel Whitehouse
and more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google.
Who defends servers against DDoS attacks, updates the software that
pushes updates, including the PKI authentication so that the update
delivery protocol itself isn't hijacked to harm users? That's

Google.

Post by Joel Whitehouse
Who protects Signal's brand against app store typo squatting? Google
again. Together, all of these measures ensure that when a user

*thinks*

Post by Joel Whitehouse
they're protected by Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and

if

Post by Joel Whitehouse
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

--
Kind regards,
Alexander Kayumov.

[Emiliano Heyns]

I hadn't considered all of this. Good point.

But given this, Firefox offers no good alternative. They're going to make a
hard push towards webextensions, and the traditionally rich opportunities
of xul extensions is going to be phased out as they move towards e10s. This
is all supposed to be happening in 2017.

On Aug 21, 2016 12:41 AM, "Joel Whitehouse" <***@joelwhitehouse.com> wrote:

Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an opportunity
for it to be ported to their favorite language, even as a native app. But
before suggesting a language or framework to replace js/Chrome Apps, let's
consider why OWS selected the Chrome Apps platform in the first place. Did
they just prefer javascript over c++? Actually, the language has little to
do with it.

Consider what happens after you discover a bug that affects the privacy of
50 million users. How do you get it to them? Distributing an update is a
non-trivial problem that is fraught with its own security concerns. OWS
chose the Chrome Apps framework because it addresses those concerns and
more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google. Who
defends servers against DDoS attacks, updates the software that pushes
updates, including the PKI authentication so that the update delivery
protocol itself isn't hijacked to harm users? That's Google. Who protects
Signal's brand against app store typo squatting? Google again. Together,
all of these measures ensure that when a user *thinks* they're protected by
Signal, they actually are.

There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps, signal-desktop
is in need of a new secure distribution channel, and if that channel
prefers javascript, c# or even perl, so be it. But any discussion that
neglects the distribution problem is unhelpful.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.
Electon apps can run portable, and the behave like native apps. It uses

Post by Emiliano Heyns
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Emiliano Heyns]

If this matter is the overriding concern btw, electron could still be a
contender - in its incarnation as the atom editor. I have no skin in the
game when it comes to what technology is used to implement a desktop
client, and having to install an editor to use signal is obviously weird,
but it does take care of:

* platform + updates
* client (extension) hosting, delivery and updates
* cross-platform

Addons.mozilla.org / chrome store also does all of that of course, with the
added benefit that there are (some) quality checks before you can get on
it, but that's not much use if the platform they support isn't rich enough
to do what signal needs, and I assume (but don't know) that if signal
desktop is an app rather than an extension, it needs something that is
going away in 2018.

If it's just separate launchability as an app, I wouldn't see that as
something we should worry about. Just move to an webextension, the user
must launch a browser + click an icon instead of launch an app (and most
users will have the browser open anyway), done.

On Aug 21, 2016 10:48 AM, "Emiliano Heyns" <***@iris-advies.com>
wrote:

I hadn't considered all of this. Good point.

But given this, Firefox offers no good alternative. They're going to make a
hard push towards webextensions, and the traditionally rich opportunities
of xul extensions is going to be phased out as they move towards e10s. This
is all supposed to be happening in 2017.

On Aug 21, 2016 12:41 AM, "Joel Whitehouse" <***@joelwhitehouse.com> wrote:

Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an opportunity
for it to be ported to their favorite language, even as a native app. But
before suggesting a language or framework to replace js/Chrome Apps, let's
consider why OWS selected the Chrome Apps platform in the first place. Did
they just prefer javascript over c++? Actually, the language has little to
do with it.

Consider what happens after you discover a bug that affects the privacy of
50 million users. How do you get it to them? Distributing an update is a
non-trivial problem that is fraught with its own security concerns. OWS
chose the Chrome Apps framework because it addresses those concerns and
more importantly, it externalizes all the effort that goes into
maintenance. Who maintains the CDN servers to host the app? Google. Who
defends servers against DDoS attacks, updates the software that pushes
updates, including the PKI authentication so that the update delivery
protocol itself isn't hijacked to harm users? That's Google. Who protects
Signal's brand against app store typo squatting? Google again. Together,
all of these measures ensure that when a user *thinks* they're protected by
Signal, they actually are.

There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps, signal-desktop
is in need of a new secure distribution channel, and if that channel
prefers javascript, c# or even perl, so be it. But any discussion that
neglects the distribution problem is unhelpful.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.
Electon apps can run portable, and the behave like native apps. It uses

Post by Emiliano Heyns
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Noir]

Yeah that's cool. Maybe we all should switch to the Google messenger? I
guess it's more likely that they will implement e2e crypto before OWS
get rid of Google dependencies. Google has the power to breach the
privacy of both, Signal users and Hangout users anyway.

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps
platform in the first place. Did they just prefer javascript over
c++? Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the
privacy of 50 million users. How do you get it to them? Distributing
an update is a non-trivial problem that is fraught with its own
security concerns. OWS chose the Chrome Apps framework because it
addresses those concerns and more importantly, it externalizes all the
effort that goes into maintenance. Who maintains the CDN servers to
host the app? Google. Who defends servers against DDoS attacks,
updates the software that pushes updates, including the PKI
authentication so that the update delivery protocol itself isn't
hijacked to harm users? That's Google. Who protects Signal's brand
against app store typo squatting? Google again. Together, all of
these measures ensure that when a user *thinks* they're protected by
Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and if
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other
programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.
On 20 Aug 2016 9:53 a.m., "Emiliano Heyns"

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers

[Robert Obryk]

Post by Noir
Yeah that's cool. Maybe we all should switch to the Google messenger? I
guess it's more likely that they will implement e2e crypto before OWS
get rid of Google dependencies. Google has the power to breach the
privacy of both, Signal users and Hangout users anyway.

Do you mean "Google has the power to create system upgrades for
Android"? If so, phone manufacturers (and maybe even carriers; not
sure how system update signing works) can do that too.

If you are referring to Signal using GCM for notifications, then
please note that all notifications sent are empty. They are just used
to cause the client to try fetching new messages (and this doesn't use
any other Google infra then the phone itself AFAIK).

Cheers,
Robert

Post by Noir

Post by Joel Whitehouse
Chrome Apps, home of signal-desktop, will being shut down next year;
several folks on the mailing list are hopeful that this is an
opportunity for it to be ported to their favorite language, even as a
native app. But before suggesting a language or framework to replace
js/Chrome Apps, let's consider why OWS selected the Chrome Apps
platform in the first place. Did they just prefer javascript over
c++? Actually, the language has little to do with it.
Consider what happens after you discover a bug that affects the
privacy of 50 million users. How do you get it to them? Distributing
an update is a non-trivial problem that is fraught with its own
security concerns. OWS chose the Chrome Apps framework because it
addresses those concerns and more importantly, it externalizes all the
effort that goes into maintenance. Who maintains the CDN servers to
host the app? Google. Who defends servers against DDoS attacks,
updates the software that pushes updates, including the PKI
authentication so that the update delivery protocol itself isn't
hijacked to harm users? That's Google. Who protects Signal's brand
against app store typo squatting? Google again. Together, all of
these measures ensure that when a user *thinks* they're protected by
Signal, they actually are.
There would be no signal-desktop without Chrome Apps, so casually
suggesting that OWS should port it to c++, java, or
"electron" isn't much help. With the sunset of Chrome Apps,
signal-desktop is in need of a new secure distribution channel, and if
that channel prefers javascript, c# or even perl, so be it. But any
discussion that neglects the distribution problem is unhelpful.

Post by Sam Lanning
Exactly,
Picking electron + js is the same choice as picking any other programming
language and gui framework to write in, and it behaves as natively as any
other solution.
Take the atom text editor, and the brave web browser for example.
What also makes electron a sensible choice is is it will require very
little work, and I believe people have already got the signal desktop app
working as an electron app before.
That being said, regardless of the direction OWS decide to go, feel free to
experiment with making your own native client in a different programming
language, perhaps as suggested using Java.
Sam.
On 20 Aug 2016 9:53 a.m., "Emiliano Heyns"

Post by Emiliano Heyns
Electon apps can run portable, and the behave like native apps. It uses
"web technologies" but it's not tied to a browser.

Post by Johan Wevers

Or maybe something like Electron can be used?

Then you're still stuck with a browser app. Fine if that's what you
like. I would prefer native programs, able to run portable. Much better
for performance and stability.
--
Met vriendelijke groet,
Johan Wevers