Read it rather quickly, but looks fine at least on the surface. Sadly, there is no way I would trust anything as sensitive as DNS with the EU given their dreadful record of creeping surveillance.
Depends a bit on which machine really. Overall, I am more confident trusting a company with a good track record or non-profit with DNS. Mullvad have great offerings with optional content blocking and DNS over both HTTPS and TLS:
If there are other entities (commercial or not) with similar DNS services I would be happy to hear about them.
I find some reactions here to my initial comment a bit puzzling. Yes, the EU has a number of great attempts at getting privacy legislation right. Personally, I even have sympathies for the cookie banners. But it is equally true that we have seen attempts and successes to introduce surveillance measures as well. I remember the fight against the Data Retention Directive [1] and we still have "Chat Control" lurking in the shadows. Thus, I do not think I am entirely wrong in feeling less than chuffed about the prospect of handing all my DNS queries straight over to an entity working directly under the European Commission.
There were many laws on surveillance proposed in the EU context as there are many parties that make proposals. But there's no actual such law in place. And the EU is bound by GDPR and EDPR and actually does a huge circus to respect them, so I'd trust them more than any other party, be it my provider or the mega corps collecting data for ads.
Where do you see negativity? I just expressed surprise someone would use it, given current situation. If I am wrong and people find it useful - by all means.
I think for any given job there's a tool thats likely best. If you hire me to paint your car and I show up with a paint brush you're probably not amused, because you know that it needs to be spray painted. If I hire you to program a microcontroller and you try to use Ruby..
agreed. but then you're breaking the existing `db.execute(str)`. if you don't do that, and instead add `db.safe_execute(tpl: Template)`, then you're back to the risk that a user can forget to call the safe function.
also, you're trusting that the library implementer raises a runtime exception if a string a passed where a template is expected. it's not enough to rely on type-checks/linting. and there is probably going to be a temptation to accept `db.execute(sql: Union[str, Template])` because this is non-breaking, and sql without params doesn't need to be templated - so it's breaking some stuff that doesn't need to be broken.
i'm not saying templates aren't a good step forward, just that they're also susceptible to the same problems we have now if not used correctly.
Yeah, you could. I'm just saying that by doing this you're breaking `db.execute` by not allowing it to take it string like it does now. Libraries may not want to add a breaking change for this.
No idea if that's the case, but the two are not necessarily incompatible.
reply