Re: What I am missing

TLS doesn't protect you against code that has been altered server side -
without the signers consent. It would alert the user, if unsigned
updates would be made available.

Ajax downloads still require a download link (with the bloburl) to be
displayed requiring an additional click. User clicks download .. ajax
downloads the data, creates blob url as src which the user has to click
to 'copy' the blob onto the userspace drive. Would be better to skip the
final part.

In regard to accept: I wasn't aware of the fact that I can accept a
socket on port 80 to serve a HTTP session. You're saying I could with
what's available today?

Michaela



On 11/19/2014 06:34 AM, Florian Bösch wrote:
> On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz
> <michaela.merz@hermetos.com <mailto:michaela.merz@hermetos.com>> wrote:
>
>     First: We need signed script code. We are doing a lot of stuff with
>     script - we could safely do even more, if we would be able to safely
>     deliver script that has some kind of a trust model.
>
> TLS exists.
>  
>
>     I am thinking about
>     signed JAR files - just like we did with java applets not too long
>     ago.
>     Maybe as an extension to the CSP enviroment .. and a nice frame around
>     the browser telling the user that the site is providing trusted /
>     signed
>     code.
>
> Which is different than TLS how?
>  
>
>     Signed code could allow more openness, like true full screen, 
>
> Fullscreen is possible
> today, https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode
>  
>
>     or simpler ajax downloads.
>
> Simpler how?
>  
>
>     Second: It would be great to finally be able to accept incoming
>     connections.
>
> WebRTC allows the browser to accept incoming connections. The WebRTC
> data channel covers both TCP and UDP connectivity.
>  
>
>     There's access to cameras and microphones - why not allow
>     us the ability to code servers in the browser?
>
> You can. There's even P2P overlay networks being done with WebRTC.
> Although they're mostly hampered by the existing support for WebRTC
> data channels, which isn't great yet.