My alma mater is setting up "lifetime email accounts" for alumni. Which seems nice, and makes sense for them trying to get their message out with a connection directly to alumni.
I'm surprised that email accounts haven't become more of a thing with most people having a mail client that will combine multiple accounts (their phone).
Imagine if your doctor gave you an account where you could send/receive messages. If they never left the server and used secure protocols to connect it'd work.
@ted It would help if all the email protocols weren't essentially rotting due to the large email providers' deciding to add their own proprietary extensions rather than fixing them.
@ted Sorry, but I don't think your idea is very sound. The entire point of SMTP is that it is an open, standardized protocol allowing for decentralized messaging between autonomous systems. Security of communications can be facilitated without the need for centralization simply by ensuring messages are encrypted end-to-end.
Your proposal creates huge admin/user overhead and a problematic dependecy model on the technical accumen of every provider with whom you need to communicate.
Do not want.
@sean while I understand your point end-to-end encryption of email is basically non-existent in common usage today. The technology has been around for 30 years but never gotten significant adoption.
I think we're at the point of needing to remove that from the list of possible solutions.
@ted The only reason it's not in common usage is because the predominance of email users use "free" email services that are ad-supported. Content encryption is counter to the interests of the provider.
Regardless, I'm in opposition to the idea of creating "portals" of communication for every provider with whom you do business. It would give users even less control of their data. My ability e.g. to retain the emails with my doctor may be at the mercy of their system (i.e., no forward, export).
@sean by using standardized protocols you'd be able to backup data as you see fit. For instance, IMAP has a plethora of tools for just that. The lock-in happens when the protocols to access the data are proprietary.
While I might prefer a signed email, what I have today is a website with a "messaging" feature and a proprietary closed source app for two proprietary phone OSes.
@ted Perhaps, but realistically would you prefer to manage and secure (and rely upon a provider to secure on your behalf) multiple (eventually many) IMAP accounts? What happens when you change doctors, or visit a specialist? Or change insurance companies, or banks? At some point, how many of these IMAP accounts would exist? Do they age out? What kind of requirements do we place on the providers to ensure the security and retention of the communications? What provider would want to take that on?
@ted Don't misunderstand me - I don't have a simple answer to the problem. If I knew a way to facilitate distributed, private, secure, end-to-end encrypted messaging that gave users total control of their data and was simple enough to use that the average consumer could do it...
I'd be a tech billionaire (hint: I'm not).
But as H. L. Mencken said, "For every complex problem there is an answer that is clear, simple, and wrong."
@ted And I know I said "...simply by ensuring messages are encrypted end-to-end." By which I meant the concept is simple. Sadly the implementation is not.
BUT neither do I think it's impossible.
@sean those are all problems I have today.
Each doctor I got to has a different medical records system with different accounts. There are some ways to get data out, but they're not in any way standard or are there ways to import. This includes specialists, and insurance companies.
I have no way to even figure out what their data retention policies are. They're mostly agreed on by local professional organizations to reduce individual liability to the point where I can't sue.
@ted Trust me, I concur that the status quo is FUBAR.
I think we all agree that a system of a few open, secure and decentralized communication protocols would be the ideal thing, but we won't have that until a large portion of the population (plus politicians!) changes their mind.
Until then, I think Ted's suggestion holds merit.
The drawback is of course that too many people only use webmail and share passwords between accounts -- but improving on that seems more realistic in the short term.
What I have today is medical providers sending sensitive data in unencrypted e-mails because they don't know that encrypted mail exists and believe it's only for ciminals and worse.
Last time I pointed the problem out, I spent 10 minutes on the phone explaining why this is not okay. I eventually gave up and just pointed at regulations which say that it's indeed not. I got a shrug and a "well if you insist..."
Case in point: Last time I mentioned we could use secure encryption and signatures for something, I was looked at in a very peculiar way. Apparently only evil people do that ... now everyone is back to pasting scans of hand-written signatures into documents and calling it "signed digitally".
Duude, what's wrong with these people?
I'm surprised (and annoyed) that universities have refused to play the role they had for e-mail for other things (like e-mail encryption... or some IM protocol, like #XMPP, or maybe Matrix these days). I'd love to have that from my uni, and it could have done a ton of good for the internet in general.
Instead, our IT department just outsourced pretty much everything to the cloud. All of our communication are belong to Microsoft now.
@Mr_Teatime Back when I was a kid, the hospital my father was working in had a garage and a team of engineers taking care of the hospital vehicles. They stopped doing so ages ago, because at some point it stopped making sense, it was not their core competency and not their business, there were specialists who could do the same more effective at better quality. Same, now, happens with IT infrastructure. Handling these things is ...
...except hospitals did not invent cars, but universities pretty much shaped the web ... and they have some specific requirements, none of which are taken are of now. We have pretty much a corporate infrastructure now and if you need to run a Linux machine, you're on your own.
They only dropped the plan to outsource the compute cluster after an external consultant found it'd cost 4 times as much. Despite the cluster admin shouting that at their faces for a year, in vain.
@Mr_Teatime I agree, but just to some point. Being into technology for research and future infrastructure purposes is one thing. Doing robust, scalable, available 24x7 hosting of e-mail or messaging infrastructure is another thing. Universities also at some point started buying pre-built computers rather than soldering and building them entirely on their own. Time moves on, maybe we just need more ethical cloud providers.
...difficult to contradict you there. Hosting bog-standard stuff with high uptime is done better and more efficiently by a dedicated company, indeed. However, forcing an entire university to use Outlook (no POP/IMAP available!) and Office 365 (not GDPR-compliant), while trating science comuting like office work (I have to manage Linux myself now, hardly time-efficient)... they've gone from trailblazing to abandoning agency in no time.
While _increasing_ the IT budget.
My analysis of what exactly the root of the problem is may be wrong, but the symptoms are plain to see: We pay more, and we get prefab service which doesn't take into account what a university does, is or should be.
All the ideas of free-thinking, breaking moulds etc.. are safely buried, at least with regards to IT, at least where I work.
here's a study on MS office and the GDPR:
My previous place (not a uni) moved IT service to a contractor, but they worked on stuff specific to us. We all had nicely configured Linux workstations. A bit on the "mature" side of things but if I needed stuff to work, it worked. Even had virtual Windows for MS office (I used LO, and that was also fine)
A server setup for the users of gould.cx to connect to the greater ActivityPub network.