Very quickly you'll find this doesn't work. Your DC will just null your IP. You'll switch to a new one and the attackers will too, the DC will null that one. You won't win at this game unless you're a very sizeable organization or are just willing to wait the attackers out, they will get bored eventually.
I’m not sure what’s so special in Oregon’s ballot boxes. But, tampering that is detected (don’t need much special to detect a burning box I guess!) is not a complete failure for a system. If any elections were close enough for a box to matter, they could have rerun them.
This seems absolutely silly, it's not hard to take a photo of a photo and there's both analog (building a lightbox) and digital (modifying the sensor input) means which would make this entirely trivial to spoof.
It's largely equivalent here - you're just exposing something via a tunnel rather than directly via your home IP.
That could have benefits, for example, if you're concerned about a DDoS attack on that service taking your home internet out, you may be able to work around it like this. But it won't mitigate a gaping hole in the underlying service which you're still exposing.
It could also have drawbacks, like limited bandwidth and higher latency, which would make it highly unsuitable for something like a game server.
There are indeed software firewalls on Android that use the VPN functionality to implement something like this so they don't even require root, I believe Glasswire offers one.
That only works if you’re concatenating the first and last name fields. Some people have no last name and thus would fail this validation if the system had fields for first and last name.
Honestly I wish we could just abolish first and last name fields and replace them with a single free text name field since there's so many edge cases where first and last is an oversimplification that leads to errors. Unfortunately we have to interact with external systems that themselves insist on first and last name fields, and pushing it to the user to decide which is part of what name is wrong less often than string.split, so we're forced to become part of the problem.
I did this in the product where I work. We operate globally so having separate first and last name fields was making less sense. So I merged them into a singular full name field.
The first and only people to complain about that change were our product marketing team, because now they couldn’t “personalize” emails like `Hi <firstname>,`. I had the hardest time convincing them that while the concept of first and last names are common in the west, it is not a universal concept.
So as a compromise, we added a “Preferred Name” field where users can enter their first name or whatever name they prefer to be called. Still better than separate first and last name fields.
Just split the full name on the space char and take the last value as the last name. Oh wait, some people have multiple last names.
Split on the space and take everything after the first space as the last name. Oh wait, some people have multiple first names.
Merging names is a one-way door, you can't break them apart programmatically. Knowing this, I put a lot of thought into whether it was worth it to merge them.
People can have many names (depending on usage and of "when", think about marriage) and even if each of those human names can handle multiple parts the "text" field is what you should use to represent the name in UIs.
I encourage people to go check the examples the standards gives, especially the Japanese and Scandinavian ones.
It’s not just external systems. In many (most?) places, when sorting by name, you use the family names first, then the given names. So you can’t correctly sort by name unless you split the fields. Having a single field, in this case, is “an oversimplification that leads to errors”.
I’m not sure what you’re trying to get at. The field containing the family name is the one labelled “family name”. You don’t have two fields both labelled “name”; there’s no ambiguity.
Whether it's healthy or not, programmers tend to love snark, and that snark has kept this list circulating and hopefully educating for a long time to this very day
Disappointing to hear considering the limitations of CRLs - is there any intention to go forward with OCSP stapling or is that completely abandoned at this point?
My understanding is that stapling is the victim of the usual incompetence and laziness that infects a lot of systems where if one in a billion fail closed that would be considered a disaster but one in ten fail open is considered fine. You can't achieve meaningful security this way.
The browser vendors have learned that you have to do it yourself or it won't be done well enough to be useful. So you pull every CRL, do a bunch of compression or other tricks, then give your users that data and now they have working revocation.
When Bob's CA and Kebab Shop breaks their revocation stack, instead of dozens of poor individual users or web site owners confused and calling Bob's outsourced call centre in Pakistan with no sign of a fix, now a Google account exec asks Bob's CTO whether they forgot to say they were getting out of the CA business...
I agree this isn't a desirable outcome, but it might be all we have.
> The browser vendors have learned that you have to do it yourself
Cool. We already got the internet ossified on TCP + UDP, other L4 protocols just get stuck in firewalls and whatnot. Now we're progressing in ossification of HTTP. <insert expletives here>
To be clear: this OCSP decision seems to be driven directly and only by web/HTTP consumers. Anything else is just not considered.
It is called the Web PKI after all. If somebody else actually wants to do all the hard work they're welcome, but my impression is that there's only enthusiasm for bitching and whining which won't get the work done.
We follow standards set by the CA/B forum, undergo WebTrust Audits, and are accepted into the root programs run by the browser vendors (Primarily: Apple, Mozilla, Microsoft, and Chrome). That is the WebPKI.
I am not implying that, but merely defining what the WebPKI is and where we fit into it.
Let's Encrypt's primary goal is to encrypt the web, and most of our decision making is based on that. It isn't so much about HTTP as it is the ecosystem.
You can use our certificates for any TLS Server use-case. I wouldn't suggest using our certificates for things which aren't TLS servers, though.
Thanks for the clarification. I guess I'll have to find a few friends to run an ACME service together with. Unfortunately, in most cases the certificate store is global across applications, so presumably we'll hit a brick wall with browser requirements.
(The services are all TLS based. They are just not HTTP based, and CRLs are generally delivered via HTTP. And I'm not going to wrangle a HTTP client into my mail server, or worse, postgres instance. The latter could also work with a local CA, it's primarily SMTP that doesn't.)
(...or I just ignore revocation and cross my fingers it'll never come up...)
Wait. What. Let's Encrypt CRLs are only available to browser vendors? So you can't even do a CRL check in an SMTP server if you wanted to?
> Our new CRL URLs will be disclosed only in CCADB, so that the Apple and Mozilla root programs can consume them without exposing them to potentially large download traffic from the rest of the internet at large.
I used to feel the same way about Plex til they started flooding my less savvy family with ads for their own content and useless features unrelated to what they want to do. Really not impressed by that one. I realized how bad it was when I got a call about a broken movie I didn't even have.
Plex still seems slicker than Jellyfin in some ways but after that experience I'd certainly consider a switch. Offline is the only reason I still use plex, but their offline setup is pretty buggy too.
