PySkyWiFi: Tạo Wi‑Fi tốc độ thấp miễn phí trên các chuyến bay đường dài

 (robertheaton.com)
1 điểm bởi GN⁺ 2024-07-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • PySkyWiFi là một thử nghiệm dùng các trường hồ sơ của tài khoản dặm bay hàng không — vốn vẫn mở trước khi thanh toán — làm nơi lưu trữ tạm thời, để gửi HTTP request và response qua lại trong chuyến bay đường dài với tốc độ cực chậm
  • Prototype ban đầu tạo chat bằng cách cập nhật và polling trường tên của tài khoản, rồi được mở rộng thành cơ chế trong đó daemon dưới mặt đất đọc các request như STOCKPRICE: APPL và trả kết quả về
  • Kiến trúc cuối cùng được chia thành sky proxy trong máy bay và ground daemon có kết nối Internet; URL đích được truyền qua header X-PySkyWiFi của request curl cục bộ
  • Việc truyền dữ liệu được thực hiện bằng cách chia HTTP request thành các chunk nhỏ, rồi sắp thứ tự bằng các segment DATA, ACK, END và số thứ tự 6 chữ số
  • Tác giả tránh cách liên tục gửi request tự động đến tài khoản hàng không thật; bài test cuối chỉ dừng ở mức dùng GitHub Gist để gọi curl lấy trang chủ blog và nhận HTML response sau vài phút

Lối đi vòng phát hiện trong cổng Wi‑Fi trước khi thanh toán

  • Trang đăng nhập Wi‑Fi trên máy bay yêu cầu thanh toán, nhưng vẫn cho phép đăng nhập tài khoản dặm bay hàng không miễn phí trước khi trả tiền
  • Khi nhìn thấy trường tên trong màn hình chỉnh sửa hồ sơ, tác giả cho rằng giá trị này có thể được dùng như một kênh liên lạc nhỏ để trao đổi với bên ngoài
  • Ban đầu tác giả định dùng Go làm ngôn ngữ triển khai, nhưng chọn Python vì như vậy có thể đặt tên công cụ là PySkyWiFi
  • Mã nguồn được công khai tại PySkyWiFi

Prototype 1: Nhắn tin tức thời bằng trường tên

  • Sau khi hai client đăng nhập vào cùng một tài khoản dặm bay hàng không, chúng gửi nhận tin nhắn bằng cách luân phiên cập nhật và đọc trường tên
    • Một bên đổi tên thành Hello how are you thì bên kia đọc được
    • Khi đổi lại thành Im fine how are you, bên đầu tiên thấy được câu trả lời
  • Việc đổi tên trực tiếp trong UI quá phiền phức nên được tự động hóa bằng công cụ dòng lệnh
    • Công cụ đăng nhập vào website và cập nhật trường tên của tài khoản test thành nội dung tin nhắn
    • Cứ vài giây lại polling trường tên; nếu giá trị thay đổi thì in ra như câu trả lời từ phía bên kia
  • Tác giả quyết định không gửi thêm dữ liệu tự động vào tài khoản dặm bay thật nữa, chỉ kiểm tra bằng cách cập nhật nhanh tên khoảng 10 lần và xác nhận tất cả đều thành công
    • Kết quả này cho thấy tài khoản đó có thể không áp giới hạn về tốc độ hoặc số lượng request
  • Việc phát triển sau đó được tiếp tục bằng GitHub Gists và file cục bộ để tái hiện cùng nguyên lý
    • Vì cách này nhanh và dễ lặp lại hơn so với dùng tài khoản dặm bay hàng không

Prototype 2: Lấy thông tin bên ngoài bằng daemon dưới mặt đất

  • Ở bước tiếp theo, tác giả chạy một daemon trên một máy tính có kết nối Internet ở dưới mặt đất hoặc trên cloud
  • Daemon liên tục polling trường tên của tài khoản dặm bay hàng không để tìm các request có cấu trúc được gửi từ máy bay
    • Ví dụ: STOCKPRICE: APPL
    • Ví dụ: SCORE: MANUNITED
  • Khi phát hiện request mới, daemon phân tích nó, lấy thông tin từ API liên quan rồi trả lại phía máy bay thông qua tài khoản dặm bay hàng không
  • Từ giai đoạn này, hệ thống vượt ra ngoài chat đơn giản và có thể tra cứu thông tin thời gian thực như giá cổ phiếu hoặc tỉ số thể thao

Kiến trúc tổng thể gồm sky proxy và ground daemon

  • PySkyWiFi là một giao thức tương tự TCP/IP: nhét toàn bộ HTTP request vào tài khoản dặm bay hàng không, để máy tính dưới mặt đất thực hiện HTTP request thật rồi tải response lên lại theo cùng cách
  • Hệ thống có hai thành phần
    • sky proxy: proxy chạy trên laptop trong máy bay
    • ground daemon: daemon chạy trên máy tính có kết nối Internet ở nhà hoặc trên cloud
  • Trước khi dùng, chạy ground daemon trước; sau đó kết nối Wi‑Fi trên máy bay và chạy sky proxy trên laptop
  • Người dùng gửi HTTP request đến proxy cục bộ bằng công cụ như curl
    • Ví dụ: curl localhost:1234 -H "X-PySkyWiFi: example.com"
    • URL đích thật được đặt trong header tùy chỉnh X-PySkyWiFi
  • Ground daemon xóa header X-PySkyWiFi và dùng nó để định tuyến đến website đích
    • Body của request và các header khác được chuyển tiếp nguyên trạng
  • Khi toàn bộ quá trình hoàn tất, người dùng nhận được HTTP response như một request Internet thông thường, nhưng tùy tình trạng mạng trên máy bay, request có thể bị treo trong vài phút và tốc độ chỉ ở mức vài byte mỗi giây

Gửi nhận HTTP bằng chunk, ACK và tài khoản thứ hai

  • sky proxy nhận request từ curl rồi chia toàn bộ HTTP request thành các chunk
    • Vì lượng dữ liệu có thể chứa trong trường tên của tài khoản dặm bay hàng không là rất nhỏ
  • Mỗi chunk lần lượt được ghi vào trường tên của tài khoản dặm bay hàng không thứ nhất
  • ground daemon polling tài khoản; khi phát hiện chunk mới, nó đọc chunk đó và để lại xác nhận đã nhận rằng có thể gửi chunk tiếp theo
  • Khi toàn bộ HTTP request được ghép lại, ground daemon gửi request thật ra Internet
  • HTTP response đi theo quy trình tương tự theo chiều ngược lại
    • ground daemon chia response thành các chunk và gửi đi
    • Để đơn giản hóa triển khai, các chunk response dùng tài khoản dặm bay hàng không thứ hai
    • sky proxy đọc các chunk, ghép lại thành HTTP response và trả về cho lệnh gọi curl ban đầu

Tách vai trò của tầng truyền tải và tầng mạng

  • Logic giao tiếp của PySkyWiFi được chia thành tầng truyền tải và tầng mạng
  • Tầng truyền tải quyết định sẽ gửi dữ liệu nào theo thứ tự nào
    • Cách chia thông điệp dài thành các chunk nhỏ
    • Cách báo cho bên gửi biết bên nhận đã sẵn sàng nhận chunk tiếp theo
    • Vai trò này hơi giống TCP, nhưng chỉ ở mức rất lỏng lẻo
  • Tầng mạng ghi và đọc dữ liệu mà tầng truyền tải đã quyết định vào nơi lưu trữ thực tế
    • Nơi lưu trữ có thể là tài khoản dặm bay hàng không, file cục bộ hoặc hồ sơ Discord
  • Sự tách biệt này giúp dễ gắn thêm nền tảng dặm bay của hãng hàng không mới
    • Chỉ cần triển khai tầng mạng mới, tầng truyền tải vẫn giữ nguyên
    • Tầng mạng dùng cho test có thể đọc ghi file cục bộ thay vì tài khoản dặm bay hàng không

Quy tắc truyền bằng DATA, ACK, END

  • Một kết nối truyền tải PySkyWiFi gồm hai pipe
    • Mỗi client có SEND pipe để ghi và RECV pipe để đọc
    • Tài khoản dặm bay hàng không có thể được dùng làm pipe
  • Tại một thời điểm, PSWF client chỉ có thể gửi hoặc nhận
    • Ở chế độ gửi, client không thấy dữ liệu bên kia gửi
    • Ở chế độ nhận, dù client gửi dữ liệu thì bên kia cũng không thấy
    • Đây không phải cách gửi nhận hai chiều bất cứ lúc nào như TCP
  • Thông điệp dài được truyền bằng các segment DATA, ACK, END
    • DATA: gồm ký tự D, số thứ tự được padding thành 6 chữ số, và dữ liệu chunk thực tế
    • Ví dụ: D000451adline": "Mudslide in Wigan causes m
    • ACK: gồm ký tự A và số thứ tự 6 chữ số cần xác nhận
    • Ví dụ: A000451
    • END: một ký tự E, đánh dấu kết thúc thông điệp
  • Bên gửi sau khi gửi DATA sẽ chờ đến khi nhận được ACK cho số thứ tự đó
    • Khi nhận A000451, nó xem chunk 000451 đã được xử lý và gửi chunk 000452
  • Khi bên nhận thấy END, nó xử lý rằng thông điệp đã kết thúc, rồi bên gửi và bên nhận đổi vai trò

Interface triển khai tầng mạng

  • Tầng mạng cung cấp một interface đơn giản để ghi và đọc dữ liệu vào nơi lưu trữ
  • Có hai thao tác bắt buộc
    • send(msg: str): ghi msg vào nơi lưu trữ
    • recv() -> str: đọc thông điệp từ nơi lưu trữ
  • Trong triển khai dựa trên dặm bay hàng không, hai thao tác này tương ứng với việc ghi và đọc trường tên của tài khoản
  • Cũng có hai thuộc tính bắt buộc
    • sleep_for: thời gian tính bằng giây mà tầng truyền tải chờ giữa các lần polling RECV pipe
    • segment_data_size: số ký tự chứa trong một segment
  • sleep_for có thể đặt thấp trong các triển khai test như file, nhưng với triển khai dùng tài khoản dặm bay hàng không thì cần ít nhất vài giây để tránh gửi quá nhiều request đến server từ xa
  • segment_data_size phải bằng kích thước tối đa của trường trong tài khoản dặm bay hàng không đang dùng; ví dụ là khoảng 20 ký tự
  • Có hai hook tùy chọn
    • connect_send(): được gọi khi khởi tạo SEND pipe; trong triển khai dặm bay hàng không, nó có thể được dùng để đăng nhập bằng tên người dùng và mật khẩu nhằm lấy cookie
    • connect_recv(): được gọi khi khởi tạo RECV pipe

Mã hóa base26 và ý tưởng cải thiện băng thông

  • Form HTML của tài khoản dặm bay hàng không có thể không cho phép ký tự không phải chữ cái trong tên
    • Stephen có thể được chấp nhận
    • GET /data?id=5 có thể bị từ chối
  • Để tránh điều này, tầng mạng cần mã hóa segment sang base26 trước khi ghi vào tài khoản dặm bay hàng không
    • base26 biểu diễn chuỗi chỉ bằng các ký tự từ A đến Z
    • Chuyển chuỗi byte thành một số lớn, rồi biểu diễn bằng các ký tự A~Z như chữ số trong hệ cơ số 26
    • Ví dụ: b26_encode("Hello world") trả về CZEZINADXFFTZEIDPKM
  • Tầng truyền tải không cần biết về việc mã hóa này
    • Tầng mạng chuyển byte thành base26 để ghi, rồi khi đọc thì khôi phục lại thành byte
  • base26 làm chuỗi dài ra đáng kể, khiến băng thông giảm
    • Nếu dùng base52 với cả chữ hoa và chữ thường thì có thể ngắn hơn, nhưng điều này được để lại làm cải tiến cho phiên bản 2
  • Có thể tăng băng thông bằng cách tăng kích thước segment
    • Dù một trường chỉ lưu được 20 ký tự, nếu ghi đồng thời 5 trường 20 ký tự thì có thể gửi segment 100 ký tự trong một request
    • Bên nhận có thể đọc 5 trường trong một request rồi nối lại

Dư địa cải tiến từ HTTP CONNECT và bài test cuối

  • Thay vì gửi nhận HTTP request thủ công, PySkyWiFi có thể tạo tunnel tốt hơn nếu dùng HTTP CONNECT requests
  • CONNECT là cách mà hầu hết HTTP proxy sử dụng; nhờ đó, PySkyWiFi có thể hoạt động như proxy cấp hệ thống và xử lý cả request từ trình duyệt
  • Khi dùng CONNECT, PySkyWiFi tự thương lượng kết nối TLS trực tiếp với website đích, nên traffic đi qua tài khoản dặm bay hàng không sẽ được mã hóa
  • Nhược điểm là khối lượng triển khai sẽ lớn hơn nhiều
  • Trong bài test cuối, tác giả tunnel dữ liệu qua GitHub Gist để tải trang chủ blog bằng curl, và nhận được HTML response sau vài phút

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-10
Ý kiến Hacker News

  • Vài chục năm trước, vợ/chồng tôi dùng tin nhắn Google Voice theo kiểu đọc và trả lời ngay trong hộp thư đến Gmail, nhưng vì ghét điện thoại di động nên luôn mang theo một chiếc Kindle Keyboard cũ có 3G không giới hạn
    Trình duyệt đơn giản của Kindle có thể mở giao diện Gmail cấu hình thấp, nên có thể dùng nó như một thiết bị SMS không mất phí hàng tháng, vấn đề duy nhất là thông báo tin nhắn mới
    Vì vậy sau khi jailbreak, khi đang định gắn một bộ đếm lên màn hình chính thì tôi chợt nghĩ có thể đặt bộ đếm cạnh tên thiết bị Kindle, thứ có thể đổi được trong tài khoản Amazon
    Từ máy chủ tại nhà, tôi dùng tự động hóa trình duyệt để đăng nhập Amazon và đổi tên thiết bị thành My Kindle (x), trong đó x là số tin nhắn Google Voice chưa đọc, và Kindle sẽ cập nhật tên trên màn hình chính trong vòng chưa đầy 1 phút nên nó hoạt động tốt suốt nhiều năm

    • Tôi nhớ hóa đơn AT&T cho Kindle 3G hồi đó khổng lồ lắm
      Tôi nhớ chỉ cần giảm vài byte thôi cũng tiết kiệm được cỡ cả triệu đô
    • Tôi từng cho một đồng nghiệp đi du lịch mượn Kindle Keyboard rồi nó bị trộm ở Mexico
      Khi đó nó chắc gần như là chiếc Kindle đời cũ nhất còn hoạt động được, nên có lẽ kẻ trộm chỉ tiện tay lấy luôn thứ có sẵn trong túi
      Sau này tôi lại tìm được một chiếc Kindle Keyboard giá 20 đô ở chợ đồ cũ, nhưng pin chết sau 6 tháng; tôi vẫn còn giữ máy nên đang tò mò chi phí pin thay thế là bao nhiêu
    • Cái 3G miễn phí đó thực sự rất tuyệt
      Có thể gắng gượng dùng Gmail trên trình duyệt, và tôi còn làm một trang web Zork thân thiện với Kindle để chọn giữa nhiều ROM zmachine và chơi game chữ
      Nó còn được vài trang tin nhắc đến nên cũng nhận được chút phản hồi
    • Tôi cũng từng làm vậy
      Không có kiểu tích hợp khéo léo là đổi tên Kindle, nhưng tôi cũng đã nhắn tin một thời gian bằng Keyboard Kindle có 3G không giới hạn
    • Trước khi mua smartphone, tôi từng dùng Kindle Keyboard để chỉ đường trong các chuyến đi đường dài bằng ô tô
      Trang web Google Maps vẫn có thể chạy được, dù rất chật vật

  • Trước đây tôi từng đi một chuyến phà từ Ý sang Hy Lạp kéo dài khoảng 20 tiếng; trên đó có Wi‑Fi trả phí dựa trên internet vệ tinh, nhưng tôi không muốn trả tiền
    Truy cập vào Stripe để thanh toán thì vẫn mở, và hóa ra có thể vào mọi trang của stripe.com, kể cả tài liệu dành cho nhà phát triển, nên tôi bắt đầu tải đi tải lại ảnh để lãng phí băng thông
    Rồi tôi chợt nhớ rằng để Stripe hoạt động thì cần truy cập Fastly CDN, mà Reddit cũng dùng Fastly, nên sau khi kết nối tới Stripe tôi đổi HTTP header Host thành reddit.com và có thể xem Reddit
    Ảnh không hoạt động vì i.redd.it không nằm trên Fastly, nhưng bằng cách trỏ old.reddit.com trong /etc/hosts tới IP Fastly của Stripe và bỏ qua lỗi TLS đáng sợ, tôi còn đăng nhập được

    • Với kiểu đó, đối tượng bị hại khi bạn tải về vài gigabyte tài liệu rất có thể là những hành khách trên máy bay đang trả tiền cho dịch vụ đó
      Nếu kết nối bị chậm làm họ không bao giờ mua lại nữa thì công ty cung cấp cũng bị thiệt, và chi phí băng thông upload của Stripe cũng có thể tăng
      Tôi thậm chí còn tránh tải dữ liệu trên mạng di động vì sợ ảnh hưởng xấu đến những người xung quanh
    • Tôi không hiểu chính xác làm vậy thì được lợi gì
      Tôi hiểu đây là một thử nghiệm trí tuệ để khám phá có thể truy cập đến đâu trong một kết nối bị chặn, nhưng cố tình lãng phí băng thông thì giống như mở vòi nước trong nhà vệ sinh công cộng để xả nước vô ích hoặc làm tắc bồn cầu cho nó tràn ra
    • Đó là domain fronting, và hiện nay đã bị chặn ở mọi CDN lớn
      https://en.wikipedia.org/wiki/Domain_fronting
    • Lần sau chắc bạn sẽ mở nước trong khách sạn chỉ để dạy cho họ một bài học vì dám cung cấp dịch vụ trả phí
    • Tôi thắc mắc vì sao phản xạ đầu tiên với một dịch vụ mà bạn không muốn trả tiền lại là tìm cách lạm dụng hoặc làm suy giảm nó

  • Vài tuần trước, khi đưa con đi học ở trung tâm thương mại, tôi thử dùng Wi‑Fi miễn phí nhưng laptop đăng nhập thành công rồi lại báo không có internet
    Tôi kiểm tra default gateway thì thấy nó nối tới một modem Cisco, ở đó hiện ra công cụ chẩn đoán và danh sách thiết bị đã kết nối, nhưng kết nối internet đang bị tắt
    Tôi tra model bằng điện thoại thì thấy tài khoản quản trị dùng số serial làm username và để trống mật khẩu; còn có cả mẫu ví dụ, mà tên của một thiết bị đang kết nối trông đúng kiểu mẫu đó
    Tôi đăng nhập luôn và bật nút internet lên; 15 giây sau nó chuyển sang màu xanh, và tôi cũng đặt lại mật khẩu cho thiết bị

    • Tôi từng về thăm gia đình rồi kết nối vào Wi‑Fi không bảo mật của hàng xóm để vào VPN công ty
      VPN không kết nối được, tôi thấy có thể vào router rất dễ nên đã đổi cài đặt MTU, và ngay lập tức mọi thứ hoạt động bình thường

  • Tôi thích kiểu hacking này theo đúng nghĩa gốc của từ đó, rất ngầu
    Tuy vậy, kiểm tra lại gần đây thì có vẻ DNS toàn cục trên skywifi vẫn phân giải bình thường mà không cần thanh toán, và trên chuyến bay tôi từng đi thì có lẽ ngay cả một đường hầm iodine thông thường cũng chạy được
    https://github.com/yarrick/iodine

    • Vài năm trước tôi từng vận hành một dịch vụ iodine công khai cho ai cũng có thể truy cập
      Để tránh bị báo cáo lạm dụng, tôi cho lưu lượng đi ra ngoài từ máy chủ vòng qua Tor, đồng thời ghi log xem nó hoạt động trên mạng tàu hỏa, khách sạn và sân bay nào, và còn cung cấp thêm các giao thức tunneling khác
      Đó là một dự án thú vị trong một thời gian, giờ nghĩ lại chắc tôi nên để nó chạy tiếp
      Dạo này DNS tunneling khó hơn một chút vì một số máy chủ DNS, đặc biệt là Google, ngẫu nhiên hóa chữ hoa chữ thường trong truy vấn DNS, làm hỏng nghiêm trọng một số kiểu mã hóa nhất định
    • iodine từng chạy được trên Wi‑Fi của một hãng hàng không khác cách đây 6 năm
      Ý tưởng và nguyên lý thì thú vị, nhưng vì tốc độ quá chậm nên gần như vô dụng trong thực tế, trừ khi chỉ chạy thứ gì đó cỡ ứng dụng nhắn tin trên UDP ;-)
    • Nếu tường lửa cho phép DNS thì chẳng phải chỉ cần dùng WireGuard qua UDP/53 thay vì động vào chính giao thức DNS sao?

  • “Tôi quên sạc tai nghe nên Limp Bizkit bắt đầu phát ra từ loa laptop. May là có vẻ những người khác trên máy bay không để ý, thế là mọi người cùng quẩy vui vẻ.”
    Những người như vậy thiếu phép lịch sự nơi công cộng cơ bản
    Chắc hẳn nhiều người xung quanh thực sự thấy phiền, chỉ là họ quá lịch sự để bảo đừng ép người khác phải nghe thứ tiếng ồn không cần thiết

    • Nếu tác giả viết “đây là châm biếm” thì coi như làm hỏng châm biếm rồi
    • Tôi đọc nó như một trò đùa
      Có quá nhiều người thiếu phép lịch sự cơ bản kiểu này nên tôi thấy đó là một câu đùa buồn cười, và ít nhất có lẽ tác giả ngoài đời không phải kiểu người như thế
    • Trò đùa không hẳn là hay, nhưng hợp với chủ đề bài viết
      Nó thể hiện hình ảnh một hacker xem khả năng có Internet miễn phí như một cơ hội có thể thực hiện được, rồi phía sau lại giữ khoảng cách theo kiểu mình không phải loại người thực sự đi lạm dụng hệ thống của hãng hàng không, nên tông mở đầu có vẻ là một dụng ý văn phong
    • Có lẽ đó là thứ con người gọi là “hài hước”
    • Mong là đúng như những người khác nói, đó chỉ là đùa
      Nếu không thì đó là hành vi cực kỳ thô lỗ và lạnh lùng

  • Tôi tự hỏi có phải chỉ mình tôi cứ lên máy bay là lúc nào cũng mệt đến mức chẳng làm được gì ngoài nhắm mắt chờ đến lúc kết thúc không
    Chỉ cần nghĩ đến việc lấy laptop hay sách ra thôi cũng đã thấy đuối, lại còn quá nhiều tiếng ồn và không có tai nghe chống ồn nên rất khó tập trung
    Tôi đã ra khỏi nhà và trải qua ít nhất 2 tiếng đi tàu, tàu điện, kiểm tra an ninh, rồi đồ ăn không lành mạnh ở sân bay cũng chẳng giúp ích gì
    Thời tiết thì nửa năm quá nóng hoặc quá lạnh, lại còn ba lô 10kg làm tôi đổ mồ hôi suốt, nên cuối cùng lên máy bay là chẳng còn tâm trạng làm gì nữa

    • Tôi bị ADHD ở người lớn, và ở chỗ làm thì càng khó tập trung hơn, nhưng trên máy bay hay ở những nơi phức tạp khác thì ngược lại tôi lại tập trung như laser
      Nghe có vẻ trái trực giác, nhưng tôi nghe nói nhiều bộ não ADHD hoạt động như vậy, và thời gian trên máy bay lại là lúc tôi làm việc hiệu quả nhất
    • Trước đây tôi từng thử lấy laptop ra làm gì đó, nhưng từ khi khoảng cách ghế bị thu hẹp thì việc lấy ra bất cứ thứ gì lớn hơn máy tính bảng thực sự rất khó
      Hoặc phải để trên đầu gối, hoặc nếu người ngồi trước ngả ghế thì có nguy cơ làm vỡ màn hình; vài năm trước một đồng nghiệp của tôi đã thực sự gặp chuyện đó
      Giờ tôi chỉ lấy iPad và tai nghe chống ồn ra để xem phim hoặc chương trình TV
    • Không chỉ mình bạn đâu
      Cơ thể tôi cũng phản ứng y như vậy, và tôi nghĩ nó liên quan đến lượng oxy giảm trong không khí
      Vấn đề không phải là tiếng ồn mà là không khí, dù tai nghe chống ồn thực sự rất hiệu quả
      Dù vậy, đúng là cũng có những người hoàn toàn không bị ảnh hưởng và vẫn làm được việc hữu ích trên máy bay
    • Tôi thì hoàn toàn ngược lại
      Dù có mệt hay thiếu ngủ đến đâu, tôi cũng không ngủ được hay thấy buồn ngủ trên máy bay, nên các chuyến bay xuyên Đại Tây Dương còn khổ hơn, thậm chí còn có cảm giác bị trêu khi người đi cùng ngủ một mạch 8 tiếng
    • Không chỉ mình bạn đâu
      Khi đang bay đầu óc tôi rất mụ mị, đến mức chỉ nhắm mắt cho tới khi hạ cánh; có thử đọc sách hay làm việc thì 5–10 phút sau não như tắt ngấm
      Kỳ lạ là suất ăn trên máy bay lần nào cũng làm tôi đầy bụng, nên ngay sau khi hạ cánh là phải dùng thuốc
      Thú vị là trong hai lần tôi ngồi hạng thương gia, tôi vẫn đọc được phần nào trước khi não tắt hẳn
      Trên tàu đường dài, nếu ngồi nhìn theo hướng tàu chạy thì tôi thực sự dễ làm việc hơn, nhưng nếu tàu quá đông thì não lại tắt tiếp

  • Nghe chuyện gửi những thứ như giá cổ phiếu, tỉ số trận đấu hay thời tiết làm tôi nhớ đến tính năng Google từng cung cấp qua dịch vụ tin nhắn SMS
    Trước khi mua chiếc smartphone đầu tiên tôi dùng nó rất nhiều; chỉ cần gửi W[ZIP code] tới 46645 (GOOGL) là họ trả lời thời tiết bằng SMS
    stock:[symbol] cũng dùng được, và còn có nhiều tính năng khác mà giờ tôi đã quên mất
    Tất nhiên Google đã khai tử nó, nhưng trong thời gian còn tồn tại thì khá tuyệt

    • Hồi còn nghịch PHP, tôi từng làm một bot Twitter tên SongBuddy để tìm bài hát bằng một đoạn lời
      Qua SMS DM mà Twitter hỗ trợ lúc đó, bạn gửi vài dòng lời bài hát, nó sẽ tìm " lyrics" trên Google, phân tích kết quả rồi trả lại tên nghệ sĩ và tiêu đề bài hát qua SMS
      Nó không hoạt động quá tốt, nhưng tôi vẫn khá tự hào
    • Trang chuyển đổi tỷ giá tôi đang dùng do một giáo sư vận hành, và chắc hẳn đang chạy trên một chiếc Pentium III giấu đâu đó dưới gầm cầu thang trường đại học, vậy mà đã sống suốt vài chục năm và có vẻ sẽ tồn tại mãi
    • Tôi đã tạo một giao diện SMS↔ChatGPT bằng Twilio và một instance AWS
      Nhờ vậy tôi có thể hỏi ChatGPT ở bất cứ đâu trên Trái Đất bằng chiếc máy liên lạc vệ tinh cầm tay inReach Mini 2, và khá thích việc có thể hỏi ngay cả khi đang ở giữa Death Valley
    • Tôi từng luôn dùng dịch vụ đó với điện thoại gập
      Gõ truy vấn Google thì mất thời gian, lại có thể phải chờ 1–2 phút mới nhận được kết quả, nhưng vẫn còn hơn là không có gì
      Tôi chủ yếu dùng nó để tìm địa chỉ những nơi muốn đến rồi nhập vào TomTom, thời thế đã thay đổi nhiều thật
    • Tôi tò mò không biết chuyện đó là từ khi nào
      Khoảng năm 1995, khi làm ở một công ty nghiên cứu viễn thông là công ty con của Ericsson, tôi đã nghĩ ra ý tưởng này, và ví dụ tiêu biểu là cập nhật trạng thái chuyến bay
      Khi đó không ai tưởng tượng được nhắn tin P2P, nơi phải bấm nhiều lần trên bàn phím số mới nhập được một chữ cái, lại trở nên phổ biến đến vậy; nên trong bối cảnh dữ liệu trên web thời kỳ đầu ngày càng nhiều, các dịch vụ thông tin trông có vẻ là cách dùng tốt nhất
      Teletext khi ấy vẫn còn tồn tại, và cũng có một dự án riêng để cào dữ liệu từ đó
      Nhưng nghĩ đến việc cuối cùng những người như chúng tôi, có quyền truy cập SMS, và công chúng nói chung đã dùng nó vào việc gì thì thật thú vị

  • Điều thú vị là tác giả đã tiến khá gần đến ý tưởng TCP trên một trường chỉnh sửa dùng chung trừu tượng
    Bản thân nó thôi cũng có thể là một công cụ rất ngầu
    Nếu chỉ cần thiết kế ở mức cao cách hai bên đọc và ghi vào tài nguyên dùng chung, thì có thể tưởng tượng ra một proxy xử lý toàn bộ phần còn lại và cung cấp nó như một SOCKS proxy

    • Tôi nhớ là từng có người triển khai TCP/IP trên DNS để dùng Internet miễn phí tại các hotspot sân bay Boingo tính phí
      Rồi cuối cùng Wi‑Fi miễn phí trở thành tiêu chuẩn nên chuyện đó không còn gì to tát nữa, và giờ đã chuyển sang cuộc chiến Wi‑Fi miễn phí trên máy bay
      Cuối cùng thì Wi‑Fi trên máy bay cũng sẽ miễn phí ở khắp nơi, và nhiều hãng hàng không đã làm vậy rồi
    • Tôi đã nghĩ về chuyện này nhiều năm nay, từ khi nhà mạng ở nước tôi bắt đầu quảng cáo “WhatsApp không giới hạn” trên các gói cước có giới hạn dữ liệu
      Chắc chỉ nhắn văn bản được thôi chứ không gửi ảnh hay video được, nhưng như vậy cũng đã đủ cho việc duyệt web thông thường rồi

  • Vài năm trước, hiệu trưởng trường đại học của chúng tôi nói đại ý rằng “game ảnh hưởng đến việc điểm danh”, rồi quyết định chặn mạng LAN sau 10 giờ tối
    Cách triển khai là chặn toàn bộ lưu lượng đi lại theo địa chỉ IP, nhưng không chặn bản thân TCP, và cũng hoàn toàn quên mất IPv6, thứ khi đó cũng không còn quá mới mẻ
    Vì vậy tôi đã làm một ứng dụng chat P2P đơn giản chạy qua IPv6, và vấn đề duy nhất là phải chia sẻ địa chỉ IPv6 cho bạn bè để họ lưu trong danh bạ
    Nó hoạt động rất tốt, nhưng về sau tôi nhận ra rằng tunnel ra một máy tính bên ngoài mạng còn dễ hơn nhiều

  • Đây có vẻ là một ví dụ gần như hoàn hảo khiến tôi nhớ đến bài viết hãy viết thêm nhiều phần mềm vô dụng và cuộc thảo luận HN sau đó
    Nó có thay đổi cuộc đời không? Có lẽ là không
    Quá trình tạo ra và khám phá nó có vui không? Gần như chắc chắn là có
    Chúng ta nên làm nhiều thứ như thế này hơn
    https://ntietz.com/blog/write-more-useless-software/
    https://news.ycombinator.com/item?id=37911900