HN user

DanielDent

711 karma

https://www.danieldent.com/

Posts13
Comments228
View on HN

Here's a very quick summary of what I linked above: In Israel it would be easy to look at the data and conclude that vaccines are providing ~67% efficacy against severe disease/death.

But, once the data is broken down into buckets that help address confounding variables (i.e. different vaccination rates among different age groups), things look very different. All of a sudden efficacy numbers are looking better than 90% for a lot of people.

This will similarly matter a great deal as people try to figure out how long vaccines provide protection. The groups that got vaccinated the earliest in many places were older people and health care workers -- groups which start out at higher risk, and also have a higher probability of less effective immune response to vaccines (older people).

As a result of that, it will be easy for analysts that don't consider that issue to under-estimate the effective time period of vaccines.

The archive.is link you provided isn't working for me at the moment, but to address your statement in the context of the above framework:

The group of people most likely to have been infected with the virus are not the same as the group of people most likely to have antibodies as a result of immunization. In many places, there are a lot more younger people who have gotten infected with the disease than older people. There are other socioeconomic and behavioural differences too.

Given that young people tend to have a more effective immune responses to begin with, and given that they have been shown to have better outcomes after being infected with this virus, it's easy to see a way to incorrectly conclude that stronger immunity results from infection-acquired antibodies, even if the opposite may be true.

In short: Apparent differences may be better explained by the fact that it's a different group of people who have been infected vs those who have not been infected.

Goodbye Freenode 5 years ago

For a little bit of ancient history: I was one of the admins who worked to create OFTC. We all knew each other from Open Projects Network (which rebranded as Freenode).

I was barely in high school when I came up with the name OFTC and I registered OFTC.net. Very early on in the process of creating OFTC, I agreed with all of the people I was creating OFTC with that I would behave as caretaker rather than owner of OFTC.net while we figured out our governance.

Ultimately we came up with a governance model, and we also managed to convince Software in the Public Interest to take custody of the domain name and have it managed in accordance with the governance model we designed.

We started with a pretty great group of both capable and well-intended people, and one of the things we figured out was that if OFTC was going to be a sustainable project, it needed more sustainable governance than the project we were leaving.

One of the key people behind the very early push for OFTC to have a stable governance model later became a Member of Parliament here in Canada.

I think a fairly manageable path forward is underway which makes this a smaller issue than it first seems:

(1) Firefox already uses its own root store

(2) App developers can include additional roots in addition to the system root store: https://developer.android.com/training/articles/security-con...

(3) Chrome is migrating to using it's own store: "Historically, Chrome has integrated with the Root Store provided by the platform on which it is running. Chrome is in the process of transitioning certificate verification to use a common implementation on all platforms where it's under application control, namely Android, Chrome OS, Linux, Windows, and macOS. Apple policies prevent the Chrome Root Store and verifier from being used on Chrome for iOS."

https://www.chromium.org/Home/chromium-security/root-ca-poli...

There's a really big gap between the $0.01/gb you are talking about being charged on droplets and the $0.10/gb that DigitalOcean is using on newer offerings like this and "App Platform".

https://www.digitalocean.com/docs/container-registry/ - "In the future, each plan will have a bandwidth allowance and additional outbound data transfer (from the registry to the internet) will be $0.10/GiB."

The fact that somebody could put a caching proxy in front of the container registry -- on a droplet also hosted at DigitalOcean -- and have their bandwidth costs fall 10x for doing that does indeed provide further illustration of the absurdity of DigitalOcean's new approach to bandwidth pricing.

There are many CDNs that make money charging < $0.01/gb.

Indeed DigitalOcean themselves built their place in the market by charging $0.01/gb for bandwidth. How do we reasonably get to $0.10 as is the case here?

If it were really that expensive for them they could outsource it to a CDN for well under $0.01/gb at their scale, which would leave them the ability to get margin. But all of this pricing is in fact completely detached from the underlying physical realities -- they are charging these prices because they think they can get away with it, not because they need to do so to cover costs and have some margin.

Bandwidth prices shouldn't be going up, indeed they should be going down. 100 gigabit interconnects are a thing now.

sigh. DigitalOcean continues their march towards irrelevance.

First it was the app platform and now this. Gouging us at $0.10/gigabyte bandwidth charges makes us: (1) think less of you, and (2) adds a bunch of cognitive complexity & work to developers' lives.

If this is how it's going to be we may as well just use AWS or move on to one of your competitors that isn't trying to pretend that bandwidth is expensive. It isn't, and there isn't any reason we should have to design applications around artificially absurdly inflated costs.

Even Oracle pretends to understand this. _ORACLE_ are the ones trying to make the case that they aren't only about having hostages/locked in customers.

When Oracle is beating you on this metric you've really jumped the shark.

What this describes is a mechanism for k8s to delete underlying resources prior to removing them from k8s.

E.g. before completely removing the CRD representing an S3 bucket, this provides a mechanism for that S3 bucket to be deleted from AWS systems.

Which I think is the opposite of what you were hoping.

The .com zone file is updated every few minutes. Caching behaviours will vary significantly. Frequently a significant fraction of traffic can be using new nameservers within minutes, with a long tail of traffic with older information.

Each TLD does their own thing. For example, last time I checked, .ca only seemed to be serving a new zone file every few hours. How long new nameservers take will depend on your luck in terms of where you are in their refresh cycle.

It used to be that nameserver changes with TLDs were measured in days, not minutes. Even today some TLDs continue to operate this way.

It would be difficult to differentiate between responses that vary due to load balancing and responses that vary due to active fingerprinting.

Even when a site only has a single physical location, load balancing might be done in part by having DNS randomly return one of many valid IP addresses. E.g. this is a behaviour supported by Amazon's Route53.

Larger sites frequently use a combination of anycast and DNS based routing to get packets to the closest POP. This introduces both (1) difficulty identifying when fingerprinting is occurring, and (2) still more opportunities for fingerprinting.

Most users will find it impossible to control which POP their packets get routed towards. For someone doing fingerprinting, it could be a very useful signal.

This would make it harder to build a fingerprint, especially if responses were sampled from a number of independent sources.

The next logical step in the arms race would likely involve fingerprinting systems using more bits than strictly necessary, and using error correcting codes - i.e. treat the sampling as "noise" to be overcome.

It seems both more straightforward and more effective to build recursion paths that you can trust aren't doing any intentional or unintentional caching.

This of course means the performance benefits of caching go away. This has been a theme in computing lately (i.e. CPU speculative execution leaks such as meltdown).

A recursor could be built which only uses each query response once, with prefetching used to reduce the performance impact.

However, the mere fact prefetched responses exist would also leak data.

Third party DNS servers are helpful in one sense - you can share your state with other users.

Turning off EDNS with your own recursor won't really make much difference. Limiting the maximum cache length will help, but will also eliminate much of the benefit of having a local recursor.

The other issue with running your own recursor is nasty networks will transparently proxy DNS and you can end up using a cache you don't even know exists.

DNSCurve, DNSCrypt, and DNS-over-HTTPS solve one set of problems while introducing different ones.

- Never allow any part of the computing systems you use to cache anything.

- Insist that everything in your life exist in a state of being functionally pure & stateless.

- Eliminate access to all sources of timing data.

- Make sure that all tasks are completed in a pre-determined fixed amount of time regardless of resource contention.

There are so many different side channel attacks, and the computing primitives & API choices we have been making for years make it challenging to build secure systems.

Caches are very deeply embedded in the culture of how computing is done. Making tasks take longer than strictly necessary to avoid leaking information goes against our instincts to optimize system performance.

It's going to take a lot of work and cost a lot of money to get software to a point where we aren't playing whack-a-mole with side channels.

More pragmatically, the current implementation of this technique can be dealt with by being very conscious of how much data your DNS resolver(s) are leaking & being conscious of how large the anonymity set is of the userbase of your DNS resolver(s).

If you limit DNS cache times and use blinding computation techniques to limit the identity information your DNS resolver has or retains about you, then DNS cookies can be largely mitigated. If you have faith that 1.1.1.1 is operated in the manner that Cloudflare claims, the measures they have taken go a long way to making DNS cookies unusable.

I also pointed out some additional specific mitigations when I reported this issue to the Chromium team in October 2015:

https://bugs.chromium.org/p/chromium/issues/detail?id=546733

I published dnscookie.com in late 2015. I google "dns cookies" and a few other things terms, was surprised that the terminology appeared unused, and it seemed suitable for the concept I was describing.

In May 2016, RFC 7873 was published which also uses the term "DNS cookies".

These two things share a name but have different meanings. The naming collision is an unfortunate coincidence.

Phoenix: LiveView 7 years ago

I have been eagerly waiting for this ever since I saw Chris McCord's demo. Having this become tightly integrated into the Phoenix framework will be game changing.

I think there are a large number of use cases for which this completely obviates the need to build a SPA. That's a huge time savings, and also makes for a faster cycle time as an app gets iterated upon/redesigned. The cost implications are massive.

In many circumstances I think it will also be a better user experience than a SPA -- e.g. this avoids "cold start" performance issues for a user's first page.

Thanks for the hard work Chris, José & team. Elixir & Phoenix are a joy to use while also being incredibly powerful/productive.

GSMA standards have always included purposeful insecurity, e.g. look at the history of A5/1 & A5/2.

It's a group that buys into the idea of secure backdoors, I'm not sure it's possible for them to build a secure system.

I actually think the current Huawei mess is direct fallout from our history of creating purposefully insecure systems: if the overall system was designed to be secure, the network infrastructure potentially being compromised wouldn't be such a significant issue.

At one point, one of the attack vectors was said to be by spoofing or otherwise manipulating traffic to/from a wireless femtocell. The same wireless femtocells that many operators will gladly sell or give to you for free or very little $.

I don't know how effectively that strategy still works today, but I think it speaks to the significant degree to which the phone system is completely insecure and untrustworthy by design.

"Friendly fraud" is not a Facebook-invented term. It's a term used and understood by card issuers, acquirers, and merchants.

Friendly fraud encompasses:

- Dissatisfied customers who don't find refuge in a refund policy/process

- Customers who are embarrassed by their purchases. This situation is commonly triggered when a significant other reads a credit card statement.

- Customers who spend beyond their means, and then look for a "solution" when the statement comes due

I find it weird the way Facebook seems to be using the term here. These are charges that were never contemplated by the cardholder. There is no "buyer's remorse" dimension.

Friendly fraud is specifically about charges that are agreed by the card holder, but they later change their mind and pretend otherwise.

Nonsense. The AGPL is a pretty nasty license to begin with, but this new license makes your software nearly useless.

For example: prior to this change, people could develop an extension to MongoDB which combined MongoDB with some GPLv3 software, and they could then freely redistribute that combined work.

Now they cannot.

MongoDB may as well be Oracle as far as most developers will care now (that isn't a compliment).

My understanding is that SLC is seen as safer, and lower densities are also seen as safer. Beyond that I don't know for sure.

I imagine that even an "industrial" grade flash card is still engineered with the assumption that it will be turned on for a while every now and then.

As I understand, SSD would be an especially poor choice for this - an SSD left unpowered for an extended period will begin to experience data durability issues. The firmware of a powered SSD will mitigate this issue by engaging in periodic refresh activity.

This is a classic use case for tape. LTO drives support reading up to 2 generations earlier, i.e. an LTO-7 drive can read an LTO-6 tape. By not using the latest standard, you should be able to find cheaper drives, but the risk becomes always being able to find a (working) tape drive that is capable of reading your specific tape.

All of a sudden spinning rust drives start to look pretty good...

Are there often significant issues that arise while Cloudflare is mitigating an attack?

I've often wondered why people would conduct attacks if the attacks don't actually end up doing anything.

The fact that somebody is protected by a DDoS mitigation service should be evident to most of the people capable of conducting an attack.