I think I recall Vincent being added in early August.

He was sent for in-person vetting on July 29th

Seems WA likely had a series of infiltrators @Matthew MN which you eluded to a couple days back. But until we see codes that don't go back to Vincent WA then we can only speculate.

Robert WA was kicked because they all suspected him and he always wore a mask. Lines up with the other details. They likely are holding onto those screenshots to avoid implicating him or saving them for a dox.

I highly doubt that this guy joined and the next day was doing banner drops while having antifa follow them around. So I would expect another previously removed WA name to surface soon in these codes.

Yep, they will post them and clear it up for us soon.

@Matthew MN

Vincent WA
Created at
August 2, 2021 4:56 AM

Ok when added to an RC channel I am pretty sure you can scroll up

Yes, you can

Ok that explains that

If they have caught on to the numbers they might avoid releasing screenshots from their active guy

So in the screenshot I posted from July 31st, Vincent was scrolling up basically then?

yes

We may consider wiping network chats more frequently, if they aren't already under a policy.

Retention is 7-15 days

Ok, that seems like a balanced amount of time.

7 seems fair if it isn't already that

We can flag people who have suspicious reception for further evaluation, but we can't act as if gut feelings are substance of their own. There have been more cases of people just coming off as weird and being fine, and we don't want to lean into paranoia, the very thing these infiltration are meant to inspire.

As for Jake's idea, Directors could have a red flag sort of note that applies to their membership. If someone is flagged with any strange acts, then they are investigated heavily until either removal or reassurance.

Activism Channel: Raw photos are nearly useless to infiltration considering they're all published as-is, have no meta-data, and have never been used in any infiltration or opposition strategy in any instance. If someone is only visiting their home town, then that's something for their local leadership to examine. Otherwise, they only indicate a vague metro area. There may be some more efficient way to log the photos, but I think this should not be a focus while there are generally any other pressing matters. That's a downtime project.

@Jake AR I did not rename Victory, I have not been given any instructions on it. Do you want me to implement those CF settings on the Victory domain?

@Vincent TX @Jason NY What precisely is the proposed content of the announcement, cease using the application, make a new password?

Vincent WA:
August 2, 2021 4:56 AM

Time-wipe on channels seems fine across the board.

Summary of announcement would be:
- We are imminently disabling access to rocket chat via the rocket chat app
- You can only access rocket chat from now on using a web browser
- Let us know now if you don't remember your password so that you are not locked out

I would add "As previously announced," to the first line. This is not a new thing, this was announced months back.

@Jason NY You mean viewing on the web browser, and the desktop app, which does include the message codes? The disabling of the application is to ensure the codes are visible, correct? Only the [mobile] app is scheduled to be disabled, correct?

People may have a concern about functionality, driving people to use other platforms. Could updating the server to the latest version help alleviate this with the removal of the mobile application?

Was victory taken offline? It's offline right. I wanted it online so we can make sure our change didn't break it. Don't implement the cloudflare changes yet. We should let the announcement get to everyone first so they can start using browser on phone or computer.

Just turned it on again.

Disabling the mobile app is to ensure the codes are visible, however we are also restricting API access to only requests from victory (necessary) which will kill the mobile app as a side effect. The API restriction is to limit the scope of potential exploits and to prevent a denial of service by people flooding the API with bogus requests. The disabling of the API might also make the desktop app defunct.

That is correct. Mobile app should be only thing that stops working. If the cloud flare firewall change does not create the outcome that we want we will undo that change and do something else that's a little bit more complicated but in the end that is the goal to disable the mobile app

Okay nvm about desktop app then

The desktop app essentially uses a browser

Okay, so just to confirm, desktop app will be fine? Only mobile app.

Confirmed

Correct

Thank you.

You can also put in the announcements that if anyone has any trouble and is unable to get back into the server they can use the website or mumble

SOP is send a contact request or message via someone you know.

Gotcha

Victory is back up

@Thomas Jason is correct with the announcements we need to throw out

Will do that in conjunction with other announcements in the plans already.

Thank you

@all So what is being implemented this evening, and by who'm. Want to write this down

I'd make it clear they can use mobile browser. Ppl think everything on a phone is an app sometimes

@Vincent TX Tonight's goals are to prepare for API restriction. We will need to wait for some time after the announcement goes about, probably until the morning. We also need to get a development sandbox VPS up so that we can install the latest version of rocket and work on importing our scripts and database. We'll swap production with sandbox only once we're sure everything is working correctly. We can then move on to secondary goals.

Save password complexity for a different time, something that can be rolled out gradually?

Yep, secondary goal imo.

Okay

For upgrading rocket chat I think we should try to make a clone of the server and we might be able to do that through our host. Then run an incremental script to upgrade rocket chat through all the minor releases which will upgrade the database schema

Oh great idea, I didn't think about that. That'll make our job much easier.

If everything checks out, then we implement here.

There's a good chance that all of our customization will be fine the main issue is does the database update and does our front end layout change a whole lot like the colors the order of things sometimes they add features and so we have to go in and disable them in the settings

If Thomas can make a clone of the server we'll get a new IP address but I'll need to go in there and disable the firewall that only allows you to access the front end from cloudflare. After that we should be able to go into the IP address to test it

Sounds good.

Actually I forgot the firewall is through our host so when Thomas makes a clone we just need to disable the firewall settings for that clone server

I say we focus on the next 24 hours getting everybody onto the browser and making sure that's all working and then we can work on cloning a server because if this all gets messed up we're going to need Thomas to go in there and undo the cloudflare stuff so I don't want Thomas doing two things

Does restricting the API have the potential of messing up the server in a significant way?

No, it doesn't. It's all outside rules from cf, so simply delete rule and everything goes back to normal instantly

I just didn't want to rush it just in case we get bogged down helping ppl reset passwords and stuff

I'm cool with it either way. Glad we're getting changes done

We can fix every issue with the updated rocket chat / database schema on a dev sandbox and then only switch it over to production when we're absolutely sure it'll work as expected

I don't think we need to wait to get started on that

Okay. Also just so we're on the same page the goal is to use the sandbox just to test the upgrading process and if that is all good then we will do that live on the actual production server because we don't want to lose messages that happened since the clone

Depends on how quickly we can import the database and have it working properly I suppose

And just as a reminder before we do anything on the production server, we have to have Thomas make a snapshot so worst case scenario we can just revert back to a few hours before. But we'll do that once we're done testing with the sandbox and know that everything works

Yep definitely

If we figure out a method to import the database and upgrade the schema within 10 minutes we'll probably be good to just swap sandbox with production rather than building up production live

Someone can just do it at like 4 am and there probably won't even be any messages sent

If it's that fast we can consider swapping, but in the past we've just kept the same server.

We will soon find out

Another thing is to remember to record the steps that we're taking to upgrade the server on our cryptpad doc as we go along

Yea, I'd like to know what worked too. I keep docs on all RC processes

Excellent. I think we're good to go as soon as server is cloned.

@Thomas Steps to clone server: power down main rc server, create a snapshot, power on main rc server, go to MORE next to latest snapshot and choose CREATE, choose the same configuration of memory, I think it's 3gb but check, create some root password and send that to Jason NY, go into the newly created server, choose networking then under firewalls it should say no firewalls applied

@Jason NY I am not sure if the clone copies over ssh meys, but if not the root password should work

No worries

https://pf3618.bloodandsoil.org/group/socialmediamanagement?msg=fbjn9nC3Dn6vukCZq

This either confirms that there is another infiltrator, or that antifa has obtained the police reports.

Or the guys who did it are in communication with him and are stupid enough to brag about threatening me with a firearm

You know that is the case bro. These people live off of hubris alone.

Putting on the hacker glasses

This guy is real dumb if he is clicking random links

Or he's just trolling and opening it while on tails to waste our time. I hope he's dumb

It's an android user agent

Android 10

Motorola Moto Z4

Comcast-7922

It's not a tor circuit because it's on hardly any blacklists.

Might be connecting from phone but that's not a mobile hostname.

Residential VPN/Proxy or it's actually where he's at.

https://search.arin.net/rdap/?query=71.56.169.200

@Thomas talk with Paul CA before doing anything with the infils information

That IP is not listed in the mumble logs

I did however find some of Vincents info

On 11/17 he logged in from Corona California

I mean he said some really stupid shit in a public Telegram chat when he got angry

We also found a residential Seattle IP

Lawrence FL just sent me screenshots of all of that

You know what I just noticed, the secret hashes are not added to new messages

Idk how if it's when I left and came back it's like it didn't update the new messages. Let me know if you guys notice that. I might have to update the JS. Those hashes are critical

I see them in this channel

works for me

@Vincent TX sam should have sent you another even more incriminating screenshot