8 ms·
Chrome 78 Beta: a new Houdini API, native file system access and more
- deleted 7y ago[deleted]
- andrewstuart 7y agoMy theory is that many Electron apps don't really need Electron - they just need secure, constrained local file system access. Electron has massive potential security issues. Chrome with native file system access could make it possible for many of those Electron apps to simply be browser apps, making them vastly more secure and bringing them back into the domain of the ordinary web app. It's a hugely important new feature.
- cwyers 7y agoA lot of them just need to be on the taskbar/notification area and not in a browser tab, honestly.
- gregmac 7y agoIf would be interesting if you could allow a site to "open as application" (instead of open in new tab) - or this could even be called "install". The site would then appear in your OS like any other app, and may or may not have some of the browser chrome (URL bar, tabs, navigation buttons) depending on the site. I currently have many pinned tabs - email, music - where I'd happily promote them to "apps". Even some of the real applications I use I only really use to get this behaviour (Slack comes to mind). I'm a way, this is sort of similar to how Chrome OS works - just I want it on a real OS, I'm not at the point of being 100% web (or Electron-based) apps, and as a developer, probably never will be.
- stormbrew 7y agoChrome has/had this. It's called Chrome Apps[1]. But they deprecated them[2] [1] https://developer.chrome.com/apps/about_apps https://developer.chrome.com/apps/about_apps [2] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
- darrinm 7y agoSounds like you’re describing the Progressive Web App (PWA) install that Chrome recently added. Coming to Firefox (if not there already), and Edge. Not holding my breath for Safari though.
- vnorilo 7y agoMobile Safari supports PWAs and quite a bit of infra like service workers. Last time I looked it didn't work well in the background (reloads page on resume) but seems like they have most of the building blocks. EDIT: This post [1] says background switching should be working in iOS 13. [1] https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49 https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwa...
- CopOnTheRun 7y agoYou can do something similar in chromium/chrome by using the `app` flag. I set jupyterlab to launch with chromium --disable-extensions --app=%s which hides the URL bar and tabs, as well as disables any extensions. I'm sure it's possible to create a shortcut on Windows that does the same thing and place it on the desktop or what have you.
- ymolodtsov 7y agoYou literally can do that and not just for PWAs.
- Stratoscope 7y agoYou can do this yourself in Chrome right now! Open the page you want to be an "app", and on the Chrome three-dot menu, select More Tools / Create Shortcut... Edit the name as you wish and check the "Open as window" checkbox, then click OK. Now you have a shortcut on your Start menu that works like any other app shortcut. You can pin it to the taskbar, save it to the desktop, any of the usual things. And when you open the app it will have its own window and its own icon on the taskbar. This works on Windows and Linux at least - have not tried it on macOS.
- mcpherrinm 7y agoI use this on Mac OS too. I use it for Gmail, gcalendar, slack, etc which I always have open on my work macbook.
- The_rationalist 7y agoThis has been done recently. https://youtu.be/EiXtKTjcLRE https://youtu.be/EiXtKTjcLRE
- dddddaviddddd 7y agoOffline mode is important too, but of course you can do this on the web just fine nowadays.
- dswalter 7y agoYour version only works as long as there is only one browser.
- bdcravens 7y agoHow many die-hard Firefoxers run at least one Electron app?
- realusername 7y agoNot sure what's your point but I would prefer my Electron apps to run with Firefox's engine if possible since it's the browser I mainly use, it would use much less memory.
- The_rationalist 7y agoIt would be slower and that's all that matter. Ram is dynamically allocated and chrome has arguably better caching. Ram usage has only one user facing drawback, it's when it affect negatively performance. Chrome then outweight Firefox on your own criterion, by one indirection. Anyway Firefox lack many features useful for "electron apps" and this new file system acesss will add to the list
- realusername 7y ago> It would be slower and that's all that matter. Ram is dynamically allocated and chrome has arguably better caching I don't want to use chrome, so it's never going to be an option. The best option in a ideal world is the browser the user is using since there's not that much resource needed to open one more tab. Some APIs around that would be ideal.
- pedrogpimenta 7y agoWhy? Why couldn't they work the same way in any browser, like websites do?
- rubbingalcohol 7y agoIs the filesystem API based on any web standards process? I'm curious if this is a Google-only feature.
- iso-8859-1 7y agoYes: https://github.com/WICG/native-file-system https://github.com/WICG/native-file-system
- userbinator 7y agohttps://wicg.github.io/native-file-system/ https://wicg.github.io/native-file-system/ Editor: Marijn Kruisselbrink (Google) As you may be painfully aware of by now, "web standards process" means next to nothing if Google gets to decide the standards anyway.
- deleted 7y ago[deleted]
- nindalf 7y agoWhat are you complaining about exactly? That a standard was authored by someone who works on a browser? Would you prefer if standards were worked on by people with no browser development experience? Here's the draft of the accessibility API [1]. The two editors are from Mozilla. Does this mean that the process of defining this API, gathering feedback, iterating and publishing it "means next to nothing" because folks from other organisations didn't chip in? [1] - https://wicg.github.io/historical-a11yapi/taxonomy.html https://wicg.github.io/historical-a11yapi/taxonomy.html
- rubbingalcohol 7y agoGoogle should not be releasing an implementation before the "very early" spec is finalized. They aren't acting in good faith with behavior like that.
- xg15 7y ago
- p7IDD243 7y agoThe Native File System API sounds like an exploit waiting to be discovered.
- iso-8859-1 7y agoI downvoted you because it is a superficial knee-jerk judgement.
- pg_is_a_butt 7y agoi upvoted them to counteract your own superficial knee-jerk judgement and ignorant hypocrisy.
- apatheticonion 7y agoI upvoted you because you explained your downvote
- synt4x1k0 7y agohttps://github.com/WICG/native-file-system/blob/master/EXPLAINER.md#proposed-security-models https://github.com/WICG/native-file-system/blob/master/EXPLA...
- 7y ago
- kaendfinger 7y agoI find it interesting how the solution to the OTP SMS problem is to provide the SMS Receiver API. I think the iOS keyboard OTP suggestion is the right way to do that. An SMS Receiver API, even if secure, just seems like a backwards way to solve this problem.
- pcr910303 7y agoI’m not sure about how to think about the file system API. On one hand, is great to see that secure file system access is possible in-browser, which allows most electron apps be converted into PWAs. That’s great, I no longer need to run 5 different chromium instances. On the other hand, I’m really not sure if I like the future of editing Microsoft office documents in the browser. I heavily believe that apps should have an integrated UX (with appropriate OS-specific widgets), because it allows coherency and familiarity.
- notatoad 7y agoThe "coherence and familiarity" argument for native apps is only half the story though. Cross-platform coherence and familiarity is also important. And as an app developer, when you have to make a decision regarding whether you should be familiar and coherent to the rest of the operating system or the other installs of your app, that's pretty much always going to land on the "my app" side. Especially with Microsoft office, which was completely chock full of custom controls and didn't feel at all like part of the OS last time I used a natively installed version (on windows 7)
- pcr910303 7y ago> The "coherence and familiarity" argument for native apps is only half the story though. The user only uses the application in the platforms that one uses; so cross-platform coherence is mostly meaningless. > And as an app developer, when you have to make a decision regarding whether you should be familiar and coherent to the rest of the operating system or the other installs of your app, that's pretty much always going to land on the "my app" side. They might be beneficial to the developer; but it definitely isn’t to the user, which ultimately uses the app. One might argue that the user will use the app for multiple platforms; However the user will ‘know’ the average user experience for both platforms, hence having no problems adapting two different interfaces if the interface is well designed to match each platform. > Especially with Microsoft office, which was completely chock full of custom controls and didn't feel at all like part of the OS last time I used a natively installed version (on windows 7) I’m pretty sure Microsoft has opened the ribbon controls for this exact argument. At the very least, the Windows 7 file explorer’s toolbar looks very similar to the Office 2007; so Microsoft is trying to make the operating system more coherent. The introduction of the Notification Center in Windows 10 has a similar purpose; to make lots of different notification system in Windows coherent. If you want to look what an operating system looks like when the entire ecosystem considers coherence importantly: try using macOS. macOS users take this very seriously to the point that almost every app (that is not election) uses the default cocoa toolkit. Microsoft office isn’t an exception; they implemented the custom ribbon menu, but other than that it’s mostly plain Cocoa and it doesn’t standout as much as in other platforms.
- robocat 7y agoBrowsers need a bright line between documents (HTML and CSS) and applications (electron-like, notifications, complex APIs, access to features that affect the user's security). Plain HTML documents are SEO friendly, are a11y friendly almost by default, back/forward navigation works, and HTML doesn't chew battery and bandwidth on JavaScript. For our web app the biggest pain points are: security (hard to integrate third party libraries), control over the viewport (an app header and footer that don't get lost when zoomed - like an App), control over data entry (the hacks we have to do for fast reliable time and date entry are rediculous, and other stuff is just too hard), and control over navigation (browser back/forward is broken for applications that POST data). Unfortunately Google don't seem to want to encourage plain HTML documents (instead the insane AMP shit).
- mindcrime 7y agoBrowsers need a bright line between documents (HTML and CSS) and applications (electron-like, notifications, complex APIs, access to features that affect the user's security). Glad that somebody else sees this. This muddling together of a perfectly good hypertext browser and a poor man's operating system is really not a Good Thing. Just think about the difficulty web "applications" have dealing with something like function keys. If I press F5 in my browser, and I asking the browser to reload the page, or telling the page to do something? And how would I know ahead of time if the page has hijacked a given key combo that I intuitively expect the browser to respond to (ctrl+w maybe). Whether we separate out the application runtime from the browser altogether and have a handoff mechanism, or add some way for a page to request something like an "application mode" to the browser, it really feels like we need a way to make this "page" vs "application" distinction. And yes, of course, the line appears a bit fuzzy. I'm not saying figuring out an answer to this is easy, but I hope there are people out there thinking about it.
- TeMPOraL 7y ago> And how would I know ahead of time if the page has hijacked a given key combo that I intuitively expect the browser to respond to (ctrl+w maybe). Or like GMail does with CTRL+. - it doesn't even use it for anything, but it still eats the key sequence, preventing me from interacting with Multi-Account Containers on Firefox. I think I might have even seen sites breaking CTRL+TAB or CTRL+SHIFT+TAB, but can't find an example now.
- nitwit005 7y agoThe linked article about defining typed CSS properties using a mix of script and style tags seems perplexity complicated to me: https://web.dev/css-props-and-vals/ https://web.dev/css-props-and-vals/ Was this intended to be tied to some other feature or framework not mentioned?
- ylum 7y agoRest in peace XSS Auditor
- rhacker 7y agoFor those that are interested in the security around file system access please go here: https://developers.google.com/web/updates/2019/08/native-file-system#security-considerations https://developers.google.com/web/updates/2019/08/native-fil... If you look at the various restrictions, you will see that the user is in control of most of the operations. It restricts access to system folders. I do think that many lay people may still fall prey to attack vector sites that may save an evil EXE or something, hoping they will later click it. However, I suspect once we see this feature in action, hopefully it will disallow creating executable files.
- zaphirplane 7y agoI read the link you referenced. Am not clear on how seeming it action will mitigate the vector. Saving msi inf sys com files tick, save in locations people have open in explorer/finder tick. The mitigations appear around overriding Files in user and system directories and revoking access.
- tinus_hn 7y agoIt’s not really possible to know which are executable files. The solution is to add the attribute that says the file was downloaded so it doesn’t run automatically.
- jukik 7y agoThats make chrome more comfortable
- mika9090 7y agoSerious question: is there a salvation for native desktop development??
- The_rationalist 7y agoWell electron already allow you to use arbitrary language and acesss almost any native OS api. So electron is the salvation for hybrid_native desktop development. Your question would better be: Is there a salvation for native and cross platform GUI frameworks other than chromium ? The answer is probably no as chromium beat everything both feature wise, library wise and (yes) performance wise. Really why native development isn't totally dead yet is because of inertia to learn new technologies and because of shared misconceptions about chromium performance and GUIs framework performance. This growing gap could have been deduced so many years ago because of a simple fact: The number of full time employees working at improving chromium vs the number of full time employees working at improving QT, or GTK, etc. They are order of magnitudes more. And it has deeply increased since microsoft has joined chromium (they have moved a number of employee to chromium probably comparable as if all Gtk + QT devs moved to working on chromium. Btw, as they both know they can't keep up, they progressively webify (QTwebengine, both use CSS for styling, etc)
- xg15 7y agoWe're uneasy enough with Google effectively turning the WWW into a platform under their control with them running Search, Chrome and Android - but this sounds as if the platform might actually extend to "any application with a GUI". (With Apple being the one competitor) I can't see how this is good.
- armitron 7y agoI can’t take this answer seriously. Assuming half of what you claim were true, it would still be terrible for us to cede control of the future to Google. Of course the grim reality is that none of your claims are even remotely true. This is a classic case of worse is better amplified by Google being in a position of unprecedented power and abusing it to full effect. Those of us who were old before Google even existed, can see very clearly where this road is leading. On the other hand this is a battle that has to be fought mainly by the younger generation. Alas, it does not seem that we are winning.
- jitendrac 7y agoNative file system access, That is what I wanted and waited the most for. Now It is possible to create an App alike webapp which needs just one prerequisite of selecting a folder on the start.