|
Volmarias posted:But seriously, what's Denver? an nvidia designed chip which is arm compatible via a mix of hardware decoding and software-based dynamic recompilation. i guess at some point they wanted to support both armv8 and x64 on the same chip with the tech, but scrapped that after realizing that intel's lawyers would have eaten them alive.
|
#
?
Apr 23, 2017 14:58
|
|
|
|
| # ? Jun 1, 2024 16:16 |
|
|
yeah, appears to be a transmeta revival, as no one has learned anything from history
|
|
#
?
Apr 23, 2017 16:32
|
|
|
Munkeymon posted:I don't record my bideo shames because I assume correctly the nobody gives a flying gently caress about watching me suck at being coordinated with such insightful commentary as 'gently caress' 'poo poo' 'bullshit' 'oh come on' 'god drat it' and my favorite go-to 'ugh' a lotta people just do it so their buds can watch while doing other poo poo, some of my friends do that and it's alright to have on in the background while i'm makin' circuits  okay back to security thread time sorry
|
|
#
?
Apr 23, 2017 23:45
|
|
|
Cybernetic Vermin posted:yeah, appears to be a transmeta revival, as no one has learned anything from history transmeta without the dumb VLIW bullshit might be interesting
|
|
#
?
Apr 24, 2017 01:29
|
|
|
so there's this uber poo poo in the news today https://techcrunch.com/2017/04/23/uber-responds-to-report-that-it-tracked-users-who-deleted-its-app/ apparently I've totally misunderstood how iphone stuff works because I really thought apple had fine grained permissions more like android so if your app wasnt authorized to use poo poo it would fail, but apparently anyone can/could leech identifiable information via IOKit, and would only by prevented by the apple reviewers dilligence? like, quote:“They were dynamically loading IOKit.framework (a private framework), then dynamically loading some symbols from it to iterate through the device registry (also very much forbidden). if your developer TOS says something is forbidden, why the gently caress wouldn't that also be forbidden in the IOS API?
|
|
#
?
Apr 24, 2017 02:44
|
|
|
I'm pretty sure that Apple does automated analysis of your binary and auto rejects you for using forbidden symbols, though I'm not 100% on that.Malcolm XML posted:A miserable pile of secret ops? 
|
|
#
?
Apr 24, 2017 02:50
|
|
|
Volmarias posted:I'm pretty sure that Apple does automated analysis of your binary and auto rejects you for using forbidden symbols, though I'm not 100% on that. yeah but I mean, I assumed it was something that also happened on the device like "your allowed permissions metadata, which is signed and verified by apple, does not include iokit access, you tried to access iokit, your app will now die and the phone will send a report to apple HQ about how nasty you are" not just "gee willikers I hope this static analysis we run catches all applications that try to do system("rm -rf /")"
|
|
#
?
Apr 24, 2017 03:00
|
|
|
ymgve posted:yeah but I mean, I assumed it was something that also happened on the device like "your allowed permissions metadata, which is signed and verified by apple, does not include iokit access, you tried to access iokit, your app will now die and the phone will send a report to apple HQ about how nasty you are" at least we're in the right thread.
|
|
#
?
Apr 24, 2017 03:04
|
|
|
ymgve posted:so there's this uber poo poo in the news today Fingerprinting is complicated and hard to defeat technically while remaining useful. It's one of those things where policy (and policy enforcement) goes far.
|
|
#
?
Apr 24, 2017 03:44
|
|
|
apseudonym posted:Fingerprinting is complicated and hard to defeat technically while remaining useful. It's one of those things where policy (and policy enforcement) goes far. but apparently iokit is something you could use to get the phone specific identifier, so app devs didn't need to think about doing complicated fingerprinting analytics, only about dodging app review it's totally understandable that it's hard to prevent "classic" fingerprinting where developers gather stuff like ip addresses, cookies, whatever to fingerprint users, but this was apparently a system call on a platform ecosystem that's entirely under apple's control, and their only security up until a few years ago was "please don't do that while we're watching" ymgve fucked around with this message at 03:57 on Apr 24, 2017 |
|
#
?
Apr 24, 2017 03:54
|
|
|
and when caught defrauding the app review process, Uber was too big to fail. the (driver) app should have been pulled
|
|
#
?
Apr 24, 2017 03:59
|
|
|
I read that they had geofenced Apple HQ and when the app sense it was in that location it wouldn't do the thing and since it was obfuscated it just didn't get caught
|
|
#
?
Apr 24, 2017 03:59
|
|
|
also I'm the president of Sudo Security Group
|
|
#
?
Apr 24, 2017 04:00
|
|
|
funny Star Wars parody posted:I read that they had geofenced Apple HQ and when the app sense it was in that location it wouldn't do the thing and since it was obfuscated it just didn't get caught That's exactly what they did. Location == Apple means it won't make any IOSKit calls. The location query wouldn't even be looked at twice, since that's a core function of the app running normally.
|
|
#
?
Apr 24, 2017 05:05
|
|
|
ymgve posted:but apparently iokit is something you could use to get the phone specific identifier, so app devs didn't need to think about doing complicated fingerprinting analytics, only about dodging app review Well lol, giving Apple more credit than they deserve there on how they lock down their APIs. Still when you're running code on the device its really hard to prevent fingerprinting, the analogies to browser fingerprinting dont hold up great.
|
|
#
?
Apr 24, 2017 05:07
|
|
|
quote:I worked for a company that nearly acquired unroll.me. At the time, which was over three years ago, they had kept a copy of every single email of yours that you sent or received while a part of their service. Those emails were kept in a series of poorly secured S3 buckets. A large part of Slice buying unroll.me was for access to those email archives. Specifically, they wanted to look for keyword trends and for receipts from online purchases.
|
|
#
?
Apr 24, 2017 05:09
|
|
|
Giving random SV companies access to your email seems like such a great idea tho!
|
|
#
?
Apr 24, 2017 05:13
|
|
|
But Dropbox with
|
|
#
?
Apr 24, 2017 14:25
|
|
|
apseudonym posted:Giving random SV companies access to your email seems like such a great idea tho! im the guy in the comments trying to sell their own weird email service and whining that people don't trust it even though he charges money. y-combinator proceeds to get really happy about the "value proposition" and other capitalism things, yet not a single visiter with a y-combinator referrer signs up 
|
|
#
?
Apr 24, 2017 14:30
|
|
|
flosofl posted:That's exactly what they did. Location == Apple means it won't make any IOSKit calls. The location query wouldn't even be looked at twice, since that's a core function of the app running normally. they're not flagrantly violating the rules to make their business model work, they're disrupting the app industry
|
|
#
?
Apr 24, 2017 14:36
|
|
|
app review isn't source review, they only look at your binary to manually spot check their UI rules. there are automated tests to catch stuff like linking to forbidden symbols, but there are ways around that in objective-c/swift. like, if someone assembles a framework name at runtime and submits it to the dynamic loader you can't tell whether it's a kosher optimization or someone trying to sneak into the private namespace without context. the overall policy is supposed to act as a backstop to this but whenever they reject an overly clever app for "gently caress you and we're not gonna argue about this" there's a huge PR shitstorm so it's become very rare
haveblue fucked around with this message at 16:18 on Apr 24, 2017 |
|
#
?
Apr 24, 2017 15:55
|
|
|
if there are banned APIs then those APIs should not be accessible at runtime, but I don't think that's whats going on here. I think its probably a policy issue where the API is ok to access but what you do with the results has policy restrictions like "you can query this api to get the device id and here is a list of things you should or should not use it for" if they shouldn't be able to, in this example, get device id at all, then the api shouldn't be accessible from the sandbox.
|
|
#
?
Apr 24, 2017 16:48
|
|
|
ate all the Oreos posted:im the guy in the comments trying to sell their own weird email service and whining that people don't trust it even though he charges money. y-combinator proceeds to get really happy about the "value proposition" and other capitalism things, yet not a single visiter with a y-combinator referrer signs up The headlines on this one have been amusing this morning quote:Unroll.me head 'heartbroken' that users found out it sells their inbox data We're sorry. So sorry. So sorry that you caught us
|
|
#
?
Apr 24, 2017 16:49
|
|
|
they weren't caught so much as someone actually read what they do in their terms of service.
Shaggar fucked around with this message at 16:54 on Apr 24, 2017 |
|
#
?
Apr 24, 2017 16:51
|
|
|
hey if I ever wanted to hide my_crimes.txt i'd just throw it smack in the middle of a long eula
|
|
#
?
Apr 24, 2017 16:53
|
|
|
its like someone making a big deal out of a "discovery" that facebook monetizes your interests and activities.
|
|
#
?
Apr 24, 2017 16:54
|
|
|
this prompted me to double-check spark's EULA and they're still legit so thanks, uber & unroll
|
|
#
?
Apr 24, 2017 16:56
|
|
|
I'm with you here though, shaggs. Anyone who gives a third party service their email login credentials deserves whatever happens to them and then some
|
|
#
?
Apr 24, 2017 16:57
|
|
|
Shaggar posted:if there are banned APIs then those APIs should not be accessible at runtime, but I don't think that's whats going on here. I think its probably a policy issue where the API is ok to access but what you do with the results has policy restrictions like "you can query this api to get the device id and here is a list of things you should or should not use it for" i'd more assume that the api is used by apple's libraries to do things that are Allowed, so closing the security hole would require redoing those library functions to do the device-id-related stuff in the core os instead of on the app side. and then you've got to do something about all the apps using the old library versions that expect to call the private api.
|
|
#
?
Apr 24, 2017 17:01
|
|
|
apple apps should be running in a different sandbox config that allows those api actions. or if they're system applications, not running in the sandbox at all.
|
|
#
?
Apr 24, 2017 17:03
|
|
|
Shaggar posted:I think its probably a policy issue where the API is ok to access but what you do with the results has policy restrictions like "you can query this api to get the device id and here is a list of things you should or should not use it for" well yeah, it's impossible for a simple binary analyzer to determine the full context in which a particular call is made. I'm giving the reason apple doesn't typically have access to that context there are indeed things in the ios api where using them requires that you submit additional documents with your app explaining why you need that feature and what you're using it for, like allowing non-secure HTTP to arbitrary domains
|
|
#
?
Apr 24, 2017 17:05
|
|
|
totally. it just seemed to me that all the reporting was suggesting its some kind of technical abuse ex: breaking out of the sandbox vs policy abuse where they're misusing api access that they've been legitimately granted. if it were technical abuse it would be a sign of flaws in the apple sandbox which more than uber would be exploiting.
|
|
#
?
Apr 24, 2017 17:12
|
|
|
Shaggar posted:apple apps should be running in a different sandbox config that allows those api actions. or if they're system applications, not running in the sandbox at all. sometimes libraries intended for application developers use "private" system calls that aren't meant to be used directly. since the library code is embedded in the app, the app's security context has to have access to the api, but the app code itself is not supposed to use it directly. if the library is well designed, then the "private" api doesn't actually provide anything that the app couldn't already do by calling the officially supported library. but sometimes that's not the case, and it can be hard to lock it down if you don't want to break apps compiled against the badly-designed version of the library.
|
|
#
?
Apr 24, 2017 17:28
|
|
|
https://lyrebird.ai/ Welp. I think we can give up now. https://lyrebird.ai/demo
|
|
#
?
Apr 24, 2017 17:36
|
|
|
Carbon dioxide posted:https://lyrebird.ai/ on the one hand that's some creepy dystopia stuff, on the other hand we can finally get voice assistants that talk in Majel Roddenberry's voice like proper star trek poo poo
|
|
#
?
Apr 24, 2017 17:42
|
|
|
also that robot obama sounds like he's being forced to talk by electric shocks or something 
|
|
#
?
Apr 24, 2017 17:45
|
|
|
Shaggar posted:apple apps should be running in a different sandbox config that allows those api actions. or if they're system applications, not running in the sandbox at all. It pains me when shaggar is right but core OS functionality runs with higher privs than a random app, it's not hard to do that correctly.
|
|
#
?
Apr 24, 2017 18:14
|
|
|
if they could handle the performance effects, they could just broker everything
|
|
#
?
Apr 24, 2017 18:15
|
|
|
they do have cross-sandbox communication which they use for app extensions but maybe the overhead is too great to use it for everything
|
|
#
?
Apr 24, 2017 18:17
|
|
|
|
| # ? Jun 1, 2024 16:16 |
|
|
haveblue posted:they do have cross-sandbox communication which they use for app extensions but maybe the overhead is too great to use it for everything It's not. Relying on private APIs not being used for security is just bad OS design.
|
|
#
?
Apr 24, 2017 18:35
|
|