Thread: Jolla - alike, or how Jolla adopted the Google's anti-open-source practices.
View Single Post
marmistrz is offline marmistrz
2018-02-09 , 15:32
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#37
Originally Posted by deprecated View Post
Meanwhile, run a tcpdump and look for suspect connections. Trace them back to their source and prove that the packets contain any data that violates Jolla's privacy policy, then I'll start to subscribe to your conspiracy theory.
Playing the devil's advocate a little here for the whole post.

Are you sure that your model covers all computationally-bounded adversaries?

There's a lot of potential scenarios that are not so naive.
Actually, the naive approach is a really stupid one. If the software is sending some data all the time, the user may notice extraordinary consumption of mobile data. Even on wifi this may be relatively easy to track.

A clever adversary will filter the gathered data - based on keywords, on the content. Upload it to the remote side only when there's something really big found.

The adversary may wait for a remote signal to start sending the data gathered. If there's no signal to upload the data, they may even discard it.

If the adversary is the store application - it may disguise the traffic by intertwining it with real, legitimate traffic - e.g. base64 encode it, split into chunks, add to the payload, recover back at the remote side.

The adversary may wait with uploading anything until anything worth uploading, and when the damage done is unrecoverable. E.g. when it finds a bitcoin wallet worth over X BTC.

The only way to prove that this can't be done is to examine the source code - or reverse engineer it. I do not claim this is actually done - but possibly can, and invisible source makes it much easier to hide rogue intentions.

More on the point, though, the vast majority of closed bits on Sailfish are the UX and arbitration using Android device drivers.

I don't think the bits like Alien Dalvik, Exchange support or XT9 should be counted, as they're licensed from third parties. Jolla open sourcing someone else's work after leasing it from them just doesn't make sense
IMHO cjk input on Jolla should not depend on proprietary bits, seeing how good the open-source building blocks are. Keyboard is one of the most delicate areas when it comes to security, that's the perfect place to place a keylogger, and from what I've heard, the cjk input bits are binary .so libraries.

If you've a problem with unauditable code or proprietary binary blobs, I have some bad news for you:

Anything you use day-to-day has arbitrary code that isn't open to public scrutiny, unless you have the good fortune to own one of a handful of older Thinkpads (or a select few other notebooks) or some one-off smartphone with a fabled open baseband.
You seem to forget one thing. It's much, much more difficult to exploit the firmware without userland support than to do that directly in userland (example, let's stick to the keyboard apps: it's much easier to write a keylogger in the keyboard app than in the CPU firmware)
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 5 Users Say Thank You to marmistrz For This Useful Post: