rjst01

Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?

If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.

Thanks for the suggestion. I'm on iOS but the notification settings look the same.

I already had all but one of the settings you mentioned disabled, along with most of the others. I'll report back in a day or two.

Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records.

(Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)

Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.

DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?

An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.

Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.

I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed.

And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so.

That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.

I had to completely turn off notifications for Instagram because none of the provided settings appear to disable the almost-daily "for you" and "trending" notifications. Now I don't get notified when someone DMs me there, which has lead to me missing important messages.

I was wondering exactly how hard factoring RSA-1024 would be today and found this stackexchange answer: https://crypto.stackexchange.com/a/111828

In summary, it estimates the cost at $3.5 billion using commodity hardware, and I'd expect a purpose-built system could bring that cost down by an order of magnitude.

Encryption for 30 years ago? Trivially breakable with quantum

I wouldn't be so sure - quantum computers aren't nearly as effective for symmetric algorithms as they are for pre-quantum asymmetric algorithms.

The headline here makes it sound (to me) like Salesforce did the study.

In practice, whether or not this actually works can be very hit-or-miss. We've found several UEFI implementations will not consider a disk bootable if the pMBR doesn't exactly match the spec, which specifies that the 'protective' partition shouldn't be marked as bootable in the MBR partition table.

Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.

Why? We are running the exact same images that we would be mirroring into and pulling from our private registry if we were doing that, pinned to the sha256sum.

It is a trade-off. For many services I would absolutely agree with you, but for hosting public open-source binaries, well, that really should just work, and there's value in keeping our infrastructure simpler.

Your case is simply prioritizing work that you would have wanted to complete anyway

It's busy-work that provides no business benefit, but-for our supplier's problems.

specific outbound IP addresses that they can then whitelist

And then we have an on-going burden of making sure the list is kept up to date. Too risky, IMO.

Amazon ECR for instance provides the option to host a public registry.

Let me give you an alternative perspective.

My startup pays Docker for their registry hosting services, for our private registry. However, some of our production machines are not set up to authenticate towards our account, because they are only running public containers.

Because of this change, we now need to either make sure that every machine is authenticated, or take the risk of a production outage in case we do too many pulls at once.

If we had instead simply mirrored everything into a registry at a big cloud provider, we would never have paid docker a cent for the privilege of having unplanned work foisted upon us.

Yeah, I agree that's problematic. And I would have no objection to implementing a UI feature that displayed a warning banner of some kind if it detected that the page had been translated.

They probably understand it just fine. Someone higher-up has just over-ruled them. There may even be a good reason for it, but because of the way companies work, we will probably never find out what it is.

Locale I'm using as a shorthand for "the bundle of variables that your service or business needs to tweak between customers in different markets". It may determine things like currency, date/time or currency formatting, or relevant regulatory framework. My argument is that language should always be sett-able independently of the other variables locale controls.

For an example of a site that almost gets it right, see https://www.finnair.com/ . You are first prompted to set location, and then language. I say "almost" because although they will allow you to select English in any market, they won't allow you to select any offered language in any market.

In comparison, https://www.flysas.com/ you get one dropdown which sets market, currency, and language in one go.

When I first ran into this issue back in 2017, I posted in the React issue tracker that I had ”fixed” my app by blocking translation entirely.

Please do not do this! In almost every instance I've encountered severe Translate-related broken-ness, it's still worked well enough to get me a snapshot of the current page translated. Fighting through this is still less cumbersome than the alternatives.

The only alternative solution that I can think of, is to implement your own localization within your app (i.e. internationalization)

I will add, please make sure that language is an independent setting, and not derived from locale! I sometimes have to use translate on sites that have my preferred language available, but won't show it to me because it's tied to locale and that changes other things that I don't want, like currency.

On one such site I used a browser extension to rewrite the request for the language strings file.

I was recently looking for an article I remember reading a bit over a year ago. I could even remember some exact phrases that appeared. I tried to find it on Google for more than 10 minutes, ultimately to no avail. I then went looking through chat histories and was able to find where I had shared it to someone.

I relayed this story to a friend who suggested I try Kagi. It was on the first page on my first attempt. I was also able to use it to find a different article I was sure I read even longer ago, that I didn't have as clear memory of.

One day I will give a lighting talk about the load bearing teapot, or how and why I made HTTP Status 418 a load bearing part of an internal API, and why it was the least bad option considering the constraints.

I've had to do some ridiculous things to get them to behave after installing Linux, like tricking the BIOS to deal with UEFI correctly

I would suggest going for a couple of generations newer - the M92p is from an era before UEFI became really stable. For automated testing of my startup's product we have a testlab of tens of older USFF desktops and the M700/M900/M910 machines are some of my favorites. They're also just before the cut-off for Windows 11 support so they're still available dirt cheap.

Two things to watch out for - the M700 lacks a PCI-E M.2 slot - the internal M.2 slot supports only SATA M.2 drives. Second, the front USB ports failing is a really common failure mode.

This was actually shown off at CES earlier this year, here's the only video I can find: https://www.youtube.com/watch?v=GqCwLjhb4YY

In this it's claimed that Intel is doing a direct framebuffer copy. I'd say the "Microsoft’s Remote Desktop without all of the setup." is editorialising.

It's not the clearest shot, but the latency shown at 30s in that video looks pretty good to my eyes.

On the other hand I've been caught out by tech companies making exaggerated claims about pre-release products before, so who knows, maybe it actually is no better than VNC.

Yes - but as this is a purpose-designed protocol for display transport over thunderbolt, I would expect it to perform better than a remote desktop solution intended to go over a potentially low-bandwidth network.

In the past I've found that using RDP to a VM running on localhost can actually perform better than the console provided by the VMM, but it's still not close to the experience of using the OS natively. I would expect this to be a lot closer.

I hope we get a mac client for this at some point - travelling with two laptops sucks, so bringing a NUC I could remote into with good performance would be a huge win.

I agree in principle, but I think there has to be some room for exceptions here. Some portable devices like smartwatches are too space constrained for USB-C and some devices might use too much power for USB-PD but still be too small to include the power supply internally. Also, some of my synth gear uses a locking barrel connector, which I think is a better trade-off than a locking USB-C connector because it can be locked and unlocked faster.

Bundled power bricks are also much less likely to directly be e-wasted without being used.

A hill I will die on is that tech products should just stop bundling cables, for anything, with the possible exception of unit-specific power adapters. A while back I purchased a KVM switch - it came with 3 DP cables, which went straight into my e-waste box. I've also seen office fit-outs where mountains of cables that came with monitors went straight from factory to landfill because they were the wrong length.

I understand some of the reason it happens - it's not a great experience to buy a product and then be unable to start using it immediately because you don't have the right cables. And there are a lot of low-quality cables out there which might have the right connectors but not actually work - I bought at least 3 different 5m DP cables before I found one that reliably worked at 4K. But surely that can't justify the literal mountains of e-waste the practice creates.

Sadly I don't think it'll ever change without regulation.

Embedding the Starlark interpreter into a Rust program took me less than an hour. There's little more to it than adding the crate and calling into it. No futzing with the build process.

If starlark does everything you need (and especially if its limitations are desirable for your use case) then it's the clear choice in my view.