Bitwarden ไม่เป็นซอฟต์แวร์เสรีอีกต่อไป

 (github.com/bitwarden)
1 คะแนน โดย GN⁺ 2024-10-21 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • บิลด์ Bitwarden Desktop 2024.10.0 จำเป็นต้องพึ่งพา @bitwarden/sdk-internal และมีการตั้งข้อสังเกตว่าเงื่อนไขไลเซนส์ของ SDK ดังกล่าวที่จำกัดว่า “ห้ามใช้พัฒนาแอปสำหรับซอฟต์แวร์ที่ไม่ใช่ Bitwarden หรือพัฒนา SDK อื่น” ทำให้ไม่เป็นไปตามข้อกำหนดของซอฟต์แวร์เสรี
  • ผู้ตั้งประเด็นระบุว่าข้อจำกัดนี้ขัดกับ freedom 0 ของ GNU และหากลบ dependency นี้ออก จะไม่สามารถบิลด์ desktop-v2024.10.0 และ master ปัจจุบันได้
  • ตัวอย่างการทำซ้ำปัญหาคือ ลบไดเรกทอรี bitwarden_license และทำความสะอาด node_modules ก่อนบิลด์ แล้ว build:preload จะล้มเหลวด้วยข้อผิดพลาด TS2307 6 รายการ เพราะหา @bitwarden/sdk-internal และโมดูล WASM ไม่พบ
  • คอมเมนต์บางส่วนชี้ว่า SDK นี้ถูกใช้เป็น feature flag ไม่เฉพาะใน Desktop แต่รวมถึง browser, CLI, web clients ด้วย ขณะที่ฝั่ง Bitwarden ตอบว่า SDK กับไคลเอนต์เป็นคนละโปรแกรม และการสื่อสารผ่านโปรโตคอลมาตรฐานเพียงอย่างเดียวไม่ทำให้เป็นโปรแกรมเดียวกันในมุมมองของ GPLv3
  • ต่อมา Bitwarden ได้ปรับโครงสร้างโค้ดและการแพ็กเกจของ SDK เพื่อให้สามารถบิลด์ได้โดยมีเฉพาะ ไลเซนส์ GPL/OSI และย้ายการอ้างอิง sdk-internal ของไคลเอนต์ไปยังรีโพซิทอรี sdk-internal ใหม่ ก่อนปิดอีชูนี้ว่าเสร็จสิ้น

ประเด็นที่ถูกยกขึ้น: บิลด์ Desktop 2024.10.0 และไลเซนส์ของ SDK

  • อีชูนี้ถูกเปิดขึ้นโดยระบุว่า Bitwarden Desktop 2024.10.0 ไม่ใช่ซอฟต์แวร์เสรีอีกต่อไป
  • การเปลี่ยนแปลงสำคัญคือ Pull request #10974 ที่นำ dependency @bitwarden/sdk-internal เข้ามาในบิลด์ของเดสก์ท็อปไคลเอนต์
  • ไลเซนส์ของ dependency นี้มีข้อจำกัดดังต่อไปนี้
    • “ไม่สามารถใช้ SDK นี้เพื่อพัฒนาแอปพลิเคชันสำหรับซอฟต์แวร์ที่ไม่ใช่ Bitwarden รวมถึงซอฟต์แวร์ที่มี implementation ที่เข้ากันไม่ได้กับ Bitwarden และไม่สามารถใช้เพื่อพัฒนา SDK อื่นได้”
  • ผู้ตั้งประเด็นมองว่าข้อกำหนดนี้ละเมิด freedom 0 ตามนิยามซอฟต์แวร์เสรีของ GNU
  • นอกจากนี้ยังระบุว่า หากไม่ถอด dependency นี้ออก ก็จะไม่สามารถบิลด์ desktop-v2024.10.0 และอาจรวมถึง master ปัจจุบันได้

การบิลด์ล้มเหลวที่ทำซ้ำได้

  • ผู้ตั้งประเด็นลองบิลด์ด้วยวิธีเดิม คือเอาไดเรกทอรี bitwarden_license ออก แล้วใช้ node_modules ที่ถูกล้างแล้ว
  • การบิลด์ล้มเหลวที่ขั้นตอน build:preload ของ apps/desktop
  • ข้อผิดพลาดคือ TS2307 ที่ระบุว่าไม่พบโมดูลหรือ type declaration ของ @bitwarden/sdk-internal ในหลายไฟล์
    • libs/common/src/platform/abstractions/sdk/sdk.service.ts
    • libs/common/src/platform/abstractions/sdk/sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/default-sdk.service.ts
    • libs/common/src/platform/services/sdk/default-sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/noop-sdk-client-factory.ts
  • ยังมีข้อผิดพลาดว่าไม่พบพาธ WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm
  • ส่งผลให้ webpack 5.94.0 คอมไพล์ไม่สำเร็จด้วยข้อผิดพลาด 6 รายการ และ npm run build:preload จบด้วยโค้ด 1

ปฏิกิริยาจากชุมชนและความกังวลที่ขยายวง

  • คอมเมนต์หนึ่งอ้างถึงอีชูที่เกี่ยวข้อง bitwarden/sdk-sm#898 พร้อมแสดงความกังวลว่า Bitwarden กำลังโฆษณาตัวเองว่าเป็นโอเพ่นซอร์ส แต่กำลังเปลี่ยนไปเป็นซอฟต์แวร์กรรมสิทธิ์
  • ผู้ใช้อีกรายบอกว่าปัญหาคล้ายกันนี้ใน NPM release ของ CLI client เคยถูกรายงานไว้เมื่อสองเดือนก่อนใน #10648 แต่ไม่ได้รับการตอบกลับ
  • ผู้ใช้บางส่วนกล่าวถึงทางเลือก เช่น การฟอร์กเวอร์ชันเก่า, Vaultwarden และแอปเดสก์ท็อป Tauri ที่ครอบเว็บอินเทอร์เฟซของ Vaultwarden
  • คอมเมนต์หนึ่งชี้ว่า เนื่องจากเป็นผลิตภัณฑ์ที่เกี่ยวข้องกับรหัสผ่าน การย้ายไปใช้ “ทางเลือกอะไรก็ได้” ควรทำอย่างระมัดระวัง และแม้จะฟอร์กเฉพาะไคลเอนต์ ปัญหาการพึ่งพาบริการเซิร์ฟเวอร์หรือซอฟต์แวร์ฝั่งเซิร์ฟเวอร์ก็ยังคงอยู่
  • อีกคอมเมนต์อ้างว่า SDK นี้ไม่ได้ถูกใช้เฉพาะใน Desktop release แต่ยังถูกใช้เป็น feature flag ใน browser, CLI, web clients ด้วย และระบุว่าทุกเวอร์ชันของ Bitwarden 2024.10.0 ใช้ SDK นี้

คำชี้แจงเบื้องต้นจากฝั่ง Bitwarden

  • สมาชิกของ Bitwarden ตอบว่า แม้จะมีการขยายการใช้ SDK ในไคลเอนต์มากขึ้น เป้าหมายยังคงเป็นการทำให้การใช้ SDK คงความเข้ากันได้กับ GPL
  • ฝั่ง Bitwarden ให้เหตุผลไว้ 3 ข้อดังนี้
    • SDK และไคลเอนต์เป็นคนละโปรแกรม
    • โค้ดของแต่ละโปรแกรมอยู่คนละรีโพซิทอรี
    • การที่ทั้งสองโปรแกรมสื่อสารกันผ่านโปรโตคอลมาตรฐาน ไม่ได้ทำให้กลายเป็นโปรแกรมเดียวกันสำหรับวัตถุประสงค์ของ GPLv3
  • ปัญหาที่ผู้ใช้ไม่สามารถบิลด์แอปด้วยวิธีดังกล่าวได้ ถูกระบุว่าเป็น บั๊ก ที่จะมีการแก้ไข
  • หลังจากนั้น บทสนทนาถูกล็อกโดย Bitwarden และจำกัดไว้เฉพาะ collaborator

การปรับแก้ขั้นสุดท้ายและการปิดเรื่อง

  • Bitwarden ระบุว่าได้ปรับโครงสร้างโค้ดของ SDK และวิธีการแพ็กเกจ เพื่อให้สามารถบิลด์และรันแอปได้โดยมีเฉพาะ ไลเซนส์ GPL/OSI เท่านั้น
  • การอ้างอิงแพ็กเกจ sdk-internal จากฝั่งไคลเอนต์ถูกเปลี่ยนให้มาจาก sdk-internal repository ใหม่
  • มีการอธิบายว่ารีโพซิทอรี sdk-internal ใหม่นี้ใช้โมเดลไลเซนส์เดียวกับที่ Bitwarden ใช้กับไคลเอนต์เดิม โดยอ้างอิงข้อมูลที่ LICENSE_FAQ.md
  • ปัจจุบัน การอ้างอิง sdk-internal นี้ใช้เฉพาะไลเซนส์ GPL
  • หากในอนาคตมีการใส่โค้ดภายใต้ Bitwarden License เข้าไปในการอ้างอิงดังกล่าว ก็จะมีวิธีสำหรับสร้างหลายรูปแบบของบิลด์ได้ คล้ายกับการบิลด์ของ web vault client
  • เดิมที sdk repository จะเปลี่ยนชื่อเป็น sdk-secrets และยังคงโครงสร้าง Bitwarden SDK License เดิมไว้สำหรับผลิตภัณฑ์ธุรกิจ Secrets Manager
  • โค้ดในรีโพซิทอรีและแพ็กเกจ sdk-secrets ไม่ได้ถูกใช้ในแอปไคลเอนต์ จึงจะไม่ถูกอ้างอิงจากแอปไคลเอนต์อีกต่อไป
  • อีชูนี้ถูกปิดเมื่อวันที่ 25 ตุลาคม 2024 ด้วยสถานะ completed

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
tribela 2024-10-21

ฉันชอบใช้ KeePass มาก แต่เห็นคนพูดถึงแต่ Bitwarden กันเหลือเกินเลยคิดว่าจะลองใช้ดูสักครั้ง สุดท้ายคงต้องใช้ KeePass ต่อไปดีกว่า เพราะมันไม่ใช่แบบที่ต้องพึ่งเซิร์ฟเวอร์ แค่เก็บไฟล์ให้ดีก็พอ ทำให้พร้อมใช้งานได้สูงกว่ามาก และสำหรับฉัน KeePass ตอบโจทย์มากกว่า
 
GN⁺ 2024-10-21
ความคิดเห็นจาก Hacker News

  • ที่ยอมจ่ายเงินก็เพราะคาดหวังว่าจะได้สนับสนุน โอเพนซอร์ส และด้วยเหตุนี้จึงย้ายจาก LastPass มา Bitwarden
    เรื่องครั้งนี้ให้ความรู้สึกเหมือนถูกมีดปักหลังแล้วบิดซ้ำ ดูเหมือน CEO Michael Crandell จะมาถึงจุดเปลี่ยนทางการเงินคล้ายตอนขาย RightScale เลยอาจกำลังเตรียมให้ถูกซื้อกิจการ: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • แม้แต่เอกสารปี 2022 ในหน้านั้น ใต้หัวข้อ “อะไรจะเปลี่ยนไป?” ก็ยังเขียนไว้ว่า Bitwarden จะยังคงรักษา สถาปัตยกรรมโอเพนซอร์ส ต่อไป
      ตอนนี้ดูเหมือนจะไม่ใช่แล้ว เป็นการเคลื่อนไหวที่อันตราย โอเพนซอร์สมีคุณสมบัติที่ดีหลายอย่าง แต่สิ่งสำคัญในกรณีนี้คือความปลอดภัย ผมแปลกใจเสมอที่บริษัทต่าง ๆ เอาก้อน binary ทึบ ๆ มาอ้างว่าปลอดภัย Intel Management Engine ก็เป็นแบบนั้น และตอนนี้ Bitwarden ก็เหมือนไปเข้าพวกเดียวกับ IME และสวิตช์ Juniper แล้ว
      การไปทาง closed source เป็นตัวเลือกที่มีความเสี่ยงสูง ตลอดเวลาที่ผ่านมา ผมไม่ได้จ่ายเงินให้ตัวซอฟต์แวร์เอง แต่ผมจ่ายเพื่อความปลอดภัยได้ และก็จ่ายจริง Bitwarden ได้เงินผมเพราะมันเก็บสิ่งที่ผมถือว่ามีค่าที่สุดและเป็นส่วนตัวที่สุด แต่ท้ายที่สุดมันก็เป็นแค่ซอฟต์แวร์ และ byte ที่เรียกว่า “bitwarden” นั้นมาจากไหนก็ไม่สำคัญ ใครก็ fork แล้วให้ byte ชุดเดียวกันได้ ถ้ามีคนรัน mirror ของ Bitwarden ที่ใช้แต่ซอฟต์แวร์โอเพนซอร์ส เงินของผมก็จะไปทางนั้น ยิ่งถ้ามีคำสั่ง build ที่ทำให้ reproducible ได้ว่า binary ที่รันอยู่กับ binary ที่ผมดาวน์โหลดลงอุปกรณ์หลายเครื่องเป็นตัวเดียวกัน ก็ยิ่งดี ผมไม่ถือว่ารหัสผ่านของผมปลอดภัย เว้นแต่ว่ามันถูกจัดการโดยซอฟต์แวร์โอเพนซอร์ส

  • การเคลื่อนไหวครั้งนี้ไม่ได้ทำให้แปลกใจมากนัก Bitwarden ขยับไปทาง ฝ่ายขายองค์กร อย่างหนักในช่วงไม่กี่ปีที่ผ่านมา และระหว่างนั้นก็ปล่อยฝั่งผู้บริโภคทิ้งไว้
    เพิ่งไม่นานมานี้เองที่เปลี่ยนจากฐาน MAUI เดิมมาเป็นแอป iOS แบบ native โดยแอปเก่าดูผิดแผกในหลายแง่มาก ตอนนี้ไคลเอนต์ iOS เองก็ยังมีส่วนที่ต้องตามให้ทันอยู่
    หลังจากรับเงินทุน VC แล้ว ดูเหมือนจะเอนไปเน้นรายได้และกำไรมากขึ้น ตัวเลือกนั้นไม่ได้ผิดในตัวเอง แต่เป็นทิศทางที่ค่อนข้างต่างจากวิธีที่บริษัทเริ่มต้นและเติบโตมา
    Proton Pass ก็น่าสนใจอยู่บ้าง แต่เหมือนบริการอื่น ๆ ของ Proton โมเดลราคามักจะสูงไปนิดเสมอ ผมลองใช้ Proton Pass แบบฟรีมาพักหนึ่งแล้ว และเพราะ Bitwarden ไม่ได้พัฒนาไปในทิศทางที่รอมาหลายปี เลยจะดูว่าคุ้มไหมที่จะย้ายไปใช้ตัวเลือกแทน
    ตัวจัดการรหัสผ่านในตัวของ iOS ก็ใช้ได้ดีพอสมควร แต่เป็นเฉพาะรหัสผ่าน และไม่รองรับการจัดเก็บ ค้นหา และกรอกอัตโนมัติสำหรับข้อมูลประเภทอื่น

    • น่าขันดี บางบริษัทอาจใช้ Bitwarden อยู่เพราะมัน เปิดกว้าง และไม่ต้องผ่านสายฝ่ายขายองค์กรเพื่อใช้สิ่งที่มีประโยชน์มาก ๆ
      ถ้าทำให้ผลิตภัณฑ์ใช้งานยากขึ้น ก็จะเสียลูกค้าและโอกาสการขาย นึกถึงสายคุยแย่ ๆ ที่เพิ่งมีกับ Postman ขึ้นมา แทนที่จะต้องคุยโทรศัพท์อีกครั้ง ตอนนี้ Hoppscotch ดูดีกว่ามาก
    • ทำไม เงินลงทุน VC ถึงแทบจะทำให้ทุกอย่างพังอยู่เสมอ

  • คำตอบของ CTO บอกว่าได้ขยายขอบเขตการใช้ SDK ไปยังกรณีของไคลเอนต์มากขึ้น แต่เป้าหมายคือให้ SDK ถูกใช้ในลักษณะที่ยังคง ความเข้ากันได้กับ GPL
    เขามองว่า SDK กับไคลเอนต์เป็นโปรแกรมแยกกัน โค้ดของแต่ละโปรแกรมอยู่ใน repository แยกกัน และเพียงแค่โปรแกรมทั้งสองสื่อสารกันด้วยโปรโตคอลมาตรฐานไม่ได้ทำให้กลายเป็นโปรแกรมเดียวตาม GPLv3 ส่วนประเด็นที่ต้องสามารถ build แอปด้วยวิธีที่พยายามทำในที่นี้ได้นั้น เขาบอกว่าเป็นแค่ bug ธรรมดาที่จะแก้ไข

    • คำตอบแนวนี้น่าหงุดหงิดจริง ๆ เพราะมันเลี่ยงคำถามจริงด้วยการเหมือนจงใจเข้าใจขอบเขตคำถามผิด
      สิ่งที่อยากถาม CTO ประมาณนี้คือ คุณตอบแล้วว่า “ทนายของพวกคุณมองว่าหลบเรื่องนี้ทางกฎหมายได้ไหม?” แต่ไม่ได้ตอบคำถามหลักที่ผู้คนกังวล ทีม Bitwarden มองว่าไม่มี ปัญหาทางจริยธรรม ในการทำให้โปรเจกต์ที่ผู้คนจำนวนมากสนับสนุนและมีส่วนร่วมอย่างชัดเจนเพราะเป็นโอเพนซอร์ส กลายเป็นของเอกชนหรือ? การจัดการรหัสผ่านเป็นธุรกิจที่ต้องการความไว้วางใจสูงโดยธรรมชาติ แล้วจะรับมือกับความแตกร้าวของความไว้วางใจ การ fork และการย้ายหนีที่เกิดจาก rug pull จากโอเพนซอร์สไป closed source อย่างไร? ถ้าบริษัทอยู่ในสถานการณ์สิ้นหวังถึงขั้นต้องพิจารณาการตัดสินใจแบบนี้ ไม่มีวิธีที่ชุมชนจะช่วยกันพาผ่านไปโดยไม่ต้องทำให้เป็นของเอกชนหรือ?
      ผมเข้าใจว่าในฐานะ CTO ตอนนี้หน้าที่คือทำทีเป็นห่วง โดยเฉพาะในฟอรัมที่ปิดบทสนทนาไม่ได้ แต่แนวทางตอนนี้แทบจะยืนยันความกลัวที่แย่ที่สุดว่า “เราเชื่อว่าทำได้ตามกฎหมาย และไม่เห็นว่าการกระทำของเรามีปัญหา” นี่เป็นบรรยากาศที่ผิดอย่างยิ่งสำหรับบริษัทที่ทำเงินได้ก็ต่อเมื่อผู้ใช้ต้องเชื่อใจโค้ดและคนที่อัปเดตมัน
    • พูดอีกอย่างคือ bitwarden/clients เป็น GPLv3 แต่ไคลเอนต์ Bitwarden ในฐานะองค์รวมที่ใช้งานได้เป็น ซอฟต์แวร์กรรมสิทธิ์ และ CTO มองว่าไม่มีปัญหา ส่วน issue ก็ถูกล็อกแล้ว
    • ประเด็นหลักไม่จำเป็นต้องเป็นว่าเป็น “โปรแกรมเดียว” หรือไม่ ปัญหาอยู่ตรงนี้
      “สำหรับงานในรูป object code ‘ซอร์สที่สอดคล้องกัน’ หมายถึงซอร์สโค้ดทั้งหมดที่จำเป็นต่อการสร้าง ติดตั้ง และรัน object code รวมถึงการแก้ไขงานนั้น และสคริปต์ที่ใช้ควบคุมกิจกรรมเหล่านั้น”
      ผมเข้าใจจริง ๆ ว่าการทำเงินในฐานะบริษัทโอเพนซอร์สนั้นยากมาก นั่นจึงเป็นเหตุผลที่ผมเองก็เป็นหนึ่งในลูกค้าแบบจ่ายเงิน
      เงื่อนไขยกเว้นที่ใส่ไว้กับ SDK ดูคล้ายมากกับซอฟต์แวร์ควบคุมเวอร์ชัน BitKeeper ที่เคยใช้กับ Linux kernel อยู่ช่วงหนึ่ง ไปดูตอนจบของเรื่องนั้นได้เลย

  • เคยชอบ เคยจ่ายเงิน และถึงขั้นแนะนำให้เพื่อน ๆ ใช้ ซึ่งพวกเขาก็ชอบด้วย
    ตอนนี้ว่าจะย้ายไป KeePassXC มีวิธีไหนแนะนำสำหรับ sync database กับ Android บ้าง? มีแค่เซิร์ฟเวอร์ Raspberry Pi ที่รัน cloudflared อยู่

    • ถ้าอยากคงความสะดวกแบบคลาวด์ไว้โดยไม่กลับไปเจอ sync conflict จากการย้ายไฟล์ Proton Pass เป็น GPLv3。ただถ้าภายหลังเกิด rug pull ผมเองก็ไม่รู้ว่าสถานการณ์ self-hosting จะเป็นอย่างไร
      https://github.com/ProtonMail/WebClients/tree/proton-pass%40...

https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...

[https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE](<https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE>;)

  • ใช้ SyncThing เพื่อกระจายคลัง KeePass ไปเฉพาะอุปกรณ์ที่จำเป็นอย่างแม่นยำ สำหรับผมมันทำงานได้ดีมาก แต่อาจต่างกันไปตามความต้องการ

  • อยากใช้ KeePass กับ ecosystem ของมันจริง ๆ แต่ การแชร์รหัสผ่าน ไม่ค่อยดีนัก ผมกับภรรยามีรหัสผ่านที่ใช้ร่วมกันเยอะ และ Bitwarden ทำส่วนนี้ได้ดีมาก ไม่รู้ว่าทางเลือกที่ใช้งานได้จริงสำหรับเราคืออะไร

  • Keepass2Android ซิงก์ได้หลายวิธี เช่น ssh(sftp), Nextcloud น่าจะหาวิธีที่เหมาะกับคุณได้

  • การใช้ KeePassXC ร่วมกับไคลเอนต์ Nextcloud สำหรับ Android นั้นสมบูรณ์แบบสำหรับผม ใช้มาหลายปีโดยไม่มีปัญหา

  • GitHub issue ถูกล็อกไม่ให้ถกเถียงต่อแล้ว ทางเลือกหนึ่งที่เป็นไปได้ดูเหมือนจะเป็น Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    น่าเศร้าจริง ๆ ที่เรื่องแบบนี้เกิดขึ้นซ้ำ ๆ ในโปรเจกต์โอเพนซอร์สเมื่อคนมีเงินเข้ามา

    • Vaultwarden เป็นตัวทดแทนฝั่งเซิร์ฟเวอร์ และปัญหาตรงนี้ เท่าที่ผมเข้าใจ คือ ไลเซนส์ของเดสก์ท็อปไคลเอนต์
    • García เพิ่งเริ่มทำงานที่ Bitwarden เมื่อไม่นานมานี้ น่าจะน่าสนใจถ้าได้ฟังความเห็นของเขา
    • Vaultwarden รองรับ passkey ไหม?

  • ไม่เคยดูละเอียด ๆ แต่จากการตลาด ผมคิดว่า Bitwarden เป็น ซอฟต์แวร์เสรี อย่างสมบูรณ์ แต่ดูเหมือนว่าตั้งแต่ราวปี 2020 จะมีองค์ประกอบแบบ proprietary แปลก ๆ เข้ามา

  • เคยหวังว่าสักวันจะย้ายไป Bitwarden แต่ถ้าหา ระบบนิเวศแบบเปิด ที่แข็งแรงไม่ได้ ตอนนี้คงไม่ทำแล้ว จะคอยดูต่อไปว่าเรื่องจะเป็นอย่างไร

    • ผมลองย้ายมาใช้ Bitwarden เต็มรูปแบบโดยต่อกับ backend ของ Vaultwarden เป็นเวลา 1 ปี แต่เมื่อเทียบกับ 1Password ที่เคยใช้ ประสบการณ์ด้อยกว่ามาก
      เกณฑ์ประเมินอย่างหนึ่งคือ “ทุกคนในครอบครัวใช้ 1Password และพอใจกันอยู่ ระดับนี้พอจะโน้มน้าวให้พวกเขาย้ายได้ไหม” การตัดสินใจย้ายสุดท้ายผมทำได้เองก็จริง แต่ถ้าจะให้พ่อแม่ที่อายุมากลองของใหม่ ประสบการณ์ผู้ใช้สำคัญมาก
      ผลคือไม่ได้ โดยรวม UX ไม่ดีแล้ว ไคลเอนต์ Bitwarden ยังช้ากว่ามากทั้งบน Linux, Mac, Windows, iOS ตั้งแต่การค้นหาไปจนถึงการล็อกอินก็เป็นแบบนั้นทั้งหมด ฟีเจอร์ก็น้อยกว่า ขาดส่วนที่เห็นชัดอย่างการจัดเรียงรหัสผ่าน รายการโปรด เครื่องมือจัดระเบียบที่ดี และการกรอกอัตโนมัติก็เสถียรน้อยกว่ามาก
      ผมมีความไม่พอใจกับวิธีทำธุรกิจและการรับมือลูกค้าของ 1Password มาหลายปี แต่ตัวจัดการรหัสผ่าน—ตอนนี้ใกล้เคียงกับตัวจัดการความลับที่เก็บมากกว่ารหัสผ่านแล้ว—เป็นศูนย์กลางของชีวิตประจำวัน เลยรู้สึกว่าควรใช้สิ่งที่เจ็บปวดน้อยที่สุดเท่าที่เป็นไปได้ สุดท้ายจึงน่าเสียดายที่กลับไปใช้
      ผมไม่ได้ใช้ Bitwarden เพราะมันเป็น open source แต่เพราะพยายามใช้ตัวจัดการรหัสผ่านที่ดีที่สุดเท่าที่จะเป็นไปได้ ถึงอย่างนั้นก็ชอบที่มัน เปิด และ Vaultwarden ก็เหมือนอัญมณี หวังจริง ๆ ว่าจะมีเวลาและฝีมือพอสร้าง frontend ที่ดีกว่านี้

  • “ตอนนี้ยังไม่มีแผนจะปรับ ไลเซนส์ SDK เราจะเผยแพร่ต่อใน F-Droid repository ของเราเอง https://mobileapp.bitwarden.com/fdroid/repo/”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    ประเด็นนี้ถูกหยิบยกขึ้นมาใน repository ของ SDK ตั้งแต่เดือนกรกฎาคมแล้ว และ SDK ดังกล่าวใช้ไลเซนส์นี้มานานกว่าหนึ่งปี

  • ใช้ Bitwarden บน iOS, PC, Mac อยู่ ตอนนี้ต้องหาทางเลือกแล้ว เป็นวันที่น่าเศร้าจริง ๆ
    ผมก็เป็นสมาชิก Premium ปีละ 10 ดอลลาร์เหมือนกัน กลายเป็นรายได้ที่เสียไปเพราะแนวปฏิบัติน่าสงสัย
    มีวิธี export แล้วอพยพไปทางเลือกอื่นไหม?

  • เป็นโปรเจกต์ที่ผมจับตาดูอยู่ เผื่อจะเป็นทางเลือกที่ดีกว่า Keepass(X,XC) สำหรับผม แต่ตอนนี้คงไม่ย้ายในที่สุด