tldr; xxxDAV toegang dient als keuze; transparant, instelbaar en hybride toepasbaar te zijn.
Het verleggen van grenzen door gebruikers zg ‘vrijwillig’ in de eendenfuik te houden middels manipulatie, is een uiterst verwerpelijk verschijnsel.
Daarom dient alle software van Freedom open -en transparant* zijn, dat wmb ook geldt voor de gebruikte systeemconfiguratie. Dit laatste was bv in de tijd van xs4all (voordat KPN haar BigTech greep versterkte) standaard inzichtelijk en uiterst nuttig om inzichten op te doen. Met techniek van nu, wil ik mij zelfs voorstellen dat Freedom alles - muv te herleiden privacy data - op (of in) GitHUB formaat publiceert. Gebruikers hoeven dan niet (risicovol) op servers rond-te-hupsen maar kunnen daar op/aanmerkingen via het versiebeheer proces volgen.
* Helaas is voor tal van zaken dit door een principiële keuze al niet meer mogelijk, denk aan TV, Telefonie, en deels ook de toegepaste mijnFreedom & website-omgeving waar iemand maar moet ‘raden’ hoe dat is ingericht.
De mengeling van wat zwaar(der) weegt zal ieder voor zichzelf, gelet kennis/vertrouwen & boel, moeten bepalen.
Kern is dat ‘cloud’ op hybride wijze primair moet kunnen integreren met bestaande faciliteiten (mail/dns/website) en dan als keuze ook toepasbaar is in de eigen omgeving elder (dat niet perse thuis hoeft te zijn). En ja, de locatie met wie daar dan toegang en toezicht over heeft; moet door de gebruiker instelbaar zijn. Door en met die transparantie, kan en gebruiker naar keuze ook bepalen of die het zelf of door een ander laat beheren. NB het beheer van Freedom is wmb beperkt tot het in standhouden van de toegankelijke faciliteit en het bieden van een raamwerk.
De opslag dient naar keuze ook encrypted te kunnen zijn, zodat ook een Freedom (ongeacht een dwingend verzoek) niet zonder toestemming die data dan kan ontsleutelen.
Dit laatste incl het sleutelbeheer daarvan, is weer eenvoudig te regelen met de reeds bestaande PGP functionaliteit die (on/offsite) al aanwezig is en mogelijk al toegepast wordt voor zijn/haar mail.
Met die eigen encryptie, maakt het mij - serieus - niet veel uit waar data fysiek dan staat.
On topic biedt wmb xxxDAV (dwz cal/card/web) als een aardig startpunt als voor ‘cloud’ waarbij het resource gebruik dan kan worden gedeeld over de afgenomen capaciteit van het abbo en naar keuze kan worden uitgebreid. Iemand die al die functies niet aks zinnig ziet, is natuurlijk geheel vrij om daar vanaf te zien.
De functie van cal/cardDAV is min of meer al operationeel en daaraan dan (op verzoek) webDAV toevoegen; is een kwestie van willen aanzetten. Los daarvan is het wenselijk dat de instellingen van o.a. ‘mijnFreedom’ via een APi kan plaatsvinden, zodat alles op afroep door een betreffende gebruiker (anders) kan worden ingesteld.
tldr; mijnFreedom authenticatie rules maakt (gedeelde) card/calDAV toegang geven mogelijk ZONDER het eigen account wachtwoord uit handen te moeten geven.
Een protip voor zij die de standaard aanwezige card/calDAVwillen gebruiken en die met/naar één of meer anderen (apart & los van elkaar) willen kunnen authenticeren zonder hiervoor het eigen (account)wachtwoord te moeten delen. Een issue, ik wilde niet mijn hoofwachtwoord delen, dat ik eerder had onderkend en nu dan kan oplossen .
Opgelet: de zg ‘default’ agenda die als calDAV wordt gedeeld is als eerder uitgelegd, niet dezelfde noch is die vice versa toegankelijk vanuit webmail. Aan dit probleem wordt door Soverin gewerkt. De ‘default’ cardDAV echter maakt wel onderdeel uit van de contactenlijst van de webmail.
Middels authenticatie regels op mijnFreedom wordt het mogelijk om voor cal/cardDAV één of meerdere los van elkaar staande wachtwoorden te gebruiken.
Iemand die toegang wil hebben tot de gedeelde (default) cal/cardDAV moet daarvan de url weten:
Dat te gebruiken wachtwoord is natuurlijk niet het eigen (hoofd)account wachtwoord van de mailbox maar het wachtwoord dat op dat account is in te stellen door toevoeging van een autorisatie regel. Zie MIJNfreedom - Authenticatie sessies en regels | Freedom waarin zde volgende zaken van toepassing zijn:
Beperk de specifieke regel, expliciet en uitsluitend tot “calendar”
Laat het IP-adres, ja serieus, blanco (= default werkend voor alle (inclusief interne) IP-adressen) die de agenda-serverfunctie aanroepen.
Vul het wachtwoord in dat de gebruiker van de agenda gaat/kan gebruiken.
Opmerkingen
Opmerkingen:
er mag meer dan 1 authenticatie regel worden gebruikt voor dezelfde locatie(s) om zo meerdere gebruikers toegang te geven.
het IP adres is NIET zoals iemand zou denken het externe adres waarvandaan wordt ingelogd op de agenda maar het interne (ws proxy 10.x.x.x) adres van server die de agendafunctie authenticeert. Wat dat sèc interne adres is, is verder niet van belang en het veld daarom het beste blanco of op 10.0.0.0/8 ingesteld te worden.
het bovenstaand maakt ook duidelijk dat het kan zijn dat bij sommigen hun agenda-toegang elders niet werkt. Iemand die middels externe IP adres authenticatie van generiek “all”, waar agenda-toegang onderdeel van uitmaakt, kan dan tegen toegangsproblemen aanlopen.
het te gebruiken wachtwoord moet een wachtwoord zijn dat niet voorkomt in de wachtwoordboeken die boefjes hanteren (Freedom aka. Soverin checkt gecompromitteerde en wijst dan een te vervuild wachtwoord af).
NB: over authenticatie van toegang tot diensten, is nog wel veel meer te zeggen. Iets dat ik maar overlaat aan anderen om het veilige & nuttige gebruik daarvan te ondervinden.
Niemand gaat toch zijn hoofdwachtwoord buiten de deur en laat staan op een BYOD gebruiken… toch ?
En als gezegd het volledige gebruikt en in hoeverre calDAV naast het reeds operationele cardDAV gaat integreren in/met RoundCube webmail, wordt afwachten.
Soverin liet mij onlangs weten dat zij hard aan het werk zijn. Wellicht dat Freedom vanuit haar belang Soverin kan bijstaan de voorzieningen nog beter te (ver)maken.
En ja, iemand die dit allemaal maar onzin vindt om te kunnen doen, wordt ook gelukkig om het niet te hoeven gebruiken.
Ik hoop dat dit cal/cardDAV gebruikers weer een stapje verder helpt.
Ik wil graag een stukje cloud-ruimte die ik via webdav aan mijn Fritzbox en/of aan mijn NAS kan hangen. Ik wil graag in de mijnfreedom omgeving kunnen instellen vanaf welke IP-adressen dat toegankelijk is (afgezien van gesharede mappen met een eigen URL en wachtwoord) en hoe vaak dat gebackupt wordt.
Of Nextcloud daarvoor het beste platform is en of dat aan soverin wordt geoutsourced laat ik voorlopig aan Freedom over. Zij zullen daar verstandige besluiten over nemen en die later op basis van ervaring en gewijzigde omstandigheden zonodig herzien.
Prima natuurlijk dat in ‘vertrouwen’ aan Freedom over te laten die dan wel moet (willen) weten wat de gebruiksstrekking daarvan is en ik dat dan precies het 'hoe’daarvan wil zien.
Vooralsnog ga ik actief afwachten of -en in hoeverre Freedom technisch die innovatie wil & zelf kan maken op & in de korte termijn inpast op de Toekomstvisie.
Dat Nextcloud “mooi” is, zie ik ook maar dan niet voor mijzelf. De (deel)functies FF integreren in een bestaande omgeving, zal dan nog een hele onderneming worden. Los van hobby, ook alleen duurzaam wanneer men een “bedrijf” zoekt die dat ‘nextcloud’ eco-systeem met kennis van zaken, deskundig gaat onderhouden. Maar goed, ik laat mij graag verrassen of Freedom dat dan zelf - los van Soverin, hoe dan ? - gaat doen.
Het nut van een losse clouddienst, tenzij “veel & gratis”, zie ik verder niet. Overal en nergens kan ik bergen cloudstorage organiseren.
Puur als techneut kijkend, is het de kunst om een sukje “nextcloud” als webDAV functie toe te laten voegen aan onze Freedom account zodat het vooral ook bruikbaar is voor mail & website. Dat iemand specifiek alleen zelf in te richten webDAV functie wil hebben, is dan ook opgelost. Niemand verplicht een webDAV gebruiker dat die moet mailen of websites gaat maken. Iemand die Internet lonely wil, staat het vrij om een eigen pad te zoeken.
Ja maar, dan weet ik in veel gevallen niet waar het is opgeslagen en wie daar een vinger achter kan krijgen. Als ik zorg dat het encrypted is, moet ik weer zelf zorgen voor sleutelbeheer.
Ik heb nog nergens gezien dat een cloudstorage provider de toegang kan beperken op IP-adres dat ik vanaf mijn dashboard kan instellen. En hier komt dan de meerwaarde van de dienst via de ISP: die kan instellen dat mijn cloudstorage standaard uitsluitend via mijn eigen vast IP-adres toegankelijk is, en ik kan daar dan mijn witte lijst aan toevoegen.
Helder en je (ver)meent dat een losse dienst zo moeilijk is dat een ISP daarin wat zou toevoegen door het dan maar ook in te richten.
Je hebt gelijk wanneer je redeneert vanuit puur het basisgebruik zonder zorgen. Prima om dan iets over te laten aan een ander wat altijd een keuze moet zijn en niet omdat er een suggestie zweeft; dat alleen de dienstverlener dat zg goed zou kunnen.
Dat afnemers daar vertrouwen scheppen in wat zij zelf niet zouden kunnen (of vaker; willen begrijpen) is dan ook onderdeel marketing.
Ontzorgen is vooral synoniem om te zorgen dat mensen niet zonder die geboden zorg (nog) kunnen bestaan.
Mij maakt het sws geen bal uit dat mijn onleesbaar gemaakte data in de cloud voor anderen toegankelijk is. Ze kopiëren & lezen zich maar wezenloos. Belangrijk is dat alleen ik volledig in beheer moet zijn of wie en wanneer dat kan lezen en eventueel veranderen.
Er is ook iets tegenstrijdig in privacygedrag van mensen (cognitief dissonant) die veel willen en dan de aanspraak daarop (of beter verantwoording zoals het uitkomt) elders willen beleggen. Privacy is een zelfkeuze en wat een ISP moet doen is die keuze mogelijk maken en niet om het daarover te beslissen.
Een ISP moet ongeacht doel en gebruik van data, altijd aanbieden dat iets afgeschermd kan worden voor onbevoegden. Of dat nu mail, data of iets anders is. Freedom stelt die Soverinfunctie dan ook onverkort beschikbaar. Iemand kan zelf instellen of -en vanaf welke locatie mail of gerelateerde data toegankelijk is. Inhoudelijk is er bv PGP dat eenmaal goed ingericht, onmerkbaar haar werk doet. Iemand die dat niet wil, kiest daar dan zelf voor.
Dat encryptie en sleutelbeheer ingewikkeld is, is een door onbeminden “zorgvuldig” in stand gehouden mythe omdat het doel en gebruik; tegenstrijdige belangen dienen. Zorgvuldig omdat “belanghebbenden” voor & in die data, dat vooral zelf willen bepalen.
En als afscherming wel mogelijk is, wil BigTech (en overheid) zich op eigen voorwaarden zich toegang kunnen verwerven.
Gelukkig doet Soverin en daarmee Freedom, die daar niet aan meedoen en stellen dan ook toegang en encryptie daarvan beschikbaar. een USP dat wmb veel te veel onbelicht blijft
Inzake webDAV toegang stel ik mij zo maar voor dat gebruikers net als bij webmail, imap, smtp en ook cal/cardDAV etc; dat zelf via het dashboard kunnen instellen via authenticatie regels.
Dat dashboard van mijnFreedom zou bv wmb ook kunnen worden uitgebreid om in te stellen welke externe snoeshanen al of niet bij mijn internet aansluiting mogen (binnen)komen.
Het framework als fundament daarvoor is al aanwezig, nu dat alleen nog dat verder willen - laten - uitnutten.
Als je beroepsmatig systeembeheer doet, is het nuttig en nodig om je in alle technische aspecten in te lezen en te begrijpen hoe je iets moet inrichten. Als je het echter eenmalig voor jezelf doet, moet je voor ieder onderwerp afwegen of je de tijd die daarvoor nodig is wilt investeren, om er dan later achter te komen dat als je iets wilt wijzigen je niet meer precies weet hoe het werkt, en waarom je het zo hebt ingericht. De beheersinspanning voor dat aspect wordt dan onevenredig groot. Daarom is het handig als je de keuze hebt om op dat punt ontzorgd te worden, en te kunnen terugvallen op een helpdesk, die wel voldoende dagelijkse routine heeft om te weten waar je naar moet kijken.
Voor welke aspecten je liever ontzorgd wil worden, en wat je beslist zelf wilt regelen is voor ieder verschillend. Keuze vrijheid is daarom uitgangspunt. Die keuze vrijheid moet wat mij betreft ook gelden voor het gebruik van de infrastructuur (kabel/AON/GPON/XGSPON) en van het TV-platform (DRM) en STB. Er zullen wellicht nog wel een paar rechtszaken gevoerd moeten worden tegen de grote monopolies; alles op zijn tijd. Modemvrijheid is afgedwongen, maar nog niet overal toepasbaar. Een aantal andere vrijheden moeten nog op de oligopolisten worden veroverd.
Vervolgens is het nu handig wanneer op tal van aspecten Freedom, al dan niet via partners een dienst of feature aanbiedt, dat voor een grote groep gebruikers goed genoeg is, en daarnaast de keuze vrijheid om die dienst elders af te nemen met specificaties die beter passen bij jouw specifieke situatie en wensen. Van de helpdesk kan dan niet verwacht worden dat ze detailkennis hebben van alle alternatieven voor wat ze zelf aanbieden, maar daarvoor is dan de community (resp. een wiki) met tutorials als aanvulling op de helppagina’s
Yep het gaat om de keuze simpel maar ook diepgaand bij & in Freedom gebruik te maken van diensten. Ik blijf er vanuit gaan dat Freedom qua “diensten” niet gaat vervallen in een eenheidsworst die elders de KPI’s.
Dat 80% bedient en de rest die wat zg bijzonders wil naar elders wordt verwezen. Dat een bedrijf functies in toegepaste OpenSource niet wil faciliteren, is een verwerpelijke keuze die gebruikers daarmee dan koeioneert en onvrij maakt.
Dat bedrijven het spelletje doen dat (tegenwoordig) matzwarte lak duurder is dan infrarood geharde metallic-duotone, is vooral door ‘marketing’ gedreven waar imo een Freedom juist niet in moet (terug)vallen. Dat een gewenste functie niet kan worden toegepast op grond van techniek (of beheer) moet dat met wederhoor; transparant worden uitgelegd.
Dat een bedrijf de helpdesk support beperkt tot zeg level 1 of 2, kan ik mij best voorstellen omdat idd diehards zelf toch wel gaan rondneuzen op indepth bronnen. Voor inhoudelijk zaken die de helpdesk kennis overstijgt, moet Freedom zorgen dat die zaken dan worden gevolgd bij en door haar partners.
Freedom moet juist open interfaces bieden om alles op maat te kunnen inrichten. En daarnaast voor van alles een “default” oplossing die voor 80% van de gebruikers goed genoeg is, of althans genoeg om mee te beginnen of op te kunnen terugvallen als iets niet bevalt of niet meer werkt.
Iedere gebruiker bepaalt zelf voor welk onderdeel hij de ontzorgd wil worden door Freedom, en voor welk onderdeel hij zijn eigen keuzes maakt, zonder daarin belemmerd te worden door de keuzes die hij voor andere onderdelen maakt.
Ik denk eerder dat met ‘interface’ ws eerder een API haalbaar is zodat de standaarddiensten, ik denk vooral wat men doet met mijnFreedom dat nu per browser verloopt, kunnen worden bestuurd en functioneel toegepast voor eigen wensen en toepassingen.
Het zou fijn zijn wanneer ik dan on-the-fly via bv XML een ‘alias’ of ‘cname’ kan wijzigen of de status kan opvragen van een resource.
Dit even los dat de aanwezigheid van xxxDAV (vooral webDAV) daarin naar keuze kan worden ingezet. Hetzij voor iemands muziek, mijn part TV opname of in mijn geval gekoppelde data-opslag om via die weg de website-functie te kunnen inrichten en/of mail attachments uit te wisselen.
Maar goed, laat Freedom beginnen met formeel Cal- & CardDAV beschikbaar stellen (dat er immers al is) en dan als volgende stap daarbij webDAV faciliteren (in & binnen de bestaande ruimte van het account.
Wij hier al best veel issues met CalDAV, afspraken in de agenda’s gezet en even later zijn ze gewoon plots weg, of niet in sync op andere devices.
Nu heb ik er niet over liggen klagen, omdat ik weet dat het nog niet officieel ondersteund wordt, maar vrouwlief begint het al aardig irritant te vinden.
Hier idem… en ik maar als missionaris het product promoten… en voor wat echt belangrijk is, dus nog steeds rondzwem in de fuik van Google
In contracten staat het idd nog niet en daarom dat ik op grond van wat WEL zou moeten kunnen (nl: adresboek bewerken) in/met webmail en niet functioneert; daarover “klaag”. In Webmail kan ik aantoonbaar geen contacten bewerken.
Dit om te voorkomen dat een helpdesker mijn ticket gemakshalve* wegbonjourd met “doen we (nog) niet (meer)”
Gaat ongetwijfeld wel weer goed komen, dingen werken vaak al (wat) beter dan toen dit helemaal een puinhoop was.
Het is wel wat vermoeiend om tickets te moeten maken om via level 1,2 en 3; ergens bij een te drukke beheerder uit te komen dat die kick-ass doet.
Het kost dus dagen van doorzeuren en via het proces; formeel “druk” zetten voordat iets weer gaat werken.
Ondertussen vaker meegemaakt - bij/met andere issues - dat men moet worden overtuigd dat er een storing is (het bekende gedoe van we willen screenshots).
Vervelend wordt wanneer een beheerder iets zelf niet direct ziet als een probleem omdat die het niet (h/er)kent (laat staan hanteert). Dit gaat de laatste tijd gelukkig wel beter.
//-- ik parafraseer even wat weg --//
Het kost ook tijd om het gebruiksbelang duidelijk te maken aan de betrokken organisaties zoals Freedom maar ook Soverin hier(in) een serieus USP zien voor xxxDAV support.
→ mail maar ook je contactlijst, agenda en data veilig bij Freedom en daarmee niet langer geopenbaard aan meekijkende BigTech.
Technisch is het lastig(e) dat de implementatie - inhoudelijk, xxxDAV is geen Rocket science meer - stabiel moet worden.
Probleem lijkt dat men mogelijk cal/carddav apart ergens op een instabiele server (erbij) draait en wanneer onbereikbaar, die hopeloos qua intranet eruit stuitert met onze 504. Hetzelfde zien exact zo wanneer we data of websites willen exporteren dat steeds weer kapotloopt omdat men de verkozen server-2-server niet goed weet te managen.
Bijkomend probleem is dat men structureel moeite heeft, hoe de (SSO) authenticatie credentials binnenin het intranet autoriseert. Binnenin Soverin kan dit werken maar gaat vervolgens mis in multitenant modus voor bv een Freedom. Kortom, de toegangsarchitectuur is niet op orde.
Autorisatie op grond van authenticatie is relatief makkelijk zolang de (sleutel)techniek binnen/in op één (cluster)server van één gebruiker en bijbehorende transactie blijft.
Het is ingewikkelder wanneer de ingelogde authenticatie van een gebruiker apart moet worden geautoriseerd op/voor/naar andere servers - dwz aparte cal/carddav - dan waarop fysiek was ingelogd.
Men gaat immers ook niet willen dat intranet verkeer, onveilig dwz zonder autorisatie kan (ver)lopen omdat de voordeur ergens van het slot was gehaald.
Ook het offline doen van cal/carddav - d.i. via Thunderbird - lijkt mij via een aparte proxyserver te gebeuren waarmee ook die onbereikbaarheid kan worden verklaard.
Kreeg een mail van de helpdesk dat het probleem is opgelost.
Mooi werk en idd, adresboek (en daarmee de res tvan xxxDAV) mits ingelogd met hoofdaccount (en/of Thunderbird) doet het weer.
Adresboek bewerken middels Webmail authenticatie mislukt nog steeds omdat intranet server 10.10.3.11 kennelijk de toegang dan afwijst.
Dat heeft over het algemeen weinig met calDAV te maken maar meer met de gebruikte clients die geen merge doen, maar uistsluitend een upload van de eigen database… Alle calDAV clients moeten ervan uitgaan dat de centrale calDAV server de hoofd database heeft.
en dat ze alleen de eigen updates mogen toevoegen… bij een shared agenda moet dan natuurlijk de ene gebruiker niet de agenda items van de ander verwijderen… want dat is een expliciete verwijdering.
Ik heb dan ook een prive agenda (dat heeft elk account) en voeg daar dan ook enkele shared agenda’s toe.
Een shared agenda kan ook een gezins/apparaat/ruimte/… zijn… (zodat iemand die kan “reserveren” )
In mijn client krijgen de afspraken in de verschillende agenda’s een eigen kleur en staan gezamenlijk bij elkaar.
Ik vind het raar als het aan de clients zou liggen, dan heb ik drie clients (Thunderbird, iCalendar en Google Calendar) die alleen bij deze agenda issues vertonen.
Als het goed is heeft elk agenda item een last-updated timestamp en kan elke client die lokaal vergelijken met de eigen database.
De sync moet dan ook Per agenda item gedaan worden. Niet alles in een keer.
Alleen items waarvan de locale timestamp later is dan de centrale versie mag geupdate worden.
(update is ook agenda item verwijderen…, timestamp van verwijdering moet bewaard blijven tot na synchronisatie).
(dus een ical file transfer is niet de correcte synchronisatie methode).
voor zij die de standaard aanwezige card/calDAVwillen gebruiken en die met/naar één of meer anderen (apart & los van elkaar) willen kunnen authenticeren zonder hiervoor het eigen (account)wachtwoord te moeten delen. Een issue, ik wilde niet mijn hoofwachtwoord delen, dat ik eerder had onderkend en nu dan kan oplossen .
truc…
zijn hoofdwachtwoord buiten de deur en laat staan op een BYOD gebruiken… toch ?
