Just curious (and no negative implications whatsoever): is "we made it so that only one person at a time can type in a paragraph. No longer can that annoying classmate delete what you just typed" code for "operational transforms are hard to implement, especially without a source of truth?"
Yes and no :) I did indeed not implement OT, but it's also a true story that I would create a Google Doc and share it, nobody knows what to write, I type a sentence, and my classmates delete it as a joke, to mess with me :)
But yeah, feedback on the collaboration is welcome. Do you think editing one sentence with multiple people is necessary, and if so why? And on the other end of the spectrum, Word-style edit requests (which need to be approved before they are applied) are also sometimes necessary.
My main use case for Docs is collaborative fiction writing. There's no concept of "paragraph ownership"; there will be two or more people editing the document, and we'll go over it a half-doze or more times, editing as we go.
The ability to make arbitrary changes is essential for this.
There's no permanent paragraph ownership in Airborn OS either, but it's locked for about 10 seconds when you edit a paragraph. Or are you saying that the two editors would be editing the same paragraph at the same time?
I use Google Docs only for work. It never happened that we inadvertently deleted each other's work but it happens that we have cursors in the same paragraph.
Maybe there are multiple reasons for that.
One is that we're not in the business of trolling coworkers and losing time, quite the opposite. However I can understand that when I was little that would be fun sometimes.
Another reason is that we often use another channel to coordinate our work, email (I'll be working on that), chat or voice calls. The risk of undoing someone's work is nil.
With the approach of Airborn it could happen that I have to say "please move your cursor somewhere else so I can show you an alternative" or fix a typo. That would be odd and make us lose time.
To offer a different use case: as a high school English teacher I will commonly work through a paragraph with a student, commenting and modifying as we discuss. The lock out would be quite frustrating.
Sounds really pragmatic. Two people editing exactly the same thing at the same time sounds confusing; not just really hard to implement. i.e. Why would anyone want someone amending as they type. This approach makes the user experience simpler and simplifies the implementation. I like it :).
The only scenario where I can see this being a bad decision would be for bots. For example, if you had a spell checker loaded which ran as a separate user rather than under your own session; so the spell checker couldn't auto-correct words until you'd finished typing the sentence. Here I'm imagining something like Rosie the translator bot from the original Google Wave demo... But I don't think you have bots anyway, so this won't be a concern for the present anyway.
I have had plenty of real-world situations, with Google Docs, whereby I have fixed someone else's spelling (or vice versa) as they have been typing. Working on sheets/slides where this isn't available has always felt awkward in comparison, and I wouldn't look to get more of it.
I for one welcome this decision. I would perhaps limit the locking to one sentence at a time (which may split into several after editing) rather than a paragraph, and with an optional timeout for inactivity.
I am a big fan of open source alternatives to Google and Facebook (see Qbix). Do you mind if I contact you?
I agree. This may be a useful and simple way to implement locking. Often when editing for things other than minor punctuation or spelling, individual sentences or paragrapshs often get split or combined as statements are rephrased or ideas reorganized.
It's good to have if you want to go peer2peer eg. not having a server in between. Btw, Google Docs don't use a OT, or only a simple one, it does depend on the server and that you are online.
A writing style that I try to use is that I just type ... don't look up words, just write YYY where I can't find the right word to use, then I read the text and fix all spelling errors, sentences, remove unnecessary parts etc. That way you can be in flow. But instead of you doing the fixing later, someone else can do it for you - while you are writing!
Google Docs does use OT. Or at least it did about six years ago, and I doubt that has changed. Source: I cowrote the original implementation (which was not OT, it was a three way merge of complete HTML files), and I was around when a new team rewrote the entire app using OT.
Historical note: live three way merging of HTML files, being produced by content-editable div implementations in different browsers, which like to rewrite each other's coding decisions in arbitrary ways (suddenly all your BRs become Ps, whee!) is "fun" in a way that I don't really ever need to revisit.
Any plans to make self-hosting straight-forward? Granted, I haven't spent much time looking for it, but I've been looking for something similar to this for quite some time, and Nextcloud's Collabora isn't quite what I'm looking for.
Not really, because of https://news.ycombinator.com/edit?id=15596604. Why would you like to self-host? (Not implying that there are no valid reasons, just curious which reasons are important to you.)
Google locked me out of my documents. I have more trust in Google to provide a service than you. If Google does not reliably provide the service, I'm moving the service on-prem.
Nothing in particular, I just already have a server set up with a good amount of storage because I didn't want to pay year-to-year for something like dropbox to save photos and videos to.
I'd also be interested in getting the documents to appear in my Nextcloud and vice-versa.
At the end of the day, it's mostly about having everything in a central location with a good set of backups in place.
I see. What are you missing in Collabora? There's also OnlyOffice for Nextcloud, which is quite a feature-complete editor, I think: https://api.onlyoffice.com/editors/owncloud
Because if I'm going to bet on someone other than Google keeping my crap secure and accessible, I'm going to be betting on myself, not on some fly by night entity with a very limited runway.
It seems like holding down a key does different things in different language alphabets. I can't seem to hold down a key and have it type the same character repeatedly in English, however (e.g. press a, expect aaaaaaa... until key up).
Any intentions on adding support for right to left languages? This is the only reason why I have a Windows 7 virtual machine with Office 13 installed. I am looking for alternatives.
If you select an RTL interface language, the UI becomes RTL. And in Chrome, you can select RTL in the editor in the context menu. Are you looking for something similar to that in Firefox, or are there any other issues with RTL?
Yes, that works. (I can start using this more). As a suggestion maybe you should add the writing direction to the top options. I would not have thought to check the right click menu for anything other than cut/copy/paste, spell check and other less important things.
Oh my gosh, this looks like months of work, even if the editors are OS, the beautiful homepage, the billing, replying to emails and keeping everything up...
Thanks a lot! It has indeed been years of work, and while the Firetext editor existed as a mobile Firefox OS app, a big chunk of work has still gone into it. The presentations app is closer to how it already was, though.
Even without any browser involved, just curling it takes 1.5 seconds on my mac
time curl "https://airborn-usercontent.herokuapp.com/pub#?f=c8d42cd38bfc2c26/87261eeee80726bf6eb9ed886ce7517c7435b1c267e4f50b48eae9582a6ef4c8"
(....)
real 0m1.570s
Thanks for the report. Unlike the rest of the website, that url is not behind a CDN (although the document itself is), mainly because it's on a different domain (for security reasons). For me it's relatively fast, but I'm close to the server. I'll try to get it behind a CDN, too.
When you were running an operation at Google scale, the challenge of fighting fraud is something that people who have not worked at that scale can only imagine. These guys will also encounter fraud at some point. And when they do so, I guarantee they will be no better at it than Google this.
If they can't access the data, then they shouldn't be able to moderate it.
There are plenty of things on the web where you can upload data and they don't use machine learning algorithms to decide if your content is "valid" or "invalid". It all depends on various tradeoffs.
> Right, google drive has a big problem with public file hosting and piracy.
I'm pretty sure this isn't a DMCA takedown case here. Google scanned the content of the file, didn't like it and removed access via an algorithm. Nobody but Google knows how it works.
If the content is encrypted then it's impossible to use google docs document viewers, editors, or collaborate online on a document directly via google doc. It becomes just a dumb file host with no added value.
You're probably right about that. But, I believe that reading and blocking private, non-shared, documents in a user's account is not the right approach to abuse. If it ever becomes necessary, Airborn OS could inspect publicly shared documents for abuse, too.
You just made a perfect argument for why the Google design is inadequate. It centralizes way too much power to make them the target of lawyer and it makes them the arbiter of acceptability as well.
You state that the problem of fraud is particularly challenging "at Google scale". There is a fairly easy solution: Don't do things at Google scale. Many of these nearly unsolvable social problems we've created, such as YouTube content moderation, are manageable, or simply don't occur, outside Google scale.
Which begs the question: Is doing things at Google scale really something to aspire to? Has even Google solved the problem of doing things at Google scale if they have problems they cannot solve adequately at Google scale?
Yes, totally. A completely new service that has quality controls so tight they'd never use white-on-light-blue text for their website is much more likely to be reliable than the world's largest internet company, considering the latter just today had a bug affecting about 1 in 500,000 users before it was fixed two hours later.
The worst part is that there seems to be little to no recourse. Unless your a GSuite user, you have no support number to call and have to wait until the issue resolves itself. If it does.
This looks great! Minor nits: In what way is this an OS? Also in the US, Airborn (e.g. to be in the air) is spelled "Airborne" and it's difficult to type it without the trailing 'e' without spellcheck fixing it automagically.
The most significant ways in which it's a bit like an OS are
1. It has a Window Manager (try it out in the demo, you can drag around windows and such)
2. It has a File System, which does encryption and compression. This makes it so that the "apps" (documents and presentations, and in the future hopefully spreadsheets) don't have to know anything about encryption. This made it very easy to port the presentations app, for example.
3. It has a Marketplace with apps (not that they are very useful).
But yeah, since many people don't seem to like the name nor the OS-like UI, I'm considering dropping both. I'm just a bit concerned because there are many other companies named simply Airborne or Airborn. Also, integrating documents and presentations into a more unified UI would be a lot of work, since they're pretty much standalone apps today.
Names barely matter, but yeah, the "OS" is confusing, airborn makes me think viruses and plagues, don't get any feelings of "documents", or "encryption", or "security" from it, and the namespace is overloaded, it will be hard to get rank.
Otherwise I really like the project. I want all my data on all sites to be locally encrypted and backed up in the cloud. Documents is the perfect start, because there is very little server-side introspection needed. I'd like my friend graphs and contacts to be next.
In terms of UI, start by copying google docs exactly, they did a fine job.
Misspellings are usually on purpose to provide distinctiveness as a in built defence against a trademark being claimed to be a term in the art or a generic term.
I like the name, -born (i.e. conceived) on the air - i.e. in an ethereal space. As opposed to the suggestions for "Airborne" which would be carried on the air, the use of "born" is better as it suggests genesis.
I don't think this product is from the US and is primarily for English speaking audience. I guess they added english support later. Because, you can see "redirigir al navegador a otra" when redirecting.
I see the domain is registered in the Netherlands.
I like "even if we get hacked" With all the data breaches in the news I feel like this is a selling point many would understand.
I would even go further and say "and even if we get subpoenaed"
my 2cents
If you get hacked, the attacker will replace the application code. When the user logs in again (or opens a new browser window) the modified application code will decrypt all of their data and send it to the attacker. The encryption provides no protection from hackers.
Protection from hackers comes only from reviewed and verified software and hardware. The only consumer platform that comes close is iOS.
You should speak to me, as a customer, about my benefit in using your product.
Currently you're telling me what won't happen in a very unfortunate event. I think this is wrong in 2 ways.
1. You're telling me a message "the other way around". Even if you just say "Keep your documents secure" is better than "Nobody will access your documents".
2. You're comparing w/ Google docs so, following the logic of your message, what's the probability that Google will get hacked? Tiny, right? So... you're not telling me anything useful.
You can check lastpass or 1password as examples. They implement more or less the same thing, but as you can see they don't talk about how it works, but about the benefit for me, as a customer.
Thanks for the suggestions. The reason I mentioned getting hacked in the copy, is because I think that for the average customer, it's now starting to seem like every web service is getting hacked. I wanted to highlight that we're trying to solve that in a better way than "well, this time we really won't get hacked!" But yeah, I'll try to bring out that message in a more positive way.
I like the copy. "Even if we get hacked, they can't read your ..." is a real claim. It means something concrete, and is an interesting hook for someone who's technically literate. Something more generic like "We keep your documents secure" means almost nothing nowadays -- literally every online document storage system will tell you that regardless of how seriously they take security. I'm sure Equifax will be happy to tell you how secure your data is with them.
> for the average customer, it's now starting to seem like every web service is getting hacked.
It did have a positive influence on me right away. It also established this sense of trust. Enough that I began to crawl through the other pages for more info.
I also appreciated how you managed to convey, in a single image, exactly what was encrypted (ie, both document content and filename).
The first question I had was how Google Docs handled this. Do they also encrypt? If so, do they encrypt both filename and content? Considering Google's business model, I always assumed that they did less in this regard - relying instead on other mechanisms to protect user data.
I would keep the encryption message and double-down... comparing how other services handle privacy, tracking, data-mining, encryption. It's your strongest selling point.
You mean as proven by being able to share docs publicly? There isn't some grand conspiracy here, Google never claimed they couldn't read your content. That's literally the point of most of Google Docs is that Google _can_ read the content.
You have good points and in you might be right for the common user.
But as a technical user I despise that and I liked the honest way this was presented. Because this is something everyone should be thinking before signing up (granted most don't, so, yeah).
No, I don't necessarily think it implies you'll be hacked immediately, or anytime for that matter.
I definitely get what you are trying to do though. It's so secure it doesn't matter if someone has the data.
Perhaps some clever illustration depicting the odds of cracking AES-256 (e.g. a man fishing in the ocean but there's only one fish to be caught). Visuals can be a great way to convey complex concepts.
I don't think what you have is a huge red flag but someone might read it and say "Whoa, ok, it sounds secure but what about other systems they have in place? Are they insecure, are people trying to get at my data 24/7 on their servers, etc.
Your current copy tells something very real and concrete to the user, gives him valid information. It is useful.
All suggestions in this thread ("it is secure!") are just marketing gibberish, slogans without any meaning. If you intend to appeal to a large, stupid audience, maybe they're good, but it is a little dishonest.
While you are right, it wouldn't be that great of an idea for Honda to market their new airbags by saying "Next time you get into that accident, at least your face won't be smashed into a million pieces by your wind shield!".
While what he has is fine, you can convey the same sentiment without saying "Even if we get hacked..."
Yeah, exactly. I agree with the "so secure" suggestion by the other commenter. You can tweak it to your liking but you don't want to give the impression you're anything less than complete with your approach to security.
Thankfully, I don’t think this is a super strong selling position. Google has an incredible reputation for keeping its users safe and their information private. What you don’t know is whether google in fact stores your documents in an encrypted format at rest. If they do, then what exactly are you offering?
Google can and does read your documents (in an automated fashion). That's how they can flag documents for abuse/TOS violation, as they are currently having issues with today. The whole argument here is that Airborn OS can't read your documents, presumably at all.
A bit off-topic, but since Google's goal seems to be know everything possible about you, so they can sell better, more expensive ads and make more money, they presumably do more than just look for TOS/copyright violations. Otherwise I agree with what you said.
Everyone gets hacked (in the sense of 'data breach', not 'encryption cracked' - 90% of compromises seem to be simple social engineering such as spearphishing) sooner or later if the data they hold is interesting enough.
I'd choose a company that says "even if our servers get stolen, your data is safe" over "data breach? us? unpossible!"
Not sounding like marketing material is exactly what makes it sound trustworthy to intelligent people. I can only assume that's the current target audience.
Yes, it is, but after that, it stays installed and runs before you open the web app the next time. In effect, this makes it trust-on-first use, just like if you'd install a desktop app which then had some secure update mechanism.
Yes, it can, but whenever the Service Worker's code changes, the user is warned. There's an "updatefound" event [1] which both the web page and the old Service Worker get. I wrote a blog post with more background info at [2].
Of course, it would be better to only warn the user if the Service Worker changes if it doesn't match the version on GitHub, but that's blocked on [3].
Furthermore, there are some very edge-case situations where the Service Worker can update when Airborn OS is not open or not visible (e.g., in a hidden iframe [4]). That is why, when you register and check "Notify me before updating Airborn OS", it asks you for permission to send you notifications. Those notifications are currently only used to warn you when the Service Worker updates.
The concept of Transparent Web Apps (TWA) is an interesting one - more so than AirbornOS itself. Any chance of packaging it (i.e. in the form of library, or make it as a SaaS) to promote adoption? This can enable more TWA and perhaps pivot yourself to become the TWA hub/directory.
Yes, I'm planning to make a library for it. It won't be quite install-and-forget, because the developer has to 1) push to GitHub or another public log before every deploy and 2) somehow let the Service Worker know where to find the latest version on GitHub. But it's definitely possible.
A TWA hub sounds interesting. I think that if you have a list of web apps that
1. are a Transparent Web App
2. have had a security audit
you could then add some UI in the browser that says "this web app keeps your data private". That would be useful not just for apps that use client-side encryption, but also very simple web apps, like say word counters. It's very useful for users to know whether the word counter sends their data to the server or not.
Of course, step 2 would be quite expensive, although for simple web apps it would be manageable. It would have to be financed by either the web apps themselves, or some big entity like Mozilla (which for years has had volunteers manually check browser extensions for things like this, too).
The JavaScript trust issue will always be a concern when webcrypto is used, and webcrypto is a web Api expected to be made broadly available across browsers (desktop and mobile). If somehow the concept of TWA can be made easy for developers to adopt and you pivot to handle/streamline the heavy lifting, I think you may have a much more lucrative nitch. Think of this as VeriSign for TWA. Wouldn’t that be cool? Someone (i.e you or Mozilla) should do this. This really promotes the open web.
> Yes, it can, but whenever the Service Worker's code changes, the user is warned. There's an "updatefound" event [1] which both the web page and the old Service Worker get. I wrote a blog post with more background info at [2].
Unless this is an extremely rare event, a hacker could easily just piggy back on a recent change and inject a worker that does not alert on "updatefound".
If the service is hacked and if the "update found" alert isn't a very rare event, users will not validate every single update against GitHub, and a place check would see an update, allowing the attacker to push code when an update is made. A good portion of users will run the infected code before the service is shutdown.
I never said it was easy. I said it was possible and doable.
First, you said “easily”, so I thought it must be effortless. Second, only paranoids and security conscious individuals will ever validate against GitHub. Your average Joe really doesn’t care. I do however agree with you that security must be hardened as much as possible, but your hypothetical case is weak. It will work for any software that auto update. Browser? OS? Let me give you another one, what if a satellite flies over your head and capture your password as you type? Oh and how about your CPU? Should we start making our own hardware now? You know.. can’t trust anyone after all.
Yes, I did and was wrong. Easy does not mean effortless and I also meant it in a context where the machine was already compromised, but didn't make that clear.
> only paranoids and security conscious individuals will ever validate against GitHub.
The op expects this to happen anytime a user gets a message saying the code is updated. I agree that no one will do it and it'll become a click through.
> but your hypothetical case is weak. It will work for any software that auto update. Browser? OS?
I state in another post that you are always subject to this issue. However, when running local software, and not at the mercy of someone else's computer/server, you have the ability to choose when and how you update.
I can also validate all code against signatures and public logs before running it, which is not something that can be done with service workers or any website in general. twiss says as much themselves: https://github.com/w3c/ServiceWorker/issues/1208
And yes, there is normally an implicit assumption that the hardware is not spying on you simply because there are no alternatives.
It really comes down to how often I need to validate my trust and how easy it is to do so.
Web apps, under the best conditions, are hard to grab and pull all the source into external files for examination and almost impossible to do so before executing it, baring using tools like curl or wget, and running the js yourself to figure out what else needs to be downloaded. Not to mention that needs to be done every time I access the app.
With a traditional app or is, I could (not that anyone does) verify the code (which for f/oss is easy to obtain) before I compile it myself. (Where I'm trusting the compiler, yes.)
I'm not trying to argue that there is a perfect method. I'm arguing that this application isn't even in the running for a good, fairly trustable method. I don't believe it solves the fundamental issue of having to trust the code download every single time, regardless of their service worker check because it itself is not protected. We'll, protected by the vigilance of the end user, which is where we started anyway.
What if the hacker changes the HTML file to point to their evil version of JavaScript file without ever triggering the Service Worker’s cache? Will that defeat the security feature?
Oh yes, as if it was an offline app when initiated. Interesting. You should really make this more broadly available and perhaps build service around it. If you can make it security sounded, then I’m sold. Perhaps, it solves the trust issue of JavaScript. For the fun of it, maybe throw in some blocktrain tech or something to enhance that trust model of yours. Would love to see how this gets developed.
That would move the trust from GitHub to that public log. However, GitHub provides us not just the "publicly verifiable update" part, but also the "authenticated update" part. In other words, how do you know that the person putting something in a blockchain is the owner of the website? You'd need a public key, and then not lose it, etc. But it's indeed possible.
This is a really interesting train of thought that I wasn't familiar with. Thanks for pointing out Binary Transparency, and I'll be eager to see where your product goes!
Hopefully you can get it fixed in other browsers. My apologies for this, but I find it amusing that a Google services alternative works better in a Google provided browser. :-)
"We (the makers of Airborn OS) won't be able to read them even if we wanted to."
I take such claims with a huge grain of salt on the web. YOU serve the Javascript. YOU can change it at any time to phone home what I wrote. No point in trying to change it with the Web alone - that's how it's designed. The server must be trusted at all times.
That's interesting, but you're plugging holes in a waterfall I think.
For example, that first visit which installs the service worker can already deliver bad code.
Not saying you will do it, but it all relies on people trusting you not to do it. So statements like "we CAN'T read your stuff" are not true on the web. Luckily, most web users don't care about being hacked by the server - they care about owning their own data! :)
Agreed but with a desktop app, the author can sign it and the OS verifies that signature. Sadly the Web does no such thing with the top level document.
Yes, that's true, but the author (or intermediary-who-delivers-the-binary) can also.. not sign it (deliver an unsigned version). Often, you don't have many other options than to trust the binary the website is serving you.
As for the crypto, am I correct in seeing that it uses PBKDF2 to derive an AES key from their password. And then it uses SJCL's encrypt/decrypt methods?
When you create an account, it downloads a file which contains
- Your username
- Your password, encrypted with a random key.
That random key (but not your encrypted password) is sent to the server. When you request a password recovery, we send you a file by email which contains that key and with which you can decrypt your password.
That way,
- We don't have your encrypted password
- A random person / application can't grab your password from your computer
- We verify that it's you who wants a password recovery (by sending you an email).
What extent of docx support is important, do you feel? Is just importing docx to html (the native format) sufficient, or should they stay as docx while editing? Should it be possible to export from html to docx?
As an end user, I don't care what format Airborn uses internally. What matters is that I can interact with documents and files sent to me by other people, which are likely authored using Microsoft Office, Libreoffice, and Google docs.
As a developer, I would ideally recommend to look into using a custom internal representation for a document and developing converters that convert between your representation and various formats. This way you won't be hindered by limitations of a specific format.
However, if you lack the resources to develop and maintain these converters yourself, look into the feasibility of leveraging LibreOffice by using a preexisting format like WordProcessingML as an internal format. You can then use LibreOffice to handle the conversion between the various formats you want to support. The downside to this is that you'll eventually outgrow WordProcessingML if you want to support futures not supported by that specific format.
Also, consider placing print preview near the print command, or vise versa. Having two locations that contain the same type of functionality can be confusing.
The very premises that a hacker can't read my data is laughable. Unless I'm using a native app to do the decryption a hacker could gain access to my data as it leaves your server or if they can store the encryption credentials from my session and use them later
When it leaves our server, the data is encrypted and not readable. To get your encryption key, they would need to execute code in your browser, and we describe how we protect against that at https://www.airbornos.com/docs/security.
Of course, we're only talking about when our server gets hacked. If your computer gets hacked, you have a problem regardless of whether you're using a web app or a native app.
> To get your encryption key, they would need to execute code in your browser,
You mean like all the javascript you're sending me?
> To solve this, we're using a relatively new web technology (Service Workers) to install some code which can't be changed without setting off a warning to you. That code then keeps taps on all other code, and checks that it matches the publicly available version on GitHub.
I really think you need to rethink your security here, because this just makes me even more sure that I don't trust you. It's actually a good bit laughable. If an attacker has access to your server, why should I believe that they wouldn't be able to update your github repository? (Why do I know you use different keys, don't put your private key on the server, &c?)
I have to trust you _regardless_ of any of your technology, and that's the problem. If someone has your server, there is very little I won't put past them to also have access too.
In sum, I think you're in for a world of hurt if you expect anyone who actually cares about security to trust you to never, ever make any mistakes.
> Of course, we're only talking about when our server gets hacked. If your computer gets hacked, you have a problem regardless of whether you're using a web app or a native app.
You're obviously just being needlessly argumentative about this. My meaning is obvious because of the context and the situation I described.
> I don't have my GitHub password/keys on the server. Why would I have them there?
Because you only need an SSH key to push to github and it's not uncommon for people to leave those laying around (or to forward them with a connection!) on a server.
The better question is not "Why would you have them there?" but "How do I know you don't have them there?"
> Yes, but it's trust-on-first-use. There's a big difference between
You're showing a very fundamental misunderstanding of trust and security. I trust your code every single time I load the application. I don't care what measures you _think_ you've put into place, I will _guarantee_ you they are not fool-proof if you have a compromised system. You're insistance that it is is very disheartening and continues to degrade any trust I would have placed in you.
> 1. Trusting me today when I say that the GitHub keys are not on my server,
No, it's trust that you will never ever ever ever place them on any device you ever own where it is accessible or that said device will never ever ever be hacked.
> 2. Trusting me today when I say that I'm not sending your password to the server, and being able to verify that by checking the code on GitHub
And when this changes? Must I audit the code every single time I load the code? Because yes, I need to do that to ensure you havn't changed anything.
> 1. Trusting me every time you open the web app
I still need to do this.
> 2. Trusting me and my hosting company that I won't ever get hacked
> And when this changes? Must I audit the code every single time I load the code? Because yes, I need to do that to ensure you havn't changed anything.
No. The whole point of what I've done and made is to make sure you don't have to do this. The Service Worker checks all code that is coming from the server. If you've opened Airborn OS before on a computer, and don't see a notification saying that Airborn OS has been updated, it is guaranteed that it's still the same code. If it did change, you get a notification with a nice link to GitHub, where you can inspect the commits since last time. That code is guaranteed to be identical to the new code that you will be running if you refresh Airborn OS.
I'm glad you think that. I still don't trust you, nor do I trust that you will never be breached in such a way that a malicious update will be pushed. Everything you're saying still depends on me trusting you.
What if this is my first time loading? How do I know you're not serving up new files that don't contain checks to be visitors?
Moreover, are you insinuating that you will never update any code and that expect that pop up saying you've updated the code to never appear? Do you expect people to check commits multiple times a week or a day?
So, ok, let's assume you're 100% trustworthy and a malicious actor changes the code and I get an error. Am I now forever unable to access my documents? How can I be sure that the code I'm running is really the code on GitHub after a breach? How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly.
But again, this all assumes that your 100% trustworthy, and you're not. You're just some person asking me to believe you'll never ever make a mistake or be coerced into a malicious action.
Also I haven't seen a mention of the aes mode you're using. Your security pages is laughably shirt given that it's literally your main selling point.
Like I said, it's trust-on-first-use. This is no different from installing a desktop app.
> How do I know you're not serving up new files that don't contain checks to be visitors?
The Service Worker is installed on your own computer, and is still there the next time you open the web app.
> How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly.
You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to be. There will always be circumstances where I'm downloading it for the first time, even in the same browser and computer.
Also, step 7 on https://w3c.github.io/ServiceWorker/#update-algorithm says that updating the service worker bypasses the service worker. How do you then validate that new service workers haven't been meddled with?
That's blocked on https://github.com/w3c/ServiceWorker/issues/1208. However, there's also an alternative option to make updating the Service Worker unnecessary, by making a "stub" Service Worker which downloads, validates and executes the rest of the SW code. Then, whenever the "stub" Service Worker updates, it's likely a breach and we can warn the user accordingly.
Code you can't update is normally an expensive liability in the case that it's not perfect. Also, then the stub service worker is subject to the same problem it's attempting to solve.
I'm still left in a situation where I need to trust you don't mess up.
You even say it yourself:
> (Of course, we can't prevent the update, but we can at least try to convince the user to close the web app before it steals their private keys.)
I have nothing to do with this product, and although you appear a little negative towards the OP, it still seems as though you have quite a lot of knowledge in this area. So you peaked my interest. What what you do to avoid the scenarios you highlight?
Everytime you load a webapp, you are trusting the server. Everytime.
In this case, the author is trying to take steps to make changes more visible, but at the same time they're making their own changes cause alerts as well. However, if the product stops serving such countermeasures for new users at some point, or plays a long con over say a year of really tiny, innocent changes that eventually break the system to check downloaded files, then we're no better than any other web app out there.
So unless you're inspecting and verifying the code you actually download yourself, even with these countermeasures, you're no better than any other webapp with the need to trust the code you download _every_ time.
Now, you're always trusting a lot of things like your hardware, your compiler, your package maintainer's compiler, your package maintainer, &c (http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html). The difference, however, is that I only need to verify that trust each time I update my code, which I can do when I choose to (baring any incompatible server changes) and after I perform any audit I choose to. (With a web app, there is often no (straighforward) way to audit the code _before_ it's been downloaded and executed.
I know I've been negative about all of this to OP. I'm sure he's done a tremendous amount of work. It just makes me angry when people claim they've solved one of the largest, most important problems in cryptography, when all they did is just ask me to trust them in a different way. It also makes me annoyed that for a security-focused product, there are very few details about architecture and cryptographic choices on the product's security page.
I don't mean to denigrate the work OP has done. I just feel that they're being foolish in their security-related claims.
> With a web app, there is often no (straighforward) way to audit the code _before_ it's been downloaded and executed.
Yes, often, but not in this case. With Service Workers, you can notify the user before the code has been executed, and in most cases prevent or delay the update as well. That's why on https://www.airbornos.com/register, there's a checkbox marked "Notify me before updating Airborn OS." If you check that, Airborn OS will literally ask you whether you want to update.
First, service workers themselves are updated outside a service worker, so that is code I can't easily intercept before it is executed. (And first page load as always.)
Secondly, I still need to trust you not to make a mistake or not not be malicious over a long period of time making small tweaks that look innocent but over a year cause harm.
Third, users will become fatigued if every update you make causes them to click ok.
Yeah. While possible, Airborn OS isn't really meant to deploy yourself. If you want that, you might be better off with nextCloud or similar. Airborn OS was built to have a service that you don't have to self-host, while still being just as secure as self-hosting: https://www.airbornos.com/docs/security
Why does it have OS in the name? Is it an operating system? (This is a question I cannot find a direct answer to on their site)
Their site makes it incredibly difficult to actually find out what this really is.
The only text visible on my screen when the page loads are the lines "Airborn OS", "Even if we get hacked, they can't read your documents" and "Collaborate in real time" which tells me essentially nothing about why I'm here, what this website is, or what you're trying to sell/advertise.
The only indication as to what this software actually does is in this Hacker News title.
For contrast, Google Doc's homepage[1], the first two things I see are "Create [persuasive/adjective] documents" followed by "With Google Docs, you can write, edit, and collaborate wherever you are. For free." This tells me basically everything I need to know, as a casual user, to understand what Google Docs is and why I might want to use it.
I hope this doesn't come across as overly critical, just some (hopefully helpful) feedback.
The line that's supposed to tell you what it is is: "Create and edit files online, securely." Is that missing for you? (I admit it's smaller and less noticeable than the lines you quoted. I'll try making it more prominent.)
Fair enough. There's a fast-forward button for the impatient among us (including myself), but I agree that it's non-obvious that you would need that to read the main copy.
Mm, I don't see it. There's some animation at the top, I scroll down, and... it talks about editing documents, but there's no line anywhere that explicitly states what this is.
The whole idea of "cloud computing" is innately terrible on virtually every level. Those willing to entrust their data and the integrity of their data to any third party are either not very informed or not very smart(especially given the virtually daily reports of hacks, data breaches, and corporate malfeasance). This is especially true for word processing, which even the lowest capacity machines have the capability to perform without issue. If you value your data, your intellectual property, and your ability to perform technical tasks without disruption, you will be well-served to write all your own papers and documents on your own computer. Store them on your own hard drive and back them up to a flash drive that you physically control. Entrusting your data and your capacity to work to a third party should be avoided unless you have absolutely no other choice.
The odds of a house fire and my inability to access critical data is significantly lower than that of a cloud malfunction like the one that occurred today.
How many people had deadlines or papers due and couldn't access their data? Many more than couldn't hand in their papers or make their deadlines because of a house fire.
> Entrusting your data and your capacity to work to a third party should be avoided unless you have absolutely no other choice.
I sympathize with this concern, although in some cases, being able to read and edit documents from your phone, and collaborate on them, is very useful, and that requires some kind of cloud service. But I would very much like to implement things to alleviate these concerns – bulk export/backup, offline access, etc. If Airborn OS ever goes down, I'll make it easier and provide instructions to self-host.
>I sympathize with this concern, although in some cases, being able to read and edit documents from your phone, and collaborate on them, is very useful, and that requires some kind of cloud service.
Not being able to read and edit documents from your phone when the cloud locks you out of your document is also a concern (above and beyond all the concerns about security, privacy, and not being in control of your own data).
>Imagine you're working on a Google Doc when, seemingly out of nowhere, your ability to edit the online file gets revoked. What you see instead is an error message indicating that you've violated Google's terms of service.
>For anyone who stores work in the cloud, suddenly being unable to access your data — especially due to a terms of service violation — may sound scary. And it's really happening to some people, according to reports on Twitter. Rachael Bale, a wildlife crime reporter for National Geographic, said Tuesday that a draft of her story was "frozen" by Google.
I’m willing to trade the privacy of documents that, were they made available to a malicious actor, would make no difference to me in the slightest, for the convenience, availability, and shareability that cloud document services provide.
The alternative usually is to put your trust in a piece of software that you don't actually know, unless you have the technical knowledge and time to review it yourself.
It seems that most times you will be changing the cloud for a illusion of control.