This not being an official release from Google, using this is potentially worse than giving someone your Google password without fully vetting it. There are some existing safeguards in place to make a password alone difficult to use, but the app itself would have signed in access to your account and the contents of files. You may think it's simple to watch the app for bad behavior and decide it's safe, but you wouldn't be thinking deviously enough.
Nothing against the developer as they may be trustworthy and honest, but don't make the mistake of assuming that someone bold enough to put out something that requires that much trust must by extension be worth trusting. People too often do.
That only applies to the password, but the password wasn't really the concern. If you're signed in (no matter how you signed in), a modified browser has the same access to your account that you do with creative possibilities for abusing that. You can argue that if an app isn't trusted then there are other concerns with running it on your machine and that is true too, but some apps want to avoid being too suspect in order to maintain their installation as long as possible. Extra scrutiny in any scenario like this is good. :)
It wouldn't matter how you signed in for potential abuse to occur if the app itself is untrusted, unfortunately.
The repository doesn't include all of the code that gets included in the app, because it has dependencies. It links those dependencies on the github page, but you have to verify that the dependencies being linked to are the ones the build actually uses. Then check that you like what's in those dependencies. At first glance, a forked version of one of the dependencies is pulled from his own repository instead of the repository linked on the page, so you have to make sure you aren't vetting the wrong repository. Then the release archives package in Electron for you, so that's another thing you're trusting if you don't build it locally.
It doesn't mean anyone is doing anything wrong, but even if they have good intentions good people pull in bad dependencies occasionally too.
Developers as people are innocent until proven guilty. Software is guilty until proven innocent, especially if there's a higher chance of a security risk. Not everyone can assess that well for themselves.
> It wouldn't matter how you signed in for potential abuse to occur if the app itself is untrusted, unfortunately.
> The repository doesn't include all of the code that gets included in the app, because it has dependencies.*
> Software is guilty until proven innocent
I'm not saying you're wrong about any of this, and I don't trust this app myself (mostly because JS dependencies are hard to trust for various reasons), but...
I also can't think of any usable app that meets your criteria for trustworthiness, including some made by Google itself.
At this point, building much of anything requires standing on a teetering tower of dependencies that users can't and won't audit.
The question becomes where one draws the line. I think drawing the line at "anything that touches my Drive files" is reasonable, but we (meaning computer users) spent decades downloading sketchy executables for our Windows PCs. Although many things are browser-based now, many of us still do download native executable freeware from the web.
If you think I'm not offering a better perspective, it's because I'm not. You're right, but total security also currently means using very little of the software that's available to us.
These days, I’m very careful what gets downloaded on my computer for just that reason. Dropbox for the Mac is a security nightmare and Zoom was doing shady crap before like installing a web server to redownload itself if you uninstalled it.
On the other hand, I download all sorts of random crap on my iPad because the security model won’t let apps do anything to shady without you giving it permission.
Same way we draw the lines between risk and reward in everyday life while still managing to function. Doing that with software can be a little less intuitive than stubbing your toe and learning from the pain, but it ends up not being that hard to maintain a low resolution threat model when you prioritize well.
A user with a basic habit wouldn't need to know how to read the code for this, because there are enough signals that you wouldn't need to get that far to decide not to use it.
> but we (meaning computer users) spent decades downloading sketchy executables for our Windows PCs.
This is sadly not a valid comparison. Our PCa have a far more critical role in our lives now, have far more power to hurt us, and are reachable by 1000x more malicious actors.
We are in a new, dangerous world. We need much better OSes with much stronger sandboxing for our modern world.
It's a cool concept in theory -- I'd always thought I'd like using it.
But in practice, I realize I'm addicted to tabs. When working on 3 documents at once, I want them in separate tabs in the same window -- not 3 different windows.
Maybe I'm in the minority, but I'm actually at the point where I want things to go in the opposite direction -- just turn all my apps into tabs. (Like Chromebooks, I guess.)
Finder? VLC? Word? Preview? Spotify? Photoshop? My code editor? I just want them (or each document in them) as tabs next to other webpages and/or each other. (For Photoshop and code, I'll probably organize my own window/space for them, but still open up webpages next to my images/code.)
Having tabs and a dock feels redundant in 2020, like two competing paradigms that just need to be refactored into one by now.
Well, to be more specific -- I want the OS itself to be a full-screen tab container with multiple spaces/desktops (and add tiling, and popping out tabs like floating windows, as advanced usage).
And then each tab is an app or app document window. So I could have a Chrome tab next to a Firefox tab if I wanted. Browser tabs would be peers next to other apps.
None of this is about security, or running apps in the browser. Just using tabs as the main concept for everything, rather than windows.
This bugs me too sometimes. It's incongruous that I can stack Gmail, docs, and my company's ticket system nearly into one tabulated window, but I have to use a completely different interface to access a local file browser, RDP, or the sniping tool.
It's funny, my version would probably just put every browser tab into a different window and just use a powerful window manager like i3 to deal with everything.
I am using i3 but what bugs me is that tabs now seem to be part of the browsers.
There's no elegant way of telling Firefox to never use tabs, always open a new window. There are some extensions pretending to this, but the experience is terrible. There actually is a new tab created which is then detached.
I don't usually use Chrome, so I looked up wether it handled this, but it seems to rely on extensions too.
Qutebrowser works, but it has other limitations, such as poor extension support.
I've had the exact same experience you described. Realizing i3 is the way to go and apps shouldn't manage tabs themselves - trying to stop Firefox / Chrome from doing so - realizing it's not simple and the no tabs extension is problematic. Trying qutebrowser and giving up because it's limited.
I've settled on NoTabs Firefox with a userChrome.css that hides the tab bar until Firefox someday supports native no tabs.
Sounds like Ubuntu's Unity to me. My 2 cents: Now that I'm using two 4K panels I very much enjoy having 4 windows side-by-side (optionally even splitting those vertical "columns" horizontally to hold 2 windows). No more task switching, all I need is always visible - I personally wouldn't opt for a tab-based full-screen WM.
I think this is doable today. Just disable tabs completely on Firefox and chrome, and use a window manager that allows you to group windows into tabs (like i3)
For a while, Windows 10 Insider had a feature called Sets[1], which was exactly what you're describing on a system-wide level; it looked like such a boon to personal productivity.
PWAs are neat, but have no multi-tab feature that I know of. I put in a feature request trying to inspire the Brave dev team to make some really neat PWA stuff. They can literally do anything they want as long as the future spec doesn't conflict. Super jealous of how fun it would be able to reinvent the web with total freedom.
View/modify PWA manifest on web-app/shortcut export
I saw something similar on Hackernews a while back that allowed you to group apps together so you could switching seemingly between workflows. So instead of a dock where you group windows by app, you group them by context.
Now I'm starting to think how feasible it would be to embed other desktop apps that people have installed into an electron window or something.
As a fan of the Google Play desktop app, these Electron wrappers around Google apps are really flaky and hard to maintain. Google is motivated to break these implementations since they live outside of their direct web ecosystem, and when they break it always takes some time to recover since it's open-source. So you end up still using the browser solution.
What's additionally weird is that you can pull your tabs apart into separate windows to replicate this exact behavior. It's hard to justify why I need an exclusive browser just for one app. For Play it's justified because of tighter integrations with the OS playback keys that the browsers historically have been flaky with, especially when you're using other apps.
As it isn't affiliated with Google it shouldn't (and can't) use the name Google like this at all (it could say like "for Google Docs" or something after some clear first party branding).
Another alternative on Windows is to create a separate chrome profile and then create a desktop shortcut to that profile. Set the default page to be your drive in that profile
Here's an example shortcut
"C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 2"
I think you're going to need a unique name for the app. Google and Google Drive are protected trademarks, so they wont let you use those. You're allowed to list the compatibility, but you have to make it crystal clear that this is an unofficial client.
"Backup and Sync" still misses features like Files On-Demand/Smart Sync available in OneDrive/Dropbox and deleting files online pollutes the local trash/recycle bin on macOS/Window computers.
"Drive File Stream" actually has these lazily loaded file placeholders, but it is treated like an additionally mounted volume instead of a local folder somewhere on my local disks. It also managed to occupy over 60 GiB RAM for over a week during its initial sync which had lots of small files created by Arq Backup.
It seems like 'unlimited' cloud storage is foremostly limited by the performance characteristics of their sync clients.
On my laptop (an old Ultrabook), GDrive Sync and Backup will literally take 30+ minutes on "process files" (while using 30% cpu and high disk I/O) every time I reboot.
Also its UI (IIRC written in Python) often fails to load (give you a blank box).
Dropbox still has the best sync tech and is the only one that can handle deep and numerous file hierarchies. The rest have better pricing and integrations like email/productivity apps.
Actually, Resilio is not any slower than Dropbox. Syncthing is also faster thans any commercial offering I ever tried. Even Nextcloud sync is fast after an initial init.
What exactly are you referring to? Upload speed? That's not the issue.
Dropbox is the best at crawling a very complex directory structure with millions of files and diffing it efficiently with the server and other clients, and then transferring all the individual changes. Nothing else comes close. And their write-ups show the work involved:
Yes. I knew you could use git and install modules on each end separately, but putting the whole thing in sync is just more convenient for some personal toy projects.
They've gotten way too enterprise, and I mean that in the worst way possible. Cloud files should always follow the "don't make me think" philosophy and a feature comparison matrix is the polar opposite of that. I guess it's time to look at Dropbox.
I switched to Google Drive a while back because I really wanted better photo storage and Dropbox killed that off a while back, plus the Google One account is pretty nice. But I had no idea that Google would be so horrible at syncing files. It's really amazing how poor it is compared to Dropbox.
Dropbox has spent a decade on solving a single problem and that shows in the product experience, even though it's more costly and has less extra features like email and productivity apps.
Their blog posts explain why they're so much better:
I guess I just don't get how this is different / better than making a desktop chrome shortcut that opens into a new window? It gives the appearance of running as an independent app.
Performance will be similar to using Google Docs on Chrome. Memory usage will be probably worse since you are running another engine besides your browser.
Is it just for the convenience of not having to type the URL on your browser?
I'm guessing it's for people that want the Google products to be their main desktop office suite. Haven't looked into it, but maybe it can open .docx files etc. directly as the default app for it?
What's the difference between using this and clicking on the new "Install" button in the URL bar? I have all of my Google apps available as system apps either using that button or using "More tools -> Create shortcut", which is probably one of the best hidden gems of Chrome (yes, even Gmail can run as a separate app and supports offline mode).
> Want a Microsoft Word-esque experience for your Google Drive? Or simply looking to separate Google Drive from the other bajillion tabs that you opened for your research paper? Look no further!
Well first of all, I'd pretty much rather have a shortcut that can be opened in any browser I'd want to use, than to download another copy of Chrome dedicated to running the Google Drive web app as its own 'app' using Electron.
Secondly, Chrome supports grouped tabs which allows you to organise your tabs anyway which sounds great over having 3 - 4 separate Electron apps trying to behave like MS Office (Just don't).
And last but not least, Unlike MS Office, this requires a persistent internet connection to function. So if your internet is down, your wonderful Google Drive electron app will look like this: [0]
There was something similar for gnu+linux too (nativefier was the name iirc) that worked for a while but then stopped working.
It was very handy.
I kind miss those things because having certain websites in their own apps within their own browser was comfortable.
EDIT: I've tried https://github.com/jiahaog/nativefier and it seems to be working again. Basically you can invoke it and pass it the url of any webapp and it will package an electron-based browser that loads your webapp on startup.
I mean, I can't see this lasting longer than a year until Google decides to break something on their end. And for the love of God, stop using Electron.
Nativier wraps a website with Electron, and in the end it's not a native apps. What I mean is a Google Drive client like Dropbox client in linux where I can sync a directory in my computer, to a directory in my Google Drive.
There are some unofficial Google Drive client in Linux like Grive2 (https://github.com/vitalif/grive2), but like any unofficial apps, they are prone to break when Google update their API.
Nothing against the developer as they may be trustworthy and honest, but don't make the mistake of assuming that someone bold enough to put out something that requires that much trust must by extension be worth trusting. People too often do.