I haven't done it with docker. Have you looked at the docker config that specifies the rc version

We definitely want Thomas to make a snapshot of the server right before we make any changes so that way we can easily just revert everything and only lose like at most an hour

I assume it's something like this. Is this what Michael tried? https://forums.rocket.chat/t/solved-please-help-how-to-update-rocket-chat-on-docker/6672

Customizations:

One improvement would be to compartmentalize the org into isolated servers with leadership being allowed in a central one. Activism photos could be uploaded via victory or in a channel on each rocket chat instance which forwards it to a central rocket server. This would limit infiltrators reach (can't see all users), and if a server is breached we don't give up all our info.

They could technically be on a single server but further protection would be on multiple servers

Oh, this is why we disabled auto update

The db has to go through schema updates as well, I'll look into how we do that

That probably is the case

It was a major headache in the past and would just wreck the server automatically one day

Updating is not always best with RC, it breaks a lot of stuff usually, especially visually and new features have to be disabled and hidden. I agree that we should for possible security fixes, but it also has a risk.

That'll probably work still

Yeah rocket chat says they recommend updating one version at a time to make sure that the database updates properly

That's a pain

They have to log in to get into victory, right?

That's possible and probably the best thing to do. Or we could just run One update at a time and make sure everything works with every single update. I don't know how many were behind

Also if we can make honeypots for infiltrators that's be helpful

Like a download all users data button

Or a bit more subtle

Yea

It'd let us know to keep an eye on someone

That's like the screenshot notifier

We also need to get off the app

I can also do it by blocking all API calls that aren't local or from specific server

Via cloudflare rule. Browser uses sockets not api

That'd also block anyone from API raiding us, but we can also put limits on API calls I believe

Thomas will have to since I don't have access to the almighty dns settings

I am not active, but I am always reachable. Thomas can get a hold of me anytime.

Let me mock up the cloudflare rule. It's pretty easy if I remember

Victor probably did

To at least victory

I am not sure, it was a long time ago

Add all this to the list or edit it and pin it

We could test this first.

We already limited API calls to 10 a min

Just showing

But we could limit it 0 I think except for admins and bots

Which are the accounts the scripts use when doing API calls.

Yea, however, Victory probably does too

I assume auth API is allowed otherwise how could it rate limit

Does anyone know the exact API call victory uses?

When I do, someone other than me will have to test app victory.

Mobile browser should work

Victory?

I thought someone wrote a debug script and uploaded it somewhere for us

Thanks Vincent, I don't have mumble admin access

I believe we have never been exploited through a lack of a security update, not saying we shouldn't update,but rather I'd put it at the bottom of priorities esp since it has the greatest effect on server uptime

Rekeying all severs would be good though, should do that occasionally anyways

Text length includes punctuation and spaces right? I haven't ran it in a while

Okay, just to clarify so everyone knows how to use the decoder

Can you share the cryptpad with jakepf

Esp on the coasts

How could you be objective about it so you don't just have to rely on your gut? What were some flags in the interview you think

But more often then not, the gut is right.

That's a good idea, if someone is suspicious early on, get into a chat so you have their undivided attention, then ask for a screenshot like that for proof. If there is big delay or hesitation, kick em

I wonder if there are more tests like that, so we can employ them to give us more reason to be suspicious

Like we need a way to record "infractions" or something, so like last min no show needs to be reported and logged. Date and type of incident. If we see a pattern then we can be cautious

Only NDs know about it so it's invisible to normal users. But we could log lots of things. Talking about guns or violence. Asking for personal info. Etc

This stuff happens over months and it's hard to notice patterns perhaps. You don't want to create a culture of paranoia for normal members, but NDs could make it more logical in addition to gut feelings. Help catch suspicious behavior. Being active then not active at all is another sign.

@Vincent TX https://cryptpad.fr/profile/#/2/profile/view/VV4CcvDQNVXjLlh5Q+SdV3AzJ0noGtqmcaiWAy8kNzo/

For suspicious members, we could require proof of a sock account that is aligned with the views they described. Some might not have it, but in interview you could ask about sock accounts on Twitter or gab, and if they say they do,later on you ask for their handle and ask they post something unique temporarily to verify it's there's. This would only be required if you have that gut feeling and aren't sure and want more concrete proof

Same here

But I'd had said that in interview so this would not apply to me, but new guys usually do have a Twitter

No we are the good guys who have to be a step ahead

They think we're dumb, so it has to be a "secret" police vibe so they don't realize we got all sorts of redundancies

Accepted

Still says unauthorized

https://cryptpad.fr/kanban/#/2/kanban/view/u46aPYse3w0X3voyqYcLVDgqIc5P+ebBcB1Ex+Q+9Cw/

It's possible if we force web browser useage. I assume I could write a JavaScript event for it

Better add that idea to the list. It's a good one

Yes

We could also have a bot that people upload their activism photos too. And that bought doesn't even need anything special it could just be someone's job to log in as that bot and download them but it could forward it to another channel with just a few people in it who need to have access to activism. Or it could repost those images in a public channel but that way it's washed away the members who posted it if that is what we're trying to hide

I haven't seen that feature but I'll look into it

The good I'd it shows org activity which creates momentum and two it's easy since they are already in the server

Once again if it was web only we could use js to remove names

Technically the data would be there from the initial payload but it'd be harder to find

Anything with JS like that is considerably easy to implement

I think the cloudflare API rule is what I should work on

It can be tested first with the built in rate limiter in RC

@Thomas are you reenaing victory? Is there something we should look into for why we took it offline? I would like to verify blocking API calls doesn't break victory Integration

User hash decoder script is already done and pinned in this channel.

Benjamin made it and uses it

It's actually Matthew for that

Implementing a password policy would be easy. We just need to define the complexity we want. Then we need to gradually Force users to change their password. Admins can go into the user panel and individually select users to require them to change their password on their next login.

Hopefully they can use the same password that they currently use as long as it's complex enough. Probably something that should be in an announcement

These are the proposed cloudflare changes that will block any connection that has API in it that isn't coming from the victory server IP address which I don't have on hand right now. This isn't tested but if it breaks stuff we can just turn it off. Now if this works correctly people will not be able to use the app so do we need to tell everyone to get onto the browser or have we already told that to everybody

This will have to be done on both b&s.org and pf.us

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.

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

The desktop app essentially uses a browser

Correct

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

Gotcha

Victory is back up

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

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