Android Market in Android 2 required specifically a Gmail account and gave the "aeris@example.com does not use Gmail. Add Gmail to your Google account" registration for a Google account associated to any other email address. Google Play Store in Android 4 or later allows use of any Google account but requires a Google+ profile in order to leave a review of an app.
I'd like to see a responsibility system put in place. Something like Stackexchange where it is easy to have an account, but you have to earn privileges to post or comment
According to this walkthrough of Stack Exchange, you first earn 10 by improving formatting or grammar in five posts. This gives "participate in meta", allowing you to ask for clarification of a site's scope, and "remove new user restrictions", allowing you to cite sources in questions and answers, provide screenshots in questions and answers if necessary, and answer protected questions. Then you earn 40 more by providing useful answers to a couple questions. This gives "comment everywhere".
In your vision of ResponsibleTube, how would a new user go about earning enough points to comment? Would initial reputation be based on an invite tree (like the field trials of Orkut, Gmail, and Google+), a valid enrollment in higher education (like the field trial of Facebook), a valid subscription to mobile phone service (like Yahoo! and current Gmail), or a months-long waitlist (like Google Contributor)?
Let me rephrase: "Back in the olden days, where I directly paid for service that was not a geographic monopoly, the provider would care about such issues."
A sales lead for every maker of cat food, cat litter, cat medication, cat toys, and other products targeted at cat owners. Sing it with me: Meow meow meow meow, meow meow meow meow...
If you bought a TV, and the first thing it did was prompt for your credit card, would you actually do that?
Perhaps if it was a device specifically intended for use with electronically purchased copies of works of authorship, not a device primarily intended to decode and display HDMI or ATSC signals. A Kindle reader, for example, needs an Amazon account.
So how is an RP's operator supposed to know with which IDPs to register so as not to turn away a user who tries to log in with an OpenID identifier issued by an unsupported IDP?
They promised [...] freedom [...] for everyone to develop.
When I finally got mine, I turned it on and the first thing it did was ask for my credit card number. Tried to skip it but it was not possible.
If no one is willing to pay for games, then how should everyone keep a roof over their heads while developing games? Or by "freedom" did you mean free as in FSF, with all games having DFSG-free code and assets?
the user won't need to type in that 60-character password on their mobile device. The user can just unlock the password manager and paste in the saved password.
How would the user get the long password into the mobile device's password manager in the first place?
The password manager should run on the user's own PC
Provided the user has an own PC. Good luck logging in at a public library or Internet cafe.
If an app needs to perform an action on behalf of a user, it should get its own distinct, revocable API key.
And store this "own distinct, revocable API key" in what secure manner? Client applications distributed as free software have already run into problems with how to store an OAuth 1.0a or 2.0 client ID and client secret.
Yes, and how many of those apps ask for a copy of your address book ? I don't mind sharing if needed for a function, web privacy being a lost cause, but if you want to d/l my 5000 plus contact professional contact list, uh, NO.
Some people want to use a function that requires location; others don't. Some people want to use a function that requires the address book; others don't. If there are seven different permissions that can be used by an optional function, do you expect the developer to make 2^7 = 128 different apps, one for each specific combination of optional functions?
A 1024x600 pixel netbook's screen is still physically larger than those phones. To actually read text on those without changing the layout, you'd need a magnifying glass. This is why the web browsers on these devices tend to interpret CSS 1px as 1.5, 2, or 3 actual pixels.
Some people must have a high tolerance for this sort of treatment.
If the alternative is unemployment, which leads to starvation due to inability to afford food and imprisonment due to violations of city sit-lie ordinances, a lot of people are willing to tolerate a lot of BS.
Of course, the real solution is to get rid of passwords. Web sites should switch to using OpenID authentication.
One problem is that a lot of identity providers,* such as Google, have switched from classic OpenID to OpenID Connect. Because of the OAuth 2 underlying OpenID Connect, it has become more common for IDPs to require each relying party* to enter into a contractual relationship with the identity provider. With classic OpenID, if you had an identifier URL from a given IDP, you could use it on any RP. But in OpenID Connect, you can't use your identifier unless the RP has a client ID and client secret pair issued by the same IDP that issued your identifier. There is a Dynamic Client Registration protocol for an RP to automatically obtain a client ID and client secret from an IDP, but no major IDPs appears to support DCR. If there are n RPs and m IDPs, a human has to review and accept a contract m*n times, and managing this becomes O(n^2):
* In OpenID, an "identity provider" is the website that issues OpenID identifier URLs and takes your password, such as Google, and a "relying party" is the website that takes your OpenID identifier and redirects you to the identity provider to log in.
(Some of them don't even have the "X" corner icon. You have to choose one of the presented links to close.)
Such as Pinterest ("There's more to see..."), Chicago Tribune, and any site using CPALead ("Please complete a survey to unlock this page") or Google Consumer Surveys ("Answer a question to continue reading this page"). Unfortunately, Google Search hasn't been good at demoting sites using these.
It behaves like one in every way, just the mechanics of how it's displayed is different...so maybe browsers need to dust off their 'pop-up blocker' option code and update it to block these damn things too?
The difference in mechanics makes all the difference. Pop-up blockers could define a pop-up as a call to window.open without a click event below it in the call stack. Showing an in-page pop-up is just changing the visibility of an HTML element, and there are plenty of legit reasons to do that. To work around that, you'd have to put JavaScript on a whitelist; good luck managing such a whitelist on a 4" screen.
Second, it does anyway for some POS F2P/P2W app [...] Solution? Android, F-Droid
I might be misunderstanding you, but how are apps available through F-Droid a substitute for "some POS F2P/P2W app"? I thought games were one of the few things free software had trouble providing.
Install NoScript, and a lot of Blogspot blogs (such as the featured article) will just show the spinning gears GIF forever until you whitelist the site, at which point the crap returns.
I imagine that hosting providers default to password logins because it reduces support costs. Their customers tend to be unfamiliar with SSH public key authentication and especially with synchronizing these keys across multiple devices including mobile ones.
Why the hell don't you have port knocking enabled for SSH?
I imagine that hosting providers default to not requiring port knocking because it reduces support costs. Their customers tend to be unfamiliar with port knocking.
If it costs you money to both be secure and live in the sticks, then why not move from the sticks, as other Slashdot users have suggested? [1][2][3][4][5][6][7][8]
Another commonplace annoyance is sites of no consequence that ask for an email address and for some unknown reason require it to be entered twice.
Some site probably tested it and found that it reduces the number of registrations that fail to complete because the user mistyped his e-mail address and thus failed to receive the registration confirmation e-mail message. Then other sites copied it.
If you are writing software that takes in a password and you are hashing the password to compare it to a stored hash, there is no reason at all to restrict the maximum length of a password or prohibit certain characters from being used in it.
Other than that it's far harder to type a 60-character password on a mobile device whose only text input method is a flat sheet of glass. Allowing users to enter a long password discourages users from even trying the mobile site or mobile app.
If you are writing software that takes in a password and you are NOT hashing the password (but instead storing it in the clear or otherwise doing something with it), you shouldn't be writing software involving passwords in the first place
Unless you're storing the user's password in order to log on to a service on the user's behalf. A password manager is an example of such an application. With other applications, even if the service supports some form of OAuth, the application still has to somehow store the client ID, client secret, and user token securely.
Slashdot Mirror
Android Market in Android 2 required specifically a Gmail account and gave the "aeris@example.com does not use Gmail. Add Gmail to your Google account" registration for a Google account associated to any other email address. Google Play Store in Android 4 or later allows use of any Google account but requires a Google+ profile in order to leave a review of an app.
I'd like to see a responsibility system put in place. Something like Stackexchange where it is easy to have an account, but you have to earn privileges to post or comment
According to this walkthrough of Stack Exchange, you first earn 10 by improving formatting or grammar in five posts. This gives "participate in meta", allowing you to ask for clarification of a site's scope, and "remove new user restrictions", allowing you to cite sources in questions and answers, provide screenshots in questions and answers if necessary, and answer protected questions. Then you earn 40 more by providing useful answers to a couple questions. This gives "comment everywhere".
In your vision of ResponsibleTube, how would a new user go about earning enough points to comment? Would initial reputation be based on an invite tree (like the field trials of Orkut, Gmail, and Google+), a valid enrollment in higher education (like the field trial of Facebook), a valid subscription to mobile phone service (like Yahoo! and current Gmail), or a months-long waitlist (like Google Contributor)?
Let me rephrase: "Back in the olden days, where I directly paid for service that was not a geographic monopoly, the provider would care about such issues."
My cat's name is fluffy, who am I?
A sales lead for every maker of cat food, cat litter, cat medication, cat toys, and other products targeted at cat owners. Sing it with me: Meow meow meow meow, meow meow meow meow...
If you bought a TV, and the first thing it did was prompt for your credit card, would you actually do that?
Perhaps if it was a device specifically intended for use with electronically purchased copies of works of authorship, not a device primarily intended to decode and display HDMI or ATSC signals. A Kindle reader, for example, needs an Amazon account.
How can someone demonstrate that he is willing to pay for games without entering his payment credentials?
Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment
[Unbalanced parentheses.] Which guide to configuring keys in popular SSH clients does your documentation link to?
However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP.
Because BP got hacked by Chinese? Naaah.
So how is an RP's operator supposed to know with which IDPs to register so as not to turn away a user who tries to log in with an OpenID identifier issued by an unsupported IDP?
They promised [...] freedom [...] for everyone to develop.
When I finally got mine, I turned it on and the first thing it did was ask for my credit card number. Tried to skip it but it was not possible.
If no one is willing to pay for games, then how should everyone keep a roof over their heads while developing games? Or by "freedom" did you mean free as in FSF, with all games having DFSG-free code and assets?
the user won't need to type in that 60-character password on their mobile device. The user can just unlock the password manager and paste in the saved password.
How would the user get the long password into the mobile device's password manager in the first place?
The password manager should run on the user's own PC
Provided the user has an own PC. Good luck logging in at a public library or Internet cafe.
If an app needs to perform an action on behalf of a user, it should get its own distinct, revocable API key.
And store this "own distinct, revocable API key" in what secure manner? Client applications distributed as free software have already run into problems with how to store an OAuth 1.0a or 2.0 client ID and client secret.
Yes, and how many of those apps ask for a copy of your address book ? I don't mind sharing if needed for a function, web privacy being a lost cause, but if you want to d/l my 5000 plus contact professional contact list, uh, NO.
Some people want to use a function that requires location; others don't. Some people want to use a function that requires the address book; others don't. If there are seven different permissions that can be used by an optional function, do you expect the developer to make 2^7 = 128 different apps, one for each specific combination of optional functions?
Start using my cell phone's data plan to download content for offline access when, because it's a cell phone, offline is 'rare'
How is the time between when you have used up the 2 GB quota and the end of the billing month "rare"?
A 1024x600 pixel netbook's screen is still physically larger than those phones. To actually read text on those without changing the layout, you'd need a magnifying glass. This is why the web browsers on these devices tend to interpret CSS 1px as 1.5, 2, or 3 actual pixels.
Some people must have a high tolerance for this sort of treatment.
If the alternative is unemployment, which leads to starvation due to inability to afford food and imprisonment due to violations of city sit-lie ordinances, a lot of people are willing to tolerate a lot of BS.
Of course, the real solution is to get rid of passwords. Web sites should switch to using OpenID authentication.
One problem is that a lot of identity providers,* such as Google, have switched from classic OpenID to OpenID Connect. Because of the OAuth 2 underlying OpenID Connect, it has become more common for IDPs to require each relying party* to enter into a contractual relationship with the identity provider. With classic OpenID, if you had an identifier URL from a given IDP, you could use it on any RP. But in OpenID Connect, you can't use your identifier unless the RP has a client ID and client secret pair issued by the same IDP that issued your identifier. There is a Dynamic Client Registration protocol for an RP to automatically obtain a client ID and client secret from an IDP, but no major IDPs appears to support DCR. If there are n RPs and m IDPs, a human has to review and accept a contract m*n times, and managing this becomes O(n^2):
* In OpenID, an "identity provider" is the website that issues OpenID identifier URLs and takes your password, such as Google, and a "relying party" is the website that takes your OpenID identifier and redirects you to the identity provider to log in.
(Some of them don't even have the "X" corner icon. You have to choose one of the presented links to close.)
Such as Pinterest ("There's more to see..."), Chicago Tribune, and any site using CPALead ("Please complete a survey to unlock this page") or Google Consumer Surveys ("Answer a question to continue reading this page"). Unfortunately, Google Search hasn't been good at demoting sites using these.
We have one: it's basically a pop-up.
It behaves like one in every way, just the mechanics of how it's displayed is different...so maybe browsers need to dust off their 'pop-up blocker' option code and update it to block these damn things too?
The difference in mechanics makes all the difference. Pop-up blockers could define a pop-up as a call to window.open without a click event below it in the call stack. Showing an in-page pop-up is just changing the visibility of an HTML element, and there are plenty of legit reasons to do that. To work around that, you'd have to put JavaScript on a whitelist; good luck managing such a whitelist on a 4" screen.
Second, it does anyway for some POS F2P/P2W app [...] Solution? Android, F-Droid
I might be misunderstanding you, but how are apps available through F-Droid a substitute for "some POS F2P/P2W app"? I thought games were one of the few things free software had trouble providing.
in my experience HTML5 video interstitials are still uncommon
I've seen HTML5 video interstitials when browsing Wikia with an Android device.
Install NoScript, and a lot of Blogspot blogs (such as the featured article) will just show the spinning gears GIF forever until you whitelist the site, at which point the crap returns.
Why do you allow password logins for SSH?
I imagine that hosting providers default to password logins because it reduces support costs. Their customers tend to be unfamiliar with SSH public key authentication and especially with synchronizing these keys across multiple devices including mobile ones.
Why the hell don't you have port knocking enabled for SSH?
I imagine that hosting providers default to not requiring port knocking because it reduces support costs. Their customers tend to be unfamiliar with port knocking.
you keep a copy or an excerpt of the password book safe in your wallet
Likewise, most adults in my country keep a plastic card with their credit card number and CVV2 in their wallets.
If it costs you money to both be secure and live in the sticks, then why not move from the sticks, as other Slashdot users have suggested?
[1] [2] [3] [4] [5] [6] [7] [8]
Another commonplace annoyance is sites of no consequence that ask for an email address and for some unknown reason require it to be entered twice.
Some site probably tested it and found that it reduces the number of registrations that fail to complete because the user mistyped his e-mail address and thus failed to receive the registration confirmation e-mail message. Then other sites copied it.
If you are writing software that takes in a password and you are hashing the password to compare it to a stored hash, there is no reason at all to restrict the maximum length of a password or prohibit certain characters from being used in it.
Other than that it's far harder to type a 60-character password on a mobile device whose only text input method is a flat sheet of glass. Allowing users to enter a long password discourages users from even trying the mobile site or mobile app.
If you are writing software that takes in a password and you are NOT hashing the password (but instead storing it in the clear or otherwise doing something with it), you shouldn't be writing software involving passwords in the first place
Unless you're storing the user's password in order to log on to a service on the user's behalf. A password manager is an example of such an application. With other applications, even if the service supports some form of OAuth, the application still has to somehow store the client ID, client secret, and user token securely.