r1ch

That requiring users to install software that makes their devices vulnerable is not a viable security model.

There's still a whole business sector selling snake oil "anti screenshot" software and such to banks and government agencies and such (complete with vulnerable kernel drivers of course). They learned nothing from the ActiveX days.

We're on Enterprise Standard, our renewal was up like 50% because "Gemini is included now think of all the added value" yet they won't even give us the latest models. I tried hard to champion Gemini internally once every user had it included, yet we ended up spending extra on Claude because Gemini has stagnated. Even the included usage for the Gemini CLI was taken away and now requires an extra subscription. I wonder if we we'll even see Gemini 4 before 2028. It's ridiculous.

I came away frustrated by this too, I wanted to see the UI but it seems to be some kind of non-interactable embed instead of a video that I can fullscreen or popout etc.

Alongside this release I seem to have lost all thinking traces from all models - now it only generates a one-line summary similar to Gemini. I'm guessing this is an anti distillation measure? I'm surprised to see no one else complaining about this, it's a significant reduction in usefulness not being able to explore alternative angles that the model discarded in the final output.

Does Sol allow this kind of research by default or is this a "look at me I'm on the cyber research allowlist" post?

Even that isn't sufficient - I've been using this for years and every so often AWCC still manages to get through. The only 100% protection from it is to use Image File Execution Options to match on the installer name to prevent it from ever running.

Great for merchants, not so much for consumers. Once the merchant has your money it's very difficult to get it back if things go wrong.

Meta had(has?) a similar bug with one of their business manager features, the attacker has complete control of the initial body text which makes it highly convincing.

Trying to report this was an exercise in futility, I guess they get so much beg bounty spam that their security submission process filters out the occasional legitimate issue.

I've started to assume that any non-chain hotel is compromised after losing $2k to hackers that completely owned the hotel's email system. Thankfully DMARC made it irrefutable that it was their system at fault and they assumed liability. BEC is shockingly common and difficult to detect until it's too late.

The timeline is off too if the Trend Micro report is to be believed. It makes for a catchy headline, but a source is definitely warranted here.

I recently had to go through the recovery flow for an admin account and it was wild. Despite Google manually unlocking the account and giving me a reset link, every login was forced to authenticate via SMS using the (removed) phone number. Luckily I was able to get a hold of it and get the code, but even after adding a TOTP and security key 2FA, further logins still required SMS.

It feels like the security team made this change to reduce account hijacking but it's at complete odds with the recovery flow and modern security practices. Better hope your phone number doesn't get hijacked or recycled because it's the key to your account now, security keys be damned.

Anyone can request a CVE, this is sadly the most likely path towards getting it fixed.

Every shared hosting provider has this risk. Critical projects should be using dedicated or VPS hosting, preferably with encrypted filesystems too as even datacenter techs can fall victim to social engineering.

I'm pretty surprised that they got away with unsigned updates and shared hosting as long as they did. I wonder how many similar popular projects are out there on dodgy infrastructure.

Please do not take 5000mg/day of Vitamin D. The author confuses IU and mg which is very dangerous.

Yes, that's standardized but is only rated for up to 30 meters at the higher speeds you get from it, so it's not very useful outside of server room / data center applications and you probably want to be using fiber at that point.

The bottleneck with SFTP / SCP / SSH is usually the server software - SSH can multiplex streams, so it implements its own TCP-style sliding windows for channel data. Unfortunately OpenSSH and similar server implementations suffer from the exact same problems that TCP did, where the windows don't scale up to modern connection speeds, so the maximum data in-flight quickly gets limited at higher BDPs.

HPN-SSH[1] resolves this but isn't widely deployed.

[1] https://www.psc.edu/hpn-ssh-home/

OP mentions using "Cat 7" cables - please don't buy these. Cat 7 isn't something that exists in TIA/EIA standards, only in ISO/IEC and it requires GG45 or TERA connectors. Cat 7 with RJ45 connectors isn't standardized, so you have no idea what you're actually getting. Stick with pure copper Cat 6A.

The modern way to do this is with the Content-Security-Policy: frame-ancestors directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

Cloudflare will actually slow down TTFB for small, less popular sites since they don't maintain a keepalive connection to the origin. This means you pay an additional TCP/TLS setup cost from the Cloudflare POP to the origin which is worse than a direct connection. I also tried testing a smart-placed worker and cloudflared, neither of which seemed to help.

Ironically the AI crawlers I do want to block - the million-IP-strong residential botnets that fake their user agents - Cloudflare doesn't detect at all.

At first they were easily detectable using HTTP header analysis - e.g. pretending to be Chrome but not sending the headers that Chrome always sends. Now it's a combination of TLS / HTTP protocol level analysis and application layer - e.g. we send a cookie on the user's "normal" page view and check it exists on the higher-resource usage pages they might later visit - the bots don't care about normal viewing patterns and try to hit the higher-resource pages on their first visit, so they get blocked.

Residential proxy botnets have exploded since LLMs became a thing. The amount of DDoS-level scraping we receive from residential IPs has exploded over the last year, one of our sites that typically sees around 10k unique IPs per day jumped to over 2M before we were able to deploy appropriate mitigations. We originally started blocking the IPs, but then we ended up blocking legitimate users as they seem to specifically use ISPs that have very dynamic IPs (i.e. the customer's IP will change even if their router stays on 24/7).

This is the same direction that Microsoft is taking Windows. Smart App Control is already rolling out to some regions - no .exe will run without a code signing certificate.

https://learn.microsoft.com/en-us/windows/apps/develop/smart...

Loss-based TCP congestion control and especially slow start are a relic from the 80s when the internet was a few dialup links and collapsed due to retransmissions. If an ISP's links can't handle a 50 KB burst of traffic then they need to upgrade them. Expecting congestion should be an exception, not the default.

Disabling slow start and using BBR congestion control (which doesn't rely on packet loss as a congestion signal) makes a world of difference for TCP throughput.

Thanks, somehow I missed that entry.

How did you deal with the length of the USB and display cables? I thought after 5m or so things would start falling apart. Are there active extenders and can they can handle 240+ Hz?

This can also happen with IP addresses. We recently moved one of our sites to a new IP and got a trickle of complaints about it being inaccessible from various authoritarian countries. After some digging, the new IP was used as a Tor bridge (not even an exit node) over _ten years ago_. I gave up any hope of fixing that and just ordered a different IP address.

The end user typically has their device compromised by using free apps where the developers were bribed $$$ to add the proxy "SDK". The botnet operator then rents out the bandwidth at exorbitant rates to anyone who will pay for it.

Chrome extensions are also a huge source of this, they look for extensions with a large install base and then make an offer to buy it to turn all the users into proxies.

The re-encrypted part isn't necessarily true though and you have no way of knowing. Users are misled because they see a nice secure lock icon in the browser, but that only protects the connection to the local Cloudflare POP, the rest of the way to the origin is all vulnerable to MITM.

As a security company, anything less than "Full (Strict)" should not exist.