Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Categories
Random page
Top Contributors
Recent changes
Contribute
Create a page
How to help
Wiki policy
Article suggestion list
Articles in need of work
Help
Frequently asked questions
Join the discord!
Help about MediaWiki
Moderators' noticeboard
Report a bug
Consumer Rights Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Talk:Futurehome Smarthub Mandatory Subscription Fee
(section)
Add topic
Page
Discussion
English
Read
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit source
Add topic
View history
Purge cache
General
What links here
Related changes
Special pages
Page information
Cargo data
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Integrity === I end up with similar issues. Thinking about it, it is also normal to have the same issues. It is what internet is good for, having too much of anything which allow its flexibility. What if we try to use some of its ideas? ==== Identity ==== Each user has an identity (using a public/private certificate, what is driving HTTPS, also named SSL certificate). So you can't impersonate someone else (except if its private certificate leak). ==== SSL Features (if you want to read more) ==== SSL certificates allow sub-certificate, which allow trust to be inherited. Why would you want that? Security reason. If you have multiple servers working all together, you probably want one certificate per computer. This means, without sub-certificates, each server would have to be trusted. Which may take some time. So having a parent certificate, allow to trusting a _group_ of peoples. It also allow to revoke certificates. We probably will need short life certificates because we don't want an endless list of revoked certificates from 1990. If certificates are alive only 1 month, then you can assume, at worst, one month of revoked certificates. That, however, need more thinking around it. SSL idea is to trust its parents. There is no "by the way, X become Y, so transfer trust to it". Which open up a wide open of issues. ==== Trust ==== How SSL work currently on the internet? Companies have a root certificate that OS trust. OS trust them because they are transparent on sub-certificates they created. And nowday, their transparency is even one level higher and 3rd party are doing audit as well. Unfortunately, we are going to need a somewhat similar way. Having some feedback on trust over time. Then, either an automatic system(? could be a good tools) create such trust list, or/and, you subscribe to an entity that will publish its trust list. Such content feedback should also be something at its core. Ideally (but it is also a security risk), peoples should double check themself the content somebody else published and raise flag if needed. That may be a seucrity risk, think about somebody creating a virus payload and asking peoples to visit it. Ads farming, ... Since new users are technically endless account. This need better thinking around that. You could also do it more on a passive way (which may also be an issue for the page integrity, as per, if only one guy visit it in 5 years... it is possible the page has been updated in the meanwhile). Peoples add a browser extension that try to push into the system page they are looking. (But for privacy... that may be another issues)
Summary:
Please note that all contributions to Consumer Rights Wiki are considered to be released under the Creative Commons Attribution-ShareAlike 4.0 International (see
Consumer Rights Wiki:Copyrights
for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:
Cancel
Editing help
(opens in new window)