It’s private to the extent that those private companies are. Well, at least it’s not totally public! I mean, what’s the probability of waking up today and finding out that facebook’s data center’s were breached and all private stuff is out in the open? Nill!
But yeah, at the algorithmic level, the said algorithms have access to everything private with no anonymity concerns.
it’s not nil
i know of at least one case where facebook had insufficient access controls on their CDN and private photos were leaked via. a cache
here’s the top hit from google for another breach https://www.nytimes.com/2018/09/28/technology/facebook-hack-data-breach.html
1 Like
if you know an algorithm that can do recommendations from anonymous or at least psuedonomous data i think we can make that work 
otherwise it seems by the nature of the algorithm you need to trust something or someone somewhere (which we can also make work, but it’s not quite as exciting)
1 Like
Yeah, I remember reading a paper about doing collab in a distributed system some months ago… Don’t know which exactly.
However, if I know you visited nytimes today, my chance at finding your anonymous counterpart gets higher! And I also know you visited this forum, and BOOM! I got you! Now everything you do online, I’ll know… You get the idea…
Yup, right. That’s the conclusion I’ve reached thus far…
holochain can give you roughly as much decentralisation or centralisation as you are comfortable with for a given algorithm
in this case it seems the algorithm itself is invasive, not sure if we can ‘repair’ it at the network level 
but we can at least enforce standards on trusted processors, e.g. like medical records and payments etc.
e.g. so many companies out there just process credit card payments without proper audits and compliance, or they get an audit once instead of annually and just let it lapse, etc.
we could implement a network that you can only connect to if a registered auditor crypto signs your devices once a year as per an established international standard - actually this could be done at the holo level too
so actually we can do trusted servers better too 
2 Likes
The design pattern to do such stuff that I envisioned is (don’t mind please) a bit comical at best!
A (h)app has multiple agent-types in the DNA rules.
-
Plain-old users. They include both news publishers and viewers, and any other role you might have in your (h)app.
-
Collab_Gods: This is whom you submit your continuous private history in return for recommendations. It’s essential that you trust them.
Now, to create a collab_god agent, you need a private key that only the trustworthy organization that developed the (h)app has. If the agent can “sign” a random number that the prove_youre_a_god function asks you to sign, then great! You’re a collab_god now! The corresponding public-key is simply specified in the DNA!
The organization spawns (much like microservices) all those collab_gods (yeah, multiple gods for load-balancing) with some shell-script that they pass the top-secret private-key to. And voila! The gods are now running on holo-ports all over the world. And as part of their functionality, they do all the hard work of collaborative-filtering, encrypting any public data that they produce in the process with the secret that only they know. The users just pick a random collab_god to send their browsing data to and receive recommendations from, and they do so every time they come online. And if let’s say the original organization’s key gets sacrificed, then worry-not! It’s not the end of the world! Someone else whom the community trusts enough can create a new breed of collab_gods with a new private-key for that purpose; in fact multiple gods’s breeds should be able to coexist (as per the DNA). Just publish (as an entry) the public key of the new breed and that’s how others can refer to it (via its corresponding public key on the DHT).
Feels like I’m making a fun of myself bringing greek ancient mythical Gods in the discussion, but yeah… Maybe it’s a good idea? In fact, it can even provide the company a revenue stream if each call to recommend_me(pub_key_of_god_breed_to_consult) can charge a small fee for the service (after all it’s the company that pays for the holo-hosting, not just for the God-agents but also for the users)! What’s your opinion on this? Should agents be restricted to human beings (as is evident from the great many people trying to build biometrics and other rubbish into Holochain apps) or should we have such Gods of Thunder in the app?
And it can be expanded much beyond that. You can have a God_Of_Time to do time-based routine jobs on the network; the possibilities are endless! Representing such features as full-fledged agents can allow us to mitigate the limitations of purely-human-agent-centric systems!
Or is this a silly idea? Does it break any implicit invariant that I’m unaware of that Holochain assumes? @thedavidmeister ?
@The-A-Man makes sense to me, it seems to be an upgrade over the way things currently work
now:
- there is an unsolvable data security issue that nobody wants to insure
- some regulatory body creates an onerous list of checkboxes
- some company sets out to tick all the boxes
- independent auditors attempt to tick boxes on pieces of paper
- the company creates a proprietary API in front of their box-compliant machines
consumers experience vendor lock-in due to the proprietary API (ever used Stripe’s API? or a bank API?) and they have little or no visibility on the audits (who did it? when? were there any outstanding items?)
the reality is that even if an audit lapses or failed, most customers will not know about it and even if they do they will find it very expensive and inconvenient to rebuild all their systems to a new API - yet customers can be held liable for non-compliance in a vendor’s breach…
the same thing on holo(chain):
- there is an unsolvable data security issue that nobody wants to insure
- some regulatory body creates a template DHT that enforces as much as possible in code
- the regulatory body puts the DHT behind the signatures of independant auditors and a signing time server that the regulator maintains
- any company that meets the requirements can apply to maintain the DHT
- auditors inspect the company and make public the results as well as signing the company into the DHT
- consumers write their systems to the interface of the DHT
- consumers pay a premium vs. vanilla holoports for the additional compliance audits
consumers have no vendor lockin because they implement their systems on a standard DHT, and they are guaranteed the audits are real because vendors are automatically and immediately blocked from the system when the audit expires - consumers may not even be aware that their original vendors have changed over time, their service should continue uninterrupted by trust-equivalent new vendors (according to the regulator and auditors)
1 Like
Yup, right… Can’t be more succinct. Really sounds like the web of the future, where every organizational body has got a role to fulfil, who do so in a clean organized clarified standard as dictated by the template.
1 Like
my notes on time - https://github.com/holochain/holochain/blob/develop/crates/hdk/src/host_fn/sys_time.rs
1 Like
I’m finding this thread overwhelming cuz I’m reading the whole thing at once 
but I have a few extra things to contribute:
- If a person isn’t always using their app but has their computer on all the time (common scenario), the UI could be smart enough to do these garbage-collection, auto-like, etc tasks for them, as you said.
- I do like your idea of ‘time gods’ or whatever you called them – trusted nodes who can do work for you – although there are certain very agent-centric tasks that might take a bit of work to model. In the “I always leave my computer on” scenario, the time god could do the automatic stuff rather than the person’s UI, but that seems like unnecessary complexity. So maybe you’d want to explore other options. For instance, maybe your app has some concept of delegated identity, where Alice creates a signed certificate saying that “Time God X can publish data for me and, as long as they reference this certificate when they do it, you can consider it as if it were me doing it.”
- I hear you wondering about Holo hosts and whether they can take some responsibility for running automated tasks, since they’re always on. Initially I thought similar thoughts, but as I learned about Holo I learned that a host can’t do anything without a user’s consent.
- Correct me if I’m wrong @thedavidmeister but weren’t the core devs toying with the idea of conductor-level cronjobs as a future feature? This would still require the user to leave their computer on, but at least there’s built-in stuff and you wouldn’t have to roll your own in the UI.
- You’re right @The-A-Man that your DNA’s zome functions constitute an API that somewhat restrict how agents can access data. Yes, the data can still be accessed by someone who can produce the right credentials (“Yeah, I’ve got the right DNA hash, and here’s my membrane joining proof showing I’m legit allowed to be here”) but can bypass the zome API. What I’m learning, though, is that privacy has a lot to do with greasing/friction – that is, it’s not just about whether it’s possible to steal private data, but also about how hard it is (especially compared to the payout). However, a good security professional needs to be paranoid and think about what’s possible, not just what’s likely. What concerns me is the payout – with a cloud system, if an attacker compromises a user’s computer, they get access to the user’s stuff, and if they compromise the server (which is a lot harder), they get access to everyone’s stuff. But with Holochain, compromising a user’s computer can give an attacker access to all of ‘our’ data – that is, data that’s shared among the participants. There’s one comfort, in that people can still have a lot of private data on their source chains that the attacker can’t access, but it does put a responsibility on a hApp creator’s shoulders to think hard about DHT data and threat vectors. Another comfort is that the core devs plan to start encrypting all at-rest data, so an attacker would have to rely on the hApp actually running (that is, the user entered their decryption password).
3 Likes
Yup, our life would have been heaven if that were the case… But with Holo, thin chance, as stated by you:
yup, there are some challenges to agent-centricity for sure. My hunch is that the benefits will outweigh the challenges, but it doesn’t make the challenges go away!
2 Likes
Loved the greasing/friction metaphors… Looks like perfect privacy is a pipe dream at best! What should matter to us is that we be relatively more private than both client/server and blockchain’s fantasy (unscalable) web solutions!
1 Like
yes scheduled tasks are part of the planned hdk
1 Like
“don’t say the hammer is useless because screws exist and the screwdriver is useless because nails exist” 
dead.
pessimists find a problem with every solution and optimists find a solution to every problem
1 Like