Most Security Assertions Dangerous [Re: YouTube via Onion Services]
grarpamp at gmail.com
Thu Dec 6 00:25:05 PST 2018
In a thread...
(noting that all onions can be physically located by determined
adversaries, thus failing another commonly sold security assertion)
> - Its free software and the code is available for install/checkup.
That assertion is irrelevant in the security context
of the thread so far, and it's dangerous advice.
As with protonmail and all the other fakeass encrypted email
websites... the JS code is loaded by the browser from the web
service itself, there is currently NO trusted way for the user to
independantly audit that the code they end up executing in
real time *from* the service matches the code *in* any repo,
or for the user to choose to ignore the service code and load
and execute any repo code of their choosing instead.
> Youtube is made by a dick company to humanity called Google, which is
> funding their services by stealing/collecting users data. So the JS
The current code load model is a nasty exploit waiting to happen,
does happen (Hushmail, NIT's, etc), and simply should not be trusted,
no more than GOOG and FB the dicks, themselves, indeed.
Or Java, ActiveX, Flash, and whatever other "secure" crap some
scam tries to push into your pathetically insecure and
untrusted exec platform.
Sure Invidious Onion is fun, probably has some merits and
use cases, and even simple html could be an exploit, and
users can run it all in a sandbox, etc.
But let's not say there's any trusted link between the running
and repo codes, nor that any sufficient set of people have looked
at, and signed over, most codes, or are even allowed to... .
Also, clicking on any video listed on the onion frontpage
index initiates at least three connections straight to google
instead of the proxy onion. That's not clean.
> Plus you can watch the videos without the need to allow any JS.
> this particular YouTube frontend/proxy seems to be
> more focused on offering an alternative viewing experience rather than
... those and a few others readers can find and post here.
 You can't even say those for the release iso's of
OpenBSD, FreeBSD, the Linux's, etc... back
to their claimed source code repos... because
either those repos have no internal cryptographic
roots or hashes to sign over or with in the first place,
or some process in the path from there to the iso's
is not reproducible or cryptographically chained.
Same goes for Apple, Microsoft, Intel, AMD, ARM,
You're all still woefully fucked therein because you keep
buying the Kool-Aid, and refusing to demand, fix,
ignore, or eliminate them and their issues.
#OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #CryptoCurrency
The list of requisites to even get close to improving
the situation grows...
More information about the cypherpunks