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