Lucian Tomuta's Forum Nokia Blog

My application doesn't contain malware !!! if it was this case, I thing that there will be a ton of infected phones just because they use FExplorer but nobody !! I was obliged to use the test UID because nobody could be sign it because of the new online signing process ...

OK, for the capabilities, when I had switched to the 3rd edition, I have no idea about this new "platform" and capabilities, that's the reason why I have selected all !!! but if you want, now, I can remove the capabilities that I don't need !! but be confident, the 3rd edition protection is "strong" and I don't access the part that I can't !!!

PS: I understand that this freeware is embarassing for some developpers who want to produce the same application to earn money (ie : non-free) ....

Don't panic !, if these capabilities are allowed *freely*, they are not stupid at symbian, it's just because there is no risk to use them ... I develop for more than 25 years and I have NO TIME to develop malware ....

Domi.

It's not really fair to brand Dominique Hugo a creator of malware without evidence of intent. It's also potentially Libellous (damaging to a developer's professional reputation). I suggest that you use the power of the internet to email Dominique personally if it bothers you so much.

In general, overstating capabilities is a common symptom of migrating applications to 3.x. It provides a quick way of making an application useful without having to spend an age debugging through your code, and as such is an understandable situation to be in. Particularly for freeware where there is little reward in rehashing the same old app for all fragmented platforms.

Clearly there is a problem with the deeply unpopular signing process.

For the most part, the devcert abuse is the pass of least resistance for freeware authors and useful debugging tools for developers. Nokia and Symbian need to make big improvements here.

>made an industry out of breaking the rules
There are no rules in security. An abuse must be patched and we welcome those who find flaws because it's the hidden flaws which pose the most threat.

Ok, I have people's attention. That is good.

This many years after the introduction of the Platform Security concepts it is difficult for me to accept lack of knowledge as defense argument. As for damaging one's reputation that is obviously not my intent, in fact all I did was to present a state of fact that can be verified on developer's web site.

And no, he is not alone. And yes, there are other applications that have the same problem. But this is why using Domi as an example, with hopefully the chance to also document how he fixed the mistake, would be a good lesson to learn for all developers.

Domi, you have missed the point, I'm not accusing your application of being a malware once installed on end-user's phone. Your application, through its release mechanism, is causing harm to developers. The application released by you contributed, together with the others, in creating a DoS attack on Symbian Signed. And that is malware, whether intentional or not.

As said already, I really like your application, I've been using it a lot. Symbian Signed recommended it to developers to help in their application testing. So the value is recognized but we need to also recognize mistakes and fix them. However, as you know there are other applications like yours on the market, either self-signed or Symbian Signed for Freeware. There might also be commercial applications like that but that's certainly not my concern.

So, fix your release and I'll be happy to promote your application. In fact I already did, since I believe I've spelled the name correctly and that's the only thing that matters whether you get good press or bad press. :)

@Twmd, you are right, the Symbian Signed process is to blame for some of the problems developers have. More on that to follow. My point here is that while breaking the rules developers are risking to make their like more difficult, see the Open Signed Online process.

Nice timing, if I remember right next week it's my turn to be expert and the topic is Platform security, i welcome all questions, and try to provide answers & links to self study materials.

anyway, I think I have proven quite well, that file managers do not necessarily require any additional capabilties. And also that you can do quite a lot with capabilties allowed for self-signing.

Don't know about this version, but old FExplorer was also able to kill processes and tasks - sometimes necessary when developing.
For that you need PowerManagement capability.

So FExplorer is now blamed for irratical behaviour of the Symbian Signed server? It either shows very high popularity of this app or really bad server configuration

Humm ....

after reading that :
https://www.symbiansigned.com/app/page/public/openSignedOnline.do ,symbian seems to accept test range without restriction (point 5) !

I can suppress some capabilities but in such way, use the basis filebrowser proposed by forum.nokia as sources without any tool and my app is dead !

Domi.

I have a lot of sympathy for ltomuta's perspective here. The Symbian Signed process is quite complicated but it's not THAT complicated. Anyone capable of programming for Symbian is capable of understanding the process and following it properly.

The question is, why should they? Particularly a freeware developer - what is their incentive for doing things the way Symbian Signed wants them too?

A security system (and that includes the signing part, not just the actual security software on the phone) that relies on ALL the developers behaving in a certain way is a BADLY DESIGNED SYSTEM.

FExplorer is a tool for developers and power users. They are sophisticated enough to accept beta-level software with quirks and bugs. They don't care at all if it passes some quality critera as long as it does what they want it to do.

There is no way that FExplorer should be distrubuted on something like the Nokia download client but I really don't see a great threat to the security of phones everywhere if it is signed so that anyone who wants can download and install it.

Perhaps we need something like "beta-signed" that gives a warning much like the old dev cert warning on install but is not restricted on IMEI. If it uses the same mechanism as open signed then Symbian Signed can still refuse to sign some applications (if they are suspected cracked or suspicious in some way).

Mark

Yes, and they are actually wrong on doing that but I will blog about this later. I am also giving them some time to correct themselves ...

If you want to release the application with powerful features (and capabilities) that do that, release it. With proper certification however, either as freeware or commercial (that is, you pay for testing and then give it for free if you want so).

For a very timely coincidence, have a look at this article... it seems that not knowing exactly which capabilities to assign to an EXE is not exclusive to 3rd party developers... ;-)

http://www.newlc.com/peek-inside-n-gage-first-access-sis-file

Scroll down to "Capabilities of binaries" and weep. :-)

@Sorcery-ltd: Good points. But the definition of freeware might deserve a separate discussion.

@mgroeber9110: No surprise for me. :(

It's all about design. Of course, as an insider, you think that it's easy to learn about platform security, and that all developers should have learned about it by now. But most developers tend to learn just as much as is needed to get their code to run. If they're not interested in your platform security concept, they'll ignore it as long as they can. As Sorcery-ltd pointed out, they have no interest in it.

I learned about platform security the hard way, back when it was being introduced, and the documentation was fragmented, incomplete and inconsistent. I really wanted to understand it all, so I got the platsec book and read it, but lots of my questions were still unanswered, so I had to go with what just happened to work in lots of cases. Well, what can you do? It was a commercial product, and no one in their right mind would hold off releasing it, because we weren't sure if we had managed to understand the whole platform security architecture correctly.

So I have a lot of sympathy for anyone who just doesn't want to be bothered with platform security. Most developers just want to get their code running. Jeepy obviously fits in this category. As do the N-Gage developers at Nokia. Platform security is not perfect from a usability perspective. Pointing the finger at developers who don't have the time and energy to learn about another set of massive infrastructure might seem like a good idea, but there's a risk that it'll alienate as many as it'll teach a lesson.

I am an insider and I can sign my applications with an all powerful devcert. But when I start developing I delete even the ReadUserData capability that the Carbide.c++ template adds to the new project by default. I start with None and if the program will need a capability I will add it, once I understand why is needed. I can start with "ALL -TCB" but what would I learn/gain from that?

I have not said that things are perfect. I might find at runtime that I have not enough capabilities but I don't simply add more/all but rather try to understand what happens and why.

Does this make life more complicated? Not at all. KErrPermisionDenied is just another error one has to debug and solve, and it is definitely easier to fix than a random KErrGeneral or KErrNotFound.

And speaking of quick fixes and lack of incentives, how many of you use User::Exit(0) in your code rather than fixing that annoying memory leak? How many of you use destructors at all? There's no incentive for doing that either, is there?

Of course the big problem for an independent developer is getting the app signed when it needs more than basic capabilities. But this problem should not be ignored just because there seems to be a workaround for it. Not when the workaround sucks for you and for your customer. Not when the workaround is an obvious mistake screaming to be fixed.

As for alienating developers, I don't think there's a risk of that. They won't mind a weird dude obsessed with a romantic notion of fair-play.
Of course there might be an accident and somebody could say "Thank you!". But if you hear that just ignore it, it is probably a friend of mine. ;)

Best regards,
Lucian

I think that symbian want to kill the developers of freeware with their process, I'm not against security but not too much ... I would really want their opinion but I don't know that symbian would directly participate to this thread ...

Cheers,
Domi.

@Lucian, I think it's very commendable that you're making such an effort to encourage people to play by the rules. Perhaps I'm just too cynical but I think it's futile. As currently designed the system requires almost everyone to play by the rules. If that were the case in life then we would never have needed platform security in the first place!

I share your romantic notion of a better world where we all work together to make things easier for everyone... I just think we're such a long way from getting there that pragmatism suggests a rather less idealistic solution.

@Domi, I'm sure Symbian would love to have the largest freeware developer community of any platform in the world. It would add immense value to their offering. However, some of the largest stakeholders are network operators and they're scared about the platform being too open. They don't want their networks broken, or a million customer service calls a day dealing with problems caused by 3rd party applications. Symbian signed representatives have indeed responded on other blog discussion threads elsewhere in the past. They're trying their best to make it work for everyone - I guess the people that pay the bills get top priority though.