No.6367
File: 1579400643508.jpg (121.52 KB, 800x700, 8:7, 80a796e95bdabea6b78bb4ef0a….jpg) ImgOps Exif Google
New thread for discussing the issues in the transparency report.
No.6368
File: 1579400881641.jpg (95.98 KB, 917x960, 917:960, reloading.jpg) ImgOps Exif Google
>>6367what happened with the previous one?
No.6371
File: 1579401939025.png (177.23 KB, 811x986, 811:986, 9b6803d13382a3d3a0760663e0….png) ImgOps Google
Well, i wonder if todays escapade will change anyone's answers.
No.6372
File: 1579402551413.jpg (149.52 KB, 1024x577, 1024:577, m_7.jpg) ImgOps Exif Google
>>6371This only made me realize how vulnerable the boards can be. Only an anonimous could mess with an entire one.
No.6373
File: 1579402625126.png (541.52 KB, 674x976, 337:488, EOab1rDX4AID57R.png) ImgOps Google
>>6369>alguien lo borro con un ataque de flood.my reaction:
https://youtu.be/rzxPdwQX7bII see
2 hours ago I decided to play Dragon Quest XI and when I returned there was a 404 not found.
but Ok
No.6375
File: 1579408612039.png (894.53 KB, 1268x2307, 1268:2307, 98b822fc286035a4fc4748eeee….png) ImgOps Google
Yeah, guys, even if you might not like any potential changes to the site meant to combat ban-evasions and raids like this, we can't let the ban-evaders take control of the staff and power trip all over them and us.
No.6376
File: 1579409660643.jpg (132.83 KB, 849x768, 283:256, White_lipped_tree_frog_cai….jpg) ImgOps Exif Google
What happened to /canterlot/? Can you restore from backup?
Well, I guess the question about needing to implement more extreme technological enforcement mechanisms for bans is now answered. (I guess you could also go the legal route and pursue CFAA charges, but the wheels of justice move very slowly, so that's probably not a viable option, at least for the short term.)
No.6378
File: 1579413250099.png (142.98 KB, 860x1104, 215:276, 163-1636405_transparent-to….png) ImgOps Google
>>6377My proposal to make ponyville real was a very important thread to have lost. Maybe we can save that one.
No.6379
File: 1579439095732.jpg (46.74 KB, 424x810, 212:405, tumblr_q48cuvwZPM1yr2rayo1….jpg) ImgOps Exif Google
i guess i wasn't around for whatever the heck happened
don't really see why we need to make any of the drastic changes to how the site works
i voted 1 on every single one of those
making this site harder to use will most definitely make me less likely to use it
im only using it not because all it takes is me typing out a post and applying an image. anything else ruins the site for me.
anyways, whatever.
No.6380
File: 1579448658171.jpg (549.61 KB, 1200x900, 4:3, 1452140829927.jpg) ImgOps Exif Google
>>6379>i guess i wasn't around for whatever the heck happenedSomeone apparently raided /catnerlot/ with spam.
>making this site harder to useSome of the options wouldn't make the site any harder to use for users, even if none of {IP address, tripcode, password for file deletion} are recognized. It would just delay their posts until a mod approves.
No.6381
File: 1579449410021.jpg (149.52 KB, 1024x577, 1024:577, m_7.jpg) ImgOps Exif Google
>>6380> It would just delay their posts until a mod approves.It might discourage new-comers.
Edit: And might push the mods.
No.6383
File: 1579449974172.jpg (19.62 KB, 480x480, 1:1, s_3.jpg) ImgOps Exif Google
Yes, we should not forget that this community targets people who are/ have been on IB's, people that probably are not accustomed to get their post delayed by mod-approval.
>>6382
Don't you like new friends?
No.6385
File: 1579450479975.jpg (7.26 KB, 272x185, 272:185, s_5.jpg) ImgOps Exif Google
>>6384
Neat.
No.6387
File: 1579450755953.jpg (36.85 KB, 330x371, 330:371, s_27.jpg) ImgOps Exif Google
>>6386
No.6388
File: 1579459902701.png (277.56 KB, 900x900, 1:1, ab1c72772bb6c4c2a69059bcbb….png) ImgOps Google
>>6379Basically LeAnon and Fleur effectively deleted canterlot and spammed the place with neo-nazi stuff and ban-evasion was a key part of that.
No.6390
File: 1579460816567.jpg (65.63 KB, 628x800, 157:200, 2a328d7e50cb6f863ccf0d2884….jpg) ImgOps Exif Google
>>6389
Whatever, just bring back Sweetie Belle, she's far more tolerable than you.
No.6393
File: 1579472491570.png (167.9 KB, 887x607, 887:607, 1459627604784.png) ImgOps Google
>>6388I propose an idea: Maybe there should be a per-board limit of many new threads can be created (and how many ancient threads can be bumped) in any 24-hour window. Mods would be able to approve threads so that they don't count towards the limit. And this limit would be for all users combined, not per user. /canterlot/ and /townhall/ never get more than a full page of threads in a single day unless they're being raided/spammed.
No.6394
File: 1579477501499.jpg (4.93 MB, 4160x3120, 4:3, 20200118_164858.jpg) ImgOps Exif Google
>>6393These werent new threads but necro bumps.
Doing nothing is best. Letting the children have their fun is better than complicating everything we do. Making mods do approval work is a dead-end solution that only lets the tail wag the dog.
No.6396
File: 1579492525727.jpg (1.12 MB, 1536x2048, 3:4, chibi_shy_by_ptcrow-d89ooo….jpg) ImgOps Exif Google
>>6394>These werent new threads but necro bumps.OK, but how does that relate to my post? I specifically said:
>(and how many ancient threads can be bumped)>Making mods do approval workThe limits would be high enough that it would entail no additional work for the mods in 99%+ of the time. The ability to manually approve threads would only needed to be used in rare situations where users make an exceedingly large number of legitimate threads.
No.6397
>>6396I dont want to be rude but, telling you that your proposed method would not have affected the current situation is how it relates to your post. (Edit: plus it wouldnt work anyway cuz they can just switch ip and keep creating threads)
There simply is no securing the site against raiders because there will always be a hole for them to exploit.
Eroding our own usability will accomplish the raiders' goals without them even having to use effort attacking us.
It's a lose/lose.
No.6398
File: 1579564181392.png (75.85 KB, 200x200, 1:1, o_fl_070827.png) ImgOps Google
>>6397>telling you that your proposed method would not have affected the current situation is how it relates to your post. (Edit: plus it wouldnt work anyway cuz they can just switch ip and keep creating threads)OK, you're misunderstanding my post. Please read
>>6393 again, very carefully:
>per-board limit of many new threads can be created (and how many ancient threads can be bumped) in any 24-hour window.>And this limit would be for all users combined, not per user.In my proposal, no more than
N threads could be created or necrobumped on a given board in any 24-hour period. It's not
N threads per IP address; it's
N threads total. So one IP makes 5 threads, then another IP can make at most
N-5 threads.
>>6394>These werent new threads but necro bumps.Are you sure about that? Why would the threads have been completely deleted if they were just necrobumped? If I had to guess, I would guess that there were BOTH necrobumps AND new threads spammed.
No.6399
File: 1579599097794.png (38 KB, 220x220, 1:1, Applejack_looking_stern_S0….png) ImgOps Google
>>6398No, i understood your algorythm. It would provide a new means of attacking the site by the attacker producing N new threads causing every legitimate new thread to wait for a mod to approve it.
Supporting my point: its futile to try and out-think the criminal mind.
If they want to attack us, then at least lets not do their work for them by adding barriers to our own use of our site.
I don't intend to say that you are wrong, only express my opinion. I hope i am not being rude.
No.6400
File: 1579614083954.jpg (46.64 KB, 370x490, 37:49, medli-add912b8d63b36bf0bfc….jpg) ImgOps Exif Google
>>6399> It would provide a new means of attacking the site by the attacker producing N new threads causing every legitimate new thread to wait for a mod to approve it.It's true that an attacker would be able to prevent the creation of new legitimate threads until the mods delete their spam threads. But this is a weaker attack than being able to spam the whole board to the point where all legit threads are pushed off the end of Page 10.
(I didn't mention explicitly, but deleting a thread would also remove it from the limit. Conceptually, the database query would be something like "select count(*) from Threads where BoardID=$BoardID and LastBumpTime > ${CurrentTime - 7*24*60*60} and not IsModApproved and not IsDeleted".)
No.6401
File: 1579615091260.png (10.58 KB, 325x298, 325:298, moa-zelda.png) ImgOps Google
>>6400Actually, that query doesn't perfectly capture my proposal, but I think it's close enough. But on second thought, the "ModApproval" field should be a time-stamp rather than a bool, and only threads approved in the last week or so should be excluded from count, to prevent a previously-approved thread from being later necrobumped.
No.6408
>>6405If this is true then how many posts per day are deleted really is a "transparency" issue.
In which case i think we should have that information.
>>6404Not all. Im still here.
No.6410
File: 1581136676239.png (157.54 KB, 435x360, 29:24, you are a wonderful pony.png) ImgOps Google
>>6405at present, the site is whisper quiet on the spam front, and has been since that one burst of activity
we haven't even had a report in the past week!
that said, history can and will repeat itself if we are not careful, and the staff is still intent on implementing a solution that the userbase approves of
No.6411
File: 1581182197097.png (24.87 KB, 259x189, 37:27, 1569320966696.png) ImgOps Google
>>6410I'm enjoying the lack of complaints from the few.
No.6762
File: 1594097898011.png (325.88 KB, 1280x720, 16:9, loli-platelet.png) ImgOps Google
Maybe it is time to unsticky this thread?
No.6763
File: 1594190166004.png (13.08 KB, 179x321, 179:321, lola96.png) ImgOps Google
>>6762The problem with that is that cute raridash image wouldn't be greeting you every time you come to canterlot.
