Will MeeGo be as hack friendly?

[Rapparee]

Will MeeGo be as "hackable" as Maemo, will we still have the extras dev to play in? Is it still completely open? Will this turn into a buy everything device?

[conny]

Yes. Yes. No :)

[HtheB]

Will this turn into a buy everything device?

What do you mean by that? :confused:

[xerome]

Think he means if we'd have to pay for almost every service on the phone. I'm sure some apps will be free like those on OVI store right now. Being a cheapo bugger however, i'm also interested in how 'hackable' Maemo will be as compared to symbian XD

[shadowjk]

I think the answer is "it depends". MeeGo in itself is open and hackable. However, device vendors could very well take meego and put it on a "TiVoized" device, making it unhackable..

[qgil]

Maemo and Moblin are beloved operating systems for mobile hackers and MeeGo will acquire and expand that heritage.

Even if vendors will be able to limit the openness of their devices, it is expected to have always a choice of fully open MeeGo devices, including devices sold by Nokia.

[jaem]

I might also add (and I think I've said elsewhere) that even if other manufacturers TiVo-ize it, we're still likely better off than most of what's out there now... Anything can in theory be cracked, given enough time, and unless they do something really outrageous to it, once you have full root access, it's still Linux, and you could probably just gut all their junk. For that matter, to my understanding, MeeGo requires (or at least encourages) open source drivers, which makes things a lot easier.
But yeah, Nokia seems pretty committed to Openness themselves, which is awesome.

[mannakiosk]

Will MeeGo be as "hackable" as Maemo, will we still have the extras dev to play in? Is it still completely open? Will this turn into a buy everything device?

It's so much hack friendly that hacking is infact the only thing you can do with it, at the time being... :)

[Laughing Man]

Considering the rumors of some of the DRM implementation in Maemo 6/Harmattan, I'm not so sure. Seems like you were going have to choose between having a free open-hackable device and a semi-hackable device (e.g. no kernel modifications if you wanted to keep the access to DRM files).

[Master of Gizmo]

Maemo and Moblin are beloved operating systems for mobile hackers and MeeGo will acquire and expand that heritage.

Even if vendors will be able to limit the openness of their devices, it is expected to have always a choice of fully open MeeGo devices, including devices sold by Nokia.

I wonder how MeeGo is supposed to be able to fulfil that. From speaking with Intel reps one of the key features of meego is security (which defintely is a point where maemo is extremely weak). And in order to protect the users content from malicious apps but also to implement DRM/content protection, they plan to install a crypto/authentication framework.

However, i see two problems in doing that:

a) the GPLv3 (which MeeGo imho uses with gstreamer) prevents you from using encryption to protect your business modell. How is this supposed to work?

b) Of course such a framework limits the hackability. A device cannot be completely open on one side and protect user data as well as multimedia content on the other side.

So will we have to jailbreak the next gen devices? Will the average user still have a method to get root access without removing/lossing vital parts?

This sounds like the same problem Sony solves on the PS3 by removing the "OtherOS" option: You cannot allow people to openly tinker with a unit that carries information that you don't want them to tinker with.

[qgil]

The MeeGo Security framework (which is what was called Maemo 6 Security Framework) is highly configurable. It's up to the device vendor to define the level of openness of a device and it's up to the customers to buy a device with the desired levels of openness.

No matter what, MeeGo will fulfill the requirements of the licenses of the components integrated.

[johnel]

As far as I understand there are 2 installable images of n900 MeeGo.

(1) The closed image - (includes BME, wifi & bluetooth firmware)

(2) The open image - does not include the above components.

The open image can be installed on the n900 but you may damage the device due to the lack of battery management (no BME).

But you can install the open image on a virtual device and use it as a development environment.

The only realistic decision is to install the closed image to the n900.

The open image can be freely distributed by the closed image cannot?

I'm fine with that.

However if I wanted to create a custom image for the n900 I can do that but I would have to exclude the closed components.

Are the components seperate enough so I can build a custom image on the n900 and install the closed components too?

Will these components ever be "open source". I understand that there may be patent, third-party license and/or distribution issues too. But until these components are open-source then I don't think the MeeGo platform (as regads to the n900) can be considered open-source.

Am I just being really "picky" about this. I'm not an open-source zealot but I would feel a lot better if these components were "freely" available. I would even settle for unrestricted re-distributable firmware blobs and battery-manger binary.

I've had my fingers burnt before with stuff like this (ATI drivers now legacy - no longer work with newer versions of Xorg)

[dov]

Considering the rumors of some of the DRM implementation in Maemo 6/Harmattan, I'm not so sure. Seems like you were going have to choose between having a free open-hackable device and a semi-hackable device (e.g. no kernel modifications if you wanted to keep the access to DRM files).

It's more than rumors. See:

http://lwn.net/Articles/373780/

[attila77]

The MeeGo Security framework (which is what was called Maemo 6 Security Framework) is highly configurable. It's up to the device vendor to define the level of openness of a device and it's up to the customers to buy a device with the desired levels of openness.

No matter what, MeeGo will fulfill the requirements of the licenses of the components integrated.

I know this is more of a meego.com question, but how does this relate to the Intel counterparts ? The Maemo 6 Security Framework was in good part based on TrustZone, which is AFAIK an ARM specific technology (=not present on the Intel counterparts). Still confused :confused:

[Stskeeps]

As far as I understand there are 2 However if I wanted to create a custom image for the n900 I can do that but I would have to exclude the closed components.

Are the components seperate enough so I can build a custom image on the n900 and install the closed components too?


You can make your own image with the closed components but currently not redistribute.

In the area where you grab closed images (after accepting EULA), there is a kickstart file with a auto-generated repository URL (unique to yourself, do not distribute at breach of EULA). This is same template which the closed image was built from

This repository contains the closed components (BME, wifi firmware, bt firmware, etc), so you can make your own images.

Even though this isn't open source, I'm personally happy cos we can grab the closed source parts with ease due to our ownership of the devices.

[Master of Gizmo]

No matter what, MeeGo will fulfill the requirements of the licenses of the components integrated.

How can a drm protection scheme fulfil the gplv3 requirements?

I have asked this question many times and the answer always was either "don't worry, everything will be ok" or "i just don't know". But i think this question deserves a real answer as it's not some proprietary nokia/intel code we are talking about.

[Master of Gizmo]

I might also add (and I think I've said elsewhere) that even if other manufacturers TiVo-ize it ...

They can't as the licenses explicitely forbid exactly that.

[javispedro]

Relevant GPL3 parts (extracted from http://www.gnu.org/licenses/gpl-3.0-standalone.html, emphasis mine):
A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.


From Maemo Security (http://wiki.maemo.org/Maemo_security#Can_open_applications_use_the_DRM_e ncryption_mechanisms_in_the_Open_and_Closed_modes. 3F) in the wiki:
(of course some content becomes unavailable when one switch to its own kernel, for example DRM)

So, dunno. I don't think the GPLv3 will allow for operators to sell devices where you cannot enter "open mode" (would violate the first bold statement), but Nokia might be allowed to disallow the download & use of DRM'd apps and media in "open mode" (might be allowed as per the second bold statement).

IANAL.

EDIT: Note that Open vs Closed mode in the Harmattan security framework at least has nothing to do with BME, etc. (those are "the closed components" and I'm pretty sure they will still be avail in "open mode", else the device would be useless).

[Master of Gizmo]

So, dunno. I don't think the GPLv3 will allow for operators to sell devices where you cannot enter "open mode" (would violate the first bold statement), but Nokia might be allowed to disallow the download & use of DRM'd apps and media in "open mode" (might be allowed as per the second bold statement).


To me it seems even more complex. The 1st highlighted paragraph imho reads: You have to allow people to tinker with the code and while doing so you are not allowed to disable certain functionality just because of the fact someone tinkered with it.

Otherwise the gplv3 would not be able to prevent tivoization (which was one of its primary goals). To avoid tivoization you must prevent manufacturers from disabling (service critical) components just because someone modified certain code. If you allow manufacturers to do so you again face the tivo issue: The device will just refuse to work after you uploaded new code.

Of course there's a difference between "not working at all anymore" and "doesn't play drm protected files anymore". But you cannot draw the line there as "evil" manufacturers will then draw the border whereever they like and e.g. tivo may still say "hey, hacked units still display the time. they just don't playback any files anymore. so no reason t complain".

Hightlight 2 imho has nothing to do with this. It imho only sais that nokia/intel do not have to provide any guarantee on the parts the hacker modified. Still as of highlight 1 they must not add artifical limitations to the part the hacker did not touch.

To me this means: I must be e.g. allowed to upload a new kernel (regardless of the mode the device is in). Furthermore they must not disable certain functions (e.g. decoding og drm protected files) just because they detect my modified kernel.

I still don't see how they could add drm in a hacking-prevented but still legal way.

[javispedro]

Hightlight 2 imho has nothing to do with this. It imho only sais that nokia/intel do not have to provide any guarantee on the parts the hacker modified. Still as of highlight 1 they must not add artifical limitations to the part the hacker did not touch.
Because I see DRMd files as downloaded (a "service" provided for a work "that has been modified by the client" -> no requirement). If anything, this forbids them to disallow you to access your already bought DRMd songs, but allows them to prevent you buying any new DRMd song. (Stuff gets more weirder when you think that a DRM might be implemented as a quick ping to an online server every time you try to play a "protected" material... god save us).

Clearly, this last clause is designed to help prevent cheaters from entering a multiplayer network (or stuff like that), but I see no difference between that and preventing freeloaders from entering a paid content network.

[qgil]

How can a drm protection scheme fulfil the gplv3 requirements?

I have asked this question many times and the answer always was either "don't worry, everything will be ok" or "i just don't know". But i think this question deserves a real answer as it's not some proprietary nokia/intel code we are talking about.

The first time you asked was in the Maemo Summit and the clear answer was that there is no software licensed with GPLv3 in Harmattan.

In MeeGo the use of GNU (L)GPL version 2.x is encouraged (http://meego.com/about/licensing-policy).

[Master of Gizmo]

The first time you asked was in the Maemo Summit and the clear answer was that there is no software licensed with GPLv3 in Harmattan.

Oh, i assumed that was just the state at that time and not by purpose. Elena on the other hand just had no idea what to answer and about the implications of the GPLv3.


In MeeGo the use of GNU (L)GPL version 2.x is encouraged (http://meego.com/about/licensing-policy).

That page does not mention that the intended limitation has anything to do with DRM etc. Also "encouraged" seems rather odd if the introduction of GPLv3 code will lock the resulting device out of any shop system (be it app stores or content stores) and will cut the user off some off his personal data stored on the device.

Android is an example of this. Any home-compiled/unofficial android version does not have access to the app stores and thus bascially nobody is using such versions except for demo purposes.

How will access of MeeGo devices to things like app stores be controlled? Sure "open" devices will not have access to any store (as they could otherwise just re-distribute any downloaded app).
How tight will the limits be for a MeeGo device? Who verifies that a MeeGo device can be trusted and is allowed access to the store infrastructure? What happened if i wanted to build a device myself? Or if i port MeeGo to some so-far unsupported plattform? Will the resulting "open" device be locked out of any app store? And do you still expect there to be a marked for "open" devices if they won't have shop access?

My concern is that the "open" path will just die. How many of the current n900 users would "close" their device if this would give them access to apps/drm stuff? And would the resulting two user groups still be big enough to survive independently?

[qgil]

Oh, i assumed that was just the state at that time and not by purpose. Elena on the other hand just had no idea what to answer and about the implications of the GPLv3.

She hesitated giving details about Harmattan content at that time. This is why Peter helped giving the answer. Of course Elena was aware about the implications of GPLv3, just like any Linux security expert is.

If you have questions about MeeGo licensing, security framework, etc meego-dev is the place to ask. In fact there was already something about GPLv3 some weeks ago.

For the rest, let me just insist that the security framework itself is not limiting, but the configuration each device vendor applies on it. If you don't like how open MeeGo device A is then go for MeeGo device B. If the problem is about app store A only delivering software for closed devices then choose another alternative.

My concern is that the "open" path will just die.

I'm not concerned. On the contrary, I think MeeGo pushes openness to the mobile industry and mainstream like no platform has done before. (I should be a person to be concerned about MeeGo openness since my paid job is quite related to it) :)

[ChoMar]

Just to clarify this a bit for myself (im having trouble understandig this whole thing) as an Enduser (no developer or anything)

- i will be able to install a fully functional Open MeeGo system. It will have some closed Components (Battery Management...) in it but it wont have DRM and stuff. Its just not Redistibutable.

- i will be able to install everything i want in this open environment (as long as it doesnt need the DRM-functions of the closed System)

- an open System will still be suported as much as possible and wont be "banned" because its "evil-communistic-terroristic" or anything. (like Jailbreaked i-Phones or hacked X-Boxes or Linuxusers)
Of course "as much as possible" is an importand part and widely defined. Could make an Answer a little bit difficult.