For the generic selector naming I'd suggest "cascade selector/selectors" as that gives a hint of the origins and describes the actual function of it pretty well.
I see what you mean, but what would this do except add more churn?
Words sometimes have misleading aspects, but I don't see any practical problem with the current usage of the word "selector" in web dev. The CSS part is often omitted when it's implicit.
The spec separates selectors cleanly into its own module already, and there are already implementations that don't rely on HTML rendering.
Any rename by commitee wouldn't stick anyway, and the origin of this selector spec is CSS, doesn't prevent other uses.
When you bring in "cascading", you already go close to the CSS / rendering aspect, because that's the most common use case for cascading?
But in the real world, for maximal battery savings and therefore UX, routing any notification data via APNS is recommended.
Fortunately you can choose the payload by yourself and just send a notification "ping" without any data about the messages. But if we're serious about security, you just don't ping the client about new messages because even the time and existence of a notification can be compromising. _The user will know that they got a message, when they open the app and see that they got a new message._
Routing e2ee notification data via APNS is fine, it’s no different than routing e2ee notification data via HTTPs. Your ISP sees the outer ciphertext in both cases (APNS is also mTLS).
It's not likely, but if you're an expert I'm sure you could think of a few ways it would be possible. The reason we give people with pacemakers a list of machines to avoid is definitely not to waste their time because there is no possible way any of those things could be dangerous to them.
As an RF expert I can assure you that I could create a device to wirelessly interfere with a pacemaker. A pathological one, maybe, but the point remains: regulation is needed.
The question is whether such interference could be created by a device as a by-product of its normal operation, not by a weapon that's intended to cause harm.
It couldn't be less relevant. It's noise that distracts from the interesting core of the topic. When I'm reading HN, I don't want a long string of "oh btw theres an account on this website called abc_defg". I doubt it's interesting to anyone with sense.
I've been toying with an idea of creating a JS runtime that tries to run all code two times, one which runs all identifying information inside a runtime that has any network API's stubbed, and another that replaces the identifying info with garbage.
Most likely needs manual quirk code overlays for sites, but it's totally a solvable problem.
archive.today has a documented history of altering the archived content, as such they immediately lose the veil of protection of a service of "public good" in my books.
Just my 2 ¢, not that it really matters anymore in this current information-warfare climate and polarization. :/
What do you want me to address? I'm just pointing out that there are no great archival services, and the only real alternative to archive.today is worse.
>Pay attention to this type of behavior, folks. It's revealing
Yes! That one. But we need it for video ads as well now.
Ads are an evil that must be removed from the internet, and draining the wallets of companies using ads, without upside, would make them place less value on them.
Assuming US, I think that the gov't can't actually compel speech from an entity e.g. force to keep signing the canary.
Warrant canaries are the way entities can circumvent the narrow case where the gov't actually can restrict your free speech, by creating a case where your lack of speak is telling. By this framework we can then come around again to the first point.
The point of a canary is that it's cryptographically signed, and it's possible to set up a duress passphrase that will delete the key when entered, so if everything works correctly an unauthorized party can't keep posting signed canaries.
reply