I had to use their silly drag-and-drop email builder because I'm handing the email off to be edited by a non-dev. I dropped in a "Code" module so I could add some custom CSS but because a style tag generates no space, that module is no longer accessible via the UI as there's nothing to click on. So I thought oh brother I'll just inject a couple br tags via the Inspector and then poof, I'm in the doghouse.
Rather than it being dev tools itself, I think it's more likely that your injected <br> tags got POSTed to an API endpoint (or similar) in unescaped format, and were categorised by a WAF as attempted XSS. It's common for WAFs to block you for this kind of thing, unfortunately.
Still ridiculous, but not quite the same thing as being banned for opening dev tools (of course, I am also speculating here, I guess we'd need to hear from mailchimp to be sure).
Actually just opening the dev tools triggers it. The blacklist seems to expire on its own so I went ahead and opened the dev tools and did nothing more, reloaded, blocked.
Wow, that code is entirely unreliable. It just detects your browser's viewport being outside of some threshold of a "normal" aspect ratio and then just blindly assumes that means the devtools are open. The only devtool it can actually detect is Firebug. Everything else is nothing but a blind guess based on the size of your viewport. I'd be astonished if anyone used this code for anything serious.
… that incorrectly detects devtools as open, when it isn't (false positive), and fails to detect devtools when it is open in a separate window (false negative)…
Yeah, as other posters hint at, vertical tabs. But it isn't just vertical tabs that'll trigger it, any sidebar will, including native/vanilla ones; AFAICT it's just looking at the client area being less than the window by some threshold.
It only detects if there is a block in the browser that does not serve as website rendering. Since I use Tree Tab on side panel of Firefox, this plugin will believe I have opened devtools all the time.
Edit: it will think I closed devtools when I really open devtools. I start to wonder how shitty the code is.
Yeah I thought it would be a weird oversight on MC's part to make you jump through hoops just to insert a style tag but it completely disappeared from the UI. The effect from my CSS was still there so I know it was still on the page...somewhere.
This is worrying since I have accidently opened dev tools hundreds of times by clicking both mouse buttons when my cursor is near the bottom of the screen.
I have a tic disorder (not Tourette's, because my tics are all nonverbal). One of my tics is that I mash both mouse buttons over empty space pretty frequently. I even go out of my way to keep my cursor positioned over empty space so I can mash the mouse buttons when I need to, and it's not uncommon for me to move the cursor while mashing the buttons. If the cursor is towards the bottom of the screen, that's pretty much guaranteed to open dev tools, since all it takes is a small motion of the cursor with the right-click menu open to hit the 'Inspect' option.
This is why I despise gestural focused computing. Of all the features in any software, I think my least favorite is pull-to-refresh.
I suspect that would be easy to solve with smarter context menus that could ignore clicks likely to be accidental, since "Accidentally clicking the thing that just popped up before you even see it" is a common ish mistake worth implementing workarounds for.
>I even go out of my way to keep my cursor positioned over empty space so I can mash the mouse buttons when I need to
I have severe and sporadic clonus in my mousin' arm. I do exactly the same thing when I need to keep my hand on the mouse.
Another thing that I have done off-and-on to accomodate certain software is to have my keyboard or mouse 'toggled' off and on with an autohotkey (or equivalent) script. If I need to rest or wait for something with my hands on the hardware then I toggle the thing off with an easy-to-reach hotkey of some sort until i'm ready to actually type/mouse.
Likewise I hit F12 all the damn time because I'm aiming for the Home key, which is undersized on my keyboard, and they're right next to each other.
Great, now I need to wait 8 seconds while my browser re-renders some 40-meg page which could've been plain text.
On the other hand, if I ever think about using MailChimp to send spam, I hope someone would just come cut my hands off, then I won't need to care about hitting the wrong keys.
Reminds me of my habit of scrolling the mouse wheel above nonresponsive parts of the UI. I wore out the scrollwheel of my last mouse. Though I never thought of it as a tic, even though I have various tics myself. Doesn't open dev tools but it makes YouTube's Shorts feature absolutely unusable because the slightest scroll input will cause a switch to another video.
I regularly instruct users to open dev tools to clear their site-specific cookies because there doesn't seem to be a way of doing this without clearing _all_ cookies anymore other than in Dev Tools > Application
Not sure what browser you're referring to, but Firefox still allows you to clear site-specific cookies by clicking on the button to the left of the URL (usually a lock icon since most things are https these days)
It's incredibly easy to do on a MB pro with a touch bar if you keep the function keys visible and tap the minus key with an open and relaxed hand. I preface my notes with -- and == so I do it fairly often.
This is not true, at least in Chrome. I've tried with an object with the `toString` property set, and tried with a function with an updated prototype. In both cases, Chrome just...displays the object.
I mean, okay, I can see how they definitely have a use. But to try and auto-fetch js and css maps just because I want to have a look at the DOM?
Why not wait until I actually try looking at js/css? Or even until I ask to see the source map?
Prefetching never feels right to me. Even though I know GET requests are supposed to be side-effect free and idempotent (and if they're not, that's a choice by the server devs and they'd better have covered all the edge cases where clients correctly act as if they are...), it has the architectural equivalent of a "code smell" to my nose.
Interesting to note. In Firefox "show original sources" seems to be enabled by default but in Chrome at least the settings checkbox is labeled "Allow DevTools to load resources, such as source maps, from remote file paths. Disabled by default for security reasons" and unchecked for me. Haven't checked Safari to see what its behavior is.
Similarly, here are some techniques for debugger detection [0]. I've seen some crypto mining malware in the wild that did this to make deobfuscation more difficult.
I can only imagine the amount of security pressure they feel since they are basically a backdoor into easily stealing one or more company identities once you pass the 2FA, with full address books of customers that will trust emails deployed through MC campaigns and blindly click on links in the emails sent out, so I am guessing they err on the side of caution and have tons of false positives instead of letting anything pass through or disrupt.
Reminds me of my experiences with UnitedHealthcare’s website. If I try to log in with Firefox + uBO I get mysterious permissions errors and “something went wrong” messages for the next few hours, even after switching browsers. Use Chromium from the beginning though and it’s smooth sailing. And of course their “tech” support is beyond useless about this.
In the general case, I assume it's mostly just bad coding practices, and developers not testing how their site performs with an ad or cookie blocker active.
That's an anticompetitive move. If you need to switch senders for some reason, the inspector is the only clean way to get an email's HTML into another ESP.
An email client like Thunderbird or Mail will save a copy of the email on your local hard drive, which will include the HTML. This isn't something I do regularly, but would be first first response if I needed to see the HTML of an email. Maybe Mailchimp has protections against this route too?
Yes, it's true. You don't want all the chrome from the actual send around the body of your email because the other ESP will be providing that. You might also want to prevent certain fields and links from converting into the send versions. But in a pinch, sure, you could slice the body out of a copy in Thunderbird.
Yes it does. Say you're an agency sending email on behalf of several different organizations. If you export one to send through CampaignMonitor (usually list or domain approval related), the employee who pulled the HTML gets their hand slapped by the IP ban. It's less likely to happen next time with a different campaign or different client. I haven't actually experienced the IP ban but I've sent for the same organization through multiple ESPs without quitting one for good.
Even if you are a single organization user and leaving for good, you might do so gradually or perform test sends first. Speaking from experience again.
Wow, so this is why I've been having trouble getting Mailchimp to load lately. As a developer I often have devtools open for whatever I'm working on. If need to help out marketing with an automation or something, using the same tab, I get banned for the day.
We had to contact Mailchimp on March 7th regarding their flawed implementation of CKEditor.
To demonstrate the issue, we sent them a screencast[1] (in the video we opened dev tools).
We requested and were provided with a refund. Per my other comment on this thread. The content of the request was created using GPT (although the prompt history is not available, it can be reverse engineered).
The email sent and reply to the email are available[2].
I'm adding this comment to highlight the very reasonable fair use of opening up dev tools to try to workout what is going on.
Would be funny if it were a corporate reaction to a security researcher contacting them about some silly web API design (e.g., endpoint taking an arbitrary account ID without authorization check).
In the writeup, the researcher illustrates by copying the service URL from the browser's dev tools. And so the obvious corporate corrective action is...
Readit News
Still ridiculous, but not quite the same thing as being banned for opening dev tools (of course, I am also speculating here, I guess we'd need to hear from mailchimp to be sure).
https://github.com/sindresorhus/devtools-detect
EDIT: doesn't seem to work if I have devtools as a separate window
Yeah, as other posters hint at, vertical tabs. But it isn't just vertical tabs that'll trigger it, any sidebar will, including native/vanilla ones; AFAICT it's just looking at the client area being less than the window by some threshold.
It only detects if there is a block in the browser that does not serve as website rendering. Since I use Tree Tab on side panel of Firefox, this plugin will believe I have opened devtools all the time.
Edit: it will think I closed devtools when I really open devtools. I start to wonder how shitty the code is.
I have a tic disorder (not Tourette's, because my tics are all nonverbal). One of my tics is that I mash both mouse buttons over empty space pretty frequently. I even go out of my way to keep my cursor positioned over empty space so I can mash the mouse buttons when I need to, and it's not uncommon for me to move the cursor while mashing the buttons. If the cursor is towards the bottom of the screen, that's pretty much guaranteed to open dev tools, since all it takes is a small motion of the cursor with the right-click menu open to hit the 'Inspect' option.
I suspect that would be easy to solve with smarter context menus that could ignore clicks likely to be accidental, since "Accidentally clicking the thing that just popped up before you even see it" is a common ish mistake worth implementing workarounds for.
I have severe and sporadic clonus in my mousin' arm. I do exactly the same thing when I need to keep my hand on the mouse.
Another thing that I have done off-and-on to accomodate certain software is to have my keyboard or mouse 'toggled' off and on with an autohotkey (or equivalent) script. If I need to rest or wait for something with my hands on the hardware then I toggle the thing off with an easy-to-reach hotkey of some sort until i'm ready to actually type/mouse.
Great, now I need to wait 8 seconds while my browser re-renders some 40-meg page which could've been plain text.
On the other hand, if I ever think about using MailChimp to send spam, I hope someone would just come cut my hands off, then I won't need to care about hitting the wrong keys.
* The copy command for many terminal apps on linux
Deleted Comment
That's still Tourette's. Tourette's is described as an involuntary movement /or/ sound.
> It is characterized by multiple movement (motor) tics and at least one vocal (phonic) tic.
> Tourette's is at the more severe end of a spectrum of tic disorders.
EDIT: “vocal,” I should say, not “verbal”
Very simple for a system to detect the request for the map file.
If that's their vector turn off the autoloader and try from a clean IP.
Edit: You can redefine console.log to be a noop, but that's also detectable.
...and how to disable them from auto-loading.
I mean, okay, I can see how they definitely have a use. But to try and auto-fetch js and css maps just because I want to have a look at the DOM?
Why not wait until I actually try looking at js/css? Or even until I ask to see the source map?
Prefetching never feels right to me. Even though I know GET requests are supposed to be side-effect free and idempotent (and if they're not, that's a choice by the server devs and they'd better have covered all the edge cases where clients correctly act as if they are...), it has the architectural equivalent of a "code smell" to my nose.
Dead Comment
Could yours be a Windows Group Policy from $WORK?
[0] https://x-c3ll.github.io/posts/javascript-antidebugging/
The source map requests was a more successful option. Also played around with "snap" resize but it was too agressive.
As for whatever the reason MailChimp would block your up is pretty ridiculous.
The part I do not understand is even websites that verify you via 2FA do this, so I assume their goal is to track you no matter what.
An email client like Thunderbird or Mail will save a copy of the email on your local hard drive, which will include the HTML. This isn't something I do regularly, but would be first first response if I needed to see the HTML of an email. Maybe Mailchimp has protections against this route too?
Even if you are a single organization user and leaving for good, you might do so gradually or perform test sends first. Speaking from experience again.
We had to contact Mailchimp on March 7th regarding their flawed implementation of CKEditor.
To demonstrate the issue, we sent them a screencast[1] (in the video we opened dev tools).
We requested and were provided with a refund. Per my other comment on this thread. The content of the request was created using GPT (although the prompt history is not available, it can be reverse engineered).
The email sent and reply to the email are available[2].
I'm adding this comment to highlight the very reasonable fair use of opening up dev tools to try to workout what is going on.
[1] https://files.littlebird.com.au/Screen-Recording-2023-03-08-...
[2] https://files.littlebird.com.au/Screen-Shot-2023-03-21-at-8....
In the writeup, the researcher illustrates by copying the service URL from the browser's dev tools. And so the obvious corporate corrective action is...