अपनी इमेजें वापस चाहिए? 5 डॉलर दीजिए
(lutr.dev)- पुराने अकाउंट्स साफ़ कर रहा एक यूज़र पुरानी तस्वीरों की उम्मीद में Photobucket में लॉग इन हुआ, लेकिन यादें पेवॉल के पीछे थीं
- जिस अकाउंट को वह पहले फ्री image hosting के लिए इस्तेमाल करता था, उसकी access $5 प्रति माह subscription में बदल चुकी थी, और भुगतान से पहले यह बात कि यह monthly charge है, पर्याप्त स्पष्ट नहीं थी
- भुगतान के बाद खुला अकाउंट खाली था, और यूज़र ने इस बात पर नाराज़गी जताई कि जिन अकाउंट्स में इमेजें नहीं थीं, उनसे भी पैसे मांगे गए
- अगर अपलोड की गई तस्वीरें न हों तो 48 घंटे के भीतर refund request की जा सकती है, ऐसा एक फुटनोट में लिखा था, लेकिन यूज़र को यह बाद में दिखा और वह अपने 5 डॉलर वापस नहीं ले सका
- बाद में यूज़र ने कहा कि उसे नहीं लगता कि Photobucket ने जानबूझकर इमेजें डिलीट कीं; ज़्यादा संभावना यह है कि उसने पहले कोई और, इससे भी पुराना अकाउंट इस्तेमाल किया था
पुराने Photobucket अकाउंट में मिला payment barrier
- पुरानी online accounts साफ़ करते समय यूज़र को पुरानी image hosting service Photobucket का अकाउंट फिर याद आया
- उसे Imgur अकाउंट में सैकड़ों पुराने screenshots मिले और उसने उनका backup लिया, इसलिए उसे उम्मीद थी कि Photobucket में उससे भी पुरानी यादें बची होंगी
- लॉग इन करने के बाद Photobucket ने “You shared them. We protected them.” संदेश के साथ एक स्क्रीन दिखाई, जिसमें पुराने images देखने के लिए भुगतान मांगा गया
- शुरुआत में यह “just $5” जैसा लगा, लेकिन असल में यह $5 प्रति माह subscription था
- यूज़र का मानना था कि यह flow यूज़र की जिज्ञासा का फायदा उठाकर subscription दिलाने के लिए बनाया गया है
- आखिरकार उसने कार्ड जानकारी डाली और
Pay by Cardदबाकर भुगतान कर दिया - भुगतान के बाद “Start filling your bucket” स्क्रीन खुली, और अकाउंट में कोई इमेज नहीं थी
- यूज़र को लगा कि संभव है बचपन में उसने कोई दूसरा, इससे भी पुराना Photobucket अकाउंट इस्तेमाल किया हो
- साथ ही उसने Photobucket की आलोचना की कि उसे यह पता हो सकता था कि अकाउंट में इमेजें नहीं हैं, फिर भी उसने भुगतान लिया
refund फुटनोट और पोस्ट वायरल होने के बाद की प्रतिक्रिया
- भुगतान पेज पर एक फुटनोट था, जिसमें लिखा था कि अगर अपलोड की गई तस्वीरें नहीं हैं तो 48 घंटे के भीतर refund request की जा सकती है
- यूज़र ने पोस्ट लिखते समय इस फुटनोट को देर से देखा, इसलिए वह समय पर refund नहीं मांग सका और उसके 5 डॉलर चले गए
- Hacker News पर पोस्ट के ध्यान खींचने के बाद, यूज़र ने दो और बातें स्पष्ट कीं
- उसे नहीं लगता कि Photobucket ने उससे नफ़रत के कारण उसकी अपलोड की गई सारी इमेजें जानबूझकर मिटा दीं और फिर $5 प्रति माह मांगे
- उसका मानना है कि जिन इमेजों वाला अकाउंट था, वह अभी लॉग इन किए गए अकाउंट से अलग और उससे भी पुराना अकाउंट होने की अधिक संभावना है
- पाठकों ने उसे कार्ड chargeback आज़माने की सलाह दी, और यूज़र को तब पता चला कि debit card पर भी chargeback संभव हो सकता है
- पोस्ट के Hacker News पर लोकप्रिय होते ही उसके personal blog को host कर रहे Vercel की
Edge Requestsसीमा लगभग 2 घंटे में छूने वाली थी- यूज़र ने कहा कि समय मिला तो वह इसे Cloudflare Pages जैसी किसी service पर migrate कर सकता है
1 टिप्पणियां
Hacker News की राय
पुराने तरीके से करना हो तो कुछ ऐसा होता: “मेरे पास 1984 में मिला एक email copy है, क्या उसे recover किया जा सकता है?” और जवाब मिलता, “अगर आप $500 non-refundable, और लागत असीमित रूप से बढ़ सकती है फीस दें, तो हम पहले यह assess करेंगे कि media को पढ़ा भी जा सकता है या नहीं”
यादों की कितनी कीमत लगाई जाए, यह अपने आप में अच्छा सवाल है
ऐसी कंपनियाँ कंपनियों के मिलियन-डॉलर risk recover करने के लिए होती हैं, और उसी market के हिसाब से अपना समय और equipment pricing तय करती हैं, baby boomer nostalgia trip के लिए नहीं
मुझे भी Photobucket account delete होने वाला है, ऐसा email मिला था, तो कई साल बाद login किया। वहाँ भी subscription के लिए कहा गया, लेकिन account deletion process में जाने पर पहले पूरे data download का option मिला
उससे मैंने अपनी images वापस ले लीं और account बंद कर दिया; असल में subscription लेने की ज़रूरत नहीं पड़ी
कुछ इस अंदाज़ में, “इसीलिए हम सस्ती subscription fee दे पाए…”
उन emails के आने के समय तक भी login करके photos download की जा सकती थीं, और मैंने भी ऐसा ही किया
कुल मिलाकर वे काफ़ी transparent थे, इसलिए author ने वे emails miss कर दिए, इसे Photobucket की गलती कहना मुश्किल है
हाँ, लेकिन जिस account को वापस पाना है उसका preview न देना साफ़ तौर पर अच्छा user experience नहीं है, और उस हिस्से का बचाव करना मुश्किल है
account में कुछ भी नहीं है, इसलिए अच्छा होता अगर वे बस उसे delete कर देते, लेकिन असल में यह बस खुल्लमखुल्ला scammy nudge जैसा लगता है
लेकिन एक साथ सब कुछ download करने का अच्छा तरीका नहीं मिला, इसलिए टालता रहा
दिलचस्प बात यह है कि download request करने के बाद account delete करना ज़रूरी नहीं है, इसलिए मैं जानबूझकर उसे ऐसे ही छोड़ने वाला हूँ
करीब 2007 में Gaiaonline पर बनाए गए लगभग 600 शर्मनाक avatar edits, कुल 81MB उनकी server space घेरते रहेंगे, इस उम्मीद में कि किसी दिन मैं उन्हें $5 फेंक दूँ
समझ नहीं आता कि इसे सिर्फ corporate greed का मामला क्यों माना जा रहा है। photos preserve नहीं हुईं, और इस हिस्से पर लेख की शिकायत वाजिब है
Photobucket monetization में पूरी तरह fail हो गया, Fox को बेचा गया, और फिर Ontela नाम के एक अनजान startup के पास चला गया (https://en.wikipedia.org/wiki/Photobucket)
service पूरी तरह बंद भी हो सकती थी और hard drives crusher में जा सकती थीं, लेकिन शायद किसी ex-private-equity टाइप operator ने हिसाब लगाकर देखा कि preservation से भी पैसा बनाया जा सकता है
अगर यह ठीक से काम करे—या कम से कम ऐसे images अब भी देखी जा सकें जिनके monthly views का median 0 है—तो जबकि बाकी internet link rot से गायब हो रहा है, यह सबके लिए win-win जैसा दिखता है
Photobucket को यह बात पहले से पता रही होगी, इसलिए यह काफ़ी deceptive है और refund माँगना बनता है
business model था “free storage दो और ads से पैसा कमाओ”, और 2007 में Fox ने इसे $300 million में acquire किया था
Ontela pre-iPhone era की photo upload app provider थी, और MySpace की असफलता के बाद Fox ने Photobucket को spin off करने का फ़ैसला किया, तब दोनों कंपनियाँ merge हुईं
बहुत मुमकिन है कि वह acquisition के समय वाली original infrastructure पर चल रही हो, end-of-support dependencies से भरी हो, और acquisition से पहले भी security ठीक न रही हो
regulatory requirements में हुए बदलाव भी शायद ignore किए जाते हों, और terms of service में “हम commercially standard तरीकों से security बनाए रखते हैं” जैसे झूठ भरे हों
ऐसे zombie sites को online बनाए रखना win-win नहीं है
कम से कम मेरा data अब भी वहाँ था
अगर उन्होंने साफ़ लिखा था कि “आपने share किया। हमने सुरक्षित रखा।” यानी मेरी photos मौजूद हैं, तो यह card chargeback वाला मामला लगता है
फिर भी ठीक है। अगर वे $5 लौटा भी दें तो मेरे मन में Photobucket थोड़ा कम बुरा लगेगा, और मैं ऐसा नहीं चाहता
ऐसी हरकत करने वाली कंपनी को वास्तव में सज़ा देने के लगभग यही इकलौता तरीका है
पिछले 1 साल में मैंने eBay पर तीन बार counterfeit या defective सामान खरीदा, और सबूत होने पर भी eBay की guarantee पूरी तरह बेकार निकली; बैंक से chargeback लेना दाँत खिंचवाने जैसा था
एक मामले में तो उन्होंने सीधा मना ही कर दिया था
“अपना personal blog Vercel पर host करना हमेशा सबसे अच्छा विकल्प नहीं हो सकता। पोस्ट करने के 2 घंटे के भीतर ही Edge Requests limit लगभग छू गई” — यह हिस्सा खास लगा।
मैं हमेशा सोचता था कि incident response software engineering के सबसे कम आकर्षक कामों में से एक है, लेकिन कई developer blogs ऐसे तरीके से बनाए जाते हैं जिनमें downtime लगभग तय होता है।
कोई बहुत खास वजह न हो तो static site generator से काम बहुत अच्छे से चल जाता है।
उसके बाद GitHub Pages, AWS free tier जैसी कई third-party services भी हैं जहाँ इसे मुफ्त में दिखाया जा सकता है।
अहम बात यह है कि files मेरे अपने computer पर रहती हैं, उन्हें जितनी बार चाहूँ repository में replicate कर सकता हूँ, और कोई भी third-party service उन files को बंधक नहीं बना सकती।
खुद चलाए जाने वाले blog के लिए यह इतना सही तरीका है कि इसे best practice कहा जा सकता है, और लेख में बताई गई तरह की समस्या मुझे उसी practice का पालन न करने का सीधा नतीजा लगती है।
अगर Google Photos app में जैसे मेरी photos हैं, वैसे ही उन्हें एक बार में export कर दे, तो मैं खुशी-खुशी 5 डॉलर दे दूँगा।
अभी वह मुफ्त में Takeout देता है, लेकिन photos सैकड़ों zip files के अंदर तारीख़ के हिसाब से गहरे subfolders में बिखरी होती हैं।
इतना तो मैं सह सकता हूँ, लेकिन समस्या यह है कि वह processing और deduplication को उलट देता है, जिससे एक ही file की 20 copies random जगहों पर बिखर जाती हैं।
इससे भी बुरा यह है कि अगर आप एक साथ दो से ज़्यादा zip files download करने की कोशिश करें, तो error आता है, नया Takeout request शुरू करवाता है, और फिर दोबारा download उपलब्ध होने वाला email आने तक 24 घंटे इंतज़ार करना पड़ता है।
मैंने तो बस मान लिया है कि वहाँ के product manager का जीवन लक्ष्य सिर्फ लोगों को Google Photos छोड़ने से रोकना है।
अभी मैं Google Photos search feature से एक बार में 100 photos दिखाता हूँ, उन्हें zip में download करता हूँ, फिर selection बने रहने पर उन्हीं 100 को delete कर देता हूँ — इस तरह थोड़ा-थोड़ा करके कम कर रहा हूँ।
इससे Takeout वाले हंगामे के उलट चीजें कुछ हद तक व्यवस्थित रहती हैं और deduplication भी बनी रहती है।
यह वास्तव में कहाँ तक चीजें संभालता है, या Immich में migrate किए बिना भी आसानी से इस्तेमाल हो सकता है या नहीं, यह मुझे नहीं पता, लेकिन यही tool दिमाग में आया।
मैं Immich का नया user हूँ और Google Photos कभी इस्तेमाल नहीं किया।
मैंने select all करके download किया, Google Photos ने दावा किया कि सब कुछ archive कर दिया गया है, लेकिन असली zip में बहुत सारी files गायब थीं।
Photobucket का नाम सुनकर मैं यह देखने गया कि वहाँ मैंने क्या-क्या रखा था।
पुराने emails खंगालकर यह पता लगाया कि कौन-सा address इस्तेमाल किया था, फिर login करने की कोशिश की, लेकिन password याद नहीं था, तो reset link पुराने Hotmail पर भेजा।
Hotmail ने device को नहीं पहचाना क्योंकि उस पर 10 साल से login नहीं किया था, और उसने शायद पहचान सत्यापन के लिए पहले कभी बनाए गए hotmailspam@my-domain.com पर email भेजकर कई verification codes भरवाए।
Hotmail में login करके Photobucket password reset link दबाया, नया password बनाया और उसे password vault में रख दिया।
नतीजा यह निकला: “Failed to reset password Firebase: Error (auth/the-service-is-currently-unavailable.).”
बिल्कुल परफेक्ट। अब कहने को कुछ नहीं है।
अगर card payment reversal का कोई सही उपयोग मामला है, तो यही वह मामला है।
support team से कहो कि अगर refund नहीं दिया गया तो आप chargeback के लिए आवेदन करेंगे, और अगर वे मना करें तो सच में आवेदन कर दो।
अगर वे refund से मना करें या अनदेखा करें, तो सीधे chargeback file कर देना चाहिए।
आदर्श रूप से customer support refund की तुलना में chargeback पर मामला खत्म होना बेहतर है।
तभी बदलने की प्रेरणा बनती है, और ऊँचा chargeback rate वही प्रेरणा बन सकता है।
लेकिन credit card company आम तौर पर उम्मीद करती है कि आप पहले merchant के साथ मामला सुलझाने की कोशिश करें, इसलिए “मौका देने” के लिए customer support से पहले संपर्क करना ठीक है।
Flickr की तारीफ़ बनती है। आपने चाहे जितने gigabytes upload किए हों, वे अब भी accessible रहते हैं; बस Flickr Pro plan न होने पर आप आगे upload नहीं कर सकते।
20 साल से ज़्यादा Flickr Pro इस्तेमाल करने के बाद मैंने payment बंद कर दी, और free plan limit के नीचे आने के लिए photos को सिर्फ 1024px resolution में ही bulk download किया जा सकता है।
नहीं तो सालाना 82 डॉलर वाला Flickr Pro देना पड़ेगा।
मेरी photos तब तक बंधक हैं जब तक मैं पैसे न दूँ।
photos delete नहीं हुई थीं, लेकिन access मुमकिन नहीं था।
यहाँ तकनीकी पाठक ज़्यादा हैं, इसलिए यह बताने का एक तरह का दायित्व महसूस होता है कि Immich कितना अच्छा है, और यह मुफ़्त open source भी है
यह मेरे जैसे उन लोगों के लिए भी ठीक है जो “ज़िंदगी भर admin” नहीं बने रहना चाहते
10 साल से ज़्यादा समय से मेरे लिए जो तरीका अच्छी तरह काम कर रहा है, वह यह है कि फोटो की मूल फ़ाइलें साधारण फ़ोल्डरों में रखो, उनका बैकअप Synology और Dropbox में रखो, और उसके ऊपर फोटो देखने/शेयर करने वाला ऐप जोड़ दो
अगर Immich से ऊब जाऊँ या कोई बेहतर विकल्प आ जाए, तो बदल सकता हूँ
मैंने इसे सेटअप करते हुए यह भी लिखा है कि यह कैसे काम करता है, पढ़कर अपनी ज़रूरत के हिसाब से बदलने की सलाह दूँगा
https://jaisenmathai.com/articles/my-ridiculously-robust-pho...
https://medium.com/vantage/understanding-my-need-for-an-auto...
यह Google Photos ऐप जितना अच्छा है, लेकिन डेटा आपका अपना रहता है, और ज़रूरत पड़े तो स्टोरेज भी कम कीमत में बढ़ाया जा सकता है
अपने पुराने Photobucket अकाउंट में मैं बचपन में बनाए गए screenshots ढूँढना चाहता था
शुक्र है कि मैंने असली फोटो वहाँ स्टोर नहीं किए थे
वह अपने समय से आगे की चीज़ थी, और यह देखकर अच्छा लगा कि आप अब भी photo sharing space में काम कर रहे हैं
use case के हिसाब से setup काफ़ी पेचीदा हो सकता है
मुझे Windows के लिए Docker Desktop पसंद नहीं है, इसलिए मैं इसे Windows Subsystem for Linux के Docker container में Tailscale के साथ चलाता हूँ, और ऐसा सेट किया है कि PC चालू होते ही यह अपने आप initialize हो जाए
इसे चलाने लायक बनाने में कई घंटे और GPT के साथ बहुत सारी बातचीत लगी, हालाँकि संभव है कि मेरा setup आम न हो
सबसे बड़ी समस्या overhead और smart settings की कमी है
उदाहरण के लिए, मेरी पत्नी और मैं एक ही Android device इस्तेमाल करते हैं, लेकिन backup default Android image folder structure की नकल करता है, और दोनों devices की संरचना एक जैसी होने से एक ही अकाउंट शेयर करते हुए दोनों का एक साथ backup नहीं हो सकता
अगर अकाउंट दो हिस्सों में बाँटें, तो हर अकाउंट अपने thumbnails अलग बनाएगा और face recognition भी अलग चलानी पड़ेगी, जिससे manual tagging समेत समय और space दोनों की काफ़ी बर्बादी होती है
दूसरी समस्या यह है कि external folders में जो file system structure और organization पहले से है, उसे सीधे इस्तेमाल नहीं किया जा सकता; Immich के अंदर उसे albums के रूप में फिर से बनाना पड़ता है
इसके लिए script तो मिली है, लेकिन अनुभव अभी अधूरा है
तीसरी बात, सीधे external folder में backup नहीं किया जा सकता
backup पहले default Immich folder में जाता है, फिर मुझे उसे निकालकर अपनी structure के मुताबिक सही external folder में खुद रखना पड़ता है
GitHub पर देखा तो अच्छा लगा कि इन issues की reports पहले से हैं, मैंने सबको upvote भी किया, लेकिन पता नहीं वे अभी तक हल हुए हैं या नहीं
Dropbox जैसी कोई चीज़ जोड़ना मेरे लिए विकल्प नहीं है, और ऐसी functionality के लिए और ज़्यादा system resources खर्च करना भी बड़ी कमी है
Synology पर बहुत पैसा खर्च नहीं करना चाहता, इसलिए सस्ता DAS इस्तेमाल कर रहा हूँ, और offsite manual backup भी रखता हूँ
मेरा मानना है कि कई failure points वाले जटिल system के बिना Immich को यह काम खुद संभालना चाहिए
settings देखने पर backup के बाद space खाली करने का option तो था, लेकिन वह मैंने चालू नहीं किया था
यह कोई बहुत बड़ी तबाही नहीं थी, लेकिन कुछ messaging apps उन तस्वीरों को देख नहीं पातीं और उन्हें corrupted मानती हैं