j_coder

Who uses Plaid for ACH verification must start to think on alternatives. Visa blocked PayPal to growth its ACH payments a few years ago.

I can imagine on a few decades company's data center on a single square meter chip :)

So Google don't test for load? They should ;)

You need to find as soon as possible trusted people that can tell you how bad is your idea/game play/sound/narrative so you can fix it or do something else. Most will just be polite to you or be trolls.

Very advanced civilizations could learn how to create targeted worm hole like structures to send information through it using real world physic rules that we don't know yet

It is amazing how each new version of Android has a complete new UX and none of them are actually good. Google is basically a back-end company incapable of doing good UX (if it is more than a search bar).

It is not the OCR that is costly. It is the JavaScript execution to render the page so you can do the OCR. You can even increase the JavaScript execution cost if suspicious.

You will also have to automate all page variations and the traditional challenges (login, captcha, user behavior fingerprinting, ...)

At the end the development time, cost and server cost will kick you out of business if you are too dependent on the information or you start to loose money every time you scrap.

Yes. The idea here is to make you dependent on OCR (you also have to find where is the information as the page design changes) and to waste a lot of your server resources making it very costly to scrape.

It is "easy" to block scraping. Make it very costly to scrape:

- Render your page using canvas and WebAssembly compiled from C, C++, or Rust. Create your own text rendering function.

- Have multiple page layouts

- Have multiple compiled versions of your code (change function names, introduce useless code, different implementations of the same function) so it is very difficult reverse engineer, fingerprint and patch.

- Try to prevent debugging by monitoring time interval between function calls, compare local time interval with server time interval to detect sandboxes.

- Always encrypt data from server using different encryption mechanisms every time.

- Hide the decryption key into random locations of your code (use generated multiple versions of the code that gets the key)

- Create huge objects in memory and consume a lot of CPU (you may mine some crypto coins) for a brief period of time (10s) on the first visit of the user. Make very expensive for the scrapers to run the servers. Save an encrypted cookie to avoid doing it later. Monitor concurrent requests from the same cookie.

The answer is that it is possible but it will cost you a lot.

It would make sense if it was the only alternative as the kernel can handle it. The appropriate behavior is to remove all traces of the speculative execution including cache hits.

I would never send to him :)

So it is a game over here. Unless Intel can change the microcode to force a page fault in this case.

I suspect a better solution instead of KPTI is to evict all user space pages from cache when an invalid page access happens if fault was caused by read/write kernel space pages. My kernel days was so long ago that I don't now if it is possible.

Massive performance hit but only on misbehaved software. Well behaved software will not have the performance hit of KPTI.

Kernel could even switch dynamically to KPTI if too many read/write attempts from user space.