💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › ydsfv9a6rk.fsf@UBEblock.ps… captured on 2023-05-24 at 18:27:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
From: Winston <wbe@UBEBLOCK.psr.com.invalid>
Subject: Re: Initial thoughts
Date: Fri, 03 Dec 2021 13:21:51 -0500
Message-ID: <ydsfv9a6rk.fsf@UBEblock.psr.com>
2 of 2 I'm reposting. I explained why in the other reposted article.
I previously posted:
Note: I've only just read the FAQ. I have not read the protocol spec.
As partially noted in the FAQ, many of the privacy and annoyance issues
Geminii seeks to address, including popups, are caused by scripts
(mainly Javascript, but other scripts are allowed and supported) and
cookies. Geminii addresses these by not supporting scripts or cookies.
"No scripts" fixes pretty much all the annoyances.
Geminii does not support CSS or style. Given modern CSS's media query
capabilities, not supporting CSS helps protect privacy (such as device
property identification, which can be accomplished via CSS style in
several different ways).
I see that Geminii also does not allow file inclusions, so images,
iframe content, and the like aren't available. That stops web bugs.
There are, however, other methods for tracking, and I can't tell whether
Geminii addresses them.
1) Link click tracking.
Suppose you have a page of links, and the site that served that page
wishes to track which link you clicked. [In the case of Google, for
example, my impression is that they use the information about which
one you chose to improve search result order, moving the more popular
choices up in the search results.]
The typical method of doing that is what I'll call a URL redirect.
Let's say host H1 served a page of links L1, L2, L3, ... Tracking
by H1 might be accomplished by using local links of the form:
/url?q=L1&searchquery=queryID&youclicked=L1
/url?q=L2&searchquery=queryID&youclicked=L2
When you click on the link, the request goes to H1 which collects the
tracking info and redirects the client to L1, L2, ... -- a redirect
that is mostly invisible to the client, so it looks like you went
directly to the link (e.g., L1).
If Geminii allows full URI spec URLs, then '&'s are allowed and
there's nothing that would prevent this kind of tracking.
2) Misleading link labels.
One of my peeves with HTML is the ability to specify things like
[my ISP doesn't allow HTML tags, so I'm using [] instead of <>]
[a href=link1] Unrelated link2 [/a]
where the text label doesn't match the link and can be arbitrarily
misleading. Phishers love this. I see that Geminii allows links and
labels. Always displaying the link URL would help, but not everyone
is going to take the time to examine the URLs, so:
Could a URL such as [I don't know Geminii link format, so I'm using
label; link here]
Wells Fargo login; https://www.wellsfargo.com.login.scammer.scam/...
(a method used by some scammers, where they put the name you expect
at the beginning of a long domain name, counting on the reader not
noticing that the URL continues with '.', not '/') work in a Geminii
document to mislead the reader?
3) Does the geminii: network protocol support the "Host: name" header?
The "Host: name" header is used to support multiple virtual hosts
with just a single IP address, including running a single server for
all the hosts.
I think I've now seen articles in this newsgroup indicating that it
does, so you only need to answer #3 if the answer is No.
Just some initial thoughts,
-WBE
Parent:
Initial thoughts (by Winston <wbe@UBEBLOCK.psr.com.invalid> on Tue, 26 Oct 2021 19:32:55 -0400)
Start of thread: