[tor-talk] Most Security Assertions Dangerous [Re: YouTube via Onion Services]

[grarpamp]

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...

[bo0od]

One simple line: how is that related to be bad for invidious ?

- You talked about JS been bad (agreed), but its unrelated/invalid to
invidious case. Protonmail cant operate/login without the JS and most
likely their JS is closed source but that has nothing to do with invidous

- You mentioned repos and bsd ..etc this has nothing to do with user
security while they are browsing invidous case.

- You mentioned the connection unclean , well hey the guy just started
the mirror yesterday give a chance. plus its free software do support
him in github to make this better place.

- You mentioned youtube-dl and similar services , well these firstly has
different goals than another safe front end to YB in our case with
invidous. Also Invidous onion by design it has Onion hidden services
security , whereas with youtube-dl downloading from youtube this isnt
valid case (no onion hidden services implementation).

So in short , instead of warning the ppl about something which has no
meanings on reality, go and help to make invidous (or any similar
service) better place for security and privacy for the end user.

Thank You :)

Post by grarpamp
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...

[mick]

On Thu, 6 Dec 2018 03:25:05 -0500
grarpamp <***@gmail.com> allegedly wrote:

[ some snippage throughout ]

Post by grarpamp

- 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.
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.
[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...

Thank you once again Grarpamp. You may be OTT occasionally, but
nevertheless it is worth reminding people that security is not an
absolute. We all make assumptions about who, or what is trustworthy
and in what context. But those assumptions should always take account of
our own particular threat models.

Best

Mick

---------------------------------------------------------------------
Mick Morgan
gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
https://baldric.net/about-trivia
---------------------------------------------------------------------

[Nathaniel Suchy]

Post by grarpamp
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.

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 (you'd need to stay a few versions behind and merge changes after you've confirmed they are safe). But for a second let's be realistic here.

1) Very few people know every programming language and have the ability to successfully security audit their operating system, apps, and web clients.
2) You are running unknown code every day. Do you trust the vendors?
3) There's no perfect security, but you can strive for better.

It's unfair to call encrypted email providers "fake". They're trying to solve a complicated problem, inside a web browser, with no easy solution :-/

Cordially,
Nathaniel Suchy

Post by grarpamp
On Thu, 6 Dec 2018 03:25:05 -0500
[ some snippage throughout ]

Post by grarpamp

- 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.
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.
[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...

Thank you once again Grarpamp. You may be OTT occasionally, but
nevertheless it is worth reminding people that security is not an
absolute. We all make assumptions about who, or what is trustworthy
and in what context. But those assumptions should always take account of
our own particular threat models.
Best
Mick
---------------------------------------------------------------------
Mick Morgan
gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312

Post by grarpamp
https://baldric.net/about-trivia <https://baldric.net/about-trivia>

---------------------------------------------------------------------
--
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>

[grarpamp]

Post by Nathaniel Suchy
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.

Post by Nathaniel Suchy
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 .

Post by Nathaniel Suchy
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.

Post by Nathaniel Suchy
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?

Post by Nathaniel Suchy
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.