Re: On The Safety of Publicly Open-Registration Solid Servers

po 2. 10. 2023 v 12:48 odesílatel Matthias Evering <me@evering.eu> napsal:

> Am 02.10.2023, 11:16 Uhr, schrieb Sarven Capadisli <info@csarven.ca>:
>
> > Emelia, thanks for raising concerns that's part of the broader social
> > web, and ways in which we can improve work from our (CG and ecosystem)
> > end.
> >
> > I'd like us (the CG) to follow-up constructively. I don't want this
> > information to get lost in the emails (this mailing list is "used for
> > general discussions and announcements" [1]).
> >
> > It would at first glance may appear that your recommendations may not
> > specifically fit under the scope of the CG but it is not out of scope
> > either [2]. But, I do acknowledge that there are takeaways we can break
> > down and work on in the context of the CG and are in scope (and if not,
> > why not, right?). And, this work or information is not limited to the
> CG
> > and should be further developed as part of the Solid Project.
> >
> > Here are some suggestions:
> >
> > * Storage Terms of Service Template [3] that can be adopted by storage
> > providers, in addition to their local laws, in the spirit of the Solid
> > project.
>
> Emelia, Melvin, Sarven and List/CG:
>
> with interest I read about security concerns.
> these seem to be well-profound.
> as first action item for me I see the Terms of Service, which I will add
> to my/our production system.
>

Hi Matthias

Managing a public server with a focus on user data protection requires
attention to various tasks including establishing Terms of Service, domain
management, server management, handling updates, SSL certificate
management, and user support, among others. Our experience with
solid.community, which received over 50,000 signups, highlighted these
challenges.

It's a bit harder than mastodon I think, which is why we had a team (mostly
Alain) to share the load with the original solid.community

Something I'll share which I dont think I have told anyone before.  I had
the misfortune that my domain provider (domainmonster) went out of business
while I was running that domain.  Consequently bad things happened.  When I
tried to renew a domain it sometimes didnt register in the control panel.
When I dropped a domain again it would renew and charge my credit card when
I didnt want it.  One domain was actually a typo which I wanted to get rid
off, but they kept renewing it, and billing me!  They had no support since
they were going out of business.  It was a tough situation.

Also the DNS control panel was limited and it was hard to renew wildcard
certificates.

I knew I wanted to move it to a better domain, but that would have been
down time for the whole site.  And we had 100% uptime for a quarter of a
decade.  Given the slow responsiveness of the support staff, I knew it
could be 1-2 days to 1-2 weeks.  So it was hard to find a window to move
it, I wrote dozens of emails, too.

Eventually I transferred the domain to namecheap (this also coincided with
a time I got sick during covid, and took the site offline).  Namecheap have
been a reliable provider for me, and they have an advantage you can
delegate people to update the DNS or manage the server, which allows a team
effort.  But, by the time solid.community was back up, fortunately only 1-2
days later, our data was gone, and I was locked out.  I offered to keep the
same domain for users, but the new domain sc.net had assumed control of the
data.

The situation for hosting is a lot better today, given that terms of
service exist, servers are cheap, letsencrypt has tooling, and DNS can be
automated.  There are many more possibilities for team collaboration, and
server costs are relatively low.

However, one thing that concerns me is how to deal with people spamming the
server, hence my inquiry on whether an invite system is possible, or
something similar.  In any case, a community server would likely be low
volume from legit users right now, as solid is less active than it was back
then.


>
> > * Best Practises and Guidelines for storage providers, taking different
> > types of invitations, registrations, and data policy and rights (e.g.,
> > [4][5]) which also goes together with what's in scope as per
> "(meta)data
> > models.." [2]. And more broadly on hosting, infrastructure and systems
> > (e.g., part of Web Sustainability Guidelines [6]).
> >
> > * Further develop Use Cases and Requirements [7][8][9][10] (and other),
> > taking processing (e.g., generally [11] but with further considerations
> > towards ensuring trust, safety, and moderation).
>
> I will follow closely and give my best efforts.
>
> > May I ask you and others interested in this work to follow-up in one of
> > those space? It is not an exhaustive list and may not entirely address
> > the concerns you're raising so I can encourage everyone to take up this
> > work in one of the, or to be created, workspaces.
>
> as next I will follow the citations.
>
> > Lastly, some of this work is no entirely on the Solid project to solve,
> > so please also consider following-up with existing groups and
> > communities out there both in W3C and elsewhere. Hint: this would be a
> > good CG Task Force if we can distil the needs further.
> >
> > Huge thanks!
>
> I hope we can address the Behavioural as well as the technical issues.
> lastly let me assure that I feel welcomed in our diverse community I
> could
> not do the work without crowdhelp.
>
> kr, @ewingson
>
> > [1] https://www.w3.org/community/solid/charter/#communication
> > [2] https://www.w3.org/community/solid/charter/#scope
> > [3] https://github.com/solid/specification/discussions/577
> >
> > [4] https://www.w3.org/TR/odrl-model/
> > [5] https://w3id.org/dpv
> >
> > [6] https://w3c.github.io/sustyweb/#hosting-infrastructure-and-systems
> >
> > [7] https://github.com/solid/user-stories
> > [8] https://solid.github.io/authorization-panel/authorization-ucr/
> > [9] https://solid.github.io/notifications-panel/notifications-ucr
> > [10] https://github.com/solid/specification/issues/317
> >
> > [11] https://github.com/solid/specification/issues/394
> >
> > -Sarven
> > https://csarven.ca/#i
> >
> >
>
>
> --
> Matthias (@ewingson)
>
>