7 ms·
Edit: deleted, for very valid criticism. Next time I won't post in a rush during work hours.
by libertymcateer 10y ago
Edit: deleted, for very valid criticism. Next time I won't post in a rush during work hours.
- shawnz 10y ago> Please be aware that the Chrome browser does not offer a secure local storage protocol for its developers ... Compare this to Safari, which offers secure local storage at OS level security But this is just as secure as full disk encryption of the device right?
- chrisballinger 10y agoNot for malware running in user space.
- md_ 10y agoThe browser runs in user space. Desktop OSes don't offer any sort of partitioning here. So there's very little reason to have any app-level encryption on a desktop OS.
- vetinari 10y agoRunning in user space is not enough. It would need root. It is also hard to keep root, when you have dm-verity and selinux in enforcing mode. Android applications are also sandboxed from each other. You would have hard time getting from one app to another's files, unless the original app published them - or you've got root.
- md_ 10y agoDon't take this the wrong way, but as a non-lawyer, I try to heavily caveat any statement I make about the law. Would you consider heavily caveating statements you make about information security? A lot of what you say here is basically wrong.
- dmix 10y agoIndeed, this is technical expertise domain of an information security researcher, not a lawyer. A national security lawyer could provide interesting insight into how the CIA is allowed to use these tools vs NSA.
- deleted 10y ago[deleted]
- libertymcateer 10y ago> I try to heavily caveat any statement I make about the law. That is appreciated, and you are in the minority. I'm taking this advice, btw, and being more circumspect when I post in the future.
- md_ 10y ago:) Cheers.
- libertymcateer 10y agoFor serious, thank you for taking the time to engage. I do take this seriously.
- md_ 10y agoYep. Same. And I would probably have posted a longer and less confrontational explanation of why you're (mostly) wrong if I weren't tired after a long day of work. ;) The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.
- libertymcateer 10y agoThis argument is almost exactly what I was on about. I'd love to see some summary of it and why they came down where they did.
- jcfrei 10y agoI would like your take on a more specific question: Do you think that Google applications (GMail, Search, Translate, Maps, etc) themselves can get access to the necessary kernel subroutines to catch information which is intended for encryption? Or would running a custom rom (ie. cyanogenmod) while still using Google applications suffice to mitigate these attacks?
- md_ 10y agoWait, what? If you are running something based off of AOSP, you're running code that was touched by Google employees. Is your fear that Google is installing backdoors to help the CIA? If so, why are you afraid of that?
- jcfrei 10y agoRight, so in the scenario I mentioned, an update to a Google application would give this application more access to the kernel (through some backdoor) and enable it to intercept the communication of other apps. I'm asking whether this is possible or not - assuming the kernel itself cannot be modified. If that's the case then parts of the android kernel or the way android handles access to microphones, etc. might need to be hardened in the future.
- md_ 10y agoThe Android security model doesn't work that way. Non-system applications can't access the kernel, minus a local EOP or something like that. Is that your concern? And if so, why are you concerned specifically about Google apps? Any malicious app can exploit a local EOP.
- jcfrei 10y agoYes, that is my concern. You mention system applications - I believe this excludes any application which can be installed (with an app store or apk)? What is a local EOP? I couldn't find any info on this abbreviation. I used Google as an example.
- jMyles 10y ago> Compare the security of Android - which we now know to be 'owned' by the US Government To what are you referring to here, precisely? Since AOSP is open source, is there a specific line of code that you can point to that contains (or is emblematic of) this insecurity? Your article doesn't seem to say.
- chillydawg 10y agoThe CIA tools to own it were just leaked. You are commenting on the thread talking about those tools and the leak announcement.
- jMyles 10y agoAs far as I can tell, my question ("which line of code is broken?") is also not answered either in the NYT piece or the wikileaks release. If I'm wrong, do you have a link?
- libertymcateer 10y agohttps://www.washingtonpost.com/world/national-security/wikileaks-says-it-has-obtained-trove-of-cia-hacking-tools/2017/03/07/c8c50c5c-0345-11e7-b1e9-a05d3c21f7cf_story.html https://www.washingtonpost.com/world/national-security/wikil...
- benwilber0 10y ago> Here is my take as an information lawyer and (slightly-higher than script-kiddy-level) web developer as a "(slightly-higher than script-kiddy-level) web developer" I'm going to guess that he doesn't actually know very much about AOSP, the Linux kernel, or indeed GNU/Linux security in general. So his emphatic statement "Compare the security of Android - which we now know to be 'owned' by the US Government" is pretty much worthless as he's very clearly speculating about things that he doesn't understand.
- libertymcateer 10y ago
- awinter-py 10y agocareful with claims that android is 'owned'. You want to distinguish between: - remote takeover (like stagefright vuln) - ability to take control of the device from within an app sandbox - ability to unlock a device in your physical possession (FBI was able to do this on prev V of ios)
- libertymcateer 10y agoI spent a fair amount of time reading up on the wikileaks last night. While the released info does appear to not be beyond KitKat, the array of listed hacks is staggering. Have you had a chance to look? I understand that there are very fine levels of distinction between these types of hacks, but it seems to me that there were multiple root compromises.
- bitmapbrother 10y ago>Compare the security of Android - which we now know to be 'owned' by the US Government - with the security of iOS, which was the subject of a public and gruesome lawsuit about a year ago because the Fed could not hack iOS. So your comparing the current security of the iPhone with old CIA Android and Chrome exploits from circa 2011-2013?
- sleepychu 10y agoWas going to email you but I couldn't find a way of getting your contact information without enabling google JS (something you might want to consider as a privacy advocate) The background video on gibber is awful, makes it very hard to read the page. I've just opened it in another browser with all the JS on and again your page totally doesn't work with the google ajax switched on. Worth fixing.
- libertymcateer 10y agoNoted, and thanks. Your feedback is much appreciated.
- revelation 10y agoEh, they couldn't hack (1) the device in standby/locked with keys flushed and (2) the encrypted physical data on the flash. But that is a much more difficult proposition. Just hacking the device while it is being used is what every iOS jailbreak does. And there seem to be quite a number of them. Not sure why you mention "secure local storage"; none of that local storage is secure if the device is compromised! That can then be bypassed in the same way that you bypass WhatsApp or manipulate any other app on the device.
- nikcub 10y ago> Next time I won't post in a rush during work hours. I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0] A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app It is trivial to find the plaintext in these situations. Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page. To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered. [0] https://www.gibberit.com/ https://www.gibberit.com/ [1] http://i.imgur.com/CsgOkZ2.png http://i.imgur.com/CsgOkZ2.png [2] http://i.imgur.com/uZg0E4l.png http://i.imgur.com/uZg0E4l.png [3] http://i.imgur.com/eq19mET.png http://i.imgur.com/eq19mET.png [4] http://i.imgur.com/lOsibBP.png http://i.imgur.com/lOsibBP.png
- libertymcateer 10y agoBelieve it or not, I very much appreciate your feedback.
- nikcub 10y agoI'd probably take the site down, or mark it clearly as being a hobby project. As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki: https://www.chromium.org/Home/chromium-security https://www.chromium.org/Home/chromium-security
- libertymcateer 10y agoIt's currently marked as beta all over the site, for exactly these reasons.
- 10y ago