For the last several months, eTransfers initiated from my desktop browser (Firefox on Linux, same as you) have required confirmation via the RBC app on my iPhone. Definitely seems like they have multiple scales of trustworthiness for people/devices/activity. Kind of wish they'd be more transparent about what they are, but I guess that sort of transparency can easily become a vulnerability.
These are also obnoxious - RBC has checked whatever box makes Google's RCS web app refuse to render them, so if I'm am my computer, now I have to get up and go find my phone so that I can manually input the code.
If you're using Gmail's “Send As” feature to use a different SMTP server for outgoing mail, then yes, you must have a proper DMARC TXT record configured on the domain you send from (even if it's just `v=DMARC1; p=none`).
Maybe a generator sized to run a regular home in perpetuity, but I bet it's much, much less than that to have an electrician install a GenerLink and to buy a regular portable generator just powerful enough to run your fridge and freezer.
Yes, as I understand it, this sort of problem is what “Name Constraints”[0] were designed to solve. (Well, really, they were intended to be used with corporate internal CAs[1], but there's no reason they wouldn't work more broadly, too.)
I imagine, too, that as better encoders become available, we'll be able to losslessly recompress existing JXLs, much as mozjpeg's jpegtran can losslessly recompress existing JPEGs.
Right. Although the article demonstrates the changes by making requests of a public web server, I would imagine this change has been primarily motivated by a desire to reduce overhead and latency on internal communication between microservices, which very often uses unencrypted HTTP/1 traffic.
reply