PySkyWiFi: 장거리 비행에서 무료 저속 와이파이 만들기

 (robertheaton.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • PySkyWiFi는 결제 전에도 열리는 항공 마일리지 계정 프로필 필드를 임시 저장소로 써서, 장거리 비행 중 HTTP 요청과 응답을 아주 느리게 왕복시키는 실험임
  • 초기 프로토타입은 계정의 이름 필드를 갱신·폴링해 채팅을 만들고, 이어 지상 데몬이 STOCKPRICE: APPL 같은 요청을 읽어 결과를 되돌려주는 방식으로 확장됨
  • 최종 구조는 비행기 안의 sky proxy와 인터넷에 연결된 ground daemon으로 나뉘며, 로컬 curl 요청의 X-PySkyWiFi 헤더로 대상 URL을 전달함
  • 전송은 HTTP 요청을 작은 청크로 쪼갠 뒤 DATA, ACK, END 세그먼트와 6자리 시퀀스 번호로 순서를 맞추는 방식임
  • 실제 항공사 계정에 자동 요청을 계속 보내는 방식은 피했고, 최종 테스트는 GitHub Gist로 블로그 홈페이지를 curl 호출해 몇 분 뒤 HTML 응답을 받는 수준에 머무름

결제 전 Wi-Fi 포털에서 발견한 우회 통로

  • 비행기 Wi-Fi 로그인 페이지는 결제를 요구했지만, 결제 전에도 항공 마일리지 계정 로그인은 무료로 허용함
  • 프로필 편집 화면의 이름 필드를 보고, 이 값을 외부와 주고받는 작은 통신 채널처럼 사용할 수 있다고 봄
  • 구현 언어는 처음에 Go를 생각했지만, Python을 쓰면 도구 이름을 PySkyWiFi로 붙일 수 있어 Python을 선택함
  • 소스 코드는 PySkyWiFi에 공개됨

프로토타입 1: 이름 필드로 만든 인스턴트 메시징

  • 같은 항공 마일리지 계정에 두 클라이언트가 로그인한 뒤, 이름 필드를 번갈아 갱신하고 읽는 방식으로 메시지를 주고받음
    • 한쪽이 이름을 Hello how are you로 바꾸면 다른 쪽이 이를 읽음
    • 다시 Im fine how are you로 바꾸면 첫 번째 쪽이 답장을 확인함
  • UI에서 직접 이름을 바꾸는 방식은 번거로워 커맨드라인 도구로 자동화함
    • 도구는 웹사이트에 로그인해 테스트 계정의 이름 필드를 메시지로 갱신함
    • 몇 초마다 이름 필드를 폴링하고, 값이 바뀌면 상대의 답장으로 출력함
  • 실제 항공 마일리지 계정에는 더 이상 자동 데이터를 보내지 않기로 하고, 이름을 빠르게 약 10번 갱신해 모두 성공하는지만 확인함
    • 이 결과는 해당 계정이 요청 속도나 개수에 대해 제한을 걸지 않았을 가능성을 보여줌
  • 이후 개발은 GitHub Gists와 로컬 파일로 같은 원리를 재현해 진행함
    • 항공 마일리지 계정보다 반복 개발이 빠르고 쉬웠기 때문임

프로토타입 2: 지상 데몬으로 외부 정보 가져오기

  • 다음 단계에서는 지상 또는 클라우드의 인터넷 연결 컴퓨터에서 데몬을 실행함
  • 데몬은 항공 마일리지 계정의 이름 필드를 계속 폴링하며, 비행기에서 보낸 구조화된 요청을 찾음
    • 예: STOCKPRICE: APPL
    • 예: SCORE: MANUNITED
  • 새 요청을 발견하면 데몬이 이를 파싱하고 관련 API로 정보를 가져온 뒤, 항공 마일리지 계정을 통해 비행기 쪽으로 되돌려줌
  • 이 단계부터 단순 채팅을 넘어 주가나 스포츠 점수 같은 실시간 정보 조회가 가능해짐

sky proxy와 ground daemon으로 구성한 전체 구조

  • PySkyWiFi는 HTTP 요청 전체를 항공 마일리지 계정으로 밀어 넣고, 지상 컴퓨터가 실제 HTTP 요청을 수행한 뒤 응답을 같은 방식으로 올려보내는 TCP/IP 유사 프로토콜임
  • 구성 요소는 두 개임
    • sky proxy: 비행기 안 노트북에서 실행되는 프록시
    • ground daemon: 집이나 클라우드의 인터넷 연결 컴퓨터에서 실행되는 데몬
  • 사용 전 지상 데몬을 먼저 실행하고, 비행기에서 Wi-Fi에 연결한 뒤 노트북에서 sky proxy를 실행함
  • 사용자는 curl 같은 도구로 로컬 프록시에 HTTP 요청을 보냄
    • 예: curl localhost:1234 -H "X-PySkyWiFi: example.com"
    • 실제 대상 URL은 X-PySkyWiFi 커스텀 헤더에 넣음
  • 지상 데몬은 X-PySkyWiFi 헤더를 제거하고 이를 대상 웹사이트 라우팅에 사용함
    • 요청 본문과 다른 헤더는 그대로 전달함
  • 모든 과정이 끝나면 일반 인터넷 요청처럼 HTTP 응답을 받지만, 항공기 네트워크 상태에 따라 요청이 몇 분 동안 멈춰 있고 속도도 초당 몇 바이트 수준일 수 있음

청크, ACK, 두 번째 계정으로 HTTP 왕복하기

  • sky proxy는 curl 요청을 받아 전체 HTTP 요청을 청크로 나눔
    • 항공 마일리지 계정의 이름 필드에 한 번에 담을 수 있는 양이 작기 때문임
  • 각 청크는 첫 번째 항공 마일리지 계정의 이름 필드에 순서대로 기록됨
  • ground daemon은 계정을 폴링하다가 새 청크를 발견하면 읽고, 다음 청크를 보내도 된다는 수신 확인을 남김
  • 전체 HTTP 요청이 재조립되면 ground daemon이 인터넷으로 실제 요청을 보냄
  • HTTP 응답은 반대 방향으로 같은 절차를 거침
    • ground daemon이 응답을 청크로 나눠 보냄
    • 구현을 단순하게 하기 위해 응답 청크는 두 번째 항공 마일리지 계정을 사용함
    • sky proxy가 청크를 읽어 HTTP 응답을 재조립하고 원래 curl 호출에 반환함

전송 계층과 네트워크 계층의 역할 분리

  • PySkyWiFi의 통신 로직은 전송 계층과 네트워크 계층으로 나뉨
  • 전송 계층은 어떤 데이터를 어떤 순서로 보낼지 결정함
    • 긴 메시지를 작은 청크로 나누는 방식
    • 수신자가 다음 청크를 받을 준비가 됐음을 알리는 방식
    • TCP와 아주 느슨하게 비슷한 역할
  • 네트워크 계층은 전송 계층이 정한 데이터를 실제 저장소에 쓰고 읽음
    • 항공 마일리지 계정, 로컬 파일, Discord 프로필 같은 저장소가 될 수 있음
  • 이런 분리는 새 항공사 마일리지 플랫폼을 붙이기 쉽게 만듦
    • 새 네트워크 계층만 구현하면 전송 계층은 그대로 유지됨
    • 테스트용 네트워크 계층은 항공 마일리지 계정 대신 로컬 파일을 읽고 쓸 수 있음

DATA, ACK, END로 맞추는 전송 규칙

  • PySkyWiFi 전송 연결은 두 개의 파이프로 구성됨
    • 각 클라이언트는 쓰기용 SEND 파이프와 읽기용 RECV 파이프를 가짐
    • 항공 마일리지 계정을 파이프로 사용할 수 있음
  • PSWF 클라이언트는 특정 순간에 보내기 또는 받기 중 하나만 가능함
    • 보내기 모드에서는 상대가 보낸 데이터를 보지 못함
    • 받기 모드에서는 데이터를 보내도 상대가 보지 못함
    • TCP처럼 언제든 양방향 송수신하는 방식은 아님
  • 긴 메시지는 DATA, ACK, END 세그먼트로 전송함
    • DATA: 문자 D, 6자리로 패딩된 시퀀스 번호, 실제 청크 데이터로 구성됨
    • 예: D000451adline": "Mudslide in Wigan causes m
    • ACK: 문자 A와 확인 대상 6자리 시퀀스 번호로 구성됨
    • 예: A000451
    • END: 문자 E 하나로 메시지 종료를 표시함
  • 송신자는 DATA를 보낸 뒤 해당 시퀀스 번호의 ACK를 받을 때까지 기다림
    • A000451을 받으면 000451 청크가 처리됐다고 보고 000452 청크를 보냄
  • 수신자가 END를 보면 메시지가 끝난 것으로 처리하고, 송신자와 수신자가 역할을 바꿈

네트워크 계층 구현 인터페이스

  • 네트워크 계층은 데이터를 저장소에 쓰고 읽는 단순한 인터페이스를 제공함
  • 필수 연산은 두 개임
    • send(msg: str): msg를 저장소에 기록함
    • recv() -> str: 저장소에서 메시지를 읽음
  • 항공 마일리지 기반 구현에서는 두 연산이 계정의 이름 필드를 쓰고 읽는 동작이 됨
  • 필수 속성도 두 개임
    • sleep_for: RECV 파이프를 폴링하는 사이에 전송 계층이 대기할 초 단위 시간
    • segment_data_size: 한 세그먼트에 담을 문자 수
  • sleep_for는 파일 같은 테스트 구현에서는 낮게 둘 수 있지만, 항공 마일리지 계정 구현에서는 원격 서버에 너무 많은 요청을 보내지 않도록 최소 몇 초로 둬야 함
  • segment_data_size는 사용하는 항공 마일리지 계정 필드의 최대 크기와 같아야 하며, 예시는 약 20자임
  • 선택 훅은 두 개임
    • connect_send(): SEND 파이프 초기화 시 호출되며, 항공 마일리지 구현에서는 사용자명과 비밀번호로 로그인해 쿠키를 얻는 데 사용될 수 있음
    • connect_recv(): RECV 파이프 초기화 시 호출됨

base26 인코딩과 대역폭 개선 아이디어

  • 항공 마일리지 HTML 폼은 이름에 알파벳이 아닌 문자를 허용하지 않을 수 있음
    • Stephen은 허용될 수 있음
    • GET /data?id=5는 거부될 수 있음
  • 이를 피하려면 네트워크 계층이 세그먼트를 항공 마일리지 계정에 쓰기 전에 base26으로 인코딩해야 함
    • base26은 문자열을 A부터 Z까지의 문자만 사용해 표현함
    • 바이트 문자열을 큰 숫자로 바꾼 뒤, 26진법 숫자처럼 A~Z 문자로 표현함
    • 예: b26_encode("Hello world")는 CZEZINADXFFTZEIDPKM를 반환함
  • 전송 계층은 이 인코딩을 알 필요가 없음
    • 네트워크 계층이 바이트를 base26으로 바꿔 기록하고, 읽을 때 다시 바이트로 복원함
  • base26은 문자열을 상당히 길게 만들어 대역폭을 줄임
    • 대문자와 소문자를 모두 쓰는 base52를 사용하면 더 짧아질 수 있지만, 이는 버전 2 개선사항으로 남겨둠
  • 대역폭은 세그먼트 크기를 키워 늘릴 수 있음
    • 필드 1개가 20자만 저장할 수 있어도, 20자 필드 5개를 동시에 쓰면 100자 세그먼트를 한 요청으로 보낼 수 있음
    • 수신자는 5개 필드를 한 요청으로 읽어 다시 이어 붙일 수 있음

HTTP CONNECT가 남긴 개선 여지와 최종 테스트

  • PySkyWiFi는 수동으로 HTTP 요청을 주고받는 대신 HTTP CONNECT requests를 사용하면 더 나은 터널을 만들 수 있음
  • CONNECT는 대부분의 HTTP 프록시가 사용하는 방식이며, 이를 쓰면 PySkyWiFi가 시스템 수준 프록시처럼 동작해 브라우저 요청도 처리할 수 있음
  • CONNECT를 쓰면 PySkyWiFi가 대상 웹사이트와 직접 TLS 연결을 협상하므로, 항공 마일리지 계정을 통과하는 트래픽이 암호화됨
  • 단점은 구현 작업이 훨씬 많아진다는 점임
  • 최종 테스트에서는 GitHub Gist를 통해 데이터를 터널링해 curl로 블로그 홈페이지를 불러왔고, 몇 분 뒤 HTML 응답을 받음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 수십 년 전 배우자가 Google Voice 문자를 Gmail 받은편지함에서 바로 읽고 답장하는 식으로 썼는데, 휴대폰을 싫어해서 무제한 3G가 붙은 옛 Kindle Keyboard를 들고 다녔음
    Kindle의 간단한 브라우저로 저사양 Gmail 화면을 열 수 있어서 월 요금 없는 SMS 기기처럼 쓸 수 있었고, 문제는 새 문자 알림뿐이었음
    그래서 탈옥 후 홈 화면에 카운터를 붙이려다, Amazon 계정에서 바꿀 수 있는 Kindle 기기 이름 옆에 카운터를 두면 되겠다고 떠올림
    홈 서버에서 브라우저 자동화로 Amazon에 로그인해 기기 이름을 My Kindle (x)로 바꾸게 했고, x는 읽지 않은 Google Voice 문자 수였으며 Kindle은 1분 안에 홈 화면 이름을 갱신해서 몇 년간 잘 동작함

    • 3G Kindle의 AT&T 청구서는 엄청났던 걸로 기억함
      몇 바이트만 줄여도 백만 달러쯤 절감되는 수준이었다고 기억함
    • 여행 가는 동료에게 Kindle Keyboard를 빌려줬다가 멕시코에서 도난당했음
      당시엔 거의 가장 오래된 동작 가능한 Kindle이었을 테니, 도둑은 그냥 가방 안에 있던 걸 집어간 듯함
      나중에 벼룩시장에서 20달러짜리 Kindle Keyboard를 또 찾았지만 6개월 뒤 배터리가 죽었고, 아직 본체는 갖고 있어서 교체 배터리 비용이 궁금함
    • 그 무료 3G는 정말 대단했음
      브라우저로 Gmail을 간신히 쓸 수 있었고, 여러 zmachine ROM 중 골라 텍스트 게임을 할 수 있는 Kindle 친화적 Zork 웹사이트도 만들었음
      몇몇 뉴스 사이트에 소개되면서 어느 정도 반응도 있었음
    • 나도 이걸 했음
      Kindle 이름을 바꾸는 영리한 통합은 없었지만, 무제한 3G가 붙은 Keyboard Kindle로 한동안 문자를 보냈음
    • 스마트폰을 사기 전엔 장거리 자동차 여행에서 Kindle Keyboard로 길찾기를 했음
      Google Maps 웹사이트를 간신히 돌릴 수 있었음

  • 예전에 이탈리아에서 그리스로 가는 약 20시간짜리 페리를 탔는데, 위성 인터넷 기반 유료 Wi-Fi가 있었지만 결제하고 싶진 않았음
    결제를 위해 Stripe 접근은 열려 있었고, 알고 보니 stripe.com의 개발 문서 등 모든 페이지에 접근 가능해서 이미지를 반복 다운로드하며 대역폭을 낭비하기 시작함
    그러다 Stripe가 동작하려면 Fastly CDN 접근이 필요하고 Reddit도 Fastly를 쓴다는 걸 떠올렸고, Stripe에 연결한 뒤 HTTP Host 헤더를 reddit.com으로 바꾸니 Reddit을 볼 수 있었음
    이미지는 i.redd.it가 Fastly가 아니라 안 됐지만, /etc/hosts에서 old.reddit.com을 Stripe의 Fastly IP에 연결하고 무서운 TLS 오류를 무시하니 로그인도 가능했음

    • 그런 식으로 문서 몇 기가바이트를 내려받아 피해를 주는 대상은 그 서비스를 돈 내고 쓰는 비행기 안 승객들일 가능성이 큼
      느려진 연결 때문에 다시는 사지 않게 되면 제공 회사도 피해를 보고, Stripe의 업로드 대역폭 비용도 늘릴 수 있음
      나는 주변 사람에게 악영향을 줄까 봐 셀룰러에서도 다운로드를 피하는 편임
    • 그런 행동에서 정확히 뭘 얻는지 모르겠음
      차단된 연결에서 어디까지 접근 가능한지 탐색하는 지적 실험은 이해하지만, 일부러 대역폭을 낭비하는 건 공중화장실 수도꼭지를 열어 물을 버리거나 변기를 막아 넘치게 하는 것과 비슷함
    • 그건 도메인 프론팅(domain fronting) 이고, 지금은 모든 대형 CDN에서 막혀 있음
      https://en.wikipedia.org/wiki/Domain_fronting
    • 다음에는 유료 서비스를 감히 제공했다는 이유로 호텔 수도를 틀어놓고 교훈을 줬겠네
    • 왜 돈 내기 싫은 서비스에 대해 첫 본능이 기능을 악용하거나 저하시키는 쪽이었는지 궁금함

  • 몇 주 전 쇼핑몰에서 아이들 수업을 데려다주고 무료 Wi-Fi를 쓰려 했는데, 노트북 로그인은 성공했지만 인터넷은 안 된다고 나왔음
    기본 게이트웨이를 확인하니 Cisco 모뎀으로 연결됐고, 진단 도구와 연결된 기기 목록이 보였지만 인터넷 연결은 꺼져 있었음
    휴대폰으로 모델을 검색하니 관리자 계정은 일련번호이고 비밀번호는 비워두는 방식이라 했고, 예시 패턴도 있었는데 연결된 기기 중 하나의 이름이 딱 그 패턴처럼 보였음
    그대로 로그인해 인터넷 버튼을 켰고 15초 뒤 초록색이 됐으며, 장치 비밀번호도 새로 설정함

    • 가족을 방문했다가 이웃의 보안 안 된 Wi-Fi에 접속해 회사 VPN에 들어가려 한 적이 있음
      VPN이 안 붙어서 라우터에 쉽게 들어갈 수 있길래 MTU 설정을 바꿨고, 바로 정상 동작했음

  • 이런 해킹은 원래 의미 그대로 멋지고 좋아함
    다만 최근 확인해보니 skywifi에서 전역 DNS는 결제 없이도 정상 해석되는 듯했고, 내가 탔던 비행기에서는 그냥 일반적인 iodine 터널도 동작했을 것 같음
    https://github.com/yarrick/iodine

    • 몇 년 전 누구나 접속할 수 있는 공개 iodine 서비스를 운영했음
      악용 신고를 피하려고 서버의 외부 트래픽은 Tor를 거치게 했고, 어느 기차·호텔·공항 네트워크에서 동작하는지 로그도 모았으며 다른 터널링 프로토콜도 제공했음
      한동안 재미있는 프로젝트였고 계속 돌려둘 걸 그랬음
      요즘은 일부 DNS 서버, 특히 Google이 DNS 요청의 대소문자를 무작위화해서 특정 인코딩을 심하게 깨뜨리기 때문에 DNS 터널링이 좀 더 어려워짐
    • 6년 전 다른 항공사 Wi-Fi에서 iodine이 동작했음
      아이디어와 원리는 재미있지만 속도 때문에 실전에서는 거의 쓸모없고, UDP 위에 메신저 정도 올린다면 몰라도 그렇다 ;-)
    • 방화벽에서 DNS가 허용된다면 DNS 프로토콜 자체를 건드리지 말고 WireGuard를 UDP/53으로 쓰면 되는 것 아닌가?

  • “헤드폰 충전을 깜빡해서 Limp Bizkit이 노트북 스피커로 나오기 시작했다. 다행히 비행기 안 다른 사람들은 신경 쓰지 않는 듯해서 다 같이 신나게 즐겼다.”
    이런 사람들은 기본적인 공중 예절이 부족함
    주변의 많은 사람은 분명 신경 쓰였겠지만, 쓸데없는 소음을 강요하지 말라고 말하기엔 너무 예의 바른 사람들이었을 가능성이 큼

    • 저자가 “이건 풍자입니다”라고 쓰면 풍자가 망가짐
    • 나는 농담으로 읽었음
      이런 기본 예절이 없는 사람이 워낙 많아서 웃긴 농담이라고 생각했고, 적어도 저자가 실제로 그런 사람은 아닐 듯함
    • 농담이 재미있지는 않았지만 글의 주제와는 맞음
      공짜 인터넷 가능성을 실행 가능한 기회로 보는 해커의 이미지를 보여주고, 뒤에서는 실제로 항공사 시스템을 악용할 사람이 아니라는 식으로 거리를 두기 때문에 초반 톤은 문체적 장치로 보임
    • 인간들이 “유머”라고 부르는 것 같음
    • 다른 말처럼 농담이었길 바람
      아니라면 엄청 무례하고 냉담한 행동임

  • 비행기만 타면 항상 피곤해서 눈 감고 끝날 때까지 기다리는 것 말고는 아무것도 못 하는 사람이 나뿐인지 궁금함
    노트북이나 책을 꺼내는 생각만 해도 지치고, 소음도 많으며 소음 제거 헤드폰도 없어 집중이 어려움
    집에서 나와 기차·트램·보안검색을 거치며 최소 2시간을 보낸 상태이고, 공항의 건강하지 않은 음식도 도움이 안 됨
    날씨도 반년은 너무 덥거나 춥고, 10kg 배낭 때문에 계속 땀이 나서 결국 비행기 안에서는 뭘 할 기분이 안 남

    • 성인 ADHD가 있는데, 직장에서는 집중이 더 어렵지만 비행기나 다른 복잡한 장소에서는 오히려 레이저처럼 집중할 수 있음
      직관과 반대지만 많은 ADHD 뇌가 이렇게 동작한다고 들었고, 비행기에서 보내는 시간이 가장 생산적임
    • 예전엔 노트북을 꺼내 뭔가 해보려 했지만 좌석 간격이 줄어든 뒤로는 태블릿보다 큰 물건을 꺼내기가 정말 어려워짐
      무릎에 걸쳐야 하거나, 앞사람이 좌석을 젖히면 화면이 깨질 위험이 있는데 몇 년 전 동료에게 실제로 그런 일이 있었음
      요즘은 그냥 iPad와 소음 제거 헤드폰을 꺼내 영화나 TV 프로그램을 봄
    • 나만 그런 게 아님
      내 몸도 똑같이 반응하고, 공기 중 산소량 감소와 관련 있다고 봄
      소음 문제가 아니라 공기 문제이며, 소음 제거 헤드폰은 정말 효과가 좋음
      그런데 전혀 영향받지 않고 비행기에서 유용한 일을 하는 사람들도 있긴 함
    • 나는 정반대임
      아무리 피곤하거나 잠이 부족해도 비행기에서는 잠들지도 피곤해지지도 않아서 대서양 횡단 비행이 더 괴롭고, 동행이 8시간씩 잠들면 놀림당하는 느낌마저 듦
    • 나만 그런 게 아님
      비행 중엔 머리가 아주 멍해져서 착륙할 때까지 눈을 감고 있고, 책을 읽거나 일을 해보려 해도 5~10분 뒤 뇌가 꺼져버림
      이상하게도 기내식은 매번 복부 팽만을 일으켜서 착륙 직후 약이 필요함
      흥미롭게도 비즈니스석을 두 번 탔을 땐 뇌가 꺼지기 전까지 어느 정도 독서를 할 수 있었음
      장거리 기차에서는 진행 방향을 보고 앉아 있으면 실제로 일을 하기가 더 쉬운데, 기차가 꽤 붐비면 다시 뇌가 꺼짐

  • 주식 시세, 경기 점수, 날씨 같은 걸 보내주는 이야기를 보니 예전에 Google이 문자 메시지 서비스로 제공하던 기능이 떠오름
    첫 스마트폰을 사기 전 정말 많이 썼고, W[ZIP code]를 46645(GOOGL)로 보내면 날씨를 문자로 답해줬음
    stock:[symbol]도 됐고 지금은 잊어버린 여러 기능이 있었음
    물론 Google이 종료했지만, 지속되는 동안은 꽤 멋졌음

    • PHP를 만지던 시절, 가사 일부로 노래를 찾아주는 SongBuddy라는 Twitter 봇을 만들었음
      당시 Twitter가 지원하던 SMS DM으로 가사 몇 줄을 보내면 Google에서 " lyrics"를 검색하고 결과를 파싱해 아티스트와 제목을 SMS로 돌려주는 구조였음
      잘 동작하진 않았지만 꽤 자랑스러웠음
    • 내가 쓰는 환율 변환 사이트는 교수 한 명이 운영하고, 아마 대학 계단 밑에 숨겨둔 Pentium III 컴퓨터에서 돌고 있을 텐데도 수십 년째 살아 있고 평생 갈 것 같음
    • Twilio와 AWS 인스턴스로 SMS↔ChatGPT 인터페이스를 만들었음
      덕분에 휴대용 위성 통신기 inReach Mini 2로 지구 어디서든 ChatGPT에 질문할 수 있고, Death Valley 한가운데서도 물어볼 수 있다는 게 꽤 좋음
    • 폴더폰으로 그 서비스를 항상 썼음
      Google 검색어를 타이핑하는 데 오래 걸리고 결과가 오기까지 1~2분 걸릴 수 있었지만 없는 것보다는 나았음
      주로 가고 싶은 장소의 주소를 검색해서 TomTom에 입력하는 데 썼고, 시대가 많이 바뀌었음
    • 그게 언제였는지 궁금함
      1995년쯤 Ericsson 자회사인 통신 연구 회사에서 일할 때 이런 아이디어를 떠올렸고, 대표 예시는 항공편 상태 업데이트였음
      숫자 키패드에서 한 글자를 입력하려면 여러 번 눌러야 하는 P2P 메시징이 그렇게 인기 있을 거라고는 아무도 상상하지 못했기 때문에, 초기 웹에서 데이터가 늘어나는 상황에서는 정보 서비스가 가장 좋은 활용처럼 보였음
      Teletext도 아직 존재했고, 그걸 긁어오는 별도 프로젝트도 있었음
      그런데 SMS에 접근할 수 있던 우리와 일반 대중이 결국 그걸 어디에 썼는지 생각해보면 흥미로움

  • 저자가 추상적인 공유 편집 필드 위의 TCP에 꽤 가까이 갔다는 점이 흥미로움
    그 자체로도 아주 멋진 도구가 될 수 있음
    양쪽에서 공유 자원에 읽고 쓰는 방법만 고수준으로 설계하면, 나머지는 모두 처리해 SOCKS 프록시로 제공하는 프록시를 상상해볼 수 있음

    • 유료 Boingo 공항 핫스팟에서 공짜 인터넷을 쓰려고 DNS 위 TCP/IP는 이미 구현된 적이 있는 것으로 앎
      결국 무료 Wi-Fi가 표준이 되면서 더는 별일이 아니게 됐고, 이제는 기내 무료 Wi-Fi 전쟁으로 넘어왔음
      결국 기내 Wi-Fi도 어디서나 무료가 될 것이고, 이미 여러 항공사에서는 그렇게 하고 있음
    • 우리나라 통신사가 데이터 제한 요금제에서 “무제한 WhatsApp”을 광고하기 시작한 뒤로 몇 년간 이걸 생각해왔음
      텍스트만 되고 이미지나 영상은 안 되겠지만 일반적인 웹 탐색에는 충분했을 것임

  • 몇 년 전 우리 대학 학장이 “게임 때문에 출석에 영향이 있다”는 식으로 말하며 밤 10시 이후 LAN 네트워크를 차단하기로 했음
    구현 방식은 IP 주소로 오가는 모든 트래픽을 막는 것이었는데 TCP 자체는 막지 않았고, 당시 아주 새롭진 않았던 IPv6도 완전히 잊고 있었음
    그래서 IPv6로 동작하는 간단한 P2P 채팅 앱을 만들었고, 유일한 문제는 친구들에게 IPv6 주소를 공유해 연락처에 유지하게 해야 한다는 점이었음
    잘 동작했지만, 나중에는 네트워크 밖 컴퓨터로 터널링하는 편이 훨씬 쉽다는 걸 알게 됨

  • 이건 쓸모없는 소프트웨어를 더 많이 쓰자는 글과 뒤이은 HN 논의를 떠올리게 하는 거의 완벽한 예시 같음
    인생을 바꾸는가? 아마 아닐 것임
    만들고 탐색하는 과정이 재미있었는가? 거의 확실함
    우리는 이런 걸 더 많이 만들어야 함
    https://ntietz.com/blog/write-more-useless-software/
    https://news.ycombinator.com/item?id=37911900

답변달기