[bug] Open Graph Protocol entries for image refer to wrong image on certain posts #304

New issue

Closed

opened 2023-04-21 21:24:25 +00:00 by Susul · 3 comments

Susul commented

2023-04-21 21:24:25 +00:00

Version

3595e391+snowdin

What were you trying to do?

I posted a this link to discord:

https://snowdin.town/notice/AUsunNDxV39uL1iZG4

I ran this command:

curl https://snowdin.town/notice/AUsunNDxV39uL1iZG4 | grep meta

What did you expect to happen?

1: An embed should have been generated that shows the image which was attached to the post

2: The meta tags should include the image attached to the post

What actually happened?

1: The embed only contained the profile picture

2: The meta tags only referred to the profile picture

Because there is no field for general comments:
This only happens with some posts, for example this post embeds as expected.
Also I have only tested this on a fork, tho this behaviour should also be present in this repo

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Version 3595e391+snowdin ### What were you trying to do? I posted a this link to discord: ``` https://snowdin.town/notice/AUsunNDxV39uL1iZG4 ``` I ran this command: ``` curl https://snowdin.town/notice/AUsunNDxV39uL1iZG4 | grep meta ``` ### What did you expect to happen? 1: An embed should have been generated that shows the image which was attached to the post 2: The meta tags should include the image attached to the post ### What actually happened? 1: The embed only contained the profile picture 2: The meta tags only referred to the profile picture Because there is no field for general comments: This only happens with some posts, for example [this post](https://snowdin.town/notice/AU52vTgQ0vlMFq8os4) embeds as expected. Also I have only tested this on a fork, tho this behaviour should also be present in this repo ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

floatingghost commented

2023-04-21 21:26:31 +00:00

Owner

the difference is your "bugged" one is NSFW-tagged

it would be expected behaviour to not expose sensitive images via metadata

the difference is your "bugged" one is NSFW-tagged it would be expected behaviour to not expose sensitive images via metadata

Susul commented

2023-04-21 21:41:16 +00:00

Author

I dont think this would be expected. If you are sharing something like this by link you are already intending it to be viewed.

If this was a post containing pornography and you are sharing it to discord, the discord channel its shared in would already be tagged NSFW. If you are sending it to a friend on telegram they would already have consented to viewing it.

If you are sharing the post somewhere else, you are the one putting a content warning on it. In this case the poster tagged it for eye-contact, but if you are sharing the post in a group where you generally dont CW eye-contact, you wouldnt want the embed to be hidden because of that CW.

Sharing a link fundamentally recontextualises a post and the choice to embed the image should be left at the sharer, not the software

I dont think this would be expected. If you are sharing something like this by link you are already intending it to be viewed. If this was a post containing pornography and you are sharing it to discord, the discord channel its shared in would already be tagged NSFW. If you are sending it to a friend on telegram they would already have consented to viewing it. If you are sharing the post somewhere else, you are the one putting a content warning on it. In this case the poster tagged it for eye-contact, but if you are sharing the post in a group where you generally dont CW eye-contact, you wouldnt want the embed to be hidden because of that CW. Sharing a link fundamentally recontextualises a post and the choice to embed the image should be left at the sharer, not the software

floatingghost commented

2023-04-21 21:46:22 +00:00

Owner

"recontextualised" or not, this is the expected behaviour

doc link: https://docs.akkoma.dev/stable/configuration/cheatsheet/#pleromawebmetadata-provider

this is not a bug

it is standard among fediverse software (masto behavies the same way)

"recontextualised" or not, this is the expected behaviour doc link: https://docs.akkoma.dev/stable/configuration/cheatsheet/#pleromawebmetadata-provider this is not a bug it is standard among fediverse software (masto behavies the same way)