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.

What I don't understand is why the kernel patches and microcode updates are still been worked out today. They had 6 months to work on it.

No secret channel to communicate with Linux Kernel developers? No coordinated effort? Last minute findings?

On this thread https://lkml.org/lkml/2018/1/4/174 looks like that the author is disclosing the info on the last minute.

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 thought that:

mov rax, [Somekerneladdress]

would trigger an interrupt even on speculative execution as described on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...

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.

You are right.

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.

Isn't possible for the kernel to patch all clflush instructions when the software is loaded to keep a circular list of all evicted addresses that would be evicted again on the interrupt that happens when the protected address is read? This way the the timing attack would not be possible.

Looks like the information was somewhat public available since middle of the last year on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... and http://www.cs.binghamton.edu/%7Edima/micro16.pdf. Also similar methods from 2013 paper http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf (timing side channel attacks).

Any reason for the panic now? Any know malware using it?

It is the opposite. Batteries degradation acts as an internal resistance at rest (Rd) that increases over time. There is a second resistance (Rc) that increases as you discharge the battery. As you draw current (I) from the battery the nominal voltage decreases according to Omhs law V = Vn - I*(Rd + Rc).

You can plot different voltage charts as the battery discharges at different stages of degradation (increased Rb). As you know the peak current that phone drains at maximum load you know the minimum voltage it requires to operate. At this minimum voltage you show 0% (or a little higher so the phone can have enough power to gracefully shutdown).

What Apple is doing is slowing down the processor so it drains a smaller current reducing the minimum voltage the phone needs to operate extending the battery life (that also measures the time between 100% to 0%). This way you don't complain that an one year old phone battery is discharging too fast probably because of battery fault or wrong specification. There also a good side effect for Apple of decreased performance perception that induces to premature phone upgrades.

First?

https://www.vice.com/en_id/article/3knb7n/kidnappers-around-...

It is about battery life. This is how the battery should be measured: 100% -> Doesn't charge more 0% -> Do no provide enough voltage/current for safe operation at current power mode.

At 5% the phone could switch (configurable) to extended battery mode (low power mode) and alert the user.

As the battery ages the user will notice better a faster battery discharge (from 100% to 0%) and not the performance slowdown.

Coders need to strike now and kill the AI threat. We should not wait for 2040!!! - No deep learning, - No Alpha Go Zero, - No autonomous cars, - No whiteboard tests, - No open office, - No rental increases.