iancarroll

Looks like AI slop and certainly not wormable in the traditional sense. Hard to imagine that your access to a Tailscale SSH server would then allow further replication, and certainly it would not allow for meaningful cross-tenant replication.

Seems like they responded on Reddit: https://www.reddit.com/r/Tailscale/comments/1xekjpd/tailworm...

That doesn't seem relevant for the stated tasks, especially given they are running on Windows...

This was taken about five days after they discovered the device[0], so it appears to have been installed to catch the culprit. I was confused as well.

[0] https://www.justice.gov/opa/pr/saudi-national-arrested-insta...

Recently moved our RDS instances from r8g. to r8gd., which adds local NVMe, and I think the average I/O latency went from 1.0ms to 0.1ms. Adds up in big queries!

> “Even if that device does reboot for any number of reasons, memory maintenance or the power is lost or whatever, the AFU state is not lost. This is the true magic behind the GrayKey Preserve and the Evidence Preservation Mode function.”

Based on this, it seems more likely that this involves exploiting the device to retrieve the underlying keybags present in AFU mode and store them, rather than manipulating the actual feature of automatic reboots. Then the device can be exploited again in BFU mode but with the prior keybag to decrypt everything.

It sounds like this feature is being used to exploit and extract keys from devices without a warrant (or in advance of getting one), which seems dubious to me.

I think most people are using some variation of Chinese models due to the safeguards. I have some self hosting but the economics are bad - OpenRouter etc are a very competitive marketplace and usually better.

Pretty hard to implement in practice!

% dig www.tesla.com +short

www.tesla.com.edgekey.net.

e1792.dscx.akamaiedge.net.

<akamai IP>

We can quantify the impact of the scripting tools pretty easily - 1.5k requests per day! I just went on Reddit and viewed a few posts, and it caused about 500 HTTP requests in DevTools. Luckily HN is not that bloated, but I just don't see the number of requests as meaningful even if it was orders of magnitude higher.

As the OP said, they don't do anything when the server isn't vulnerable, and serving a 404 page is incredibly cheap.

Even before AI, I can't imagine a single bug bounty researcher doing that. Pre-AI, everyone ran a tool like subfinder to enumerate subdomains, httpx to resolve them, nuclei to scan them, etc. There's no human review involved there at the subdomain level.

And I don't know anyone that would really look at the intermediary of a CNAME even during a manual test. Maybe if it was obviously a third party service.

Are you confident you are not viewing too many pages on HN? What if many other people are also trying to read this thread?

I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.

I feel confident that no system exposed to the internet should have a problem with 50,000 requests per month! If they do, they probably shouldn't run a public NTP server, or have a public IP address at all.

The OP says they have received 50,000 requests in about a month. What service is being denied by 0.01 requests per second?

How do you suggest I determine the information is bad, if the domain is hosted on tesla.com, and Tesla says I am authorized to test it? Should I inspect all 1,368 subdomains on tesla.com by hand, and then do the same for 400+ bug bounty programs?

As a bug bounty researcher, my systems would do the same thing if they ended up georouted to this IP. *.tesla.com is marked as in scope on https://bugcrowd.com/engagements/tesla, and my agents will probe anything under there as it is presumed to have explicit authorization.

Not sure if there is a great solution, but I'm inclined to say that attack traffic like this is the new normal. In fact, the attack volume they got is quite small compared to the volume I have seen on other tech company subdomains - the new normal is probably much worse.

Prepaid cards are great for the vendor because they have breakage (the unspent amount before expiry). I doubt the data is worth much relative to that. If anything, they have much less of a tie to the individual.

Importantly, there is only an incentive for L2/L3 data on business/corporate cards, which have an inflated interchange rate above personal cards anyway.

This is not a scheme to get enhanced targeting data for personal transactions.

I agree, I have been in a lot of buildings where the elevators have extremely poor performance due to this. It can be 4AM but they are all configured to rest on one floor or something like that.

Looks great but the CLI output is not particularly interesting while the scan is running. I wish it could show token usage, some kind of progress, etc.

I've wasted so much money on vendor charging cables in the past 10 years while traveling or moving that I would probably buy this just for the USB-C port, assuming it is actually splash proof.

I wonder what HR sensor they use. Samsung apparently has an average error of 7% which is pretty bad, so I wonder if this would be worse. [0]

[0] https://www.cnet.com/tech/mobile/i-ran-30-miles-testing-5-sm...

We use github.com/go-webauthn/webauthn with no complaints!

In Shenzhen, they told me that I can take the full test on any visa if my permitted length of stay is 90 days or more. Supposedly the US embassies now issue 90 day visas for Americans, so I am hoping to try that route soon as I have already been through two temporary licenses...

Surprised to see this here but happy to answer any questions! Driving across China and getting to use the latest EVs has been quite fun and I hope to do it even more in the future.

Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.

Apps installed via the MAS have sandboxing applied to them, so this isn't really true.

The latest FSD does not attempt to check if your hands are on the wheel at all.

My Cloudflare enterprise order form has costs for overages for Workers and the following language about everything else:

> If Customer exceeds any of the Total Quantity for the Services below, Cloudflare will invoice Customer in arrears at a rate that corresponds to the rate set forth in the table after this one labeled “Excess Usage Pricing.” If no such Excess Usage Pricing table has been added by the Parties to this order form or if such table does not include the Service(s) for which Customer has exceeded the Total Quantity, then the Parties will negotiate in good faith an increase in the Fees for such Service(s). Should the Parties fail to reach an agreement on an increase within thirty (30) days of Customer’s receipt of notice from Cloudflare that Customer has exceeded its usage cap for the Service(s), Cloudflare will have the right to immediately terminate such Service for its convenience, and without liability to Customer or any third party.

Your whole account is undisclosed marketing for this service. Fingerprinting in this manner is highly unlikely to be viable - there are too many middleboxes at the TCP layer to try and fingerprint on it.

0.5% is a pretty incredibly low interchange rate in any case. But if you are saying that half of it is going to scheme fees, I doubt it is funding rewards programs for consumers.

Well, OpenAI already sold it (but kept the team), so it’s in someone else’s hands now.

I know plenty of security researchers who exclusively use Claude Code and other tools for blackbox testing against sites they don’t have the source code for. It seems like shutting down the entire product is the only safe decision here!