
Google Chat is the worst desktop chat program I have ever used - shshhdhs
https://technex.us/2018/11/google_chat_is_the_worst_desktop_chat_program_I_have_ever_used/
======
zwayhowder
I agree with everything except the browser login bit. It should give you the
option. I uninstall any app that provides me an electron rendered window
claiming to be Google but with no visible URL or TLS info. It's a bad bad idea
to let average users get used to the idea that they should put their google
password and OTP into a black box that can do anything with it.

------
temeritatis
Almost all google products are really weak on Q&A. It's very sad that a
software giant, a leader, a "role model" such as google can not do better.
IMHO they should set an example for the rest of the industry.

Badly coded apps (web pages or what have you) are unfortunately the norm in
todays society, not the exception. Release now, fix later (if ever).

I often think about this when my boss or clients wants me to rush things (i.e.
skip testing, refactoring, write spaghetti code etc). Maybe that will save
them money in the short term. But if you look at it from a larger scale, in
the long term and also all the other people it will affect, i'm not sure it
will actually be cheaper for society as a whole. You can imagine the butterfly
effects it will have, and when everyone does it. It's mentality i wish would
go away quickly.

------
sascha_sl
This mostly boils down to using OAuth for login.

>What happened to sending my login info over an HTTPS connection in the
background and getting a session token back? I guess that's too simple for
Google.

Not exposing an HTTP endpoint that easily lets you check if a Google account
with said credentials exists (because it has to work from anywhere) and not
maintaining an API that supports all the weird edge cases to logging in to
Google (2FA, showing notices, locked out accounts, requiring additional
authentication).

You essentially want this mess with application specific passwords back?

~~~
stevew20
I think he's saying that in the persuit of security, Google has engineered the
usefulness and useability out of this application.

There are good, sane, safe ways to hold login credentials. Instead of those
ways, Google has picked one that is incredibly inconvenient, and with opening
a server on your machine, also opens a new attack surface... I hope they
deviated from their aweful coding practices and made the server right...

~~~
Crosseye_Jack
What’s insane or unsafe about this method? Using this method for signing in a
local application with Oauth is used all over the place with very little
issue.

Sure the interface could be tweaked a little by maybe offering to select which
browser to login with or othering the user a “copy sign in link to clipboard”
button or something for few people using multiple browser slash containers to
keep there accounts separated.

As for the localhost server listening for the code from oauth, it only needs
to run for the duration of processing the first login (if you are going to use
a keep signed in feature) reducing the window anyone could attack the server.
It doesn’t need to punch a hole in your nat, it just needs to bind to
localhost instead of your network card so only processes running locally could
access the server during the process.

Using a state field could remove any csrf attack surface.

All the server should be receiving in this case is a single use code which can
be exchanged for an access token to use the account depending on the scope you
have defined during to login process. The data in transit it’s still encrypted
all the way back to your browser. It’s only after you have successfully logged
in with the auth site send you a redirect header so your browser does the
final step of passing the code to the application.

If you captured the code in the redirect you would have to use the code before
the application could and if you managed that the application can not use the
code to the user in asking the user to log in again, if the user is able to
successfully login to the application then your access token will probably be
revoked once it’s regenerated when the application exchanges the code it got
from the successful login for a account bearer token.

Considering all this I would say it would be easier to just intercept the
access token over the network, the application memory or from where ever the
application stores it for its next use (it’s keep me signed in functionality)
which could be exploited from any other locally running application on your
system.

I don’t see how this is any less secure than sending the users password over
the wire from your application, having to dead with any 2fa the user has.

------
AtlasBarfed
Well, support will be yanked at the end of 2020 :-P

... in keeping with Google's disassociative identity in chat apps. It's
seriously now worse than Microsoft and syncing applications.

------
anotheryou
He can't have used skype for business yet

------
ledriveby
Electron apps are pretty miserable in general.

~~~
FlorianRappl
Is Google Chat really an Electron app? If it is, then I wonder why it cannot
do OTA update or why it has to open a browser for login (instead of opening
the page in the Electron shell).

Long story short: It's either a really badly written Electron app or no
Electron app (well, still obviously not written for 2018).

