Even ECH isn't that helpful. ISP still sees the IP addresses you connect to. Even when non-dedicated IPs are used, I'd be surprised if a quite basic traffic analysis (say, bytes transferred on first visit) wouldn't identify the domain.
VPN providers at the tier of Mullvad should be precise about this stuff -- I think it's more than just a nitpick, considering the audience. oh god did I just use an emdash.
Note that you need some flavor of secure DNS to enforce ECH. The protocol is designed to be downgradable.
and there's a goddam ad at the start of every apple TV show, and macOS forces ads on you via the SETTINGS app! (both such ads are for other apple products ... still, it's an ad)
What's to prevent Apple from making iOS and macOS free to "copy, redistribute, and modify"? The OS is free already, and the platform does cryptographic signature verification before allowing its installation. macOS already automatically finds local caching servers, which amounts to redistribution capability baked in.
They can just claim that the user is free to turn off SIP and "modify" the binary bits, or that kernel extensions amount to modification.
I think you're misreading it. It doesn't ban Linux from providing age collection and verification. It makes it a choice, rather than mandatory.
I would expect that Linux users want access to age-verified apps just as much as other users, so such a signal will be available.
Also, you're being overly pedantic on the language used. It transfers liability away from the service, more easily allowing operation in about half of the states. "age verification" is a fine lay description.
Nobody cares about the distinction except pro-age gating activists. I don’t want any law that requires specific behavior from the OS, whether it’s verification, attestation, or something else.
True, but it requires setting up a mailbox at bigdomain.com for every use case. With your own domain you can just setup a catchall mainbox like catchemall@yourdomain.com and don’t even need to remember any mailbox@bigdomain.com name. Just use github@ and it will be automatically be catched by your catchall.
So any mail to anyrandomstring@yourdomain.com is actually received? Sounds like something that works great when only you do it, but might quickly be abused if it catches on?
Going back on topic, Apple offers mail hosting for custom domain, along with the optional “one mailbox, infinite aliases” feature we’re discussing right now. I’ve been using it for a while now and no bot spam. No spam at all actually.
> along with the optional “one mailbox, infinite aliases” feature we’re discussing right now.
They’re not exactly the same thing. Aliases are alternate addresses (under one domain) you set up yourself, while a catch-all just accepts any address in the domain as valid. While iCloud Mail does allow catch-all¹, aliases are capped at a maximum of three².
Surprisingly not. I have catch-all emails on several of my domains, and rarely get common name spam. I've blacklisted less than a dozen names on my domains in over 20 years.
A friend of mine does the same. Catch-all, and buying expired domains he thinks funny or related to projects and customers he previously worked with. On multiple occasions he has received emails that truly where never meant for him, not spam but actual emails.
So far I think he's returned at least two domains to their previous owners, because letting them laps was a mistake.
I guess it varies then. When I did it (probably 15 or 20 years ago mind) I unleashed a torrent of spam so voluminous that I had to write scripts to clean it up my inbox after I turned it off again.
It never happened to me - I use a catch all and almost never got emails like this. Why would bots try to guess emails on random domains when there are billions of known emails to send spam to.
This past weekend, I finally have purchased my own domain and was contemplating using it for email.
I had thought about a catch all, but was worried about bots. What is the best option?
Do you create addresses such as:
eyeball@customdomain.com (for the eye doctor)
tooth@customdomain.com (for the dentist)
bank@customdomain.com
realfirstname@
reddit@
...
...
I would like the ability that if I am in a situation that someone says "give me your email for..." and I would like the ability to just hand them something that is disposable. Would I just stand up say 10 addresses like:
random1, random2, random3... then delete them at some point in the future?
I really like Cloud's Hide My Email, but have been looking for alternatives since I am not sure where Apple is heading post Tim Cook.
For things I know ahead of time I'm going to need to give someone an email for (e.g. the dentist), I'll pre-make that address and have it ready for when they ask for it. For one-offs / unprepared asks for my email I usually just give them my 'main' initials@personaldomain.com e-mail just for the simplicity... Fastmail does let you use *@personaldomain.com to forward to your main address, but for the rare circumstance in which you need to reply to one of those emails, you do need to configure it in the settings.
Thanks. I really don't use email that often; I might get 20 emails a month, and those are just notifications versus actual actionable communications that require a response.
I have been looking at Fastmail, along with Purelymail ($10/year), which seems to have similar features.
I use Migadu to host my email, and they have a really cool wildcard-style system where I can basically define a regex string, and any email address matching that string goes to my main email.
In my case, I use a specific set of numbers just before the @ as the matching string (let’s say, “45”), so email to firstname45@domain works, or doctor45@domain, or library45@domain all get delivered. Since the spammers don’t know this, I don’t get any spam. But I still have the benefit of being able to make up arbitrary emails on the spot for any purpose.
> all APs identify as the same BSSID, and decide between them who answers a client
That is decidedly not a solution. Neighboring APs necessarily need to be on different channels, to avoid Co-Channel Interference (CCI). An AP doesn't answer just on BSSID but also on a specific channel.
This feels like a weird comment on an article about how they monitored usage, identified misuse, and terminated the people involved.
There's surely plenty of entities that need better controls around usage of technology / records / etc, but this is an example of somebody having an incentive and then following through.
it's also possible that we're only seeing a few select departments fire their officers. there are no laws around this as far as I'm aware so enforcement is purely departmental policy. how many sheriff's offices and police departments do these audits and how many of them act on abuses?
you should need a warrant to monitor the products of mass surveillance and it should be as narrowly targeted towards a suspect as possible. or just not have any of the mass CCTV placements everywhere in the first place
I'm in favor of pushing for police departments (and really any governmental body with access to any kind of data) to have regulations around access to that data, access controls to restrict illegitimate access, and monitoring to detect improper access by people who do have legitimate access but don't follow the proper regulations.
I think you're correct that we don't tend to see the instances where improper usage occurs, tautologically because those entities aren't doing their homework on the above.
I think the point we disagree on is the idea that accountability by a singular department is an indication that it's sufficient for vendor to avoid regulatory action. in terms of privacy protections, the strategy should be defense in depth. I think about the audits that happen in health tech for eg on the software side, both at the request of regulatory agencies and their clients
any platform that enables people to be stalked, harassed, tracked, and so on should face the same level of scrutiny in the form of auditing and open access to internal policies around data sharing
You're correct that we disagree on that point. Flock is providing a tool; if we think the tool can be used in problematic ways, we ought to regulate users of the tool (in this case, government entities). This has the added benefit that the burdens on the government around their treatment of citizens have a higher bar for transparency and conduct than we place on private entities.
"it's not the gun, it's the person that holds it" is not a philosophy that's tracked with me given the probabilistic, population-wide outcomes. the same applies here - tools should build in strict data and privacy protections as part of their UX. you lower the probability of abuse wherever you can because you know a bad actor will find a way, regardless, but the point is to add enough friction that even the worst of the bad actors has a difficult time getting what they want
its good PR for these systems that they are very keen to roll out, i would say theres a vested interest in stories like these from the exact agencies deploying them
If government entities get good PR for rolling out strong policies, practices, and tooling for the data they have, and that makes more of them very keen to do so... mission accomplished?
Cards on the table, I am an optimist. But this feels pretty realistic: it's basically a corollary to the idea that public outrage about bad policies, bad practices, or bad tooling is problematic for these government entities. They want to avoid it. There's plenty of examples of this, even honing to just the US. Increasingly there's even examples of this specifically in the US, for police departments, for usage of Flock.
There always ends up being a real world to digital interface and it always has the potential for abuse, and thus always requires some level of monitoring and validation.
The department in this article appears to be doing just that:
> Every search run through the Flock Safety platform is automatically logged — who ran it, when, and the reason they gave for doing it. SPD said they also have other safeguards in place, including mandatory training, role-based access controls and supervisory oversight.
I've recently bought many domains (1000+ over the last year). A few of them (the more valuable ones) all had TXT records for `@` (the root) that had for-sale info. This new record is just a TXT record anyway, proving the point that the interested buyer can quite easily learn of a domain for sale with existing mechanisms.
Also, for domains that are just "parked", not in current use, obviously the parking page can just have a for-sale banner. This is exceedingly common.
> Enquiries that would have been welcome never arrive, and the ones that do arrive are indistinguishable from spam.
claim is that very many things are not needed, but they are. they are just provided by the layer beneath (S3). so isn't correctness highly dependent on s3 correctness? was s3 built for that, vs just plain durability? for example, would it be just as reliable with minio?
i would prefer a thing that was more self-contained, not dependent on a black box service layer underneath.
much apologies if i just have a poor understanding.
VPN providers at the tier of Mullvad should be precise about this stuff -- I think it's more than just a nitpick, considering the audience. oh god did I just use an emdash.
Note that you need some flavor of secure DNS to enforce ECH. The protocol is designed to be downgradable.
reply