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.
ADDED: So in the interrupt handler the kernel could evict all user space pages from cache before returning control to user space so it could not use the timing attack on the cache of the speculative execution of Mov rbx,[rax+Someusermodeaddress] on the address rax+Someusermodeaddress.
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.
Not having a central controller multiple subsystem vendors would have to cooperate using an agreed DMA communication protocol to monitor you and send the information back using the wifi/ethernet chip. Possible but unlikely.
The best approach is to evict all user space pages from cache when an invalid page access happens if the page fault was caused by the software trying to read/write kernel space pages.
Massive performance hit but only to misbehaved software. Normal software will not have the performance hit of the current solution.
Kernel could even switch to unmapped kernel pages solution if too many read/write attempts.
So in all cases just evict the entire process memory from the cache when the interrupt is raised when reading from a protected memory. The performance penalty would apply only to misbehaved code.
For software that requires self-modifying code to run the existing Linux kernel patch would apply (performance penalty). If there is other ways to flush the cache it is necessary to evict the entire software memory on the interrupt.
I know it was scheduled but the information on the links are public and prior to the scheduled disclosure. A hacker could figure out the problem by reading the available information before the Google Project Zero.