Busy servers generate more heat. Inefficient code makes servers busier. There’s a real physical outcome for bad performance code at scale.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
London has lots of datacentres in Slough (near Heathrow) and Docklands (London City Airport, but also many LHR planes transit over).
AWS/Azure/GCP/etc Colo in Equinix/Telehouse datacentres there, and those Docklands locations in particular were picked based on location to LINX (major London peering/interchange), and LINX was put in Docklands out of desire for relatively proximity to telcos, and London’s banking/finance industry.
Semi-related, there are some very cool converted datacentres in the UK.
The Bunker operates an underground datacentre out of a former military installation. Radar base if memory serves me. That’s definitely hardened from airplane attacks and I believe is used by some hyperscalers.
DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against?
He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies).
What’s his next step if the authors publish as an information RFC? He can’t stop that, right?
> What’s his next step if the authors publish as an information RFC? He can’t stop that, right?
This is a slightly complicated question. There are several main routes to an Informational RFC.
* Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages.
* Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed.
In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.
Thanks for the clarification. It’s a bit of a shame as going via ISE would have let the group move onto other endeavours. Maybe people will just refer to the draft name and that’s that.
Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".
I’m a passive observer on the same list and have been for at least several years. I don’t plan to comment on the WGLC currently going on… but I will be so extremely happy once the subject is done with.
It’s like watching a cybersecurity version of Dawsons Creek or The Young and the Restless or… Jerry Springer?! Insane
There used to be - probably still are - cameras that would digitally sign all their images. Used in crime scenes? Maybe we will end up seeing wider adoption of this, despite the privacy implications. Hackers attention then will focus (once again) on the certificate supply chain and crypto hardware.
What about a system that saves in some way the hash in a Blockchain, and if you, eg, XOR the hash of the video with the hash of the previous block you will "certainly" know that the video was created between the previous block and the block where the hash is saved in. That's a starting point.
Like when people discuss voting, I believe a blockchain [0] is a terrible pitfall compared to a classic distributed database system of predefined nodes run by different organizations. For example, imagine a couple hundred predefined nodes run by different states, federal agencies, etc.
An attacker altering the ledger would still require compromising an unreasonably large number of independent groups at once, and even then the rest would be able to clearly see that some unusual and suspicious event occurred.
By limiting membership a bunch of problems simply vanish, like long-clearing times, wasting hardware on mining, vulnerability to foreign botnets, etc.
[0] A blockchain is distinguished by its core requirement, from which a cascade complexity flows: Uncontrolled node membership. Don't be fooled by people pitching "private blockchain", its a contradiction in terms designed to rehabilitate hype, like "multi-sample Theranos test" or a bicycle as "Segway passively stabilized inline wheel model."
You just described IBM's whole Hyperledger Fabric thingy. I worked with it once upon a time, with the biggest insurance companies in my country where they plus a regulator all ran nodes.
it does something, sometimes. it pushes the required fabrication timeline back.
if it is mandated that every photo or video taken for the possible use in evidence is notarized at the time of acquisition, any fabrication would necessitate total premeditation. that is, the fabricators would need to know ahead of time what they were pursuing and what evidence they would need. this seems like a very costly barrier.
for example, altering security footage would require some fantastical elements: a real-time system of ingesting real footage and altering it in real-time to slip it into the notarization pipeline within the error margins.
requiring that any equipment that produces acceptable evidence stream commitment hashes in real-time to public append-only repositories would be an enormous step forward.
"Crack the hash"? Does this mean you were employing some novel hashing algorithm and relying on its secrecy? If so your employer were never serious about security in the first place. Hardware attestation is more or less a solved problem, and that solution does not involve secret algorithms.
Eh. It was some kind of hash of the image. I was not involved in that project, so can't tell you exactly how it worked, but the images were "signed," and someone figured out how to "re-sign" an altered image.
Sure but conceptually no one should've been able to crack any hashing scheme anyone half-way decent at their job could come up. SHA256 is the default and it's unbroken. Even SHA1 has scant few known collisions. So like...what the heck were they hashing and how that anyone was able to crack it?
Most likely is either extracting the private key from the camera or getting the camera to sign arbitrary data. If the signing isn't part of the sensor die itself there's a bus where the image data gets transferred from sensor to signer, so an attacker can inject arbitrary data onto that bus to get it signed, even though they never actually extract the signing key.
I imagine in this age of blockchains you could embed into a media file a signature that proved it was no older than the timestamp of when it occurred, the digital equivalent of a hostage-proof-of-life photo with a recent newspaper
But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time
> But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time
Many (most?) blockchain mechanisms include a timestamp in each transaction on the chain, so while multiple records from the same owner prove little (the timestamps could be faked over a given period of time) the interaction with the wider network and the chain would give some confidence that the record happened between within a small amount of time.
The other possibility, that doesn't require a chain with many independent active participants, is to have things signed by an external trusted authority. Submit a hash of the content and appropriate metadata to them, and have them sign it with a signing timestamp. I've considered abusing ACME certificates for document signing like that: the hash of content (or some signature based upon it) becomes the subdomain to sign¹ and you get a certificate that even after expiry is evidence that the CA saw that value at the signing timestamp. Note of the signing will also be in the public certificate transparency log. This wouldn't, on its own, prove anything about the authenticity of the content, that could have been doctored before signing, but it does prove that the content+metadata existed at that time (so might be more useful in copyright claim type cases, or agreed contract situations where all parties have signed the content and the signatures are included in the metadata, than for proving authenticity).
----------------
[1] based64²-ed with non-alphanumeric characters removed and truncated³ to fit or split, so acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.domain.tld or acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.w5jmmkpmyfgshx2jecsfordpnq.domain.tld
[2] names not being case-sensitive drops some of the entropy, if that is a concern use a 32-bits-per-character encoding instead and have names twice as long
There isn't a way to externally sign/validate a TXT record, that I know of.
A TXT record may be used in the signing process if using DNS verification, but you are getting a certificate for the name overall so using an A record to hold the hash you are looking to certify does the trick, then if you want to use HTTP-01 for verification rather than an extra DNS record you can.
You don't need a blockchain for that. You just need some reliable-enough way to publish hash(image) with a timestamp - some way that it's infeasible enough as to be considered impossible for thepublisher to change the hash or the date.
Back when I was on Twitter and following a lot of infosec accounts, it was quite common to see tweets that were just a hash. Sometimes they'd have an explanation "Zero click RCE in Android 10 - {hash}"
In the past I've used gmail for this internally - email a hash of something critical (logs, configurations, decision docs, etc) to a dedicated gmail account - relying on the in feasibility of "faking" the date/time once it's onb Google's servers.
The important thing here would be to make sure those hashes are published somewhere where its technically infeasible for the police to change it after the fact, so not on a platform the police run or p-aid for (or that is run or paid for by an organization that the police can request or coerce the operators to make changes).
You literally just need several oracles which sign hashes at the time they receive them and record that fact.
As a community service you need them to have enough scale that no individual hash or source can be tampered with without being likely to become known as unreliable to everyone else as well ala certificate transparency records.
(You could probably just bootstrap let's encrypt for this - issuing a certificate you use to sign a bunch of data would stamp several minimums on the order anything could have happened).
Interesting, There aren't any newspapers left in my country, neither printed nor not printed. The closest you can find is the weekly advertising booklet here and there. Which is irrelevant now because a computer can either stich new content to an old picture, or entirely producing a custom picture.
That would be a use case for a block chain. But I still don't understand how you are securing the integrity of the validity of the certificate stating the authenticity of the media. I only understand you are stamping media with a "at least as old as [timestamp]
If you want to prove that "happened at or after this timestamp" you can use a randomness beacon. NIST[0] and others publish a random number every N minutes. Embed that (or a combination) of those seeds to prove that you observed this value. This does not work for the harder problem of proving an event happened before a timestamp.
Seems like this idea solves a different problem than signed timestamps. You have access to not only the current random numbers, but also any random number from the past (as long as someone somewhere wrote it down). I just don't quite get what this could solve if you can either use a current number or an old number. Just not a future number because they're not around yet.
Embedding a public random number also doesn't resist tampering, unlike signed timestamps.
There are some - albeit few - cars that tick most of this checklist.
MZS5 EV[1] checks most except the physical buttons, which is a half tick. There’s some physical buttons for some important things, but could do better. The previous model of had more buttons but essentially the same checklist-wise.
2025 Hyundai Kona SEL EV ticks most, maybe even all, of them. I'll mark with "(Maybe)" the ones that there might be some question about.
1. (Maybe) The door handles protrude like God intended, and it is obvious what you are supposed to do since there is an impossible to miss button.
However, the button only unlocks the door if you have the key fob, and sometimes it can take a couple pressed for it to work, so that might disqualify it.
If you want to unlock it without that key fob (and without using the app) there is a physical key, but the keyhole is behind a cover that is not obvious.
2. Yes to physical door opening mechanism.
3. Yes to door handle affordances.
4. Yes to physical charge port mechanism. Simple push to open latch mechanism, which is the only way to open it.
5-10. Yes to turn signal stalk, physical controls on steering wheel, physical temperature and fan controls, physical are flow and direction controls, and physical glove box opening mechanism.
11-13. Yes to rearview mirror, rear window, and side-view mirrors.
It is basically the same as a non-EV Kona at the same trim level except for things that have to be different.
> Among software developers, and especially among those who work on security-sensitive systems, there is a well-known maxim: Don't roll your own crypto. This does not mean that nobody is allowed to write cryptographic code. Someone has to. It means that, for ordinary production software that protects sensitive data of users, we should not rely on a private, unreviewed implementation that has not been vetted by the wider software development community. We should use established, vetted software packages or tools wherever possible.
The great things about all these crypto libraries are:
- Minimal to no dependencies
- Coded by security conscious people
- Often externally audited
I wish more libs/deps are crafted like them. Until then the risk of rolling your own vs using a dep isn’t as different as it could be.
Allow git clone for free/unrestricted still.
Require the user to sign in to view html views. Sign in require a valid email or phone where a validation link is sent.
Or: Users signed in won’t see the Anubis. Users not signed in can still see the html views but have to use a very high work level?
Or: Limit unauthenticated requests from an IP to 5/minute. Authenticated requests can do a lot more before hitting the limit.
reply