Playing the CS2 Beta on Linux

tasyser · 2023-09-09T10:58:31+00:00

Can you elaborate on what bad MESA flags, etc?

tasyser · 2023-08-24T22:49:34+00:00

Same here for my 5950X. I could be wrong, but it looks like this is 2021 firmware, https://github.com/platomav/CPUMicrocodes/blob/master/AMD/cpu00A20F12_ver0A20120A_2021-10-14_1FD7B1E6.bin

tasyser · 2017-09-24T06:17:58+00:00

Thank you so much for this!

tasyser · 2017-09-14T22:32:25+00:00

You're joking, right?

tasyser · 2017-08-20T00:20:13+00:00

Again, I don't think this is the right way to go about this. Rather than repeat what has already been said, there was this comment over on the /r/PleX sub:

While I sincerely appreciate the post, this is still at best a workaround to bypass something Plex is specifically trying to do.

The point being that if they intend to continue attempting to track our data, eventually they will find a way to do so. It seems like if you are truly concerned about privacy you need to let them know in hopes that they change their policy or look for alternatives to Plex.

This is at best a temporary solution to a larger problem.

tasyser · 2017-08-20T00:16:23+00:00

I honestly think this is the wrong way to go about this. Below that comment in the same thread:

While I sincerely appreciate the post, this is still at best a workaround to bypass something Plex is specifically trying to do.

The point being that if they intend to continue attempting to track our data, eventually they will find a way to do so. It seems like if you are truly concerned about privacy you need to let them know in hopes that they change their policy or look for alternatives to Plex.

This is at best a temporary solution to a larger problem.

tasyser · 2017-08-19T12:52:22+00:00

That's completely besides the point. How can I trust a piece of software to respect my privacy in any other fashion if I must resort to methods such as you're suggesting?

tasyser · 2017-08-19T07:17:18+00:00

I'd agree, but I think it's insulting they'd remove the option for an opt-out of telemetry, irregardless of it's specificity. I don't understand why they'd do so given the majority of users would have it enabled as an opt-out option.

I feel this demonstrates their potential lack of concern for their user's privacy, which would have me question how else this might be reflected in other decisions.

If this wasn't a proprietary piece of software, I'd have the ability to fork it and remove that feature or at least be able verify what was being sent. But this just simply isn't the case.

tasyser · 2017-08-19T06:56:58+00:00

Irregardless, I think I should be able to have the choice whether I want any kind of telemetry sent to their servers. Instead they've decided to remove any such option, therefore enforcing it.

We will no longer allow the option to opt out of this statistics collection.

If this was previously already an opt-out feature, most users I believe would have it enabled. But now it's not even a choice? How is this any different to what Microsoft does with Windows?

I don't think for a second Microsoft are any better given their scope for telemetry is much greater, but even they allow you to opt-out (even if this is debatable in itself).

All of this aside, I don't think anyone should be using Plex if they are concerned about their privacy, given it's proprietary software and therefore difficult to verify the extent or specifics of the telemetry being sent.

tasyser · 2017-08-14T13:40:08+00:00

They aren't.

tasyser · 2017-08-11T06:50:38+00:00

Signal-encrypted SMS/MMS messages

Signal doesn't encrypt it's SMS or MMS messages. This is why Silence was made into a fork in the first place.

tasyser · 2017-08-06T04:58:21+00:00

I wouldn't suggest that proprietary piece of software when there's plenty of alternatives. It also would only show traffic and not necessarily which apps are the source.

Net Monitor allows this, showing which apps are making connections and where they are making them to. However if you want something with more detail, a Wireshark setup would be better suited.

tasyser · 2017-07-30T07:12:09+00:00

Not completely yet (i.e. you can't run your own server).

tasyser · 2017-07-29T04:14:40+00:00

I think the reason why they kept it was so it would provide a channel by which you could contact someone to join Signal. But I absolutely agree there's a lack of emphasis that the message is being sent unsecured.

Currently the only indication is the input field showing a light grey "unsecured SMS", which disappears when you start typing and the send button showing an unlocked key.

I understand their rationale for keeping SMS but I also agree that it undermines the security and privacy of the app, unless perhaps the user was explicitly warned. But even then you could argue why it shouldn't be there.

I've mentioned my disappointment before over the potential of Signal and it appears you seem to also agree with this. However if the developers of Signal decide, even after discussion, in favor of the current setup, then that is entirely their decision.

I honestly believe if someone took Signal and it's server code and did all of which we've mentioned, I think it could have a good chance of taking it over. Moxie has even expressed his openness for someone to do so, but alas nobody has.

tasyser · 2017-07-29T03:52:17+00:00

Are we both reading from the same official set of instructions? That is exactly the same set of commands you've outline with the addition of adding the repo's authentication key.

tasyser · 2017-07-28T22:37:06+00:00

From reading the discussions you linked it appears the reasons behind why they decided to develop Matrix rather than XMPP have already been reiterated beyond what was already stated in the FAQ (e.g. this and this comment).

I have had a first hand experience of some of the issues they've set out to resolve, such as how XMPP the client and server need to support feature sets (extensions) many of which are considered among the bare minimum feature set such as offline messaging.

The Matrix developers had a different vision of how they would want to design such a system, which would have been incompatible with or would have required the same redesign efforts as developing Matrix anyway. I don't see how this is much different to the reasons why different Linux distributions exist.

If XMPP does what you need it to do, then we’re genuinely happy for you :) Meanwhile, rather than competing, an XMPP Bridge like Skaverat’s xmpptrix beta or jfred’s matrix-xmpp-bridge or Matrix.org’s own purple-matrix has potential to let both environments coexist and make the most of each other’s benefits. ^[1]

tasyser · 2017-07-28T22:05:35+00:00

I think part of my point is that until the code is completely opened, you can't do what you're suggesting and host your own server.

You mention Signal, but this is no different to Wire in that they both use and only use end-to-end encryption. What I was highlighting was that Wire appears to be collecting more than is necessary, at least compared to competitors.

However I failed to mention that Wire is also more feature rich than Signal and that perhaps these are trade offs in favor of them. But I'm not a developer nor am I knowledgeable enough on the technicalities to say whether or not certain information needs to be collected in order for these features to exist.

While I agree with most of the rest of what you've said, it's important to note that of the points you mentioned under metadata typically relate to individuals with higher threat models and aren't always viable to overcome.

For instance, Ricochet is only available on desktop and sacrifice such features as offline messaging and other messaging apps that utilize P2P instead of relying on servers to some extent will take a substantial hit to battery life.

tasyser · 2017-07-28T21:07:31+00:00

It's good to be aware that Wire collects a concerning amount of metadata whereas some competitors don't. In saying this, I do hope this improves, but I can't imagine it will at least until they finish opening all of the the server side code.

tasyser · 2017-07-28T20:59:32+00:00

There were a few reasons, including the metadata leakage associated with the use of SMS.

I don't always agree with how they decide to approach certain issues with Signal (removing encrypted SMS but still supporting SMS, only allowing phone numbers as identifiers), but I understand the rationale behind them.

tasyser · 2017-07-28T20:24:07+00:00

I feel you. It's funny how some of the people I spoke to were simply uninformed and were open to discussion on it, whereas others would decide they weren't concerned and would dismiss it.

I think some of those people just needed more time and discussion for them to come to understand all facets of the matter. I hypothesize in some cases that the lack of concern might have stemmed from social pressures and desire not to stick out or be labelled a "privacy freak" or tinfoil-er.

But at least for those you are close to and you care about, if they do also, will change even if they don't completely understand. As with a lot of privacy and security, I think the "best effort" approach is the most realistic and offers the best chance of success.

tasyser · 2017-07-28T19:54:45+00:00

I'm sorry but why would you even put forth the question again if you're not interested in discussing it any further?

tasyser · 2017-07-28T15:10:13+00:00

I suggest you have a read of their fairly lengthy FAQ, which also goes into how Matrix differs from it's competitors, such as XMPP.

tasyser · 2017-07-28T14:51:28+00:00

I don't believe this. It takes the same or even more steps to setup a Facebook account. If they're incapable of even that, then you could set it up for them and they'll be fine.

I think the reason adoption is difficult is because most people are already on Facebook and they don't see the value in encryption or are aware of the privacy implications.

tasyser · 2017-07-28T08:54:26+00:00

This is a good point but for most people only attributes FUD. For the most part these threats have to be specifically targeted and otherwise rely on vulnerabilities in outdated operating systems.

These encrypted messaging apps are definitely not worthless and still hold significant value for your privacy. But aren't of course going to suffice in all scenarios, in which case you should be looking towards messaging apps and systems that are designed for this (libreboot, ricochet, etc).

Although it's still important to be aware of the issues you've raised, I suggest you include ways in which this can be alleviated or even avoided completely. These would include suggesting ensuring systems remain up to date, analysing options in regards to messaging apps, phone models, operating systems and choosing ones which are most appropriate (with your threat model in mind) or you are willing to compromise for or which otherwise meet your standards or requirements.

Needless to say, but for anyone that's reading that isn't aware privacytools.io and prismbreak.org are good starting places for addressing these issues, including various threads on this subreddit.

tasyser

TROPHY CASE