MSC3852: Expose user agent information on Device
#3852
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| # MSC3852: Expose user agent information on `Device` | ||
|
|
||
| Currently, sessions are only easily recognisable by their `device_name`. Depending on client implementation, this may | ||
| include some stringified information about the session. (For example, Element web uses `'%(appName)s (%(browserName)s, | ||
| %(osName)s)'`). This information can become stale, and if edited by the user any device detail is lost. | ||
|
|
||
| By exposing more detailed and up to date session information, users will be able to more easily recognise their | ||
| sessions. This gives users more confidence in removing stale or suspicious sessions. | ||
|
|
||
| ## Proposal | ||
| Home servers already record the user agent per session today to expose it in the admin API [GET | ||
kerryarchibald marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. for the historical record (not that it affects this MSC at all): it's believed to be a mistake that any admin endpoints made it into the spec, though this is pending further discussion. However, a server should still have realtively easy access to user agent information if it needed to start storing it. |
||
| /_matrix/client/v3/admin/whois/{userId}](https://spec.matrix.org/v1.3/client-server-api/#get_matrixclientv3adminwhoisuserid). | ||
| This MSC proposes exposing the latest recorded user agent as `last_seen_user_agent` on the `Device` model returned by | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Client-Server API endpoints [GET | ||
| /_matrix/client/v3/devices](https://spec.matrix.org/v1.3/client-server-api/#get_matrixclientv3devices) and [GET | ||
| /_matrix/client/v3/devices/{deviceId}](https://spec.matrix.org/v1.3/client-server-api/#get_matrixclientv3devices). | ||
|
|
||
| ```jsonp | ||
| { | ||
| "device_id": "QBUAZIFURK", | ||
| "display_name": "android", | ||
| "last_seen_ip": "1.2.3.4", | ||
| "last_seen_ts": 1474491775024, | ||
| "last_seen_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" | ||
| } | ||
| ``` | ||
|
|
||
| ## Alternatives | ||
| N/A | ||
|
|
||
| ## Security considerations | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| The user agent is currently only exposed in the admin API and following this MSC would be accessible to normal users. | ||
|
There was a problem hiding this comment. I'd imagine some of these concerns could be alleviated by allowing this to be opt-in, i.e. a query parameter on device creation that states whether the user_agent should be tracked. I would also make the field optional for homeservers that just don't want to track that information, because I can see contexts where storing that information could be difficult legally. There was a problem hiding this comment. Note that as stated in the MSC, homeservers already expose user agent information via On the client-side, if the client wishes to not share their user agent with the homeserver, then don't send a user agent with your request. |
||
| The `/devices` endpoints only return device information for the current user, so this is not a concern. | ||
|
|
||
|
|
||
| ## Unstable prefix | ||
| While this MSC is not included in the spec `last_seen_user_agent` should use the unstable prefix | ||
| `org.matrix.msc3852.last_seen_user_agent` | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably a little late with this kind of feedback, but I do wonder if user agent strings are a thing we really want to be showing to end users. They've started their journey towards being deprecated anyway in favour of user agent hints (although obviously it will be a long road). Would adding a device name or similar that's just not visible to other users achieve a similar thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I have an MSC in the pipeline to make device names completely hidden from other users.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the problem is that on web the only way to get information about the platform (operating system, browser, browser version) is the user agent. Without using the user agent we couldn't make this information available to clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely any information in the user agent we could equally get with javascript and put into a field in the request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My JS-fu is weak. Would that not still have to use the user agent? I'm not sure I understand how that is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, I can't speak on behalf of the entire SCT. I don't think it's that bad, just worth considering other options (and the alternatives section is blank, after all).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. @kerryarchibald could you add this into the alternatives so that it's clear to everyone without having to read this thread?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have added two options to the alternatives section, please let me know if I've transcribed them accurately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding those @kerryarchibald. It spells out the problem and potential solutions concisely.
Note that if folks are particularly taken with either alternative approach, I'd recommend they create a new MSC and mention that it is an alternative approach to this one.
As for this MSC, I remain concerned with having a field explicitly for user agent. Perhaps a third alternative could be a mix of the two presented already: we have separate fields for
platform,clientBrandandclientVersion, but they are set by the homeserver using HTTP client hints, or the client's latest user agent as a fallback.That would eliminate the concern of clients not keeping the information up to date, while additionally not enshrining user agents into the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kerryarchibald are you able to take a look at this thread? It appears to be the blocker for this MSC entering FCP at the moment.