Remove the requirement of a U1 account for notifications

[dpniel]

The requirement on having a U1 account is purely artificial and not used beyond checking the user actually has an account. This wasn't so much an issue when we only had the canonical store as you needed to sign in to U1 to install apps, but this isn't a requirement with the openstore.

I don't think a user should have to create a U1 account "just" to get notifications when it provides no advantages and isn't actually used by the push service.

This will just require removing the signing-helper binary and remove the auth checks from the client code.

[Flohack74]

Well I am not 100% with you... by removing any checks we effectively create an open push server on the internet, which can be used by (theoretically) anonymous masses. Not only we do not know these guys then (at least U1 is some form of identity), we also pay for the bandwidth. Imagine someone uses this for controlling his spam zombies...
I am fine with U1 but currently it´s not used in the right way. U1 is only checked on the device for creating the token. Basically also the server should check if incoming push msgs have a token that was generated using a valid U1 token, otherwise reject them.

[Flohack74]

And another side note, the current server will receive & queue messages if they just have a token set that looks valid, i.e. is a pair of device id and app id. The device does not need to be online/registered with the server. This can be exploited very easily ;)

[dpniel]

What I was thinking more of was having an oauth like setup between the client and server using a generated token/secret. Much like how you would register a 3rd party client with github or any other service. This would mean we can control access to the server on a per client basis but keep the user data minimal by continuing with just knowing the device name + app id.

[Flohack74]

Yep I agree...

[Flohack74]

Well why not:

1. Client logs in to U1
2. U1 issues an access token with this protocol feature: https://tools.ietf.org/html/rfc6749#section-4.4
3. Received token is given to Apps using push notifications
4. Apps combine this token with the app id and register on the 3rd party servers
5. 3rd party server send combined token
6. push server splits token and verifies that U1 token is valid

our push server has no idea who is behind the U1 token, as this information is not passed on. Tokens given by U1 will be eventually renewed when the device is rebooted etc, so there is probably not much deterministic data behind. Also pairing with IP addies makes not so much sense, since most IP addies on mobile networks are shared these days

[dobey]

I think we should remove the u1 account stuff entirely from ubports images. It is now only used for push notifications, and even then only used on the client side. We should remove it entirely, as it's a complicated custom plug-in for online-accounts, and Canonical will want to get rid of the API it uses to create the token and such, at some point, probably in the next 12 months or so when 14.04 becomes end of life. I think only reason it's still working, is because 14.04 still uses the old software-center.

As for your proposal there @Flohack74 it's not going to happen. U1 is not going to implement OAuth 2.0, and it is not currently using OAuth (though the token itself is compatible with 1.0a). I begged for a couple years to get OAuth 2.0 implement to make the account plug-in much simpler on the phone, and got nowhere with that.

Keeping it on doesn't help prevent spamming the push server or doing naughty things. I think we should get rid of it. I think if we want some better authentication here for push clients and servers talking to push server, we're going to need to do something outside the realm of U1 or Canonical servers.

[Flohack74]

Oh that is sad news, indeed. I was thinking that U1 will stay around, as it is not a really heavy footprint for Canonical. Is there any official announcement for that? And weren't there any developer services connected to it?

[dobey]

Well, U1 as a login service will stay around. It's used by snappy and Launchpad and a bunch of other services. However, they use different methods of authentication than the old API we're using, which is what will go away. The stuff snappy uses is I think designed heavily around snappy, and not suitable for us, and the OpenID stuff would only make sense for the forum site or such, not the phone.

I think relying on U1 for push doesn't make sense for how we're using it, or what we expect to get out of it. I think it would be better to figure out a better solution to the problems we're trying to solve by having the U1 login on the device now.

I don't think there's any official announcement about it, yet. I might expect to see something in a few months though, after 18.04 is out, Ubuntu Core 18 gets released, and someone takes stock of how many people have hit that API versus how many hits from 14.04 come from those same IPs, or such. After 14.04 EOL, I think UT devices would be the only thing still using that API, so I expect it to get removed, the same as the push server, app store, and other things have been removed.

[dobey]

Well I am not 100% with you... by removing any checks we effectively create an open push server on the internet, which can be used by (theoretically) anonymous masses.

Thought I should reply to this too, since it's not correct. As it stands, the push server is already 100% open on the internet. The U1 check is entirely on the client side, and the push service is fully documented. Anyone could go and create a client (or modify the existing client to just not need the U1 account), and deploy it anywhere, to make use of the existing server.

It's also very trivial to create a U1 account to use for this, so even if that requirement existed on the server side, anyone could still go and abuse the service for any other purpose.

I think we can solve these problems in a more reliable, and seamless, manner, without the U1 account; and in a way that would also improve our statistics data.