Great photos. I love your Norfolk robins. I also love that you've taken the time to set up browsing by species!
If you're at all interested in feedback:
- When scrolling through a gallery grid, the multiple fixed-position headers eat up an awful lot of screen real estate. On my MacBook Air (effectively 1280x800), I can only see one full row of photos at a time. Feels very cramped.
- Navigating to a photo from a gallery and then hitting my browser's “Back” button takes me back to the “Report” tab on the galley, not the photo grid. Makes gallery browsing pretty difficult.
- Maybe both of these problems could be ameliorated by making gallery photos open in the lightbox, rather than shunting you directly to their pages. Although...
- Items in a gallery's slideshow/lightbox display don't have a link to their photo pages. Maybe the name of the photo could link to its page?
Wow, cool – IMO, the galleries are so much easier to browse now.
I'm not sure if selling prints is a priority for you, but it would be rad if you could do on-demand prints. In the meantime, I'll e-mail you about a couple :)
I wish I had a better sense of how these zero-click vulnerabilities work so I could get a sense of how to protect myself from them (you know, without giving in to Liquid Glass). Can they be blocked by an ad blocker? Are they blocked by any extant ad blockers? What about “Lockdown Mode”?
"0-click example: receive an MMS with a malformed image that exploits a bug in decoding ..."
Consider a SMS firewall that:
- flattens text to ascii-256
- recompresses, noises and slightly resizes images and video
... and only then passes the message onto your real (SIM card) phone number.
This, of course, requires that you host your phone number somewhere like Twilio which has other added benefits like additional protection from SIM-jacking and being invulnerable to theft or loss of your handset, etc.
If this firewall is available as a commercial product, eventually it be infected, so there won't be any need to hack any client devices. Since this is clearly a niche product, the device manufacturer won't be able to identify and fix bugs as effectively as companies like Apple do. This follows ROSKOMNADZOR recommendations: to install a middleware device that decrypts, stores, modifies, blocks and redirects all traffic depending on rules submitted from external party.
It's a watering hole attack.
At any point your iphone sends an http request to a compromised site, by add, link, embedded, etc. your device will be exploited.
there really isn't a way to permanently defeat this.
We are about to see an explosion of novel attack types utilizing this exploit as their basis, you realistically cannot defend yourself against these without either updating or no longer using an iphone.
I think https://gitlab.collabora.com/hardware-enablement/rockchip-35... is still the best reference for mainline support of the RK3588. As you say, DP alt mode and video encoding are totally unsupported right now. Hopefully things will keep progressing; it's a very feature-rich platform, and I think it will have some legs even after it is no longer the compute king (e.g., the RK3688 is on the horizon).
My preferred conspiracy theory is that larger, brighter screens hold attention better, so everyone involved in the whole “user experience” (phone manufacturer, application developers, advertisers, etc.) prefers (whether they consciously realize it or not!) phones to have a larger screen. Smaller phones make fewer demands; who would want to make a device like that?
Several years ago in the UK, giffgaff had a similar plan (throttled to 384 kbps after 80 GB throughput) which they called “always on”. I thought that was a good linguistic compromise.
There's gotta be a bit more subtlety going on here. DHCP leases include a lifetime:
$ ip address show dev br0 | grep -m 1 valid_lft
valid_lft 69133sec preferred_lft 69133sec
It's possible that older versions of macOS persisted the lease details across reboots and reused unexpired leases on subsequent network reconnections.
I am also fairly sure that I have never personally seen any evidence of any OS doing this, including macOS, including when it was still called Mac OS X. I suspect macOS simply brings up its networking stack earlier in the boot process, so the network connection is more likely to be ready and waiting by the time the desktop loads.
Using the same lease is better but still could cause IP conflict if the lease was revoked and reused (though I guess that’s much rarer)
that said I do agree with you that the behaviour was probably not as described or at least not present in current systems because it would wreak havoc on public wifi etc
I’ve never dhcp being any sort of bottleneck so I hope their just doing the regular dhcp thing
You're getting downvoted, but you're not wrong. If anyone else had come up with it, it would have been ignored completely. I don't think it's as bad as some people make it out to be, but it's not really that compelling for end users, either. As other folks in the thread have pointed out, WebP is basically the static image format that you get “for free” when you've already got a VP8 video decoder.
The funny thing is all the places where Google's own ecosystem has ignored WebP. E.g., the golang stdlib has a WebP decoder, but all of the encoders you'll find are CGo bindings to libwebp.
Just like you used to be able to provide storage drivers on a floppy disk, you can now provide NIC drivers on a USB stick. (IIRC, there's a button for it on the Microsoft account sign-in page of the OOBE.)
You're looking in the wrong place. They don't need to be listening for mail on the machine behind the A/AAAA records for the domain, because they have an MX record indicating that mail should be delivered elsewhere:
$ dig MX gmai.com +short
1 mail.h-email.net.
Port 25 is very rare these days, as it implies the possibility of unencrypted traffic; legitimate SMTP traffic uses port 587. That said, I checked a couple of the hosts that that name resolves to, and they all listen for both SMTP and secure SMTP traffic:
$ nmap -p 25,587 mail.h-email.net
Starting Nmap 7.95 ( https://nmap.org ) at 2025-12-18 16:31 UTC
Nmap scan report for mail.h-email.net (165.227.159.144)
Host is up (0.093s latency).
Other addresses for mail.h-email.net (not scanned): 91.107.214.206 165.227.156.49 167.235.143.33 5.75.171.74 5.161.194.135 178.62.199.248 5.161.98.212 162.55.164.116 49.13.4.90
rDNS record for 165.227.159.144: mail2.h-email.net
PORT STATE SERVICE
25/tcp open smtp
587/tcp open submission
As far as I've been able to research, these typesquatting domain traps started at the same time as Spamhaus CSS blacklist which was actually a company called Deteque.
If the MX has a large number of Hetzner IPs as mailservers, then it's probably Spamhaus.
Signing, notarization, and hash checking just ensures that what I run is the thing that you meant for me to run. Source availability permits me to ensure that what I run is the thing that I meant to run.
If you're at all interested in feedback:
- When scrolling through a gallery grid, the multiple fixed-position headers eat up an awful lot of screen real estate. On my MacBook Air (effectively 1280x800), I can only see one full row of photos at a time. Feels very cramped.
- Navigating to a photo from a gallery and then hitting my browser's “Back” button takes me back to the “Report” tab on the galley, not the photo grid. Makes gallery browsing pretty difficult.
- Maybe both of these problems could be ameliorated by making gallery photos open in the lightbox, rather than shunting you directly to their pages. Although...
- Items in a gallery's slideshow/lightbox display don't have a link to their photo pages. Maybe the name of the photo could link to its page?
reply