neerdowell
Joined 11 years ago
Karma
287
Submissions
54
Member since
Nov 25
Recent submissions
Comment · 10 years ago
This is a textbook example of FUD.
Comment · 10 years ago
> There's no way to know GCHQ/NSA aren't running 90%+ of bridges and exit relays
Yes there is. There are currently 857 exit nodes. The Tor Project only has to personally know who runs 86 of them to ensure that 90% of the exits are not run by the NSA.
In fact, since ~90% of traffic exits through the top ~260 relays, they'd only need to know 27 of the people who run those.
Comment · 10 years ago
> The Tor Browser does not send misinformation; it just blocks.
No, it doesn't. TB sends all kinds of misinformation, from the user agent string (always reports itself as being its base version of Firefox running on 32-bit Windows 7) to rounding javascript timing functions to reduce the precision.
> A solution would probably be a browser where every version, on every platform reports the exact same things, always the same way.
That's exactly what Tor Browser does.
Comment · 10 years ago
> The Wire guys made very specific claims (where did they get the >$2M figure from ... and why would they simply invent such a figure).
Their court filing[0] says the license fee was "unspecified" and the $2 million figure was based on "information and belief" which is legal terminology used to dodge perjury[1]. If they had really been told that, they wouldn't be using terms that mean "I heard that from somewhere second-hand and think it might be true".
[0] https://www.scribd.com/doc/311974670/Wire-Swiss-GmbH-v-Quiet...
Comment · 10 years ago
You think more than 50% of the people using Chrome deliberately sought it out and installed it after making an informed decision?
Not because it was pushed via bundlware or a Google-owned property?
Comment · 10 years ago
Most users haven't made a conscious choice to use Chrome. They install it accidentally by not unticking a checkbox[0] or because they are told it will make the Google work better[1].
Comment · 10 years ago
CCleaner: https://i.imgur.com/LNFjqzd.png
The checkbox is pre-selected.
Comment · 10 years ago
Except they are. The F-Droid devs kept claiming they weren't. Moxie asked them to describe the system and surprise, surprise the keys are stored on a machine that is connected to a network that is connected to the internet. It turned out that the F-Droid devs didn't/don't understand the concept of stored offline vs online.
Response from actual FDroid dev:
> It's connected to the network, yes
Comment · 10 years ago
What? APKs are signed by the developer before they uploaded to the store and the signatures are verified by PackageManagerService which is a part of AOSP.
Comment · 10 years ago
> By giving NSA the only thing what they want: metadata from Google
What metadata does Google get from Signal messages? The time/date you received a message, the size of the message... Is there anything else?
Comment · 10 years ago
What does Play Services have to do with anything? APKs downloaded from the Play Store are signed by a key the developer holds and validated by Android's PackageManagerService which is open source.
Comment · 10 years ago
> But ignoring much of the developing countries (see whatsapp), China
Moxie says Signal works fine in China: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Comment · 10 years ago
> He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him.
He doesn't like how F-Droid uses centralized signing keys which are stored online: https://github.com/WhisperSystems/Signal-Android/issues/127#...
Comment · 10 years ago
Each device has its own key. Before a message is sent, the client grabs all the keys for each device associated with the account of the recipient, it then encrypts the message separately for each device and sends a separate encrypted copy for each device.
This scheme has various weaknesses, eg. a rogue key could be associated with someone's account without their knowledge, and anyone who sends this person messages will therefore be sending a copy encrypted with the rogue key.
Comment · 10 years ago
I'm not seeing your point. A vulnerability was found in OpenSMTPD. That vulnerability could not be exploited on OpenBSD because there was no way to overflow the buffer without smashing the stack canary. If you had the same version of OpenSMTPD running on a generic Linux kernel or on Mac OS X, it was vulnerable. On OpenBSD it was not. Ergo, OpenSMTPD running on OpenBSD is more secure than OpenSMTPD running on other platforms that do not provide the same mitigations.
At least, that's the way I see it.
Now, are you saying that because it's possible to bypass the mitigations in some other cases, preventing that vulnerability (and others) doesn't matter?
Or, are you saying that it would be possible to craft an exploit that bypassed the stack protection for that particular vulnerability? In which case I would love to see your PoC.
Or something else?