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

[Nathaniel Suchy <me@xxxxxxxxxxx>]

> 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



Dec 6, 2018, 8:55 AM by mbm@xxxxxxxxxx:

> On Thu, 6 Dec 2018 03:25:05 -0500
> grarpamp <> grarpamp@xxxxxxxxx <mailto:grarpamp@xxxxxxxxx>> > allegedly wrote:
>
> [ some snippage throughout ]
>
>>
>> > - 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 <https://baldric.net/about-trivia>
> ---------------------------------------------------------------------
>
> -- 
> tor-talk mailing list - > tor-talk@xxxxxxxxxxxxxxxxxxxx <mailto:tor-talk@xxxxxxxxxxxxxxxxxxxx>
> 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>
>

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