kheina-com / blue-blocker Goto Github PK
View Code? Open in Web Editor NEWBlocks all Twitter Blue verified users on twitter.com
License: Mozilla Public License 2.0
Blocks all Twitter Blue verified users on twitter.com
License: Mozilla Public License 2.0
It'd be nice to be able to see the accounts the extension has blocked in the event you did not see the pop-up for any given reason, to confirm it's working as intended.
Great addition injecting notifications of users being blocked, however it can be a bit disruptive for some people so I'd like an option to not display those popups. This should be pretty easily done by adding another checkbox.
I think the one on chrome (forgot the name of it) has this feature but this one works on firefox. It has everything i need except for the ability to only mute blue users instead of blocking
Being able to run this on search results directly would allow a user to deploy a 'worldcode' script such as '-filter:verified filter:blue_verified filter:replies' to block substantially all verified accounts. [This sounds like a good thing to empower]. The script used here https://gist.github.com/adalinesimonian/b52a753c9fd6c176598745df01ba12dc accomplishes this in a direct manner, but without this addon's flexibility; between the most recent popover method and the machinegun method used earlier this week, there's a strong synergy with this extension.
Please build in support for mobile.twitter.com. I primarily use the mobile site via Firefox Nightly, and would love to use the extension to block Twitter Blue users on the go.
Not sure if this is more difficult to impliment, but it would sure be nice. 90% of them are clearly algorithmically generated resale scams.
This could be a good option to prevent overblocking:
"skip users followed by users I follow"
If possible also add an option to define the number of followers:
"skip users followed by [n] users I follow"
Currently, queue consumer is only started when a request is received and a new user is added to the block queue. however, now that the block queue is stored in localstorage, it's possible for the queue to be populated on initial load
From https://extensionworkshop.com/documentation/publish/distribute-manifest-versions/:
It is not possible to create a version of an extension that is MV2- and MV3-compatible. Therefore, you need a way of distributing both types of extension if you need to continue supporting older clients, such as Firefox ESR. (Firefox ESR 102.x, the extended support release for enterprises – large companies and organizations – is supported until September 2023, when the ESR release moves to a version supporting MV3).
Would it be possible for Blue Blocker to support MV2 until September? I know it's a bit of an ask but Debian Stable for example which is releasing soon will be stuck with MV2 until September at least.
there is a continuing issue where users get signed out, regardless of queue interval, it just happens sometimes. This is acceptable, but just detect when the user is signed out so that the queue will stop processing and not send useless requests
On my firefox install, it's cleared roughly 1600 blue checks, but there are 2 that it cant clear. The queue frequently drops to 1 then pops back up to 2. I suspect it is trying to block someone and failing, but that means its constantly pinging twitter.
I'd like the ability to view the queue so I can identify the problem accounts, and the ability to either manually remove accounts from the queue (or maybe clear the queue), or have the extension stop trying to block an account after a number of attenpts then remove them from the queue.
I ran into an issue where I was having a queue of blocks processing when I was logged out (probably block rate limiting), but when I logged back in and tried to kick it off again, all blocks that were trying to process were returning 403 errors, the body of the response being that the CSRF header didn't match.
(I'm going to note in advance that I'm in that zone here of "knows enough to be dangerous", so, apologies if I've missed something about how this works and my theories are a little bunk.)
From the investigation I was able to do, what I think happened is that the blocks were queued with the header block from one session, including the CSRF token, but after signing back in, processing started again sending those requests using the cached but now invalid CSRF token.
(My investigation here was a little limited because I'm kinda wary about letting the thing just keep flying sending invalid block requests.)
I was able to get blocking working again by removing and reinstalling the extension in chrome, which suggests to me that I probably could have also let it send however many failed block requests and it'd eventually come back to me. However, there might need to be some sort of recovery here that doesn't require refreshing the extension or having to wait for the queue to stream out all the doomed requests, like a manual button for clearing the queue, something that watches the return of the block requests firing to handle when errors start happening, etc.
Instead of just hiding like the ad blockers do, actually block the account when a promoted ad is shown. This should, of course, be an option, probably opt-in.
Twitter is returning legacy checkmarks on certain users (threshold unknown) and purposely labelled it as Twitter Blue.
An article relevant to this issue can be found here as many celebrities are trying to remove their checkmarks: https://www.avclub.com/celebrities-now-working-to-remove-their-apparently-mand-1850366148
However, using filter:verified and filter:verified_blue still works to differentiate legacy checkmarks and Twitter Blue checkmarks. Evidence: Maybe this can be used to differentiate legacy and blue checkmarks.
Steps to reproduce:
Tested using: Firefox extension
this is due to default value returned for BlockQueue
being 0
and not []
https://github.com/kheina-com/Blue-Blocker/blob/main/firefox/options.js#L16
https://github.com/kheina-com/Blue-Blocker/blob/main/chrome/options.js#L16
It blocks people with NFT avatars, which is not disclosed in the title or description. This should be either a separate option or a separate plugin.
Is there anyway this problem can be mitigated? I don't mind just logging back in again but a lot of users will probably find this off putting. I know the extension already has a queue system, so maybe it can be improved to reduce the likely hood that Twitter will log you out.
Sometimes this extension makes a mistake and blocks (or in my case, mutes) accounts that I'd already unblocked/unmuted previously. I would like for this extension to remember unblocks/unmutes and then remember to not block/mute them again if it encounters them again (or, if this is already supposed to be how the extension behaves, it should be documented more clearly)
Apparently if you put the words "blue check" in your profile comment, you can restore your legacy blue check without paying for Twitter Blue: https://twitter.com/kenklippenstein/status/1653084206631714816
I have seen several other accounts saying this as well. It might only be for accounts that previously had a legacy blue check, though? (I'm unable to test for myself to verify, though, since Twitter doesn't want to seem to save any edits I make to my profile lately...)
I just got a really stupid idea and honestly I don't even know if it would work, but I want to look into it.
instead of creating a mock ui request manually via ajax and formdata, would it be possible to use css and/or xpath selectors to find the tweet on page and mock a click on the ui element that performs the block normally?
this way the built in frontend would be handling everything for us in terms of removing elements from the dom, authentication, request building, etc, etc.
main issue with this would be what if the user has navigated away from the page containing the tweet and/or user that actually displays the block button? in this case we would fall back to the previous logic of using ajax and formdata, but it would force us to maintain more bullshit.
https://gist.github.com/adalinesimonian/b52a753c9fd6c176598745df01ba12dc
Boundary case where queued accounts are suspended prior to blocking do not clear resulting in repeated bad requests and lockout. More probable issue if backlog is allowed to build over time or as more users are blocked (user will eventually add someone who is suspended inside the time between queueing and blocking).
Add a popup element on twitter to show recently blocked users, add an undo button that unblocks or unmutes the user and adds them to an allowed list persisted in api.storage.sync (or maybe a proper database? idk if addons have those)
would be nice to have the block queue size in this log:
[Blue Blocker] blocked [user](@[handle]) due to Twitter Blue verified.
if too inconvenient i can take a whack at it after work
a nice bit of double punishment would be the ability to add all blue ticks to a user-predefined list (let's call it "Blue Tick Scum", for example) so they get a notification that's happened. They can have their piss boiled for a few days before I switch your main extension back on and actually block them.
pretty please
A bug or an overload issue causing account to log out and reset display to the default white screen. I don't know if it's random or caused by too many accounts being blocked/queued at the same time.
If you open up a twitter link from somewhere the plugin won't parse and block the first few replies that are loaded when you open the link.
It's nice to block blue users but also I have found it helpful to block any account that is advertising on twitter. Would there be any interest in adding this?
I scrolled through the comments on a Musk tweet to test the extension with the console open and the success rate was around 20%. It appears that the block event is more consistent by visiting the users profile and then opening a tweet or sometimes two.
The log message for blocks is also always blocked USER (@USER) due to NFT avatar.
regardless if they actually do have an NFT avatar or not.
Says it all. Companies are getting around the blue block by being gold.
Would it be possible to include what exactly these switches do? Either in the readme or as a hover tooltip in the extension window?
this should allow the repo to be much more linear, merging the firefox and chrome folders and reducing the need to have separate codebases for each platform. it may also mean being able to remove the second manifest entirely and using a single shared manifest.
when a normal block occurs through the UI, the tweet blocked as well as all tweets in the timeline or comments are removed from the page. this logic should be duplicated in the addon, wherever possible
adding this here for posterity, Blue Blocker does not currently support this, but should be able to work fine in conjunction with https://github.com/BlueLiteBlocker/BlueLiteBlocker, though I have not personally tested it
Sorry, I don't know what the reason is.
But when I add this extension to my Firefox, it doesn't work to start with. If I pin the extension icon, it gets a blue dot and a tooltip saying I need to grant permissions. If I go to manage this specific extension, and go to permissions, the permissions for twitter.com are not enabled. Enabling these permissions then lets the extension work as expected.
I might have previously installed and then removed the extension. Maybe that caused it?
I noticed that, when browsing through https://tweetdeck.twitter.com, users are being queued properly, but the block call fails consistently and the users remain queued.
If I switch to https://twitter.com, then those queued users are blocked correctly.
I do see errors in the console, but nothing in the error message indicates what exactly failed although I suspect it's a cross-domain problem.
[Blue Blocker] error:
error { target: XMLHttpRequest, isTrusted: true, lengthComputable: false, loaded: 0, total: 0, srcElement: XMLHttpRequest, currentTarget: XMLHttpRequest, eventPhase: 2, bubbles: false, cancelable: false, … }
bubbles: false
cancelBubble: false
cancelable: false
composed: false
currentTarget: null
defaultPrevented: false
eventPhase: 0
explicitOriginalTarget: XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, … }
isTrusted: true
lengthComputable: false
loaded: 0
originalTarget: XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, … }
returnValue: true
srcElement: XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, … }
target: XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, … }
timeStamp: 0
total: 0
type: "error"
<get isTrusted()>: function isTrusted()
<prototype>: ProgressEventPrototype { lengthComputable: Getter, loaded: Getter, total: Getter, … }
[shared.js:178:11](moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/shared.js)
BlockUser moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/shared.js:178
(Async: EventListener.handleEvent)
BlockUser moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/shared.js:177
CheckBlockQueue moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/shared.js:142
(Async: promise callback)
CheckBlockQueue moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/shared.js:136
(Async: setTimeout handler)
sync moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/models/queue_consumer.js:55
_timeout moz-extension://978c7cc8-6d56-437c-9a99-3bb5693eac96/models/queue_consumer.js:52
If you have the "skip users with 1M+ followers" option enabled and come across a blue user with 0 followers, the console will log an exception for them erroneously indicating they have 1M+ followers.
This is possibly due to this part of shared.js:
options.skip1Mplus && (user.legacy.followers_count > 1000000 || !user.legacy.followers_count)
I'm not sure what was intended by the last part of that expression (check for undefined value maybe?). But in JavaScript, !0
evaluates to true.
As the logic is set up now, every tab will have it's own consumer, basically increasing the speed with which the queue is consumed by the number of twitter tabs the user has open. this is fine for an MVP, but will likely hit the rate limiter if the user doesn't know this is happening (most users)
eventually, the tabs will need to communicate between each other to select a single tab to consume the queue. if that tab is closed or crashed, another tab should begin consuming the queue
not sure what's causing this, but I've seen it a couple times.
Enabling an autoscroll would speed up loading names into the queue and prevent issues where threadloading stalls in cases where threads aren't being actively refreshed. I use a macro that jams the spacebar down because I'm both very dumb and very lazy, and it works for me. But I know a lot of people who are either dumber or lazier than me, and this would be helpful for them while also increasing automation by a large factor.
Sequential scrolling by x /<200 pixels has a couple edge cases with frustrating outcomes - when ads obstruct certain ranges of the page, and near the bottom of a thread but before it loads new tweets: persistent scroll overcomes these cases consistently.
For a couple reasons it may be preferable to both block AND mute.
Personally the only insufferable stuff I'd actually want to block comes from accounts with subatomic follower counts being pushed to the top of the replies. There's this list of Twitter Blue subscribers with <2000 followers but it's 4 months old which makes it largely useless to me.
Since there's already an optional check for accounts with >1M followers, could another optional check be added to only block accounts under a custom number of followers?
Hasn't been an update in some time. @DanielleMiu let us know if you're still maintaining this...
Notifications are annoying because they take up way to much space, but I've adapted to them. It'd be better if it had a size/placement option.
from https://addons.mozilla.org/en-US/firefox/addon/blue-blocker/reviews/1958673/
It would be great to have a button to pause collecting new usernames while still letting the queue run. Some blue checks are more annoying than others, and it would be nice to be able to fill up a queue in search and then go back to my timeline without adding unintentional blocks.
#10 made it so users who are to be blocked get added to a queue and then each user in the queue is blocked in 5 second intervals. This is to avoid being signed out by the API, however I find 5 seconds is a bit too long, especially on threads with many blue verified users.
In my testing even lowering it to 1.5 seconds prevented the sign out most of the time, however I think it would be better to just have this interval be configurable.
Alternatively the 5 second interval would not be as bad if the queue was stored independent of the page, so as a user is navigating around Twitter the queue will continue to be processed in the background, but I think this might be more difficult to implement.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.