| 00:28.09 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
| 00:38.26 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 00:51.59 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 01:14.20 | *** join/#neo900 Humpelst1lzchen (erik@f054180233.adsl.alicedsl.de) |
| 02:51.54 | *** join/#neo900 mordac (~mordac@blowfish.protoc.org) |
| 02:57.29 | *** part/#neo900 mordac (~mordac@blowfish.protoc.org) |
| 03:36.43 | *** join/#neo900 xes_ (~xes@unaffiliated/xes) |
| 05:19.51 | *** join/#neo900 Oksana (~chatzilla@Maemo/community/council/Wikiwide) |
| 05:58.51 | *** join/#neo900 lobito1 (~lobito@97-123-231-201.fibertel.com.ar) |
| 06:00.48 | *** join/#neo900 trx (ns-team@devbin/founder/trx) |
| 06:14.21 | *** part/#neo900 lobito1 (~lobito@97-123-231-201.fibertel.com.ar) |
| 07:25.10 | *** join/#neo900 freemangordon_ (~ivo@213.222.56.174) |
| 07:28.38 | *** join/#neo900 ecloud (quassel@nat/digia/x-xyumkcaiagapfyfi) |
| 07:32.45 | *** join/#neo900 trx (ns-team@devbin/founder/trx) |
| 08:10.39 | *** join/#neo900 modem (~modem@fsf/member/modem) |
| 08:34.47 | enyc_ | MonkeyofDoom: oooh thats useful to know armhf chroot works =) |
| 09:03.48 | *** join/#neo900 mvaenskae (~mvaenskae@vpn-global-014-dhcp.ethz.ch) |
| 09:07.13 | *** join/#neo900 freemangordon_ (~ivo@213.222.56.174) |
| 09:16.53 | 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.02 | 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 =) |
| 09:58.17 | *** join/#neo900 j (c3103452@gateway/web/freenode/ip.195.16.52.82) |
| 11:09.12 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
| 12:17.38 | *** join/#neo900 antiatom (~ilse@91.214.169.69) |
| 12:46.49 | *** join/#neo900 Kabouik (~quassel@147.99.219.229) |
| 12:53.31 | *** join/#neo900 che1 (~che@o159.tum.vpn.lrz.de) |
| 13:13.37 | *** join/#neo900 rjeffries (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 14:01.10 | *** join/#neo900 louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 14:06.30 | *** join/#neo900 lobito (~lobito@190.177.196.70) |
| 14:12.13 | *** join/#neo900 cybiko123 (~cybiko123@c-50-165-68-200.hsd1.il.comcast.net) |
| 14:12.43 | *** join/#neo900 cybiko123 (~cybiko123@c-50-165-68-200.hsd1.il.comcast.net) |
| 14:12.45 | *** join/#neo900 cybiko123 (~cybiko123@unaffiliated/cybiko123) |
| 14:31.02 | *** join/#neo900 lobito (~lobito@190.177.196.70) |
| 16:04.08 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 16:20.48 | *** join/#neo900 Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 16:40.59 | *** join/#neo900 lobito (~lobito@190.177.196.70) |
| 17:25.20 | *** join/#neo900 HylianSavior (~mafuyu@2607:5600:c6:1d::3d64) |
| 17:49.57 | *** join/#neo900 cybiko123 (~cybiko123@c-50-165-68-200.hsd1.il.comcast.net) |
| 17:50.05 | *** join/#neo900 cybiko123 (~cybiko123@unaffiliated/cybiko123) |
| 17:56.02 | *** join/#neo900 silviof (~silviof@unaffiliated/silviof) |
| 18:01.43 | *** join/#neo900 lobito1 (~lobito@190.177.214.223) |
| 18:06.37 | *** join/#neo900 lobito (~lobito@190.177.192.156) |
| 18:10.43 | *** join/#neo900 lobito1 (~lobito@190.177.197.170) |
| 18:15.24 | *** join/#neo900 paulk-aldrin (~paulk@armstrong.paulk.fr) |
| 18:48.41 | *** join/#neo900 silviof (~silviof@unaffiliated/silviof) |
| 19:04.53 | *** join/#neo900 sparetire_ (~sparetire@unaffiliated/sparetire) |
| 20:15.26 | *** join/#neo900 arcean (~arcean@nat3.finemedia.pl) |
| 20:22.13 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 20:27.04 | DocScrutinizer05 | background: http://www.forbes.com/sites/ewanspence/2015/07/14/nokia-android-smartphone-plans/ |
| 21:28.23 | *** join/#neo900 louisdk (~louisdk@94.144.63.225) |
| 21:54.51 | *** join/#neo900 louisdk (~louisdk@94.144.63.225) |
| 22:04.52 | enyc | DocScrutinizer05: oooh useful publicity sensible? |
| 22:05.28 | DocScrutinizer05 | sorry? |
| 22:05.36 | enyc | DocScrutinizer05: i see all the mentioses of ccc.de and otherwise |
| 22:05.44 | enyc | DocScrutinizer05: is this trying to get more publicity/interest in neo900 ? |
| 22:06.06 | *** join/#neo900 louisdk (~louisdk@94.144.63.228) |
| 22:06.50 | 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.50 | 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.19 | DocScrutinizer05 | the remaining tasks are pretty simple: build it |
| 22:08.40 | DocScrutinizer05 | the blocker: get more preorders |
| 22:08.52 | 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.58 | enyc | DocScrutinizer05: and be 'workable' / 'usable' |
| 22:09.25 | DocScrutinizer05 | see neo900.org |
| 22:09.34 | 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.52 | DocScrutinizer05 | I don't know what to present to you to convince you |
| 22:11.15 | enyc | DocScrutinizer05: i'm not sut atlking about me... but anybody who hasn't been following in great detail |
| 22:11.26 | DocScrutinizer05 | so? |
| 22:11.34 | enyc | DocScrutinizer05: underpinng steps, how many more board respins, realistic estimate of remanintg tasks and time |
| 22:12.13 | 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.35 | 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.36 | DocScrutinizer05 | please read about all that in http://talk.maemo.org/showthread.php?t=91142 and http://neo900.org/ |
| 22:19.45 | 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.22 | 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.08 | *** join/#neo900 louisdk (~louisdk@94.144.63.228) |
| 22:23.54 | 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.12 | DocScrutinizer05 | proto_v2: get a "working device" with core system (CPU, RAM, storage and power) on attached BB-xM |
| 22:25.55 | DocScrutinizer05 | proto_v3: integrate core system into proto_v2 board and evaluate for production |
| 22:26.07 | 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.08 | 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.22 | enyc | nodsnods |
| 22:31.24 | DocScrutinizer05 | we checked so much now, I'm almost sure we will have a working proto_v2 already, on first spin |
| 22:31.42 | 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.58 | DocScrutinizer05 | ilon: ^^^ |
| 22:33.04 | DocScrutinizer05 | dos1: ^^^ |
| 22:36.48 | DocScrutinizer05 | ilon: dos1: wpwrak: we also _need_ to send reminder mails now |
| 22:37.28 | enyc | DocScrutinizer05: thankyou... for taking on board ... trying to be helpful here considering from a different pov... |
| 22:37.46 | DocScrutinizer05 | thanks a lot! :-) |
| 22:39.36 | *** join/#neo900 louisdk (~louisdk@94.144.63.228) |
| 22:41.04 | 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.48 | 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.44 | DocScrutinizer05 | sorry, I can't follow |
| 22:48.39 | DocScrutinizer05 | aaah, maybe I get the idea |
| 22:49.18 | DocScrutinizer05 | well, it's not our decision how users react on atypical behavior of modem |
| 22:49.45 | 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.09 | 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.27 | 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.42 | DocScrutinizer05 | yes |
| 22:52.39 | 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.45 | 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.13 | ZetaR | Is this by government regulation, or just industry best practice? |
| 22:54.26 | DocScrutinizer05 | this is GSM operation specs |
| 22:54.38 | ZetaR | Ah, okay. That is good. |
| 22:55.25 | DocScrutinizer05 | modem violating the known GSM specs is clearly something fishy, so -> ALARM |
| 22:56.42 | 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.28 | DocScrutinizer05 | but that obviously only can happen when modem is associated to an APN |
| 22:57.41 | ZetaR | Right. |
| 22:58.10 | DocScrutinizer05 | and when it happens, you know what might be the cause and could still check |
| 22:58.58 | ZetaR | Is it possible to write to the modem firmware remotely, to your knowledge? |
| 22:59.07 | DocScrutinizer05 | with Neo900 you at least get to know about such events, with any other phone you wouldn't even realize |
| 22:59.18 | DocScrutinizer05 | yes, absolutely |
| 22:59.52 | DocScrutinizer05 | afaik all modems have an OTA-update option nowadays |
| 22:59.54 | ZetaR | Can the user overwrite this using a firmware update utility, then? |
| 23:00.17 | DocScrutinizer05 | yes, you could reflash the original firmware |
| 23:00.41 | ZetaR | Okay, good. So if you have "banal" misbehavior, you can always fall back on reflashing the firmware. |
| 23:00.49 | DocScrutinizer05 | though, you never have a warranty which firmware *really* is running on modem |
| 23:01.21 | DocScrutinizer05 | and just because of this simple fact, we don't trust *any* modem firmware |
| 23:01.53 | *** join/#neo900 arossdotme (~zxy@79-69-205-125.dynamic.dsl.as9105.com) |
| 23:01.55 | 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.02 | DocScrutinizer05 | we rather supervise it and detect rogue or strange behavior |
| 23:02.51 | DocScrutinizer05 | it doesn't make any difference. The original firmware is as potentially rogue as the pushed new one |
| 23:02.57 | 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.16 | DocScrutinizer05 | the modem *is* insecure |
| 23:03.21 | DocScrutinizer05 | *always* |
| 23:03.50 | DocScrutinizer05 | and we don't treat it as bricked, we treat it as suspicious / rogue |
| 23:03.55 | DocScrutinizer05 | always |
| 23:04.34 | DocScrutinizer05 | we don't hope for a good modem firmware behaving, we simply monitor it all the time |
| 23:04.44 | *** join/#neo900 arossdotme-nolog (~zxy@79-69-205-125.dynamic.dsl.as9105.com) |
| 23:05.31 | 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.32 | 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.04 | DocScrutinizer05 | there's no such thing |
| 23:06.25 | 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.32 | *** join/#neo900 lobito (~lobito@190.177.208.182) |
| 23:06.45 | DocScrutinizer05 | *shrug* |
| 23:07.10 | DocScrutinizer05 | there ARE NOT banal misbehaviors |
| 23:07.31 | DocScrutinizer05 | every misbehavior is a misbehavior |
| 23:07.37 | ZetaR | Yes, I need to pick a different word... I understand that. I am having trouble explaining myself. |
| 23:07.39 | DocScrutinizer05 | and it has a reason |
| 23:08.08 | DocScrutinizer05 | and you prolly can't stop the reason, but you can know it exists and that's your joker |
| 23:08.37 | DocScrutinizer05 | the modem itself cannot go rogue more than we already assume it is |
| 23:09.51 | 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.16 | 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.18 | 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.04 | DocScrutinizer05 | again, 'irritating' is worst case |
| 23:12.11 | ZetaR | Right. |
| 23:12.32 | DocScrutinizer05 | and when they did that once, they can do it twice |
| 23:12.41 | ZetaR | Of course. |
| 23:13.35 | DocScrutinizer05 | A) define your exploits you are concerned about. B) consider what you can do to avoid them |
| 23:14.21 | DocScrutinizer05 | the exploit, the ONLY exploit they could inject into modem is making it send when it shouldn't |
| 23:15.11 | DocScrutinizer05 | they have no chance to access your local storage on Neo900, unlike any existing android phone out there |
| 23:15.33 | DocScrutinizer05 | they can't turn your phone into an eavesdropping device either |
| 23:15.48 | DocScrutinizer05 | again unlike... (see above) |
| 23:16.05 | 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.57 | ZetaR | Thanks for the explanations. |
| 23:17.03 | DocScrutinizer05 | it's highly questionable if reflashing would help |
| 23:17.42 | DocScrutinizer05 | most probably any OTA exploit would be tenporary and get "deinstalled" by simply powercycling the modem |
| 23:17.50 | ZetaR | Sorry, I have to go AFK for a bit. I will think about what you said. |
| 23:18.36 | DocScrutinizer05 | cya later then |
| 23:18.59 | *** join/#neo900 louisdk (~louisdk@94.144.63.228) |
| 23:30.01 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 23:37.12 | *** join/#neo900 vakkov (~vakkov@84.54.169.227) |