Determine how long the ability to re-enable unauthenticated media (i.e. `enable_authenticated_media: False`) will be supported
In the future we will drop the enable_authenticated_media option, making all media access need authentication in the future.
But which version of Synapse should do this?
cc @element-hq/trust-safety @element-hq/synapse-core
I suggest arbitrarily waiting 2 months at minimum, making this an early 2025 thing to happen.
This means dropping old spec versions, correct?
No, it means the config flag disappears. The freeze would be enabled by default, and cannot be turned off.
Thanks - in which case we'd like to propose end of Feb to remove this.
Sounds great! I don't expect anything to come up which delays it, but will raise loudly if that changes.
I understand I might be unique but unauthenticated access to files is one of the features that I use a lot. I allow large files on my selfhosted server and send these links to other people all the time. On top of that, my experience with trying to bridge these (large) files to other tools/services I often find I hit their limits and they wont send. In this case I'll send a link instead of the file so the people on the other end still get it.
I agree that by default unauthenticated access to files is a bad thing and it shouldn't be enabled by default but to remove this all together is a bad idea.
@RUzOfuz5m It's at all possible to use a small proxy server to serve medias at your homeserver unauthenticated, I found no reason why unauth media support must belongs in Synapse
@ShadowRZ well, even user avatar on matrix.to is broken now, so at least some files via some event or something, or files in public unencrypted rooms should be able to be set as available unauthenticated. Also this change broke the MSC1951, so you can't use custom stickers in element anymore, and it still not support the MSC2545 as another implementation (official app btw)
@Radiquum
Also this change broke the MSC1951, so you can't use custom stickers in element anymore (official app btw)
Element Sticker Picker are entirely unrelated to any MSC at all. While if using scalar.vector.im they might work, using https://github.com/maunium/stickerpicker (not an Element project btw) it can't work at all, likely due to Widgets API limitations which seems doesn't allow widgets to grab an auth token for auth media usage.
Also mind you provide details on how you get the screenshot you provided? I don't think it was shoted on matrix.to.
@Radiquum
Also this change broke the MSC1951, so you can't use custom stickers in element anymore (official app btw)
Element Sticker Picker are entirely unrelated to any MSC at all. While if using scalar.vector.im they might work, using https://github.com/maunium/stickerpicker (not an Element project btw) it can't work at all, likely due to Widgets API limitations which seems doesn't allow widgets to grab an auth token for auth media usage.
that's the point, since this change all media is require auth, so custom stickers in maunium that is based off msc1951, don't load, well you can send them (maybe), but you won't see any preview of what sticker are you sending, and it is literally the only way to use custom stickers in element.
And I'm talking about element there, since it doesn't support adding custom stickers natively via rooms, like in fluffychat/cinny that are implemented the msc2545, even though seems like it will be an official implementation of stickers
Also mind you provide details on how you get the screenshot you provided? I don't think it was shoted on matrix.to.
Also here the another screenshot
I mixed up the synapse auth screen with matrix.to in the previous one
custom stickers in maunium that is based off msc1951
Just to clarify, maunium-stickerpicker is not based on MSC1951 (nor any other MSC), it's just for element
Widgets (including sticker pickers) which require authenticated access to media can use https://github.com/matrix-org/matrix-spec-proposals/pull/4039
The MSC was updated to handle authenticated media changes.
Sounds great! I don't expect anything to come up which delays it, but will raise loudly if that changes.
Actually turns out the former discussion exposed something I haven't forseen, to quote myself:
Some builtin templates used
mxc_to_httpJinja function which is documented in https://github.com/element-hq/synapse/blob/ebc21a8c67ed7a05af010e329b6402cd41229ebe/docs/templates.md#L30-L35Implmented with https://github.com/element-hq/synapse/blob/ebc21a8c67ed7a05af010e329b6402cd41229ebe/synapse/util/templates.py#L84-L118 so looks like it returns an unauth thumb URL
I think it means builtin Synapse templates still relied on unauth media URLs, causing a defect in the screenshot posted in https://github.com/element-hq/synapse/issues/17950#issuecomment-2562678186
I personally don't consider that a blocker for this work. It sounds extremely similar to https://github.com/element-hq/synapse/issues/17832
Most clients support authenticated media but matrix.to still doesn't work apparently.
Also, I think the name enable_authenticated_media is a bit confusing, something like freeze_legacy_media may be better.
I've started this work at https://github.com/element-hq/synapse/pull/18732 though as noted in https://github.com/element-hq/synapse/pull/18732#issuecomment-3115203710 it's a bit non-trivial to fix all the tests.
If someone would like to take it over, please do. Otherwise I'll get to it again one day.