offline decentralized single sign-on in the browser

[Michiel de Jong]

See http://substack.net/offline_decentralized_single_sign_on_in_the_browser - interesting! With something like that, web apps can really be "unhosted", with code signing independent from servers we contact via DNS. :)

I remember we talked about similar ideas and the need for something like this three years ago on this list: https://groups.google.com/forum/#!search/unhosted$20wildcard/unhosted/c4KcKLxAqRs/u_icUSxYhGEJ


Cheers,
Michiel

[Nick Jennings]

Interesting work by substack, I like the concept and I heard a little buzz about it from other sources too, so good to see it's getting some attention!

I read through the old forum link you pasted but I didn't see anything which discusses this kind of concept (granted, most of the links were dead :)

--

---
You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[François Kooman]

On 11/28/2014 01:09 PM, Michiel de Jong wrote:
> See http://substack.net/offline_decentralized_single_sign_on_in_the_browser
> - interesting! With something like that, web apps can really be "unhosted",
> with code signing independent from servers we contact via DNS. :)

I don't see anything there about code signing? Nor about actually
signing in to something? Are the app resources (js|css|html) signed in
the manifest to avoid tampering?

The sooner we see "web apps" as "native" applications that use the
browser as their runtime (VM) the better. The way "apps" are currently
distributed is not really smart from a security perspective, especially
if CDNs are used.

The only way to do this properly is to have a "store" or something like
apptorrent (using a tracker you trust) where you can actually download
the application and run it in your browser. There needs to be code
signing (by the author) or by a delegated party like f-droid does for
Android apps to make it trustworthy. Or of course, package a web app as
an RPM or DEB file and install it through your package manager is even
better. Another idea is what EFF is doing with HTTPS everywhere for
Firefox. They provide the XPI themselves and also handle updates
themselves by signing the XPI offline before pushing it
[https://lists.eff.org/pipermail/https-everywhere/2014-April/002050.html].
That could work for webapps as well... only trust on first install and
after be sure the updates can be trusted.

Using a manifest with a cache that never expires to avoid updates... are
you kidding me? The web is still so young and already people are
proposing these horrible hacks... :)

Cheers,
François

[Nick Jennings]

Hi Francois!

On Fri Nov 28 2014 at 3:13:16 PM François Kooman <fko...@tuxed.net> wrote:

On 11/28/2014 01:09 PM, Michiel de Jong wrote:
> See http://substack.net/offline_decentralized_single_sign_on_in_the_browser
> - interesting! With something like that, web apps can really be "unhosted",
> with code signing independent from servers we contact via DNS. :)

I don't see anything there about code signing? Nor about actually
signing in to something? Are the app resources (js|css|html) signed in
the manifest to avoid tampering?

The sooner we see "web apps" as "native" applications that use the
browser as their runtime (VM) the better. The way "apps" are currently
distributed is not really smart from a security perspective, especially
if CDNs are used.

The only way to do this properly is to have a "store" or something like
apptorrent (using a tracker you trust) where you can actually download
the application and run it in your browser. There needs to be code
signing (by the author) or by a delegated party like f-droid does for
Android apps to make it trustworthy. Or of course, package a web app as
an RPM or DEB file and install it through your package manager is even
better. Another idea is what EFF is doing with HTTPS everywhere for
Firefox. They provide the XPI themselves and also handle updates
themselves by signing the XPI offline before pushing it
[https://lists.eff.org/pipermail/https-everywhere/2014-April/002050.html].
That could work for webapps as well... only trust on first install and
after be sure the updates can be trusted.

I don't think these are the only ways to do it. I personally think the idea of an app store is really taking a step back. Why do we need an app store for apps which can be deployed anywhere on the web? Why should we wait for a 3rd party to package up an already available web-app as a .deb or .rpm?

If, during a web-apps release, md5sums (or something like that but more secure) of the code are also generated, it should be safe to import these into your own browser extension which can use the browser API to verify an app you load as being verified against the has of the release you chose.

This browser extension can also be responsible for the key signing described in substacks post, for example. 

Then you can deploy the web app anywhere you please, or fetch it from the source and, as long as it's using the version you manually added, your extension will let you know everythings OK.

This doesn't audit the code, which is a separate process, but I think it's better to fetch a list of audited code to your browser plugin if you desire, or manually add apps you come across, than to wait for someone to package it for you.

 

Using a manifest with a cache that never expires to avoid updates... are
you kidding me? The web is still so young and already people are
proposing these horrible hacks... :)

I don't think the point is that you never again request updates, it's that you can freeze the version and use it offline and not have to worry about any potential compromises. Then you can manually update whenever you want, or set auto-updates. (this is explained on the example site linked to from the post).

-Nick

 

Cheers,
François

--

---
You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.

To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+unsubscribe@googlegroups.com.

[Jon Richter]

I just want to point out quickly, that the mentionned code signing (of the hyperboot component) doesn't have anything to do with the single sign on (of the keyboot component).

I believe this difference led to some confusion here.

The code signing on build time is used for verifiable versioning of your applications code. which can indee be updated. and even switched, on runtime.

The single sign on involves some browser crypto black magic which I actually didn't understand at all.

Any enlightening comments on this?

[François Kooman]

On 11/28/2014 04:37 PM, Nick Jennings wrote:
> Hi Francois!

Hi Nick! :)

> I don't think these are the only ways to do it. I personally think the idea
> of an app store is really taking a step back. Why do we need an app store
> for apps which can be deployed anywhere on the web? Why should we wait for
> a 3rd party to package up an already available web-app as a .deb or .rpm?

Well, you don't, but then you have essentially the same trust as
downloading a random executable from a website claiming not to be
malicious. Actually, this is not much different from installing e.g.
Firefox by downloading it from the Mozilla website without verifying it.
Bad! Now if you apply this to web applications there is not even a way
to verify the apps at all... it will require a lot of work to make this
happen (in the browser). Replicating what is already done for 'normal'
apps yet again, but now for the web.

I like being able to download the OS once, and then verify the signature
once, and then be able to "trust" all software you install through its
software manager. The same sounds nice for web apps...

> If, during a web-apps release, md5sums (or something like that but more
> secure) of the code are also generated, it should be safe to import these
> into your own browser extension which can use the browser API to verify an
> app you load as being verified against the has of the release you chose.

You will need some public key crypto as well signing the signature of
the app manifest (and its resources). Maybe you can package the entire
web app in one signed archive and call it deb, rpm or apk. Oh wait ;)

> This doesn't audit the code, which is a separate process, but I think it's
> better to fetch a list of audited code to your browser plugin if you
> desire, or manually add apps you come across, than to wait for someone to
> package it for you.

Well, I don't see a problem with that. Stable software will have regular
releases anyway and can then be packaged. This can be automated a lot,
see e.g. f-droid where they build directly on a new tag in GitHub (afaik).

> I don't think the point is that you never again request updates, it's that
> you can freeze the version and use it offline and not have to worry about
> any potential compromises. Then you can manually update whenever you want,
> or set auto-updates. (this is explained on the example site linked to from
> the post).

Rock and a hard place. I want updates when they are needed. I don't want
to freeze a version and then be clueless if the update can be trusted...

Cheers,
François

[Leen Besselink]

On Sun, Nov 30, 2014 at 05:44:59PM +0100, François Kooman wrote:
> On 11/28/2014 04:37 PM, Nick Jennings wrote:
> > Hi Francois!
>
> Hi Nick! :)
>

Hi folks,

> > I don't think these are the only ways to do it. I personally think the idea
> > of an app store is really taking a step back. Why do we need an app store
> > for apps which can be deployed anywhere on the web? Why should we wait for
> > a 3rd party to package up an already available web-app as a .deb or .rpm?
>
> Well, you don't, but then you have essentially the same trust as
> downloading a random executable from a website claiming not to be
> malicious. Actually, this is not much different from installing e.g.
> Firefox by downloading it from the Mozilla website without verifying it.
> Bad! Now if you apply this to web applications there is not even a way
> to verify the apps at all... it will require a lot of work to make this
> happen (in the browser). Replicating what is already done for 'normal'
> apps yet again, but now for the web.
>
> I like being able to download the OS once, and then verify the signature
> once, and then be able to "trust" all software you install through its
> software manager. The same sounds nice for web apps...
>

Well, you also have the HTTPS-model.

Because a whole bunch of platforms support code signing:
http://en.wikipedia.org/wiki/Code_signing

Where the CA vouches for your identity.

> > If, during a web-apps release, md5sums (or something like that but more
> > secure) of the code are also generated, it should be safe to import these
> > into your own browser extension which can use the browser API to verify an
> > app you load as being verified against the has of the release you chose.
>
> You will need some public key crypto as well signing the signature of
> the app manifest (and its resources). Maybe you can package the entire
> web app in one signed archive and call it deb, rpm or apk. Oh wait ;)
>

Well, there are a few people that have ideas about signed web apps.

First of all it's old as dirt:
http://www-archive.mozilla.org/projects/security/components/signed-scripts.html

Packages webapps have been standardized:
http://www.w3.org/TR/widgets/

But not much used (anymore) I believe, some older devices did support this.

In theory you could sign them ?:
http://www.w3.org/TR/widgets/

Nowadays we just bookmark-to-the-homescreen and use appcache and soon the serviceworker.

These kind of solutions I don't see how they really solve anything:
https://kjur.github.io/jsrsasign/

The best I've seen is Mylar, they sign everything and encrypt all the data:
https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/popa
http://css.csail.mit.edu/mylar/

You don't even have to trust the origin server.

They also created the encrypted database:
http://css.csail.mit.edu/cryptdb/

The most likely to get into modern browsers any time soon is:
http://www.w3.org/TR/CSP2/#source-list-valid-hashesl

That solves the untrusted CDN problem.

Obviously CSP 1.x already added a bunch of security features:
http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Also we have other features:

If you want to load code from an untrusted source, keep it in an iframe to do priviledge speration:
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/akhawe

Those are improvements on top of 'good old' http://en.wikipedia.org/wiki/Same-origin_policy and
https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage

Still you can't trust the origin server on the first visit, but at least we can secure it as much
as possible for return visits:

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Chrome and Firefox are working on:
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21

> > This doesn't audit the code, which is a separate process, but I think it's
> > better to fetch a list of audited code to your browser plugin if you
> > desire, or manually add apps you come across, than to wait for someone to
> > package it for you.
>
> Well, I don't see a problem with that. Stable software will have regular
> releases anyway and can then be packaged. This can be automated a lot,
> see e.g. f-droid where they build directly on a new tag in GitHub (afaik).
>
> > I don't think the point is that you never again request updates, it's that
> > you can freeze the version and use it offline and not have to worry about
> > any potential compromises. Then you can manually update whenever you want,
> > or set auto-updates. (this is explained on the example site linked to from
> > the post).
>
> Rock and a hard place. I want updates when they are needed. I don't want
> to freeze a version and then be clueless if the update can be trusted...
>
> Cheers,
> François
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.

[Will Scott]

Great roundup.

One more mechanism for signing that is worth being aware of, though is underutilized in practice is the content-md5 header/trailer to allow servers to checksum their resources. It seems to be implemented on several server platforms, but not really used much in practice from what I can tell.

For instance: http://nodejs.org/api/http.html#http_response_addtrailers_headers

--Will

[François Kooman]

On 11/30/2014 07:58 PM, Leen Besselink wrote:
>> I like being able to download the OS once, and then verify the signature
>> once, and then be able to "trust" all software you install through its
>> software manager. The same sounds nice for web apps...
>
> Well, you also have the HTTPS-model.
>
> Because a whole bunch of platforms support code signing:
> http://en.wikipedia.org/wiki/Code_signing
>
> Where the CA vouches for your identity.

The CA vouches for the owner of the domain, not for scripts downloaded
from a CDN or even from the site itself. Also, the CA model is not
entirely perfect, and a code signing certificate is typically different
from a server certificate... has other key use flags and may or may not
have additional identification requirements for the requester.

>> You will need some public key crypto as well signing the signature of
>> the app manifest (and its resources). Maybe you can package the entire
>> web app in one signed archive and call it deb, rpm or apk. Oh wait ;)
>
> Well, there are a few people that have ideas about signed web apps.

I think the idea is fundamentally flawed. If there is no trusted anchor
from where to start you are screwed.

Actually, although this is off-topic, I'm beginning to lose faith in the
whole concept of web apps as envisioned years ago. I mean, I do see
advantages, in theory, of having multiple implementations of a JS VM
(i.e.: browsers), but it doesn't solve any problems that wasn't solved
already yeaaars ago. The write once run everywhere idea existed already
a long time ago (Java) but never got of the ground due to lacking
first-class integration with the OS it runs on. I'm afraid the same will
happen with JS. Either fragmentation which in effect will lead to one
winner, or least common denominator apps. I guess the answer was given
by Google already when they announced "Inbox". So HTML/CSS/JS apps will
not be better than writing for any other 'proprietary' platform.

What I do like to some extent is the writing applications in HTML/CSS/JS
and then packaging them like 'native apps', i.e. what is done in the
Firefox OS Market, or in GNOME extensions. The stuff you link to can be
of big use there, but not for the 'general' Web I think. That is the
only way forward for these kind of apps I'm afraid to make them at least
a little bit of an alternative to what is currently out there.

I like the idea of gngr (https://gngr.info/) to go back to the pre
Web-2.0 web for publishing and ripping the web apps, i.e.: JS,
completely out of the browser and use a separate run time for that (like
Firefox OS does).

Thanks for your extended answer and the shitload of resources :)

Cheers,
François

[Leen Besselink]

On Wed, Dec 03, 2014 at 05:06:04PM +0100, François Kooman wrote:
> On 11/30/2014 07:58 PM, Leen Besselink wrote:
> >> I like being able to download the OS once, and then verify the signature
> >> once, and then be able to "trust" all software you install through its
> >> software manager. The same sounds nice for web apps...
> >
> > Well, you also have the HTTPS-model.
> >
> > Because a whole bunch of platforms support code signing:
> > http://en.wikipedia.org/wiki/Code_signing
> >
> > Where the CA vouches for your identity.
>
> The CA vouches for the owner of the domain, not for scripts downloaded
> from a CDN or even from the site itself. Also, the CA model is not
> entirely perfect, and a code signing certificate is typically different
> from a server certificate... has other key use flags and may or may not
> have additional identification requirements for the requester.
>

Actually on certain platforms, it's not the domain.

For example if you had a just an executable file, what domain is there to check ?

It's like a Extended Validation certificate (green bar) which checks the
name of the organisation.

But I'm pretty sure some people can still be fooled by an organisation named: PayPal Europe.

> >> You will need some public key crypto as well signing the signature of
> >> the app manifest (and its resources). Maybe you can package the entire
> >> web app in one signed archive and call it deb, rpm or apk. Oh wait ;)
> >
> > Well, there are a few people that have ideas about signed web apps.
>
> I think the idea is fundamentally flawed. If there is no trusted anchor
> from where to start you are screwed.
>

Well, the domain(name) is the trust anchor.

When talking about trustmodels, I think it basically is choose any of these:

With the CA model you don't depend on DNS.
With DNSSEC/DANE you have signed DNS.
With Namecoin you have a claimed name.
With the Linux distribution you can check what goes into the package repository and it's singed/checked on installation.
With the appstore model you have to hope the appstore is any good. I won't trust a proprietary vendor.
With the Mozilla appstore somewhere between a Linux distribution and proprietary appstore ?

Did I forget anything ?

> Actually, although this is off-topic, I'm beginning to lose faith in the
> whole concept of web apps as envisioned years ago. I mean, I do see
> advantages, in theory, of having multiple implementations of a JS VM
> (i.e.: browsers), but it doesn't solve any problems that wasn't solved
> already yeaaars ago. The write once run everywhere idea existed already

It did solve one problem, Javascript performance:

Though sometimes with the asm.js 'hack':

http://www.i-programmer.info/news/167-javascript/5694-firefox-runs-javascript-games-at-native-speed.html

"Firefox with float32 optimizations can run all those benchmarks at around 1.5x slower than native, or better."

https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/

It's funny, when you are running Javascript benchmarks in other languages Javascript (even over asm.js) wins:

http://www.i-programmer.info/news/167-javascript/6238-java-asmjs-or-native-which-is-faster.html

They are now also working around the DOM:
http://www.funnyant.com/reactjs-what-is-it/

Which really is the slowest part of any webpage.

> What I do like to some extent is the writing applications in HTML/CSS/JS
> and then packaging them like 'native apps', i.e. what is done in the
> Firefox OS Market, or in GNOME extensions. The stuff you link to can be
> of big use there, but not for the 'general' Web I think. That is the
> only way forward for these kind of apps I'm afraid to make them at least
> a little bit of an alternative to what is currently out there.
>

You mean like ?:

Running webapps on the desktop:

http://en.wikipedia.org/wiki/Mozilla_Prism
https://hacks.mozilla.org/2012/05/desktop-apps-with-html5-and-the-mozilla-web-runtime/

Or on Android:

http://www.extremetech.com/mobile/184404-mozilla-opens-up-app-store-to-android-with-newest-version-of-firefox

> Thanks for your extended answer and the shitload of resources :)
>

No problem.

> Cheers,
> François

Have a great day,
Leen.

[Nick Jennings]

Hi Francois,

On Wed Dec 03 2014 at 5:06:11 PM François Kooman <fko...@tuxed.net> wrote:

On 11/30/2014 07:58 PM, Leen Besselink wrote:
>> You will need some public key crypto as well signing the signature of
>> the app manifest (and its resources). Maybe you can package the entire
>> web app in one signed archive and call it deb, rpm or apk. Oh wait ;)
>
> Well, there are a few people that have ideas about signed web apps.

I think the idea is fundamentally flawed. If there is no trusted anchor
from where to start you are screwed.

Actually, although this is off-topic, I'm beginning to lose faith in the
whole concept of web apps as envisioned years ago. I mean, I do see
advantages, in theory, of having multiple implementations of a JS VM
(i.e.: browsers), but it doesn't solve any problems that wasn't solved
already yeaaars ago. The write once run everywhere idea existed already
a long time ago (Java) but never got of the ground due to lacking
first-class integration with the OS it runs on. I'm afraid the same will
happen with JS. Either fragmentation which in effect will lead to one
winner, or least common denominator apps. I guess the answer was given
by Google already when they announced "Inbox". So HTML/CSS/JS apps will
not be better than writing for any other 'proprietary' platform.

That you can trust an app simply because it comes from a "trusted source" (ie. a Linux distribution or app store) is a myth from the beginning. There is no one going through the code and reading it line by line, vetting for security flaws or malicious code, any more than there is in any other type of developer - user relationship in the open-source world. Just look at the OpenSSL bugs that had been there for years. 

The trust is actually built up from use and reputation. There are always people trying out new applications before they make it into a distros packaging, and when enough people use and like the application - voila - it makes it into the distro.

I don't think you can "solve" the problem of trust simply by making an app store, or packaging web-apps up in .debs to run in stand-alone webkit instances. Sure, if that's the only way you feel comfortable, then you can do that. What I'm talking about though is trusting that *the code you are executing in your browser is the same as the code that the developer published*. 

This is where I think the built-in browser crypto routines will come in very handly, because you can use the developers signed checksums to compare to the checksums of the code you're running. 

As for browser fragmentation. I agree this is a potential issue. I don't understand why Google Inbox can only run in Chrome, I haven't been able to find any technical articles on this (do you have any?). I think it's horrible and hope that they remedy this very soon. 

But JavaScript is not even close to the same situation as Java. JavaScript grew /with/ the web, not against it. It is an absolutely fundamental difference. The language and runtime itself is also sound, that's not to say there are no big issues with browser functionality implementation and differences in priority. Alas, you cannot regulate everything. So far the only time I've seen a modern web-app that can't run in a modern browser has been when it's using a new prototype of a feature that none of the other browsers have implemented yet. Even then, shims are quickly developed - even if performance suffers. Like I said, I don't know what's going on with Google Inbox and what their justification is, I hope it's something technical though and not political.

Cheers

Nick

[François Kooman]

On 12/05/2014 11:50 AM, Nick Jennings wrote:
> Hi Francois,

Hi Nick,

> That you can trust an app simply because it comes from a "trusted source"
> (ie. a Linux distribution or app store) is a myth from the beginning. There
> is no one going through the code and reading it line by line, vetting for
> security flaws or malicious code, any more than there is in any other type
> of developer - user relationship in the open-source world. Just look at the
> OpenSSL bugs that had been there for years.

True, it is not about the bugs, it is about what you mention below, that
you know that what you get is what the developer intended you to get.
There can of course still be all kinds of malicious code embedded in the
app, but at least you can point to the author of the code (or the
distribution packager) for screwing it up, not some unknown
man-in-the-middle.

> The trust is actually built up from use and reputation. There are always
> people trying out new applications before they make it into a distros
> packaging, and when enough people use and like the application - voila - it
> makes it into the distro.

Well, that works to some extent. Reputation is good, but it doesn't
solve the problem of running what you expected to run.

> I don't think you can "solve" the problem of trust simply by making an app
> store, or packaging web-apps up in .debs to run in stand-alone webkit
> instances. Sure, if that's the only way you feel comfortable, then you can
> do that. What I'm talking about though is trusting that *the code you are
> executing in your browser is the same as the code that the developer
> published*.

It solves one problem to have a directory of signatures for web apps you
are running... to know that you run what was intended.

> This is where I think the built-in browser crypto routines will come in
> very handly, because you can use the developers signed checksums to compare
> to the checksums of the code you're running.

True. But you need to get a list of certificates from the developers in
your browser, or how else do you know what to verify against? App
checksum pinning sounds wrong :)

> As for browser fragmentation. I agree this is a potential issue. I don't
> understand why Google Inbox can only run in Chrome, I haven't been able to
> find any technical articles on this (do you have any?). I think it's
> horrible and hope that they remedy this very soon.

https://news.ycombinator.com/item?id=8606879

Actually, I really don't care about Google Inbox and will never use it
if I can help it...

> But JavaScript is not even close to the same situation as Java. JavaScript
> grew /with/ the web, not against it.

What does this mean? Java can do REST requests or produce HTML code ;)
What is "the web"?

> It is an absolutely fundamental
> difference.

How? Especially if you see a web app as some code running in a JS-VM
sandbox...

> The language and runtime itself is also sound, that's not to
> say there are no big issues with browser functionality implementation and
> differences in priority. Alas, you cannot regulate everything. So far the
> only time I've seen a modern web-app that can't run in a modern browser has
> been when it's using a new prototype of a feature that none of the other
> browsers have implemented yet. Even then, shims are quickly developed -
> even if performance suffers. Like I said, I don't know what's going on with
> Google Inbox and what their justification is, I hope it's something
> technical though and not political.

I'm afraid that the future of web apps are apps compiled to asm.js or
NaCl to achieve interoperability... and what have we won then? :) I
guess we are doomed to reinvent the same stuff over and over on a new
abstraction layer again and again...

Other clear limitations of "the web" as a platform is e.g. Mailpile. It
can't be written as a browser only application and needs server side
code. In theory this should not be needed at all... Ignoring NAT,
firewall and performance issues it should be possible to write this
completely in JS running in your browser! You can do that on every other
platform...

Cheers,
François

[François Kooman]

On 12/06/2014 01:43 PM, François Kooman wrote:
>> As for browser fragmentation. I agree this is a potential issue. I don't
>> understand why Google Inbox can only run in Chrome, I haven't been able to
>> find any technical articles on this (do you have any?). I think it's
>> horrible and hope that they remedy this very soon.
>
> https://news.ycombinator.com/item?id=8606879

Also check the comments there. hilarious.

See what they did with the CSP: """there seems to be no CSP protected
between Google domains in Google Chrome""". Oh nooes! :P

Cheers,
François

[Nick Jennings]

On Sat, Dec 6, 2014 at 2:43 PM, François Kooman <fko...@tuxed.net> wrote:

On 12/05/2014 11:50 AM, Nick Jennings wrote:
> Hi Francois,

Hi Nick,

> That you can trust an app simply because it comes from a "trusted source"
> (ie. a Linux distribution or app store) is a myth from the beginning. There
> is no one going through the code and reading it line by line, vetting for
> security flaws or malicious code, any more than there is in any other type
> of developer - user relationship in the open-source world. Just look at the
> OpenSSL bugs that had been there for years.

True, it is not about the bugs, it is about what you mention below, that
you know that what you get is what the developer intended you to get.
There can of course still be all kinds of malicious code embedded in the
app, but at least you can point to the author of the code (or the
distribution packager) for screwing it up, not some unknown
man-in-the-middle.

Yes, this is what is necessary for being able to safely trust sources and

continue to access and try out new web apps without having to wait for
things to make it to a system package or app store.

 

> The trust is actually built up from use and reputation. There are always
> people trying out new applications before they make it into a distros
> packaging, and when enough people use and like the application - voila - it
> makes it into the distro.

Well, that works to some extent. Reputation is good, but it doesn't
solve the problem of running what you expected to run.

But it does help to determine which apps make it into trusted app stores.

After enough people try out and like an app, someone can take the time
to package it for a specific app store or OS.

> I don't think you can "solve" the problem of trust simply by making an app
> store, or packaging web-apps up in .debs to run in stand-alone webkit
> instances. Sure, if that's the only way you feel comfortable, then you can
> do that. What I'm talking about though is trusting that *the code you are
> executing in your browser is the same as the code that the developer
> published*.

It solves one problem to have a directory of signatures for web apps you
are running... to know that you run what was intended.

> This is where I think the built-in browser crypto routines will come in
> very handly, because you can use the developers signed checksums to compare
> to the checksums of the code you're running.

True. But you need to get a list of certificates from the developers in
your browser, or how else do you know what to verify against? App
checksum pinning sounds wrong :) 

This is an over-simplification, but hopefully there becomes a convention of
providing SHA256 sums of your app whenever you publish a new version in
some well-known place in the same location as your app sources. Ie. the
github repository, or something.

The location can also be published within the source code in some meta tag.

A browser plugin can identify the version and verify the SHA256 sum,
automatically informating you if they match or not. Successful matches will
be stored within the browser plugin (optionally synced to your remote storage)

and if you later visit the web app and something has changed, you are

immediately notified.

If the checksum URL has not changed, it can easily just grab the new
checksum and verify against the new code. However if the checksum URL
has changed, it would alert you and display the old URL and new URL so
you can decide if you want to trust the new source or not. Flagging apps
will warn you every time you vist the site so you don't forget to resolve the

issue or blacklist it.

That's the general idea i've been toying with in my head for over a year now,

of course, it means nothing if web app publishers don't start publishing their

checksums on each release. A hosting platform like 5apps.com could

do this automatically though.

Also, if the author has not published any checksum, or done anything to
accomodate this paradigm, you could still - if you wanted - generate a
checksum based on the current code you're running, and store that

so that next time you visit you are alerted of any changes, additional
files, new url sources, etc. It's not idiot proof, but it's not intented to be,
it's just a way to reasonably trust that you will be made aware of any

significant changes to the apps you use. Giving you more freedome to

try out new apps without waiting for them to be included in an app store
or OS package.

 

> As for browser fragmentation. I agree this is a potential issue. I don't
> understand why Google Inbox can only run in Chrome, I haven't been able to
> find any technical articles on this (do you have any?). I think it's
> horrible and hope that they remedy this very soon.

https://news.ycombinator.com/item?id=8606879

Actually, I really don't care about Google Inbox and will never use it
if I can help it...

Thanks for the link.

Actually, I really like Google Inbox, it helps keep me at inbox zero, which
makes my life easier. It's good to know that it's just a technical issue and that
they didn't want to release something on Firefox that would make their product
look bad to the average user.

I would pay money to someone making an unhosted Google Inbox clone.

 

> But JavaScript is not even close to the same situation as Java. JavaScript
> grew /with/ the web, not against it.

What does this mean? Java can do REST requests or produce HTML code ;)
What is "the web"?

Exactly, anything can do REST requests or product HTML. JavaScript/HTML/CSS,
however,  is the compile target for those other things. Java is just a binary blob
sitting ontop of the web, downloaded, and run with a browser plugin. It's not
the web.

We didn't choose JavaScript to be the language of the web, but everytime we try
to choose something to be the language of the web we fail.

> It is an absolutely fundamental
> difference.

How? Especially if you see a web app as some code running in a JS-VM
sandbox...

Sure, the web is a content delivery system for browser VMs which have
evolved to be optomized for running HTML/CSS/JS natively. It is what we
have when we stop trying to force new solutions. See above.

> The language and runtime itself is also sound, that's not to
> say there are no big issues with browser functionality implementation and
> differences in priority. Alas, you cannot regulate everything. So far the
> only time I've seen a modern web-app that can't run in a modern browser has
> been when it's using a new prototype of a feature that none of the other
> browsers have implemented yet. Even then, shims are quickly developed -
> even if performance suffers. Like I said, I don't know what's going on with
> Google Inbox and what their justification is, I hope it's something
> technical though and not political.

I'm afraid that the future of web apps are apps compiled to asm.js or
NaCl to achieve interoperability... and what have we won then? :) I
guess we are doomed to reinvent the same stuff over and over on a new
abstraction layer again and again...

asm.js is not intended for interoperability. It's a subset of JavaScript which,
when a developer programs just using that subset, and strip out a lot of
extra parts of the language in order to make a heavily optimized runtime.  A
not so sound analogy would be heavy compiler optimizations on some C
code to increase performance. asm.js is not used for everyday web app
development.

Other clear limitations of "the web" as a platform is e.g. Mailpile. It
can't be written as a browser only application and needs server side
code.

It could be, it just wasn't.

 

In theory this should not be needed at all... Ignoring NAT,
firewall and performance issues it should be possible to write this
completely in JS running in your browser! You can do that on every other
platform...

Oh, do you mean opening a TCP socket and implementing the SMTP
protocol in your web-app?

You are still using server-side technology to receive and/or route that email.

POP, IMAP... also, would still be using servers and server-side code to

complete the functionality.

Servers play a role, they should just play a "service" role rather than

"a part of a web-app" role.

Cheers,
Nick

[François Kooman]

On 12/09/2014 10:31 AM, Nick Jennings wrote:
> Yes, this is what is necessary for being able to safely trust sources and
> continue to access and try out new web apps without having to wait for
> things to make it to a system package or app store.

Sure. For experimental and proprietary software that makes perfect
sense. Just as Docker makes sense for this use case. I wouldn't trust
production quality web services to Docker just yet, and probably never,
but running a Docker container running Adobe Reader, sure :)

In my experience the (proper) packaging of software is almost trivial
assuming the developers have some clue about how to properly distribute
software. Many applications include a gazillion (modified) dependencies
that first need to be untangled before it can be properly packaged.
Point in case: Google's Chromium browser: A nightmare for distribution
packagers.

I'm afraid we will see the same for web applications, especially if it
becomes the norm to include all dependencies in the application
container and never bother again looking at it after it works... So
you'll end up with 300 copies of jquery.js in your browser cache/disk
instead of just 1 or 2.

Using the 'but it runs in a sandbox so it doesn't need to be secure' is
a sure way to shoot yourself in the foot some day...

> But it does help to determine which apps make it into trusted app stores.
> After enough people try out and like an app, someone can take the time
> to package it for a specific app store or OS.

That is true in a way, but how do you find apps when they are not in
some kind of store? Google? HackerNews? Indirectly that will then
becomes a (very untrustworthy) app market. The enemy here is obscurity
:) No one will know about your app...

>> True. But you need to get a list of certificates from the developers in
>> your browser, or how else do you know what to verify against? App
>> checksum pinning sounds wrong :)
>
> This is an over-simplification, but hopefully there becomes a convention of
> providing SHA256 sums of your app whenever you publish a new version in
> some well-known place in the same location as your app sources. Ie. the
> github repository, or something.

Well, if you already trust GitHub, you might as well use GitHub pages to
distribute the app, no need for hashes, unless they can also be
validated by checking a signature to match the authors public key.

> A browser plugin can identify the version and verify the SHA256 sum,
> automatically informating you if they match or not. Successful matches will
> be stored within the browser plugin (optionally synced to your remote
> storage)
> and if you later visit the web app and something has changed, you are
> immediately notified.

Bleh, I don't want to be notified if the version changes, at least not
in a way except "new features in release X.Y are: ...".

> If the checksum URL has not changed, it can easily just grab the new
> checksum and verify against the new code. However if the checksum URL
> has changed, it would alert you and display the old URL and new URL so
> you can decide if you want to trust the new source or not. Flagging apps
> will warn you every time you vist the site so you don't forget to resolve
> the
> issue or blacklist it.
>
> That's the general idea i've been toying with in my head for over a year
> now,
> of course, it means nothing if web app publishers don't start publishing
> their
> checksums on each release. A hosting platform like 5apps.com could
> do this automatically though.

Well, yeah, but then 5apps becomes your app store, and you might as well
do it properly then. Developers sign their app with their own private
key and publish their public key @ 5apps and be done with it :)

> Actually, I really like Google Inbox, it helps keep me at inbox zero, which
> makes my life easier. It's good to know that it's just a technical issue
> and that
> they didn't want to release something on Firefox that would make their
> product
> look bad to the average user.
>
> I would pay money to someone making an unhosted Google Inbox clone.

Yeah, we probably all would :) At least we'll have Mailpile at some
point in the future (hopefully).

> Exactly, anything can do REST requests or product HTML.
> JavaScript/HTML/CSS,
> however, is the compile target for those other things. Java is just a
> binary blob
> sitting ontop of the web, downloaded, and run with a browser plugin. It's
> not
> the web.

It could be implemented native in the browser, it just never was. I'm
just saying there is not much difference. JS is also a 'binary blob' in
most cases, heavily minified/obfuscated. There are no benefits with
being 'able' to read the Google Inbox JS 'source' code, it might as well
be a blob.

> We didn't choose JavaScript to be the language of the web, but everytime we
> try
> to choose something to be the language of the web we fail.

Sure, there is nothing wrong with JS, it just doesn't differ much from
something else. JS is not the problem here, but integration with the
rest of the system is (for now).

> Sure, the web is a content delivery system for browser VMs which have
> evolved to be optomized for running HTML/CSS/JS natively. It is what we
> have when we stop trying to force new solutions. See above.

Sure...

> asm.js is not intended for interoperability. It's a subset of JavaScript
> which,
> when a developer programs just using that subset, and strip out a lot of
> extra parts of the language in order to make a heavily optimized runtime. A
> not so sound analogy would be heavy compiler optimizations on some C
> code to increase performance. asm.js is not used for everyday web app
> development.

Not intended, but the best we have? It actually *is* interoperable :)

>> Other clear limitations of "the web" as a platform is e.g. Mailpile. It
>> can't be written as a browser only application and needs server side
>> code.
>
> It could be, it just wasn't.

I'm sure lots of stuff is missing. For example opening a socket to IMAPS
on a random server somewhere (without using another server somewhere
doing WebSockets <--> IMAPS for you).

> Oh, do you mean opening a TCP socket and implementing the SMTP
> protocol in your web-app?

Yeah!

> You are still using server-side technology to receive and/or route that
> email.

Uh... but so does Thunderbird? So if you want to write a mail client you
need to be able to speak IMAPS, SMTPS, etc, from the client pov.

I found Firefox.html somewhere on HN a couple of days ago, this is very
interesting!

https://github.com/paulrouget/firefox.html

Cheers,
François