Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 78 Beta: a new Houdini API, native file system access and more

blog.chromium.org

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#31

Post by gravypod »

ori_b wrote: post #29
gravypod wrote: post #28

Earlier quoted context omitted.

The MITM happens at an application level. Not from your backend. A client chooses who to get the AMP content from: Google or You. Users who don't want Google's edge caching (MITM) can use software that doesn't talk to Google servers and still benefit from the plane HTML.

Which software would that be?

Any software that provides you a link to content can implement, and also choose not to implement, AMP's edge caching (MITM) support. One might be Google's Android launcher's news app, another might be Telegram's "Instant View" feature for links, or hypothetically even a terminal app could load an AMP page.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#32

Post by paulddraper »

gravypod wrote: post #28
paulddraper wrote: post #27

Earlier quoted context omitted.

5. It's MITM'd by Google's servers. --- I don't know if you are being accidentally or purposefully misleading. No one has a problem with simple HTML. That's never the dispute. People have a problem with Google servers seizing control of the client server relationship.

The MITM happens at an application level. Not from your backend. A client chooses who to get the AMP content from: Google or You. Users who don't want Google's edge caching (MITM) can use software that doesn't talk to Google servers and still benefit from the plane HTML.

Instead of speaking in vague terms about "optional application-level MITM from the backend cache", it might help to illustrate the choice users have with concrete examples.

With real world examples, how can an ordinary choose to use AMP and how can an ordinary user choose not to.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#33

Post by gravypod »

paulddraper wrote: post #32
gravypod wrote: post #28

Earlier quoted context omitted.

The MITM happens at an application level. Not from your backend. A client chooses who to get the AMP content from: Google or You. Users who don't want Google's edge caching (MITM) can use software that doesn't talk to Google servers and still benefit from the plane HTML.

Instead of speaking in vague terms about "optional application-level MITM from the backend cache", it might help to illustrate the choice users have with concrete examples. With real world examples, how can an ordinary choose to use AMP and how can an ordinary user choose not to.

> Instead of speaking in vague terms about "application-level MITM from Google's back end"

I don't consider actual, verifiable, facts vague.

> In real world terms, how can they choose to use AMP and how can they choose not to.

They can use software that doesn't load AMP pages from Google and instead loads them from the host site. You can do this by using DuckDuckGo as a search engine which won't return URLs to Google's cache of AMP content. You can use messaging apps that will open your web browser and navigate to links rather than using the AMP version.

Edit: Here is an example. Assuming you are on a desktop browser you should be able to navigate to this url and see a page: https://preview.amp.dev/documentation/examples/e-commerce/ch...

This is a Google made example of an AMP page. It's pretty bare bones but as you can see if you open up your browser's networking tab the browser is talking to `preview.amp.dev` not to the AMP caching URLs. Your browser is fetching content directly from the site. There is nothing stopping software from doing this with an AMP page.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#34

Post by userbinator »

iso-8859-1 wrote: post #7
rubbingalcohol wrote: post #5

Is the filesystem API based on any web standards process? I'm curious if this is a Google-only feature.

Yes: https://github.com/WICG/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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#35

Post by paulddraper »

gravypod wrote: post #33
paulddraper wrote: post #32

Earlier quoted context omitted.

Instead of speaking in vague terms about "optional application-level MITM from the backend cache", it might help to illustrate the choice users have with concrete examples. With real world examples, how can an ordinary choose to use AMP and how can an ordinary user choose not to.

> Instead of speaking in vague terms about "application-level MITM from Google's back end" I don't consider actual, verifiable, facts vague. > In real world terms, how can they choose to use AMP and how can they choose not to. They can use software that doesn't load AMP pages from Google and instead loads them from the host site. You can do this by using DuckDuckGo as a search engine which won't return URLs to Google…

I meant to say "abstract" not "vague".

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#36

Post by bdcravens »

dswalter wrote: post #14
andrewstuart wrote: post #3

My 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 fe…

Your version only works as long as there is only one browser.

How many die-hard Firefoxers run at least one Electron app?

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#37

Post by laughinghan »

pcr910303 wrote: post #24
notatoad wrote: post #17

Earlier quoted context omitted.

The "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 o…

> 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 g…

The user only uses the application in the platforms that one uses

Most people only use one desktop and one mobile OS, but it's extremely common to use the same app on both desktop and mobile.

If your Mac and Windows apps both have to be consistent with your iOS app, they end up having to be consistent with each other.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#38

Post by [deleted] »

userbinator wrote: post #34
iso-8859-1 wrote: post #7

Earlier quoted context omitted.

Yes: https://github.com/WICG/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]

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#39

Post by CopOnTheRun »

gregmac wrote: post #21
cwyers wrote: post #4

Earlier quoted context omitted.

A lot of them just need to be on the taskbar/notification area and not in a browser tab, honestly.

If 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…

You 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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#40

Post by rhacker »

For those that are interested in the security around file system access please go here:

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.

Post reply on HN