7to2

Does this mean we will be able to embed private keys and API keys in deliverables? (i.e. to cryptographicaly sign artifacts, APIs tokens, and other niceties).

Sucks that DRM and user rights violations is about to get much much worse.

They stopped?

Trust on first use is absolutely a valid use of PGP signatures that is being used in many real world systems (ask me how I know). You finding that PGP isn't being used they way you think it should does not justify removing it without providing a replacement.

Why on earth wasn't the community asked before you implemented this change?

> Given all of this, the continued support of uploading PGP signatures to PyPI is no longer defensible. While it doesn't represent a massive operational burden to continue to support it, it does require any new features that touch the storage of files to be made aware of and capable of handling these PGP signatures, which is a non zero cost on the maintainers and contributors of PyPI.

This uninformed reasoning is what's indefensible.

That quote doesn't make any sense even if we stopped at the first part. I PGP-sign my packages and my key is not on any public key server. It's on my website. This reasoning lacks rigor and seems to only serve as an excuse to remove a feature that some pypi devs didn't like without offering an alternative for security guarantees that it provided.

Doesn't 5G share some of the frequencies used by normal wifi? IIRC devices implementing one standard even cooperate with devices implementing the other to coordinate frequency use.

Where did you go to? I'm in a similar boat.

ARM offers the same possibility.. in exchange for a fee and a stack of NDAs. Competition and openness is how we should deal with this disease.

> You are in an echo-chamber.

Doesn't matter. An echo-chamber that your target demographic frequents can be just as damaging to your overall reputation if not more.

Source: Someone currently working in government IT procurement who is literally in charge of evaluating cloud-based products (hi, google!).

Also funny you mention Paypal and Stripe: At my last job, we chose to go with traditional payment processors in large part because of how frequent stories about Paypal and Stripe screwing legitimate companies pop up.

That's why I'm rooting for riskv processors, so that we can get the equivalent of reproducible openSSL binaries. US chips that are found to be irreproducable can be rightfully ignored.

Exactly. Even if we assumed for the sake of argument that wifi cards have complete access to the system, that in and of itself does not excuse CPU vendors to broaden the attack surface and prevent owners from narrowing it back down.

I can't wait for riscv systems to take off. Hopefully we'll get more than the two horrible choices we have now and, hopefully, they won't be able to abuse the market in the same way.

Screw both intel and amd for deliberately putting us all at risk.

> [ ] Always choose this option.

It's not that they don't understand it, it's that they don't want the average user to have a convenient way to control this setting. Prompting the user for permission would give the user a very convenient way to keep it disabled for most websites. It's as simple as that.

Think about it this way: Which is more tedious: going into the settings and enabling and disabling webGPU every time you need it or a popup? Which way would see you keeping it enabled?

Its tyranny of the default with an extra twist :)

> But closer inspection showed that its use was to get user's IP address for better fingerprinting.

Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]).

[1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(