Thanks. Yes, I would have to put myself in that category. Typical play here is to offer the self-hosted option. Not sure if that is in the pipeline for the creators of this. Then you are into that trust/operational overhead tradeoff conversation.
Fair pushback and point taken. The reason this isn’t trivial is that the CLI is the easy and lightweight part. The heavy part is the infra behind it: auth, vaulting, token refresh/exchange, revocation, provider edge cases etc.
We'll think how to best accomodate full self-hosting in the future!
What do you anticipate to be the hardest part of supporting a self-hosted solution? I've worked a fair bit on converting SAAS -> self-hosted and always interested to hear others' pain points.
I imagine a lot of the organizations that would find this most valuable, and would be willing to pay a lot, would be the same ones that would require something like this.
I think the hardest part is the environment/support matrix, not getting it to run in the first place.
It’s usually pretty doable to make a system self-hostable on a happy path. The hard part is supporting it across lots of customer environments without being in the loop every time: custom IdPs, private networking, KMS/HSM/BYOK requirements, upgrade/migration paths, backup/restore, observability, and all the weird edge cases that only show up once other people operate it.
And yes, I think your last point is right: the customers who care most about this category are often exactly the ones who will require self-hosted.
What's your take? Curious what you found effective vs. what you deem hardest from your experience.
Currently we can use Bitwarden either hosted or self-hosted, which solves most of these problems (plus my own extra rig I built to generate OAuth tokens, for people which support that).
Could you elaborate on what challenges you face that can't be solved by the Bitwarden approach?
There's a "European Declaration on Digital Rights and Principles", signed by the member states, and I believe the right to access internet freely, without companies being permitted to mandate entire IP addresses blocks being forbidden from routing and within 30 minutes from the request surely would fit within that one, or others, in some way or another. No company should hold that power and it's a serious precedent others states in the union would want to leverage for their own reasons too. Reading this recent TorrentFreak article, the regulations should probably align with the following thinktank's analysis, at the very least:
>The report makes 12 formal recommendations. The most significant is that IP-based blocking should be avoided altogether, due to its inherent tendency to block large numbers of legitimate service sites. DNS-level or URL-level blocking should be used instead.
if it interferes with my ability to sell products and services in spain because my website gets blocked as a side-effect, then yes, the EU should care.
for example geo-blocking within the EU is also illegal. if you offer a service or product in any EU country, then anyone in the EU must be allowed to buy it.
among other things this also means that if there is any country in the EU where these sports broadcasts are accessible legally, then spain would not be allowed to block them either.
> if it interferes with my ability to sell products and services in spain because my website gets blocked as a side-effect, then yes, the EU should care.
As long as you’re not disadvantaged compared to a Spanish seller of goods or services or Spain’s law is specifically violating an EU one, I don’t think so.
> for example geo-blocking within the EU is also illegal. if you offer a service or product in any EU country, then anyone in the EU must be allowed to buy it.
Definitely not. You’re not automatically obliged to sell to other EU countries just because you’re selling in one. There are some categories where you have to, but that explicitly excludes video streaming.
There is another regulation for subscribers temporarily traveling to a different EU country not losing access to a service they subscribed to in their home country, but that’s also something else.
so even if not a reality in all sectors, removing geoblocking is in the interest of the EU.
going back to the original question:
Why should other EU members care what websites Spain allows their citizens to access? Does the "EU" even have authority for such a thing?
they do care, and they should, and yes, they have the authority.
personally, when i read the report, seeing how young people are more interested in viewing content from other countries, what first came to my mind is the increased integration of EU countries and cultures that comes from that. that's the why.
Surely EU members should care if Spain blocks the access to government services offered by EU members. In Finland various government services (like Police's website) do use Cloudflare.
And Spain is not blocking access to Spain's citizens, it's blocking access people in Spain. These could be citizens of other EU members who need to access their government's website for reason or another (e.g. renewing passport) while they visit Spain or reside in Spain.
The question is about the authority to pass laws that only some countries need to obey. To my knowledge, the EU does not have the authority to do that.
The EU doesn't work like that. It's a union of sovereign states, not a central government.
Banning the member states from legislating something would require changes to the Treaties of the European Union. And that in turn would require unanimous consent from the member states.
The EU could legislate the matter on its own, which would override national laws. But it's not in the habit of doing narrow single-purpose laws, because that's not in the culture of the people who run the union. Instead, there would probably be a comprehensive law on internet blocking and censorship, which would be a very bad idea.
> Compared to traditional C or C++ projects it's madness.
Those projects typically rely on an external package manager to handle their dependencies for them. Apt, yum, etc. Otherwise you end up in dependency hell trying to get ./configure to find the development headers of whatever it needs. I don't miss those days. Rust/Cargo is a godsend.
It may be better from a DX perspective, but it's pure pain for distros like Debian who don't want to use cargo at build time to fetch arbitrary dependencies and instead use vetted system versions.
Perhaps that is true, but the Cloudflare anti-bot protection is too stupid and annoying.
They should have used a cookie or something else that does not require asking me every few minutes to prove once more that I am not a bot.
There was a time when Cloudflare had become less intrusive, but for the last months it has begun again to intervene almost each time when opening some pages.
There is no doubt that anti-bot protection can be implemented in a better way than Cloudflare does, but presumably the alternatives would consume more resources on their servers, so probably they choose whatever minimizes their costs, regardless if that ensures maximum discomfort for Internet users.
Who knows what upsets ClownFlare? I'm using Vivaldi on Linux on IPv6 in Denmark with every uBlock filter enabled and Cookie Auto-delete. That seems to confuse and anger CloudFlare and I get CAPTCHA tarpitted constantly.
Those are easy enough to dissuade with readily available PoW solutions. People use CF & co. out of convenience, the exact same reason that most websites load resources from at least half a dozen third parties instead of self hosting.
That, ironically, includes Cloudflare. Without rampant bots making the internet worse for everybody, they wouldn't have as much work. And their portion of profit is anything but small.
The only thing that falls apart is the IP address identification, which is only a very small signal for identifying an internet user. X/Twitter undoubtedly has more identity information than just an IP address.
There are ways for the government to do that sort of thing on an emergency basis, and it would take quite some time to make it's way through the courts. There are precedents from nuclear weapons technology and cryptography. I don't think it'll hold up or be particularly effective because the horse has left the barn already, but they could probably slow things down if they really wanted to.
Of course there is. Fully automatic weapons are banned. Certain chemicals and biologics are banned. Certain hacking tools are banned (DMCA):
> The “tools” prohibitions, set out in sections 1201(a)(2) and 1201(b), outlaw the manufacturing, sale, distribution, or trafficking of tools and technologies that make circumvention possible. These provisions ban both technologies that defeat access controls, and also technologies that defeat use restrictions imposed by copyright owners, such as copy controls. These provisions prohibit the distribution of software that was designed to defeat CD copy-protection technologies, for example.
By using the type system. You define your type constraints at the module interface point and when you try to link the third-party module into that interface the compiler ensures that the constraints are satisfied. Same thing the compiler is already doing in simpler cases. If you specify that a third-party library function must return an integer, the compiler will ensure that function won't unexpectedly return a string. Just like that, except the type system is expanded to enable describing more complex behaviours.
That could be possible for browser apps which already have a sandbox. Doubtful for general purpose languages. For example I have a library and utility to change user password, or writing sudo alternative sudors etc. How would you even begin to sandbox that are core os utilities or need access to core os themselves.
more specifically, one can introduce policies into the runtime, or given rust hoist at least some of them into compiletime that would do things like (a) enforce syscall filtering based on crate or even function (b) support private memory regions for crates or finer grained entities that are only unlocked upon traversing a declared call-gate (c) the converse, where crates can only access memory they themselves have allocated except a whitelist of parameters (d) use even heavier calling conventions that rpc to entirely separate processes
fn prints_output(value: &str) @ mut std::io::Output {
println!("side effects! value: {}", value);
}
effect CurrentTime {
pub date_time: DateTime<Utc>
}
fn takes_context() @ CurrentTime dt -> String {
dt.date_time.format("%H:%M").to_string()
}
// combine effects for shorter declarations
// `?mut` is only mutable if the function declares it as `mut`
effect TimeAndOutput = CurrentTime + ?mut std::io::Output;
fn implicit_pass() @ mut TimeAndOutput {
prints_output(takes_context());
}
fn creates_new_context() @ mut std::io::Output {
// you only need to create the context thats not passed automatically
implicit_pass(@CurrentTime { date_time: DateTime<Utc>::now() });
}
effects can also have private fields and methods realized as a function pointer. that means `Output::print` can do different things in a simple cli app and a server framework with advanced logging. the calling function never knows the details.
syntax not final obviously and idk if it should be called "effect" or "context" so im using both. every function has to declare them but theres no big ergonomics hit when you have union effects and ide autocomplete. might not be easy to implement this in practice but the concept is simple, its basically some extra objects that get automatically passed through kinda like react context.
a function that takes no context and no &mut parameters is pure, if it takes only "shared" context its view (no side effects but depends on shared state). this can be used to let the compiler optimize better or guarantee security, like proc macros have to be pure or build.rs can only log to a provided output. of course you need to forbid unsafe code in the untrusted module to make it safe.
> Kontext holds secrets server-side and mints short-lived tokens per session.
That probably makes this thing DOA for most people (certainly for me and everyone I know).
reply