dr|z3d
yeah, zzz, this was what I was referring to: iFrameResize({ log: false, heightCalculationMethod: 'lowestElement' }, frame)
dr|z3d
better to use a tagged element instead, less of a performance hit.
dr|z3d
(you really do not want to be iterating over every element on the page if you can avoid it)
dr|z3d
not_bob_afk: you plank!
dr|z3d
publishing news from 10 years into the future...
not_bob
Hahahahahah, fixed.
not_bob
I didn't even notice.
not_bob
Anyay, better now.
not_bob
I bet that made it float to the top of planeta ;)
not_bob
Anwyay, back to AFK for me!
dr|z3d
planktastic!
Titlacahuan
planet.i2p -> planeta.i2p? interesting
not_bob_afk
planeta.i2p is better than planet.i2p
Titlacahuan
looks better that's for sure. I like that there's some world news as well
dr|z3d
all hosted on the network.
dr|z3d
at least it was last time I looked.
zzz
dr|z3d, no
zzz
- if we didn't write the html, we don't know what the bottom element is
zzz
- html emails aren't huge, it doesn't matter
zzz
- I tested hundreds and hundreds of emails, this flavor is the only one that works on all, which is what the js docs say too
dr|z3d
zzz: yes.
dr|z3d
no, it mentions two specific options, not one.
dr|z3d
the taggedElement is faster because you're not iterating over the page to find the last element, you're injecting a hidden tagged element at the bottom of the page. faster. just as reliable.
zzz
can't guarantee injected one is at the bottom due to positioning of other elements. we didn't write the html
dr|z3d
of course you can. you just inject it before </body>. if the html doesn't have that, it's fail.
zzz
no because absolute positioning of some other element. it's not necessarily positioned at the bottom just because it's last
zzz
docs say this version is guaranteed to work, and it does, and the speed is fast enough
zzz
other flavors did not work 100%
dr|z3d
I don't think absolute positioning has anything to do with it. taggedEement relies on the last element on the page in the html, not the viewport.
zzz
no it's not. see docs
zzz
you're tagging the element that you promise is the bottom one
zzz
which only works if we wrote the html
dr|z3d
no, you're not tagging an existing element in the html, you'd adding one just before body close.
zzz
i understand. that one still may not be the lowest position
zzz
you're coming at me with theory but I have test results
dr|z3d
viewport position has nothing to do with it. and if it did, which I'm pretty sure it doesn't, you'd just add a css rule at put it at the bottom.
dr|z3d
haha, theory. ok.
zzz
your theory is it's unacceptbly slow, and some other way, that's harder to code, might work just as well but be faster
dr|z3d
my theory is that it's slower, not that it's unacceptably slow, just wasted cpu cycles, but if it's more or less instant, then nothing doing. as you were :)
zzz
the last element in _their_ html isn't always lowest, I found that in testing, so if we add a tagged one after that, it's not necessarily lowest either.
zzz
that's why last element flavor isn't guaranteed, only the iterate thru everything flavor is guaranteed
dr|z3d
you guarantee being the last element by inserting a span, for example, immediately prior to the blody close tag. that way you're *guaranteed* to be the lowest, unless their html is completely fubar.
dr|z3d
*body
zzz
there's a lot of fubar html email out there unfortunately
dr|z3d
haha, ok. :)
zzz
we have plenty of other js that iterate thru the dom, e.g. getElementsByClass("foo") - it's not ideal but it's not a calamity
zzz
the docs say this is the only one guaranteed to work if you don't control the html, and I confirmed that with lots and lots of testing
dr|z3d
yeah, except we do control the html, don't we?
dr|z3d
I mean, the html is downloaded and stored locally.
zzz
we didn't write it so we don't know where the bottom element is. we can modify or inject it but we still don't know
zzz
happy merging
dr|z3d
when I get around to merging your code, I'll let you know. :)
dr|z3d
most of your recent stuff has been merged and is available in dev builds on skank, just not the drag and drop or the html e-mail.
tennis2
After you have finished sanitizing HTML email, I will be a total prick and ask you to sanitize SVG so we can have SVG in TorBrowser Safest Mode :P
tennis2
Is JS allowed in HTML email? I had no idea?
zzz
talk to torbrowser
zzz
we don't allow any js in html email except for what we're injecting to make the iframe the right size
dr|z3d
yeah, that's definitely a torbrowser issue.
dr|z3d
good. what about other offsite resources, how are they handled? downloaded via proxy and cached locally?
zzz
no it's all locked down by CSP
dr|z3d
so no external images or anything else?
zzz
no
dr|z3d
what about external css files?
zzz
y'all had 3 weeks to review/comment on the MR )))
tennis2
"talk to torbrowser" they don't talk anymore, they are above the plebs it seems. I was just joking carry on and be brilliant as you are.
zzz
no
zzz
but we do load embedded/attached images (that's the cid: stuff)
zzz
but look at the iframe CSP and you tell me if I missed anything
tennis2
"we don't allow any js in html" Perfection. Maybe we will point your efforts out to the tor devs, and see if they finally will fix SVG. AFAIK they block svg because they *may* contain JS. If you have done the work to sanitize that, I'll see if they will be interested. Carry on, thanks.
zzz
telling tor to do something like i2p does is guaranteed to fail, don't even try
tennis2
"don't even try" :( Yeah, I know this feeling. I'll be polite and upbeat. You never know... :/
Titlacahuan
tennis2, try to see it from their perspective - writing SVG parsing code in C++/Rust in order to find html and then sanitizing code isn't nothing
Titlacahuan
maybe the sanitization can be reused or is easy to do
dr|z3d
actually, sanitizing svgs at a basic level is fairly straightforward.
Titlacahuan
also there is a very strong excuse that maximum safety mode is expected to not work at times, and missing images are not such a big deal in their minds
dr|z3d
the only thing you're really worried about is embedded scripts.
Titlacahuan
I don't know enough about the SVG format, I guess it's the part of the logic that finds the actual html inside the rest of the svg binary
dr|z3d
and you don't need to write a parser, it's straightforward text/xml, you just grep for the script tag and remove.
dr|z3d
if you want to sanitize further, you'd just remove any x-links/hrefs to external content. not difficult.
dr|z3d
zzz: maybe a toggle button to load external content, with a toggleable invertory of external files.
dr|z3d
*inventory
zzz
button maybe, reload with different CSP, but we're not parsing the html, we don't have an inventory
dr|z3d
/ Function to list blocked resources
dr|z3d
function listBlockedResources() {
dr|z3d
const blockedResources = [];
dr|z3d
// Get all resource elements on the page
dr|z3d
const resourceElements = document.querySelectorAll('img[src], script[src], style[href], link[rel="stylesheet"][href]');
dr|z3d
// Check if each resource is blocked by CSP
dr|z3d
resourceElements.forEach((element) => {
dr|z3d
const url = element.getAttribute('src') || element.getAttribute('href');
dr|z3d
const isBlocked = !window.fetch(url, {
dr|z3d
method: 'HEAD'
dr|z3d
}).then((response) => {
dr|z3d
return response.ok;
dr|z3d
}).catch(() => {
dr|z3d
return true;
dr|z3d
});
dr|z3d
if (isBlocked) {
dr|z3d
blockedResources.push(url);
dr|z3d
}
dr|z3d
});
dr|z3d
return blockedResources;
dr|z3d
}
dr|z3d
/ Display blocked resources on the console
dr|z3d
const blockedResources = listBlockedResources();
dr|z3d
console.log('Blocked Resources:');
dr|z3d
blockedResources.forEach((resource) => {
dr|z3d
console.log(resource);
dr|z3d
});
zzz
fancy
dr|z3d
:)
tennis2
Exactly dr|z3d, xml parsers must exist in any lang I'm sure and then just yank out anything that isn't g, path, circle, rect and whatever other basic stuff you want to allow. Part of me thinks that they are paranoid about some kind of rendering exploit in graphics cards or something. I just am unable to fathom how the issue was not solved ten years ago. Part of me gets conspiratorial here and thinks that tor
tennis2
devs are compromised, they don't want Tor to be used in safest mode. *wink
zzz
but this cascade of suggestions after the review is over but before you've tested it is just weird. please try it ))
dr|z3d
been a bit distracted lately, my bad.
zzz
i get it, me too
zzz
happy to hear critiques but pls give it a whirl first, thats why I pushed it from my hard drive to yours :)
dr|z3d
sure, I'll get back to you when I've taken it out for a date :)
dr|z3d
are we far off the server-side keepalive stuff?
zzz
what did I say, a week after the client side was merged? you can start your clock now
zzz
but that's just to put the MR up, can't tell you what the review time might be
zzz
it's also important to let the client side soak and identify any issues before adding in the complication of the other side
dr|z3d
ok, thanks. anything amiss turns up, I'll let you know, as always.
dr|z3d
tennis2: Iconspiracies aside, I don't think you can blame tor, it's a noscript feature I think.
tennis2
no no, tor safest blocks svg, no script may do it too but tor does it. When tor devs were on trac I went on there to inform them that svg embedded in CSS was working and they blocked it pretty quick. The funny thing is one person complained when I reported that and said I was making tor less user friendly and no one batted an eyelid.
tennis2
s/no script/NoScript/
tennis2
I would argue that it was at that point when someone with any sense would have come forward and asserted that and SVG whitelist ought to be developed. I may have done that too actually.
tennis2
Since tor moved off trac, they well... yeah
tennis2
Have been more difficult to liaise with
zzz
need to finish up my next tor blog post, maybe this week
dr|z3d
if you haven't already watched the state of the union video, I'd mostly not bother.
dr|z3d
maybe nickm's talk about arti is worth looking at, the rest is guff.
zzz
the puff is the most important part, seeing how they puff
dr|z3d
I'm easily bored :)
zzz
or guff
zzz
I'm deep in dnscrypt atm.
zzz
at the point where it doesn't work and no idea why
zzz
need to find test vectors
dr|z3d
have you got a java dns server listening on 53 you can test with?
zzz
and/or server side code with lots of logging
zzz
dnscrypt is not on 53 and there is no java impl
dr|z3d
I don't know where/how you're testing, this may/may not be helpful;
dr|z3d
#!/bin/bash
dr|z3d
# Define the DNSCrypt server addresses to test
dr|z3d
servers=("sdns://server_address1" "sdns://server_address2")
dr|z3d
# Define the DNS record to query
dr|z3d
dns_record="A google.com"
dr|z3d
# Loop through each DNSCrypt server address
dr|z3d
for server in "${servers[@]}"
dr|z3d
do
dr|z3d
echo "Testing DNSCrypt server: $server"
dr|z3d
# Query the DNS record using the DNSCrypt server
dr|z3d
result=$(dig @localhost -p 53 +tcp +short $server $dns_record)
dr|z3d
# Check if the query was successful
dr|z3d
if [ -n "$result" ]; then
dr|z3d
echo "Query successful. Result: $result"
dr|z3d
else
dr|z3d
echo "Query failed. Check the DNSCrypt server configuration."
dr|z3d
fi
dr|z3d
echo "" # Add a line break for readability
dr|z3d
done
zzz
like any other encrypted anything, if you get the crypto or anything else wrong it's not going to answer, that's where I'm at
zzz
so I need to install a server locally that will tell me what's wrong, or else pull vectors out of some repo and validate those
zzz
there's no vectors in the spec except for the hashing part
dr|z3d
maybe try this, could help with debugging: dnscrypt-proxy
zzz
yup
zzz
actually that's the client side
dr|z3d
ah, I figured it would provide some useful debugging info. maybe you can run it with a server.
zzz
I'm the client
dr|z3d
yeah, I think you push requests through it and enable test mode and it'll give you some debugging output.
zzz
i got the server running
dr|z3d
*thumbs up*
zzz
[DEBUG encrypted_dns] UDP query error: Err(Unencrypted query or different protocol)
dr|z3d
you'll have it fixed up in no time :)
zzz
that msg isn't very helpful, I'm back to needing vectors or hacking the server code which I'm not going to do
zzz
but at least now I can test without sending packets to amsterdam
zzz
it's just like all our protocols, it's all MAC'ed, so it either works or it doesn't, and if not there are no clues