Beware. When it's your turn to be dissatisfied with their unchecked power, it'll be much too late.
1,120 karma · joined April 7, 2012
Beware. When it's your turn to be dissatisfied with their unchecked power, it'll be much too late.
1) A trained FSB operative completely fell for a convincing enough social engineer, armed with nothing but caller-id spoofing software. Even though he was extremely apprehensive in the beginning of the call, he was slowly "eased into" talking top-secret stuff on the non-secure phoneline. This was so incredible that his last words on the call were "I was shocked by your questions. Was this OK that we talked about this on a non-secure line?". That's crazy. What chance do normal people have against such a good social engineer?
2) The amount of pro-Putin commenters in this thread (mind that some of these comments are dead), claiming that this is a CIA false flag or some such.
IIRC it is stored in your Google Drive under an API key that is dedicated to whatsapp (in some kind of per-app storage). I don't really know much about Google Drive API.
However, I am fairly sure that the key is in the binary on your phone, so it shouldn't be much of a challenge to get access.
I think there was something like this on Github once, that no longer works (due to trivial changes, likely).
Update: https://github.com/YuriCosta/WhatsApp-GD-Extractor-Multithre...
Looks recent, didn't try myself.
https://faq.whatsapp.com/android/chats/about-google-drive-ba...
Or do we already live in a world where cars don't work without internet access?
Either explain to us the attack vector against actual SHA1 certificates that could result in wide-spread faking of certificates, or withdraw your claim.
Your explanation needs to also explain how this attack could cicumvent the various defense-in-depth official and unofficial checks (certificate transparency, certificate revocation lists, limited time validity)."
I hope we can at least agree that this is not the way to argue about security protocols at least when it comes to crypto.
And of course "there is no evidence that any large scale voting fraud took place". Uttered to me by multiple people who I know understand that there can't be any evidence.
Email is not secure, no matter what service you use. It is transferred in plain text between providers.
1) DRM on these machines is dead (yay).
2) "Anti-theft" features, which are really there just as an excuse to put a dedicated DRM chip into your box, are dead.
3) Physical access to your machine by a sophisticated attacker is game over (unless your data is encrypted and at rest).
I hope #3 isn't news to you, despite having an Apple logo on your machine (or Phone).
The answer is sort of yes, in the sense that they provide you with more succinct explanations and analogies. This is useful if you want to explain this stuff to other people (who are not on HN).
I never thought it would be that easy, but it converted the task of writing something that does MDIO, SPI, and WiFi (with a webserver) in C, to basically a day of work.
Also the "feel" of running an interactive python shell on a tiny 1x3cm board as part of the initial bring-up process after manufacturing is just awesome. Controlling every IO "manually" via the interactive shell is so much better than seeing your prepared C code crash and burn, and only then start debugging it.
This particular case is also outrageous for other reasons:
1) They are only doing this now because Corellium has been selling virtually the same thing for a while already.
2) They are doing this to try and hurt Corellium financially, while they're already suing them in parallel.
3) Agreeing to their terms here, effectively makes you a glorified Apple QA engineer. Only you don't get a salary, but rather, a bounty for whenever you find a bug. For most people that would be way, way less money than just being employed wherever.
If America doesn't crack down on Google's, Facebook's and Twitter's ability to "moderate" (censor) content at their discretion (today!), Western democratic society will come to an end. Sooner rather than later.
These services are utilities, sometimes monopolies, and must be regulated as such.
The only "security" this improves, is of devices where the manufacturer has decided to lock you out!
This kinda reminded me of the late 00's. It was quite common that the odd government or enterprise website was IE6 only.
All hail the new IE6.
Let's make software that generates content that to the big-media-bots looks like their copyrighted content, but to a human arbiter looks like anything but. This can be done automatically, by continuously gauging the response of the bots to variations in our generated content, and adjusting accordingly.
We'll spray this content all over, using throw-away accounts. Then dispute all the claims. Could we increase the volume of all claims n-fold this way? If so, at some point this would have to affect the trustworthiness of these bots with Google.
I refuse to accept that there is no way to fight back. If we could abuse the system in some way as to make this a problem for Google, I believe change can be achieved.
Encryption of IP traffic happens on the open system, so no problem there.
If you'd like to complain about encryption of voice calls happening on the closed modem, I have some bad news. It wouldn't matter if it was open or closed, since the network it negotiates keys with is also compromised.
The only problem remaining, on this particular device, is direct connection of physical sensors (microphone, GPS, etc) directly to the modem. This is solved by physical switches (or hardware switches controlled from the open system) between the sensor and the modem.
The only exception I see now is the GPS, which is embedded into the modem. If they solve that, I'm buying the phone.