Security Through Transparency
dApps on IPFS
Anybody who watches The Lock Picking Lawyer knows that traditional security is provided mostly through obscurity, as he demonstrates with nearly every video that this kind of "security" is no security at all.
I've just put the last checks together that I believe makes the dlux dApp distribution scheme as secure as any traditional website. Let's talk about how this works, pose a challenge, and invite some commentary.
Arbitrary Code Execution
The real name of the game is executing arbitrary code in a certain context. Traditional websites have had this exploit thru all sorts of means and if you decide to build a dApp on DLUX you'll have the same expectations of knowledge as any normal website developer. Things that we can't control are obviously out of bounds, such as setting up a phishing website and getting a user to click a link in an email. However, the way dlux dApps are set up it was possible to to send somebody a link, get them to load a page inside of the same sandbox as usual... which would mean exposing that dApps data through cookies, localStorage, and even sessionStorage in some cases. Depending on the nature of the dApp this could mean leaking valuable information.
DLUX dApp Paradigm
In a few words DLUX dApps should be roughly identical to setting up your own static website, on your own server, with your own SSL certificates. There are numerous ways to accomplish the same thing on today's internet such as github pages. The major differences here are instead of free hosting, Hive has content rewards. Posting an app on github pages like The SPK Network Monitor won't earn you any cryptocurrency and has the possibility of being censored or deleted by Github.
DLUX | Language classes for Ukrainian refugees in VR is a very simple dApp that just displays some 360 images. If I wanted to censor this dApp I could, but the goal of decentralization is to have multiple people run multiple frontends, or even have a local application that can deliver this content no matter the whims of certain individuals.
I hope this paradigm meets or exceeds any other UX for both the developer and the user in terms of speed, trust, security, and usability.
Breaking Down DLUX Security
Using the above dApp; looking at the domain you will find bezkresu.ipfs.dlux.io. It's set up in such a way that only 
Clicking on this app from dlux.io will generate this link:
https://www.dlux.io/dlux/@bezkresu/language-classes-for-ukrainian-refugees-vr
Links to dlux.io
This link will likely benefit from a HEAD request to enable link previews. GET requests will have dlux.io will serve this static file with the following interesting code.
const author = window.location.pathname.split('/')[2].replace('@', '')
const permlink = window.location.pathname.split('/')[3]
fetch("https://api.hive.blog")
.then((r) => r.json())
.then(res => {
stateObj = res.result
metadata = stateObj.json_metadata
hashy = JSON.parse(metadata).vrHash,
vars = `?${location.href.split('?')[1]}` || `?`
//...
function match (s,t) {var a=[];for(var i=0;i<s.length;i++){j=s.indexOf(t,i);if(j>=0){a.push(j);i=j}else return a}}
subauthor = match(author,'.').length ? match(author,'.').join('') + author.replace('.', '-') : author
ipfsdomain = `https://${subauthor}.ipfs.dlux.io`;
location.href = ipfsdomain + `${vars}&hash=${hashy}&author=${author}&permlink=${permlink}&user=${user}`
It forwards the request to an IPFS enabled subdomain. Probably the hardest thing to understand here is Hive Accounts can have a . in them which would make this subdomain 2 or more subdomains. If 
Managing an iFrame
Our IPFS server only has one file to serve. This file checks some signatures indirectly and puts the dApp in an iFrame. Let's see how this works.
dns01 = window.location.hostname.split('.')[0]
dots = match(author,'.')
authorizedDNS01 = dots.length ? dots.join('') + author.replaceAll('.', '-') : author
if(dns01 != authorizedDNS01){
goAhead = false
alert(`This dApp failed it's signature check.\nYou are likely following a malicious link:\nAuthor: ${dns01}
!= subdomain: ${authorizedDNS01}\n Please report')
}
The match function is the same as above. It does it's own check to see if it's on an authorized subdomain before asking a Hive API for the post content. The user following a link to an unqualified domain will get a warning message and no iFrame will be set up.
Caddy Configuration
Finally, to serve anything out of our IPFS's subdomain gateway we've configured Caddy as follows.
*.ipfs.dlux.io {
root * /var/www/html/ipfs
file_server
@ipfs {
header Referer https://{labels.3}.ipfs.dlux.io*
}
handle @ipfs {
reverse_proxy /ipfs/* localhost:8080
}
tls {
dns cloudflare {api-key}
}
}
*.ipfs.dlux.io handles our wildcard subdomain.
file_server serves our one and only file that checks subdomains, and set's up the iFrame sandbox
@ipfs defines a rule where the referer matches the current subdomain
handle @ipfs forwards ipfs/CIDs to the IPFS instance to load out the dApp.
tls give Caddy the information it needs to keep our SSL certs up to date.
Capture the Flag
I've put a 'secret' in my localStorage.
It's sha256 hash is as follows: 16f20aed9b0f3a773f890c54936ed60df1c9d225723e2b9b7c89f30cd1bb3146
I'll click on any link posted below. If you can get my secret from my localStorage I'd love to know how. So much in fact that I'll offer a 50,000 DLUX bounty (or 500 Hive).
If you can think of improvements, I want to know. If you have questions, ask them.
I hope that our sandbox is just as secure as any other website. That phishing out of a non-managed url is the best an attacker can do... and the sandbox only executes code that the author wrote.
As always, a vote for my witness or approval of proposal 234 helps me out.