HN user
It would result in fewer online games that stop working altogether when the publisher wants to stop it.
All the publisher would have to do is to create a "mini self-hosted server" application and provide it and they would follow the law on this.
It's really not that complicated. Not "free", of course, but it's not exactly expensive either if you plan to do that from the moment you write your first line of code.
The latter.
It's a tool, if using data is necessary to make the tool work, then its output derives from the data.
If the LLM generation is not derivative of its training data, then why would it need the training data in the first place?
It's because circles allow for a stagger and overlap as shown later on. It's not really possible to get the same effect from squares.
Basically, for this specific structure, they had to develop their own "sub structures" on the 1d line. These sub structures are known to create one little thing going diagonally (and then leave a bunch of debris behind, but that doesn't matter too much for that first step, they called this custom part "the fuse"). Then, there is a known technique where taking "diagonal moving objects" created on the same y-coordinate and placing them at the "right x position" makes the collide in a way where you can "program" where to create diagonal moving objects but at arbitrary positions on the screen (this is called a "binary construction arm"). And then, once you can create these anywhere on the screen, then you've basically won ; there's another technique to turn arbitrary positions into arbitrary shapes ("extreme compression construction arm", or ECCA), and it's "just" a matter of making the ECCA clean up all of the debris and build a new fuse but moved over.
Of course, the "just" here does the heavy lifting and represents over two years of exploration, writing algorithms for how to clean up everything, and so on.
Do look into jsdoc typing and "//@ts-check".
I do agree with you on the compilation, and this is the reason I'm still writing the occasional .js or .mjs file. However, the js I write starts with enabling ts-check and has all of its type information encoded as comment. This way, I'm getting the benefits of typescript while writing the code without needing the whole compilation step.
Context: This is for a 2019 data breach on a system that was created in 2012. The GDPR was instated in 2018 (has it really been that long? Wow feels like yesterday) and Meta failed to disclose the 2019 data breach properly under GDPR, hence the fine.
None of these are true for the MitM threat model that caused this whole investigation:
- If someone manages to MitM the communication between e.g. Digicert and the .com WHOIS server, then they can get a signed certificate from Digicert for the domain they want
- Whether you yourself used LE, Digicert or another provider doesn't have an impact, the attacker can still create such a certificate.
This is pretty worrying since as an end user you control none of these things.
The requirement to ID yourself online was already a thing in China, and using government-provided unique IDs for that isn't the worst way to go about it. The main issue would be mandatory reporting (i.e. if the companies have to constantly send data about what every given ID is doing on their website), but that's a different issue - and I don't feel like it's harder to do this using the phone numbers they already use compared to using a government GUID.
The main issue is that this would make obtaining access to Chinese websites even more difficult for people outside of China. It was kind of possible to go around the phone number restriction by obtaining a phone number, but going around the government ID is going to be significantly more difficult.
TS allows you to pass a read-only object to a method taking a read-write value:
type A = { value: number; }
function test(a: A) { a.value = 3; }
function main() {
const a: Readonly<A> = { value: 1 };
// a.value = 2; <= this errors out
test(a); // this doesn't error out
console.log(a); // shows 3
}I really don't agree with that. Git is a powerful tool with very few actual downsides, and the unwillingness of some developers to spend an hour learning how it works hurts them in the long-term.
It's like sticking to the text editing feature of your IDE because you can't be bothered to learn how it works. Sure, you _technically_ can do that, but you're losing on everything that makes an IDE useful and probably losing actual days or weeks worth of work because of that.
Not quite that, we've known about galaxies outside our own (like the Magellanic clouds or the Andromeda galaxy) for a few millenia, and the main reason black holes haven't been discovered for a while because they're black and we needed a theory to know where to look. The current theory of cosmology has overall been pretty stable for a while.
What's interesting there isn't that much the object themselves which are bog-standard as far as celestial objects go, but how red-shifted (and therefore how far away/long ago) they are, which is something the model doesn't quite exclude but does warrant some tweakings of the "initial parameters" of the universe to make it work this way compared to what we expect.
Weird choice to talk about the placebo effect in this context. The placebo effect is definitely used in combination with chemical and biological effects when administering drugs (or, more accurately, it always automatically happens). It's just when trying to test the efficacy of drugs that you need to control for the placebo effect, otherwise the noise of the results would drown the signal of the biological/chemical impact.
Captura is a great piece of software - I've used it for years, and I still use the latest release today.
It is a complete, all-in-one tool - very straightforward UI, lots of formats supported (especially through ffmpeg integration) and very easy to use in terms of window or screen area selection for recording - and more importantly for my use-cases, it's portable (no install, no admin rights needed). Really a great example of what's possible in that space.
I didn't participate in the project, but I've checked out the PRs and issues list every now and then and it's been frustrating seeing the author struggle against the store republishing issues for literal years. The issue tracking that (#405[1]) is not a happy read for sure.
The fact that Captura's MIT licensing gave effectively a "license to steal" to people and that it's so easy to publish something and sell it on the Microsoft store didn't mesh well.
I've however been really disappointed by Microsoft's non-response through all of that republishing debacle. Republishing free software is a difficult topic to get right for edge-cases, sure, but the Captura case was obvious to rule on and Microsoft did nothing for years - it was clear that there was no process for this kind of scenario, and that the solution was to do nothing. It took the author taking down the project for them to react, and even then I'm convinced that's only because whoever handled that case assumed that the republisher was the one taking it down, not the project author.
I don't think it's likely. The real migration has been and will continue to be towards Discord servers and similar "smallish" live chat-based communities on centralized services.
The age of small self-hosted forums is unfortunately behind us, and I don't see them reviving any time soon.
To simplify equations that create ratios between distance, time and energy. That's literally it. Using Planck units is a math trick to remove a bunch of constants from a bunch of equations.
The Planck length doesn't really have any known physical importance, at least no more than a meter does. There's some things that happens around a planck length (for example, the current theories predict that black holes need to be at least bigger than a planck length to exist, or alternatively the Planck length is the point where the quantum uncertainty completely overtakes any other classical theory) but particles can "move" distances less than a planck length (with lots of caveats, mainly because quantum uncertainty makes the notion of "moving" in the classical sense kinda weird and barely applicable, but still, they _can_).
A common belief is that the Planck length is kind of the "minimal distance" and start thinking that it's the "pixel of the universe" but there's no actual theoretical framework saying that. It's just a common misconception.
There's a good chunk of the article about that. "Constant-tile" is a bit of a misnomer, "secret-independent resource consumption" is a better way to say it. If you just add a "sleep(rand)" or equivalent then you can still break the secret using statistics or sidechannel attacks.
I don't think that's a healthy mindset to have.
Just because something is widely used doesn't mean it's more secure (example: libwebp). The security issues tend to happen mostly when creating optimizations that bypass the "obviously secure" way to do things, but rely on an internal state that gets broken by another optimization down the line. This is way less frequent in "smaller" projects, just because they didn't need to go through that round of optimizations yet.
For this question specifically, tho, I think Ladybird is extremely interesting in terms of creating a security-focuses C++ project. Between the constant fuzzing that each part of Ladybird already goes under (courtesy of the OSS-Fuzz initiative), the first-class citizenship of process separation for the different features of the browser, the modern C++ used in Ladybird (that prevents a lot of the issues cropping up in commonly used media decoding libraries), the overall focus on accuracy over performance in library implementations, and the compiler-level sanitatization utils (UBSAN, ASAN) that are enabled-by-default, I think it's less likely that an critical security-impacting bug would exists in Ladybird's .ico support than in Webkit's for example.
The advances of renewables are definitely dependent on strong compute and widespread global (or at least widespread local) networking. Smart grids need all of the different tools from different manufacturers to talk to each other, which an agreed-upon networking protocol like IP on top of an existing internet backbone makes very easy to ipmlement. On-demand energy storage and providing from battery banks - or even hydroelectric storage or (as mentioned in the article) gas-powered backup turbines need the analytics power to study and predict load variations on all of the collected data, which existing data centers for search or even apps makes trivial to acquire.
Now, there could have been technical solutions for these issues found in the 80s or 90s, but more probably than not the engineers back then would not have thought about this beyond the obvious corporate aspects - after all, it's much more "practical" to focus on connecting the big power plants together and just vaguely estimate the required consumption.
It's probable that, if you sat at a design meeting in the 80s and proposed, as "an energy-efficient solution", to have a small computer in every consumer's breaker box that monitors the incoming electricity, sends the info through a combination of radio and country-spanning wires to a central server, and then do analytics on it to predict when the power is needed, you'd have been laughed out of the room. And yet, that's how smart grids work nowadays and it is the correct solution to this problem.
The improvements in energy storage and solar/wind renewables would have started decades earlier, sure, and that would have mattered. But I don't think anybody would have been able to use them the way we can use them today if it was done twenty or thirty years ago, and the technology might have died down instead. It's hard to know for sure, but it's a very plausible outcome.
LIGO by itself serves "very little" purpose, just watching for gravitational events that are theoretically possible and checking if they happen for real. It actually confirmed that these events exist a while ago[1], and now it's "just" looking for more things we already know exist.
in my opinion, the point of LIGO is no longer in detecting these gravitational events anymore tbh. Doing that is cool, and will bring us more data points about the events, but it's unlikely to ever yield "new science" like that.
Instead, LIGO (and Virgo) excel in exactly the kind of thing that we see in this article: to push the barrier of what we can do in this hyperspecific use-case, finding ways to do "new" engineering that would not make sense for other commercial projects yet and finding out how to implement cool solutions. The fairly consequent amount of funding and the extra focused goal it is aiming for will lead to new techniques and technologies that might have an impact.
Now, is there a guarantee that this new technology will have a larger impact than "better detectors"? No. Actually, there's no guarantee about anything coming out of LIGO ever, no more than out of the LHC[2] or ITER[3] or the ELT[4] will give us new science. But putting all of your eggs in the same basket is a bad solution for making more science, and there's enough room in science budgets to try a few dozen monumental projects and see what sticks.
[1] https://en.wikipedia.org/wiki/First_observation_of_gravitati...
[2] https://en.wikipedia.org/wiki/Large_Hadron_Collider
I don't think you understand the policy.
Unity isn't doing what Unreal did and asking for a cut of every sales. That would be surprising, that would be impactful, but that would be a manageable amount of money.
Unity is asking for a fee on every _install_ of the game, even if it amounts to one single sale of the game. Quoting their FAQ[0]:
Q: If a user reinstalls/redownloads a game / changes their hardware, will that count as multiple installs?
A: Yes. The creator will need to pay for all future installs. The reason is that Unity doesn’t receive end-player information, just aggregate data.
That means that if you sell a game for $1, and if a user reinstalls it 6 times over the course of their ownership of the game (changing computers, just uninstalling/reinstalling to free up space every now and then, adding or removing mods, etc...), and you made more than 200.000 sales... You now owe Unity $1.20 for that user. And you only earned $1 from that user. Sure, you can pay Unity 1500/year/developer to rise the threshold to $1 million and lower the fee to $0.15 per install, but that's not a "deal". That's a racket.
This is absolutely, completely unsustainable. And not like "this will cost some money to companies" unsustainable, more like "it will be cheaper to hire people to port our game to another engine" unsustainable, as the person handling the business side of Among Us stated yesterday[1]:
This is legit the kind of math I'm doing too. I've learned that Unity's fee won't be retroactive which is delightful, but also Among Us gets enough dls per month that I could just hire two whole people to port AU away from Unity instead of them taxing us for 0 added value.
And that's not accounting for business models like bundles or game passes. AGGRO CRAB, the developers behind the upcoming "Another Crab's Treasure" game announced earlier this year and coming out early next year, has stated that they are unsure whether their GamePass release will be sustainable for them[2]:
This means Another Crab's Treasure will be free to install for the 25 million Game Pass subscribers. If only a fraction of those users download our game, Unity could take a fee that puts an enormous dent in our income and threatens the sustainability of our business.
To be more exact and add some context, as reported by journalist Stephen Tottlio[3], Unity executive Mark Whitten stated that the fee would be sent to Microsoft:
As for Game Pass and other subscription services, Whitten said that developers like Aggro Crab would not be on the hook, as the fees are charged to distributors, which in the Game Pass example would be Microsoft.
This will, however, deincentivize Microsoft to publish games made by studios who use Unity because Microsoft would be potentially publishing at a loss, which of course they don't want to do. So, not the exact same impact to developers, but the same difference for them.
And of course, that's not accounting for all of the "freemium" models here and there. And I don't mean microtransactions, I mean games that lock part of the content behind a paywall but propose access to most of the game for free. That business model, sustainable so far, is now literally going to end up with Unity asking for more money than you earn a year. (and yeah, this is a real risk for some companies. Anduo Games, the company behind the NSFW game Third Crisis, is still wondering if they're in that exact situation and what they can do about it[5]).
This move is just bonkers. Like, it's a business model where just using a game engine means that you can end up owing more money to a company than you earned over the lifetime your game.
And this is why people are not happy about this move.
[0] https://forum.unity.com/threads/unity-plan-pricing-and-packa...
[1] https://twitter.com/forte_bass/status/1701696983617180010
[2] https://twitter.com/AggroCrabGames/status/170169103683230926...
[3] https://www.axios.com/2023/09/13/unity-runtime-fee-policy-ma...
[4] https://itch.io/post/8572430 (the link is to a comment and is fully SFW, the game this comment is about isn't)
Hacking the root certificates of TLS doesn't allow you to read every TLS-encrypted conversation ever, thankfully. It just allows you to set up a MITM attack that looks legit. And sure, that is bad, but it's not "immediately makes everything readable" bad.
That's why I call TLS keys "ephemeral" under this threat model.
The goal of anti-E2E legislation isn't to be able to MITM a conversation - again, government agencies can already set that up with the current protocols fairly easily. The goal of the legislation is to make it so that, "with the correct keys that only the good guys have", you can decrypt any past message you want that was already sent using the messaging system, without needing access to either device.
If the governments only settled with an "active tap system" that works like a MITM for e2e encrypted channels, we wouldn't be having this discussion or we wouldn't be talking about new regulations. Because again, that is already possible, and governments are already doing it.
That's completely missing the point. This is not about perfection, this is about the threat level.
Decryption is always going to be technically possible. A government can always get possession of a phone, invest a lot of time and skill to get the key out of it, and then use that. This is what happened in that one famous Apple case, and this is what is always going to happen when people use E2E encryption. The point I made in my other posts was that once you get the key, you have the key, and that doesn't change just because the key is on the phone. That's your threat model when you use E2E encryption.
TLS works the same way. The encryption keys are ephemeral, but they're temporarily stored on your computer and on the server you're communicating with. If you want to attack a TLS connection (and you can!) you need to obtain the key from either the server or the client, and that's your threat model when you use TLS.
This is a completely fine and acceptable threat model as long as the keys are stored in a disparate sea of targets, either on hundred of millions of possible client/server machines for TLS, or on each person's phone (each one with a different model, from a different maker, and using different apps) for E2E. The thing is, in such a distributed model, nobody can realistically get every key out of every phone at once. This makes every single attack targeted to a couple of high-profile target, and therefore the impact of successful attacks way, wayyyy lower.
The issue arises when you decide to forbid end-to-end encryption, and instead mandate a global way to decrypt everything without needing access to the phone itself. This changes the threat model in a way that makes it unsustainable.
Again, and I know I repeated that vault analogy but it's a great way to explain attack surfaces and threat models: It's fine if everyone has a vault at home with their life savings in gold inside, because nobody can realistically rob every vault from everyone at once. It's still fine if every city has a vault where people store their gold, because while a few robberies might happen, it's possible to have high enough security to make it not worth to rob this vault. It starts being a bad idea to ask everyone to put their gold into a large, unique central vault that "only the government" has access to, because the money you need to spend to protect that vault is going to be prohibitive (and no way the government isn't going to skimp out on that at some point). And finally, it's an awful ideal to make that with magical gold that you can steal by touching it with a finger and teleporting out with it, because all of that gold is going to disappear so fast you better not blink, and losing that combined pile gold is going to impact every citizen ever.
It's a matter of threat modeling: the moment there's a way to access absolutely everything from a single entry point with possibly avoidable consequences for the attacker, then that entry point becomes so enticing that you can't protect it. You just can't. No amount of effort, money, and technical know-how is going to protect that target.
"Intrinsically linked" doesn't exist. Encryption is math, math you can do on a piece of paper (in theory). Anything you set up to log the fact that people did that math is always going to be meaningless if people take the numbers and do the math away from your logging system.
Now, you can say "but you can't ever access the numbers, just order the computer to do the operation". And also "To order the operation, you need 2FA and a signature for a judge and the president". And, of course, "The numbers needed for decrypting are split between three different servers all with their own security system and they can't be forced to talk to each other without the president's signature being added to a public log". And that's all well and good, but consider this: I install a listener on the RAM of each of the three servers. I wait until it does a totally legit, totally approved thing that gets logged. I now have the numbers copied somewhere. I do the decrypting for everything else away from the servers.
Sounds like a difficult operation? You're talking about three numbers worth a trillion dollars if they ever get out. Spy missions have been done that were harder to pull off for less benefit.
You just thought of [technical solution] to prevent listening through the RAM? Great, you just solved one _very obvious_ part of the attack surface. Now to address the ten thousand other parts identified by your threat model, and I really hope that you did a perfect job while designing that threat model because one blind spot = all of the keys are out forever. Also, no pressure, but your team of 10 or 100 or even 1000 people working on that threat model are immediately going to be pit against teams of the same size from every government ever, so I hope your team has the best and most amazing engineers we'll ever see in the world. And that's not considering the human aspect of all of that, because, well, one mole during the deployment, one developer paid enough by an adversary to do an "accidental" typo that leaves a security hole, one piece of open-source software getting supply chain attacked during deployment, and your threat model is moot.
The issue is that whatever "audit" or "protection" method you create, whatever technology you use to ensure only the "good guys" get the information and the "bad guys" can't, it's only layers added on top of the real issue:
The final key is always going to be a single number. Once the key is out, it's out. There's nothing you can do about it being out, and no way to know it's out unless your audit system somehow caught it beforehand.
And that key (or these keys, which doesn't change much between "one number" and "two billion numbers" in terms of difficulty of stealing or storing them) is going to be worth trillions of dollars.
Again, the bank vault thing is an apt analogy (up to a point): You can add all of the security "around" the vault, guard rounds, advanced infrared sensors, reinforced concrete with weaved kevlar in it, etc... But if someone ever gets the dollar bills in their hands, then they got the bills. And if they somehow manage to bypass the security systems and not get noticed as they go in for the steal, you have no way to know who they are or that they did it.
Now, that is completely fine for a standard bank vault: after all, you need to physically send someone in, it's pretty rare for people to actually want in the vault so security can be pretty slow and involved, it doesn't have that much "money" inside (I'm pretty sure no bank vault in the world contains more than a handful of millions at any given time), and above all it's "physical" stuff inside: you'd immediately see if it's gone, it's not like someone who got in the vault can "magically" copy the bank notes and leave with the money while leaving the vault seemingly intact.
It's less fine for a "server" vault, where not only do you store everything so it's worth trillions, but people need to access it all the time because "investigations" and "warrants", and in a fast way because "terrorism", and if there's a breach or a mole or anything like that then people can copy all of the data inside and leave the server seemingly intact.
I think thinking that there's a technical solution is misunderstanding the problem, and that anyone pretending they "solved" it are always going to minimize one risk or the other. The governments and regulators don't get that yet, because it looks like it's just a technological issue to build "the vault". But the real issue, the fact that "the vault" doesn't matter when the consequences of stealing the contents of the vault are risk-free for bad guys but so immensely impactful for citizens, is the reason why technical solutions won't ever be enough.
The point is that today, the key isn't in Google's or Amazon's or Meta's servers, but on the phones of people. That means that you literally don't have the key if you don't have the phone. And governments don't want that, they want the keys in order to eavesdrop but without being noticed (and stealing the phone would get you noticed).
So your only option to comply with this is to remove the phone-only key storage option and move all of the key into your servers, which is what we talk about when we mean "breaking end-to-end encryption".
The issue is that to comply with the rules, you have to secure that server so only the good guys can get in, and only if the warrant is legit, but also to allow fast access for time-sensitive cases such as terrorism and secret cases such as NSA investigations. You also have to make sure that there's absolutely no way for people to access that server if they don't have the approval.
Oh, and also that server / these servers contain the keys to read every message from every citizen of your country (including politicians), which is probably worth as much of your GDP.
So you need to build the equivalent of a safe containing one trillion dollars that can't be accessed for any reason except all of the reasons mentioned abov3. Except that this theoretical trillion of dollars are special dollars where if you mess up and let people in without anyone noticing they got in, they can "steal" the trillion dollars and start spending them and nobody would notice that they're being spent. And there's just about every country on earth that would love to "borrow" your two trillion dollars, especially if you can't ever realistically prove they did it.
Easy, right?
Note about the more productive approach: Mozilla published a blog post[0] back in late June about what solutions are already available and advising for the law to reinforce these existing mechanisms instead of mandating a new browser-level blocking thing that can easily be abused.
[0] https://blog.mozilla.org/netpolicy/2023/06/26/france-browser...
To simplify, the same way that a surfer on the sea can use the movement of the sea itself (waves) to surf!
An Alcubierre drive (they're theoretical) would basically constantly compress the time curve of spacetime in front of the craft, allowing the craft to "ride" this compression as it moves forward, which means that the local speed of light of the craft is faster than the speed of light of an external observer. Note that the main issue we have is to find something that can compress space, and then to have it have enough energy for it not to be trivial (because 110% of the speed of light, while technically FTL speed, is still very slow for interstellar travel). And of course, while the existence of something that does this spacetime curve compression fits the math we have, we've yet to find a material or technique that actually does so.
Well, good news about that, a simplified version of adblocking through content filtering[0] is already part of Ladybird (and has been part of Browser[1], the version of Ladybird integrated in Serenity, for a while). There is even a video[2] where Andreas implemented it!
[0] https://github.com/SerenityOS/serenity/blob/master/Ladybird/...
[1] https://github.com/SerenityOS/serenity/blob/master/Userland/...
I can actually comment on that fist question, having contributed to Serenity a bit in the past.
I did two big patches in the system, the first by adding websockets to the system[1][2] and the second (still ongoing) about allowing Browser to run in Linux directly[3]. Each went through several iterations trying to iron out all the lifetime and memory safety bugs I encountered, including in the first case one that got through the whole PR process and only got caught months afterwards.
The first change (WebSockets) took me a while to finalize, the main issue during its development was to solve the issues of the underlying socket never getting closed. This was actually due to RefCounted pointers getting implicitely captured by lambdas, which I solved by creating weak pointers for a bunch of them. This fix, however, ultimately broke the expected lifetime of the underlying socket by deleting it too early sometimes, which caused a sporadic disconnect issue. Now, this was not caught at all during the PR process, and was only found and fixed by Andreas a few months later[4]. This is directly a lifetime issue, and would have been caught by either a system that holds references directly.
The second change (headless-browser) took me at least twice as long than expected to do to make it work, due to some random crashes that I could not track down. This was ultimately diagnosed as me passing the wrong type of argument to the MemoryStream type, which accepted both BufferedSocket and TCP/TLSv1.2 Sockets directly but expected the behavior of BufferedSockets - it took two other people on Discord to debug this issue[5]. Note that that bug still allowed the headless browser to work for a little bit before it crashed, just not long enough that I didn't notice the bug. This bug was ultimately due to an invalid type constraint that I believe was left as-is as a workaround for another issue, but it could have been easily caught any language that didn't allow implicit reinterpretation of random memory data, so it ultimately is memory safety that lead to that happening.
Since I'm currently two for two in "memory safety-related issues" in my PRs, then yes I'd consider that, just like any other system, Serenity is having problems with memory safety - and that's just my personal experience. It's possible to do some things in C++ to try to limit these issues, and there's a lot of that being done in Serenity already. But in C++, all it takes is either a mistake by someone less skilled (me) or a workaround by someone who didn't think it'd be an issue, and the memory safety issues pop up again.
[1] https://github.com/SerenityOS/serenity/pull/6420
[2] https://github.com/SerenityOS/serenity/pull/6610
[3] https://github.com/SerenityOS/serenity/pull/13473
[4] https://github.com/SerenityOS/serenity/commit/1735d978ed2449...
[5] https://github.com/SerenityOS/serenity/pull/13473/commits/2d...