It works fine. Clients don't complain about the interface. The project has been going on for 20 years or so now, and doesn't need big refactors every time a dependency gets updated because it avoids dependencies.
Thanks for your reply. This seems like it builds the UI almost completely in server code, which I usually avoid these days because in my experience, it causes other problems. I should have mentioned that in my question.
That seems like a very irrational fear. Attackers don't go around trying to break into Home Assistant to turn the lights on at some stranger's house.
There's also no particular reason to think Home Assistant's authentication has to have a weakness point.
And your devices are also unlikely to start a fire just by being turned on and off, if that's your fear you should replace them at once because if they catch fire it doesn't matter if it's an attacker or yourself turning them on and off.
Greenland sharks don't kill humans, they're not more "responsible" for what white sharks do than you as a mammal are responsible for tigers killing their prey.
That's what I do too (not iOS + GrapheneOS but the result is the same) as I was tired of fighting to make my bank apps and itsme (digital identity app in Belgium) work on my rooted phone.
Everytime I have to use a stock phone I'm appalled at the ads and I have absolutely no trust in any US or Chinese manufacturer. So I use them only for banking and digital id because that's presumably not what they actually care about.
It's not that expensive, I think many people have an old Android phone lying around, it doesn't have to be up to date.
It is very ironic that the solution is using an old, insecure phone full of unpatched holes for all important banking and id business, because that one is vendor-allowed while your state-of-the-art GrapheneOS is not.
If only banks cared about state-of-the-art security.
In reality, banks couldn’t care less. They only care about checking boxes and don’t consider where these boxes come from; every unchecked box is a risk.
Did the latest sham "security audit" say that root is bad? They'll block it.
My job's SSO moved to provider that either required an unrooted phone or a reliable Voice auth.
For 2 years the voice authentication worked fine (they call me, I type in a number) on my regular rooted phone. Then one random morning I just stopped getting the phone calls. "Network said no".
Complete lock out, nothing I could do except go out and panic-buy an unrooted phone not running Lineage and using a modern Android version. (I tried my older unofficial lineage phones without root, and no dice.)
I opted for a good phone I could postmarket later, but gosh did it set me back almost 1/5 of my monthly salary.
The ban was specifically to hinder the Concorde, so it made sense to base it on supersonic flight rather than noise in case the Concorde would have managed to mitigate its noise level one way or another.
Reference? There was an "Anti-Cordorde Project" [1] but its purpose was to ban all supersonic flight, for environmental reasons. Concorde being the only in regular service, thus the targeted name.
I don't know about the Dutch but apparently the Flemish don't understand German without having learned it at school.
I speak both some German and some Dutch (as nth languages, I can understand them fine but speaking is hit and miss) and sometimes I don't notice which is which and answer in the wrong language, to me they're almost the same language with a different accent. I translate the German into some Frenglish mess for my Flemish friends to help them understand and it works great.
For this specific issue I'm surprised, I have used all kinds of USB PD chargers for my laptops and all of them but one are less than 100W, with no problem at all.
The ones I use most are 20W and 40W, just stuff I ordered from AliExpress (Baseus brand I think).
This laptop uses a weird barrel jack so I have to try to find something USB-C-to-this-specific-barrel-jack. So far I haven't found anything that doesn't require 100w, as everything on the planet is just rebrands from the exact same Chinese factory.
But if they have to be exposed then a firewall won't help, and if they don't have to be exposed to the internet then a firewall isn't needed either, just configure them not to listen on non-local interfaces.
I'm not sure what you mean, what sounds dangerous to me is not caring about what services are listening to on a server.
The firewall is there as a safeguard in case a service is temporarily misconfigured, it should certainly not be the only thing standing between your services and the internet.
If you're at a point where you are exposing services to the internet but you don't know what you're doing you need to stop. Choosing what interface to listen on is one of the first configuration options in pretty much everything, if you're putting in 0.0.0.0 because that's what you read on some random blogspam "tutorial" then you are nowhere near qualified to have a machine exposed to the internet.
They don't have to assume that traffic is efficiently routed, on the contrary if they can have a <1ms RTT from London to a server, the speed of light guarantees that that server is not in Mauritius EVEN if the traffic was efficiently routed.
It just can't be outside England, just one 0.4ms RTT as seen here is enough to be certain that the server is less then 120 km away from London (or wherever their probe was, they don't actually say, just the UK).
RTT from a known vantage point gives an absolute maximum distance, and if that maximum distance is too short then that absolutely is enough to ascertain that a server is not in the country it claims to be.
One of our competitors was claiming a server in a middle eastern country we could not find any hosting in. So I figured out what that server's hostname was to do a little digging. It was >1ms away from my server in Germany.
I see I was mistaken, but I'm tempted to continue poking holes. Trying a different angle, though it may be a stretch, but could a caching layer within the VPN provider cause these sort of "too fast" RTTs?
Let's say you're a global VPN provider and you want to reduce as much traffic as possible. A user accesses the entry point of your service to access a website that's blocked in their country. For the benefit of this thought experiment, let's say the content is static/easily cacheable or because the user is testing multiple times, that dynamic content becomes cached. Could this play into the results presented in this article? Again, I know I'm moving goalposts here, but I'm just trying to be critical of how the author arrived at their conclusion.
This is about ping though, so presumably ICMP packets. There is no content to cache as the request is sent with random data that must be sent back in the reply.
It is very unlikely that VPN providers use convoluted caching systems just to make their ping replies appear to come from a different region than the one they claim to be in. It would be much more likely for them to add a little latency to their responses to make them more plausible, instead.
My experience is with this: https://github.com/Dolibarr/dolibarr (what I currently work on is quite similar, but it's not open source).
It works fine. Clients don't complain about the interface. The project has been going on for 20 years or so now, and doesn't need big refactors every time a dependency gets updated because it avoids dependencies.
reply