dagenix

The argument is that the servers aren't a problem - the problem is that we don't have a protocol to block them. Of course, we wouldn't need a protocol to block them if they weren't a problem. I'm very confused by this argument.

Following the herd absolutely can be the right answer. Especially if the question is how to reduce friction for contributors.

React isn't an SPA library.

A major difference between your ISP and a VPN is that your ISP is generally an established company based in the same jurisdiction as you are. So, if they do something terrible, in theory at least, they can be brought to court. A non-trivial number of VPNs that claim to protect your privacy, however, are based all around the world with unclear corporate structures. If they do something terrible, you likely have no recourse at all. How much faith you want to put in a promise made by such a company is up to you - but I would push back on the idea that simply making a promise really provides much value by itself.

And your solution is?

The problem is the Thread object can be forgotten such that it's never dropped. This would cause the thread to never be joined. This becomes a problem if the thread is borrowing anything from the stack since the borrow could then outlive the stack frame.

If you switch, your odds of winning are 2/3.

Fair enough - I missed the part about Handshake. I don't know much about Handshake, but, if it does what I assume it does, I do see how DANE would make sense in that context. Whether or not Handshake is a good idea I guess is the real discussion point - but, maybe one I'm not too interested in debating, especially given my limited knowledge.

The problem with DANE is that it doesn't move us away from CAs, it just conflates the role of running a DNS zone with also being a CA. And even CAs may be problematic, the entities running DNS zones are often more so.

What do you mean by "brute force"? Find a collision? I think it's almost certain the combined resources of every computer ever made would be unable to brute force a collision in a 1024 bit hash.

> This meant Lucene was less concerned with things like MVCC, ACID, and 3-NF, and was instead concerned with much more practical concerns, like how to build a fast and humane interface for unstructured data.

I absolutely hate this attitude. Different use cases have different requirements. The author here appears to be dismissing any use case different than their own as not practical.

Caching the delay defeats a big purpose of the cache in the first place - to reduce latency. But, also, the entity trying to fingerprint the request might also control the CDN - in which case, they can control the latency of non-cached requests. So, maybe in even minutes non-cached requests complete fast, but in odd minutes they are slow - in which case, a deviation from that behavior could be detected as a signal.

This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seconds and an uncached one loads in ~1.0 second:

* Any random delay of up to less than 0.9 seconds is completely pointless since we would know that any resource that loads in 0.5 seconds has to be cached - the 0.4 seconds spent waiting is useless.

* A random delay of up to a second creates ambiguous cases: is 1.1 a cached + maximally delayed response or an uncached but only slightly delayed response? But, with a random delay, we're still going to have pretty different peaks in the expected latency graphs for cached and uncached resources - uncached ones would peak around 0.5 seconds and cached ones would peak around 1.5 seconds.

* A random delay much more than a second would start causing the peaks on our expected latency graphs to be closer together - at a 10 second delay, we'll have a peak in the graph around 5 seconds for cached resources and 6 seconds for cached ones. I'm a bit fuzzy on how many resources we'd have to load to get a statistically significant finger print. I suspect its not all that many - but I could be wrong. However, we're also talking about a pretty significant delay by this point.

We also have the issue of how to handle AJAX requests. You only get one shot to measure the initial load. But, after that you can make an AJAX request to re-load that same resource with caching disabled and measure that. I'm not a statistician, but, I suspect that that information will be pretty helpful in figuring out what was cached vs not cached. Of course, we could add in some random delays here too - but since we can measure this an unlimited number of times, I suspect this would be even easier to defeat.

So, my suspicion is, that these type of random delays are possible to defeat if you have a better grasp of statistics than I do.

But, we could also assume that that is not the case and that they can't be defeated - what does that get us? We've had to add all these random delays in to block the side channel which is going to hurt latency - the very thing we're trying to improve with caching. I also suspect there is a ton of complexity to consider if you want to avoid having all of the same random delays on repeated visits.

Its pretty bold of you to assume that you know more about this problem than every browser developer.

Websites don't just "use Vue". They use some particular version of Vue along with particular versions of other libraries. My understanding is that once you put all of that together, this can create some significant privacy leaks.

It's my understanding that that type of countermeasure can be defeated with some statistical analysis.

Is there something that DataGrip does that PyCharm doesn't? As best as I've been able to tell, every feature that DataGrip has, PyCharm also has.

How many of them make web browsers? An engineering team that can build one is not cheap.

Awesome, thanks for that perspective!

I'm not sure I agree with most of this article, but, it seemed interesting and I was wondering what other people thought - especially for an interesting library like Aurelia that doesn't get nearly as much discussion as some other frameworks.

Even without a crash, one of the transactions will be completed before the other ones.

If the coordinator crashes, one (or all) of the transactions will be stuck until the coordinator comes back - or, if it never does - until someone manually rolls them all back of commits them all.

Why? Couldn't you just take the whole payment via bank transfer and then go buy Bitcoin afterwards if you wanted to? This sounds like extra steps that I don't understand the point of.

Missing from the article is a warning about how hard it actually is to make RSA secure. There are a _ton_ of footguns that are easy to miss which can result in a totally broken implementation. So, nifty article and all - but there really should be a disclaimer that an actual implementation is an order of magnitude more complex once you take into account all of those gotchas.

What if you accidentally format the drive on the host with the ZFS snapshots? Won't that result in synchronizing the deletion of those files to all your other devices?

If you accidentally reformat the ZFS drive, that will delete all your files and snapshots and then Syncthing will replicate those deletions.

I'm really not super familiar with Syncthing, but it sounds like it's niche is availability as opposed to durability.

From the Syncthing FAQ (https://docs.syncthing.net/users/faq.html#is-syncthing-my-id...):

> Is Syncthing my ideal backup application?

> No. Syncthing is not a great backup application because all changes to your files (modifications, deletions, etc.) will be propagated to all your devices. You can enable versioning, but we encourage you to use other tools to keep your data safe from your (or our) mistakes.

IMO, it's a good thing that decode() doesn't on strings in Python 3.

> It's possible for a business to advertise a product in two different currencies at the same time, but it's very, very rate.

FYI: It seems like you have a typo at the end of that sentence.

It seems that its being managed by a subsidiary of Mozilla, MZLA Technologies Corporation: https://www.zdnet.com/article/mozilla-moves-to-monetize-thun....

Apparently they are hiring: https://www.thunderbird.net/en-US/careers/#apply

This isn't a conspiracy - the problem with HTTP/1.1 pipelining is that responses have to go out in the same order as the requests that generated them. So, if a slow request comes in that generates a small amount of data, followed by 10 fast requests that generate a lot of data, the server has to hold all those big, fast responses in memory until the slow one finishes. That's bad for utilization - and it makes it easier to DOS a server. With HTTP/2, the server can respond immediately to whichever request finishes first - which is much better for utilization of server resources.

Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup.

https://en.wikipedia.org/wiki/HTTP_pipelining: says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support.

https://forum.nginx.org/read.php?2,269248,269249#msg-269249: Some person says that Nginx doesn't support pipelining. Other people agree. I can't find anything to contradict that.

https://serverfault.com/questions/266184/does-apache-webserv...: Someone says that Apache doesn't support pipelining. Again, I can't find anything to contradict that.

https://stackoverflow.com/questions/17299489/iis-and-http-pi...: This person says IIS doesn't support pipelining. Against, I can't find contradictory evidence.

Twisted used to support pipelining, but removed it: https://twistedmatrix.com/trac/ticket/8320

So, who exactly supports HTTP/1.1 pipelining?

It is true that if you fire multiple requests off to an HTTP/1.1 host without waiting for a response, you'll probably get responses back. The thing is that most hosts will process those requests one at a time. This is not pipelining - this is just processing requests one at a time as they come in. So, you're saving the latency required to get the request to the server - but not getting any benefit from parallel processing since the servers process the requests serially. With HTTP/2, however, at least some servers will actually process those requests in parallel - potentially with better performance.