數據分析有可能做成社會不公平

黑人在某些外國社會裡本身可能是較受到歧視的族群。
而既有的社會資源分配方法對於黑人本身就可能是較不公平。
AI﹑大數據分析等,在利用既有數據driven來智能化﹑自動化﹑科技化的同時,也可能因著data而learn了那些本來不公平的社會資源分配法則,繼續做成歧視及不公。

這個論點其實都不是我原創,以前聽人說過。
是否真的會如此,我覺得都並不一定,因為不是所有數據driven的分析最後都會得出那種結果吧。
但始終整個argument仍是言之成理。
在社會科學﹑政策研究﹑科技三者的研究結合時potentially也可能要考量這些。

其實加入人為解讀及調整去平衡,也許就能抵消那些問題。

黑人族群的貧窮問題

純粹假設而言,如果統計模型上某社區的黑人犯罪率特別高,那針對統計模型而作出一些措施,也有可能是情有可原。

我的意思,完全不是歧視血統種族優劣什麼的。

其實有些社會裡,黑人被歧視是既有的事實(不代表是合理)。
因為黑人被歧視,所以黑人的族群就得到較少機會﹑資源,繼而結構性地做成黑人族群的貧窮。
我手頭沒有實質數據,但我純粹估計的話,黑人在美國或美國部份地區可能是相對貧窮的族群。
當然,黑人之中也有富足的人,但我指的是整體的統計model。

而黑人族群的貧窮,可能做成黑人族群的隔代貧窮的惡性循環。
而隨貧窮而來,就可能衍生犯罪率等問題。
如果簡化問題,很多人就可能會得出黑人就是犯罪率的因果關係。

如上面的推論,我是相信當中或許有Correlation關係,但並不是因果關係。
有些針對黑人族群的「成見」,有些時候可能是大概是對的,但不一定是因為血統,而是可能因為社會出於歧視而做成資源分配不公所結構性引起的結果。

Fortel v6.3.0 release notes

=== Fortel v6.3.0 release notes ===
Release date: 2017-06-17:

New feature:

  • 加入智能輸入功能。
    • 智能粵語語音輸入(只支援Chrome):
      若在電腦或電話上使用chrome,可以使用粵語語音輸入。
    • 智能文字輸入
      系統現支援智能文字輸入。
    • 智能輸入功能能夠支援類似以下的文字格式:
      • “一九八六年二月六日 早上8時30分男士”
      • “農曆1986年2月6日 晚上8:30 女士”
      • “舊曆1986年正月初六 8:30PM 女士”
      • “西曆1986-2-6 20:30 先生”
      • “公曆86年2月6號 夜晚8點半小姐”

=========================

Fortel 紫微斗數排盤網網址: https://www.myfortel.com/
project homepage: http://blog.airic-yu.com/mycode/fortel

My Sharing about a Workshop for Building Serverless Application

Recently I participated a workshop about building serverless application. And this is my feedback sharing.

What is built in the workshop?

More detail to say, the workshop is actually let developers to have a taste on using a serverless cloud solution to implement a simple web application.

The web application is a kind of simple web page for polling lunch food.

 

Usual way: Web server with Backend

Usually to build such such web page, we may need a backend web server which serve the web page. And the backend may also need handle user login service, and connect with database for access the polling record data as well.

 

The “Serverless” way: Delegate backend to “backend-as-a-service” cloud

What means by the “serverless” in the workshop context is “no backend”. It means that developers may no need to handle/worry about the backend part but only focus on building the frontend web page. Hence, in the workshop, I just wrote some static HTML page and static frontend JS script only. (i.e. C Drive上網大法)

But…How can it be “no backend”????

Actually there is still kind of “backend” but it is delegated to the serverless cloud solution (“backend-as-a-service”). Hence, The backend services are hosted on cloud and services exposed as APIs.

And developers(e.g. me) may just writing static frontend page which invoking the cloud APIs in order to use login service and access the polling record data directly.

 

But My Concerns …

However, after the workshop I have some concerns about such serverless/backend-as-a-service technology.

 

1) Transparent API key in frontend

In the above simple sample which I played in the workshop, the backend APIs are requiring an static API key to call. But the API key is put in the static frontend page which is transparent to end user. (I can easily see it with firebug)

If the API key is required to call backend service or even accessing cloud database records directly, exposing the API key may introduce security problem if not carefully handled the doors.

My conversation with their engineer

I asked their engineer about my security aspect concerns. And I further ask them if they have aware of it, would it be a factor which pushing such technology to be limited on some private/internal website solutions instead.

The engineer answer me that the webpage in workshop is just for tasting. For other platform like mobile app, the source code is not visible to end user and developers may even use ProGuard to obfuscate the byte code.

Then I didn’t further talk on the questions because I feel they have no way to resolve the security issues.

Andoird app can be cracked to access APK file. And hackers can decompile APK to get source code. While ProGuard may only slow down how hackers do reverse engineering but it cannot prevent them to do so. So the problem is still there.

 

2) Potential XSS issue

During the workshop I wrote HTML page in local as C-drive-file (i.e. C Drive上網大法), but their “backend-as-a-service” APIs are on their cloud website domain.

Normally such cross domain Ajax call is blocked by browser to prevent webpage running cross site script (i.e. XSS).

Such browser security restriction can be resolve by defining Cross-Origin Resource Sharing (CORS) HTTP headers. And that is what they did.

It is OK if you don’t understand what I said in above paragraph. The fact is that, their cloud service APIs are allowing any website to access them.

What is the potential problem? Of coz … XSS attack.

If an end-user didn’t logout the “serverless” webpage and then continue browsing other websites, there is a chance which other dirty website may try invoking the cloud service APIs to hack something.

 

What did I learn?

Through the workshop I tasted the serverless/backend-as-a-service technology which is really fancy for developers to build webs without concerning much about the backend part.

However, as I stated, security is a very important concerns. And developers playing such technology must have awareness on the security aspects. Developers should ask themselves about:

Where are the back doors? Is the back doors acceptable? Or shall we use workarounds to cover the back doors? Or is it worth to take the tradeoff to use such technology after our evaluation?

 

What I have learnt from other BAAS solutions?

From time to time, actually I heard about some other technology concepts which may share some similarity of technology I tried in the workshop.

For example, I have ever heard of some other backend-as-a-service solutions provided by vendors. And they may share some security concerns which I mentioned above.

I have also ever heard of some vendor solution which directly turning the “Database with tables, schema, records” into REST API. And the solution may directly exposing the REST API to external systems. (Database-as-REST-API?)

It may be not that promising as expected although it firstly sounds good because:

1) Simply transforming Database schema into REST API definition may producing some un-developer-friendly naming problems which may not be developer friendly. And the DB schema may not be a developer-friendly representation of data structures for API consumer to understand as it is not intended for such purpose. Actually, usually a common problem is that the DB schema is too complicated and bulky that external domain consumer developers cannot understand how to directly consume it. Exposing database as REST API would not solve such problem.

2) Database has transactions. However, stateless is one of the philosophy of REST API. REST API Resources would usually not providing the same level of transaction controls. So such Database-as-REST-API approach may either broke the Database transaction functionality, or turning the REST API into something violating REST API philosophy.

(Off topic too much….so I would stop here)

想想你在年輕的時候

我有時幾鍾意接觸d freshman developer,因為岩岩出黎社會年輕有幹勁。
反而有時做多幾年野之後人好易滑晒瓦。

人在社會,either是環境把你塑造成環境的形態,or你去反影響﹑反塑造環境的形態。

當人們身處一間公司或一個環境,而人們把自己的視野與界限限定在公司裡面,其實有可能在三幾年後你就會變成了公司/環境/社會的形態。
甚至當初你有些理念而堅持反對一些東西,到最後你變成了你所反對的東西。「限制」變成了你不知不覺習慣了的一部份。

有時會聽見人們說「想去學乜乜乜」。
其實如果有心學些什麼,網上﹑世界大把resources。
我自己也不會有一種一定要在公司裡學習什麼什麼的概念,因為那是自我設限。
面向世界﹑擴闊境界,是獲益更多的。

有時我會跟一些比較fresh的同事在公事之後傾多兩句公事。
了解一下他們平時做事上有沒有遇到過些什麼問題?有沒有什麼想法可以令d事做好一點?

年輕人,會有理據地complain什麼什麼的,很好,fast feedback,能把事更好的改進。
年輕人,有時理想主義一點,是好的,值得我去反思自己是否不知不覺放棄了一些價值。
我自己希望能繼續用「年輕人」的心態做人,另一方面當面對真的後生年輕人,我也希望能幫助到他們,不要令他們滑瓦。

REST mindset

我真係見過,好多人做REST API,做到….

講REST API其實一定要知resource既概念。
我以前真係見過,有developer係用個Java interface class(util service果種)黎做REST resource。(我study過擺明唔係intended design)
點解?
因為好多developer做野唔會深究去諗點解,只要駁得通d library,call到,做到requirement,咁就OK。
佢地so called係做REST,但其實個mindset只係做RPC而已。

但其實做REST API最重要係個mindset。

點解要做REST API?
係因為對consumer來說簡單易用,低使用門檻,低學習門檻。
所以REST API最核心精神就是consumer oriented。
consumer oriented衍生出來的,就是借用HTTP protocol method & status去做Resource及CRUD。

其實真係可以問問果堆developer,佢地有冇諗過咩叫REST?點解要做REST?點樣先係consumer oriented?
如果冇,其實可以由今日開始問下自己多d依d問題。

面對API這東西,在「environment」裡面,對我來說最大的問題從來不是什麼tools,也不是business什麼,而是人們的mindset與culture。

[it學術研究] 熱血時報節目like/分享/留言數字之謎

[itdog學術研究][熱血時報節目like/分享/留言數字之謎]
 
從熱血時報網頁上看到《建國神話XXXXXX》的facebook數據,是「Like:1474 分享:1474 留言:34」
由於like及分享的數目永遠一樣,所以我自己都覺得好奇怪,所以我自己就去了驗證一下。
 
從網頁的ajax request上查找到這條GET request:
 
 
這一條request,是熱血時報call facebook的API拿取數據,這數據是來自facebook的。
而其response的結果是:
 

 

 
其response中的1474與34,正正是like/分享及留言的數目。
 
我修改了一下request:
 
 
得出的結果如下:
 

上面的數字解釋:
359: 是熱血時報原本的那個post的like count (哈哈﹑嬲嬲那些不計作like)。
19: 是熱血時報原本的那個post的comment數目。
 
至於1474與34…
 
1474那個就是平時網頁上看到Facebook like button上面的那種”1.4K people like this.”的那個數字。
我在facebook查找一下就可以知道這數字包括了什麼。
 
What makes up the number shown next to my Like button?
The number shown is the sum of:
1) The number of likes of your URL
2) The number of shares of your URL (this includes copy/pasting a link back to Facebook)
3) The number of likes and comments on stories on Facebook about your URL
 
即是原本的post的like及comment,以及這條URL在facebook上有幾多人share,以及這些post所衍生出來的like及comment,所有總數加起來的數字。
所以嚴格來說,那不是真正的「like」數目,也不是真正的「share」數目,而是facebook把所有engagement加起來的數字。
 
至於34個comment,也應該是類似的把share的數目aggregate出來的,至於實際如何計算我就未能在facebook上找到。
我也數不到如何才count到34。
 
另外,我試過share/comment,但無論是private還是public post,數字都沒有update到,所以那些value可能是cached value或Schedule update value。(未必update)
 
—————————————
 
結論:
網頁上like及share及comment的那些數字(1474, 34)是來自facebook,這數字不是假的。
不過熱血時報把那些數字labelled as 「Like:1474 分享:1474 留言:34」,其實某程度上算是有點誤導(可能是programmer之無心之誤)。
 
熱血時報原本的那個post的like及comment數目分別是359及19。(不計再share出去的post所衍生的數字)
嚴格來說,1474是engagment(參考上面)
而like及share的各自數字未能得知,但計埋衍生數字,總like數必定多於359及少於1474。(未必得知實際數目)

年年重覆一次的六四再討論

關於六四的討論, 把上年的討論拿到一年後的今天, 或把今年的拿到明年, 也許你會發覺近幾年討論內容差不多。

其一原因是六四主流context在開始有人提倡轉化的幾年前後也沒有轉化過。主流意見如司徒華曰: 不需要改變。幾年的討論也就一再在同一static constant content上不斷重新retry connection, 每年都重覆一次。

香港的處境每況越下是不證自明的。
客觀事實是, 環境處境一直在變, 而六四context不變。
context不變, 可以是一種穩定處境的應對方式, 反之的隨context而變, 則是另一種處世應對方式。

我是認同要跟context變, 從而去支援處境中的苦撐抗爭, 而論點我在很多文章也提過在此從略。
而認同六四context不變的, 卻往往從大中華主義同胞中國人角度去演繹吧。

我倒希望, 那些認同”不變”的, 也多多嘗試從連結香港當下處境的角度落墨探索。
堅係do not go gentle into that good night。

確立香港人的本土六四

六四當年,是香港人有參與其中,這件事本身就有香港人立足的context。(我是四﹑五年前已經如此說…)
是以,以本土角度,甚至港獨角度,也可以用香港人身份context去面對六四這件事。

六四的context是否需要大中華主義與愛國?我覺得不是必然需要的。
六四事件本身是發生於大中華主義時期底下。
香港人其時的心理狀態,是有一半的中國人心態,亦有一半為自身香港人前途擔憂心態,很複雜糾結。
那些心理狀態其實只是一個背景,不需要照單全收。
我們可以extract香港人面對前途問題的心態那部份,作為六四的本土context。

又或者不如用另一個角度去看。
假如今天是已經香港獨立或歸英或whatever香港人自由自主處境,那香港人是否還能去紀念六四?
切割了中國人身份認同,以香港人身份認同,仍能去紀念六四,你先想像一下這種心理處境。
然後你再平心靜氣想想,我們香港人在這心理處境,是以什麼心態去紀念六四?

確立香港人身份認同,亦確立了六四的本土context,其實去記念六四什麼什麼的,也沒有問題。
只是支聯會什麼的出於其本質就一定要你硬食大中華主義,那就沒法子。
所以要本土context去切入六四,而如果你的本土是切割中國人身份﹑確立香港人身份認同;
那你其實不可能在支聯會的框架下去做到;
你就要另開新路去做。

我是支持開新路的思維的,窮則要變,不能不思變。

「平反六四」——等待中共發落

其實「平反」兩個字的確係需要釐清並反省係咪需要amend。
「平反六四」之「平反」,這口號之初實出於愛國民主運動的思維框架,有由中共重新評價六四事件之意思。

90年代,香港也只是寄望河水不犯井水,然而從沒直接冒犯中共之意,六四仍待中共發落。
回歸後,香港都仍是差不多。
無他,多年來六四Framework底下宣傳愛國民主運動思想,配合民主回歸派的民主話語權,其實群眾也被modelized成那種意識形態:六四仍待中共發落。

直至近年,才比較多人嘗試提出其他可能性:
獨立﹑歸英﹑聯邦﹑….
這些事未必直接衝擊六四事件,但其與中國人身份切割的想法,卻衝擊六四政治Framework。

最後,人們就提出一個問題,對六四問題,我們是否應去講「平反」——等待中共發落?
有些人說,那只是字眼偽命題。但實際並不單不只是字眼問題,而更是意識形態問題。
文字承載思想主義繼而化作行動,文字之表面形態可以不執著,但文字之意則不得不重視。