quohort
Or perhaps the client can tell the server what webpage it's fetching from and the security check can be done server-side?
It is just strange to me that this security check has to be done on client-side (in the browser) as opposed to on the web server actually responsible for distributing the content.
You're suggesting that reliability should be improved by being obfuscating the code through transpilation or by merit of being generated by a black box (LLM).
I really suspect that simply transpiling code to rust or ada or some other "safe" language largely wouldn't improve its security. The whole point of these "safe" languages is that they encourage safer practices by design, and that in porting the code to rust you have to restructure the program to conform to the new practices (as opposed to just directly re-implementing it).
I haven't seen a LLM that is reliably capable of logic/reasoning or can even reliably answer technical questions, much less synthesize source code that isn't some trivial modification of something it has been trained on. And it's not clear that future models will necessarily be capable of doing that.
Steam is successful because it has good user experience compared to alternatives, and has a lot of major titles.
Well on a basic level, if the consumer buys your motherboard or laptop and it doesn't work out of the box (but your competitors do) then you are going to have a massive customer satisfaction problem.
> Doesn't 90% of the push for this come from Media companies to implement DRM?
I don't think so. DRM is an old lens of understanding the problem from the last generation. See https://www.youtube.com/watch?v=HUEvRyemKSg . The new methods use a softer approach. Consider something like iOS where the developers can just make it very uncomfortable to do something like download a video and watch it. There's no bittorrent app or p2p file-sharing, there's no real filesystem, and there is no real standalone video player. So users rely on streaming services to do this for them, and you can charge money to middle-man that service.
You don't need to strictly enforce copyright like with DRM, just use trusted computing so that the entire system discourages general computer-like operations (including copying files, running programs, etc.) and encourages acting like a thin client to some server. This is a much better model because some small fraction of users still DO need to have general-purpose computing to make consumables in the first place (for example, video editors or musicians, writers, programmers) but the majority of the user-base is discouraged for a variety of reasons. The more you can separate the creator of information from the user of information, the more you can charge the user to access the creator.
You can't replace the OS or any of the parts of the machine because of trusted computing, so you cannot really use reverse engineering to simply break the system (and if you do, it may break the trust chain you now need to access now-networked services). Another example is that on a lot of phones and laptops these days, you can't add removable storage, so you are heavily encouraged to use cloud storage. And you are discouraged from using cloud services from any third party (usually on an API level, as services provided from the OS vendor can integrate better with the system). Consider how Apple pushes iCloud and Microsoft pushes OneCloud.
I think we are seriously nearing the point of no return. Once you have manufacturers start implementing TC, that will really hamper reverse engineering efforts. Over time, the side channels will get ironed out.
Enforcing TPM requirements isn't about making users make changes, it's to scare OEMs into including TPMs by default so they don't get complaints from users. Microsoft wants a more controlled hardware environment like Apple does, because it's more profitable for a variety of reasons.
The fact that invoices are temporary in LN is a weakness of the design, not an intentional choice. The lightning network represents a regression from the typical use-case of cryptocurrency because both sender and receiver need to be online to make a payment.
I'm sure that has something to do with it, but such campaigns are catalyzed by china's military aggression in the south pacific. Morality is an afterthought.
I think the onus is on the developer to use standards that are well supported and to try to avoid standards like webUSB that are niche. To use semantic HTML and such so that the website fails in a more useful way to the end user when the standards aren't supported.
... over SMS!
Usually when you have a textbook, they will have some nice illustration that is tangentially related to the content of the book (like fibonacci spiral for a math book or some chemical reaction for a chemistry book for example). But I suppose that there isn't really such an equivalent unless it's a computer graphics book.
I guess it's also like how every project has to have its own "cutesey" mascot.
Whereas the problem that Namecoin, ENS, and others (presumably namebase as well?) are trying to solve is squaring the whole triangle with a petname system that sacrifices security for human-meaningful names. They are what's referred to as a petname system.
For example, you could have a parametric design for a custom/designer piece of clothing and adjust parameters to tailor to individual wearers while having some automated manufacturing
There really ought to be a system (like .onion services or eepsites but without the mixnet/anonyminity) where you can just register a domain by a public key and have a signed pointer to your address on the internet as DHT. Sort of like IPNS or GNS but more common so you can just point someone to a domain like "0x1234[...]ABCD.ed25519.pubkey" and they can get a secure connection to you at whatever address you have.
> Two, I hope no one else gets caught up in it. There are a lot of strong words and claims but nothing remotely actionable. It's pushing pure panic/fear/angst.
This made me laugh, it comes off as so condescending. Don't worry about my "mental health". The purpose of life is not to just be content all the time, it's to overcome suffering and achieve some level of self-actualization.
If we are on the verge of the apocalypse, It should feel apocalyptic. The question is of how urgent the apocalypse really is (taken with a grain of salt to make room for the unknown) and what can be usefully done.
> cloudstrike is just a company that is strong on sales/marketing but weak on tech, who found a market that requires you to be strong on both. I don't think there's anything wrong with such companies existing, but it seems clear they should never be in a position to break everything.
I do think there is something wrong "fixing" security by just outsourcing your problems to some other company to monitor. Real security is about one's own operating practices and standards. Companies like cloudstrike don't necessarily increase security, they increase fragility because they act as a central point of failure.
> The fix could be the market, regulatory, and/or technical. There are tradeoffs, so we probably need to work through the arguments of different approaches and different combinations of approaches.
The author suggests that the problems are more systematic. I would say the fix is cultural: we have a flawed culture of outsourcing security to the market, regulators, or technology.
The "Offer" Model presented just seems like a conventional multisig escrow, presumably with the blockchain serving a as a signalling mechanism?
I think that we have been able to thwart "treachery" in the meantime by exploiting side-channels in trusted computing implementations. Ultimately it may be necessary to amend the constitution to prevent manufacturers from distributing locked-down hardware for the good of free society (competition, democracy, etc.) at large. Otherwise, computer giants will have ultimate control over the distribution of information (given that the economics of manufacturing are driven by economies of scale).
I assume the TPM in this case would only have a partial decryption key? I think something similar could be accomplished with SSS, no?
2. As for this, I can say i've never used DBX with UEFI Secure boot. Instead of revoking keys, I just remake the entire PKI from the top. The PKI is only there to support independent use by OS Vendor/OEM hence the separation of PK/KEK/db.
3. Counterpoint: over-reliance on TPMs and such. Whereas the ordinary trust chain only requires signature verification at the start of boot (presumably on-chip), measured boot requires more complex trusted computing hardware (presumably off-chip).
Personally, I find that systems that are overly-reliant on complex trusted computing hardware tend to lack in other areas. For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN. These systems try often to reconcile "analog" passkeys like Biometrics (FaceID, fingerprints) by using trusted computing. Of course, if the trusted computing systems are breached (https://www.404media.co/leaked-docs-show-what-phones-cellebr...), then security is very weak.
I suppose the advantage of the measured-boot method is that it is optional. So you can still boot whatever OS you want, just without some TC features.
> The only danger is that some pedant comes along and says that with these assumptions what you're now writing isn't "portable C" and relies on compiler-defined behavior, but in the real world if it does the correct thing I don't think anyone would care: just call your dialect "boringC" instead of C99 or something (borrowing Gavin Howard's term), and the issue disappears.
My idea is to make a new language with some simple syntax like S-expressions. Compilation would be (almost entirely) done with lisp-like macros, but unlike lisp it would be an imperative language rather than a functional language. The main data structure would have to be a hierarchy (analogous to CONS) to facilitate these macros.
Optimizations (and Specializations) would be opt-in and would depend on the intrinsics and macros you allow in compilation. For example, you could start writing code with this default data structure, and later swap it out for some more specific data structure like a linked list or a hashtable. The most daunting problem is the issue of how the compiler selects what optimization or specializations to use; Optimizing for something like code size is straightforward, but optimizing for code speed will depend on what branches are taken at runtime. Now I suppose that the language should simply allow the programmer to manually express their preferences (which could be discovered through benchmarks/code studies).
I think that this could have a niche for manually-optimized code that requires strict static analysis and straight-forward compilation. It also could have a niche in decompilation/recompilation/reverse-engineering (I think that a similar process can run in reverse to disassemble even obfuscated code, because you could easily write a macro to reverse an ad-hoc obfuscation mechanism).
Here is another application of the language: By controlling the macros and intrinsics available at compilation, you could ensure compile-time security of userspace programs. For example, you could have a setup such that speculative execution vulnerabilities and the like are impossible to compile. I think you could safely enforce cooperative multitasking between programs.
I'll probably start with a simple assembly language like WASM, then LLVM-IR. Eventually it would have JS/C/Rust bindings to interoperate with normal libraries.
Lastly, I would like to make it so you can write routines that are portable between CPUs, GPUs, and even FPGAs, but this would be very difficult and this functionality may better realized with a functional language (e.g. CLASP https://github.com/clasp-developers/clasp) or may require programmers to work at an uncomfortably high level of abstraction.
I think this was useful context, and it was eye-opening to me.