I'm going to go out on a limb and guess you don't manually check the headers for every single email, or even only every one from Google and co, so are you doing something to flag or visualise this in some way?
Whenever I get an email that seems like it's a scam or scary like this I will open headers and the Received headers (sometimes even a From et. al. are enough) will give it away.
In zero cases did I care about SPF, DMARC or DKIM.
I recognize that this is not something non technical people or even technical people that don't know how email works and that don't have a broader technical ability/knowledge can usually use/do but it has worked 100% for me so far. knocks on wood.
I literally only skimmed the article looking for any place they might show all headers and finally when they had the list of Received I was like: duuuh, that's the first you should have looked at and this would be a non blog.
So of course it's still bad this happens as most folks, even technical ones, couldn't read email headers to save their lives and rely on little badges and filters based on things like DKIM to keep them safe.
The sibling comment basically answered for me; I don't check the headers unless I'm feeling suspicious, and such an immediate urgent call-to-action definitely counts as suspicious.
It helps that I'm using a client which shows all the headers by default, and I normally just scroll past them if I don't have doubts; all the mainstream consumerist ones seem to make that very difficult or even impossible.
If anything, it seems hiding these details is a way to increase blind trust in things like DKIM and promote learned helplessness, so they have the incentive to make clients opaque.
Ah right, that's odd, wasn't aware I lived in a totalitarian society here in the Nordics. We literally just get a notification to check it, and because the state is neither trying to gotcha us or baby us, that's just the norm. The part that takes longest for me in the whole process is usually the 2FA.
Forgive my ignorance, feel like it's embarrassing to ask here to be honest, but can someone explain how this helps/works? I've never actually used these placeholders, but I always imagined that they work by processing the image beforehand on the server and using something like a super low quality image or gradient or such as the placeholder. If this is done in pure CSS, does the browser not need to download the image first to figure out what's in it, before then doing the placeholder effect? Perhaps it doesn't help that I've not had my morning coffee yet, but I don't understand.
These placeholders are generated by processing the image on a server beforehand. Generally they create some html, css or svg markup that is served inline. Having to do a separate request for such placeholder is very bad idea.
It's not clear if these placeholders do actually help, especially placeholders with very low quality. In my opinion, they only add visual noise.
I'd focus more on avoiding layout shifts when images load, and serving images in a good format (avif, webp) and size (use `srcset` or `<picture>`).
> It's not clear if these placeholders do actually help
Well, it depends what you mean by help. It’s very dependent on use case and desired UX. Obviously you can prevent layout shifts without them, you can provide feedback on loading status in other ways, and ensure images don’t slow load time without colored placeholders. But they can provide a pleasant UX for some use cases, when done right. They can be annoying when not done well.
There are certainly legitimate cases where the placeholders come from a separate request. Most
CRDTs and similar sync engines you don’t want to (and/or are not allowed to) store binary images directly inside them, so you need to store references to some other blob storage. But Blurhash is a simple short string (and LQIP here is a simple integer) and those store well in CRDTs and other sync engines, so you can pair that with your reference pointer (which might not even be a URL depending on your blob storage engine and its sync mechanics and authorization schemes and whatever else) and whatever other metadata you want/need to include like width/height or aspect ratio and alt/title/caption.
When the CRDT or document sync engine inevitably sync much faster than your blobs you have something to show in that placeholder. If the blob sync fails for some reason, you still have something to show more interesting than your browser’s old broken image logo under your “Sync is slow or broken” warning.
I think placeholders help a bunch in situations like that where your image fetch is a lot more complicated than a URL that you can add in a `src` attribute. It’s also really easy to get into situations where such blob fetching is complex: In cases where you have to respect user and/or tenant privacy and need complex OAuth flows. In cases where you need end-to-end photo encryption. In cases where you need peer-to-peer sync and only P2P sync because you’ve been mandated to reduce touch points and likelihood of accidentally storing photos at rest in middle layers. Situations like images of HIPAA data, PII, PIFI, etc.
On a static site with public (or cookie sessioned) images direct linked by URL, yeah the placeholders don’t do much other than check certain design boxes. There’s lots of other places images (and their metadata) come from, and placeholders are a useful fallback in the worst cases.
It’s still computed at build time or dynamically, by a programming language. The “pure CSS” part of it means that the hash is decoded into something visual by CSS without any JavaScript required.
This same thing happening on the 40 series cards was good enough vindication for me not 'upgrading' to that at the time. I'd rather not burn my house down with my beloved inside.
I can relate to this perspective! It's important to step out of the system and recognize priorities like this; balancing risk and reward.
I think, in this particular case, perhaps the risk is not as high as you state? You could imagine a scenario where these connectors could lead to a fire, but I think this is probably a low risk compared to operation of other high-power household appliances.
Bad connector design that's easy to over-current? Yes. Notable house-fire risk? Probably not.
If you're using iOS you can set certain contacts to bypass silent mode so that you still hear their notifications/calls. I know it doesn't help with unknown numbers, but just saying in case you're not aware. I'd be surprised if you can't do the same on Android.
Yes, thanks, I've configured that for kids and other loved ones. But I can't pick up anything else, even sales people from India manage to use a number that appears local (in The Netherlands for me), so I might miss a call from the kid's school.
I've just added the numbers of my kids school onto the list and it's been fine for me. I've never had them contact me from anything other than the schools number, but I'm in the UK and I would be very surprised if a teacher tried to call me from their mobile phone or something.
Oh wow, I knew this was a rampant problem in the US, but I didn't realise we had that at that scale here in the Netherlands as well. Hoping I can dodge the bullet a little longer...
The clones are limited though, are they not? Like, they don't have the directional stuff and all that do they? I may be misremembering what I've read elsewhere.
> Analytics in Home Assistant are opt-in and do not reflect the entire Home Assistant userbase. We estimate that a third of all Home Assistant users opt in.
I'm a big fan of home assistant, and use it to control a LOT of my home, have done for years, have tonnes of hardware dedicated to and for it, and I've also ordered some of these Voice devices.
