<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with fe34]]></title><description><![CDATA[A list of topics that have been tagged with fe34]]></description><link>https://forum.fedi.dk/tags/fe34</link><generator>RSS for Node</generator><lastBuildDate>Thu, 28 May 2026 21:26:53 GMT</lastBuildDate><atom:link href="https://forum.fedi.dk/tags/fe34.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Question re: Origin Based Security Model (FEP-fe34)]]></title><description><![CDATA[My thoughts:
I don’t necessarily think FEP fe34 is strict enough to be a guiding principle for security across federated instances. The reporter said:
&gt; “at minimum” means same-origin is the floor, not the ceiling.
… and he’s right, there’s more you should do to verify that only the owner or a designated moderator can update and delete an object.
However we don’t have a widely-used ability to determine who the moderators or admins are for any given instance. Mastodon may have an endpoint (in their API), threadiverse software use their own (as directed by 1b12, and even then it’s optional), other software &lt;img class=“not-responsive emoji” src=“https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f937.png?v=f187f9278b7” title=“” /&gt; ?
So we fall back to origin-based security model and hand off the responsibility of determining who can and cannot alter somebody else’s objects to the sending server.
That’s a risk we take with this model. Not sure if there is more that can be done to tighten this up.
]]></description><link>https://forum.fedi.dk/topic/a39dcad1-8d83-4c77-9857-066d854dcc1f/question-re-origin-based-security-model-fep-fe34</link><guid isPermaLink="true">https://forum.fedi.dk/topic/a39dcad1-8d83-4c77-9857-066d854dcc1f/question-re-origin-based-security-model-fep-fe34</guid><dc:creator><![CDATA[julian@activitypub.space]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>