steventhedev

Weren't Iranian devs banned from github last year[0]?

That aside, I dont see any first hand source for the repo owner being Iranian, only speculation in the comments. The situation is sad, but a reasonable response to a PR that has legal issues. I don't think there's much intelligent discussion that can be had about this.

[0]: https://techcrunch.com/2019/07/29/github-ban-sanctioned-coun...

EDIT: github doesn't show profile location on mobile. My bad.

Assuming the mean is close to the median, they are reporting ~10B requests daily with a median response size of around 1KB. 10TB daily is a little under 1Gpbs. Traffic is spiky, but this isn't particularly complex once you consider they have multiple data centers/servers. Of course, I may have misread something as daily that was hourly or something like that...

For the majority of applications that follow this guide (or need to), the OS mitigations don't matter anyways:

1. They're running only trusted code.

2. L1 cache attacks aren't relevant if there's only one thread ever running on a given core.

3. Kernel-bypass networking means there are no system calls in the hot path anyways, so the OS mitigations won't even run in the first place.

If you're already doing all this it may be easier/better to look at using FPGAs instead. The advantage of this approach is that you don't need to procure a card with enough LUTs to house your design, and it allows the Ops team to contribute to performance.

Few bits of advice/comments:

1. the schedule syntax. It can seem much easier to work directly with English, but there's a reason most systems use cron-style schedules and it isn't because it's legacy. There's a benefit in having a syntax that is "alien" when you're crossing that human/computer/dev border, as it forces your users to think about how to achieve something. The other half of the reason is because it's a lot easier to validate a strict syntax with a formal grammar than anything even close to natural language. I can basically guarantee you that if someone had come up with a way to accurately parse english recurrence statements, it would have already been adopted by cron in the past (or at least a website like crontab guru[0].

2. There is no description of the job execution semantics in the distributed sense. Is it at most once, or at least once? This is important if you're designing jobs, so if someone is switching to your system from an existing system with a different semantic it will cause a lot of friction especially if you don't even list it in your documentation.

3. You have two data stores. You're using Raft for backing your key/value store, and mongo for both job metadata and also communicating with the dashboard. This is a bit confusing because in the docs you wrote that metadata goes in a sidecar yaml file. What job metadata are you referring to then? Results? Fundamentally, having multiple data stores makes your projects orders of magnitude more complicated to operate and monitor. My guess is you'll see this as a major pain point in the future when you want to scale a cluster in different ways (more jobs, more frequent jobs, longer histories, more nodes in the cluster).

All in all, it looks like a pretty decent distributed cron, but I wouldn't touch your project for my production systems. It's lacking a lot of features we need for getting Legacy (TM) work done[1] like running a specific job on a specific worker because it needs access to special hardware or some filesystem or because our PHB decided that as a policy only one of our servers can run billing code on Tuesdays.

[0]: https://crontab.guru/

[1]: "Legacy code is code that makes money"

Most likely it will be added to the OFAC sanction list at which point both Google and apple will delist the app within a few days. You can read up on how the SDN lists are basically the long arm of US law and can completely excise someone from modern society (even if they live outside the US). Banks will refuse to complete payments, merchants will refuse service, shipping companies will return packages, etc.

It's wrong in the sense that anyone who's studied standard accounting will look at your books and consider them to be incorrect.

This is important if you want to share your books or reports with your local tax office, who will begin investigating you for committing tax fraud. It's the same reason why no one fixes the HTTP "Referer" header typo. You can, but if you do then you'll have difficulty communicating with the outside world.

I think this is partially because it's applicable to so many different domains (cryptography, statistics, etc) that each have their own notational quirks. Avoiding collisions between notation in the application domain is more important than preserving some "consistent" probability notation (similar to the examples given with dot products). But the issue isn't even limited to notation: Chebyshev has at least 9 valid ways to spell his name (more if you include non-latin alphabets).

The biggest issue I've encountered is borrowing lecture slides from different universities/lecturers and the notation changes between slides on the same topic (even small things like using square brackets instead of parentheses).

Which exact headers are being leaked by GitHub? Depending on what they leak, this could be something only useful for counting hits (if all they leak is the implicit time of the request), or for fully tracking users (if they leak Etags, original IPs, etc).

It's too bad the author removed the badge from their Github profile. It would be interesting to see the effect of this post on profile views.

Many of the violations discussed on the security lists are not end of the world at all. The 63-bit instead of 64-bit serial number entropy issue is a good example of this. But the strict enforcement of all violations makes it easier to spot bad actors or at least those who aren't competently handling all of the requirements to be a CA. Bottom line: the entire CA system is built on trust.

Would you trust someone who doesn't take issues seriously because they think they're small or unimportant?

EDIT: reading the full report, it seems that the underlying risk is that if one of the intermediate CAs were to be compromised, even if it was revoked it could theoretically forge an OCSP response that it is still valid (and as a trusted CA issue certs for anything). So the response is very appropriate given the potential impact.

That's the type of behavior I would applaud. If a country is not handling law enforcement to your satisfaction, then simply don't do business there.

My issue is with an American company literally furthering their business interests by hiring foreign actors to intimidate and threaten. The relevant quote from the article:

"Mr. Sullivan’s team hired Nigerian contractors to confront him."

On the one hand I can look at what he did and say that his intent was good and he protected those women and protected his company. However, Mr. Sullivan is clearly taking the law into his own hands (even if that law is in another country).

If you look at this as a business deciding that they want to move forward a business deal elsewhere in the world, they would run afoul of the FCPA if they decided to bribe someone to further that business deal. But it seems that hiring PMCs to intimidate and threaten people is permitted. Perhaps the time has come for legislation to cover this particular practice.

There's a vast difference between a noncompete agreement between employee and employer and a noncompete/nonsolicitation clause in a contract between businesses. The first limits the individual employee's ability to compete in the marketplace. The second prevents a business partner from leveraging their position to kill your business.

Almost everyone (except the shareholders) benefits from employer-employee noncompetes being banned outright. Almost everyone suffers from having business-business nonsolicitations being banned outright. Why the studio's lawyer didn't include it in the contract is beyond me...

How does this compare to a full reverse index? I would expect a full index to be much simpler to implement and would compress better.

Still very impressive work, and gives me a new reason to learn Rust.

I've used mosh extensively over the last few years with very few issues. It composes well with tmux. The only barrier to me really advocating it is the lack of support for bastion hosts and working around firewalls.

How is this not filtered out by a lowpass filter? Wouldn't this only block the ultrasonic beeps they embed in ads?

New banks are getting FDIC approval[0]. Latest one was approved last Friday.

Perhaps you meant something else?

[0]: https://www.fdic.gov/regulations/laws/bankdecisions/depins/i...

Neat. Can you fix the numbers in the readme? It's difficult to trust a project that has glaringly obvious math errors on the front page (0.068 * 720 = 48.96, not 600.96).

Put yourself in the attackers shoes. Your goal is to spread this to as many machines as possible. The best and easiest way to do that is to add your library as a transitive dependency. What better way to infect people than to get everyone who ran `pip install numpy`? As for getting it in, I'd push it to older projects as part of a "styling cleanup" PR because there's so much noise in the diff anyways. Imagine a PR to a project adding a transitive dependency for python3-dateutil. Most people would merge without looking twice, especially if you add some scary "this deprecates py2 support" to the PR.

The actual paper: https://www.math.ucla.edu/~myding/papers/baking_paper_final....

As an aside, is this the new pipe curl to sudo bash?

    docker run --rm --privileged docker/binfmt:66f9012c56a8316f9244ffd7622d7c21c1f6f28d

Even if you disallow command execution on the bastion (good idea), this will still allow an attacker to pivot to servers behind the bastion. The whole point being that the strong auth (e.g. MFA) enforced by the bastion is a roadblock to pivoting.

Yes[0]

[0]: https://github.com/uBlockOrigin/uBlock-issues/issues/338

I've yet to see any law that requires a specific feature. Usually they're worded like "has a control for preventing unauthorized access to accounts". The definition of unauthorized, access, accounts, and even control are left to auditors and each bank defines them differently. I spent 2 months implementing something with absolutely zero security value, but the bank's auditor was insisting so we had no choice.

I don't remember any data mining projects that weren't explicitly anti-fraud, but that was years ago and things may have changed since. One project I recall was able to proactively reach out to banks and inform them of compromised accounts based on things we learned from other banks. Pretty cool stuff; kinda wish I had stayed there longer.

I worked dev (hence the username) and left the company more than 5 years ago, so I don't remember the exact regulations. I do remember it was a big deal towards end of 2012, so you're probably looking for something from around 2008 with a final enforcement date of 2012.

I'll update if I remember the name.

> Why am I supposed to believe that?

Because it's required by law, at least in the US, UK, and most of the EU. The quality varies somewhat, but the main goal is less to prevent fraud than to detect it after the fact. Basically every single bit of information your computer is willing to send will be recorded. That includes request headers at a minimum (if you've disabled JS) and quite a bit more if you do have it enabled. Try a packet capture when you open your bank account next time to see just how much they transfer out of your computer.

Source: used to work on one such product

I'm talking about "potentially" moving servers based on credible claims of upcoming changes.

In this particular case, we don't have any business interest in mainland china, so I'm willing to speculate based on other people's measurements. Acting on speculation is very different from planning. As smarter people than me have said: "plan for the worst; hope for the best"

> How do you check that?

searched for "Great firewall latency" on my mobile. Took the first result with numbers, and saw mainland latency around 100ms higher than HK.

> The DPI works mostly in async way, mirror traffic to standalone servers to extract key data points, if found a match, send RST to drop the TCP stream and maybe further blacklist the IP indefinitely.

If it works async like you describe then it invalidates my worries about latency. But it doesn't solve the "why the hell is my SSH stream getting a RST?!" because their firewall is dropping SSH by policy or because of a false positive in the traffic.

We have servers in HK. Not to reach mainland China, but to service all SE Asia. We chose HK because it has the best balance of latency between all destinations. If PRC decides to move HK behind the great firewall, we'd move our servers, and so would most other companies. Last I checked, Great Firewall DPI takes around 100ms. I don't have exact timing, it's possible it's different for ingress/egress, or that it's only on tcp connect, but 100ms means it's reasonable for us to consider pretty much any other city in SE Asia, and a few outside. For reference, Taipei is around 20ms away from HK, and Manila is around 40ms. Singapore is problematic because they have a tiny number of external cables, and they had an incident a few years back where all but one cable was out of service for months.

Point is if HK moves behind the GFW, I'll have some servers for sale.

EDIT: I'll let my stupidity stand, but for correctness: Singapore has around 15 submarine cables as of 2018, but only 3 landing sites.

I can't get into too much detail, but there were increased failure rates during a few jobs. In one case, we added ionice. In another it was a matter of adding a missing index to the DB (full table scan instead of looking at records from the last week).

There was one periodic job that we moved from the production server to work off the daily backups instead of the live server.

Regarding "Seek Out Problems and Iterate", it's a bit of an understatement how important this is. I've invested a lot of time helping my coworkers understand the distinction between tasks and problems. The end goal being only tracking problems in the ticketing system. It's not easy to do this and it takes constant effort, but it pays off very quickly. I've yet to see a real "problem" ticket stay unresolved for a long time, whereas "task" tickets tend to stay around until they're either irrelevant or they get closed after getting kicked between a few people.

A good example of this is:

- Add worker thread for X to offload Y

When the actual problem is more along the lines of:

- Latency spikes on Tuesdays at 3pm in main thread

Which may be caused by a cronjob kicking off and hogging disk IO for a few minutes.

A good rule of thumb I've found is that task tickets tend to have exactly one way of solving them, whereas problem tickets can be solved in many ways.