08:34 <enyc_> MonkeyofDoom: oooh thats useful to know armhf chroot works =)

09:16 <enyc> MonkeyofDoom: though some of the debian lxde images etc. had some custom/different pulseaudio package ... I should check the details, I might neet to reproduce something there to have that working again...

09:19 <enyc> MonkeyofDoom: I think I'll try just 'updating' one copy of the wheezy armel to jessie armel and see what happens... then consider making a jessie armhf variant =)

20:27 <DocScrutinizer05> background: http://www.forbes.com/sites/ewanspence/2015/07/14/nokia-android-smartphone-plans/

22:04 <enyc> DocScrutinizer05: oooh useful publicity sensible?

22:05 <DocScrutinizer05> sorry?

22:05 <enyc> DocScrutinizer05: i see all the mentioses of ccc.de and otherwise

22:05 <enyc> DocScrutinizer05: is this trying to get more publicity/interest in neo900 ?

22:06 <DocScrutinizer05> err basically yes. Neo900 will run a village on cccamp15 and Werner will do a talk. Of course this is to increase visibility of the project

22:07 <enyc> DocScrutinizer05: do you think you can present what the blockers and steps to completion are? I think more buyers would come if it looked like this might not fizzle-out / has clearly defined remaining tasks ?

22:08 <DocScrutinizer05> the remaining tasks are pretty simple: build it

22:08 <DocScrutinizer05> the blocker: get more preorders

22:08 <enyc> DocScrutinizer05: thats sounds simple but what are the underpinning steps and snags? are they listed anywhere enough to convince those that it looks like it will truly happen?

22:08 <enyc> DocScrutinizer05: and be 'workable' / 'usable'

22:09 <DocScrutinizer05> see neo900.org

22:09 <enyc> DocScrutinizer05: i think this 'appearance of ability to complete and work' (or lac therein) will hold up preorders... so is important... in my view

22:10 <DocScrutinizer05> I don't know what to present to you to convince you

22:11 <enyc> DocScrutinizer05: i'm not sut atlking about me... but anybody who hasn't been following in great detail

22:11 <DocScrutinizer05> so?

22:11 <enyc> DocScrutinizer05: underpinng steps, how many more board respins, realistic estimate of remanintg tasks and time

22:12 <enyc> DocScrutinizer05: so... i think this will hold up pre-orders if some may have underpinning suspiciton this could fizzle-out or similar

22:12 <enyc> DocScrutinizer05: fore xample, the simple point that ''pre orders is holding us up'' os not part of faq that i can see

22:12 <DocScrutinizer05> please read about all that in http://talk.maemo.org/showthread.php?t=91142 and http://neo900.org/

22:19 <DocScrutinizer05> for now we're on hold for preorders since we can only do one order for N900 devices and we have too few preorders yet to do that already. But that's not as bad as it sounds since Nikolaus is busy with Pyra until mid of August. After that we will continue with building proto_v2 and eventually we will order the N900, and at that point in time it's basically preorder "closed" since we cannot guarantee for further N900 getting available

22:21 <DocScrutinizer05> I'm pretty sure cccamp15 will result in another bunch of preorders, due to visibility. For feasibility see Neo Freeruner, GTA04, Pyra

22:23 <DocScrutinizer05> "underpinng steps, how many more board respins, realistic estimate of remanintg tasks and time" is all mere guesswork and worth nothing to publish any detailed lists. We elaborated on the general timeline and steps to do, several times already. More detailed info isn't available

22:25 <DocScrutinizer05> proto_v2: get a "working device" with core system (CPU, RAM, storage and power) on attached BB-xM

22:25 <DocScrutinizer05> proto_v3: integrate core system into proto_v2 board and evaluate for production

22:26 <enyc> DocScrutinizer05: fair enough =) I think these points should be copied/linked into a faq entry so e.g. that specific thread is more visibele ... i could try to word something when i'm more awake =)

22:30 <DocScrutinizer05> additional board spins are needed when we did an oopsie somewhere. The longer we check design before building a protoboard (whether v2 or v3), the more likely we find all oopsies without wasting a board spin for it

22:30 <enyc> nodsnods

22:31 <DocScrutinizer05> we checked so much now, I'm almost sure we will have a working proto_v2 already, on first spin

22:31 <enyc> so explain in the 'completion guesswork' faq that it may or may not need a further protoboard, they next will be done when nokolaus ... pyra ... but your current proto_v2 ...

22:32 <DocScrutinizer05> ilon: ^^^

22:33 <DocScrutinizer05> dos1: ^^^

22:36 <DocScrutinizer05> ilon: dos1: wpwrak: we also _need_ to send reminder mails now

22:37 <enyc> DocScrutinizer05: thankyou... for taking on board ... trying to be helpful here considering from a different pov...

22:37 <DocScrutinizer05> thanks a lot! :-)

22:41 <enyc> I had some very interesting discussions in arm discussing working between people of different types... engineers very interesting to manage =) projects and conflicting interests ... so it goes on...

22:46 <ZetaR> DocScrutinizer05: I have been thinking about a possible attack on the modem setup on the Neo900. What do you think of creating "banal" misbehavior of the modem w.r.t. transmission when it is powered but supposed to be shut down, e.g. when the user wants to use GPS with modem transmission disabled? I imagine it to be similar to breaking into a secure facility by intentionally setting the alarm off over and over again, and then during the re

22:47 <DocScrutinizer05> sorry, I can't follow

22:48 <DocScrutinizer05> aaah, maybe I get the idea

22:49 <DocScrutinizer05> well, it's not our decision how users react on atypical behavior of modem

22:49 <ZetaR> Also, if the modem has banal misbehavior out-of-the-box, then it ruins the idea of security by monitoring signal transmission.

22:50 <DocScrutinizer05> modem starting to transmit when it shouldn't is a severe atypical behavior, and it's prolly a bad idea to ignore the alarm just because it repeats over and over again

22:51 <ZetaR> So you don't think that it is likely that the modem will have misbehaving transmitting behavior in any typical state, i.e. it would be an attack, or HW damage, or something?

22:51 <DocScrutinizer05> yes

22:52 <ZetaR> Okay, that is good to know. I know I have been frustrated in the past when trying to set up security on my computers by programs doing stupid things that they shouldn't have to do.

22:53 <DocScrutinizer05> when modem is active/online and not booked in to APN and no ongoing call, it is not supposed to send longer than 1.5s continuously. No matter what. And when modem is inactive but powered up, it must not transmit at all, no matter what

22:54 <ZetaR> Is this by government regulation, or just industry best practice?

22:54 <DocScrutinizer05> this is GSM operation specs

22:54 <ZetaR> Ah, okay. That is good.

22:55 <DocScrutinizer05> modem violating the known GSM specs is clearly something fishy, so -> ALARM

22:56 <DocScrutinizer05> problematic is inbound data traffic, since it causes modem to ack that traffic even when it's not really meant to arrive at your eth0 interface (e.g. pings or similar stuff, or wring IP or whatever)

22:57 <DocScrutinizer05> but that obviously only can happen when modem is associated to an APN

22:57 <ZetaR> Right.

22:58 <DocScrutinizer05> and when it happens, you know what might be the cause and could still check

22:58 <ZetaR> Is it possible to write to the modem firmware remotely, to your knowledge?

22:59 <DocScrutinizer05> with Neo900 you at least get to know about such events, with any other phone you wouldn't even realize

22:59 <DocScrutinizer05> yes, absolutely

22:59 <DocScrutinizer05> afaik all modems have an OTA-update option nowadays

22:59 <ZetaR> Can the user overwrite this using a firmware update utility, then?

23:00 <DocScrutinizer05> yes, you could reflash the original firmware

23:00 <ZetaR> Okay, good. So if you have "banal" misbehavior, you can always fall back on reflashing the firmware.

23:00 <DocScrutinizer05> though, you never have a warranty which firmware *really* is running on modem

23:01 <DocScrutinizer05> and just because of this simple fact, we don't trust *any* modem firmware

23:01 <ZetaR> Well, I think we require a "good faith" assumption as far as hardware implementation goes. e.g. they can be forced to push firmware OTA, but it is not designed to secretly prevent reflashing.

23:02 <DocScrutinizer05> we rather supervise it and detect rogue or strange behavior

23:02 <DocScrutinizer05> it doesn't make any difference. The original firmware is as potentially rogue as the pushed new one

23:02 <ZetaR> This is true, but without a procedure for recovery the attacker can make it a choice between treating your modem as bricked and using an insecure modem.

23:03 <DocScrutinizer05> the modem *is* insecure

23:03 <DocScrutinizer05> *always*

23:03 <DocScrutinizer05> and we don't treat it as bricked, we treat it as suspicious / rogue

23:03 <DocScrutinizer05> always

23:04 <DocScrutinizer05> we don't hope for a good modem firmware behaving, we simply monitor it all the time

23:05 <DocScrutinizer05> when it doesn't, you know somebody might have attacked you. This doesn't "brick" the modem, since the modem integration and sandboxing is still as safe and secure as it been designed

23:05 <ZetaR> Yes, I realize this, but my concern was specifically pertaining to causing "banal" (uninteresting) misbehaviors as a social engineering attack, and the user not having a recourse to prevent those headaches.

23:06 <DocScrutinizer05> there's no such thing

23:06 <ZetaR> If the original firmware is tested and does not have banal misbehaviors, then the user can always reflash that firmware to prevent it.

23:06 <DocScrutinizer05> *shrug*

23:07 <DocScrutinizer05> there ARE NOT banal misbehaviors

23:07 <DocScrutinizer05> every misbehavior is a misbehavior

23:07 <ZetaR> Yes, I need to pick a different word... I understand that. I am having trouble explaining myself.

23:07 <DocScrutinizer05> and it has a reason

23:08 <DocScrutinizer05> and you prolly can't stop the reason, but you can know it exists and that's your joker

23:08 <DocScrutinizer05> the modem itself cannot go rogue more than we already assume it is

23:09 <DocScrutinizer05> actually such misbehaviors are as rogue as it gets, regading modem (well except maybe when it redirects all calls to a proxy of some TLA)

23:11 <DocScrutinizer05> then otoh what could you possibly do against them intercepting your calls, no matter if by redirecting to a proxy phonenumber or by less harsh more sophisticated means

23:11 <ZetaR> What I was trying to say is: there seems to be an assumption that the modem will not make itself "irritating" because of rogue firmware, and that the user should be able to fall back on a known non-irritating possibly-rogue firmware. But as you explained above, it should be possible to reflash to prevent "irritating" rogue firmware.

23:12 <DocScrutinizer05> again, 'irritating' is worst case

23:12 <ZetaR> Right.

23:12 <DocScrutinizer05> and when they did that once, they can do it twice

23:12 <ZetaR> Of course.

23:13 <DocScrutinizer05> A) define your exploits you are concerned about. B) consider what you can do to avoid them

23:14 <DocScrutinizer05> the exploit, the ONLY exploit they could inject into modem is making it send when it shouldn't

23:15 <DocScrutinizer05> they have no chance to access your local storage on Neo900, unlike any existing android phone out there

23:15 <DocScrutinizer05> they can't turn your phone into an eavesdropping device either

23:15 <DocScrutinizer05> again unlike... (see above)

23:16 <ZetaR> Yes, you have answered my main concerns: that misbehavior is probably malicious and not banal, and that reflash is possible to at least try to correct it.

23:16 <ZetaR> Thanks for the explanations.

23:17 <DocScrutinizer05> it's highly questionable if reflashing would help

23:17 <DocScrutinizer05> most probably any OTA exploit would be tenporary and get "deinstalled" by simply powercycling the modem

23:17 <ZetaR> Sorry, I have to go AFK for a bit. I will think about what you said.

23:18 <DocScrutinizer05> cya later then