We’re excited to share something We’ve been working on for a while and it’s called:
ShadowContact a smart, lightweight Bric that lets you publish beautiful clickable email, phone, and WhatsApp links without feeding the spam harvesters.
We all know the pain: you launch a new site, put your email or phone in the footer or contact section, and within hours you start getting flooded with spam. It’s frustrating and time-consuming.
Shadow Contact solves this elegantly using a token system. You simply place something like [obscure-email] or [obscure-studio] in any text, heading, or button. On the live website, the Bric instantly replaces it with a real, working link while your actual contact details never appear in the HTML source code.
We just bumped ShadowContact to V1.0.1 with a cool new feature
What’s New in Version 1.0.1
Version 1.0.1 adds a fourth contact type — Text — which allows you to obfuscate any plain text content on your page, not just contact links. This is useful for protecting sensitive information such as bank account details, IBAN numbers, addresses, VAT numbers, membership codes, or any other data you want to keep out of your HTML source.
If you have purchased ShadowContact already this new version will show up in the Blocs Extension Manager updater.
Read the thread, product page, marketing verbiage, manual and Gumroad page…
Honestly thats a vast task. So forgive me for bringing it up, but …
Modern scrapers can load a page in headless Chrome, inspect the JS file and run JavaScript, easily decode Base64, wait for JS to execute, read the rendered DOM and extract that which is generated. Reading all you have written about this Bric, it seems that it’s only for more basic protection, not for ALL modern bots, scrappers and of course not against more manual harvesting.
Those realities regarding actual security should be understood, which seems pertinent when presenting capabilities, without encouraging a false sense of security. Maybe a more responsible depiction would be “Reduces harvesting by simple bots and basic scrapers. Does not prevent collection by advanced crawlers or determined attackers”, because Stop and Reduce are two entirely different aspects regarding security.
If the browser can reconstruct things, then a capable automated scraper can reconstruct it too. It may prevent some weaker bots inherently due to speed vs volume which harvesters prefer but it doesn’t sound like it provides strong technical protection against a broader range of bots and scrappers. It seems to provide protection mostly against low effort harvesting, not against modern bot operators. Though it appears the Bric seems advertised — as broad overall protection verse bots, scrappers and harvesting.
Perhaps you can express further overall or make some clarifications. Because the stronger the claims, the more responsibility there is to explain the limits. Just concerned people will have a false sense of actual security being provided, verse what users should realistically expect concerning security.
I find your observations pertinent, and it’s a topic that deserves further exploration, but you’re also contributing to the confusion, and it’s better to provide clarification.
I think you have a very elegant way of questioning the seriousness of a developer; perhaps that’s superfluous.
The level of protection offered is adequate and proportionate to the type of sites that can be built with blocs, and it’s a widely used standard in other environments as well.
The 64-bit technique works. A bank would probably equip itself with different systems, but for the average user, it’s sufficient protection for their environment.
Your considerations on the product definitions help us understand that this product is actually suitable and its cost is a real response to the needs of users of this ecosystem and this does not mean that there will be no other updates that other major security systems will offer, but in that case the product will also cost more.
While I respect your response and the developer whom made it, I stand by the factual points already expressed on the topic and thus disagree with some of your assertions. However, I’ll just let the context solely as expressed in my original post offer the developer and users some things to consider and see no need to defend my comments further, those interested can easily research these topics to gain broader understanding.
Thank you for the detailed read-through and for sharing your thoughts. I appreciate people who engage seriously with the topic.
You’re right that no client-side solution offers absolute protection against every possible scraper, particularly advanced ones using headless browsers that fully execute JavaScript and inspect the rendered DOM. We’ve never claimed ShadowContact is an impenetrable enterprise-grade system. That would be misleading.
What it does provide, very effectively, is clean, practical protection against the overwhelming majority of spam bots that actually hit typical websites: the simple crawlers scanning raw HTML for mailto:, phone numbers, and obvious patterns. By keeping real contact details completely out of the source code and injecting them only client-side through tokens, it stops the low-to-mid effort harvesters that cause most of the daily frustration. This is exactly the problem we solved for Blocs users, and it works very well in real-world conditions.
For those needing stronger protection (especially on forms), we’ve also built TurnGuard, a dedicated Bric that seamlessly integrates Cloudflare Turnstile (a modern, privacy-friendly CAPTCHA alternative). It’s available in the Blocs Store as well.
Security is a spectrum. ShadowContact sits at the right point on that spectrum for most Blocs-built sites: lightweight, fast, elegant, and highly effective without adding bloat or dependencies. We stand behind it fully.
That said, I consider this discussion closed. We’ve clarified the intent and capabilities, and I’d rather focus on building useful tools than debating theoretical edge cases indefinitely. Users who want to evaluate it for themselves can read the public manual.
Thanks again to everyone who contributed to the thread. Happy building!
Tip: If you add multiple instances to your page and don’t want them all to have the same styling simply wrap the [obscure-token] in a Span and add any class.
Just to give some context on how fast we move for our Bric buyers: @PBH dropped the bug report at 1 AM, we jumped on it by 6 AM (still before our first coffee ), and by 9 AM the fix was already live with an update pushed out.
That’s how we say thank you to our fans who help us make Bric better.
Breakfast was optional this morning but fixing it for you wasn’t!
)
here
Tip: If you add multiple instances to your page and don’t want them all to have the same styling simply wrap the [obscure-token] in a Span and add any class.
), and by 9 AM the fix was already live with an update pushed out.
but fixing it for you wasn’t! 