3 ms·

you ignore extraneous user data?!??! what!?!?! why do you get it in the first place if you're only interested in a subset? bunch of lying rootkit developers

derefr 15y ago
A topical metaphor: sometimes, to get a toy, you have to buy the whole happy meal.
- hboon 15y ago
  But here, you are forced to eat it too.
ghshephard 15y ago
From the article: "If during a support call a technician asks a customer to enter a short code, CIQ will be listening for it; when it’s entered, CIQ will relay the appropriate diagnostic information to the carrier. Any keystrokes beyond that are ignored." Their explanation then, for monitoring keystrokes, is that they are waiting for a diagnostic code to be entered by the user. Presumably this can be done from anywhere within the phone, on any platform, without regards to running applications.
latch 15y ago
How do you capture a subset of data without capturing it all (and discarding what doesn't match)? If you are doing a find in a document, don't you scan through the entire document and discard whatever isn't what you want? It sounds like that's the explanation they are trying to give.
- salimane 15y ago
  the thing is, given the context, you can do this without looking at everything the user is doing, you can basically wait for the trigger (error, call drop...) to happen before trying to submit error reports. that's the way it's done in software applications
  - latch 15y ago
    Just to be clear, I'm not saying they are right, I'm just trying to look at this objectively. If you read what they said, I don't think your solution works: "During a support call a technician asks a customer to enter a short code, CIQ will be listening for it" Without knowing a ton more, maybe there's a _much_ better way to do this..like having the user explicitly launch a program rather than having something always running and always listening. No argument there. But if you're thinking they should abstract away some "code_entered" event, ultimately something lower-level is going to be listening to each keypress and looking at sequences to raise those events. Some of this stuff happens at a lower level than a lot of us might be use to programming nowadays. I'm not sure that there's necessarily a pretty error event they can hook into. Something about all of this reminds me of using stuf like Spy++ on Windows and you see just how much raw data is available at the lowest levels

derefr 15y ago

A topical metaphor: sometimes, to get a toy, you have to buy the whole happy meal.

hboon 15y ago
But here, you are forced to eat it too.

ghshephard 15y ago

From the article: "If during a support call a technician asks a customer to enter a short code, CIQ will be listening for it; when it’s entered, CIQ will relay the appropriate diagnostic information to the carrier. Any keystrokes beyond that are ignored." Their explanation then, for monitoring keystrokes, is that they are waiting for a diagnostic code to be entered by the user. Presumably this can be done from anywhere within the phone, on any platform, without regards to running applications.

latch 15y ago

How do you capture a subset of data without capturing it all (and discarding what doesn't match)? If you are doing a find in a document, don't you scan through the entire document and discard whatever isn't what you want? It sounds like that's the explanation they are trying to give.

salimane 15y ago
the thing is, given the context, you can do this without looking at everything the user is doing, you can basically wait for the trigger (error, call drop...) to happen before trying to submit error reports. that's the way it's done in software applications
- latch 15y ago
  Just to be clear, I'm not saying they are right, I'm just trying to look at this objectively. If you read what they said, I don't think your solution works: "During a support call a technician asks a customer to enter a short code, CIQ will be listening for it" Without knowing a ton more, maybe there's a _much_ better way to do this..like having the user explicitly launch a program rather than having something always running and always listening. No argument there. But if you're thinking they should abstract away some "code_entered" event, ultimately something lower-level is going to be listening to each keypress and looking at sequences to raise those events. Some of this stuff happens at a lower level than a lot of us might be use to programming nowadays. I'm not sure that there's necessarily a pretty error event they can hook into. Something about all of this reminds me of using stuf like Spy++ on Windows and you see just how much raw data is available at the lowest levels