I’m not sure why some are struggling to understand this. A single "godmode" checkbox would only be possible if every element, the marketplace, the hardware, and the payment rails, were inside one ecosystem. The Switch is Nintendo, Minecraft is Microsoft, the credit card is Visa, and so on. There are simply too many moving parts, making a single killswitch nearly impossible to orchestrate.
Building 29 separate settings with confusing and overlapping effects is less work than making a single setting of: [Local Only]?
Seems to be a much larger amount of work to design, implement, and support a more-or-less dozen-step customer journey that does NOT work than just implementing a few switches. And that goes even if the switch must be designed-in from the beginning by designing operation for local-only operation.
Surely, implementing a simple block-all-strangers to send-to-bitbucket all communications attempts by accounts not already on the whitelist is easier than all these overlapping settings described?
Unless it is explained how building a much more complex system is easier and lower-cost than a simpler system with fewer controls, the default conclusion is it is intentional.
>>It is not a dark pattern, it is just "what is the minimum we can do to sell this without doing the curation work?"
Even if for the sake of discussion we treat it as laziness, a dark pattern created by accident is still a dark pattern. The customer is no less screwed into doing something they do not want and the company does want.
> Building 29 separate settings with confusing and overlapping effects is less work than making a single setting of: [Local Only]?
The 29 separate confusing overlapping effects is by design. A single "local only" switch would (so long as that switch is enabled) lock out all manner of potential future revenue and recurring rents, which these companies very much want to see hit the balance sheet.
So the 29 separate confusing overlapping settings is designed to frustrate you to the point that you allow what they want from the start, the ability of the device to generate future revenue (via both of one time sales and recurring rents on rental sales).
>>The 29 separate confusing overlapping effects is by design
>>designed to frustrate you to the point that you allow what they want from the start, the ability of the device to generate future revenue
And this explains why they are willing to do all the extra work to do it.
It is not even close to accidental or lazy — there is nothing accidental about the intention or going to the extra cost to build those dark patterns to screw the customers.
At the end of the day if the MTX group says no, it doesn't happen. Sales is always the most powerful group in an organization, sometimes even overriding compliance if they can get away with it.
>> Building 29 separate settings with confusing and overlapping effects is less work than making a single setting of: [Local Only]?
Yes, absolutely. 29 separate overlapping settings likely match up precisely to arguments in various APIs that are used. On the other hand, what does local only even mean? No wifi? No hardwired connection? LAN only? Connection to the internet for system updates but not marketplace? Something else? All with a specified outcome that requires different implementation depending on hardware version and needs to be tweaked everytime dependencies change.
Having a separate setting for unconditionally disabling all wireless communication would be helpful. The other stuff you mention can be separate settings if it is useful to have them. (A setting to unconditionally all disable wired connections is less important since you can just avoid connecting it.)
Let's start with this: Design the architecture so the core system works fine locally. Features requiring Internet connection are in separate modules, so they can be easily turned on/off, and designed so they are still primarily local.
E.g., store all current status locally and if requested another module sends it to the cloud, instead of cloud-first.
E.g.2, install updates by making a pull of all resources and then doing the update instead of requiring continuous communication.
Allow user control with options to completely shut off, whitelist, blacklist, etc.
Simple design decisions up front to make a software package meeting the user's local needs first, THEN allowing controlled access to the internet, under the USERS' control, instead of designing every feature to contact your servers first and compromising both usability and control at every step.
The contact page on the left is something I absolutely hate. If the prefer method of contact is email, just give me an email.
If they need to enter that into some ticketing system, give me access to the ticketing system. The page on right give me some ideas how they handle things internally.
The form on left is almost certainly a webform-to-email, this is ridiculous.
looking at font choice, how ironic they are complaining about UX
If you put an email address on a contact page, all manner of sh*t is going to be thrown at you.
Automated marketing services, scammers, competitors, everyone and their dog are going to be filling up your customer service inbox and costing you time and money to manage it.
Put a contact form on your website and you can secure it with a capture, which is not bulltproof but it sure does filter out a lot of automated noise for you. Then you will find that people are generally a lot quicker to fire off an email than fill out a contact form. In my experience this generally puts one more 'thinking barrier' between you and the public, which again cuts down noise significantly.
Also, click the 'settings' button in the bottom right, and you will see they have given you a choice of fonts. Sometimes it pays to look a tiny bit further to see whether your issue has already been solved, before complaining about it.
Protection against bots seeing the e-mail on your website has been around for at least a decade.
And if any of your customers or business partners know of the company e-mail, then you're already known to all spammers in the world, since their contact lists are getting hacked all the time.
Ie: If you're a business your e-mail adress is already out there, so give it also to those who need it the most, which are your customers.
Not hit and run. There are underlying assumptions which most intelligent people can infer. The intention was to say that all of your comments are a bit naive from an ecommerce site perspective. Having been through mutiple builds and launches of them, I can tell you categorically that your comments are uninformed and wrong. But rather than write all that and make you feel like I am intentionally insulting you, I just point out that you have made your lack of knowledge obvious.
I can kind of guess what attitude customers might be met with when trying to get help with an issue from any of the multiple builds and launches that you've been involved in.
In the past it used to work the way the parent comment is describing. The confusion is understandable. Apple basically got rid of macos and replaced most of it with things from ios in 2020, a lot changed.
Your comment is overbroad as written, but it is close to true about the boot chain. The Apple Platform Security Guide [1] says: “When a Mac with Apple silicon is turned on, it performs a boot process much like that of iPhone and iPad.”
There are some fundamental different between two ecosystems.
On Google, the Google Drive and Photo are encrypted to a key owned by google.
On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive.
When it comes to lost password account recovery:
- Google can just reset your password, and your drive and photo are still accessible. All barrier are procedural, not technical.
- iCloud (with ADP), they can still reset your password, but then your icloud drive and icloud photo are loss forever.
There are some trade off ..:
- Lost password recovery experience. _Some_ user will lost their password anyway. How high should the bar be?
- Cloud first? or local device first with cloud backup?
- Are you giving the cloud data same protection as local device?
In google's solution, they put the google drive data at risk...
In apple's solution, it need extra steps to ensure you have proper account recovery flow covered.
That's all fine, but tangential to my complaint, which is about iMessage specifically. iMessage, as a system that strongly promotes e2ee as a core feature, should not be backing up its encryption keys to non-e2ee iCloud backup in any scenario. Messages should fall in the same category as keychain passwords and (yes!) Memoji, backups of which are always end-to-end encrypted even when ADP is not enabled.
In fact I would say calling iMessage an e2ee system is false advertising until this is corrected. Reasonable people would assume that an Apple system advertised as e2ee would make an effort to prevent Apple servers from having the keys to decrypt most iMessages, while the reality is with these defaults it's likely that a large majority of iMessages can be decrypted by Apple servers at will.
You aren't understanding the point being made in OP. Everyone here understands the crypto for ADP vs non-ADP, there's no need to explain it.
The simple fact of the matter is that if I have ADP enabled, my chats should be excluded from the backups of those I'm communicating with (it should be as an opt-in basis at the very least).
Not having this renders ADP useless for the purpose of its stated threat model.
Why does your desire for complete privacy and _control_ outweigh mine to keep a complete history of my communications?
Why can you reach into my phone and wipe data you sent to me?
Why are _you_ the final arbiter?
Once you send a message it is _out of your hands_. You do not own that message. You do not have the right to dictate to others what they can do with what you send to them. That’s life, that’s reality.
If you want to be able to delete your sent messages from other’s devices, there are many apps out there that can provide it to you and both you and the person you are talking to can go in “eyes wide open” to what you agreeing to (I can delete messages I sent to you and you have no record).
The potential for abuse of this is high and the vast majority of users would _not_ want this feature. The same way that mostly people probably shouldn’t use ADP due to the risks, this type of feature will cause way more issues IMHO. It doesn’t take much imagination to get to “Grandpa pressed the wrong button and deleted years (decades) of conversation from everyone’s phone”.
I am not interesting my normal conversations potentially disappearing. That was not the agreement that we had and changing the rules later on that is gross to me. If you want disappearing chats or the ability to wipe all the messages you’ve sent there are other apps (with their own pitfalls, what if I keep my phone offline and never get the update to clear out your conversations?).
You apply it to where it is needed. Not every scene need the same treatment.
reply