Restricting remote access compared to network-local access (or not).

[michielbdejong]

The Box will be accessible through the local network (when you're at home, or in the building where the Box is installed), as well as remotely (when you are away from home / not in the building where the Box is installed).

When connecting to the Box over the local network, all functionality (except maybe factory reset, which could be a physical button on the Box), would be accessible to users with sufficient permissions (there is always at least one admin user, who has all permissions).

Remote access can be activated or disactivated. Whether it should be activated automatically during first-use (opt-out), or should only be activated if the user wants it to (opt-in) is a separate topic of discussion, we're not discussing that here.

The question here is: when remote access is activated, and a user is connected remotely (via the Bridge), should the accessible functionality be:

1) always equal to the functionality to which that user has access when connected locally, inside the home/building?

Or:

2) be a subset of that.

[michielbdejong]

To relay discussion that took place on the closed mailing list back in February:

If I am reading people's posts there correctly, @arcturus, @samgiles, @Yoric, @cr and @fabricedesre all expressed their standpoint that remote access as a whole should be optional, but once activated, it should open up access to all the functions you would be able to use locally (so sort of like an always-active remote desktop to your laptop).

I myself am (I think) the only one who thinks remote access should be only for the features activated (more like how you temporarily share your screen during a Vidyo conference).

In general, I still feel that we should not build a box if it does not add any security or privacy features compared to other products in the market. The fact that Foxbox will be interoperable with IoT devices from various manufacturers, and that there will be a --no-cloud build flag for switching off all use of hosted services definitely helps, and I'm glad we're not using a hosted IDP for account management on the box. But I still think we can do better, for instance with well-designed and more fine-grained security settings like this one.

[Yoric]

@michielbdejong Would a system of permissions granted on a per-application basis improve things?

[cr]

I think nobody proposed that remote access should be a binary condition of either full access or no access at all. Under the token-based authentication scheme proposed before, our main privacy advantage would be full transparency of and fine-grained control over what a cloud service can access on a Foxbox, as well as that no cloud service is required for regular operation or even just enabled per default, turning it into a conscious user choice.

As things stand now, enabling a cloud service would amount to pointing their servers to your foxbox's remote endpoint and providing it with access credentials (works for both token and user/pass) that are authorized with the desired access privileges. How can we sensibly distinguish a cloud service from an app using the tunnel? Would it even make sense to impose that distinction?

Perhaps @michielbdejong is also proposing to generally limit remote access? I.e. that remote access never allows for admin-level access, for example, limiting the risk of token or user/pass leakage. It definitely makes sense, because hardly any remote use case requires admin privileges and the whole process of dropping those privileges can relatively easily be made such that the user won't even notice.

I'd propose the following:

• Foxbox maintains a whitelist of privileges obtainable from remote, or, conversely, a blacklist of unobtainable permissions, or both. Editing this requires admin privileges.
• That list per default excludes privileges associated with admin access, and a simple global config option "Allow admin privileges from remote", disabled per default, modifies that list accordingly with a single click.
• Every time an app or service authenticates to Foxbox through the tunnel, the set of authorized privileges is filtered according to the whitelist/blacklist of remotable permissions.
• API users (app and service developers) are instructed to not rely on the set of privileges requested on registration, but to instead query the list of currently authorized privileges for every session.

[michielbdejong]

Would a system of permissions granted on a per-application basis improve things?

@Yoric I would think yes, because I could imagine some apps (e.g. TV remote control) only make sense while at home - so I would like those apps to get a home-only access token. What would you think yourself? Are you expressing your opinion that this would improve things, or just brainstorming?

[michielbdejong]

How can we sensibly distinguish a cloud service from an app using the tunnel? Would it even make sense to impose that distinction?

Good question - maybe we can whitelist client apps which we trust will not "upload" the token to the cloud? Of course, as soon as an app updates to start uploading tokens from client to cloud, there will be a period where they get away with this before their app is blocked. But maybe that is as good as it gets.

I think nobody proposed that remote access should be a binary condition

I think several people proposed that in our February discussion, but I could have misinterpreted people's statements.

@cr Glad to hear at least you and I are both against it. :)

whitelist of privileges obtainable from remote [...] per default excludes privileges associated with admin access

Yes! Thank you! :)

[Yoric]

Are you expressing your opinion that this would improve things, or just brainstorming?

Brainstorming. I haven't entirely understood the issue at hand yet.

[cr]

I could imagine some apps (e.g. TV remote control) only make sense while at home - so I would like those apps to get a home-only access token.

Similar use cases have been discussed in the current authentication proposal, so based on that, your use case can be modeled with tags as well: For example, attach a remote tag to all devices or channels that shall be accessible from outside home, and then put something like readwrite::remote on the remote whitelist. Alternatively, if it's for some external service, limit a token's access to readwrite::remote.

Even though this implies designing a fairly powerful and complex permission system, I still think it can be done.