Software locks: Difference between revisions
m →Noteworthy bad practice examples: fixed red links |
Category:Common terms |
||
| Line 41: | Line 41: | ||
<references /> | <references /> | ||
[[Category:Common terms]] | |||
Revision as of 01:33, 12 October 2025
❗This article is a stub. You can help by expanding it.
#appeals channel in either Zulip or Discord to request removal.An article may be flagged as a stub when it is missing major elements needed to make it useful to a reader. You can help by adding missing sections, verifiable sources, relevant company policies and communications, etc. to make the article more complete.
Software locks are security measures used to control access and features in consumer electronic hardware and software. [1][2] Software locks are not considered bad practice and are necessary for basic cybersecurity and operation of most hardware, though they can be abused.
Noteworthy bad practice examples
Anti Interoperability
Also see: Proprietary protocols
wip stub example you can't use our competitors Bluetooth headset with our XYZ operating system because we invented a our own new proprietary XYZ Bluetooth audio codec and that product doesn't support it.
real example apple mfi certifications on charging and data transfer accessories
apple's history of anti-Interoperability
Account-required products
Mobile phones
ref Small preamble focused on how mobile phones require an account in order to be used, reference Google Pixels and specific Android devices requiring a Google account, and iPhones needing an Apple account.
in appliances
hvac app activation of furnace control boards (also an example of Forced app download (editors note hard to find credible ref this is a thing with ruud furnace control boards) )
Binding hardware features to non-transferable user accounts / activation & licensing locks
-wip
Server connectivity reliance
Also see: Subscription service, Digital rights management
-wip
Further reading / also see
Walled garden / Software Ecosystem