修改 booking.com 的 dark pattern

Hacker News Daily 上看到修改 booking.comdark pattern 的套件:「De-Stressing Booking.com (alexcharlton.co)」,原文連結到「De-stressing Booking.com」,這是 2019 的文章,在介紹他寫的套件。

裡面講的是像這樣的東西:

這個例子裡面是故意用有壓力的顏色 (這邊是紅色) 去推動使用者趕快下單,算是蠻經典的 dark pattern,作者有舉個 Airbnb 的類似例子,比較起來就好很多:

在 comment 也有人提到其他種類的 dark pattern,故意把一些飯店標成已經售出,製造你不趕快訂就會釘不到的假象。不過下面有人提到,在有些法律制度比較完整的國家裡面,這會牽扯到不實宣傳之類的行為:

After browsing hotels for some time I've seen booking.com show several hotels start to sell out of rooms. That usually causes me to hurry up and book, but after several hotels showed full at once I got suspicious and checked my partners phone. The hotels still showed as available there. Dark stuff. Their website is otherwise pretty good though and I still use them.

在「Online hotel booking」這邊有英國對這些線上訂房網站的調查與裁罰。

然後在 Hacker News 上的 comment 有看到一個有趣的方法,是 PresidentObama 提到的方法 (這 id XDDD),用 uBlock Origin 來擋:

From the last time booking.com was discussed I picked up some ublock origin filters that make the website more bearable.

You can copy and paste them directly in your ublock config (ublock options -> My filters)

  ! https://news.ycombinator.com/item?id=21860328
  booking.com##.soldout_property
  booking.com##.sr_rooms_left_wrap.only_x_left
  booking.com##.lastbooking
  booking.com##.sr--x-times-booked
  booking.com##.in-high-demand-not-scarce
  booking.com##.top_scarcity
  booking.com##.hp-rt-just-booked
  booking.com##.cheapest_banner_content > *
  booking.com##.hp-social_proof
  booking.com##.fe_banner__red.fe_banner__w-icon.fe_banner__scale_small.fe_banner
  booking.com##.urgency_message_x_people.urgency_message_red
  booking.com##.rackrate
  booking.com##.urgency_message_red.altHotels_most_recent_booking
  booking.com##.fe_banner__w-icon-large.fe_banner__w-icon.fe_banner
  booking.com##.smaller-low-av-msg_wrapper
  booking.com##.small_warning.wxp-sr-banner.js-wxp-sr-banner
  booking.com##.lock-price-banner--no-button.lock-price-banner.bui-u-bleed\@small.bui-alert--large.bui-alert--success.bui-alert

另外還有擋一些追蹤的 url parameter:

Apart from these, I use some additional ublock filters to block some of their tracking that I am not ok with.

$removeparam=/^(error_url|ac_suggestion_theme_list_length|ac_suggestion_list_length|search_pageview_id|ac_click_type|ac_langcode|ac_position|ss_raw|from_sf|is_ski_area|src|sb_lp|sb|search_selected|srpvid|click_from_logo|ss|ssne|ssne_untouched|b_h4u_keep_filters|aid|label|all_sr_blocks|highlighted_blocks|ucfs|arphpl|hpos|hapos|matching_block_id|from|tpi_r|sr_order|srepoch|sr_pri_blocks|atlas_src|place_types)/,domain=booking.com
  $removeparam=/sid=.\*;BBOX/,domain=booking.com
  ||www.booking.com/c360/v1/track
  ||www.booking.com/fl/exposed
  ||booking.com/personalisationinfra/track_behaviour_property
  ||booking.com/has_seen_review_list

不過好像很少用 booking.com 了...

在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決:「MySQL High Availability: Stale Reads and How to Fix Them」,另外在留言也有人提到 Booking.com 的解法:「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下,最簡單的擴充方式是架設 slave server,然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split),但因為 MySQL 的 replication 是非同步的,所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料,也就是 replication lag。

這就大概有幾種作法,一種是當發現 lag 時就回 master 讀,但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看,但這個方法就不保證讀的到東西,因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境,預設還是 R/W split,但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性,在寫入時多寫一份資料,然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法,其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊,然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法,不知道各家 framework 對這些方式的支援度如何...