So sánh các ứng dụng tự host theo dõi vị trí cá nhân

Ứng dụng theo dõi vị trí tự host nào phù hợp với trường hợp của bạn

Việc tự host ứng dụng theo dõi vị trí phụ thuộc vào một câu hỏi: bạn muốn lưu lịch sử cho riêng mình, hay muốn theo dõi vị trí trực tiếp cùng với những người khác? Dawarich giải quyết nhu cầu đầu tiên. Đây là giải pháp thay thế tự host cho Google Maps Timeline và nó cho phép nhập lịch sử bạn đã có sẵn. Traccar giải quyết nhu cầu thứ hai. Nó được xây dựng cho phần cứng GPS và quản lý đội xe, coi điện thoại như một thiết bị theo dõi bổ sung. OwnTracks nằm dưới cả hai, đóng vai trò là ứng dụng trên điện thoại và định dạng tin nhắn. Home Assistant đã biết vị trí điện thoại của bạn nếu bạn đang chạy nó, nhưng mặc định nó sẽ xóa lộ trình sau mười ngày.

Hãy chọn dựa trên những gì bạn muốn xem vào tháng tới:

• Bản đồ mọi nơi bạn đã đến vào tháng Ba vừa qua, kèm theo địa điểm và các chuyến đi: Dawarich.
• Bản đồ trực tiếp của nhiều thiết bị, kèm theo geofence và các quy tắc sự kiện: Traccar.
• Một điện thoại gửi vị trí của nó vào hệ thống bạn đang chạy: OwnTracks ở chế độ HTTP.
• Tự động hóa khi ở nhà hoặc ra ngoài, không quan tâm đến lịch sử: Home Assistant độc lập.

Không có giải pháp nào hoạt động cho đến khi điện thoại có thể kết nối tới endpoint HTTPS mà bạn kiểm soát, vì vậy phía máy chủ sẽ có một phần riêng bên dưới. Nếu bạn vẫn đang tìm hiểu xem những gì khác nên có trên máy chủ, danh sách đầy đủ hơn về những thứ đáng để tự host trong năm nay sẽ cho thấy vị trí của một ứng dụng theo dõi so với các dịch vụ khác.

Traccar: Phần cứng GPS, đội xe và vị trí trực tiếp

Traccar là một server theo dõi. Nó hỗ trợ các giao thức mà thiết bị GPS chuyên dụng sử dụng, mỗi giao thức lắng nghe trên cổng TCP và UDP riêng trong dải từ 5000 đến 5150, đồng thời cung cấp bản đồ trực tiếp, hàng rào địa lý (geofence), quy tắc sự kiện và báo cáo. Giao diện web mặc định lắng nghe trên cổng 8082.

Đối với điện thoại, có ứng dụng Traccar Client cho Android và iOS. Ứng dụng này báo cáo qua giao thức OsmAnd, mặc định lắng nghe trên cổng 5055. Các thiết lập của ứng dụng sẽ quyết định thời lượng pin và số lượng bản ghi của bạn. Distance yêu cầu cập nhật sau mỗi N mét khi đang di chuyển. Interval cung cấp báo cáo dựa trên thời gian khi khoảng cách bằng 0. Angle kích hoạt cập nhật khi thay đổi hướng di chuyển, tính bằng độ. Stationary Heartbeat quy định những gì xảy ra khi thiết bị không di chuyển. Tài liệu của Traccar nêu rõ kết quả chính xác không được đảm bảo cho bất kỳ thiết lập nào trong số này, vì điện thoại mới là bên quyết định.

Traccar đi kèm với database H2 nhúng để trình cài đặt hoạt động mà không cần cấu hình, nhưng dự án không khuyến nghị dùng H2 cho môi trường production. Họ hướng người dùng đến MySQL hoặc MariaDB cho các server nhỏ, và PostgreSQL (tùy chọn kèm TimescaleDB) cho các server lớn. Hãy chuyển đổi database trước khi bạn tích lũy dữ liệu lịch sử, vì việc chuyển đổi file H2 sau này là một công việc thủ công và không có công cụ hỗ trợ chính thức.

Điểm hạn chế của Traccar: nó là một bảng điều khiển để giám sát các đối tượng tại thời điểm hiện tại. Các báo cáo tập trung vào đội xe, hành trình, điểm dừng và tóm tắt, vì vậy dữ liệu của chính bạn trong một năm sẽ hiển thị như một kết quả truy vấn thay vì một dòng thời gian (timeline).

OwnTracks: một ứng dụng điện thoại và một endpoint, không gì khác

OwnTracks là thiết lập tối giản kinh điển. Ứng dụng gửi một payload JSON nhỏ mỗi khi xác định thiết bị đã di chuyển, và nó có thể gửi qua MQTT (message queuing telemetry transport) hoặc HTTP thông thường. Ở chế độ HTTP, endpoint là một URL có dạng http[s]://[user[:password]@]host[:port]/path, được xác thực bằng HTTP Basic, và dự án khuyến nghị mạnh mẽ sử dụng scheme https://. Đối với OwnTracks Recorder, đường dẫn là /pub.

Chế độ giám sát quan trọng hơn bất kỳ thiết lập máy chủ nào. Quiet chỉ gửi dữ liệu khi bạn yêu cầu. Manual bổ sung giám sát vùng và yêu cầu vị trí tiêu thụ điện năng thấp. Significant là chế độ tự động thông thường. Move gửi dữ liệu ngay khi thiết bị đã di chuyển được locatorDisplacement mét hoặc locatorInterval giây, tùy điều kiện nào đến trước, với giá trị mặc định là 100 mét và 300 giây. OwnTracks ghi chú rằng chế độ Move tiêu thụ pin tương đương với một ứng dụng điều hướng, và khuyến nghị dùng cho các chuyến đi hoặc khi đang sạc thay vì dùng hàng ngày.

OwnTracks Recorder lưu trữ dữ liệu nhận được và hiển thị một bản đồ nhỏ. Nhiều người không bao giờ cài đặt nó, vì payload vẫn giống nhau bất kể ứng dụng trỏ tới Recorder, Dawarich hay Home Assistant. Đó là lý do nên bắt đầu từ đây: ứng dụng là một nguồn dữ liệu ổn định, đơn giản, và bạn có thể thay đổi lựa chọn ứng dụng tiêu thụ dữ liệu sau này.

Dawarich: giải pháp tự host Google Maps Timeline

Dawarich sử dụng giấy phép AGPL-3.0 và chạy bằng Docker Compose. Một bản cài đặt hoàn chỉnh bao gồm bốn container: ứng dụng Rails, worker Sidekiq cho các tác vụ nền, PostgreSQL và Redis. Ứng dụng chạy trên cổng 3000. Các nguồn nhập dữ liệu bao gồm Google Maps Timeline, OwnTracks, Strava, Immich, các file GPX, GeoJSON và dữ liệu EXIF trong ảnh của bạn. Danh sách nhập này biến nó thành một dòng thời gian thay vì bản đồ trực tiếp, vì nó có thể tiếp nhận lịch sử dữ liệu từ trước khi server được thiết lập.

Quá trình ingest sử dụng một HTTP endpoint kèm theo API key từ trang tài khoản của bạn. OwnTracks gửi dữ liệu đến /api/v1/owntracks/points?api_key=... và Overland gửi đến /api/v1/overland/batches?api_key=.... GPSLogger sử dụng lại endpoint của OwnTracks.

Hãy lưu ý đường đi của key này. Nó nằm trong query string, và định dạng log mặc định của nginx ghi lại toàn bộ dòng request, vì vậy key sẽ xuất hiện dưới dạng văn bản thuần trong /var/log/nginx/access.log tại mỗi điểm dữ liệu. Hãy coi file log đó là thông tin mật, xoay vòng key nếu bạn chuyển log đến bất kỳ hệ thống tập trung nào, và tuyệt đối không dán URL đang hoạt động vào các luồng hỗ trợ kỹ thuật.

Đối với file compose, các volume và chính sách restart, hãy tham khảo cơ chế container để chạy compose trên VPS. Trang này chỉ dừng lại ở bước quyết định triển khai.

Home Assistant: mạnh về hiện diện, yếu về lưu trữ lịch sử

Nếu bạn đã chạy Home Assistant, bạn đã có sẵn tính năng theo dõi thiết bị. Ứng dụng companion báo cáo vị trí, còn integration OwnTracks cung cấp cho bạn một URL webhook và một encryption key để dán vào ứng dụng. Khi đã cấu hình MQTT, integration đó sẽ lắng nghe các MQTT message thay vì HTTP.

Giới hạn nằm ở thời gian lưu trữ. Recorder của Home Assistant mặc định là purge_keep_days: 10, và tiến trình tự động dọn dẹp (auto purge) chạy mỗi đêm vào lúc 04:12 giờ địa phương để ngăn database tăng trưởng không kiểm soát. Mặc định đó phù hợp cho một database tự động hóa gia đình nhưng lại sai cho một kho lưu trữ vị trí. Home Assistant trả lời câu hỏi "có ai ở nhà không". Nó sẽ không trả lời được "tôi đã ở đâu vào ngày 14 tháng 3" trừ khi bạn gửi cùng luồng dữ liệu đó đến một nơi lưu trữ lâu dài.

Theo dõi liên tục hay chia sẻ theo thời điểm?

Theo dõi liên tục nghĩa là ứng dụng gửi dữ liệu cả ngày bất kể bạn có di chuyển hay không, và kho lưu trữ được tạo ra chính là mục đích cốt lõi. Chia sẻ theo thời điểm nghĩa là mọi người theo dõi nhau trong một chuyến đi, và kho lưu trữ chỉ là hệ quả phụ không ai yêu cầu. Cùng một phần mềm có thể phục vụ cả hai mục đích với các thiết lập khác nhau.

Đối với theo dõi liên tục, hãy ưu tiên báo cáo dựa trên khoảng cách di chuyển thay vì bộ đếm thời gian ngắn, lưu database trên bộ nhớ mà bạn thực sự sao lưu, và quyết định thời gian lưu trữ ngay từ ngày đầu tiên thay vì đợi đến khi đầy ổ cứng. Đối với chia sẻ theo thời điểm, chỉ tăng tần suất báo cáo khi cần thiết và đưa điện thoại về chế độ tiết kiệm năng lượng sau đó. OwnTracks cung cấp tính năng này dưới dạng một tùy chọn trong ứng dụng, và Traccar Client cũng làm tương tự thông qua các trường khoảng cách và khoảng thời gian.

Nếu bạn chỉ muốn một liên kết chia sẻ trong hai giờ cho một chuyến đi duy nhất, hãy kiểm tra ghi chú phát hành (release notes) của server mà bạn chọn trước khi bắt đầu. Đó là tính năng thay đổi nhiều nhất giữa các phiên bản và cũng là điểm yếu nhất của mọi tùy chọn ở đây.

Bạn có thực sự cần một MQTT broker không?

Hãy bắt đầu mà không có nó. Chế độ HTTP chỉ cần một URL, mật khẩu và TLS (transport layer security), và mọi máy chủ được nêu ở trên đều chấp nhận nó. Một broker chỉ thực sự cần thiết khi có nhiều thiết bị cần cùng một luồng dữ liệu tại cùng một thời điểm, ví dụ như Home Assistant phản hồi một vùng trong khi trình ghi dữ liệu lưu lại lịch sử, hoặc các thành viên trong gia đình nhìn thấy trạng thái của nhau.

MQTT là giao thức publish và subscribe, và Mosquitto là broker phổ biến nhất. Nó lắng nghe trên cổng 1883 ở dạng cleartext và 8883 cho TLS, và bạn chỉ nên dùng cổng 8883. Kiểm soát truy cập được thực hiện theo từng topic, vì vậy một tài khoản có thể được cấp quyền publish owntracks/alice/phone và không được đọc bất kỳ thứ gì khác. Đây chính là lý do thực tế để dùng MQTT trong thiết lập gia đình: việc ai nhìn thấy ai được thực thi bởi broker, nằm dưới tầng ứng dụng, nên lỗi ứng dụng không thể làm lộ dữ liệu.

Cái giá phải trả là thêm một service với chứng chỉ riêng, danh sách người dùng riêng và chế độ lỗi riêng. Một broker ngừng chấp nhận kết nối trông giống hệt như một chiếc điện thoại mất sóng, và cả hai đều không thông báo cho bạn biết.

Một chiếc điện thoại sẽ tạo ra bao nhiêu hàng dữ liệu vị trí?

Các con số dưới đây là kết quả tính toán số học, không phải phép đo thực tế. Chúng giả định một khoảng thời gian báo cáo cố định, mỗi báo cáo một hàng, và không có yếu tố nào khác.

[
  {
    "label": "Every 30 seconds",
    "points_30d": "86,400",
    "points_365d": "1,051,200"
  },
  {
    "label": "Every 60 seconds",
    "points_30d": "43,200",
    "points_365d": "525,600"
  },
  {
    "label": "Every 5 minutes",
    "points_30d": "8,640",
    "points_365d": "105,120"
  },
  {
    "label": "Every 15 minutes",
    "points_30d": "2,880",
    "points_365d": "35,040"
  }
]

Một điện thoại báo cáo mỗi phút một lần sẽ ghi 43,200 hàng mỗi tháng và 525,600 hàng mỗi năm. Nếu tăng khoảng thời gian báo cáo lên mười lăm phút, con số hàng năm sẽ là 35,040. Các ứng dụng thực tế thường phức tạp hơn vì chúng báo cáo dựa trên sự dịch chuyển cũng như thời gian, và chúng sẽ ngừng gửi dữ liệu khi điện thoại đứng yên. Do đó, hãy coi con số ở hàng trên là mức trần thay vì dự báo chính xác.

Nửa triệu hàng mỗi năm là con số nhỏ đối với PostgreSQL. Chi phí gây ảnh hưởng đầu tiên là việc hiển thị dữ liệu: một bản đồ được yêu cầu render dữ liệu của cả năm với độ phân giải đầy đủ sẽ làm treo trình duyệt trước khi database kịp nhận ra áp lực. Đó là lý do tại sao các ứng dụng này tổng hợp lịch sử thành các chuyến đi và địa điểm. Hãy đo lường con số thực tế trên máy chủ của bạn thay vì tin vào một con số từ bài viết blog:

SELECT pg_size_pretty(pg_total_relation_size('tc_positions'));

Đó là bảng positions của Traccar trên PostgreSQL. Hãy chạy lệnh tương đương cho bất kỳ server nào bạn chọn sau một tháng sử dụng bình thường, sau đó nhân với mười hai. Không server nào trong số này tự động xóa các điểm dữ liệu cũ. Chúng lưu giữ những gì bạn gửi cho đến khi bạn xóa nó, vì vậy hãy chọn một quy tắc lưu giữ (retention rule) khi bảng dữ liệu còn nhỏ, và đảm bảo bản backup bao gồm cả database chứ không chỉ cấu hình, vì lịch sử vị trí không thể khôi phục từ bất kỳ nguồn nào khác.

Chi phí pin là quyết định của điện thoại, không phải của server

Đây là phần mà việc tự host không thay đổi được. Hệ điều hành quyết định khi nào GPS thức dậy, ứng dụng chạy nền được phép chạy bao lâu và liệu nó có duy trì được qua đêm hay không. Quản lý năng lượng của Android tạm dừng các tác vụ nền một cách quyết liệt, còn iOS chỉ cung cấp các thay đổi vị trí đáng kể thay vì một luồng dữ liệu liên tục. Server của bạn không có quyền quyết định bất kỳ điều gì trong số đó, vì vậy khoảng thời gian báo cáo ngắn hơn trong ứng dụng chỉ là một yêu cầu, và điện thoại sẽ phản hồi theo cách nó muốn.

Những gì bạn kiểm soát nằm trên điện thoại: cấp quyền truy cập vị trí nền mọi lúc, loại trừ ứng dụng theo dõi khỏi chế độ tối ưu hóa pin và điều chỉnh chế độ báo cáo phù hợp với từng ngày. Chế độ di chuyển (Move mode) cả tuần là lý do khiến điện thoại hết sạch pin vào lúc bốn giờ chiều.

Triệu chứng ở phía server là một loạt các hàng dữ liệu có timestamp cũ. Cả Traccar Client và OwnTracks đều lưu đệm các điểm tọa độ khi ngoại tuyến và đẩy chúng lên khi có mạng trở lại, vì vậy thời gian ghi (write time) và thời gian xác định vị trí (fix time) là các giá trị khác nhau. Khi bản đồ của bạn vẽ một đường thẳng băng qua thành phố, đó là khoảng trống trong các điểm fix, không phải là một con đường.

Phía máy chủ: TLS và đường dẫn tiếp nhận đã xác thực

Điện thoại cần một hostname mà nó có thể phân giải và một chứng chỉ mà nó tin tưởng. Chứng chỉ tự ký (self-signed) là lý do phổ biến nhất khiến một bản cài đặt mới không nhận được bất kỳ dữ liệu nào: ứng dụng thất bại trong quá trình bắt tay TLS và bỏ cuộc, còn log máy chủ vẫn trống vì yêu cầu chưa bao giờ hoàn tất. Một log trống trông giống như lỗi của điện thoại nhưng thực tế không phải vậy.

Có hai hướng xử lý sạch sẽ. Kết thúc TLS tại nginx bằng một chứng chỉ thực, cụ thể là chứng chỉ Let's Encrypt đặt trước nginx, và chỉ mở cổng 443. Hoặc không mở bất kỳ cổng inbound nào bằng Cloudflare Tunnel để không có gì lắng nghe trên IP công cộng, cách này phù hợp với Dawarich và OwnTracks vì cơ chế tiếp nhận của chúng là HTTP thông thường.

Một hạn chế đối với hướng sử dụng tunnel. Giao thức OsmAnd của Traccar là HTTP, vì vậy client trên điện thoại đi qua reverse proxy hoặc tunnel mà không gặp vấn đề gì. Các giao thức nhị phân mà thiết bị GPS chuyên dụng sử dụng là TCP thuần trên các cổng riêng của chúng, và những giao thức đó cần một cổng mở thực sự, được mở trên firewall của VPS và trên firewall mạng riêng của nhà cung cấp, vốn là một bảng điều khiển khác trên hầu hết các host.

Khi máy chủ đã phản hồi, hãy kiểm tra đường dẫn bằng một yêu cầu thay vì đoán mò từ ứng dụng:

curl -si -u alice:secret -H 'Content-Type: application/json' \
  -d '{"_type":"location","lat":51.5,"lon":-0.12,"tst":1788480000}' \
  https://track.example.com/pub | head -1

Một endpoint hoạt động bình thường sẽ trả về trạng thái 2xx. Mã 401 nghĩa là thông tin xác thực sai nhưng đường truyền vẫn ổn. Một lỗi curl xuất hiện trước bất kỳ dòng trạng thái nào nghĩa là lỗi DNS hoặc TLS, vì vậy hãy sửa chứng chỉ trước khi bạn can thiệp vào ứng dụng.

Endpoint ingest mở làm lộ vị trí của bạn

Một URL ingest không có xác thực sẽ cung cấp vị trí của bạn cho bất kỳ ai tìm thấy nó, và thực tế là người ta sẽ tìm thấy nó.

• Bất kỳ ai có URL đều có thể ghi các điểm dữ liệu vào lịch sử của bạn. Các điểm dữ liệu giả rất khó phát hiện và tốn công để xóa bỏ.
• URL không phải là bí mật. Nó nằm trong cài đặt ứng dụng trên điện thoại, trong access log của reverse proxy, trong lịch sử trình duyệt nếu bạn từng thử nghiệm nó trên một tab, và trong bất kỳ ảnh chụp màn hình nào bạn đính kèm khi cần hỗ trợ.
• Một endpoint phản hồi các yêu cầu GET không xác thực sẽ cung cấp vị trí mới nhất của bạn cho bất kỳ crawler nào đoán được đường dẫn.
• Hostname luôn là công khai dù bạn làm gì đi nữa. Chứng chỉ mới cấp sẽ xuất hiện trong các log certificate transparency chỉ trong vài phút, vì vậy một địa chỉ bạn chưa từng công bố vẫn có thể bị phát hiện.

Hãy sử dụng HTTP Basic qua TLS cho OwnTracks, API key cho Dawarich, và mô hình tài khoản của Traccar với định danh thiết bị duy nhất. Đặt giao diện quản trị phía sau cùng lớp xác thực với đường dẫn ingest, vì giao diện này là nơi toàn bộ hành trình có thể bị đọc. Sau đó, hãy xem ai đã truy cập sau tuần đầu tiên:

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Địa chỉ IP di động của điện thoại bạn nên chiếm ưu thế trong danh sách đó. Bất kỳ thứ gì khác có số lượng truy cập cao đều cần được xem xét, và việc thiết lập rate limit cho vị trí ingest trong nginx không tốn kém gì cả.

Một trình theo dõi cũng có thể bị lỗi âm thầm. Container dừng hoạt động, điện thoại tiếp tục lưu đệm, và bạn chỉ biết điều đó sau vài tuần khi thấy thiếu dữ liệu chuyến đi. Hãy trỏ một health check của container hoặc một OnFailure= của systemd tới server ntfy của riêng bạn để thông báo về sự im lặng đó đến đúng chiếc điện thoại đang thực hiện báo cáo.

Những ai khác có thể thấy lộ trình và cách thức thực thi quyền truy cập

Traccar thực thi quyền truy cập thông qua người dùng và quyền hạn của thiết bị: một tài khoản chỉ thấy các thiết bị mà quản trị viên đã cấp quyền, và API sử dụng session hoặc token. OwnTracks qua MQTT thực thi quyền này tại broker bằng các topic ACL, đây là phương thức mạnh nhất vì một tài khoản không thể subscribe vào một topic thì không thể đọc được dữ liệu đó, bất kể ứng dụng thực hiện thao tác gì. OwnTracks qua HTTP không có lớp tương đương, nên bất cứ thứ gì nằm sau endpoint chính là toàn bộ cơ chế kiểm soát truy cập. Dawarich được xây dựng cho mục đích một người tự xem lịch sử của chính mình, vì vậy khi nhiều người cần theo dõi trực tiếp lẫn nhau, Traccar hoặc một broker sẽ là lựa chọn phù hợp hơn.

Theo dõi gia đình là vấn đề về sự đồng thuận cũng như vấn đề kỹ thuật. Mọi người có điện thoại gửi dữ liệu định vị đều phải biết rằng thiết bị đang gửi dữ liệu và cách để dừng nó lại. Một trình theo dõi mà người dùng không thể tự tắt thì không phải là tính năng dành cho gia đình.

Những vấn đề mà self-hosting không giải quyết được

• Hệ điều hành của điện thoại quyết định thời điểm GPS hoạt động, vì vậy việc hao pin và mất dữ liệu hành trình chủ yếu do điện thoại chứ không phải do server của bạn.
• Google đã thay đổi cách xuất dữ liệu Timeline. Hãy đọc tài liệu import hiện tại của Dawarich trước khi lên kế hoạch di chuyển dữ liệu, vì định dạng file mà Google cung cấp hiện nay khác với định dạng mà người dùng đã import cách đây hai năm.
• Endpoint của bạn sẽ thấy địa chỉ IP di động của bạn trong mỗi request, và các mạng trung gian cũng vậy. Self-hosting chỉ thay đổi đơn vị lưu trữ bản ghi đó, chứ không xóa bỏ bản ghi.
• Lịch sử vị trí là dữ liệu không thể thay thế. Hãy sao lưu database, thực hiện restore thử một lần để đảm bảo bản sao lưu hoạt động tốt, và giữ bản sao đó ở trạng thái mã hóa, vì đây là file nhạy cảm nhất trên server của bạn.

FAQ

Ứng dụng self-hosted nào thay thế được Google Maps Timeline?

Dawarich. Nó được xây dựng như một giải pháp thay thế self-host cho Google Timeline. Nó nhập dữ liệu từ bản xuất Google Maps Timeline, cùng với dữ liệu từ OwnTracks, Strava, Immich, GPX, GeoJSON và EXIF ảnh. Nó hiển thị lịch sử dưới dạng các địa điểm và chuyến đi thay vì bản đồ trực tiếp. Traccar có thể lưu trữ các điểm tương tự, nhưng giao diện của nó là bảng điều khiển đội xe và các báo cáo của nó là báo cáo đội xe. Hãy kiểm tra tài liệu nhập dữ liệu của Dawarich để biết định dạng xuất dữ liệu mà nó yêu cầu trước khi lên kế hoạch di chuyển, vì định dạng xuất của Google đã thay đổi.

Tôi có thể dùng OwnTracks mà không cần MQTT broker không?

Có. Hãy đặt ứng dụng sang chế độ HTTP và cung cấp URL theo dạng http[s]://[user[:password]@]host[:port]/path, đây là /pub cho OwnTracks Recorder. Nó gửi cùng một payload JSON, được xác thực bằng HTTP Basic, và OwnTracks khuyến nghị mạnh mẽ sử dụng scheme https://. Hãy thêm broker sau này, khi hai dịch vụ cần cùng một luồng dữ liệu cùng lúc, hoặc khi bạn muốn kiểm soát truy cập theo từng topic để broker quyết định ai có thể thấy ai.

Một năm lịch sử vị trí cần bao nhiêu dung lượng lưu trữ?

Hãy tính theo số hàng thay vì gigabyte. Một báo cáo mỗi phút là 525,600 hàng mỗi năm cho mỗi điện thoại, và một báo cáo mỗi mười lăm phút là 35,040. Cả hai con số này đều nhỏ đối với PostgreSQL. Giới hạn thực tế nằm ở việc trình duyệt vẽ một năm dữ liệu điểm trên một bản đồ, đó là lý do tại sao các ứng dụng này cần tổng hợp dữ liệu. Hãy đo kích thước bảng của bạn sau một tháng với pg_total_relation_size và nhân với mười hai.

Tại sao lịch sử vị trí của tôi lại có các khoảng trống?

Hệ điều hành của điện thoại quyết định khi nào đánh thức GPS và khi nào dừng một ứng dụng chạy nền, vì vậy hầu hết các khoảng trống bắt đầu từ đó. Hãy cấp quyền truy cập vị trí nền cho ứng dụng mọi lúc, loại trừ nó khỏi chế độ tối ưu hóa pin và kiểm tra chế độ báo cáo. Trong OwnTracks, chế độ Move xuất bản dữ liệu mỗi locatorDisplacement mét hoặc locatorInterval giây, mặc định là 100 mét và 300 giây, và nó tiêu tốn pin ở mức tương đương một ứng dụng dẫn đường. Nếu các hàng dữ liệu đến muộn trong một đợt với các dấu thời gian cũ, đó là do bộ đệm offline đang đẩy dữ liệu ra, nghĩa là các điểm đã được ghi lại và chỉ có việc tải lên bị trì hoãn.

Một URL bí mật có đủ để bảo vệ endpoint vị trí không?

Không. Một endpoint tiếp nhận không xác thực cho phép bất kỳ ai biết được URL đó ghi các điểm giả vào lịch sử của bạn, và một URL không phải là bí mật: nó nằm trong cài đặt ứng dụng, trong access log của reverse proxy, trong lịch sử trình duyệt và trong bất kỳ ảnh chụp màn hình nào bạn chia sẻ. Tên miền (hostname) có thể bị phát hiện, vì một chứng chỉ mới sẽ xuất hiện trong các log minh bạch chứng chỉ (certificate transparency logs) ngay sau khi được cấp. Hãy sử dụng HTTP Basic qua TLS hoặc API key, giới hạn tốc độ (rate limit) đường dẫn tiếp nhận và đặt giao diện quản trị phía sau cùng một lớp xác thực.