我剛剛講的是，如果你用了健保卡上的號碼，再加上戶籍的辨識之後，你是拿到一個初步許可，也就是取得查詢碼，但你使用查詢碼，仍須要再鍵入身分證號及戶口名簿上的戶號，這些號碼就非其他兄弟姊妹能知道的，因此以這三個加起來的資料來作身分辨識應該是安全的。
不過同仁告訴我工作坊討論的結果，好像不太prefer這方案，認為仍有個資揭露顧慮。
所以，我認為除戶籍資料之識別，還要打健保卡裡面的號碼，這資訊除非有卡片否則你的兄弟姐妹比較不會知道，我們認為這樣應可作為辨識的方法。
我們上次提這一個協作會議的概念是，如何把Web版的申報可以比較簡單，不用插卡，不須下載外接讀卡機應用程式, 可大幅減少使用者安裝時間。我們提出的方法是納稅人可用身分證號碼、健保卡卡號及戶籍資料的關係人資料作為身分識別機制。基本上我們的想法是由使用者回答系統提出關係人如父母、兄弟姊妹之姓名、出生年月等戶籍資料，也就是由系統問納稅義務人父母、兄弟姐妹的資料，如果答得出來，應是不假，除非是當事人家屬，但因為撫養親屬是一個權利，他們可能會互相爭取撫養親屬免稅額的權利。
所以大家的意見希望還是提供會議紀錄。
我想會議紀錄倒不是非常需要。
謝謝。
好，要不然針對工作坊的進行方式，我們先作比較具體的規劃，規劃完之後就找PDIS幾個先進談一談，未來實作工作坊時，請PDIS視情況一起join。
當然，很好，非常歡迎。
是。
正在規劃。剛剛政委提的我們會仔細規劃。
對。
對，那是接續的。工作坊的結果，再來談使用者需求確定的時候，會在明年，在明年初談所謂的需求確定。
就是對民眾的說帖，請團隊幫我們檢視一下。
OK。
這個沒有。
所以未來如果需要做使用者體驗有關connection的問題，可能還要額外增加設備。現在設備是跑Unix系統，是嗎？
北部的AP server有六部，中部有四部AP server，上面還要架網路設備組。接下來有兩個報稅的DB server，另外一個是我們真正報稅的所得資料server，那個擺在我們這邊，這個是資安的考慮。主要大致是這樣，所以設備量不是那麼大。
你知道嗎？
費用。這一個案子比較特殊，這一個案子是從系統設計到客服，都是委給他們做的。
設備是先由關貿提供，未來擬定合約的時候，若需要額外的設備，就會變成我們要再調整一下合約，然後再extra補充費用給他們。
我想錢不是優先考量的問題，我們先談，如果有困難，怡君也在這邊，應該可以幫一些忙，我們很多錢從這邊來支持的。
若在5EG裡，也許會好一點。
說到經費，我跟政委簡單報告一下，其實這一些費用都是額度預算，這個案子沒有在第五階段電子化裡面，所以年預算比較吃虧，因為公務預算的額度逐年減少10%，經費比較難。
但是最近有一個工作坊，也就是7至9月會討論比較細的，106年會討論，這一些已經接近要做的這些規格，也會納到裡面去，大概是整個討論的過程這樣子。
真正上線的時候，再做一次問卷調查，是不是可以達到需求，如果不滿意再修，這個是RFP會再要求的事。
設計完之後的雛形，我們找UI、UX專家跟使用者及我一起來檢視是否符合基本的原則，使用者有時不買這樣的帳，有時理論跟使用者不一樣，這個是第二級檢視，因此我們RFP會要求把這樣的程序包在裡面，一定要做到。
我來回應一下，初步討論是這樣子，在108年合約，其實我們目前已經在討論，UI、UX有一些基本原則，上次有幾個教授來給予這些寶貴的資訊，所以這一個基本要求我們會納入，但這一些原則本質上是抽象的，所以我們接下來會在RFP要求，在開始規劃的時候就真的讓使用者一起進來設計。
這個我們有一些討論，是不是可以說明一下？
OK，這個是幅度不小的變動，替代性的軟體要講得很清楚，第二個是要先讓民眾知道，免得明年要報稅的時候，已將MAC環境設定好的民眾一下無所適從。我怕會有這一個issue，因此要早一點讓民眾知道。
提出一個問題，明年方向如果導向以這一個版為主，原來Mac或者是Linux的使用者，明年是不是直接就不提供？
關貿，我們這樣的意見應該是ok吧？
使用者認證我想暫時不改要用讀卡機，我們是用查詢碼的方法來做，我倒覺得可以找關貿來談一下，是不是把後面的scale做大一點，目前的量看能不能承載。額外的費用因為指示，我們是不是可以用預備金來解決，這也是一個解決方法，因此在現有的架構下把後面那個的提高，我覺得是有可能性的，我們再跟關貿洽談這一件事。
不過剛剛政委談的是，我們以現有的手機版方式來應用，未來明年我們把Java版拿掉，讓我們的承載可不可以負擔的量。
現在遠端很多機房的概念，變成我們要研究這一件事，到底用離線版的效益比較大，或者是用線上版，但如果要的話，scale來承載同一個時間爆量的connection，做2P就簡單了，因為連線了，一個人連很久，一萬個人要connection，可能會比較久，這個是我們目前研究的部分。
為什麼考慮離線版？因為Pure Web連線上去，一個人差不多三十分鐘左右，connection會非常大，所以這個是我們擔心未來會不會因為connection太大，造成民眾等待時間過久。
我們來談到的是108年年度，也就是把目前Java拿掉，未來要走的方向是Pure Web，或者是用做一個跨平台的離線版？
目前就現有的Web版來做，承載容量的部分，我們研究一下，我覺得是有空間的。
你們壓測的量是多少？
不使用Java的替代方案是什麼？
車馬費是有的。至於額外的報酬，政府有一些限制；車馬費或出席費一定是會有的。
對，沒錯。
……因為群組比較特定，跟我們的互動也很不錯，所以沒有聽到抱怨。
第五階段？喔！5EG。
108年的規劃是9月開始準備標案，進行標案的程序，預計12月以前標定，明年一整年的時間開發，明年是107年，開發完之後，108年就開始做大量測試及上線前準備。
是在107年所得年度，也就是108年5月就申報。
