Meta: Difference between revisions - Consumer_Action

(5 intermediate revisions by 4 users not shown)

Line 16:

====The Linux Ban====

On January 19th 2025, Meta updated their internal policies to recognize the [[free and open source software]] and operating system Linux as a "cybersecurity threat".<ref name=":1">https://distrowatch.com/weekly.php?issue=20250127#sitenews</ref><ref>https://www.tomshardware.com/software/linux/facebook-flags-linux-topics-as-cybersecurity-threats-posts-and-users-being-blocked</ref> As part of this, many Facebook users had their accounts either locked or muted for merely mentioning Linux, most notably the Linux distribution tracking site, DistroWatch. DistroWatch claims they appealed the decision the next day and had it affirmed to them that "Linux-related material is staying on the cybersecurity filter" alongside the personal account the appeal was sent from being locked. <ref name=":1" /> This quickly gained media attention with many calling this out as irony given Meta's infrastructure mostly runs on Linux.<ref>https://www.theregister.com/2025/01/28/facebook_blocks_distrowatch/</ref>

On January 19th 2025, Meta updated their internal policies to recognize the [[free and open source software]] and operating system Linux as a "cybersecurity threat".<ref name=":1">https://distrowatch.com/weekly.php?issue=20250127#sitenews</ref><ref>https://www.tomshardware.com/software/linux/facebook-flags-linux-topics-as-cybersecurity-threats-posts-and-users-being-blocked</ref> As part of this, many Facebook users had their accounts either locked or muted for merely mentioning Linux, most notably the Linux distribution tracking site, DistroWatch. DistroWatch claims they appealed the decision the next day and had it affirmed to them that "Linux-related material is staying on the cybersecurity filter" alongside the personal account the appeal was sent from being locked.<ref name=":1" /> This quickly gained media attention with many calling this out as irony given Meta's infrastructure mostly runs on Linux.<ref>https://www.theregister.com/2025/01/28/facebook_blocks_distrowatch/</ref>

9 days later on January 28th, PCMAG posted A comment to them by Meta directly confirming this was an error following Distrowatch's account being reinstated and the blocking of any Linux related content being lifted.<ref>https://www.pcmag.com/news/facebook-accidentally-blocks-users-from-posting-about-linux</ref>

Line 23:

====Artificial permission requirements in Android App====

The Facebook Android App summarily requests a lot of permissions. Most of those can be denied if unwanted. However, when the unlimited permission to access all media files on the user's phone is not granted, it is not possible to share images from the app. This is a completely bogus requirement, technically this permission is not needed. The app will guide the user into enabling that permission when they [first] try to share an image. Notably, even granting limited access will trigger the "more permissions required" guidance.

The Facebook Android App summarily requests a lot of permissions. Most of those can be denied if unwanted. However, when the unlimited permission to access all media files on the user's phone is not granted, it is not possible to share images from the app. This is a completely bogus requirement, technically this permission is not needed to share images ''out'' of an app. The app will guide the user into enabling that permission when they [first] try to share an image out of Facebook to a different app, e.g. a messenger. Notably, even granting limited access will trigger the "more permissions required" guidance.

As a crude workaround, one can take screenshots of images in the app instead of using its sharing functionality. Since that yields images in screen resolution, this workaround may not be suitable in all cases.

''[Anecdote follows, is there a better place for information like this?]'' This seems especially concerning since the app recently suggested that I post a "story", by putting together its suggestion of one. In that story, it used a picture I have in my camera roll - interestingly, a picture that is years old, that actually shows me, and I'm only partially dressed - it's a picture I took in a fitting booth that did not have good mirrors available. Possibly complete coincidence, but since only a very small percentage of pictures in my camera roll actually show me, it strongly suggests some algorithmic stuff going on. Which leaves the question, does that algorithm really run completely locally on the phone, or are images uploaded to Meta that the user never OK'd for this?

''[Anecdote follows, is there a better place for information like this?]'' This seems especially concerning since the app recently suggested that I post a "story", by putting together its suggestion of one. In that story suggestion, it used a picture I have in my camera roll - interestingly, a picture that is years old, that actually shows me, and I'm only partially dressed - it's a picture I took in a fitting booth that did not have good mirrors available. Possibly complete coincidence, but since only a very small percentage of pictures in my camera roll actually show me, it strongly suggests some algorithmic stuff going on. Which leaves the question, does that algorithm really run completely locally on the phone, or are images uploaded to Meta that the user never OK'd for this?

In my opinion, Android [or an Open Source fork of it] could strongly use a sandbox model that would allow me to "grant" that permission to the app, without actually allowing it to access anything outside of a dedicated container that the user has complete control over.

'''Useless notifications to boost engagement and facilitate tracking'''

Initially, notifications on the site were used to inform the user of events that warranted their attention, such as a new post to their wall, a direct message or interactions with their posts. Clicking the notification icon would clear its state. However, at some point Facebook started to trigger notifications when the user was inactive for too long in order to get them to engage with the platform more, which would then in turn indirectly increase their ad exposure. It was also no longer possible to fully clear the notifications because new ones would appear instantly. E-Mail notifications with the clear intent of getting the user to go to the platform rather than informing the user of something relevant are also sent on a regular basis.

This creates a constant sense of the user having unfinished business and missing out on something potentially important on the platform even though this is clearly not the case.

This was exacerbated when mobile platforms became more relevant because they allow app vendors to display notifications on the home screen of the device as well as red badges with notification counts or exclamation marks overlaid over the app icon. Incoming notifications also allow mobile apps to be woken from suspended energy saving state and do active processing in the foreground, which makes it easier for Facebook to do background tracking and transmit information back more often. This practice was also adopted by Instagram when Meta (then called Facebook) took over the platform.

===Meta Oculus VR===

Line 60:

Line 68:

Both Unity and Unreal Engine allow various OpenXR vendor plugins to be used, one of which is Meta's Oculus XR Plugin internally called the OVRPlugin. The OVRPlugin is a unified plugin that allows developers a single unified implementation for their Quest devices and OpenXR compatible devices for the PC. This sounds like an easy solution to target all current popular high-end VR headsets in one implementation.

Under the hood Meta has taken steps to lock down this plugin to only work with their own devices. This is done by checking the name of the runtime, the presence of the nonstandard XR_META_headset_id, and the lack of legacy OVR support. <ref name=":2" />

Under the hood Meta has taken steps to lock down this plugin to only work with their own devices. This is done by checking the name of the runtime, the presence of the nonstandard XR_META_headset_id, and the lack of legacy OVR support.<ref name=":2" />

It would be understandable that Meta locks down their own vendor plugin if it were incompatible with other OpenXR devices, in which case the engine could fall back to another implementation. However this is not the case as Meta makes it deliberately difficult to implement such fallbacks. For example in Unity if the generic OpenXR support is enabled while the OVRPlugin is enabled it will claim incompatibility and revert this selection to just OVRPlugin.<ref name=":2" />

Line 70:

Line 78:

As the result of their actions Meta's users are now locked in Meta's own runtime and remote streaming solution if no workarounds are applied either in the game or in the runtimes of third party's. This makes it seem like only Meta's runtime is stable and compatible with the latest games. Likewise, this forces all other headset vendors to implement similar workarounds for their devices.

Game developers are ~~adviced~~ to avoid the OVRPlugin where possible and rely on generic OpenXR implementations that support the standard correctly. ~~Effected~~ users can try the Meta Plugin Compatibility option in their SteamVR settings. The latest version of Virtual Desktop should also have the workarounds implemented. Players of Unreal Engine games report that launching the game with -hmd=openxr can bypass the plugin.

Game developers are advised to avoid the OVRPlugin where possible and rely on generic OpenXR implementations that support the standard correctly. Affected users can try the Meta Plugin Compatibility option in their SteamVR settings. The latest version of Virtual Desktop should also have the workarounds implemented. Players of Unreal Engine games report that launching the game with -hmd=openxr can bypass the plugin.

==Lawsuits==

@@ Line 16: / Line 16: @@
 ====The Linux Ban====
-On January 19th 2025, Meta updated their internal policies to recognize the [[free and open source software]] and operating system Linux as a "cybersecurity threat".<ref name=":1">https://distrowatch.com/weekly.php?issue=20250127#sitenews</ref><ref>https://www.tomshardware.com/software/linux/facebook-flags-linux-topics-as-cybersecurity-threats-posts-and-users-being-blocked</ref> As part of this, many Facebook users had their accounts either locked or muted for merely mentioning Linux, most notably the Linux distribution tracking site, DistroWatch. DistroWatch claims they appealed the decision the next day and had it affirmed to them that "Linux-related material is staying on the cybersecurity filter" alongside the personal account the appeal was sent from being locked. <ref name=":1" /> This quickly gained media attention with many calling this out as irony given Meta's infrastructure mostly runs on Linux.<ref>https://www.theregister.com/2025/01/28/facebook_blocks_distrowatch/</ref>
+On January 19th 2025, Meta updated their internal policies to recognize the [[free and open source software]] and operating system Linux as a "cybersecurity threat".<ref name=":1">https://distrowatch.com/weekly.php?issue=20250127#sitenews</ref><ref>https://www.tomshardware.com/software/linux/facebook-flags-linux-topics-as-cybersecurity-threats-posts-and-users-being-blocked</ref> As part of this, many Facebook users had their accounts either locked or muted for merely mentioning Linux, most notably the Linux distribution tracking site, DistroWatch. DistroWatch claims they appealed the decision the next day and had it affirmed to them that "Linux-related material is staying on the cybersecurity filter" alongside the personal account the appeal was sent from being locked.<ref name=":1" /> This quickly gained media attention with many calling this out as irony given Meta's infrastructure mostly runs on Linux.<ref>https://www.theregister.com/2025/01/28/facebook_blocks_distrowatch/</ref>
 days later on January 28th, PCMAG posted A comment to them by Meta directly confirming this was an error following Distrowatch's account being reinstated and the blocking of any Linux related content being lifted.<ref>https://www.pcmag.com/news/facebook-accidentally-blocks-users-from-posting-about-linux</ref>
@@ Line 23: / Line 23: @@
 ====Artificial permission requirements in Android App====
-The Facebook Android App summarily requests a lot of permissions. Most of those can be denied if unwanted. However, when the unlimited permission to access all media files on the user's phone is not granted, it is not possible to share images from the app. This is a completely bogus requirement, technically this permission is not needed. The app will guide the user into enabling that permission when they [first] try to share an image. Notably, even granting limited access will trigger the "more permissions required" guidance.
+The Facebook Android App summarily requests a lot of permissions. Most of those can be denied if unwanted. However, when the unlimited permission to access all media files on the user's phone is not granted, it is not possible to share images from the app. This is a completely bogus requirement, technically this permission is not needed to share images ''out'' of an app. The app will guide the user into enabling that permission when they [first] try to share an image out of Facebook to a different app, e.g. a messenger. Notably, even granting limited access will trigger the "more permissions required" guidance.
 As a crude workaround, one can take screenshots of images in the app instead of using its sharing functionality. Since that yields images in screen resolution, this workaround may not be suitable in all cases.
-''[Anecdote follows, is there a better place for information like this?]'' This seems especially concerning since the app recently suggested that I post a "story", by putting together its suggestion of one. In that story, it used a picture I have in my camera roll - interestingly, a picture that is years old, that actually shows me, and I'm only partially dressed - it's a picture I took in a fitting booth that did not have good mirrors available. Possibly complete coincidence, but since only a very small percentage of pictures in my camera roll actually show me, it strongly suggests some algorithmic stuff going on. Which leaves the question, does that algorithm really run completely locally on the phone, or are images uploaded to Meta that the user never OK'd for this?
+''[Anecdote follows, is there a better place for information like this?]'' This seems especially concerning since the app recently suggested that I post a "story", by putting together its suggestion of one. In that story suggestion, it used a picture I have in my camera roll - interestingly, a picture that is years old, that actually shows me, and I'm only partially dressed - it's a picture I took in a fitting booth that did not have good mirrors available. Possibly complete coincidence, but since only a very small percentage of pictures in my camera roll actually show me, it strongly suggests some algorithmic stuff going on. Which leaves the question, does that algorithm really run completely locally on the phone, or are images uploaded to Meta that the user never OK'd for this?
 In my opinion, Android [or an Open Source fork of it] could strongly use a sandbox model that would allow me to "grant" that permission to the app, without actually allowing it to access anything outside of a dedicated container that the user has complete control over.
+'''Useless notifications to boost engagement and facilitate tracking'''<!-- Maybe this warrants its own explanation, seeing that it has since become a commonly used dark pattern -->
+Initially, notifications on the site were used to inform the user of events that warranted their attention, such as a new post to their wall, a direct message or interactions with their posts. Clicking the notification icon would clear its state. However, at some point Facebook started to trigger notifications when the user was inactive for too long in order to get them to engage with the platform more, which would then in turn indirectly increase their ad exposure. It was also no longer possible to fully clear the notifications because new ones would appear instantly. E-Mail notifications with the clear intent of getting the user to go to the platform rather than informing the user of something relevant are also sent on a regular basis.
+This creates a constant sense of the user having unfinished business and missing out on something potentially important on the platform even though this is clearly not the case.
+This was exacerbated when mobile platforms became more relevant because they allow app vendors to display notifications on the home screen of the device as well as red badges with notification counts or exclamation marks overlaid over the app icon. Incoming notifications also allow mobile apps to be woken from suspended energy saving state and do active processing in the foreground, which makes it easier for Facebook to do background tracking and transmit information back more often. This practice was also adopted by Instagram when Meta (then called Facebook) took over the platform.
 ===Meta Oculus VR===
@@ Line 60: / Line 68: @@
 Both Unity and Unreal Engine allow various OpenXR vendor plugins to be used, one of which is Meta's Oculus XR Plugin internally called the OVRPlugin. The OVRPlugin is a unified plugin that allows developers a single unified implementation for their Quest devices and OpenXR compatible devices for the PC. This sounds like an easy solution to target all current popular high-end VR headsets in one implementation.
-Under the hood Meta has taken steps to lock down this plugin to only work with their own devices. This is done by checking the name of the runtime, the presence of the nonstandard XR_META_headset_id, and the lack of legacy OVR support. <ref name=":2" />
+Under the hood Meta has taken steps to lock down this plugin to only work with their own devices. This is done by checking the name of the runtime, the presence of the nonstandard XR_META_headset_id, and the lack of legacy OVR support.<ref name=":2" />
 It would be understandable that Meta locks down their own vendor plugin if it were incompatible with other OpenXR devices, in which case the engine could fall back to another implementation. However this is not the case as Meta makes it deliberately difficult to implement such fallbacks. For example in Unity if the generic OpenXR support is enabled while the OVRPlugin is enabled it will claim incompatibility and revert this selection to just OVRPlugin.<ref name=":2" />
@@ Line 70: / Line 78: @@
 As the result of their actions Meta's users are now locked in Meta's own runtime and remote streaming solution if no workarounds are applied either in the game or in the runtimes of third party's. This makes it seem like only Meta's runtime is stable and compatible with the latest games. Likewise, this forces all other headset vendors to implement similar workarounds for their devices.
-Game developers are adviced to avoid the OVRPlugin where possible and rely on generic OpenXR implementations that support the standard correctly. Effected users can try the Meta Plugin Compatibility option in their SteamVR settings. The latest version of Virtual Desktop should also have the workarounds implemented. Players of Unreal Engine games report that launching the game with -hmd=openxr can bypass the plugin.
+Game developers are advised to avoid the OVRPlugin where possible and rely on generic OpenXR implementations that support the standard correctly. Affected users can try the Meta Plugin Compatibility option in their SteamVR settings. The latest version of Virtual Desktop should also have the workarounds implemented. Players of Unreal Engine games report that launching the game with -hmd=openxr can bypass the plugin.
 ==Lawsuits<!-- I feel like this should follow the table format that I established with the Valve page -->==