Discussion:
Most Security Assertions Dangerous [Re: YouTube via Onion Services]
grarpamp
2018-12-06 08:25:05 UTC
Permalink
In a thread...
https://lists.torproject.org/pipermail/tor-talk/2018-December/044709.html

on...
http://kgg2m7yk5aybusll.onion/
http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion
(noting that all onions can be physically located by determined
adversaries, thus failing another commonly sold security assertion)
https://github.com/omarroth/invidious
- 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... [1].

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
privacy.
https://github.com/mps-youtube/mps-youtube
https://github.com/rg3/youtube-dl

... those and a few others readers can find and post here.


[1] 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,
Government, etc...
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
, #Anarchism

The list of requisites to even get close to improving
the situation grows...
Zenaan Harkness
2018-12-06 15:26:16 UTC
Permalink
Post by grarpamp
[1] 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.
Git style signed content hash chains and reproducible builds FTW
muffaluggerahs!

So Debian Buster is over 90%, yay!

From 2015 80%:

Lots of progress for Debian's reproducible builds
https://lwn.net/Articles/630074/

To Buster ~92.4%:
https://isdebianreproducibleyet.com/
“NO! … but buster on amd64 is 92.4% reproducible right now!”

To pretty dang gud bruh!:
Debian reproducible builds project update, 2017-07-23,
Stretch/amd64 reaching 94%
https://lwn.net/Articles/728599/

And some nice summary sheetskis and chartskis:
https://tests.reproducible-builds.org/debian/reproducible.html

https://wiki.debian.org/ReproducibleBuilds
Post by grarpamp
Same goes for Apple, Microsoft, Intel, AMD, ARM,
Government, etc...
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
, #Anarchism
Indeed.
Post by grarpamp
The list of requisites to even get close to improving
the situation grows...
Improvement in problem definition is necessary, and is not an
"increase" in the requisites to e.g. security of personal
communications, simply a fuller understanding of the problem.

Alt: we are rising from ignorance. Painful but necessary awareness.

Let's add to the above list another obvious in hindsight:
#StackMinimization - including HW - i.e. trust boundaries (nee attack
surfaces) must be seriously minimized to reach something we can
collectively reason about in its elements (hw/ sw).
grarpamp
2018-12-07 07:15:02 UTC
Permalink
Tutanota open sourced their client. You could use the source and run your
own version of the Tutanota client if that's your threat model. It's true
the email provider could serve different users different versions of the app
and there is no possible way to audit it in real time
A standalone app can give at least some distance and pinnable code.
And a bit more if served up from a "neutral" third party like github,
f-droid, or allowing tor or vpn to get it in some masked user fashion.
2) You are running unknown code every day. Do you trust the vendors?
Probably not wise until the world changes some more
towards those hashtags. Shall we add #SharedAudit .
It's unfair [...] They're trying to
solve a complicated problem, inside a web browser, with no easy solution :-/
Yes of course, they're at least trying something new,
that's important, so kudos.
It's unfair [...] to call [out] encrypted email providers
But is it... just look at most of their own front page
advertising statements that often go like...

"Secure Encrypted Email in your Browser"

Without weasel words, those statements can end up
being fake.

Does what net benefit the service may have for [most] users
offset potential damage arising from such statements?

There's a bunch of front page statements here too
that also have more holes than a block of Swiss Cheese...

https://www.torproject.org/

Who is parsing and calling them out, and or proffering
page updates that use suitably accurate weasel words?
inside a web browser, with no easy solution :-/
If the world is still stupidly insisting on the derelict spy exploited
relic of SMTP transport, instead of say fully encrypted P2P
overlay transports with legacy SMTP / POP / IMAP frontends
for the old timey feels, they should at least be directly extending
browser functionality to load and exec user selected third party
provided and fourth party audited message crypting code modules
from local disk.

Or should be using actual properly stood at a distance
tools like GPG, Enigmail, Mailpile, NeoMutt, whatever,
while replacement distributed P2P messaging and storage
systems gain marketshare.

If user can locally compile and use Tutanota from Github
with no blobs, that's interesting, perhaps consider dropping
them some coin if so.

Loading...