SteamDB has a filter for the AI Content Disclosed tag, which means we can exclude games with it. Now I know some lie, and others also use to state that they don't use AI, however it's the best we've got for now.
https://steamdb.info/sales/event/713414759190366804/?displayOnly=Demo&tagid=-1368160
SteamDB has a filter for the AI Content Disclosed tag, which means we can exclude games with it. Now I know some lie, and others also use to state that they don't use AI, however it's the best we've got for now.
https://steamdb.info/sales/event/713414759190366804/?displayOnly=Demo&tagid=-1368160
SteamDB has a filter for the AI Content Disclosed tag, which means we can exclude games with it. Now I know some lie, and others also use to state that they don't use AI, however it's the best we've got for now.
https://steamdb.info/sales/event/713414759190366804/?displayOnly=Demo&tagid=-1368160
I also posted this on the cross-post, here's a response.
I work at Mullvad. (co-CEO, co-founder)
Some aspects of the described behavior are as we intended and some are not. The cause is not exactly as described in the blog post. As for mitigation, we are already testing a patch of the unintended behavior on a subset of our infrastructure. If any of you try to reproduce the blog post's findings you may get confusing results throughout the day.
We will also re-evaluate whether the intended behaviors are acceptable or not. Some of this is a trade-off between multiple aspects of privacy, and multiple aspects of user experience.
Please note that this is my current understanding, which may change. I was only made aware of this an hour ago, and most of that time was spent talking with Ops, considering what to do immediately, and writing this post.
Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away.
Here's a response.
I work at Mullvad. (co-CEO, co-founder)
Some aspects of the described behavior are as we intended and some are not. The cause is not exactly as described in the blog post. As for mitigation, we are already testing a patch of the unintended behavior on a subset of our infrastructure. If any of you try to reproduce the blog post's findings you may get confusing results throughout the day.
We will also re-evaluate whether the intended behaviors are acceptable or not. Some of this is a trade-off between multiple aspects of privacy, and multiple aspects of user experience.
Please note that this is my current understanding, which may change. I was only made aware of this an hour ago, and most of that time was spent talking with Ops, considering what to do immediately, and writing this post.
Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away.
Oh, thanks for this. One question, what's with the URL on the banner? The character between the "7" and "D" in the banner looks disfigured.
Steam's AI Generated Content Disclosure states:
The developers describe how their game uses AI Generated Content like this:
-Some base textures have been AI generated during the development
-Some of the imagery and speech audio in the in-game TV programs are AI generated
-Some in-game radio music is AI generated
And a post by the developer specifically stating where AI is used.
Here is a specific rundown of the AI used in the game:
-One TV program that has two episodes, around 5min in length each (images and speech is AI, but written, edited and music composed by humans)
-One TV commercial 10sec in lenght
-Paintings on the house walls (same as in MSC)
-Food pictures/textures, around 12 separate pieces
-"Carbon fiber finish" texture, but this is definitely not important so it can be removed :D
-And then maybe half (in minutes) of the music on the radio, generated by AI and lyrics written by humans except for one instrumental song. These can be removed (apart from one song that is part of the game feature), but there is no replacement. Lets just say that without them, the radio experience is... rather interesting.
There's also 4get that is similar to SearXNG. https://4get.ca/
I have not tried it much personally though.
git repo: https://git.lolcat.ca/lolcat/4get
There's also archive.today that can bypass these paywalls. https://archive.ph/NfjJm
Look at either putting it behind a reverse proxy or using the built in Let's Encrypt / ACME configuration.
Suggested documentation:
The config linked to in their documentation states
# Address to listen to / bind to on the server
#
# For production:
# listen_addr: 0.0.0.0:8080
listen_addr: 127.0.0.1:8080
# Address to listen to /metrics and /debug, you may want
# to keep this endpoint private to your internal network
metrics_listen_addr: 127.0.0.1:9090
Port 8080 TCP is used for the connection, 9090 TCP is for metrics and not suggested to port forward. If you use a reverse proxy, you do not need to port forward to either of those ports directly, and instead to the reverse proxy.
The last thing I can suggest are the last two comments on the steam-devices repo: https://github.com/ValveSoftware/steam-devices/issues/64#issuecomment-3092449971
Try adding these to a file such as /etc/udev/rules.d/71-8bitdo-pro-2.rules
# 8bitdo pro 2 bluetooth hidraw
ACTION!="remove", KERNEL=="hidraw*", KERNELS=="*2DC8:6006*", MODE="0660", TAG+="uaccess"
and/or
ACTION!="remove", KERNEL=="hidraw*", KERNELS=="*2DC8:6012*", MODE="0660", TAG+="uaccess"
The reason I added ACTION!="remove" is due to a recent change with systemd.
ACLs for device nodes requested by "uaccess" udev tag are now always applied/updated by systemd-udevd through "uaccess" udev builtin, and systemd-logind no longer applies/updates ACLs but triggers "change" uevents to make systemd-udevd apply/update ACLs. Hence, the "uaccess" udev tag should be set not only on "add" action but also on "change" action, and it is highly recommended that the rule is applied all actions except for "remove" action.
Recommended example:
ACTION!="remove", SUBSYSTEM=="hidraw", TAG+="uaccess"
The following example does not work since v258:
ACTION=="add", SUBSYSTEM=="hidraw", TAG+="uaccess"
Check out this repo for udev rules: https://codeberg.org/fabiscafe/game-devices-udev
Instructions copied from repo: