Proposal: Reverse iframe #2169
Comments
|
@HelloZeroNet @geekless @rllola @datsec @ValdikSS @filips123 @AnthyG @anoadragon453 @github-zeronet Waiting for review! |
|
I've first predicted compatiblity issues, but, surprisingly, latest Firefox and Chrome in both Incognito and classic mode work well. |
|
I've found a minor issue with |
|
Nice presentation. Very hard to get your head around without something to kick the tires on. Hopefully it won't take much effort to get make the concept testable enough to validate it doesn't break apps or core ZN functionality like the side bar. Does this impact the URL at all? Currently, the Angular app needs to set the base href so references work. Otherwise, they try to access content from the root. e.g., "/site.css". In reality, it needs to do some parsing of the URL so you don't have to hard code the site address. There is a current issue right now with .bit domains that I haven't tested with an app because I don't have a .bit domain. I just know it is an issue today with relative referencing. It's not clear if this prefix concept in the DOM can have an impact today. One thing that makes this challenging to predict up-front is you can't realistically know what all the third party libraries are doing in a Node-based app until you see an error. You have the core ones used to build a basic Angular, React or Vue app, then you have a bunch more you add for app functionality (such as charting). Later, we upgrade these, hoping they don't break. What's the minimal you can do (time wise) to be able to have a branch where we can test the highest risk portions of the design, such as the new PREFIX (shadow DOM)? It doesn't have to do everything or provide new functionality. And, for testing, can still rely on NOSANDBOX, so long as it provides a way to test new scenarios. Just need to see validate it doesn't breaks apps. |
If you're asking for a high-risk PoC (meaning unsafe, i.e. can be abused by sites), it'll probably be finished today (it's 9am for me). By now, ZeroTalk, static sites, ZeroSites and ZeroHello all mostly work (except localStorage stuff and such). |
|
Ok, so, are there any sites using |
|
@imachug That commands should probably be available, but marked as deprecated and removed on next major version. Also, how would you prevent CORS? Because all sites would be on same origin, any site would be able to access all data from other sites even without permission. I think that this would be good improvement. This would also allow Progressive Web Apps with Web Manifests and Service Workers available. Can you share your unsafe PoC when it is available? I would like to test it. |
Sure, but
We'd compare
Sure, ping me tomorrow if I forget to send you a link. |
|
I'm currently a bit stuck with site-in-site (aka picture-in-picture) mode implementation. Good old 3 years old StackOverflow thread without an answer. Please tell me if you know how to fix that issue. |
|
Unfortunately I couldn't find a way to fix that issue, so I'm switching to another architecture: Basically, we're getting rid of iframe gate and using wrapper key instead. This architecture is still secure, but is more error-prone, so I should be careful enough. |
|
What is different between site and wrapper notifications? Could both of them use DIV or IFRAME or even be in same element? |
|
Site notifications are possibly insecure and don't store sensitive information; wrapper notifications are always secure and may store sensitive information. For example, It's unsafe to use |
|
@filips123 Forgot to ping you |
|
I've noticed that a lot of wrapper code uses jQuery. We probably don't want to pollute sites' environment, so I'm trying to port as much code as possible to Vanilla JS. |
|
Making sidebar work turned out to be a bit more difficult than expected, so you'll have to wait a bit. |
|
Looking good, but the history access could be problematic and probably there is multiple ways to recover the original function, eg. using an iframe: history.pushState = console.log
ƒ log() { [native code] }
$("<iframe id='itemp'>hello</iframe>").appendTo(document.body)[0].contentWindow.history.pushState
ƒ pushState() { [native code] } |
|
Sure; but what would you do after getting |
|
@imachug Maybe changing URL to address of another ZeroNet site. All sites would be on the same origin but I don't know if HTTP CORS headers actually prevent this. |
|
@filips123 Eh, that's why we're replacing |
|
@imachug Ok, this makes sense. And you probably can't open Also, would it be possible to differentiate between legitimate and malicious iframes? Because site can use iframe to just display other content on it (embedded game, sidebar... hosted on it) or to attack different site. |
Well, it's possible (site-in-site case), but it's restricted, so you can't call
It's impossible to attack a site with an iframe because there's a sandbox. The only way of communication is |
You are right, but it works this way: > history.replaceState = "nope"
> history.replaceState = $("<iframe id='itemp'>hello</iframe>").appendTo(document.body)[0].contentWindow.history.replaceState
> history.replaceState("", "", "/AnyUrl")
> window.location.href
"http://127.0.0.1:43110/AnyUrl" |
|
What browser are you using? That sounds like a major issue |
|
Chrome, but just tested and also works in FF |
|
Do you have any ideas how to solve this? Switching to |
|
Not really, maybe we could setup a setInterval that monitors the window.top.location, but it's pretty hackish |
|
@HelloZeroNet What if the site would somehow delete/replace |
|
@filips123 The prefix code is run before site code, so we can save setInterval beforehand. |
Not noise at all. I love diverse perspectives in a complex conversation. Your understanding of DNS is good, and that does count. |
|
So we're going to use an extension/PAC. Ok. That will probably work and won't be difficult to implement. |
Proxy owner should specify which part is real clear net domain. Or alternatively (preferely) program should detect this automatically. |
|
@KilowattJunkie Regarding custom URL schemes: How would browser know to send HTTP request to |
|
I like to look at what can be done before discussing what should be done. we didn't get far enough to talk about all the incredible things that can be done with a ZN DNS: site configuration, domain issuance, DNS like functionality like CNAME and MX if we can ever introduce ZN SMTP, etc,... @imachug did a great job at looking at possibilities! We may put ZN DNS on a side burner for now, but I'll be thinking about all the incredible possibilities in the meantime thanks to imachug's imagination. As for relays, I think ultimately we can package nginx or httpd in a Docker with ZN to make deployment very easy, providing any out-of-the-box reverse proxy and URL rewriting config needed. This also allows it to be deployed on more platforms. |
|
At the end of the day, we need 1000 developers! lol |
|
@github-zeronet I partially agree with you. However, PAC file is something that should nort be so hard, as there are only few issues with it (actually some of them are a bit harder to do). This would also enable easier integrations with other incredible things in the future. But I don't think ZN specific DNS would be useful. It would be better to just integrate it with other existing DNS projects (#2049). Also, requiring user to use Docker isn't good. Docker could be hard to install, specially on Windows, where, if you don't have Pro versions, you have to install both VirtualBox and Docker Toolbox. |
|
I don't have any particular comments to make other than: ideally the resolution to the problem should get everyone on the same page, and allow for "clean" urls (no 127.0.0.1:port business in the nav bar). As it stands I and others use a .pac file to redirect http://zero/address/, http://domainname.bit/, and http://name.zeroid/ addresses to their proper counterparts. I've attached the .pac file I use below (renamed to add a .txt extension to allow upload). something like: http://address.zeronet/ would work fine IMO, and if it works for direct addresses (not just domains) as well then that'd solve a lot of the linking problems. But if there's an extra step in setup, I'm not sure everyone would do it? That seems to be the problem right now. IE advanced users have no problem setting up the .pac and whatever else to allow links to work, but I always have to be careful to change it back to the native solution to ensure everyone can use the link. Any "optional" steps would still have that problem. |
|
So looks like we have two equivalent solutions here: ProxyIt looks like a special DNSWe'd set They are basically the same with the feature set we currently have. There might be some good usecases for DNS in the future, but I don't see any features now, @github-zeronet:
How exactly would we utilize DNS? AFAIK the same is possible with proxy.
Domain resolving is done by ZeroNet in both cases, so it's not a difference.
...but why?
This is possible without DNS, see ZeroMailProxy. If the solutions are about the same, I'd use proxy: it looks like it's easier to install and can be easily set per-browser (instead of at OS level). |
|
@imachug Other possibly may be browser extension. It isn't so powerful, but it may be easier for users to use. I'd first support PAC file and proxy which are most easiest way to implement (and both of them are related to each other). But later, we should also implement other ways to do this, such as DNS, extensions and system programs. Of that possiblities, extension should probably be implement first. |
|
Actually there is already a browser extension, but it's also using the pac file, so there is no difference: |
|
@HelloZeroNet With last update 3 years ago and old available for Chrome. Not good solution because of that, but something like this should be made to be official. There should be extension like this, but for more browser, regularly updated with latest specs and official. I will try to make and release PoC of this but I need to wait until we standardize hostname (or other) solution. Here I would still like something like |
This was just to make installing relays easier. Not for normal users. Not a requirement for anyone. Who in their right mind would run a Relay on Windows, anyway? lol |
That was all potential future state if we had ZN DNS. Not needed at all for our current feature. If I understand ZeroMailProxy, its purpose is to allow a client, such as Thunderbird, to send/receive email for you through the equiv of the ZeroMail site via SMTP/POP3 protocols. Correct? ZeroMail is a nice temporary way to solve a problem. It has limitations preventing it from being a long-term solution in its current state. I'm thinking more from a blank slate how to send email in a decentralized way with ZeroNet as the backbone. OFFTOPIC: POSSIBLE FUTURE ZERONET DNS/SMTP So, let's say I own the "safemail.yu" ZN domain. I'd want a way that people could send email to its users, like "[email protected]". But, the sender should not have to have a user account on that domain. So, I'd provide an ZN SMTP server at a site address they could use to route email to those users. The DNS record would provide an MX record pointing to that site. I'm basically pondering how this could be done on ZN, w/o clearnet. Any domain owner would have the ability to setup an email server (special type of site) that its users could receive email to (with its own storage and other rules). Anyone would be able to send email to these users, even if they did not create a user at that domain. There's a lot more going on in my head, such as offline mesh networks with intermittent connectivity to the Internet, apps to people, apps to apps, people to apps communications in addition to people to people, decentralized autonomous message storage (in this case, the owner of a SMTP relay would control storage, forwarding and other policies for their domain, and not rely on limitations of ZeroMail.) |
|
@HelloZeroNet I have managed to make a browser extension to access ZeroNet via e.g. |
|
Is redirecting /zero/1anysite -> 0anysite.zeronet and talk.zeronetwork.bit -> talk.zeronetwork.bit.zeronet not possible with the extension or what the reason of the incompatibility? |
|
It is possible but I think both |
|
Another possibility could be to use Using |
|
The .zeronet postfix looks good for me, I just wondering what the reason of the incompatibility. |
|
I could support |
|
I don't see a reason why you should support them. Even if we get rid f them later, we can also get rid of them now. Users would have to change anyway. |
|
The problem is backward compatibility (oh well). Even if we get ZeroHello, ZeroTalk and such working correctly, it might be a pain to make other sites apply fixes. |
|
Existing sites will automatically convert http://127.0.0.1:43110/1anysite to http://zero/1anysite, so if you don't redirect it in the plugin, then you will break links on all exsting site. |
|
I can support |
|
I meant not internal proxy redirect, but actual http location: header redirect. So you would have to redirect once and not for every request. |
Oh, that makes sense. I'll implement that soon (around tomorrow).
Great! |
|
Let me also add some noise :) |
|
Ideally, both Just note that it should be possible to access sites from port 80 and 443, and not 43110. Using 43110 as port number was probably meant to separate ZeroNet UI and prevent conflicts with other servers that may run on port 80. But as hostnames will be now separated, it should be possible to access sites as normal clearnet sites, from port 80 and 443 (and other ports for other services). This would also enable adding CNAME/A/AAAA and TXT record And instead of Then, browser plugin or local program would set |
|
To bind on ports below 1024 admin/root rights are needed and on Android it's not even possible. |
Abstract
Currently ZeroNet uses a wrapper for sidebar and notifications UI, and embeds site content with an iframe. This proposal fixes some issues caused by iframing by embedding ZeroNet UI into site content.
Rationale
Overview
Current architecture:
Safety layers are separated with double border.
No software has zero bugs. This includes security issues. There are many possible attack points here:
Proposed architecture;
Sure, it might look more difficult at the first glance, but security comes with a cost.
Resulting HTML
The resulting HTML (the one that browser receives) consists of a prefix and the real site
.htmlfile.Prefix
Prefix is a "magic" HTML code that sets up an analogue of what was a wrapper by creating a shadow DOM node. This ensures that the sidebar and notifications are shown correctly, independent of main site styles, and that it doesn't affect the site itself.
Gate
A gate is an iframe that acts like a gate between UiWebsocket and its user. The gate handler uses the referrer to check what permissions the websocket must have.
Fixed issues / added features
Implementation status
ETA: at most 1 week if no major issues are found
The text was updated successfully, but these errors were encountered: