Proposal for an 'allowed widgets' setting

[turt2live]

No description provided.

[manuroe]

Will it be possible to trust widgets per domain?
Needing to trust every single widget is a bit boring, no? Instead a user could trust all widgets coming from the some vendor or host.

[turt2live]

Trusting per domain is unreliable because the widget itself is likely to be wrapped by an integration manager. If you were to trust all of scalar.vector.im for instance, it would potentially open you up to an attacker's custom widget which steals your data.

Partly because of this reason, riot-web has been requiring each widget to be individually accepted. We do have the additional feature where if the logged in user is also the creator of the widget then we don't require them to approve the widget (they created it, so they implicitly trust it) - this is more of an implementation detail for the user story though.

[turt2live]

@manuroe I've changed this to put all the widget IDs into one event rather than spreading them out. Please let me know what you think.

This is mostly because trying to implement the im.vector.setting.widget.<widget ID> event in riot-web is difficult, and this new structure should be a bit simpler.

[manuroe]

Trusting per domain is unreliable

Sure. I guess we are not at the point we can trust an integration manager provider for that. But in the future, such provider could curate, validate and sign widgets they propose to the user.

Note that nothing prevents malicious update of a widget already accepted by the the user.

As widgets instances have unique ids, if a user accepts an instance of a room widget called "The super widget" in a room, they will have to accept again and again any other instances of "The super widget" they will meet after.
Is it something we want?
We could trust urls to fix this.

I am still trying to check how to make use of widgets for users as smooth as possible because I barely see users accepting every single widget.

[manuroe]

Is it something we want?

The answer is yes. We made this decision so that we do not leak the user id within the the widget url.

[turt2live]

I am still trying to check how to make use of widgets for users as smooth as possible because I barely see users accepting every single widget.

So do I, but empirically it has been fine so far.

---

It looks like riot-web trusts the URL (before replacing template variables) in addition to the widget ID - will make this reflect that.

[turt2live]

I'm blocking this on the decisions needed in element-hq/user-stories#7

[turt2live]

and promptly unblocked

[manuroe]

Do you think we can add some granularity in im.vector.setting.allowed_widgets to make usages we talked about easier to implement in the future?

We could add an additional layer like widgets in im.vector.setting.allowed_widgets where we store the data specified in this current spec. Then, we will be able to add more sources of trust like rooms, vendors, senders, etc which will be specified when needed.

That will look like:

{
    "widgets": { 
        "$1543854381213sKqbg:example.org": true
    },
    "vendors": {
        "https://modular.im/"
    }
}

[turt2live]

@manuroe added, though I'm seriously unconvinced that we'll need the vendors support. It's a security risk waiting to happen :(

[dbkr]

How is the user going to be prompted to accept a widget? What information will be presented to them? This implies they need to see and approve the contents of the 'data' object too, and therefore know how any given widget will behave (ie. that 'custom widget' will load the page in curl). How is the user going to make a decision on this?

I can't help but think that if the user is going to have to re-approve the widget every time it's edited, this is only incrementally better than them having to re-approve it after each login.

[turt2live]

How is the user going to be prompted to accept a widget? What information will be presented to them? This implies they need to see and approve the contents of the 'data' object too, and therefore know how any given widget will behave (ie. that 'custom widget' will load the page in curl). How is the user going to make a decision on this?

This is all for the user story and out of scope here. This proposal is just to track the information, and the requirement down the pipe is that every edit needs to be tracked as a new flag (which includes data, cosmetics, etc).

I can't help but think that if the user is going to have to re-approve the widget every time it's edited, this is only incrementally better than them having to re-approve it after each login.

This thought has been brought up about 20 times but doesn't seem to be a hard enough blocker.

[dbkr]

OK - will take it to the user story

[BillCarsonFr]

According to the requirements, we should re-ask permission if the widget changes. Not sure how it can change, maybe an edition of the event? In this case is it enough to just store a boolean? maybe a kind content hash also?

[turt2live]

The event ID changes when the state event changes.

[BillCarsonFr]

Just a comment regarding the 'if widget changes' requirement

[dbkr]

Talked it through and I think basically this is fine: Tom's going to update the user story to reflect how we're using the widget whitelist to infer behaviour for thing like the 'custom widget' widget (ie. what we do now). I think this makes it OK in the sense that we're sort of doing a lot more than we strictly should in order to fix this more expediently in lieu of making changes to the the integration managers / widget spec.

[turt2live]

and with that, all the stakeholders approve so this can unblock the user story now.