[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Most Security Assertions Dangerous [Re: YouTube via Onion Services]
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 :)
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...
>
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk