justsomeadvice0

I think GP intended to convey "under the price in the article" ($83/kwhr).

IIRC macOS got rid of privileged ports for these reasons. Dunno about iOS... But in any case what cell provider is going to let you handle inbound traffic? Most of the wifi networks you are on are NAT'd, etc. At best you'd probably want an outbound persistent tunnel that is "terminated" by a relay elsewhere. At that point you might as well just have the relay host the thing.

Yea, agree with this guy. Anyways I took "novel attack vector" to just mean "first time we've heard of using SSPR against AD". They even used the existing acronym "SSPR", so they're not claiming to have discovered the attack vector or anything.

They just claim to have identified abuse of an "SSPR" attack happening against Azure AD in the wild. What part is a lie?

While you can't memorize it (memorizing a fair amount of entropy would take an intelligent human quite some time), you can of course store them offline (it's just a key). Today's initial implementation on macOS restricts exporting, but that is supposed to be added according to reliable Apple devs: https://hachyderm.io/@rmondello/110329118270492669

A long time ago I wrote a variant of this - the signup page would generate a token, place it in a hidden password field, submit a hidden form, and instruct the user to click the "Save password" dialog in their browser. One advantage of this was e.g. Chrome would sync the password immediately across all your devices (in some ways this was a privacy violation, although one that the user had to explicitly opt themselves into). New sessions (e.g., if you reset or lost your browser's stored passwords) still happened via email verification, though.

Today I would just use passkeys.

doing basic entropy checks on a user-provided password pretty much solves the issue anyways.

No it does not. Users will find one high-enough-entropy variant of their password, and reuse it across all sites for life.

Authentication is pretty much a solved problem

Hrm. It might be solved for you and users like you - but it depends on your site's demographics: most internet users on the whole will not know anything about encrypted "password lockers" and "physical Webauthn tokens". Browser-managed passkeys, on the other hand, stand some chance of being easy enough to use while enforcing good security and high entropy secrets, but lack widespread adoption so far.

You can use mTLS client certificates (kept in the system key store) in browsers this way; but the UX is pretty hard to get right, and certificates nearly always have to have an expiry date to deal with the compromise-able nature of keys imported into the system key store.

Lots of people end up with AgentForward on by default as a sort of "make it work" fix, and lots of people use `git+ssh` on untrusted servers. Here's an example:

https://abyssdomain.expert/@filippo/109659699817863532

TBF this is a vulnerable config either way; but RCE on the client shouldn't be possible.

Social media networks with over 100,000,000 daily active users should not be considered as "private companies with a right to free speech through censorship". They are effectively public squares that we have all elected and chosen to share. Right and left alike.

Shouldn't this also apply to TV channels? Chat apps like iMessage? Popular newspapers, blogs, and email newsletters? And indeed, why stop at 100M DAUs - why not 10M, or 1M? The problem I expect is this path leads to the death of freedom of the press.

It took me a while to understand what you were talking about at the end there. I think the author is referring to a grammatical period ('sorry' vs 'sorry.'), not the menstrual kind, lol.

This strikes me as a very strange opinion, especially now when Threads has 100M users 5 days out and is expected to support ActivityPub. In any case: since the beginning, pointing and laughing at Mastodon (a single AP implementation) was always like saying "Yahoo Mail will never win the electronic messages war!!" - it misses the point, like, entirely.

Trying to be fair here - it's technically not linked to any blockchains. It's just (ab)using the cryptographic primitives provided by the Metamask wallet app to sign things with a key stored in the wallet. That key might (probably) also be used to sign things that end up on any sort of blockchain, e.g. ETH.

The reason to do this is some people do indeed have Metamask (a browser extension, yuck) already installed and a wallet set up - so technically this might be an easy way to enable signing for them.

The reasons not to do this, I already detailed above. It is a neat hack, that would fare tragically when applied to the masses.

Because they clicked a button in this incredibly intuitive UX that said "Sign wiki edit", and then clicked "Confirm".

I think you massively overestimate most users' grasp on cryptographic primitives...

I have never tried Waze, forgot there was a third option. Will have to give it a try after reading this thread; maybe it avoids some of the bugs in gmaps I keep running into

Sorry, but this is an absolutely terrible idea.

Signing things is cool. Humans on the internet should sign more things. But why in the world would you want to use the same key that can instantaneously shred the dollars in your bank account to ensure authorship of some edit on a website article? The UX for these two things should be incredibly different; instead you are setting people up to get phished and lose their savings.

Agree the quality of Apple Maps has improved to the point of acceptability in my experience. In addition to privacy reasons, I end up using Apple Maps because Google Maps has been having a lot of really terrible bugs for me lately. Probably 10+ times over the last few years it re-routes me down random side streets or back country roads, for no reason: sometimes even when it itself thinks doing so will add a significant amount of time to my travel! But for business search and reviews, Gmaps is still unparalleled, so it stays installed.

That sounds horrible and I would immediately quit the ecosystem... I have never experienced this in nearly a decade of use, but I also pay for TV+; is it possible you got the bad luck of getting a terrible A/B test or something?

Yea, I gave up after:

Sure, the MacBook Pro I’m writing this article on works incredibly well — it’s objectively the best laptop I’ve ever owned — but it’s also the same thing everyone else has.

The VPR Matrix laptop was somewhat interesting though, I never knew those existed. Looks pretty nice for 2005.

To my knowledge all modern DCs have out-of-band networks for this sort of thing that provide serial access to the BMC chip, nothing old school about that. Old school is having to submit a ticket to Jerry in the DC to walk the crash cart down to box 55AE, hook up a serial console, run diagnostics, and attach the output back to the ticket. You only have to deal with Jerry occasionally now, usually when the BMC or power rails fail.

If you are split-cloud under a homogenous puppet master without homogeneous break-glass SSH access (which would be crazy) then probably your best bet is to just re-kick the world. But the scaling factor for this sort of thing is most certainly not team size; it's "how many X servers can be down at the same time", which will increase with your number of servers. In any case I think the FTC is the least of twitter's concerns right now.

Been there before, we did exactly this; except over OOB+reboot-into-single-user (because SELinux). Took us a few days (~5k servers) but managed to get out of it with no public-facing downtime. The other way would have just been to rekick the world one box at a time. A number of integration tests were added after that disaster :)

It's about cutting off any free exit ramps (people that use bots to xpost and tools that allow you to find/follow friends on new platforms), same as before.

Then you make people choose: Twitter or "them".

Lots of folks can make the hop from SRE to pentesting; much of the knowledge space - especially post-exploitation - is very similar! You have the advantage that you know how to operate on a production box without accidentally destroying or interrupting it. There are tools to learn, but I think you would find it to be an easy transition.

In more mature environments I would say up to 20-30% of a pentester's job can be finding bespoke vulnerabilities, 30+% is writing reports, so you get some good exposure to those; these are the exact skills you need in vulnerability research. If possible, request a ridealong with your company's pentesters in your environment, usually they love that: SREs know where the bodies are buried.

Research itself is a bit harder leap to get into straight from SRE; definitely far fewer junior roles. A lot of companies hire up researchers internally from their red and blue teams. Bug bounties are a way in without operational experience; without doing one or the other it's a bit of a tough sell. I would recommend a year or so on a red team and try to spend as much time as possible doing vuln-researchy things. Find some interesting things, communicate them effectively, and you will be well-poised to get into research.

good point

Imagination is not enough, we're going to need some hard data

Yes and I literally agree with you in my post. The problem is, as you admit, that data exists to point toward either conclusion; then you immediately speculate that the difference must be because:

these cases tend to be biased towards health care settings

You linked to an article wherein the company itself deemed its own research into a different mRNA-type vaccine for a separate disease as not yet safe for human trials. This sounds like the type of caution you want to see from a vaccine research company.

Personally I would speculate the much larger "part of the issue" was that there was never any real need to seek authorization for mRNA vaccines in the US before COVID19, as alternatives for their targets existed. I would also speculate cardiovascular issues in mRNA COVID19 vaccines (which are real certainly) have something to do with spikey proteins in your bloodstream, and one can imagine what a more prevalent spikey virus might do to the same person. But I am not a doctor or medical researcher, just some guy on the internet who reads things; so I would not really put any stock into my speculations.

edit: my point is: it's good to be skeptical of things. Yes. It's not good to share inaccurate information, as the post above yours did.

Nit: mRNA vaccines were used in human trials for cancer immunotherapy starting in 2001, rabies in 2013, ebola, zika, influenza, cytamegalovirus, etc followed. It's not accurate to say the technology had "never been used in humans before" COVID19; but the US FDA had never approved widespread use of it until then.

I read a bit more, here is how it works, from the white paper: https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...

Authorization is performed by presenting a valid, anonymous token based on RSA blind signatures. These signatures are sent as one-time-use tokens to each proxy when establishing a connection, separating legitimate from illegitimate devices. The proxies can validate the tokens with a public key to validate that the user is legitimate, without actually identifying the user.

The following fields related to anonymous token issuance are logged as a part of Private Relay’s fraud prevention and anti-abuse measures, but cannot be correlated with connection information: • iCloud account, software version, and request timestamp

Sounds like both Apple and Cloudflare hops get the token. But Apple stashes a mapping of the token->iCloud account on its end, presumably to deal with fraud requests from Cloudflare. So my understanding then is if Apple gets a fraud/abuse request for someone's token from Cloudflare, it can and will banish your iCloud account from the service.

Edit: on closer reading I think I was wrong... The stated logged data could just be to rate limit the tokens you can request. It doesn't say they log the token itself, and they do say "cannot be correlated with connection information". So it seems you are right!

Oh I see. Yea TBH I'm not sure what happens sure if hop 2 (e.g. Cloudflare) reports fraud/abuse "up" to Apple; whether Apple takes action or not. It would certainly be technically possible but would require cooperation between the two companies, that's the only guarantee I can find. Private access tokens are a real solution here, so maybe Apple does nothing in such a scenario and expects end sites to verify those.