How would those who are opposed to DRM ensure that artists will get just compensation for their works if there are no mechanisms to prevent someone from simply digitally copying a work (be it music, movie or book) and giving it away to anyone who wants it?

If it were me, I would:

• Give the people who pay for a legitimate license for the work something that is of value to them, but costs you nothing.
• Don't artificially increase the cost of distributing works.
• Allow people to copy the work, and reward them for licensing it
• Ensure that nothing besides access to the file storing the content is required for enjoying the work.
• Build in some features to validate the authenticity of the work.
• Allow the user to backup just the signatures

For example, in a container format that supports separate streams and meta-data, store an x.509 certificate or PGP signature by a licensing representative of the artist of the content's digest/hash and the customer's details (e.g. name).

Have playback/display software show the content that has such a signature differently, e.g. a badge with the customer's details from the signature.

Allow a user who has copied the content from someone else to buy just a license for the content, and all you need to do is:

• Vlidate the hash of the content to ensure they have the copy you want them to have
• Issue a new cert/signature

Of course, some changes to media consumption software would be required to support this model.

I would definitely be motivated to license more of the works I have copied if it was easy, didn't require downloading new versions, and had something more attractive to me. There is currently almost nothing to distinguish works I have paid for from ones I haven't (except that I store them separately). For most users, the only distinguishing factor is that the one they haven't paid for is easier to use.

1)PasswordAuthentication no

(One of the reasons to use keys is to avoid password cracking, and/or enforce two-factor/multi-factor authentication/authorizaion in conjunction with sudo or a VPN or similar)

2)AuthorizedKeysFile /etc/ssh/keys/%u.pub

(Many security frameworks don't allow non-administrative users to have full control over keys, as this can lead to abuse, such as a member of the dba group, who can run certain commands as the oracle user with auditing, giving him/herself unrestricted/unaudited access to the oracle user account. Another example is if there are restrictions in the aurhorized keys entry, such as forced command, or sources that can use the key via 'from', 'no-port-forwarding', etc. etc. that should not be under the user's control )

We have historically used the LPK patch to OpenSSH, and we are transitioning to the AuthorizedKeysCommand feature, and have the two configurations above on all our production servers. Before the LPK patch, it was a non-trivial effort to add new users. I guess these days, puppet or chef would be other options too.

FreeIPA and SSSD are not required.

Just OpenSSH with either the LPK patch, or the AuthorizedKeysCommand patch, or OpenSSH 6.2 or later.

I have been using ssh keys in LDAP since 2004, with OpenLDAP. FreeIPA, and its dependency on 389/RHDS (specific, non-standard features of 389/RHDS have been built into IPA, whereas many other web interfaces for LDAP have solutions to the same problems which don't rely on proprietary RHDS features) is unnecessary.

You can develop for all of those platforms with the toolkit that is native to Jolla, Qt.

You'll still have issues with app stores though.

In South Africa, if you claim for a stolen phone, the insurance company will request the IMEI as part of their claim processing, and they will have the IMEI blacklisted on a database shared by all the local mobile operators.

Are you saying that it is impossible for anyone to use the information in your fb and gmail account to compromise your bank website account?

By the same token, I shouldn't be expected to use non-company resources (ADSL line for remote standby support, personal smartphone reading company mail) for business purposes.

Or we can come to a compromise, and all be adults.

But it got nowhere near the kind of marketing Lumia has had. Not even the N9 had anything close to what Lumia is getting (and it wasn't even sold in most first world countries), yet it made similar sales numbers.

/me raises hand ... I still can't settle on anything that would suit me better than my N900.

Or, if you lived in a different country, where Apple does not have rights to distribute it

Note that in most other countries (outside North America, and possibly the UK), there is *no* legal way to download TV shows. No TV shows on iTunes. No Netflix, no Hulu, no content available on Amazon.

You would think the production houses would have figured out that the same technology which allows a few people to distribute large content to millions of people around the world for very low costs would allow them to reach their customers directly, without many different 'distribution' companies, license agreements, thousands of lawyers (or the Apple 30% tax), and allow them to both serve the customers better, understand what the customers are prepared to pay for, all allowing them to make more money.

Why don't they just run private trackers and RSS feeds with subscriptions available per-season, in the $1 to $3 per show range?

Or rsnapshot

pageant(from PuTTY) works adequately. But, the combination of an ssh-agent and bash-completion is still difficult to achieve without actually having bash (e.g. from mingw32), and using plink (to run commands remotely once-off) and pscp are less convenient, and you lose out on all the programs that use ssh as a transport.

if the third party is your own Root CA, then it does make sense. For example, I can issue a new cert on the mail server (for whatever reason), without the users all needing to accept a self-signed cert and cultivate bad security habits.

Maybe you need to think about the 'Trusted 3rd party' a bit more, specifically comparing SSL/PKI with Kerberos. Without a trusted third party, how are you supposed to do the initial authentication you speak of? Do all your users actually check SSL certificate fingerprints every time you point them at a service using 'first party public keys' (SSL certificates are public/private, and the SSL client gets the public key during negotiation)?

And the old cert that someone stole is still valid, if they manage to redirect users to a system they control that has the old cert, your users will think it is the valid one, and the real one is the fake one, and you've just compromised all your users credentials.

I hope you don't store any personal data.

You know there's a difference between using self-signed certs, and an internal CA, right?

(of course, all root CA certs are self-signed, intermediary CA certs are not, but the distinction being, you usually don't use the self-signed cert itself for anything but signing other certs).

Using your own internal CA (which you can either do by getting a commercial CA cert signed by a commercial root CA cert, or by creating your own self-signed CA cert) to authenticate/certify your internal services is good. Using self-signed certs to secure your services usually does nothing to authenticate the service to the end user, if they aren't verifying the cert fingerprints via some other method.

Well, in actual fact, nothing prevents software from allowing the user more control of validation of certificates. For example, nothing is stopping software from storing the fingerprints, and notifying the user when the fingerprint has changed, even for certificates signed by a trusted CA. It would be useful to be able to assign a trust level to an individual CA certificate.

But, you understood that all, right? A self-signed cert has less about it that you can validate automatically than a commercially signed cert. Everything you can validate about the self-signed cert can be validated on a commercial cert.

(In our environment, where we are responsible for 200 servers with about 50 internal users, > 5000 users inside the company, plus customers, we use an internal self-signed CA cert for all internal services such as VPNs, most internal web admin interfaces, and commercial certs for customer-facing interfaces).

Nokia specifically made provision for this, there is 'open mode', you can flash kernels onto the device, they need some patches to disable the security framework if you want to boot Harmattan (and you may lose some functionality that is protected by Aegis), and while you have a non-Nokia kernel running, you will see a nasty warning when you boot the phone.

But, you can easily install (multi-boot) other distributions.

Really, how do you think mer / Nemo and Nitdroid (Android 4.0.3) run on the N9 ? Since Nokia did things right with the N9 (upstreaming as much as possible), the Nitdroid team has almost full functionality available (calls, 3G, USSD, bluetooth, wifi etc.), where on the N900 years of work by the same team and they didn't manage to get calls or 3G working (though I think mer on the N900 does).