Could Dart or other languages in the browser solve this problem of not being able to do crypto properly in the browser, or is this a more fundamental problem of having crypto inside a browser in the first place?
The fundamental issue is that the code needs be audited and signed offline so it can't be changed. Unsigned code should not be run. This makes releases harder (no push on commit).
It's not language-specific. App stores already work this way (including the Chrome web store), so a deployment mechanism is there; it's just not used as often as it should be.
It's funny, back in the day we debated ActiveX (code signing) versus sandboxes (Java and JavaScript) and the real answer is that you should have both (as Android does).
But code signing isn't magic either. You still need someone to do the auditing, and users to be careful about what they run. Since users are so trusting, I'm not sure that app stores in practice are any more secure.
Code signing turned out to be very successful for protecting against VBA macro viruses, though I would consider the use of MD5 for doing it flawed nowadays. Office 2007 and later ended up defaulting to a different solution however, and days ago I received an email in my inbox with an attachment that claims hidden content and ask the user to enable macros. It is not signed, and guess what the macro does?
How does this differ from HTTPS? Since we're dealing with World Wide Web, it can't be that you would have to install the public key of every site that you visit to get signed versions of the code – it would make browsing infeasible.
It just boils down to the CA based system that is already employed by HTTPS. You must of course trust the other party and their systems, but that's the exact same with code signing. To identify the other party, code signing uses a pre-shared secret (e.g. your OS comes pre-installed with their public key). In HTTPS you identify the other party by them possessing the right certificate, that's signed by a trusted intermediary. There's no really better way to do it, bar quantum crypto and HTTPS+DNSSEC, which is sadly not widely supported.
The difference is that if a server running HTTPS is hacked, the attacker can modify the JavaScript at will. With an app that's signed offline, this isn't possible; you could even redistribute it on an untrusted mirror.
Also, in theory, an independent auditor could rebuild the app from source and verify that the bits match, and do an independent audit of the source. So signed apps are more verifiable.
The trusted base for a signed app is (browser + app + app signer), not (browser + app + server), where the server might be a virtual machine in the cloud and you need to trust the virtual machine host provider too.
This doesn't matter most of the time because you have to trust the server anyway, but in the case of someone wanting to encrypt something on the client that cannot be decrypted on the server, it does matter. Encrypting on the client is mostly pointless unless the client code is independent of the server, which requires it to be independently signed.
There is still a cert chain of course, but it's a different one where the developer's private key doesn't get uploaded to the server.
Signed apps are fundamentally not how the web works. The argument here is that the web is basically broken for client-side encryption and the app store model is better for things like secure email or a bitcoin wallet.
But since most app store apps aren't open source and the open source ones aren't independently audited in practice, it's not clear it's a practical difference.
It's a fundamental problem with browser crypto. The attack surface of a crypto routine running in a webpage is really large. There are a lot of places where information could leak in or out, such as timing attacks. If an XSS attack on a webpage succeeds, then a large number of different attack opportunities could exist on browser crypto loaded from that page. Users might also have browser extensions which have the ability to inject into or steal from the web page. The number of things to worry about inside a browser is just way too high to really even consider using it to secure anything. The crypto would have to be built in to the browser at the very least.
