animalCrax0rz

Given Amazon's willingness to spy on their business customers (traffic data in this case), should I be worried to deploy code on AWS that has high IP value in source code form (JS, Python, etc) or bytecode (Java/C#, which can be easily decompiled). I ask this because I noticed on AWS EC2 the default behavior is that Amazon produces the private/public key pair (as opposed to having the user add their SSH public key) so if they wish, they can access any code I deploy. Let's say I make a product on AWS that competes with a current or future product of AWS itself, and let's say it gets a ton of traffic, should I be worried? Should I be using only native binaries? (C/C++, Go, Rust, etc) ??

Totally. The general problem is indeed difficult to solve, but I've seen lots of great work in this area.

In addition, the wording "test positive for Covid antibodies" may lead people to think that 30% of the population in MA is immune to Covid19. It obfuscates the fact that the mere presence of antibodies does not imply immunity. There has to be a sufficient amount of antibodies in order to successfully fight off reinfection (which could be worse than the initial infection) ...

Nope, I was simply countering that it's not as simple as they suggested. I added the link to the paper to show one approach to given them some context as to what might it look like.

Google is aware of this problem in their search approach. It's a business problem, not a technical one. You're saying the same thing in suggesting they base their decisions on some measurement set. If solving the problem adds complexity, which it certainly will, and there is not enough improvement in accuracy for the majority of cases in their measurement set, why bother? You sound like the kind of person that attacks people for their opinion. So weird, dude.

Google is in the business of producing quick results to sell ads while keeping the cost low. If anyone does better, they will likely do it using a costlier algorithm, and if there is more margin in reselling tangible products than ads then Amazon is incentivized to use costlier algorithms that are more accurate. But I think the margin in both cases does not justify the use of algorithms that may be more accurate in some small percentage of cases but a lot more costly.

I keep trying to talk about the general problem and people keep focusing on this one example. I give up. :)

Yes, I was just countering that it’s more involved than recognizing the importance of “no” in a sentence.

Which part of "The paper I linked to below describes a technique they call "deep parsing." Check it out for more context." could you not parse?

I mean if us humans have a difficulty parsing each other's statements, then why should machines do any better?

"there is no evidence of cancer" and "there is evidence of no cancer" are two different statements with different meaning, so it's more complex a task than just understanding the importance of "no" in a sentence. It's involves semantic analysis of the sentence. The paper I linked to below describes a technique they call "deep parsing." Check it out for more context.

There is this, too, from 4 years ago, which seems reasonable in my not-very-well-informed opinion (speaking of which, I'm not sure the work referenced here can deal with hyphenated negation, but it should be simple to include)

https://www.aclweb.org/anthology/P14-1007.pdf

code: https://github.com/ffancellu/NegNN

A recent study says that 6 new types of coronavirus were recently found in bats

https://www.zmescience.com/science/six-new-types-of-coronavi...

It’s time to go deeper?

When faced with an existential crisis, we tend to jump into fix it mode. But fix what? The symptoms or ourselves?

Let’s start with ourselves: we have failed miserably at being stewards to this earth. We have failed (not completely but in some very dramatic ways) at building a better future for our children and their children.

We should fix us, first, before we move on to fixing the symptoms of our flawed way of being in the world.

Don’t you think?

That's mostly unintended FUD (but still FUD) or problems that can be worked around:

<< - Is unstable because if a dependency/host goes offline, all users are broken instead of an internal build being broken (think leftpad but much worse as your users are instantly impacted, likely before you even know about it) >>

So you don't recall Leftpad?

<< - Is insecure because if a host is malicious, they can choose to supply different packages for a small subset of the requests, such as those coming from govt. requests against political targets, hosted build machines, etc. and nobody will have any way of knowing because there's no lock file/integrity hashes. >>

Are you kidding me?

https://www.zdnet.com/article/microsoft-spots-malicious-npm-...

It's not about choosing a different registry for all your modules, which will almost always be a commercial for-profit entity due to the cost of running and maintaining a centralized repository of that scale. AFAIK, or as far as I can envision, it's about a future where we can have the repository be a decentralized graph. It's definitely more challenging but we won't be dependent on one or few companies to host all modules. What do you think of that idea? My point is Ryan was right to avoid recreating dependence on commercial for-profit entities.

I think there's some confusion here.

NPM is both a massive repository as well as a package manager.

Deno will (soon?) have a package manager, but it won't be tied to one central repository run by a private company, now part of a massive corporation (Microsoft.)

So let's not lump package manager and repository: you can have a package manager that pulls in all the exact or latest dependencies at build time, but it does not have to be tied to one central repository owned and administered by one company.

Centralize-able yet decentralized.

This brought up in my mind the thought that while Deno is still WIP (for example, packaging of Rust plugins is not yet resolved) and the ecosystem around it barely exists it was designed to have no dependency on 3rd party tools like npm and yarn.

HN wouldn't let me nest another response. This is in regards to "Timers aren't necessarily even a requirement"

<<you can busyloop and count iterations of that instead as a “timer”>>

Assuming you're the only job running on the CPU, which is not the case. Threads are not running continuously. But again, if there is a working exploit in the browser then show us. Talk is cheap.

the minimum essential behavior to implement a feature is one that takes into consideration keeping the user safe from attacks... you could call that bloat, but I wouldn't be sarcastic about it: if you can make the mitigations more concise, you can contribute your ideas, no one stopping you.

performance.now resolution in Chrome is between 1 and 2 ms, I believe, with jitter. If they have a working POC for Chrome why not demonstrate the full exploit and force the Chromium team to rethink their mitigations? Lots of people talking possibilities but zero working exploits in the open. That's not a good ground for rational debate.

"We were not able use these techniques in Firefox, as they recently reduced the timer resolution to 2ms. The techinque presented here is potentially relevant even for this timer resolution, but some parameter tweaking is required.?"

AFAIK, Chrome's highest resolution is also in the ms range.

I have some thoughts, too, but thoughts don't amount to a working exploit. Show me a currently working exploit, that is in the open. As far as state actors developing such exploits, there are a ton of holes in that scenario at every layer in the stack.

Cool. I wasn't aware Chrome re-enabled SABs, with mitigations.

https://github.com/tc39/ecma262/issues/1435

postMessage cannot provide a reliable timing signal since it goes on the task queue on the receiving end (in the main thread) along with other pending events, and even if there were no other events, there is latency noise in postMessage due to the fact that the web worker is not the only thread running on the CPU. Some suggest that the attack would only take more time as the attacker has to collect a bigger sample, and factor out the noise, but I haven't seen a public exploit based on that.

The other angle of attack that used to be viable was documented in this HN comment: https://news.ycombinator.com/item?id=14057091

But AFAIK all browsers have disabled SAB, e.g. see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

EDIT:

Chrome has re-enabled SAB, with mitigations.

Again, JS can no longer perform this exploit. Browser vendors have disabled (made inoperable) high resolution timing. It's now at 1ms resolution. Not enough timing resolution to mount the attack.

That depends on high resolution times which have been disabled in all browsers. AFAIK.