codexon

The view is that most emails are becoming centralized to come from a few places. So email hosts like microsoft and google take shortcuts to stop spam by untrusting any IP they haven't seen sending emails for 5 years (this is just a random number, no one knows what the real filters are).

Why is everyone complaining about taxes being regulatory capture when email is becoming also becoming a monopoly?

It is literally impossible to start up your own email server now and have it accepted by major email hosts like microsoft and gmail now without your emails ending up in spam or even worse, completely dropped.

People should be asking why email is so broken that companies like mailchimp exist and is being bought for billions.

> You've already started to add new things, like a TOTP-ish element, to stymie replays. Then the server has to check what it's been fed, having stored neither the original password nor the hash of the password it's been passed.

I don't see how this is any different from Valve "reinventing" SSL by using RSA. This isn't a new concept or roll your own crypto. I just don't want my password to be in plain-text. The only thing the server should get is the hash. If you are using RSA on the password, that means your password is going to be in plaintext on their servers eventually.

> It cannot be allowed to have the hash because the has is now the password. Now you have all the problems of server-side hashing and comparison coupled with extra client-side hoops.

The original password? Ok go ahead and encrypt it (and also hash it). But only do it once and not every login.

> Do you think that perhaps there might be other reasons to consider here? Such as debugging, logging systems, and so on? Perhaps there are design goals beyond blocking direct attacks. On an average day, most of these systems will be more likely to be accessed and used by authorized administrators than by external adversaries

It just seems strange to me that you would have trouble trusting your administrators to accidentally leak logs. What happens if they need to debug or log the app server behind the SSL layer? How likely is it that the dumb SSL termination layer is causing a problem and not the app layer?

How exactly is asking for my password to be hashed "reinventing password hashing and salting"? Seems like the opposite, no?

If your password is properly salted, it can't be used to guess passwords on other sites, that's the whole point of salt and hash.

The fact that RSA is being used means that your plain-text password is going to appear on their servers. Maybe it won't get cracked in the SSL layer, but it is still there.

> Are you sure this is what it's guarding against? A sophisticated application architecture might involve a load balancer decrypting and doing the initial routing, several sets of data handoffs, and then the application that needs it handling the password. Any one of them could mishandle or leak the password, but only the one at the end actually needs it in the clear.

Do you realize that if an adversary even only has read access to the SSL layer, they can just copy the cookie and steal the account that way?

Then just add a time sensitive seed to it? I don't think it is equivalent to leaking plaintext. It can't be used to guess passwords on other websites.

If your SSL layer is compromised, you can't trust the client-side encryption. The attacker can send arbitrary javascript.

Why not hash the password instead?

If you've ever try reporting vulnerabilities, you'll see that some companies won't ever fix the problem until it is widespread.

Hackerone has non-technical people screening your exploits. They will often mark them as out of scope.

Companies will routinely downgrade the severity of your exploit so they can pay you less.

I'm not going to name the billion dollar company on HackerOne I have an issue with, but they routinely downplay bug reports, take over 1 year to deal with some of them (if ever). And just recently one report HackerOne screeners closed as being out of scope blew up in their face as it was exploited in the wild, and they only fixed it only after numerous public complaints.

I've heard rumors of people selling exploits for this company on the black market for more money now.

HackerOne has people screening reports that don't seem very technical.

They closed one of my reports for being a "denial of service" attack when it was a crash caused by malformed input. I've also heard of others having the same issue.

All the inflation went into healthcare, education, housing, stock market, all things conveniently not measured or heavily weighted by the PCE.

They are not allowed to buy stocks. By buying bonds they force bond holders to get out of them and into stocks.

Sometimes it isn't as nefarious as convincing people to buy a product they wouldn't normally buy, and simply just showing the right people that your product exists.

Ads really work. I have a hard time believing there's any company that put effort into having decent ads and found that they did nothing.

The only question is if they are fairly priced. It could be argued that they were overpriced due to over-funded companies overbidding on them trying to growth hack and bot traffic being mixed in.

I tried it a few times after that and it still seemed like it was many years away from being competitive with C++/Java/Go

I don't remember, I tried it out a little before it was renamed from Nimrod I think.

I used it a few times before but I stopped once I realized it was a long way off from being worth using.

The lack of tooling, libraries, and numerous compiler bugs meant that it would be easier for me to write the same thing in C++ even though nim is a superior language.

I'd imagine many people came to realize this before even trying it out.

How about providing web access through remote desktop that has a browser with websockets, flash, and non-GET requests disabled and only retrieving pages through a squid cache?

They are very likely real and OVH has a very good system. You can thank them for making free DDoS protection mainstream, dragging all other hosts kicking and screaming into providing DDoS protection.

In the past providers like Linode were happy to just null route your IP for several hours/days or charge you thousands to block a small flood.

I can't find any evidence showing that OLAP means it is okay to lose data from unexpected shutdowns. How can you have correct analytics without a complete set of data?

> For good reason. It's not a simple matter of choosing one of two options. The choice has consequences: performance.

It is a simple matter though. They can choose to sacrifice performance for data durability which I suspect would not be impacted very much since clickhouse acts like an append log. It just seems that Yandex doesn't care much for durability since they are just using the database to store people's web traffic. They wouldn't care if some of that data is lost so they don't use fsync.

As I mentioned, there's only 1 place where it says anything about fsync, and in that page, it says that is only for creating .sql files.

https://groups.google.com/d/msg/clickhouse/cjJ6v8uzu0Q/jGV59...

> The reason is because CH does not use fsync (for performance)

https://www.linkedin.com/in/dzhuravlev/

This is not the implication at all.

Clickhouse can easily add fsync, they just choose not to do it.

Mongodb also did not use fsync and was ridiculed for it, yet no one mentions this about clickhouse.

Fsync is not synonymous with transactions. Not using fsync anywhere means there's a wide window that can be over 10 minutes long when data can be lost when a server gets an unplanned shutdown.

What do you mean clearly laid out? This is the only mention of fsync I could find through google or their own search function.

https://clickhouse.yandex/docs/en/operations/settings/settin...

One thing I haven't seen anyone note about clickhouse though which would be really important to many for data durability, is that it does not use fsync anywhere at all.

For such a highly valuable website like hackerone, IP binding should be done, the extra security is worth the slight annoyance at having to relog when your IP changes.

The threshold for "small" is a lot smaller than it was in 2000.

Plenty of non-profits have been ddosed. Your website is either small or is just lucky to have an audience that isn't inclined to ddos.

It is way easier to ddos a website today than back in the 2000s. Back in 2000, you could block almost every ddos simply by having gigabit. Now there are millions of more exploitable devices.

Do a search, https://www.google.com/search?q=stresser

An attack that can cripple all but the largest networks can be had for $5-10.

It is not easier. If you don't host your website behind cloudflare it can be easily ddosed.

The only way to get good ddos protection is to centralize because it requires you to have close personal relationships across the world in order to get good bandwidth at every location.