31–40 of 89 posts
Earlier quoted context omitted.
Google just wants browsers to become more powerful cuz then more people will use Chromebooks. since everything can be done on a browser. Why do you think PWA's are being pushed so hard by google? So people can build PWA's that also run on Chromebooks. No need for native apps
I think PWA's were pushed because the google cannot crawl native applications for its search engine.
Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown that both of those measures are not impenetrable barriers to attackers and raw sockets open up a whole new set of attacks. HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put you…
How would code signing be helpful? How would the key end up being trusted? I do think that content pinning/notarization of web apps could be powerful. We are building some of those ideas here but and I have an interest in how this could be used to pin critical apps to an audited/approved version: https://transparencylog.com
If features require combination of https + code signing, you now need to not only get a file on the server, but you need to sign it. For high privilege APIs you would likely also want to do certificate approval like Windows does, where it shows you the certificate and asks whether you want to approve and whether you want to trust the signer. In many cases websites are loading code off a CDN, so the domain name of the website isn't actually important: the identity of the code's author is important and its integrity is important.
You could also configure your server to pin a given code signing certificate or set of certificates, and thus even if someone manages to get code onto your server that they signed, it wouldn't run.
Modern web platform APIs do have a way to specify expected hashes when loading external resources, so you can protect yourself against a third party (like a CDN) being compromised - but this does nothing if your server gets compromised, because they can just change the hash.
I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions;…
Security is hard, and exposing more by default (or making it defacto required) is simply asking for trouble.
Earlier quoted context omitted.
We could bring those advantages to web apps, but there isn't money in it, so it won't happen yet.
wouldn't that mean making them native apps, like something on top of electron? seems like reinventing the wheel.
Of course, writing a PWA is still a huge pain in the ass, and it doesn't give you those guarantees you mention from native apps - auditability, etc. But maybe it could get there, who knows...
Earlier quoted context omitted.
> Until widespread code-signing exists on the web this seems incredibly reckless to expose. [...] HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name…
You can sign the code on your own computer (which might even be offline) before deploying on some other company's server. So, it's harder for an attacker to get their code signed using your certificate. Hacking into the website would be useless; they'd have to get the code into the development environment. Or to put it another way, an HTTPS server automatically signs any file that it serves. That's too easy.
When it comes to getting access to code signing certificates, in many cases the state of the art is to have the signing certificate escrowed so aggressively that the only way to sign a binary is for it to go through a full build pipeline, because the central build servers are the only thing with access to the certificate. That significantly reduces the risk of someone managing to get your signing certificate and sign malware, which means you can focus on other vulnerabilities in your pipeline like your revision control server or your library dependencies.
Local apps - I can install once and check signature. - I can store them in a backup for later forensics if they do something bad. - I can firewall the process only to required services. - I can disable outside network access for local process. - I can analyze what it does before and after the fact. - They can be scanned by a malware scanner / virus scanner. Web apps: - need network access to load (and probably at run…
I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions;…
Earlier quoted context omitted.
> Until widespread code-signing exists on the web this seems incredibly reckless to expose. [...] HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name…
You can sign the code on your own computer (which might even be offline) before deploying on some other company's server. So, it's harder for an attacker to get their code signed using your certificate. Hacking into the website would be useless; they'd have to get the code into the development environment. Or to put it another way, an HTTPS server automatically signs any file that it serves. That's too easy.
Earlier quoted context omitted.
You can sign the code on your own computer (which might even be offline) before deploying on some other company's server. So, it's harder for an attacker to get their code signed using your certificate. Hacking into the website would be useless; they'd have to get the code into the development environment. Or to put it another way, an HTTPS server automatically signs any file that it serves. That's too easy.
You could achieve this with HTTPS and Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exc...
Web pages and JavaScript are the only universally trusted medium for sharing information and simple software. Making it possible for news websites to touch ethernet/usb/serial/gpu compromises that. Same goes for optimizations ilke JIT'ing and WebAssembly which have certainly done a great job making it possible for Gawker to reprogram the microcode in AMD K8 CPUs. Has the long tail of browser innovations made the web go faster? No. It went faster in 2010 IMHO. Whatever performance glut the geniuses who work on Chrome end up creating, it'll just get gobbled by more aggressive display ads and things like wild-eyed web component frameworks.