[tor-dev] Doesn't hidden services break RFC 3986?

[Ryan Carboni]

Also: just because it's HTTP/S running over a different network stack,
doesn't make it a new scheme.

Just because your dinner arrives on a different plate doesn't mean the
recipe has changed. :-)

---

https://bugzilla.mozilla.org/show_bug.cgi?id=1228457

Tor is a strange sort of sacred cow

highly revered

leaks much methane

But RFC 7686  literally bent over backwards to rewrite multiple standards
because Tor was long existing. ".onion" shouldn't be resolved or sent over
the internet.
Sure, IP multicast had to be implemented, but its relevance to people not
replacing analog technologies isn't particularly great, and those are
corporations who make billions combined per year.

But uh yes. Only the plate changed. But internet standards are very clear
on plate specifications. Or rather, "authority" lookup. The dinnerware
request protocol is pretty clear on this, with other protocols providing
for saran-wrap or foil-wrap encapsulation, with their own provisions for
exterior labeling.

(or if there was a new way to link to torrent hashes, do you think it
should be "torrent://hash/" or "hash.torrent"?)

Although, if you guys really want to risk your government funding, I
suggest $10,000 bug bounties out of a fund sized large enough to hire a
single programmer (assuming there's a risk that you'll have more than a
dozen severe bugs). To make things more difficult for the NSA, make it
clear that there is no requirement for a cyber arms seller to stay bought
by one person. Or propagate a meme that a cyber arms seller could sell the
idea of an exploit to another cyber arms seller to write a new exploit for
the same bug. Force folks like zerodium to pay twice.


or uh "Make the enemy live up to its own book of rules."

But who is your enemy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170814/e9cafa23/attachment.html>