DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
quote:Op woensdag 23 september 2020 09:41 schreef Syd het volgende:
[..]paniekzaaier zonder enige weet, ook je andere topic over dat je denkt dat je zogenaamd niet meer eigenaar bent over je bestanden.
Ik ga er verder niet op je overmatige smiley berichten in, maar Ziggo moest onder andere van de rechter thepiratebay blokkeren.
En wellicht moet jij je eens verdiepen in VPN verbindingen.
Ik zit al in de cern vpn waar nodig, kan 'm iedereen aanraden, zelfs de gratis variant biedt alles wat je nodig hebt. proton de makers, who else.... We hebben het dus niet over of je nog kunt internetten, maar over wie er nou eigenlijk beslist waar dat internet eindigt, en jouw interne netwerk begint.
Als je vindt dat jouw provider voor je moet gaan beslissen wat je wel en niet mag doen op je eigen nas, dan kun je dat goedvinden... ik zou het niet willen, want wie weet wat ze morgen verbieden?
Als je je vrijheid inlevert voor een stukje schijnveiligheid, dan verdien je ze geen van beide.
Rechters mogen vinden wat ze willen, maar daar hebben we het internet nou net voor gemaakt, zodat achterlijke landsgrenzen jouw en mijn vrijheid niet beperken,... en als je dat toch goed gaat vinden kun je net zo goed gelijk in China gaan wonen.
◢◤
Hetzelfde geldt hier op dit forum, in principe is het hetzelfde, wij als gebruikers mogen hier ook geen p0rno zooi plaatsen, en als jij dat wel wil dan ga jij problemen zoeken met Fok?quote:Conclusie: je hebt er geen probleem mee dat ziggo voor jou gaat besluiten welke bestanden wel, en welke niet online bereikbaar mogen zijn?
Laat ik het zo zeggen, die 'website' was niet voor publieke doeleinden. Hij was eigenlijk puur voor mezelf om altijd handig wat bestanden online bij de hand te hebben en ook om zonder poespas plaatjes te kunnen hosten of zelfs grotere bestanden (tijdelijk) te kunnen delen.quote:
Ten eerste kan ik prima op de PirateBay komen, via een VPN, ten tweede zijn er zat alternatieven, bv. showrss.info or rarbg.to om maar wat te noemen. Die sites zelf zijn niet illegaal, het is maar net wat de bezoeker er op doet. En ten laatste, Ziggo is voor mij hier de enige provider die snel internet aanbied. Anders moet ik het doen met enkel traag adsl. Nu zijn wel bezig met een glasvezel project hier in onze gemeente (www.glasdraad.nl) maar dat is afwachten of 50% van de mensen zich daarvoor aanmelden. Ik moet het nog maar zien gebeuren. Maar vooralsnog is Ziggo voor mij de enige snelle provider hier in dit kleine dorp. En eigenlijk moet ik blij zijn dat ik het kan krijgen hier want er zijn ook kleine dorpen die geen Ziggo hebben, en het moeten stellen met het trage adsl.quote:
Snap ook niet dat de kleine kabel provider uit Veendam (mijn geboortestad en waar ik ook ruim 20 jaar gewoond heb), SKV wel gewoon hun gebruikers synchroon internet kunnen aanbieden (1000/1000 is hun hoogste pakket momenteel).
De website draait weer, maar zonder downloads, enkel voor hosting en de tips en trucs. Heb de NAS ook helemaal geupdate en de auto-update functie aangezet. Alle poorten op het modem zitten dicht, op die enkele poort naar de nas toe.
[ Bericht 4% gewijzigd door TechnoCat op 25-09-2020 00:14:49 ]
quote:
[..]
Hetzelfde geldt hier op dit forum, in principe is het hetzelfde, wij als gebruikers mogen hier ook geen p0rno zooi plaatsen, en als jij dat wel wil dan ga jij problemen zoeken met Fok?
[..]
Je zegt het zelf al, dit forum, je bent hier bezoeker, en hebt het voor wat betreft de inhoud te doen met wat FOK! jou toestaat, dan wel verbiedt, om de doodsimpele reden dat dit forum niet jouw eigendom is. Wie bepaalt nu wat er NIET op jouw nas (aan internet) mag staan, ziggo of jij?
... en onder de inhoud van FOK! liggen haar servers. FOK! gaat het niet erg vinden als ik aan die servers vraag of ze met me willen kletsen, en als ze dat willen, wat dan de opties zijn die we in dat gesprek gaan gebruiken.
Let op: ... hier komen die geile RFC's weer meedoen:
Danny, of mensen namens hem, hebben de servers van FOK! instructies meegegeven voor het geval er zo'n vraag wordt gesteld, het is immers precies hetzelfde als dat jij op je linkje klikt om een copy van de inhoud op FOK! op te vragen zodat die op jouw monitor kan worden weergegeven, nadat deze copy bij jou is aangekomen.
wat is er dan echt gebeurt? Jij ( jouw pc) hebt een verzoek gedaan aan FOK! : "hebben jullie internetpagina's beschikbaar staan, en mag ik daar een copy van ontvangen zodat ik die kan lezen vanaf mijn eigen pc". " Tuuk, zegt Alicia ( server van FOK! ) terug, ik heb inhoud die ik jou kan sturen, zodat jij er aan jouw kant een leesbare FOK! pagina van kunt maken voor op je monitor, en die kun je desgevraagd krijgen, ik hoef daarvoor niet te weten wie je bent, alleen waar ik de inhoud naartoe kan sturen, en da's dus weer het IP van jouw pc. .. maar behalve "heb jij inhoud die ik mag hebben" , mag ik van Danny aan Alicia vragen wat ze allemaal nog meer kan, en bereid is mij haar dat te laten vragen. Danny heeft dat goedgevonden zodra hij de internetverbinding tussen Alicia en het internet tot stand bracht. Omdat hij erg knap is, wist hij dat zijn Alicia een aantal OPTIES aanbied, als een bezoeker haar vraagt wat ze allemaal te bieden heeft. Nu heeft Danny tegen Alicia gezegd: "... Als er ooit iemand de vraag stelt wat je allemaal nog meer kan dan inhoud verzenden, dan mag je daar de volgende OPTIES als antwoord op geven.
Alicia meldt dus desgevraagd aan mij "deze dingen kun je mij vragen" en 1 van die opties zou kunnen zijn de delete opdracht. Nu betekent dat NIET dat ik dus maar dingen mag deleten.
ik kan dat immers helemaal niet, maar Alicia wel, dat heeft ze me net verteld, en dat ik haar mag vragen om dat te ook te doen. Als ik Alicia vraag om voor mij iets te deleten, dan is dat het eerste moment dat zij terug rent naar haar instructies die DANNY haar meegegeven heeft.
...uitsluitend DIE instructies kunnen bepalen wat DANNY heeft besloten, ...dat Alicia allemaal goed mag vinden als het haar gevraagd wordt. Het stellen van de vraag is niet alleen niet strafbaar of inbreken, het is exact wat jouw pc ook heeft gedaan om te ontdekken of FOK! een webpagina beschikbaar had, waarvan ze jou een copy wil sturen. DAAROM is het dus DANNY die in zijn instructies aan Alicia besluit, wat Alicia voor jou en mij mag, en kan doen, en op welke manier en tot hoever.quote:Laat ik het zo zeggen, die 'website' was niet voor publieke doeleinden.
maar je wilde wel een publieke route ernaartoe hebben, en dan beslissen dat alleen jij daar mag lopen. .... dan loop je dus met een badmintonrokje de ijshockey arena binnen, tijdens de WK ijshockey, en zegt dan al glibberend op het ijs, dat geen van de spelers nog op de middenstip mag komen, omdat jij daar gaat badmintonnen... ... hoe groot schat je de kans dat we het stadion leegmaken, en het ijs laten smelten, zodat jij daar ongestoord een paar veertjes kan meppen? quote:Hij was eigenlijk puur voor mezelf
.... dus besloot je hem op internet te zetten, niet gehinderd door enige kennis van wie daar is behalve jij, en welke regels en DAAR gelden.quote:om altijd handig wat bestanden online bij de hand te hebben en ook om zonder poespas plaatjes te kunnen hosten of zelfs grotere bestanden (tijdelijk) te kunnen delen.
[..]
Daar is het internet dus voor, maar dan moet JIJ regelen dat er een machine is die doet wat jij wilt, en niet wat jij niet wilt, omdat het internet poep heeft aan wat jij ervan vindt,... of JIJ hebt iets toegestaan, of JIJ hebt iets verboden, en als ik het kan doen/ vragen/ deleten/ aanpassen/ verplaatsen/ neerzetten/ weghalen, dan heb JIJ dat goedgevonden, of je het nou bedoelde of niet.quote:-knip verhaal-
Simpel, hun verbinding, hun regels, maar uitsluitend vanaf ziggo tot aan jouw router in je huis.
Jij hebt het nu goed gevonden dat ziggo jouw nas als haar eigen internet beschouwde en behandelde, waarmee je dus ziggo de baas maakt over wat jij wel of niet op je eigen nas hebt staan. Wat zou je zeggen als ziggo morgen bij je aanbelt, en jou vertelt dat je geen houten trapleuning mag hebben in je huis.... sorry ziggo, ik haal mijn trap weg?[/quote]
quote:De website draait weer,
...indien bereikbaar op mijn internet, dan mag ik dus vragen aan jouw nas die die site aanbied, wat ie allemaal nog meer kan en wil, en ik kan je beloven dat daar dingen tussen zitten waarvan je niet eens kan vermoeden dat je nas het uberhaubt in zich heeft, laat staan goed vindt.quote:maar zonder downloads, enkel voor
... ALLES waarvan je nas het goedvind als ik de vraag stel.quote:Heb de NAS ook helemaal geupdate en de auto-update functie aangezet. Alle poorten op het modem zitten dicht.
goed begin!quote:op die enkele poort naar de nas toe.
... en dan zijn we DUS terug bij het begin. je weet NIET welke opties je nas heeft tot je ze allemaal hebt gevraagd, en je weet NIET welke vragen je kunt stellen als de fabrikant zijn software heeft gebaseerd op een eerder, gratis programma, dat NOOIT BEDOELD is geweest om buiten het interne netwerk te kunnen komen, en gemaakt is om onbeveiligd te delen. Diep onder alles wat jouw nas in het boekje meldt te kunnen, ka ie nog veel meer, en kan soms zelfs de rechten die hij zelf heeft uitdelen aan anderen die het vragen.DIG / Het is niet de vraag of, ...maar wanneer het gaat gebeuren, ..jou ook?
[ Bericht 0% gewijzigd door Oversight op 25-09-2020 11:44:08 ]
◢◤
quote:
[..]
.. doe even normaal man, wtf.
...kan je het niet meer aan, is het allemaal teveel voor je? ... jouw nas ook voor ons, maar we zijn er blij mee.
◢◤
Leuk verhaal @Oversight, maar ik kan de nas publiekelijk open stellen zonder dat het 'publiek' er daadwerkelijk wat mee kan. Als ik bv. bestanden op die nas zet, en ik post op de website een link naar het bestand, maar uiteindelijk blijkt dat het bestand versleuteld is dan kan het 'publiek' er weinig mee. Alleen ik kan er wat mee, omdat alleen ik het wachtwoord weet. Dan kan Ziggo, of wie dan ook wel kijken of er bestanden op staan die vol met malware zitten, maar onder versleuteling kan men het bestand simpelweg niet inlezen. Neem bv. het bekende 'Kmspico' bestand. Zo illegaal als het maar kan, maar Ziggo heeft daar nooit iets van gezegd, en de reden daarvan is waarschijnlijk omdat voordat deze clown party begon, juist dat bestand onder versleuteling zat. Maar, de meeste bestanden ben ik in principe niet eens meer nodig, je kunt je ook gewoon van het internet grabbelen dus ik hou het enkel bij een paar noodzakelijke bestanden die wat meer moeite kosten om te vinden en te downloaden, want je moet tegenwoordig door een oerwoud van "download" knoppen en advertentie meuk heen om ergens te komen en ze proberen je tig keer om de tuin te leiden door de daadwerkelijke download knop vrij onopzichtelijk te houden zodat jij op de verkeerde knop drukt en (wederom) een stukje malware installeert. Dat was ook een reden waarom ik de installatie bestanden liever direct a la minuut bij de hand wou hebben. Klikken en downloaden, zonder reclame.
Nog even terugkomend op die ene poort die openstaat naar de http server, zonder die poort open is de webserver niet toegankelijk van buitenaf. Wat jij suggereert is, trek je voordeur dicht, draai em op slot, pak de 10 reserve sleutels van je familie en vrienden af, gooi ze weg, en oh ja, gooi je eigen sleutel ook weg.
Nog even terugkomend op die ene poort die openstaat naar de http server, zonder die poort open is de webserver niet toegankelijk van buitenaf. Wat jij suggereert is, trek je voordeur dicht, draai em op slot, pak de 10 reserve sleutels van je familie en vrienden af, gooi ze weg, en oh ja, gooi je eigen sleutel ook weg.
quote:
Leuk verhaal @:Oversight, maar ik kan de nas publiekelijk open stellen zonder dat het 'publiek' er daadwerkelijk wat mee kan.
Neen, nope, negatief, helaas, dat probeer ik je nu steeds te vertellen. rien ne vas plus, uw nas is niet langer van u. Op het moment dat je je nas aan het internet verbind, is je nas deel geworden van het internet, een server.
... en die heeft verborgen opties, evenals je CPU, en je Os, combineer die met elkaar en maak vast popcorn.quote:Als ik bv. bestanden op die nas zet, en ik post op de website een link naar het bestand, maar uiteindelijk blijkt dat het bestand versleuteld is dan kan het 'publiek' er weinig mee.
Ik kom ook helemaal niet vragen om dat bestand, ik ga rechtstreeks praten met de freeware die verstopt zit in de software van je nas. ... en die geeft simpelweg toestemming voor die dingen waarvoor ie gemaakt is. .... ik weet op dat moment helemaal niet eens dat er uberhaubt ook een nas draait op die machine, en die zit mij ook niet in de weg. Ik praat tegen MIJN internet, en jouw pc praat terug, omdat je nas daar opdracht voor staat te geven, netjes volgens de regels die we in de RFC's hebben afgesproken voor delen zonder authenticatie.quote:-knip-
allemaal niet relevant dus.quote:Nog even terugkomend op die ene poort die openstaat naar de http server, zonder die poort open is de webserver niet toegankelijk van buitenaf. Wat jij suggereert is, trek je voordeur dicht, draai em op slot, pak de 10 reserve sleutels van je familie en vrienden af, gooi ze weg, en oh ja, gooi je eigen sleutel ook weg.
Nope, wat ik suggereer is dat je moet ophouden te denken dat JIJ kan besluiten waar het internet stopt en jouw nas begint, ...en wat het internet mag, of kan vragen. Jij denkt dat je nas 10 dingen kan, en dat ie niet in staat is om helemaal uit zichzelf, het alarmsysteem van je buurman in dezelfde straat aan te passen, zodat die nu Eftelingmuziekjes draait en alarmen negeert. Ik denk dat je nas een handtekening onder contracten zet, terwijl ie maar 5 van de 500.000 regels in dat contract heeft gelezen.[ Bericht 0% gewijzigd door Oversight op 27-09-2020 02:38:33 ]
◢◤
@Oversight, je doet je avatar in elk geval eer aan, want zo zie ik jou achter je pc zitten.
Wanneer laat je jezelf opnemen?
Wanneer laat je jezelf opnemen?
quote:
@:oversight, je doet je avatar in elk geval eer aan, want zo zie ik jou achter je pc zitten.
Wanneer laat je jezelf opnemen?
... tot zover de inhoud? ... jammer.
◢◤
@TechnoCat
Ik denk dat je het probleem goed opgelost hebt, de laatste Synology versies hebben geen bekende exploits, er is natuurlijk altijd een risico als je een NAS openzet naar het Internet maar zo te lezen heb je die wel geminimaliseerd nu. Als je nog meer zekerheid wil kan je op de NAS overigens ook een gratis firewall van Synology nog aanzetten.
Die vind je onder Control Panel > Security > Firewall
Wel een mooi verhaal over Ziggo overigens, dat is mij in heel wat jaren als klant gelukkig nooit overkomen
Ik denk dat je het probleem goed opgelost hebt, de laatste Synology versies hebben geen bekende exploits, er is natuurlijk altijd een risico als je een NAS openzet naar het Internet maar zo te lezen heb je die wel geminimaliseerd nu. Als je nog meer zekerheid wil kan je op de NAS overigens ook een gratis firewall van Synology nog aanzetten.
Die vind je onder Control Panel > Security > Firewall
Wel een mooi verhaal over Ziggo overigens, dat is mij in heel wat jaren als klant gelukkig nooit overkomen
quote:
Ik denk dat je het probleem goed opgelost hebt,
ik denk dat jullie allebei het probleem niet zien, je kunt niet iets toestaan en verbieden tegelijk.quote:de laatste Synology versies hebben geen bekende exploits,
..... wat ze dan weer wel hebben is freeware onder de software, om nog niet te beginnen over de hidden instructions die de gemiddelde cpu van zo'n apparaatje bevat. ... en voor wat betreft exploits, het bekende verschil tussen terrorisme en vrijheidsstrijders, ongewenst resultaat is niet de schuld van machine die de vraag stelt, maar van de kant die antwoord geeft.quote:er is natuurlijk altijd een risico als je een NAS openzet naar het Internet maar zo te lezen heb je die wel geminimaliseerd nu.
Trek de internetstekker eruit, en je hebt NUL risico over.quote:Als je nog meer zekerheid wil kan je op de NAS overigens ook een gratis firewall van Synology nog aanzetten.
Die vind je onder Control Panel > Security > Firewall
... die kijkt dan alleen naar de 0,001% van de dingen die ik je nas mag vragen, vast een veilig gevoel.[ Bericht 0% gewijzigd door Oversight op 27-09-2020 06:03:05 ]
◢◤
Die Firewall in de NAS heb ik toevallig gisteren gevonden en aangezet. Maar voorlopig host ik even geen programma's meer op de NAS, hij is enkel voor het hosten van online plaatjes en het delen van bestanden met anderen. Ik weet wel dat je ook online plaatjes kunt hosten op diverse sites, maar daar zit je toch vaak vast aan reclame voor je neus en het stelt je ook niet in staat om een bestand van 25GB zo maar even uit te wisselen.quote:
@:TechnoCat
Ik denk dat je het probleem goed opgelost hebt, de laatste Synology versies hebben geen bekende exploits, er is natuurlijk altijd een risico als je een NAS openzet naar het Internet maar zo te lezen heb je die wel geminimaliseerd nu. Als je nog meer zekerheid wil kan je op de NAS overigens ook een gratis firewall van Synology nog aanzetten.
Die vind je onder Control Panel > Security > Firewall
Wel een mooi verhaal over Ziggo overigens, dat is mij in heel wat jaren als klant gelukkig nooit overkomen
En omdat de NAS op een kleine ssd draait haalt het ding amper stroom uit het net, al heb ik nooit echt gemeten hoeveel stroom dat ding daadwerkelijk op jaarbasis gebruikt. Misschien iets eens te onderzoeken.
Volgens Tweakers doet hij met 2 schijven van 1TB niet meer dan 14,8W piekvermogen en 6,95W in slaapstand, maar dat zijn twee HDD's. In mijn ssd zit een ADATA SU 650 120GB ssd, vast geen stroomvreter.
Ben blij dat de TS doorgaat met zijn Synology NAS. Waarin de onzin die je post voorkomen kan worden en er zit geen backdoor op deze server software. Tevens maar vat dat niet direct persoonlijk op zal je post een stuk beter leesbaar zijn zonder die smileys.quote:
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
quote:
er zit geen backdoor op deze server software.
Maar wel 250.000 standaard opties die gevraagd mogen worden, cool !
◢◤
Bron? Onzin is een deur verderop.quote:
[..]
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
quote:
quote:0001 Host Software. S. Crocker. April 1969. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0001)
0002 Host software. B. Duvall. April 1969. (Format: TXT, PDF, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0002)
0003 Documentation conventions. S.D. Crocker. April 1969. (Format: TXT,
HTML) (Obsoleted by RFC0010) (Status: UNKNOWN) (DOI:
10.17487/RFC0003)
0004 Network timetable. E.B. Shapiro. March 1969. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0004)
0005 Decode Encode Language (DEL). J. Rulifson. June 1969. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0005)
0006 Conversation with Bob Kahn. S.D. Crocker. April 1969. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0006)
0007 Host-IMP interface. G. Deloche. May 1969. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0007)
0008 ARPA Network Functional Specifications. G. Deloche. May 1969.
(Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0008)
0009 Host Software. G. Deloche. May 1969. (Format: PDF, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0009)
0010 Documentation conventions. S.D. Crocker. July 1969. (Format: TXT,
HTML) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated by
RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0010)
0011 Implementation of the Host - Host Software Procedures in GORDO. G.
Deloche. August 1969. (Format: TXT, PDF, HTML) (Obsoleted by
RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0011)
0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969.
(Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0012)
0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0013)
0014 Not Issued.
0015 Network subsystem for time sharing hosts. C.S. Carr. September 1969.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0015)
0016 M.I.T. S. Crocker. August 1969. (Format: TXT, HTML) (Obsoletes
RFC0010) (Obsoleted by RFC0024) (Updated by RFC0024, RFC0027,
RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0016)
0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. August 1969.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0017)
0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. September 1969.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0018)
0019 Two protocol suggestions to reduce congestion at swap bound nodes.
J.E. Kreznar. October 1969. (Format: TXT, HTML) (Status: UNKNOWN)
(DOI: 10.17487/RFC0019)
0020 ASCII format for network interchange. V.G. Cerf. October 1969.
(Format: TXT, PDF, HTML) (Also STD0080) (Status: INTERNET STANDARD)
(DOI: 10.17487/RFC0020)
0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0021)
0022 Host-host control message formats. V.G. Cerf. October 1969. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0022)
0023 Transmission of Multiple Control Messages. G. Gregg. October 1969.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0023)
0024 Documentation Conventions. S.D. Crocker. November 1969. (Format:
TXT, HTML) (Obsoletes RFC0016) (Updates RFC0010, RFC0016) (Updated
by RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0024)
0025 No High Link Numbers. S.D. Crocker. October 1969. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0025)
0026 Not Issued.
0027 Documentation Conventions. S.D. Crocker. December 1969. (Format:
TXT, HTML) (Updates RFC0010, RFC0016, RFC0024) (Updated by RFC0030)
(Status: UNKNOWN) (DOI: 10.17487/RFC0027)
0028 Time Standards. W.K. English. January 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0028)
0029 Response to RFC 28. R.E. Kahn. January 1970. (Format: TXT, HTML)
(Also RFC0028) (Status: UNKNOWN) (DOI: 10.17487/RFC0029)
0030 Documentation Conventions. S.D. Crocker. February 1970. (Format:
TXT, HTML) (Updates RFC0010, RFC0016, RFC0024, RFC0027) (Status:
UNKNOWN) (DOI: 10.17487/RFC0030)
0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland.
February 1968. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0031)
0032 Some Thoughts on SRI's Proposed Real Time Clock. J. Cole. February
1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0032)
0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT,
HTML) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) (Status:
UNKNOWN) (DOI: 10.17487/RFC0033)
0034 Some Brief Preliminary Notes on the Augmentation Research Center
Clock. W.K. English. February 1970. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0034)
0035 Network Meeting. S.D. Crocker. March 1970. (Format: TXT, HTML)
(Status: INFORMATIONAL) (DOI: 10.17487/RFC0035)
0036 Protocol Notes. S.D. Crocker. March 1970. (Format: TXT, HTML)
(Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: UNKNOWN)
(DOI: 10.17487/RFC0036)
0037 Network Meeting Epilogue, etc. S.D. Crocker. March 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0037)
0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March
1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0038)
0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner.
March 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN)
(DOI: 10.17487/RFC0039)
0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. Heafner.
March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0040)
0041 IMP-IMP Teletype Communication. J.T. Melvin. March 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0041)
0042 Message Data Types. E. Ancona. March 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0042)
0043 Proposed Meeting. A.G. Nemeth. April 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0043)
0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. Landsberg.
April 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN)
(DOI: 10.17487/RFC0044)
0045 New Protocol is Coming. J. Postel, S.D. Crocker. April 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0045)
0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0046)
0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970.
(Format: TXT, HTML) (Updates RFC0033) (Status: UNKNOWN) (DOI:
10.17487/RFC0047)
0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0048)
0049 Conversations with S. Crocker (UCLA). E. Meyer. April 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0049)
0050 Comments on the Meyer Proposal. E. Harslen, J. Heafner. April 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0050)
0051 Proposal for a Network Interchange Language. M. Elie. May 1970.
(Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0051)
0052 Updated distribution list. J. Postel, S.D. Crocker. July 1970.
(Format: TXT, HTML) (Updated by RFC0069) (Status: UNKNOWN) (DOI:
10.17487/RFC0052)
0053 Official protocol mechanism. S.D. Crocker. June 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0053)
0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. Newkirk,
M. Kraley. June 1970. (Format: TXT, HTML) (Updated by RFC0057)
(Status: UNKNOWN) (DOI: 10.17487/RFC0054)
0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J.
Postel, S.D. Crocker. June 1970. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0055)
0056 Third Level Protocol: Logger Protocol. E. Belove, D. Black, R.
Flegal, L.G. Farquar. June 1970. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0056)
0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June
1970. (Format: TXT, HTML) (Updates RFC0054) (Status: UNKNOWN) (DOI:
10.17487/RFC0057)
0058 Logical Message Synchronization. T.P. Skinner. June 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0058)
0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. June 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0059)
0060 A Simplified NCP Protocol. R. Kalin. July 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0060)
0061 Note on Interprocess Communication in a Resource Sharing Computer
Network. D.C. Walden. July 1970. (Format: TXT, HTML) (Obsoleted by
RFC0062) (Status: UNKNOWN) (DOI: 10.17487/RFC0061)
0062 Systems for Interprocess Communication in a Resource Sharing
Computer Network. D.C. Walden. August 1970. (Format: TXT, HTML)
(Obsoletes RFC0061) (Status: UNKNOWN) (DOI: 10.17487/RFC0062)
0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0063)
0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0064)
0065 Comments on Host/Host Protocol document #1. D.C. Walden. August
1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0065)
0066 NIC - third level ideas and other noise. S.D. Crocker. August 1970.
(Format: TXT, HTML) (Obsoleted by RFC0123) (Updated by RFC0080,
RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0066)
0067 Proposed Change to Host/IMP Spec to Eliminate Marking. W.R.
Crowther. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0067)
0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB,
RET, and RFNM. M. Elie. August 1970. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0068)
0069 Distribution List Change for MIT. A.K. Bhushan. September 1970.
(Format: TXT, HTML) (Updates RFC0052) (Status: UNKNOWN) (DOI:
10.17487/RFC0069)
0070 Note on Padding. S.D. Crocker. October 1970. (Format: TXT, HTML)
(Updated by RFC0228) (Status: UNKNOWN) (DOI: 10.17487/RFC0070)
0071 Reallocation in Case of Input Error. T. Schipper. September 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0071)
0072 Proposed Moratorium on Changes to Network Protocol. R.D. Bressler.
September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0072)
0073 Response to NWG/RFC 67. S.D. Crocker. September 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0073)
0074 Specifications for Network Use of the UCSB On-Line System. J.E.
White. October 1970. (Format: TXT, PDF, HTML) (Updated by RFC0217,
RFC0225) (Status: UNKNOWN) (DOI: 10.17487/RFC0074)
0075 Network Meeting. S.D. Crocker. October 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0075)
0076 Connection by name: User oriented protocol. J. Bouknight, J. Madden,
G.R. Grossman. October 1970. (Format: TXT, HTML) (Status: UNKNOWN)
(DOI: 10.17487/RFC0076)
0077 Network meeting report. J. Postel. November 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0077)
0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. White.
October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0078)
0079 Logger Protocol error. E. Meyer. November 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0079)
0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. December 1970.
(Format: TXT, HTML) (Obsoleted by RFC0123) (Updates RFC0066)
(Updated by RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0080)
0081 Request for Reference Information. J. Bouknight. December 1970.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0081)
0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT, HTML)
(Status: UNKNOWN) (DOI: 10.17487/RFC0082)
0083 Language-machine for data reconfiguration. R.H. Anderson, E.
Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Status:
UNKNOWN) (DOI: 10.17487/RFC0083)
0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0084)
0085 Network Working Group meeting. S.D. Crocker. December 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0085)
0086 Proposal for a Network Standard Format for a Data Stream to Control
Graphics Display. S.D. Crocker. January 1971. (Format: TXT, HTML)
(Updated by RFC0125) (Status: UNKNOWN) (DOI: 10.17487/RFC0086)
0087 Topic for Discussion at the Next Network Working Group Meeting. A.
Vezza. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0087)
0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden,
S.M. Wolfe. January 1971. (Format: TXT, HTML) (Obsoleted by RFC0189)
(Status: UNKNOWN) (DOI: 10.17487/RFC0088)
0089 Some historic moments in networking. R.M. Metcalfe. January 1971.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0089)
0090 CCN as a Network Service Center. R.T. Braden. January 1971. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0090)
0091 Proposed User-User Protocol. G.H. Mealy. December 1970. (Format:
TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0091)
0092 Not Issued.
0093 Initial Connection Protocol. A.M. McKenzie. January 1971. (Format:
TXT, HTML) (Updates RFC0066, RFC0080) (Status: UNKNOWN) (DOI:
10.17487/RFC0093)
0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner.
February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0094)
0095 Distribution of NWG/RFC's through the NIC. S. Crocker. February
1971. (Format: TXT, HTML) (Obsoleted by RFC0155) (Status: UNKNOWN)
(DOI: 10.17487/RFC0095)
0096 An Interactive Network Experiment to Study Modes of Access the
Network Information Center. R.W. Watson. February 1971. (Format:
TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0096)
0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. Watson.
February 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI:
10.17487/RFC0097)
0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971.
(Format: TXT, HTML) (Updated by RFC0123) (Status: UNKNOWN) (DOI:
10.17487/RFC0098)
0099 Network Meeting. P.M. Karp. February 1971. (Format: TXT, HTML)
(Updated by RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0099)
0100 Categorization and guide to NWG/RFCs. P.M. Karp. February 1971.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0100)
0101 Notes on the Network Working Group meeting, Urbana, Illinois,
February 17, 1971. R.W. Watson. February 1971. (Format: TXT, HTML)
(Updated by RFC0108, RFC0123) (Status: UNKNOWN) (DOI:
10.17487/RFC0101)
0102 Output of the Host-Host Protocol glitch cleaning committee. S.D.
Crocker. February 1971. (Format: TXT, HTML) (Updated by RFC0107)
(Status: UNKNOWN) (DOI: 10.17487/RFC0102)
0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971.
(Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0103)
0104 Link 191. J.B. Postel, S.D. Crocker. February 1971. (Format: TXT,
HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0104)
0105 Network Specifications for Remote Job Entry and Remote Job Output
Retrieval at UCSB. J.E. White. March 1971. (Format: TXT, HTML)
(Updated by RFC0217) (Status: UNKNOWN) (DOI: 10.17487/RFC0105)
0106 User/Server Site Protocol Network Host Questionnaire. T.C.
O'Sullivan. March 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI:
◢◤
quote:- knip - heleboeleveel
quote:8899 Packetization Layer Path MTU Discovery for Datagram Transports. G.
Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker. September
2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4821, RFC4960,
RFC6951, RFC8085, RFC8261) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC8899)
8900 IP Fragmentation Considered Fragile. R. Bonica, F. Baker, G. Huston,
R. Hinden, O. Troan, F. Gont. September 2020. (Format: HTML, TXT,
PDF, XML) (Also BCP0230) (Status: BEST CURRENT PRACTICE) (DOI:
10.17487/RFC8900)
8901 Multi-Signer DNSSEC Models. S. Huque, P. Aras, J. Dickinson, J.
Vcelak, D. Blacka. September 2020. (Format: HTML, TXT, PDF, XML)
(Status: INFORMATIONAL) (DOI: 10.17487/RFC8901)
8902 TLS Authentication Using Intelligent Transport System (ITS)
Certificates. M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A.
Serhrouchni, H. Labiod. September 2020. (Format: HTML, TXT, PDF,
XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8902)
8904 DNS Whitelist (DNSWL) Email Authentication Method Extension. A.
Vesely. September 2020. (Format: HTML, TXT, PDF, XML) (Status:
INFORMATIONAL) (DOI: 10.17487/RFC8904)
8906 A Common Operational Problem in DNS Servers: Failure to Communicate.
M. Andrews, R. Bellis. September 2020. (Format: HTML, TXT, PDF, XML)
(Also BCP0231) (Status: BEST CURRENT PRACTICE) (DOI:
10.17487/RFC8906)
8907 The Terminal Access Controller Access-Control System Plus (TACACS+)
Protocol. T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant.
September 2020. (Format: HTML, TXT, PDF, XML) (Status:
INFORMATIONAL) (DOI: 10.17487/RFC8907)
8908 Captive Portal API. T. Pauly, Ed., D. Thakore, Ed.. September 2020.
(Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC8908)
8910 Captive-Portal Identification in DHCP and Router Advertisements
(RAs). W. Kumari, E. Kline. September 2020. (Format: HTML, TXT, PDF,
XML) (Obsoletes RFC7710) (Updates RFC3679) (Status: PROPOSED
STANDARD) (DOI: 10.17487/RFC8910)
8918 Invalid TLV Handling in IS-IS. L. Ginsberg, P. Wells, T. Li, T.
Przygienda, S. Hegde. September 2020. (Format: HTML, TXT, PDF, XML)
(Updates RFC5305, RFC6232) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC8918)
◢◤
.... had ik al gezegd dat alles wat is - weggeknipt - hierboven wel gewoon ook meetelt ? Ik wacht wel een een half jaartje, kan jij ff inlezen,.. dan kletsen we verder, ok?
◢◤
Niet nodig. En geen zin in. Daarnaast zijn de problemen die jij noemt ook sterk afhankelijk van wat er is ingesteld en over wat er zeg maar in het wild gebeurd. Mis bijvoorbeeld een rating van de mogelijke veiligheidslekken? Enz. En uiteindelijk kan je ook in een hutje op de hei gaan wonen zonder PC en server en dergelijke.quote:
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
quote:
[..]
Niet nodig. En geen zin in. Daarnaast zijn de problemen die jij noemt ook sterk afhankelijk van wat er is ingesteld en over wat er zeg maar in het wild gebeurd. Mis bijvoorbeeld een rating van de mogelijke veiligheidslekken? Enz.
... dit is de gebruiksaanwijzing. ... van je internetverbinding. ... soms zeggen ze het onbeleefd in 4 dikke letters, zoek maar es op.
R T F M !!!!
◢◤
Dus een zinloze post eigenlijk. Wat heeft de handleiding van je internet verbinding met een NAS te maken. Plus wat jij post nog nooit in de ziggo handleiding zien staan trouwens.quote:
[..]
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
quote:
Wat heeft de handleiding van je internet verbinding met een NAS te maken.
... waar sluit jij jouw nas op aan?quote:Plus wat jij post nog nooit in de ziggo handleiding zien staan trouwens.
Omdat dit de handleiding is die ziggo gebruikt om het internet bij jou thuis te krijgen, en deze regels in deze handleiding vertellen je dus alle opties,.... niet alleen de 10 die je fabrikant je wil laten zien. Internet is het verkeer en beschrijving van het wegen-net, dit zijn de verkeersregels en wegenkaarten en telefoonboeken, en rommelmarkten.
◢◤
Om te beginnen gewoon op me interne netwerk. Vervolgens bepaal ik dan of ik bepaalde zaken wel of niet naar het internet wil open zetten. Of zelfs naar andere apparaten binnen dat netwerk zelf. En om dan vervolgens binnen ter komen is er meer nodig dan alleen een wachtwoord.quote:
[..]
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
quote:
[..]
Om te beginnen gewoon op me interne netwerk. Vervolgens bepaal ik dan of ik bepaalde zaken wel of niet naar het internet wil open zetten. Of zelfs naar andere apparaten binnen dat netwerk zelf. En om dan vervolgens binnen ter komen is er meer nodig dan alleen een wachtwoord.
morgen verder, uiteindelijk ga je dit begrijpen, of je wilt of niet.
.... het is nu persoonlijk. ... geintje
◢◤
Zinloos want ik denk dat jij het een en ander niet begrijpt?quote:
[..]
Wordt als iemand die voortdurend dood is. De ware volgeling van bushidõ sterft elke ochtend en avond opnieuw. En wordt niet gehinderd door angst voor de dood. Yamamoto Tsunetomo's hagakure.
|
|
