It's really weird how an 65" HDTV will hang on the wall in a home, and yet you'll find that same home filled with people watching Netflix on a cool smartphone they bought because it has an "HD" screen.
Of course a "home filled with people" and only one HDTV will have people watching on smartphones, unless they all want to watch the same program. The prediction in Back to the Future Part II that split-screen TV would become a common feature by 2015 unfortunately did not come to pass.
Wifi access to the internet that I can be sure only ever uses wifi and never the cellphone network, so I don't need a dataplan.
Good luck getting carriers to agree to that. AT&T has been known to add a data plan behind your back unless you're very careful to buy a pay-as-you-go SIM and then activate it on AT&T's website using a desktop or laptop computer instead of in your phone.
There are too many apps which present you with [...] unintelligible (aka in other languages) [...] ads.
Say you are using the English version of an app, but all the advertisers are in Brazil and Portugal, so all you see are advertisements in Portuguese. Would you prefer Netflix- or Hulu-style geoblocking, where an application refuses to start, instead showing the error message "The application could not open because there are no sponsors for your market"?
Almost always, they do not actually need any functionality that is missing from HTML5.
Just because a piece of functionality is listed in the HTML5 Living Standard doesn't mean that the piece of functionality is implemented in Safari for iOS. Until iOS 6, <input type="file"> was missing, and until iOS 8, WebGL was missing. And per the App Store Review Guidelines, all other browsers that run on an iPhone, iPod touch, or iPad have the same functionality as Safari for iOS.
There is a HTML5 API for persistent local storage, at least 5 MB
Is that only for the data accessed by scripts on the page or also for the page itself? If I bookmark a page, close the browser, disconnect from the Internet, reopen the browser, and then open the bookmark, will the page load? Besides, in a lot of browsers, it's 5 MB of UTF-16, and you need to store certain things (such as images) encoded in base64 URIs with the data: scheme, so you can really use 6 out of every 16 bits, or 1.875 MB.
I thought "application cache" was deprecated in favor of "service workers", and "service workers" were hard to test privately because of the requirement for HTTPS.
When even the most basic actions in a game take 24 hours to complete (e.g. digging in Dungeon Keeper), how do you finish a game before becoming bored with it?
And for those who say a website is good enough for that, it's sort of hard to scan the front and back of a personal check that a relative wrote you without using the camera.
Adobe could have broken out support for camera API into a separate app that exposes a service to the main app. This way, users of Android pre-Marshmallow who don't want to use camera features can opt out of the camera permission by not installing the app, and those who do are taken to Google Play Store to install the additional features.
Unless a site's functionality starts to need web platform features not implemented by deliberately limited pack-in web browsers. Apple refused to support <input type="file"> until iOS 6 or WebGL until iOS 8. (I know it was deliberate because iAds could use WebGL in iOS 7, though web pages couldn't.) And on iOS, even third-party browsers that don't use a reformatting proxy are just Safari wrappers. Can a mobile website access the camera to, say, scan a barcode? And can a website on a tablet store itself for offline use?
In which of the European Union's 24 official languages at last count should a name for something discovered in Europe be meaningful? I think they choose Greek because it's the oldest European civilization to have become literate, with whose history Europeans speaking one of the other 23 languages are expected to be familiar.
The problem with mobile in-app purchases is not the try-before-you-buy model as much as consumables. Entitlement IAPs, which persist on a user's account after having been bought once, resemble the "shareware" model used for Doom and the "expansion" model used for Warcraft II. What irks experienced users are "consumable" IAPs that need to be re-purchased after having been used, causing games to be balanced to not be fun unless the player continually buys "gems" or "smurfberries".
Appstores should always allow me to download the version I paid for.
And then watch the version not work once it tries to connect to the Internet service on which it relies:
Protocol version mismatch This happens when the service has been updated but the app hasn't. Google Play Store may have an updated app. On the next screen, tap "Update".
[ Open Play Store ]
In the desktop world I would have an install CD or I would burn a backup copy
But when reinstalling from CD or restoring from backup, the copy would try to activate itself as a condition of use and apply an update as a condition of activation.
6) Make sure you make both Android and iOS versions for games or chat or other device-to-device applications.
Say a hobbyist or bootstrap-funded startup wants to launch on one platform and use the revenue from users of that platform to fund a port to the other platform. Should such a developer instead just stay out of the market?
So you choose to bootstrap from OCaml through old Rust to current Rust the way one would bootstrap from a C implementation through old g++ to modern g++. But this just shifts the bottleneck of the trojan origin to the OCaml binary. Is there an implementation of OCaml that is not from INRIA?
Apple is either about to begin, it has already begun, requiring all iOS apps to strictly only support IPv6, so this is entertaining.
As I understand the news release, the App Store will require apps to support networks that provide only IPv6. The problem described in the featured article pertains to networks that provide only IPv4. Users of an IPv4-only ISP must use tunnels, such as those provided by Hurricane Electric, to reach IPv6 sites, and these tunnels are messing with Netflix's ability to geolocate the user's device.
A VPN is a tunnelling service. A tunnelling service is not necessarily a VPN.
Netflix is blocking tunnels in general. A news source may report that Netflix is blocking "VPNs" because a "VPN" is a name for a type of tunnel that the news source's audience is likely to understand.
I imagine that the present situation exists because studios are unwilling to license programs to Netflix on "billing address" terms. Instead, studios require geolocation of where the subscriber is located, not where the subscriber has an offshore bank account.
Netflix has zero choice in the matter, they can not give you the content without permission of the content owners
You said "content owners". Who has authority to grant a license to transmit the TV series House of Cards? "We own worldwide rights to this that we produced, but we're not letting you watch it because we can't tell what country you're in." Or does this geoblocking apply only to third-party shows?
Last but not least there is no real reason for somebody to start a second implementation.
Yes there is. A language with only one implementation cannot so easily become a formal International Standard the way C and C++ are. Nor can a language with only one implementation support David A. Wheeler's diverse double-compiling, the most practical countermeasure to the "Trusting Trust" attack described by Ken Thompson.
Passwords should be encrypted and then stored in a database. From that point on when the password is entered it is encrypted in the same fashion and the encrypted result compared to the result in the database.
If by "encrypted" you mean "hashed thousands of times with salt", I agree. But a web app still needs to know this hash value in order to authenticate you by hashing the password you entered and comparing it to the stored value. I think part of app guy's point is that the very existence of such a password can lead to a weakness in authentication. But until there's a recoverable "something you have" factor that doesn't involve paying a cellular carrier per received text message or per month for an unlimited texting plan, passwords are the best means we have for associating a particular installation of a client-side app with a user identity.
There is NO need for any web site to know what password you use.
Unless that website is a web-based password manager app.
(Locking out the IP address is another matter in most cases).
That still allows a bad actor behind a carrier-grade network address translation (CGNAT) to DoS a hundred legitimate users behind the same CGNAT. And with IPv4 address exhaustion, many mobile ISPs and ISPs in late-developed countries have deployed CGNAT so that the Internet can have more than 4.2 billion users.
As I understand it, apps can reduce but not completely eliminate password-related security exposure. When your client side app connects to a web app, the web app needs some way to know that the client app is acting on your behalf. Sometimes this is accomplished using a TOTP app such as Google Authenticator, but then a web app still needs some way to associate a TOTP key with your account in the app. How is this done other than through a password, especially in case the user loses the device with the TOTP app?
If there's something I missed, please help this luddite understand.
Slashdot Mirror
It's really weird how an 65" HDTV will hang on the wall in a home, and yet you'll find that same home filled with people watching Netflix on a cool smartphone they bought because it has an "HD" screen.
Of course a "home filled with people" and only one HDTV will have people watching on smartphones, unless they all want to watch the same program. The prediction in Back to the Future Part II that split-screen TV would become a common feature by 2015 unfortunately did not come to pass.
Wifi access to the internet that I can be sure only ever uses wifi and never the cellphone network, so I don't need a dataplan.
Good luck getting carriers to agree to that. AT&T has been known to add a data plan behind your back unless you're very careful to buy a pay-as-you-go SIM and then activate it on AT&T's website using a desktop or laptop computer instead of in your phone.
There are too many apps which present you with [...] unintelligible (aka in other languages) [...] ads.
Say you are using the English version of an app, but all the advertisers are in Brazil and Portugal, so all you see are advertisements in Portuguese. Would you prefer Netflix- or Hulu-style geoblocking, where an application refuses to start, instead showing the error message "The application could not open because there are no sponsors for your market"?
Almost always, they do not actually need any functionality that is missing from HTML5.
Just because a piece of functionality is listed in the HTML5 Living Standard doesn't mean that the piece of functionality is implemented in Safari for iOS. Until iOS 6, <input type="file"> was missing, and until iOS 8, WebGL was missing. And per the App Store Review Guidelines, all other browsers that run on an iPhone, iPod touch, or iPad have the same functionality as Safari for iOS.
There is a HTML5 API for persistent local storage, at least 5 MB
Is that only for the data accessed by scripts on the page or also for the page itself? If I bookmark a page, close the browser, disconnect from the Internet, reopen the browser, and then open the bookmark, will the page load? Besides, in a lot of browsers, it's 5 MB of UTF-16, and you need to store certain things (such as images) encoded in base64 URIs with the data: scheme, so you can really use 6 out of every 16 bits, or 1.875 MB.
I thought "application cache" was deprecated in favor of "service workers", and "service workers" were hard to test privately because of the requirement for HTTPS.
When even the most basic actions in a game take 24 hours to complete (e.g. digging in Dungeon Keeper), how do you finish a game before becoming bored with it?
XPrivacy requires XPosed, and XPosed requires root, and root usually requires a wipe and sometimes requires purchasing a whole new phone.
Apps for my bank and credit cards.
And for those who say a website is good enough for that, it's sort of hard to scan the front and back of a personal check that a relative wrote you without using the camera.
Adobe could have broken out support for camera API into a separate app that exposes a service to the main app. This way, users of Android pre-Marshmallow who don't want to use camera features can opt out of the camera permission by not installing the app, and those who do are taken to Google Play Store to install the additional features.
Just make a decent mobile/responsive site.
Unless a site's functionality starts to need web platform features not implemented by deliberately limited pack-in web browsers. Apple refused to support <input type="file"> until iOS 6 or WebGL until iOS 8. (I know it was deliberate because iAds could use WebGL in iOS 7, though web pages couldn't.) And on iOS, even third-party browsers that don't use a reformatting proxy are just Safari wrappers. Can a mobile website access the camera to, say, scan a barcode? And can a website on a tablet store itself for offline use?
In which of the European Union's 24 official languages at last count should a name for something discovered in Europe be meaningful? I think they choose Greek because it's the oldest European civilization to have become literate, with whose history Europeans speaking one of the other 23 languages are expected to be familiar.
The problem with mobile in-app purchases is not the try-before-you-buy model as much as consumables. Entitlement IAPs, which persist on a user's account after having been bought once, resemble the "shareware" model used for Doom and the "expansion" model used for Warcraft II. What irks experienced users are "consumable" IAPs that need to be re-purchased after having been used, causing games to be balanced to not be fun unless the player continually buys "gems" or "smurfberries".
Appstores should always allow me to download the version I paid for.
And then watch the version not work once it tries to connect to the Internet service on which it relies:
In the desktop world I would have an install CD or I would burn a backup copy
But when reinstalling from CD or restoring from backup, the copy would try to activate itself as a condition of use and apply an update as a condition of activation.
6) Make sure you make both Android and iOS versions for games or chat or other device-to-device applications.
Say a hobbyist or bootstrap-funded startup wants to launch on one platform and use the revenue from users of that platform to fund a port to the other platform. Should such a developer instead just stay out of the market?
So you choose to bootstrap from OCaml through old Rust to current Rust the way one would bootstrap from a C implementation through old g++ to modern g++. But this just shifts the bottleneck of the trojan origin to the OCaml binary. Is there an implementation of OCaml that is not from INRIA?
Apple is either about to begin, it has already begun, requiring all iOS apps to strictly only support IPv6, so this is entertaining.
As I understand the news release, the App Store will require apps to support networks that provide only IPv6. The problem described in the featured article pertains to networks that provide only IPv4. Users of an IPv4-only ISP must use tunnels, such as those provided by Hurricane Electric, to reach IPv6 sites, and these tunnels are messing with Netflix's ability to geolocate the user's device.
A VPN is a tunnelling service. A tunnelling service is not necessarily a VPN.
Netflix is blocking tunnels in general. A news source may report that Netflix is blocking "VPNs" because a "VPN" is a name for a type of tunnel that the news source's audience is likely to understand.
I imagine that the present situation exists because studios are unwilling to license programs to Netflix on "billing address" terms. Instead, studios require geolocation of where the subscriber is located, not where the subscriber has an offshore bank account.
Netflix has zero choice in the matter, they can not give you the content without permission of the content owners
You said "content owners". Who has authority to grant a license to transmit the TV series House of Cards? "We own worldwide rights to this that we produced, but we're not letting you watch it because we can't tell what country you're in." Or does this geoblocking apply only to third-party shows?
SlashdotMedia is a U.S. corporation.
Last but not least there is no real reason for somebody to start a second implementation.
Yes there is. A language with only one implementation cannot so easily become a formal International Standard the way C and C++ are. Nor can a language with only one implementation support David A. Wheeler's diverse double-compiling, the most practical countermeasure to the "Trusting Trust" attack described by Ken Thompson.
Passwords should be encrypted and then stored in a database. From that point on when the password is entered it is encrypted in the same fashion and the encrypted result compared to the result in the database.
If by "encrypted" you mean "hashed thousands of times with salt", I agree. But a web app still needs to know this hash value in order to authenticate you by hashing the password you entered and comparing it to the stored value. I think part of app guy's point is that the very existence of such a password can lead to a weakness in authentication. But until there's a recoverable "something you have" factor that doesn't involve paying a cellular carrier per received text message or per month for an unlimited texting plan, passwords are the best means we have for associating a particular installation of a client-side app with a user identity.
There is NO need for any web site to know what password you use.
Unless that website is a web-based password manager app.
(Locking out the IP address is another matter in most cases).
That still allows a bad actor behind a carrier-grade network address translation (CGNAT) to DoS a hundred legitimate users behind the same CGNAT. And with IPv4 address exhaustion, many mobile ISPs and ISPs in late-developed countries have deployed CGNAT so that the Internet can have more than 4.2 billion users.
As I understand it, apps can reduce but not completely eliminate password-related security exposure. When your client side app connects to a web app, the web app needs some way to know that the client app is acting on your behalf. Sometimes this is accomplished using a TOTP app such as Google Authenticator, but then a web app still needs some way to associate a TOTP key with your account in the app. How is this done other than through a password, especially in case the user loses the device with the TOTP app?
If there's something I missed, please help this luddite understand.