Hacker News Reader

Comment by zanny | Hacker News Reader

The only major problem I still have with Vector is that despite Matrix the protocol specifying ways to register and authenticate accounts using various web apis like oauth[1] Vector is always pushed as the premium Matrix webclient but it doesn't support anything but username / password.

You would be amazed how many people simply refuse to create new username / password pairs in 2016. And its a good thing. We should be past username / password. Support oauth2, openid connect, and for the privacy minded... keep complaining to Mozilla that they shutdown Persona.

http://matrix.org/docs/spec/r0.0.1/client_server.html#oauth2...

View on HN

Actually, Vector does support alternative auth mechanisms (although it's quite buried) - it implements the web fallback mechanism, both on web, iOS & Android, such that any unrecognised auth mechanisms can be handled by whatever webpage fragment hosted by the server, as per: https://matrix.org/docs/spec/r0.0.1/client_server.html#fallb...

For instance, we have a workplace deployment of Vector knocking around that uses CAS for auth, and the whole CAS flow is handled by the fallback mechanism. (This CAS happens to be user/pass, but it could easily be 2FA or whatever instead).

That said, it's still beta, and not super-documented.

I have no qualms about OpenID Connect itself — it is a sound standard, using JSON Web Tokens is a particularly nice feature — but I dislike encouraging users to identify themselves for every service they use with Facebook or Google accounts. Way too much information about your digital life centralised with a single commercial party.

I'd much rather see the use of password managers become more common, or even better, stimulate user-friendly two-factor authentication standards such as FIDO U2F.

OpenID Connect supports discoverability, which enables a protocol like Mozilla Persona to work over it. That's exactly what some others and I are working on, hopefully we will make some headway and greatly increase the usability of authentication again.

Sounds like a good initiative, be sure to post on HN when you reach significant milestones.

What I worry about with OpenID Connect on the open internet (as opposed to OpenID Connect used in a corporate setting, or to provide single sign-on solutions for specific partnered services) is how it almost always results in a service asking you to use Google or Facebook to authenticate, with huge coloured buttons, followed by a tiny de-emphasized grey link where you can sign up using email and a password.

Is this something we can prevent?

They only provide Google / Facebook buttons because they are by far the most popular option. In practice the vast majority of major online web services support some from of openid / oauth signon, from Github to Steam to Wordpress and more.

As a site developer, it is your job to figure out what buttons your user demographic will use. If it is all facebook / google, then provide those, and most of these sites know providing more obscure options only confuses their potential users.

I think it is, because the "Google" or "Facebook" part isn't static in OpenID Connect, they're just popular defaults. OIDC doesn't care where it goes to authenticate, you can just as well enter your email, foo@example.com and the server will try discovery and authentication against example.com (which can then be running your own OIDC provider).

What we're working on (we will definitely post about it) is basically OIDC with a nicer UX, where the user enters their email, the domain is parsed out, discovery (of OIDC or whatever other protocol) is done, and the user is redirected to either their provider, if found, or to a default method of authentication (currently a link sent over email) to log in.

So what you're saying is that username/password is still the only choice for privacy minded people.

Google Talk did have XMPP functionality, which allowed for SASL. [1] But of course, they killed this off because they wanted to dominate chat and messaging with their own proprietary protocol.

If they had not followed this strategy they would be killing in this market, even whilst supporting XMPP Federation. But they have chosen to release multiple proprietary products, so they aren't the lead in the market. Silly of them really, and it just shows you they aren't really the nimble company they once were.

1. https://developers.google.com/talk/open_communications

I doubt the decision to close up their protocols was taking lightly. You can bet that user lock-in is part of their current strategy.

Did any Google engineers ever reveal Google's true intentions for shutting down their XMPP offerings?

I'm still using XMPP to connect to GChat ... I use it every workday (via Pidgin).

Google stopped supporting XMPP in the sense that they stopped trying to change XMPP to fit their needs. They also started killing off support for arbitrary XMPP servers, e.g. you cannot run your own and expect it to work with Google Chat. (This was the most up to date link I could find.)[https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog...]

You can still somewhat use it, but it does not work well. Groupchats do not work at all anymore, and there is no message synchronization over it so any Hangouts client will populate messages an XMPP client never sees, and you cannot request chat history from the remote.

It is definitely not a high quality XMPP experience. If you want to use XMPP, you should probably be using duckduckgo's XMPP offering.

One day it will go away...

They killed it because Microsoft was leaching contact data from them without giving back.

https://news.ycombinator.com/item?id=11794776

We are pretty much past needing to remember them. Checkout password managers. There are lots of options in that space these days.

Reply on news.ycombinator.com