It seems like Fillipo has been working quite closely with people running existing ct logs to try and reduce the requirements for running a log, so I'd assume he has a fairly realistic handle on the requirements.
If all certs are sent to just one CT log server, and each cert generates ~10KBytes outbound traffic, it's ~200GB/day, or ~20Mbps (full & even traffic), not in the same ballpark (2-3Gbps).
So I guess there are something I don't understnad?
I've been trying to get an understanding of this number myself as well. I'm not quite there yet, but I believe it's talking about read traffic, ie serving clients that are looking at the log, not handling new certificates coming in.
I added a footnote about it. It’s indeed read traffic, so it’s (certificate volume x number of monitors x compression ratio) on average. But then you have to let new monitors catch up, so you need burst.
It’s unfortunately an estimate, because right now we see 300 Mbps peaks, but as Tuscolo moves to Usable and more monitors implement Static CT, 5-10x is plausible.
It might turn out that 1 Gbps is enough and the P95 is 500 Mbps. Hard to tell right now, so I didn’t want to get people in trouble down the line.
Happy to discuss this further with anyone interested in running a log via email or Slack!
Yeah the requirements aren't too steep here. I could easily host this in my "homelab" if I gave a friend a key to access my utility room if I were away / unavailable.
But 2-3Gbps of bandwidth makes this pretty inaccessible unless you're just offloading the bulk of this on to CloudFront/CloudFlare at which point... it seems to me we don't really have more people running logs in a very meaningful sense, just somebody paying Amazon a _lot_ of money. If I'm doing my math right this is something like 960TB/mo which is like a $7.2m/yr CloudFront bill. Even some lesser-known CDN providers we're still talking like $60k/yr.
Seems to me the bandwidth requirement means this is only going to work if you already have some unmetered connections laying around.
If anyone wants to pay the build out costs to put an unmetered 10Gbps line out to my house I'll happily donate some massively overprovisioned hardware, redundant power, etc!
You can rent 10gbps service from various VPS providers if you can't get the bandwidth at home. Your home ISP will probably have something to say about a continuous 2gbps upstream anyway, whether it's through data caps or fair use policy.
Still, even in Germany, with its particularly lacking internet infrastructure for the wealth the country possesses, M-net is slowly rolling out 5gbps internet.
I wonder how much putting a CDN in front of this would reduce this.
According to the readme, it seems like the bulk
of the traffic is highly cacheable, so presumably you could park something a CDN in front and substantially reduce the bandwidth requirements.
Yes, the static-ct api is designed to be highly cacheable by a CDN.
That is one of the primary motivations of its design over the previous CT API, which had some relatively flexible requests that led to less good caching.
I pay roughly $800/mo each for two 10 Gbps transit connections (including cross-connect fees), plus $150/mo for another 10 Gbps peering connection to my local IX. 2-3 Gbps works out to less than $200/mo. (This is at a colo in Denver for my one-man LLC.)
If you’re paying metered you’re off by an order of magnitude - much more expensive. Even bandwidth based transit will be more expensive than that at most colos
I've long wished for built-in browser functionality that converts times to the user's preferred time zone, with perhaps a dotted outline indicating that a change was made by the browser to the page.
This is worth proposing. A tag where fallback text is provided within which can be overridden by the browser with a formatted date string would be excellent.
I used the <time> element in a subscription dashboard.
All times on the page are in UTC and are wrapped in a <time> element. The raw UTC time is on the datetime attribute and a fallback more easily readable time is inside the tags. Some JS on the page removes whatever text is inside the tag and replaces it with the user's locale specific format (no libraries required, it's a part of the browser standards).
User friendly times wasn't actually the reason we implemented it.
Our largest concern was our E2E testing. We needed to make sure that the dates/times displayed were always right (and since subscriptions involve money, we wanted to make sure that part of the website was the most tested.) The E2E testing simply ignores whatever is inside the tag and reads the datetime attribute instead. Then we can fastforward or rewind the simulated time inside the test to make sure everything is working as expected.
Yeah, but, I mean, the least you could do is to say UTC-7. I'm sure everybody living in PDT knows it's, well, their time, but how the fuck should everyone else know what time PDT is.
What I learned recently is the way Python strptime deals with this. It only parses the current time zone or "GMT" or "UTC" and all have the same effect (of returning a tz-naive object). This behavior is amazing because I don't think it's ever what you want.
How is CST ambiguous? Are you thinking of all those counties in Indiana that don't observe daylight savings? In theory at least, a specific instant in CST maps to a single specific instant in UTC, GMT, CUT or Zulu Time, whichever you set your watch to.
And it does seem like people sometimes forget that CST is not the same thing as CDT. Several months ago (after the 2024 PST -> PDT crossover) I had someone across town tell me they wanted to set up a meeting at something like 9AM. But when the invite came, the time zone was set for 9AM PST instead of 9AM PDT. I assumed it was PDT since we were in the same locality. But I did make sure my schedule was clear for the hour before on the off chance they had some weird software bug that picked time zones at random.
If your point is something similar, then I heartily agree. In theory, converting between time-zones and daylight and standard times is easy, but in practice there are several situations where it's made more difficult than it should be.
I was referring to the multiple timezones that are abbreviated to "CST", as described in a sibling comment.
But you bring up another good example. I've worked with people who write times as "PST" or "EST" all year long. This bothers me in its simple incorrectness -- I do know what they mean but I hate autocorrecting them.
But I've also worked with people in parts of Indiana, and Mexico. When they say "CST" at any time of the year, they might mean it precisely!
My strategy is to write, e.g. "8:30 AM US/Pacific". Which probably annoys other people, but at least it's precise and unambiguous. I think it's less awkward than the equivalent "America/Los_Angeles".
Full list of US lower 48 timezones: US/Arizona, US/Central, US/East-Indiana, US/Eastern, US/Indiana-Starke, US/Michigan, US/Mountain, US/Pacific.
Yes, this can be super painful, especially when correlating information from several sources, or when traveling. It can become almost impossible when reviewing historical data.
My solution to inconsistent time rendering in AWS (sometimes UTC, sometimes localtime) is to run a separate browser profile for AWS (and third party status pages) that that's always running in UTC.
But seriously, status page people: there's no excuse for being vague about timezones!
