They don't. The form markup Marketo emits might have been acceptable a decade ago. Today it's primitive and forestalls you from using any of several currently acceptable approaches to form design (you can't even set a placeholder attribute, fer cryin outloud, let alone add a classname or data-attribute your site design would like to see) no matter how you edit the CSS. And the hooks in the CSS are too limited to let you fit it into a site design of any size or complexity without spending a lot of time developing, debugging, and maintaining two completely separate codebases. The Marketo form tools smack of either arrogance ("You will use only the subset of classes and valid HTML attributes that we deign proper for you to use") or incompetence ("We couldn't figure out how to concatenate strings so you can't add your own class names or attributes"). Responsive, Bootstrap-enhanced landing pages -- "Yes!" says Marketo. But perish the thought they actually let you use a form design that integrates well and cleanly into your site design, especially if the site design is built on Bootstrap! Let that sink in. There really is no good way to build a form using Bootstrap for your Bootstrap-based Marketo landing page. And that's been known for years, yet nothing has been done, despite the fact most open source CMS's and frameworks solved that problem long ago, so the code is right there, available for study.
BTW, both Google's original reCAPTCHA and the follow-on NoCAPTCHA reCAPTCHA have been solved by some spam bots (https://www.shieldsquare.com/sorry-google-captcha-recaptcha-doesnt-stop-bots/). The latest entry in the field, the invisible reCAPTCHA currently works, I hear, but I'm wondering about its long-term viability.
Arlen, there's no better solution on the client side than these technologies. If you want to pass data through your own server, you of course may. But then you'll have created a brand-new DoS vulnerability, since all the API endpoints you could use to push leads into Marketo are rate-limited -- hardly an improvement if your resources are in fact under strain.
Even if you're right, client-side controls always have the potentially fatal flaw that the client is actually in the control of The Other Guy, not me. No mater what, that is the card that trumps all. It's why I think all client-side solutions are ultimately doomed, even if they enjoy a short period of effectiveness. The alternatives are participate in a client-side arms race, or move your prevention measures to the server side.
All sites have a DoS vulnerability, whether it's on the processing end of the form, or on the end serving up the link that sends people to the form. It's a fact of life on the web, and there's a common body of practices available to limit its effects. I'm not concerned with the computer resources; I'm concerned with saving the time and effort the human resources around me are expending dealing with the mess created by polluting the leads with the rest of the crap. The easiest, most efficient way to clean up a database is to not let it get dirty in the first place, and if spending a few computer cycles can help with that, it's worth the trade.
That's why it's worth exploring the API Marketo has for remotely inserting leads. I'm not trying to save on computer resources; I'm trying to get the computer to do the drudgery it's so good at so our people have more time to do what *they're* good at.
Interesting. Marketo's board sensor has the effect of making me sound more foul-mouthed than I am. Note the word it deemed too bad to be allowed was a four letter term that begins with 'c' and ends with a three-letter name for a style of music. Dictionary.com doesn't even call it slang when used in the manner I was using it (meaning #3, if you're playing along at home).
I wonder if crud would have fared better?
I'm pretty sure you're not aware of the limits in question.
A maximum of 30,000 form posts per day can be gatewayed from a remote server to Marketo using the API. 30K total.
A maximum of 43,200 form posts per day *per source IP address* can be forwarded from browser clients to Marketo. 100 source IPs: 4 million form posts.
So this is not a question to be waved away with "all resources are finite." It's many orders of magnitude of difference in the real-world resilience of two services: one that can be quenched by one end user over a 14.4 modem in half an hour, the other that would require sustained, distributed abuse.
Have you used ReCAPTCHA with Marketo, or are you just deciding it won't help because of an old blog post?
Interesting. Marketo says I get 50K API calls per day, each call allowed to insert a max of 300 leads per call (Marketo's REST API documentation is my source for that; I haven't tested those limits so if Marketo is lying to me about it then the rest of the math here isn't applicable). My math says that means I can insert a hard upper limit of 15 million or so leads per day (if I can manage that with a limit of 5 calls per second). If we allow for an overhead of as many as 4 calls per insertion, that still equates to a little under 4 million leads per day. I doubt our end-user with a 14.4 modem can submit that many leads that would pass our validity checks in half an hour. But let's say he can, that's not the only tool in the box: If aside from checking the validity, we rate limit to one contact form submission from a particular user every 20 seconds or so, our single user (oh, give him a full-bandwidth pipe instead of a 14.4 modem) gets to use up about 50K leads per day, leaving plenty of room for the rest of the world.
Or were you assuming I was going to make my server pretend to be a browser submitting a form?
By having the lead form post to our server, and not Marketo, we can not only control for the validity of the leads going to Marketo, but we can control the size of the batches and how frequently we update Marketo. Side effect: If we generate a spectacular amount of interest, we can buffer the leads accumulated on our end and send them in as rate limitations allow. So if for some reason we generate more than a few million leads in a day (or a stretch of days) we could buffer them on our end, and get them in to Marketo when time, and rate limitations, permit. Admittedly, if that keeps up for a long stretch of time it can become worrisome. But if that's the case we'll be making enough in profits to cover more drastic, and expensive, approaches. Anyway, we're still looking at it as a possibility; we'll have to do some serious tire-kicking (read: code writing) before we head in that direction.
I haven't used the reCAPTCHA with Marketo for two main reasons. First, I don't use the Marketo forms designer because we have not been able to consistently (that's probably an understatement; I don't think she's passed even one of them) produce forms that pass our designer's standards using it. And second, I don't like arms races; I prefer not to play. Google has twice already revamped reCAPTCHA, so I suspect I'm not alone in mistrusting it as a long term solution (though I'll admit to being a little fascinated by their current 'invisible' approach, and wondering how it'll work out with mobile and assistive tech users and other fringe cases). Hence my focus on server-side controls.
Anyway, this has now gone way far afield from the original topic. My fault, my apologies. It was not my intention, but the right buttons were pressed, and I gave in.
(And there's some supreme nonsense in that blog post, too. Note the POC link has been taken down.)
We're still trying to understand the same thing - and how to remove these leads from our instance. While working in RCE, we came across hundreds of malicious form injects. Not sure how old they are, but so far, Marketo Support still has no answer (case has been opened for almost a month now).