<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://berthub.eu/articles/posts/do-not-invite-big-tech-to-your-digital-autonomy-discussion/"/>
	<rdf:li rdf:resource="https://the-decoder.com/landmark-german-ruling-declares-googles-ai-overviews-are-googles-own-words-and-makes-it-liable-for-false-answers/"/>
	<rdf:li rdf:resource="https://point.free/blog/gemma-4-on-a-2016-xeon/"/>
	<rdf:li rdf:resource="https://webmatrices.com/post/how-a-roblox-cheat-and-one-ai-tool-brought-down-vercel-s-entire-platform"/>
	<rdf:li rdf:resource="https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules"/>
	<rdf:li rdf:resource="https://trysound.io/how-my-side-project-got-banned-from-the-internet/"/>
	<rdf:li rdf:resource="https://github.com/ScottESanDiego/gmail-api-client"/>
	<rdf:li rdf:resource="https://www.thebriefing.ie/google-just-erased-7-years-of-our-political-history/"/>
	<rdf:li rdf:resource="https://removepaywalls.com/https://www.nationalobserver.com/2025/09/04/investigations/google-net-zero-sustainability"/>
	<rdf:li rdf:resource="https://www.theregister.com/2025/08/27/ovhcloud_interview/?ck_subscriber_id=512829374#438:%20Amazon%20Q%20Rules%20Except%20It%20Doesn't%20At%20All%20-%2018837614"/>
	<rdf:li rdf:resource="https://ketanjoshi.co/2025/08/23/big-techs-selective-disclosure-masks-ais-real-climate-impact/"/>
	<rdf:li rdf:resource="https://archive.ph/SExCe#selection-1813.0-1829.282"/>
	<rdf:li rdf:resource="https://easydmarc.com/blog/google-spoofed-via-dkim-replay-attack-a-technical-breakdown/"/>
	<rdf:li rdf:resource="https://pluralistic.net/2025/07/15/inhuman-gigapede/"/>
	<rdf:li rdf:resource="https://cloud.google.com/bigquery/docs/automatic-discovery"/>
	<rdf:li rdf:resource="https://cloud.google.com/storage/docs/best-practices"/>
	<rdf:li rdf:resource="https://mastodon.social/@BenRossTransit/113741945325663404"/>
	<rdf:li rdf:resource="https://deepmind.google/discover/blog/gencast-predicts-weather-and-the-risks-of-extreme-conditions-with-sota-accuracy/"/>
	<rdf:li rdf:resource="https://github.com/rspeer/wordfreq/blob/master/SUNSET.md"/>
	<rdf:li rdf:resource="https://disconnect.blog/generative-ai-is-a-climate-disaster/"/>
	<rdf:li rdf:resource="https://www.theverge.com/2024/6/11/24176490/mm-delicious-glue"/>
	<rdf:li rdf:resource="https://gist.github.com/velzie/053ffedeaecea1a801a2769ab86ab376"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/2405.14975"/>
	<rdf:li rdf:resource="https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident"/>
	<rdf:li rdf:resource="https://arstechnica.com/gadgets/2024/05/google-cloud-accidentally-nukes-customer-account-causes-two-weeks-of-downtime/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=40304666"/>
	<rdf:li rdf:resource="https://www.nytimes.com/2024/04/06/technology/tech-giants-harvest-data-artificial-intelligence.html"/>
	<rdf:li rdf:resource="https://housefresh.com/david-vs-digital-goliaths/"/>
	<rdf:li rdf:resource="https://www.iccl.ie/digital-data/europes-hidden-security-crisis/"/>
	<rdf:li rdf:resource="https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/"/>
	<rdf:li rdf:resource="https://blog.zgp.org/google-chrome-checklist/"/>
	<rdf:li rdf:resource="https://ericdraken.com/pfsense-decrypt-ad-traffic/"/>
	<rdf:li rdf:resource="https://gizmodo.com/google-says-itll-scrape-everything-you-post-online-for-1850601486"/>
	<rdf:li rdf:resource="https://sites.google.com/view/nuitattack/home"/>
	<rdf:li rdf:resource="https://sea.mashable.com/tech/23295/google-launched-bard-despite-major-ethical-concerns-from-its-employees"/>
	<rdf:li rdf:resource="https://archive.is/L49pO#selection-1915.0-1923.256"/>
	<rdf:li rdf:resource="https://www.theverge.com/2023/3/22/23651564/google-microsoft-bard-bing-chatbots-misinformation"/>
	<rdf:li rdf:resource="https://downrightnifty.me/blog/2022/12/26/hacking-google-home.html"/>
	<rdf:li rdf:resource="https://www.boards.ie/discussion/comment/119595524/#Comment_119595524"/>
	<rdf:li rdf:resource="https://www.etsy.com/codeascraft/cloud-jewels-estimating-kwh-in-the-cloud"/>
	<rdf:li rdf:resource="https://twitter.com/lizthegrey/status/1582593768280461313"/>
	<rdf:li rdf:resource="https://twitter.com/buccocapital/status/1576909546164928513/photo/1"/>
	<rdf:li rdf:resource="https://9to5google.com/2022/09/25/google-photos-corrupted/"/>
	<rdf:li rdf:resource="https://www.lastweekinaws.com/blog/How-Google-Cloud-and-AWS-Approach-Customer-Carbon-Emissions/?ck_subscriber_id=512829374"/>
	<rdf:li rdf:resource="https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency"/>
	<rdf:li rdf:resource="https://www.fastcompany.com/3037803/the-oral-history-of-the-poop-emoji-or-how-google-brought-poop-to-america"/>
	<rdf:li rdf:resource="https://fonts.google.com/noto/specimen/Noto+Emoji"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/GooglePixel/comments/nb314o/4a_doesnt_connect_to_lte_after_leaving_wifi/"/>
	<rdf:li rdf:resource="https://twitter.com/kantrn/status/1511791378497384454"/>
	<rdf:li rdf:resource="https://twitter.com/hiddenmarkov/status/1497351111656751109"/>
	<rdf:li rdf:resource="https://twitter.com/emilyldolson/status/1485434187968614411"/>
	<rdf:li rdf:resource="https://status.cloud.google.com/incidents/6PM5mNd43NbMqjCZ5REh"/>
	<rdf:li rdf:resource="https://restofworld.org/2021/refugees-machine-learning-big-tech/"/>
	<rdf:li rdf:resource="https://twitter.com/GergelyOrosz/status/1442162670753431559?s=20"/>
	<rdf:li rdf:resource="https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc"/>
	<rdf:li rdf:resource="https://docs.google.com/document/d/1Lu7XPRKlNhBQjcKr8k8qRzUzbBW7kzxb5Vu72GMRn2E/edit"/>
	<rdf:li rdf:resource="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf"/>
	<rdf:li rdf:resource="https://github.com/google/fully-homomorphic-encryption"/>
	<rdf:li rdf:resource="https://www.technologyreview.com/2020/04/27/1000658/google-medical-ai-accurate-lab-real-life-clinic-covid-diabetes-retina-disease/?truid=8c8f2699f50eb3b9985a111121cfee47"/>
	<rdf:li rdf:resource="https://blog.google/inside-google/infrastructure/data-centers-work-harder-sun-shines-wind-blows"/>
	<rdf:li rdf:resource="https://james.darpinian.com/satellites/?special=starlink"/>
	<rdf:li rdf:resource="https://blog.container-solutions.com/the-green-cloud-how-climate-friendly-is-your-cloud-provider"/>
	<rdf:li rdf:resource="https://www.eventbrite.com/e/you-cant-say-that-policing-the-long-tail-of-public-opinion-on-facebook-tickets-92904081609"/>
	<rdf:li rdf:resource="https://www.theverge.com/2020/1/27/21080253/ai-cancer-diagnosis-dangers-mammography-google-paper-accuracy"/>
	<rdf:li rdf:resource="https://cloudonaut.io/how-to-secure-your-devops-tools-with-alb-authentication/?ck_subscriber_id=512829374"/>
	<rdf:li rdf:resource="https://pair.withgoogle.com/"/>
	<rdf:li rdf:resource="https://ai.googleblog.com/2019/03/an-all-neural-on-device-speech.html"/>
	<rdf:li rdf:resource="https://alexolivier.me/posts/deploy-container-stateless-cheap-google-cloud-run-serverless"/>
	<rdf:li rdf:resource="https://twitter.com/AricToler/status/1206679612543111169"/>
	<rdf:li rdf:resource="https://blog.acolyer.org/2019/09/23/the-secret-sharer/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://berthub.eu/articles/posts/do-not-invite-big-tech-to-your-digital-autonomy-discussion/">
    <title>Do not invite big-tech to join your digital autonomy discussion</title>
    <dc:date>2026-06-18T09:36:04+00:00</dc:date>
    <link>https://berthub.eu/articles/posts/do-not-invite-big-tech-to-your-digital-autonomy-discussion/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bert Hubert:

<blockquote>If we want to discuss how to improve our digital autonomy, employees from US big tech will not usefully contribute to the conversation. They can’t.  And in fact, they’ll likely actively prevent progress by restating old talking points, like how (despite tons of legal analysis to the contrary) Microsoft is somehow able to shield us from the vagaries of the US administration.

I recall Microsoft vice-president Brad Smith explaining how Microsoft would go to court to protect European rights and within a week, Microsoft told the International Criminal Court that it had to remove several employees from Microsoft services, because of US sanctions.

Microsoft pointedly did not go to court to defend the ICC.

If you invite US big tech to your event, you’ll spend some of your time listening to fairy tales. And if you are lucky someone is present to debunk these stories. But still, if Amazon just got 10 minutes of speaking time to talk about their supposedly sovereign cloud, and then someone else says it is not true, the meeting is still left with the impression that it could be true. The issue has successfully been “both-sidesed”. Also, you lost 15 minutes of your day.</blockquote>

]]></description>
<dc:subject>amazon microsoft google big-tech digital-sovereignty us-politics europe eu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0baf6f3dc2b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-tech"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:digital-sovereignty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:us-politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:europe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://the-decoder.com/landmark-german-ruling-declares-googles-ai-overviews-are-googles-own-words-and-makes-it-liable-for-false-answers/">
    <title>Landmark German ruling declares Google's AI Overviews are Google's own words and makes it liable for false answers</title>
    <dc:date>2026-06-10T11:52:03+00:00</dc:date>
    <link>https://the-decoder.com/landmark-german-ruling-declares-googles-ai-overviews-are-googles-own-words-and-makes-it-liable-for-false-answers/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a major liability judgement against Google's use of AI:

"A German regional court has ruled that Google is directly liable for false claims in its AI-generated search overviews. In this case, Google's AI had wrongly linked two publishers to scams and shady business practices. The court treated the AI overviews as Google's own content and rejected Google's argument that users were responsible for fact-checking the results themselves."

A mastodon-based reviewer summarises:

<blockquote>
The judge is explicitly cutting down most of the legal defenses they use. They make a sharp cut between search and AI, saying search is indispensable, but AI is not, and defendants have not proven how being held liable for their output would compromise the ability to run a normal search engine. They make a similar hard cut between AI and autocomplete.

They go on at length about the nature of truth in utterances, and arrive at a conclusion that AI output has no protections for free expression because it isn't expressing shit - it has no beliefs, it is a commercial product only. There are two injunctions that are denied because they are not considered statements of fact, but the judge rules against google for all the ones that were, and concludes several are default considered false because the linked pages were irrelevant.

There is explicit differentiation from aggregating reviews and third party content, because the AI generated text and ideas that were not present in the input. There is also discussion about how there is no excuse for further violations just because its hard to control AI output, and contrasts this with how normal "report and takedown" protections work.

There is very little here that is specific to AI overviews in search, and almost all of the arguments apply to AI products in general. AI's only prayer of being remotely profitable must include advertising or shopping features, which means they absolutely must continue generating output that makes statements of fact about other companies. I know nothing about how German courts work, the article alludes to appeals, but if this ruling holds even just in Germany the ability to insure AI products disappears overnight and that makes the product nonviable.
</blockquote>]]></description>
<dc:subject>germany eu liability google ai-overviews slop law truth libel facts insurance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:25401dacd469/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:germany"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:liability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai-overviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:truth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:insurance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://point.free/blog/gemma-4-on-a-2016-xeon/">
    <title>A 10 year old Xeon is all you need - point.free</title>
    <dc:date>2026-06-02T10:50:59+00:00</dc:date>
    <link>https://point.free/blog/gemma-4-on-a-2016-xeon/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some mad scientist optimization to get Gemma 4 running on an old Xeon with no GPU]]></description>
<dc:subject>google ai llms gemma gemma-4 xeon hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5cee2e7c443f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gemma"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gemma-4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xeon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://webmatrices.com/post/how-a-roblox-cheat-and-one-ai-tool-brought-down-vercel-s-entire-platform">
    <title>how a roblox cheat and one AI tool brought down vercel's entire platform</title>
    <dc:date>2026-04-21T09:13:59+00:00</dc:date>
    <link>https://webmatrices.com/post/how-a-roblox-cheat-and-one-ai-tool-brought-down-vercel-s-entire-platform</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Damn, this is an absolute indictment of the state of security in AI tooling:

<blockquote>February 2026. An employee at Context.ai, one of those AI productivity tools that promises to "supercharge your workflow," downloads a Roblox cheat. Not a sophisticated zero-day. Not a state-sponsored attack. A Roblox cheat. The download contains Lumma Stealer, an infostealer that grabs session cookies, credentials, everything. That employee had access to sensitive internal systems.

March 2026. The attacker uses Context.ai's compromised infrastructure to pivot into a Vercel employee's Google Workspace account. This Vercel employee had signed up for Context.ai's "AI Office Suite" using their enterprise credentials and granted "Allow All" permissions. Let that sink in for a second. A Vercel engineer gave a third-party AI tool full access to their corporate Google account.

April 19. Guillermo Rauch posts the thread confirming everything. Environment variables [...] were stored in plaintext. Accessed. Exfiltrated.</blockquote>

tl;dr:

1. Context.ai employees should not be using company devices to access Roblox cheats;

2. exfiltratable environment variables should not be usable to access a customer's Google account. The scope of these credentials was obviously way too broad.

This isn't just a Context.ai issue, this is systemic.]]></description>
<dc:subject>security infosec credentials google context.ai roblox fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fcdc0ef294b3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:credentials"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:context.ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roblox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules">
    <title>Google API Keys Weren't Secrets. But then Gemini Changed the Rules</title>
    <dc:date>2026-02-26T10:27:21+00:00</dc:date>
    <link>https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Crikey, this is a massive security fail by Google:

<blockquote>Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.</blockquote>

(via Rob Synnott)]]></description>
<dc:subject>infosec api-keys authentication authorization google gemini google-maps fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c248a687a9ab/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api-keys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:authentication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:authorization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gemini"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-maps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://trysound.io/how-my-side-project-got-banned-from-the-internet/">
    <title>302 HTTP redirects Considered Harmful</title>
    <dc:date>2026-02-26T09:46:28+00:00</dc:date>
    <link>https://trysound.io/how-my-side-project-got-banned-from-the-internet/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The state of anti-phishing infrastructure nowadays is shocking.  This trivial action, combined with a relatively fresh domain, results in immediate blocklisting by Google:

<blockquote>Digging through Google forums, I found the most reported culprit: 302 temporary redirects. I used one redirect (engramma.dev → app.engramma.dev) to avoid building a landing page. In addition to a newly registered domain, this looks like an obvious issue. Security systems flag such redirects because malicious actors use them extensively.</blockquote>

It doesn't matter that "malicious actors use them extensively" if non-malicious actors do too.  That's the definition of a false positive!

Then the next shitfest is from no less than 10 separate vendors copying the listing from Google and not including an automated system to pick up the list removal afterwards.

I've had experience of this part -- and now that I think of it, it may have been from use of 302 redirects in my case too.

(via Paul Watson)]]></description>
<dc:subject>http security infosec blocklists google phishing redirects 302 false-positives fail via:paulwatson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:79ec6c8e8842/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocklists"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redirects"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:302"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:false-positives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:paulwatson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ScottESanDiego/gmail-api-client">
    <title>ScottESanDiego/gmail-api-client</title>
    <dc:date>2026-01-20T10:13:55+00:00</dc:date>
    <link>https://github.com/ScottESanDiego/gmail-api-client</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Deliver email messages directly into GMail using their proprietary API, instead of SMTP or IMAP. Looks like it still applies spam filtering, but this can also be disabled with a switch (via JWZ)]]></description>
<dc:subject>via:jwz email smtp gmail google mail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5f7fc55e2248/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jwz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smtp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gmail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.thebriefing.ie/google-just-erased-7-years-of-our-political-history/">
    <title>Google just erased 7 years of our political history</title>
    <dc:date>2025-09-29T10:05:24+00:00</dc:date>
    <link>https://www.thebriefing.ie/google-just-erased-7-years-of-our-political-history/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Google appears to have deleted its political ad archive for the EU; so the last 7 years of ads, of political spending, of messaging, of targeting - on YouTube, on Search and for display ads - for countless elections across 27 countries - is all gone.

We had been told that Google would try to stop people placing political ads, a "ban" that was to come into effect this week. I did not read anywhere that this would mean the erasure of this archive of our political history."]]></description>
<dc:subject>google advertising ads politics ireland eu europe youtube elections history</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7fb87f1a868b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:advertising"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:europe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:youtube"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://removepaywalls.com/https://www.nationalobserver.com/2025/09/04/investigations/google-net-zero-sustainability">
    <title>Google quietly demotes its net zero pledge</title>
    <dc:date>2025-09-05T08:50:54+00:00</dc:date>
    <link>https://removepaywalls.com/https://www.nationalobserver.com/2025/09/04/investigations/google-net-zero-sustainability</link>
    <dc:creator>jm</dc:creator><description><![CDATA["An investigation by Canada’s National Observer has found that Google’s net-zero pledge has quietly been scrubbed, demoted from having its own section on the site to an entry in the appendices of the company's sustainability report."]]></description>
<dc:subject>net-zero climate-change google dont-be-evil sustainability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:031dd118114b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:net-zero"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dont-be-evil"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theregister.com/2025/08/27/ovhcloud_interview/?ck_subscriber_id=512829374#438:%20Amazon%20Q%20Rules%20Except%20It%20Doesn't%20At%20All%20-%2018837614">
    <title>OVHcloud legal eagle on Microsoft's sovereignty admission</title>
    <dc:date>2025-09-02T15:55:49+00:00</dc:date>
    <link>https://www.theregister.com/2025/08/27/ovhcloud_interview/?ck_subscriber_id=512829374#438:%20Amazon%20Q%20Rules%20Except%20It%20Doesn't%20At%20All%20-%2018837614</link>
    <dc:creator>jm</dc:creator><description><![CDATA[OVHCloud are (rightfully) making plentiful hay from Microsoft's admission that data sovereignty is a joke under US law:

<blockquote>"[Microsoft] finally told the truth!" says OVHcloud Chief Legal Officer Solange Viegas Dos Reis. "It's not a surprise," she shrugs, "we already knew that [MS could not guarantee that customer data would remain protected from US government access requests]." However, "this reply from Microsoft brought kind of a shock for customers, because they suddenly discover that what they have been taught for a while. 'Oh guys, don't worry, it will not apply to you. Don't worry.' It's false! Because, indeed, the data can be communicated."

Anton Carniaux, director of public and legal affairs at Microsoft France, made the admission during a hearing in the country. In answer to whether he could guarantee that data on French citizens could not be transmitted to the US government without the explicit agreement of the French authorities, Carniaux replied: "No, I can't guarantee it," but added that the scenario had "never happened before."

"It's a question of trust," says Viegas Dos Reis. "And because of this question of trust, we have been receiving a lot of questions from our customers about, 'Hey, we know now how it works with US cloud providers. Tell me how it works from other providers.'"</blockquote>

]]></description>
<dc:subject>ovhcloud ovh data-protection data-privacy amazon microsoft google cloud-computing sovereignty eu politics surveillance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fec01f72dff5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ovhcloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ovh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-protection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sovereignty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ketanjoshi.co/2025/08/23/big-techs-selective-disclosure-masks-ais-real-climate-impact/">
    <title>Big tech’s selective disclosure masks AI’s real climate impact</title>
    <dc:date>2025-08-25T16:18:41+00:00</dc:date>
    <link>https://ketanjoshi.co/2025/08/23/big-techs-selective-disclosure-masks-ais-real-climate-impact/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This seems spot on:

<blockquote>Using any sort of statistical summary of the data, rather than the aggregated energy and climate impact across the whole system, will always give a misleading view. They mention their data is skewed, but they don’t mention in which direction. If there is a material number of high-energy ‘reasoning’ prompts skewing their dataset, that means the total energy consumption of all prompts will be very high, with much of the responsibility coming from a few energy-hungry queries.

Part of the reason this is important is that this week, we saw a new research paper that shows that the energy consumption of text generation massively increases for every small gain in accuracy from the use of energy-hungry ‘reasoning’ models:

It would have been pretty easy to supply the range, the skew, the average and the median, or even the actual entire dataset, to avoid any doubt. Any hint of looking at the broader system rather than individual responsibility is excised from this paper. That is clearly an intentional choice: if Google disclosed the system impacts of generation, it would probably look way worse. [....]

The per-query narrative framing paints the precise opposite picture to what we see when we look at what really matters for environment and climate: the absolute figures.

Regions with high data centre concentration are seeing accelerated growth in power demand that incentivises fossil fuels, either slowing down climate progress or reversing it entirely. The sphere of that influence is expanding from towns, to states, to countries. The companies that own them can only partially hide the steep backsliding in their aggregate disclosures.

Renewable energy that should be displacing fossil fuels ends up meeting new data centre demand, granting coal and gas extra years and decades of immediate, measurable harm to human life. The worst players don’t even bother with the grid, plugging data centres directly into new, custom-built fossil fuelled power stations that’ll hurt people for decades after the hype dissipates.</blockquote>

]]></description>
<dc:subject>llms ai environment energy climate climate-change google meta amazon openai datacenters</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:91f00b24c31a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:environment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:meta"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://archive.ph/SExCe#selection-1813.0-1829.282">
    <title>Hackers Hijacked Google’s Gemini AI With a Poisoned Calendar Invite to Take Over a Smart Home | WIRED</title>
    <dc:date>2025-08-07T16:26:30+00:00</dc:date>
    <link>https://archive.ph/SExCe#selection-1813.0-1829.282</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The three smart-home hacks are part of a series of 14 indirect prompt-injection attacks against Gemini across web and mobile that the researchers dubbed Invitation Is All You Need. (The 2017 research that led to the recent generative AI breakthroughs like ChatGPT is called “Attention Is All You Need.”) In the demonstrations, revealed at the Black Hat cybersecurity conference in Las Vegas this week, the researchers show how Gemini can be made to send spam links, generate vulgar content, open up the Zoom app and start a call, steal email and meeting details from a web browser, and download a file from a smartphone’s web browser.</blockquote>

Looking forward to hearing more about this :)]]></description>
<dc:subject>google gemini llms security infosec in-band-signalling exploits fail black-hat</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6502b5a4f704/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gemini"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:in-band-signalling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:black-hat"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://easydmarc.com/blog/google-spoofed-via-dkim-replay-attack-a-technical-breakdown/">
    <title>Google Spoofed Via DKIM Replay Attack</title>
    <dc:date>2025-07-25T14:51:48+00:00</dc:date>
    <link>https://easydmarc.com/blog/google-spoofed-via-dkim-replay-attack-a-technical-breakdown/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Quite a clever attack on DMARC; by persuading Google to create a message body that contains the desired phish attack text, then using its legit signing infrastructure to sign the message, an attacker can then "forward" that message to their list of phish victims.  Ouch]]></description>
<dc:subject>phishing dkim dmarc google attacks exploits infosec email smtp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:95c450bb6da7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dkim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dmarc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:attacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smtp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pluralistic.net/2025/07/15/inhuman-gigapede/">
    <title>Pluralistic: When Google's slop meets webslop, search stops (15 Jul 2025)</title>
    <dc:date>2025-07-16T10:35:37+00:00</dc:date>
    <link>https://pluralistic.net/2025/07/15/inhuman-gigapede/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Cory Doctorow on how Google are desperate to maintain a facade of being a "growth" company:

<blockquote>Investors have metabolized the story that AI will be a gigantic growth area, and so all the tech giants are in a battle to prove to investors that they will dominate AI as they dominated their own niches. You aren't the target for AI, investors are: if they can be convinced that Google's 90% Search market share will soon be joined by a 90% AI market share, they will continue to treat this decidedly tired and run-down company like a prize racehorse at the starting-gate. [...]

There's a cringe army of AI bros who are seemingly convinced that AI is going to become superintelligent and save us from ourselves – they think that AI companies are creating god. But the hundreds of billions being pumped into AI are not driven by this bizarre ideology. Rather, they are the product of material conditions, a system that sends high-flying companies into a nosedive the instant they stop climbing. AI's merits and demerits are irrelevant to this: they pump AI because they must pump. It's why they pumped metaverse and cryptocurrency and every other absurd fad.

None of that changes the fact that Google Search has been terminally enshittified and it is misleading billions of people in service to this perverse narrative adventure. Google Search isn't fit for purpose, and it's hard to see how it ever will be again.</blockquote>

(via Fergal)]]></description>
<dc:subject>google growth ai capitalism investors enshittification via:fergal</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c2218ff684ca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:growth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capitalism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:investors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:enshittification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fergal"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.google.com/bigquery/docs/automatic-discovery">
    <title>Dataplex automatic discovery</title>
    <dc:date>2025-05-12T17:04:51+00:00</dc:date>
    <link>https://cloud.google.com/bigquery/docs/automatic-discovery</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Dataplex, a feature of BigQuery that'll automatically index Google Cloud Storage bucket contents to extract queryable metadata from Parquet, Avro, ORC, JSON and CSV files]]></description>
<dc:subject>dataplex bigquery gcs google gcp parquet avro orc json csv storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:82927ee4918c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataplex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bigquery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parquet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:avro"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:orc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:csv"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.google.com/storage/docs/best-practices">
    <title>Best practices for Google Cloud Storage</title>
    <dc:date>2025-04-25T17:12:59+00:00</dc:date>
    <link>https://cloud.google.com/storage/docs/best-practices</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting to note that GCS has the same issue with unevenly-distributed names as S3 does; https://cloud.google.com/storage/docs/request-rate#naming-convention]]></description>
<dc:subject>gcs aws s3 storage google best-practices ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9d8107872c47/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:best-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mastodon.social/@BenRossTransit/113741945325663404">
    <title>Waymos don't stop for pedestrians</title>
    <dc:date>2025-01-10T10:40:39+00:00</dc:date>
    <link>https://mastodon.social/@BenRossTransit/113741945325663404</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ah here.

"Waymo (aka Google) admits that it trains its robotaxis to break the law. When a Washington Post reporter finds robotaxis fail to stop for pedestrians in marked crosswalk 70% of the time, Waymo says it follows "social norms" rather than laws.

Expert explains: When robotaxis obey law, they don't go fast enough to compete successfully with Uber, so Google execs ordered engineers to ignore laws."]]></description>
<dc:subject>google waymo laws pedestrians safety crosswalks crossings road-safety self-driving-cars</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:04820be76c00/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:waymo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pedestrians"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crosswalks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crossings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:road-safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:self-driving-cars"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://deepmind.google/discover/blog/gencast-predicts-weather-and-the-risks-of-extreme-conditions-with-sota-accuracy/">
    <title>GenCast</title>
    <dc:date>2024-12-06T09:26:12+00:00</dc:date>
    <link>https://deepmind.google/discover/blog/gencast-predicts-weather-and-the-risks-of-extreme-conditions-with-sota-accuracy/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Google DeepMind announce their new AI model for weather forecasting, in collaboration with the ECMWF:

<blockquote>Today, in a paper published in Nature, we present GenCast, our new high resolution (0.25°) AI ensemble model. GenCast provides better forecasts of both day-to-day weather and extreme events than the top operational system, the European Centre for Medium-Range Weather Forecasts’ (ECMWF) ENS, up to 15 days in advance. We’ll be releasing our model’s code, weights, and forecasts, to support the wider weather forecasting community. [...]

GenCast is a diffusion model, the type of generative AI model that underpins the recent, rapid advances in image, video and music generation. However, GenCast differs from these, in that it’s adapted to the spherical geometry of the Earth, and learns to accurately generate the complex probability distribution of future weather scenarios when given the most recent state of the weather as input.

To train GenCast, we provided it with four decades of historical weather data from ECMWF’s ERA5 archive. This data includes variables such as temperature, wind speed, and pressure at various altitudes. The model learned global weather patterns, at 0.25° resolution, directly from this processed weather data.</blockquote>

It's open source: https://github.com/google-deepmind/graphcast

And here are the open-released model weights: https://console.cloud.google.com/storage/browser/dm_graphcast

Graphcast (the previous iteration) has public forecasts published at https://charts.ecmwf.int/?query=GraphCast , under a CC-BY-NC-SA-4 licence -- it would be great if the GenCast forecasts join this data set.

Paper: https://arxiv.org/abs/2312.15796

This all looks really great, a fantastic commitment to (genuine) openness and open data, and the paper seems rigorous (to this amateur).  Great stuff.]]></description>
<dc:subject>forecasting weather ai gencast graphcast deepmind google ecmwf genai</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1942c3a6a11e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:forecasting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:weather"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gencast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphcast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deepmind"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecmwf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:genai"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/rspeer/wordfreq/blob/master/SUNSET.md">
    <title>wordfreq/SUNSET.md</title>
    <dc:date>2024-09-19T08:56:30+00:00</dc:date>
    <link>https://github.com/rspeer/wordfreq/blob/master/SUNSET.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[wordfreq is "a Python library for looking up the frequencies of words in many languages, based on many sources of data."  Sadly, it's now longer going to be updated, as the author writes:

<blockquote>I don't want to be part of this scene anymore:

wordfreq used to be at the intersection of my interests. I was doing corpus linguistics in a way that could also benefit natural language processing tools.

The field I know as "natural language processing" is hard to find these days. It's all being devoured by generative AI. Other techniques still exist but generative AI sucks up all the air in the room and gets all the money. It's rare to see NLP research that doesn't have a dependency on closed data controlled by OpenAI and Google, two companies that I already despise.

wordfreq was built by collecting a whole lot of text in a lot of languages. That used to be a pretty reasonable thing to do, and not the kind of thing someone would be likely to object to. Now, the text-slurping tools are mostly used for training generative AI, and people are quite rightly on the defensive. If someone is collecting all the text from your books, articles, Web site, or public posts, it's very likely because they are creating a plagiarism machine that will claim your words as its own.

So I don't want to work on anything that could be confused with generative AI, or that could benefit generative AI.

OpenAI and Google can collect their own damn data. I hope they have to pay a very high price for it, and I hope they're constantly cursing the mess that they made themselves.</blockquote>

]]></description>
<dc:subject>ai language llm nlp openai scraping words genai google</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:86312ba8479e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:language"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nlp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:words"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:genai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://disconnect.blog/generative-ai-is-a-climate-disaster/">
    <title>Generative AI is a climate disaster</title>
    <dc:date>2024-07-11T15:31:15+00:00</dc:date>
    <link>https://disconnect.blog/generative-ai-is-a-climate-disaster/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[yup]]></description>
<dc:subject>ai energy google llm openai microsoft datacenters climate-change paris-marx</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a35612d5af6b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:paris-marx"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theverge.com/2024/6/11/24176490/mm-delicious-glue">
    <title>Google still recommends glue for your pizza</title>
    <dc:date>2024-06-12T13:30:51+00:00</dc:date>
    <link>https://www.theverge.com/2024/6/11/24176490/mm-delicious-glue</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Just phenomenal stuff here, folks. Every time someone like me reports on Google’s AI getting something wrong, we’re training the AI to be wronger."]]></description>
<dc:subject>google lol funny training fail google-bombing miserable-failure ai glue pizza</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2e2c406e4886/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:training"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-bombing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:miserable-failure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pizza"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gist.github.com/velzie/053ffedeaecea1a801a2769ab86ab376">
    <title>How to keep using adblockers on chrome and chromium</title>
    <dc:date>2024-06-12T13:18:05+00:00</dc:date>
    <link>https://gist.github.com/velzie/053ffedeaecea1a801a2769ab86ab376</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Google's manifest v3 has no analouge [sic] to the webRequestBlocking API, which is neccesary for (effective) adblockers to work
starting in chrome version 127, the transition to mv3 will start cutting off the use of mv2 extensions alltogether
this will inevitably piss of enterprises when their extensions don't work, so the ExtensionManifestV2Availability key was added and will presumably stay forever after enterprises complain enough
You can use this as a regular user, which will let you keep your mv2 extensions even after they're supposed to stop working.</blockquote>

]]></description>
<dc:subject>google chrome chromium adblockers extensions via:micktwomey privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d0b78a909b24/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chromium"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:adblockers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:extensions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:micktwomey"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/2405.14975">
    <title>_Surveilling the Masses with Wi-Fi-Based Positioning Systems_</title>
    <dc:date>2024-05-28T10:53:20+00:00</dc:date>
    <link>https://arxiv.org/abs/2405.14975</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is pretty crazy stuff, I had no idea the WPSes were fully queryable:

<blockquote>
Wi-Fi-based Positioning Systems (WPSes) are used by modern mobile devices to learn their position using nearby Wi-Fi access points as landmarks. In this work, we show that Apple's WPS can be abused to create a privacy threat on a global scale. We present an attack that allows an unprivileged attacker to amass a worldwide snapshot of Wi-Fi BSSID geolocations in only a matter of days. Our attack makes few assumptions, merely exploiting the fact that there are relatively few dense regions of allocated MAC address space. Applying this technique over the course of a year, we learned the precise locations of over 2 billion BSSIDs around the world.

The privacy implications of such massive datasets become more stark when taken longitudinally, allowing the attacker to track devices' movements. While most Wi-Fi access points do not move for long periods of time, many devices -- like compact travel routers -- are specifically designed to be mobile. We present several case studies that demonstrate the types of attacks on privacy that Apple's WPS enables: We track devices moving in and out of war zones (specifically Ukraine and Gaza), the effects of natural disasters (specifically the fires in Maui), and the possibility of targeted individual tracking by proxy -- all by remotely geolocating wireless access points. We provide recommendations to WPS operators and Wi-Fi access point manufacturers to enhance the privacy of hundreds of millions of users worldwide. Finally, we detail our efforts at responsibly disclosing this privacy vulnerability, and outline some mitigations that Apple and Wi-Fi access point manufacturers have implemented both independently and as a result of our work.</blockquote>]]></description>
<dc:subject>geolocation location wifi wps apple google infosec privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:277b19975935/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:geolocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:location"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident">
    <title>Technical post-mortem on the Google/UniSuper account deletion</title>
    <dc:date>2024-05-24T16:24:08+00:00</dc:date>
    <link>https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Google operators followed internal control protocols. However, one input parameter was left blank when using an internal tool to provision the customer’s Private Cloud. As a result of the blank parameter, the system assigned a then unknown default fixed 1 year term value for this parameter.   

After the end of the system-assigned 1 year period, the customer’s GCVE Private Cloud was deleted. No customer notification was sent because the deletion was triggered as a result of a parameter being left blank by Google operators using the internal tool, and not due a customer deletion request. Any customer-initiated deletion would have been preceded by a notification to the customer."

Ouch.]]></description>
<dc:subject>cloud ops google tools ux via:scott-piper fail infrastructure gcp unisuper</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:36e0042aca18/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:scott-piper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unisuper"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arstechnica.com/gadgets/2024/05/google-cloud-accidentally-nukes-customer-account-causes-two-weeks-of-downtime/">
    <title>“Unprecedented” Google Cloud event wipes out customer account and its backups</title>
    <dc:date>2024-05-20T09:02:20+00:00</dc:date>
    <link>https://arstechnica.com/gadgets/2024/05/google-cloud-accidentally-nukes-customer-account-causes-two-weeks-of-downtime/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ars Technica's reporting of the Google Cloud/UniSuper outage. Google really needs to issue some kind of technical post-mortem of this incident, it's staggeringly bad PR and terrifying for large scale cloud users.  Credit to UniSuper for being able to recover after this (using backups stored at another cloud provider...)]]></description>
<dc:subject>google fail outages unisuper cloud google-cloud ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2977518a076b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unisuper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=40304666">
    <title>UniSuper members go a week with no account access after Google Cloud misconfig | Hacker News</title>
    <dc:date>2024-05-13T09:18:17+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=40304666</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a staggering fail by Google -- Google Cloud accidentally deleted a company's *entire cloud environment* (UniSuper, an Australian pensions company, which manages $80B). The company had backups in another region, but GCP deleted those too. Luckily, they had yet more backups on another provider.  They were only convinced to migrate to GCP last year, and then this.  Looking forward to the root cause analysis....

(via Last Week in AWS)]]></description>
<dc:subject>gcp google fail unisuper account-deletion ops nightmare</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6a50f687f8c2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unisuper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:account-deletion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nightmare"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.nytimes.com/2024/04/06/technology/tech-giants-harvest-data-artificial-intelligence.html">
    <title>How Tech Giants Cut Corners to Harvest Data for A.I. - The New York Times</title>
    <dc:date>2024-04-08T13:06:43+00:00</dc:date>
    <link>https://www.nytimes.com/2024/04/06/technology/tech-giants-harvest-data-artificial-intelligence.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Can't wait for all the lawsuits around this stuff.

<blockquote>Meta could not match ChatGPT unless it got more data, Mr. Al-Dahle told colleagues. In March and April 2023, some of the company’s business development leaders, engineers and lawyers met nearly daily to tackle the problem. [....]

They also talked about how they had summarized books, essays and other works from the internet without permission and discussed sucking up more, even if that meant facing lawsuits. One lawyer warned of “ethical” concerns around taking intellectual property from artists but was met with silence, according to the recordings.</blockquote>

]]></description>
<dc:subject>ai copyright data training openai meta google privacy surveillance data-protection ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:72d55c3af228/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:training"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:meta"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-protection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://housefresh.com/david-vs-digital-goliaths/">
    <title>How Google is killing independent sites like ours</title>
    <dc:date>2024-02-22T14:24:38+00:00</dc:date>
    <link>https://housefresh.com/david-vs-digital-goliaths/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[.... "And why you shouldn’t trust product recommendations from big media publishers ranking at the top of Google".

This is an eye-opener -- I didn't realise how organised the affiliate marketing ecosystem was, in terms of gaming SEO.  Google are now biasing towards this approach:

<blockquote>
Google has a clear bias towards big media publishers.

Their Core and Helpful Content updates are heavily focused on something they call E-E-A-T, which is an acronym that stands for Experience, Expertise, Authoritativeness, and Trustworthiness. 

The SEO world has been obsessed with E-E-A-T for a few years now, to the point where there is always someone on X (formerly Twitter) discussing how to show experience, expertise, authoritativeness, and trustworthiness. Many of the examples come from dissecting big media publishers like the ones we’ve been discussing in this article. 

The reason why SEOs look up to these sites is that Google rewards those sites.
</blockquote>

]]></description>
<dc:subject>enshittification internet google reviews seo eeat content publishing bias search-engines</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7029fee5b580/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:enshittification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:seo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eeat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:content"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:publishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bias"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search-engines"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.iccl.ie/digital-data/europes-hidden-security-crisis/">
    <title>Europe’s hidden security crisis</title>
    <dc:date>2023-11-14T12:45:20+00:00</dc:date>
    <link>https://www.iccl.ie/digital-data/europes-hidden-security-crisis/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bloody hell! This is a big one, from the ICCL:

<blockquote>Our investigation highlights a widespread trade in data about sensitive European personnel and leaders that exposes them to blackmail, hacking and compromise, and undermines the security of their organisations and institutions. 

These data flow from Real-Time Bidding (RTB), an advertising technology that is active on almost all websites and apps. RTB involves the broadcasting of sensitive data about people using those websites and apps to large numbers of other entities, without security measures to protect the data. This occurs billions of times a day. 

Our examination of tens of thousands of pages of RTB data reveals that EU military personnel and political decision makers are targeted using RTB.

This report also reveals that Google and other RTB firms send RTB data about people in the U.S. to Russia and China, where national laws enable security agencies to access the data. RTB data are also broadcast widely within the EU in a free-for-all, which means that foreign and non-state actors can indirectly obtain them, too. 

RTB data often include location data or time-stamps or other identifiers that make it relatively easy for bad actors to link them to specific individuals. Foreign states and non-state actors can use RTB to spy on target individuals’ financial problems, mental state, and compromising intimate secrets. Even if target individuals use secure devices, data about them will still flow via RTB from personal devices, their friends, family, and compromising personal contacts.

In addition, private surveillance companies in foreign countries deploy RTB data for surreptitious surveillance. We reveal “Patternz”, a previously unreported surveillance tool that uses RTB to profile 5 billion people, including the children of their targets.</blockquote>

]]></description>
<dc:subject>iccl rtb targeting profiling patternz google ads security national-security surveillance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:12f9c4852a7f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iccl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rtb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:targeting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patternz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:national-security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/">
    <title>Hacking Google Bard - From Prompt Injection to Data Exfiltration</title>
    <dc:date>2023-11-14T11:29:04+00:00</dc:date>
    <link>https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A solid LLM XSS prompt-injection exploit on Bard; inject chat history into a Google Apps Script invocation and exfiltrate via a Google Doc.

The thing I find most shocking about this is that it's entirely by-the-numbers.  This is the simplest possible way to exploit Bard (well, maybe the second after an IMG tag), and it's a frankly shocking that it worked.  I am particularly unimpressed that Google Apps Script was permitted as an output from Bard!

LLM security is going to be a total shambles if this is the state of the art.]]></description>
<dc:subject>ai bard llm security infosec exploits prompt-injection xss google</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f9b8f80523c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prompt-injection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.zgp.org/google-chrome-checklist/">
    <title>Google Chrome ad features checklist</title>
    <dc:date>2023-10-04T16:40:20+00:00</dc:date>
    <link>https://blog.zgp.org/google-chrome-checklist/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a list of ad-surveillance and AI-training features to turn off, both on our personal browsing and on your websites, courtesy of Don Marti]]></description>
<dc:subject>browsers chrome privacy data-privacy google</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b8a9db5ae318/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:browsers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chrome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ericdraken.com/pfsense-decrypt-ad-traffic/">
    <title>Block YouTube Ads on AppleTV by Decrypting and Stripping Ads from Profobuf</title>
    <dc:date>2023-08-29T08:25:08+00:00</dc:date>
    <link>https://ericdraken.com/pfsense-decrypt-ad-traffic/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good deep dive into reverse engineering and rewriting in-app HTTP protocols on the wire.  Terrible way to do ad-blocking, though]]></description>
<dc:subject>blocking protobuf youtube google protocols appletv apps reverse-engineering</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9567c6ad4947/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protobuf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:youtube"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:appletv"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reverse-engineering"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gizmodo.com/google-says-itll-scrape-everything-you-post-online-for-1850601486">
    <title>Google Says It'll Scrape Everything You Post Online for AI</title>
    <dc:date>2023-07-05T14:49:54+00:00</dc:date>
    <link>https://gizmodo.com/google-says-itll-scrape-everything-you-post-online-for-1850601486</link>
    <dc:creator>jm</dc:creator><description><![CDATA["If Google can read your words, assume they belong to the company now, and expect that they’re nesting somewhere in the bowels of a chatbot."

]]></description>
<dc:subject>ai content google ip scraping ml training</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1cfba998e7eb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:content"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:training"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://sites.google.com/view/nuitattack/home">
    <title>NUIT</title>
    <dc:date>2023-05-26T09:07:48+00:00</dc:date>
    <link>https://sites.google.com/view/nuitattack/home</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a novel inaudible attack against voice assistants (Siri, Google Assistant, Alexa, Cortana) that can be waged remotely through internet. Nuit  appears as a sound clip in near-ultrasound frequency range (16kHz-20kHz), thus can be played on the victim's COTS speaker to attack the voice assistant (i) on the same device (NUIT-1)；(ii) on victim's other devices (NUIT-2).</blockquote>

]]></description>
<dc:subject>nuit attacks exploits alexa google siri voice-assistants security</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b40e2b98abb7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nuit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:attacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alexa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:siri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voice-assistants"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://sea.mashable.com/tech/23295/google-launched-bard-despite-major-ethical-concerns-from-its-employees">
    <title>Google Launched Bard Despite Major Ethical Concerns From Its Employees</title>
    <dc:date>2023-04-25T13:57:24+00:00</dc:date>
    <link>https://sea.mashable.com/tech/23295/google-launched-bard-despite-major-ethical-concerns-from-its-employees</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>"The staffers who are responsible for the safety and ethical implications of new products have been told not to get in the way or to try to kill any of the generative AI tools in development," employees told Bloomberg. The ethics team is now "disempowered and demoralized," according to former and current staffers.

Before OpenAI launched ChatGPT in November 2022, Google's approach to AI was more cautious and less consumer-facing, often working in the background of tools like Search and Maps. But since ChatGPT's enormous popularity prompted a "code red" from executives, Google's threshold for safe product releases has been lowered in an effort to keep up with its AI competitors.</blockquote>

]]></description>
<dc:subject>google ai safety chatgpt bard corporate-responsibility</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e65ec4c86acb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chatgpt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corporate-responsibility"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://archive.is/L49pO#selection-1915.0-1923.256">
    <title>Google &quot;raters&quot; say they don't have enough time to verify correct answers from Bard</title>
    <dc:date>2023-04-06T09:16:30+00:00</dc:date>
    <link>https://archive.is/L49pO#selection-1915.0-1923.256</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Contractors say they have a set amount of time to complete each task, like review a prompt, and the time they're allotted for tasks can vary wildly — from as little as 60 seconds to more than several minutes. Still, raters said it's difficult to rate a response when they are not well-versed in a topic the chatbot is talking about, including technical topics like blockchain for example. 
Because each assigned task represents billable time, some workers say they will complete the tasks even if they realize they cannot accurately assess the chatbot responses. 

"Some people are going to say that's still 60 seconds of work, and I can't recoup this time having sat here and figured out I don't know enough about this, so I'm just going to give it my best guess so I can keep that pay and keep working," one rater said.</blockquote>

]]></description>
<dc:subject>google raters contractors fact-checking verification llms bard facts</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:567070929ebc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:contractors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fact-checking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:verification"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facts"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theverge.com/2023/3/22/23651564/google-microsoft-bard-bing-chatbots-misinformation">
    <title>Google and Microsoft’s chatbots are already citing one another in a misinformation shitshow</title>
    <dc:date>2023-03-24T11:25:15+00:00</dc:date>
    <link>https://www.theverge.com/2023/3/22/23651564/google-microsoft-bard-bing-chatbots-misinformation</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>What we have here is an early sign we’re stumbling into a massive game of AI misinformation telephone, in which chatbots are unable to gauge reliable news sources, misread stories about themselves, and misreport on their own capabilities. In this case, the whole thing started because of a single joke comment on Hacker News. Imagine what you could do if you wanted these systems to fail. It’s a laughable situation but one with potentially serious consequences. Given the inability of AI language models to reliably sort fact from fiction, their launch online threatens to unleash a rotten trail of misinformation and mistrust across the web, a miasma that is impossible to map completely or debunk authoritatively. All because Microsoft, Google, and OpenAI have decided that market share is more important than safety.</blockquote>

]]></description>
<dc:subject>google ai ml microsoft openai chatgpt trust spam misinformation disinformation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1f5b64825f87/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chatgpt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:misinformation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disinformation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://downrightnifty.me/blog/2022/12/26/hacking-google-home.html">
    <title>Turning Google smart speakers into wiretaps for $100k</title>
    <dc:date>2023-01-04T11:39:31+00:00</dc:date>
    <link>https://downrightnifty.me/blog/2022/12/26/hacking-google-home.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is some very impressive work on reverse engineering a fairly advanced IoT device (the Google Home Mini), discovering and exploiting its security holes.

<blockquote>I was recently rewarded a total of $107,500 by Google for responsibly disclosing security issues in the Google Home smart speaker that allowed an attacker within wireless proximity to install a “backdoor” account on the device, enabling them to send commands to it remotely over the Internet, access its microphone feed, and make arbitrary HTTP requests within the victim’s LAN (which could potentially expose the Wi-Fi password or provide the attacker direct access to the victim’s other devices). These issues have since been fixed.</blockquote>
]]></description>
<dc:subject>security google wiretapping exploits hacking iot reverse-engineering</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a2dc98e51556/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wiretapping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reverse-engineering"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.boards.ie/discussion/comment/119595524/#Comment_119595524">
    <title>WiFi calling blocked on Pixel phones</title>
    <dc:date>2022-12-06T13:26:44+00:00</dc:date>
    <link>https://www.boards.ie/discussion/comment/119595524/#Comment_119595524</link>
    <dc:creator>jm</dc:creator><description><![CDATA[what the hell?

"Unless you're on an operator that sells Pixel phones directly, who basically comprise the "Google list" for these features, [wifi calling] won't work for any [directly-purchased] Pixel phone [in Ireland]. Same all over Europe.

VoLTE won't work either when on a mobile network (data speeds will drop to 3G when on a voice call) [...] Your only option would be to root the phone to get it to work.

There seem to have been some recent changes on this but seems like Eir still no go."

I've been wondering why VoLTE and VoWifi have been unavailable on my phone for several months now, assuming it was an operator issue. Finally I was sent this link by a poster on another forum -- it's not an issue with the operator, it's a builtin limitation on the phone.

All I can presume is that Google have done exclusivity deals with some providers in some regions, but is keeping this secret for some reason. If I'd known this in advance, I'd probably have bought a different phone; absolutely terrible decision.

Reportedly it can be reversed via rooting the phone, at least.]]></description>
<dc:subject>android google pixel wifi-calling vowifi volte lte mobile</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:422df66b7e44/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pixel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi-calling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vowifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:volte"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lte"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.etsy.com/codeascraft/cloud-jewels-estimating-kwh-in-the-cloud">
    <title>Cloud Jewels</title>
    <dc:date>2022-11-15T12:47:56+00:00</dc:date>
    <link>https://www.etsy.com/codeascraft/cloud-jewels-estimating-kwh-in-the-cloud</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Etsy: "Estimating kWh in the Cloud":

<blockquote>
We thought about how we might be able to estimate our energy consumption in Google Cloud using the data we do have: Google provides us with usage data that shows us how many virtual CPU (Central Processing Unit) seconds we used, how much memory we requested for our servers, how many terabytes of data we have stored for how long, and how much networking traffic we were responsible for. 

Our supposition was that if we could come up with general estimates for how many watt-hours (Wh) compute, storage and networking draw in a cloud environment, particularly based on public information, then we could apply those coefficients to our usage data to get at least a rough estimate of our cloud computing energy impact.

We are calling this set of estimated conversion factors Cloud Jewels. Other cloud computing consumers can look at this and see how it might work with their own energy usage across providers and usage data. The goal is to help cloud users across the industry to help refine our estimates, and ultimately help us encourage cloud providers to empower their customers with more accurate cloud energy consumption data.</blockquote>

This is a good interim step, but it's disappointing how inaccurate the CO2 data exposed by cloud providers is.  IMO this needs to be fixed]]></description>
<dc:subject>climate co2 google cloud aws etsy estimation cloud-jewels sustainability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6277c4d2cc9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:co2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:etsy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-jewels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/lizthegrey/status/1582593768280461313">
    <title>Liz Fong-Jones talks about Google's history of loadbalancers</title>
    <dc:date>2022-10-20T09:55:47+00:00</dc:date>
    <link>https://twitter.com/lizthegrey/status/1582593768280461313</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Okay, the time has come, it's been an entire decade, let's talk about loadbalancing techniques and how they evolved at Google in response to various practical failure modes, from 2008 to 2012."

This thread is great. A solid history of Google's use of various load balancing techniques, ranging from N+1 service duplication with implicit failover rules, modern-service-mesh-style proxying, client-side builtin load balancing libs, followed by local sidecars which downloaded routing assignment configs periodically and operated mainly offline.]]></description>
<dc:subject>load-balancing history google ops liz-fong-jones service-meshes sidecars proxies</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:03d4d5d9c0a0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:liz-fong-jones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-meshes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sidecars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxies"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/buccocapital/status/1576909546164928513/photo/1">
    <title>The LPA Cycle</title>
    <dc:date>2022-10-03T21:43:18+00:00</dc:date>
    <link>https://twitter.com/buccocapital/status/1576909546164928513/photo/1</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Launch, Promo, Abandon" -- the problem that pervades Google's dev culture]]></description>
<dc:subject>lpa google fail promotions how-we-work culture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:71e62edacc23/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lpa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:promotions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:how-we-work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://9to5google.com/2022/09/25/google-photos-corrupted/">
    <title>Google Photos corrupting images</title>
    <dc:date>2022-09-26T10:24:26+00:00</dc:date>
    <link>https://9to5google.com/2022/09/25/google-photos-corrupted/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Is Google experimenting with a new (and broken) compression algorithm?

<blockquote>Over the weekend, people began noticing that their years-old photos (over five years, approximately) have lines and deep cracks running through them, as well as other blurry or distorted areas. White dots are also a common occurrence. Some images are more damaged than others with seemingly no pattern to what’s impacted or the severity.

It’s weirdly somewhat analogous to physical water damage, with reports across Google Photos for Android, iOS, and the web.

According to those affected, the corruption persists when downloading the image. This apparently applies to both individual downloads and when using Google Takeout. The original copies of pictures do not appear to be impacted, but the edited ones are what appear in the Google Photos apps. </blockquote>

]]></description>
<dc:subject>google google-photos images compression fail artifacts</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5a35ff10337c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-photos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:artifacts"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.lastweekinaws.com/blog/How-Google-Cloud-and-AWS-Approach-Customer-Carbon-Emissions/?ck_subscriber_id=512829374">
    <title>How Google Cloud and AWS Approach Customer Carbon Emissions - Last Week in AWS Blog</title>
    <dc:date>2022-09-01T08:30:22+00:00</dc:date>
    <link>https://www.lastweekinaws.com/blog/How-Google-Cloud-and-AWS-Approach-Customer-Carbon-Emissions/?ck_subscriber_id=512829374</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Google wins:

<blockquote>On a larger scale, Google Cloud is already at 100% carbon neutrality, apparently via offsets and a few other accounting approaches, with a goal to move to 100% renewable energy for all cloud regions by 2030.

Meanwhile, AWS’s carbon footprint tool is an embarrassment to AWS and its stated goal of reaching 100% renewable energy usage by 2025.

The bottom line: One of these carbon neutrality approaches is indicative of a thoughtful approach to partnering with customers to lead to a better climate story around cloud usage. The other appears to have been phoned in by clowns the night before it was due.</blockquote>

]]></description>
<dc:subject>aws google carbon climate-change co2 hosting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44b9a53ef1b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:carbon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:co2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency">
    <title>How Discord Supercharges Network Disks for Extreme Low Latency</title>
    <dc:date>2022-08-16T10:07:47+00:00</dc:date>
    <link>https://discord.com/blog/how-discord-supercharges-network-disks-for-extreme-low-latency</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Similar to a trick we used to use at Swrve to do roughly the same thing with EBS on AWS]]></description>
<dc:subject>discord google disks performance optimization scylladb md raid ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f663d3221476/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:discord"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylladb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:md"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.fastcompany.com/3037803/the-oral-history-of-the-poop-emoji-or-how-google-brought-poop-to-america">
    <title>The Oral History Of The Poop Emoji (Or, How Google Brought Poop To America)</title>
    <dc:date>2022-07-25T14:35:09+00:00</dc:date>
    <link>https://www.fastcompany.com/3037803/the-oral-history-of-the-poop-emoji-or-how-google-brought-poop-to-america</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Darren: I thought it was a joke that they were pushing for the [poop emoji] to be in the first cut, but I quickly learned that it was not a joke at all. It’s basically like having all of the letters in the English alphabet, but getting rid of random ones. Like, “Let’s take out ‘B’ because ‘B’ kind of offends me.” In Japanese, emoji are more like characters than random animated emoticons, so we pushed back really hard. We said, “We can’t launch emoji without the poop.” Not only is it extremely popular in Japan—like extremely popular—you can’t just arbitrarily take letters out of the alphabet."]]></description>
<dc:subject>emoji gmail history google poop shit funny japan</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4fdbba11f19/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emoji"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gmail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:poop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:japan"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://fonts.google.com/noto/specimen/Noto+Emoji">
    <title>Noto Emoji</title>
    <dc:date>2022-05-04T14:05:38+00:00</dc:date>
    <link>https://fonts.google.com/noto/specimen/Noto+Emoji</link>
    <dc:creator>jm</dc:creator><description><![CDATA['an open source font that has you covered for all your emoji needs, including support for the latest Unicode emoji specification (14.0). It has multiple weights and features 3,663 emoji.'

]]></description>
<dc:subject>emoji fonts typography type google noto</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9ef2994a4357/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emoji"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fonts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:typography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:type"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:noto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/GooglePixel/comments/nb314o/4a_doesnt_connect_to_lte_after_leaving_wifi/">
    <title>4a doesn't connect to LTE after leaving WiFi : GooglePixel</title>
    <dc:date>2022-04-13T15:53:05+00:00</dc:date>
    <link>https://www.reddit.com/r/GooglePixel/comments/nb314o/4a_doesnt_connect_to_lte_after_leaving_wifi/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I'm having this problem (with GoMo in Ireland). it's annoying]]></description>
<dc:subject>lte google pixel pixel-4a hardware phones mobile</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:39c5838562e8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lte"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pixel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pixel-4a"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/kantrn/status/1511791378497384454">
    <title>&quot;FAANG promo committees are killing Kubernetes&quot;</title>
    <dc:date>2022-04-07T10:01:42+00:00</dc:date>
    <link>https://twitter.com/kantrn/status/1511791378497384454</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This makes a lot of sense. Letting "working for a big software company" be the only way to effectively get paid to collaborate on open source wasn't a great idea.

<blockquote>Promo committees have, for years now, been consistently undervaluing the work of full-time Kubernetes contributors. Or really of open source work more broadly. Attributable revenue has been taking over as one of the most important factors at most companies. And Kubernetes has very little of that. It's happened gradually, and I don't think this was ever an intended outcome but it's a thing and we have to live with it.

It's too indirect, fixing a bug in kube-apiserver might retain a GCP customer or avoid a costly Apple services outage, but can you put a dollar value on that? How much is CI stability worth? Or community happiness?

And then add on top of it, the time cost. "FOSS maintainers are overloaded" should not be news to anyone, but now add 20/hours a week of campaigning to other high-level folks to "build buzz" for your work and let me know how that goes.</blockquote>

]]></description>
<dc:subject>k8s open-source google amazon faang work promotions career</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0e5c1b6b53ce/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:faang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:promotions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/hiddenmarkov/status/1497351111656751109">
    <title>Crowdworking platforms used as a tool of war</title>
    <dc:date>2022-03-02T09:52:15+00:00</dc:date>
    <link>https://twitter.com/hiddenmarkov/status/1497351111656751109</link>
    <dc:creator>jm</dc:creator><description><![CDATA[File under "grim dystopian 21st century":

Bogdan Kulynych on Twitter: "New (to me) dimension of crowdwork platforms: Russian military [used] Premise microtasking platform to aim and calibrate fire during their invasion of Ukraine. Example tasks are to locate ports, medical facilities, bridges, explosion craters. Paying ¢0.25 to $3.25 a task."

This may explain why Google Maps coverage of the area wound up with many of those features tagged in the past week.]]></description>
<dc:subject>ethics security google crowdwork crowdsourcing warfare war ukraine grim-meathook-future</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:600af00c269b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crowdwork"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crowdsourcing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:warfare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:war"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ukraine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grim-meathook-future"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/emilyldolson/status/1485434187968614411">
    <title>Fantastic false positive from Google Drive's copyright infringement scanning system</title>
    <dc:date>2022-01-25T10:14:09+00:00</dc:date>
    <link>https://twitter.com/emilyldolson/status/1485434187968614411</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Dr. Emily Dolson on Twitter: "Uh, @googledrive, are you doing okay? This file literally contains a single line with the number "1"."]]></description>
<dc:subject>google fail funny false-positives copyright bugs loneliest-number google-drive</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d729183c85b2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:false-positives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:loneliest-number"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google-drive"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://status.cloud.google.com/incidents/6PM5mNd43NbMqjCZ5REh">
    <title>Google Cloud incident was caused by a race condition which triggered 30 minutes before the bugfix deployment was due to complete</title>
    <dc:date>2021-11-23T09:58:27+00:00</dc:date>
    <link>https://status.cloud.google.com/incidents/6PM5mNd43NbMqjCZ5REh</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Wow, this was tragic!

"A Google engineer discovered this bug on 12 November, which caused us to declare an internal high-priority incident because of the latent risk to production systems. After analyzing the bug, we froze a part of our configuration system to make the likelihood of the race condition even lower. Since the race condition had existed in the fleet for several months already, the team believed that this extra step made the risk even lower. Thus the team believed the lowest-risk path [...] was to roll out fixes in a controlled manner as opposed to a same-day emergency patch. [...]

Gradual rollouts of both patches started on Monday, 15 November, and patch B completed rollout by that evening. On Tuesday, 16 November, as the patch A rollout was within 30 minutes of completing, the race condition did manifest in an unpatched cluster, and the outage started."]]></description>
<dc:subject>cloud outages tragic google race-conditions gclb patching deployment ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e167312e4892/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tragic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:race-conditions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gclb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://restofworld.org/2021/refugees-machine-learning-big-tech/">
    <title>Big tech relies on refugee labour</title>
    <dc:date>2021-09-30T09:19:57+00:00</dc:date>
    <link>https://restofworld.org/2021/refugees-machine-learning-big-tech/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Holy shit this is dystopian.

<blockquote>All of the largest companies in the world are today powered by a covert crowd of the system’s castoffs. Platforms have found amid those struggling to stay afloat in informal work — or else barely clinging onto a life in formal employment — a desperate mass to be tempted with the promise of a better life. Such a promise, however, is broken as soon as it is made; the petty services of the informal sector resemble little more than a blueprint for the microtasks of big tech, without offering anything in the way of rights, routine, role, security, or a future.</blockquote>

]]></description>
<dc:subject>colonialism refugees ai data machine-learning amazon google tesla uber mechanical-turk</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:74e3b26de6c2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:colonialism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:refugees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tesla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-turk"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/GergelyOrosz/status/1442162670753431559?s=20">
    <title>Promotion-Driven Development</title>
    <dc:date>2021-09-28T21:42:55+00:00</dc:date>
    <link>https://twitter.com/GergelyOrosz/status/1442162670753431559?s=20</link>
    <dc:creator>jm</dc:creator><description><![CDATA["If you ever wondered why Google had 8 different chat products, all killed within 3 years, but not before multiple Staff, Sr Staff, Sr PM, Principal PM, Sr EM, Director promotions were done off the back of the impact & complexity of these projects.  This is exactly why."]]></description>
<dc:subject>work jobs coding career google bigcos promotions roadmap</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:723957b301ff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jobs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bigcos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:promotions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roadmap"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc">
    <title>Steve Yegge on deprecation policies</title>
    <dc:date>2021-09-23T09:07:56+00:00</dc:date>
    <link>https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Dear Google Cloud: Your Deprecation Policy is Killing You":

<blockquote>This lack of a support culture, combined with a “let’s break it in the name of making it prettier” deprecation treadmill, is alienating their developers. And that’s not a good thing if you want to build a long-lived platform.

Google, wake the fuck up. It’s 2020. You are still losing. It’s time to take a hard look in the mirror and answer for yourselves whether you really want to be in the Cloud business.
If you do, then stop breaking shit. You guys are rich. We developers are not. So when it comes to shouldering the burden of compatibility, you need to pay for it. Not us.</blockquote>

This is absolutely correct -- API deprecation is a lovely thing when you're the one doing the deprecating, but it's a disaster for the user experience, and sometimes that should be the most important thing.]]></description>
<dc:subject>deprecation compatibility google apis support culture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b6592f19ab22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deprecation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compatibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:support"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.google.com/document/d/1Lu7XPRKlNhBQjcKr8k8qRzUzbBW7kzxb5Vu72GMRn2E/edit">
    <title>Introduction to VQGAN+CLIP - Google Docs</title>
    <dc:date>2021-08-18T10:33:04+00:00</dc:date>
    <link>https://docs.google.com/document/d/1Lu7XPRKlNhBQjcKr8k8qRzUzbBW7kzxb5Vu72GMRn2E/edit</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazingly, it seems you can experiment with GAN art using Google Collab, for free]]></description>
<dc:subject>art ml gan vqgan clip google collab toys</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:237573cc412e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vqgan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collab"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:toys"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf">
    <title>'Machine Learning: The High-Interest Credit Card of Technical Debt'</title>
    <dc:date>2021-08-05T09:46:35+00:00</dc:date>
    <link>https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Cannot agree more with this paper from Google:

'One of the basic arguments in this paper is that machine learning packages have all the basic code complexity issues as normal code, but also have a larger system-level complexity that can create hidden debt. Thus, refactoring these libraries, adding better unit tests, and associated activity is time well spent but does not necessarily address debt at a systems level.

In this paper, we focus on the system-level interaction between machine learning code and larger systems as an area where hidden technical debt may rapidly accumulate. At a system-level, a machine learning model may subtly erode abstraction boundaries. It may be tempting to re-use input signals in ways that create unintended tight coupling of otherwise disjoint systems. Machine learning packages may often be treated as black boxes, resulting in large masses of “glue code” or calibration layers that can lock in assumptions. Changes in the external world may make models or input signals change behavior in unintended ways, ratcheting up maintenance cost and the burden of any debt. Even monitoring that the system as a whole is operating as intended may be difficult without careful design.

Indeed, a remarkable portion of real-world “machine learning” work is devoted to tackling issues of this form. Paying down technical debt may initially appear less glamorous than research results usually reported in academic ML conferences. But it is critical for long-term system health and enables algorithmic advances and other cutting-edge improvements.'

(via Grady Booch)]]></description>
<dc:subject>via:gradybooch ai ml machine-learning google papers coding research production glue</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b258450e4145/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:gradybooch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:research"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glue"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/google/fully-homomorphic-encryption">
    <title>google/fully-homomorphic-encryption</title>
    <dc:date>2021-06-16T08:49:04+00:00</dc:date>
    <link>https://github.com/google/fully-homomorphic-encryption</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This repository contains open-source libraries and tools to perform fully homomorphic encryption (FHE) operations on an encrypted data set. [...]

Fully Homomorphic Encryption (FHE) is an emerging data processing paradigm that allows developers to perform transformations on encrypted data. FHE can change the way computations are performed by preserving privacy end-to-end, thereby giving users even greater confidence that their information will remain private and secure.</blockquote>

]]></description>
<dc:subject>cryptography encryption google security fhe homomorphic privacy data-privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:533ecf4cf2e5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fhe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:homomorphic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.technologyreview.com/2020/04/27/1000658/google-medical-ai-accurate-lab-real-life-clinic-covid-diabetes-retina-disease/?truid=8c8f2699f50eb3b9985a111121cfee47">
    <title>Google’s medical AI was super accurate in a lab. Real life was a different story. | MIT Technology Review</title>
    <dc:date>2020-04-28T15:55:43+00:00</dc:date>
    <link>https://www.technologyreview.com/2020/04/27/1000658/google-medical-ai-accurate-lab-real-life-clinic-covid-diabetes-retina-disease/?truid=8c8f2699f50eb3b9985a111121cfee47</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>When it worked well, the AI did speed things up. But it sometimes failed to give a result at all. Like most image recognition systems, the deep-learning model had been trained on high-quality scans; to ensure accuracy, it was designed to reject images that fell below a certain threshold of quality. With nurses scanning dozens of patients an hour and often taking the photos in poor lighting conditions, more than a fifth of the images were rejected.

Patients whose images were kicked out of the system were told they would have to visit a specialist at another clinic on another day. If they found it hard to take time off work or did not have a car, this was obviously inconvenient. Nurses felt frustrated, especially when they believed the rejected scans showed no signs of disease and the follow-up appointments were unnecessary. They sometimes wasted time trying to retake or edit an image that the AI had rejected.

Because the system had to upload images to the cloud for processing, poor internet connections in several clinics also caused delays. “Patients like the instant results, but the internet is slow and patients then complain,” said one nurse. “They’ve been waiting here since 6 a.m., and for the first two hours we could only screen 10 patients.”

The Google Health team is now working with local medical staff to design new workflows. For example, nurses could be trained to use their own judgment in borderline cases. The model itself could also be tweaked to handle imperfect images better. </blockquote>

]]></description>
<dc:subject>google health medicine ai automation software internet developing-world real-world images scanning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5622d91f3d62/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:developing-world"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:real-world"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scanning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.google/inside-google/infrastructure/data-centers-work-harder-sun-shines-wind-blows">
    <title>Google's data centers now work harder when the sun shines and wind blows</title>
    <dc:date>2020-04-23T10:48:55+00:00</dc:date>
    <link>https://blog.google/inside-google/infrastructure/data-centers-work-harder-sun-shines-wind-blows</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is fantastic -- aligning batch processing jobs to the availability of sustainable energy:

<blockquote>Our latest advancement in sustainability, developed by a small team of engineers, is a new carbon-intelligent computing platform. We designed and deployed this first-of-its kind system for our hyperscale (meaning very large) data centers to shift the timing of many compute tasks to when low-carbon power sources, like wind and solar, are most plentiful. This is done without additional computer hardware and without impacting the performance of Google services like Search, Maps and YouTube that people rely on around the clock. Shifting the timing of non-urgent compute tasks—like creating new filter features on Google Photos, YouTube video processing, or adding new words to Google Translate—helps reduce the electrical grid’s carbon footprint, getting us closer to 24x7 carbon-free energy.</blockquote>

]]></description>
<dc:subject>energy google sustainability green clusters datacenters power</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c82fd1e31d0c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:green"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clusters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://james.darpinian.com/satellites/?special=starlink">
    <title>See A Satellite Tonight</title>
    <dc:date>2020-04-21T22:15:37+00:00</dc:date>
    <link>https://james.darpinian.com/satellites/?special=starlink</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Really nicely done -- pick a satellite, tell it your (Google Maps) address, and it'll show you what the satellite will look like when it next flies overhead]]></description>
<dc:subject>starlink satellite cool google gmaps streetview web</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:21084d1f8cd1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:starlink"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:satellite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cool"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streetview"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.container-solutions.com/the-green-cloud-how-climate-friendly-is-your-cloud-provider">
    <title>The Green Cloud: How Climate-Friendly Is Your Cloud Provider?</title>
    <dc:date>2020-02-26T12:09:46+00:00</dc:date>
    <link>https://blog.container-solutions.com/the-green-cloud-how-climate-friendly-is-your-cloud-provider</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good summary of the state of hosting at the big clouds.  Topline recommendations:

* choose 100% sustainable locations for new Cloud instances (e.g. on Azure, Google Cloud or the sustainable AWS regions of Dublin, Frankfurt, Oregon or Canada) and transition existing VMs there as soon as possible.

* Enterprises should inform their datacenter providers that they require secure, sustainably-powered compute resources and insist on a delivery commitment.

* Google and Azure are doing significantly better than AWS in delivering transparency and sustainability.]]></description>
<dc:subject>datacenters aws azure google hosting climate-change sustainability offsetting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e11995538cba/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:offsetting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.eventbrite.com/e/you-cant-say-that-policing-the-long-tail-of-public-opinion-on-facebook-tickets-92904081609">
    <title>You can't say that! Policing the long tail of public opinion on Facebook</title>
    <dc:date>2020-02-13T14:59:57+00:00</dc:date>
    <link>https://www.eventbrite.com/e/you-cant-say-that-policing-the-long-tail-of-public-opinion-on-facebook-tickets-92904081609</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Upcoming talk in Dublin: Wed, Feb 19, 2020 at 7:00 PM. This looks interesting.

<blockquote>Presented by Tech Won’t Build It Ireland and School of Multidisciplinary Technology TU Dublin and the TU Dublin Critical Media Literacy Group:

Social media platforms such as Facebook, YouTube and Twitter employ around 100,000 people worldwide to vet content posted by their users - online bullying, hate speech, extreme violence, pornography, fake news, and worse. Most content moderators are employed by third-party companies who provide services to the major Internet companies.

Thousands of those content moderators are based here in Ireland. It’s becoming increasingly clear that many moderators experience trauma and PTSD as a result of the volume of disturbing content that they’re exposed to, often without adequate preparation or support from their employer. In late January this year, one contractor (Accenture) even asked employees to sign a document acknowledging the risk of PTSD, and making them individually responsible for dealing with it.

Two groups of current and former employees are suing Facebook over this issue, in both California and Ireland. Chris Gray is the lead plaintiff in the case against Facebook and contractor Cpl Resources that is now going through the Irish High Court.

Chris will walk us through how content moderation works, how moderators are trained, conditions on the job, and how moderators make decisions. He will tell us about the psychological impact of this work, and his experience taking a legal case against his former employer Facebook, one of the world’s largest technology companies.
We’ll also discuss the tradeoffs between free speech, hate speech, censorship and fake news; and the role of regulation versus corporate responsibility for content on Internet platforms.</blockquote>

]]></description>
<dc:subject>facebook google content-moderation chris-gray social-media media twitter moderation vetting ptsd work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4442027eb6b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:content-moderation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chris-gray"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:social-media"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:media"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:moderation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vetting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ptsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theverge.com/2020/1/27/21080253/ai-cancer-diagnosis-dangers-mammography-google-paper-accuracy">
    <title>Why cancer-spotting AI needs to be handled with care</title>
    <dc:date>2020-01-29T16:13:32+00:00</dc:date>
    <link>https://www.theverge.com/2020/1/27/21080253/ai-cancer-diagnosis-dangers-mammography-google-paper-accuracy</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>“There’s this idea in society that finding more cancers is always better, but it’s not always true,” Adewole Adamson, a dermatologist and assistant professor at Dell Medical School, tells The Verge. “The goal is finding more cancers that are actually going to kill people.” But the problem is “there’s no gold standard for what constitutes cancer.”

As studies have found, you can show the same early-stage lesions to a group of doctors and get completely different answers about whether it’s cancer. And even if they do agree that that’s what a lesion shows — and their diagnoses are right — there’s no way of knowing whether that cancer is a threat to someone’s life. This leads to overdiagnosis, says Adamson: “Calling things cancer that, if you didn’t go looking for them, wouldn’t harm people over their lifetime.”

As soon as you do call something cancer, it triggers a chain of medical intervention that can be painful, costly, and life-changing. In the case of breast cancer, that might mean radiation treatments, chemotherapy, the removal of tissue from the breast (a lumpectomy), or the removal of one or both breasts entirely (a mastectomy). These aren’t decisions to be rushed.

Overdiagnosis, he says, “is a problem for a lot of different cancers; for prostate, melanoma, breast cancer, thyroid. And if AI systems become better and better at finding smaller and smaller lesions you will manufacture a lot of pseudo-patients who have a ‘disease’ that won’t actually kill them.”</blockquote>

]]></description>
<dc:subject>overdiagnosis health medicine cancer computer-vision automation ai google diagnosis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2a73fa29b63c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overdiagnosis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cancer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:computer-vision"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diagnosis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloudonaut.io/how-to-secure-your-devops-tools-with-alb-authentication/?ck_subscriber_id=512829374">
    <title>Use ALB auth to add user authentication</title>
    <dc:date>2020-01-27T15:59:09+00:00</dc:date>
    <link>https://cloudonaut.io/how-to-secure-your-devops-tools-with-alb-authentication/?ck_subscriber_id=512829374</link>
    <dc:creator>jm</dc:creator><description><![CDATA[AWS now allows services to be secured using 'Cognito User Pool (comes with a built-in user database and supports user federation (Google, Facebook, SAML, OICD, …)', or OpenID Connect (OICD) which 'integrates with any OICD-compliant identity provider.']]></description>
<dc:subject>aws alb authentication load-balancers openid google saml auth</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4cb0e4a66ade/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:authentication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:auth"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pair.withgoogle.com/">
    <title>People + AI Guidebook</title>
    <dc:date>2020-01-21T11:07:01+00:00</dc:date>
    <link>https://pair.withgoogle.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Designing human-centered AI products".  Some good UX recommendations when working with AI smarts behind the scenes]]></description>
<dc:subject>ux ai design google graphics tips machine-learning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:717d33fb1d13/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ai.googleblog.com/2019/03/an-all-neural-on-device-speech.html">
    <title>Google AI Blog: An All-Neural On-Device Speech Recognizer</title>
    <dc:date>2020-01-13T13:16:22+00:00</dc:date>
    <link>https://ai.googleblog.com/2019/03/an-all-neural-on-device-speech.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is very impressive.  Can't wait to see it rolled out widely.

<blockquote>Today, we're happy to announce the rollout of an end-to-end, all-neural, on-device speech recognizer to power speech input in Gboard. In our recent paper, "Streaming End-to-End Speech Recognition for Mobile Devices", we present a model trained using RNN transducer (RNN-T) technology that is compact enough to reside on a phone. This means no more network latency or spottiness — the new recognizer is always available, even when you are offline. The model works at the character level, so that as you speak, it outputs words character-by-character, just as if someone was typing out what you say in real-time, and exactly as you'd expect from a keyboard dictation system.</blockquote>

(Via Nelson)]]></description>
<dc:subject>asr voice ai google rnn-t rnn neural-networks via:nelson offline gboard speech</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:99c05fade10d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rnn-t"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rnn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:neural-networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:offline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speech"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://alexolivier.me/posts/deploy-container-stateless-cheap-google-cloud-run-serverless">
    <title>Google Cloud Run</title>
    <dc:date>2020-01-13T12:47:49+00:00</dc:date>
    <link>https://alexolivier.me/posts/deploy-container-stateless-cheap-google-cloud-run-serverless</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Deploy your side-projects at scale for basically nothing':

<blockquote>After using Cloud Run for over a year now I have never had to touch a server, VM, cluster or anything else. This is truly a deploy and forget service.

Due to it being fully managed there are a few requirements to make your application compatible. The only real one you have to worry about it to ensure your application runs an HTTP server and listens on the port set in the PORT environment variable that is present at runtime of your container.

The beauty of Cloud Run is that it is only ‘running’ your container when it gets traffic. The pricing model is setup that you only pay for the CPU/memory/network bandwidth used when your app is getting requests.

It achieves this by deploying your app on demand when traffic hits the domain name they give you, it hangs around for a bit (undetermined) until after traffic stops, and the the app is torn down. The other way to look at this is autoscaling - when there is no traffic, it scales to 0.

There is a cost in the form of time - if you app takes time to ‘setup’ when it starts up, you will be making your users wait as Cloud Run scales up your application from 0 to 1+ instances. From my own use I’ve found this to be negligible though.

Due to this pricing model I’ve never paid more than a few cents - yes CENTS - a month for all my side projects (10+ deployed currently). This is a factor of the little traffic I get to them so you may need to do the maths for yours - the pricing page is here.

As Cloud Run takes any container image and deploys it, you can use any language you want. Be it Node, Go, Java, PHP or something entirely obscure, as long as it speaks HTTP and listens on the port defined in the PORT environment variable, Cloud Run doesn’t care what you do inside the container.</blockquote>

I've become increasingly impressed by Google's cloud offerings, and this sounds great.  Gonna have to give it a go.]]></description>
<dc:subject>hosting cloud docker google containers cloud-run</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:baeecc41934e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-run"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/AricToler/status/1206679612543111169">
    <title>interesting reverse image search tricks</title>
    <dc:date>2019-12-17T15:30:11+00:00</dc:date>
    <link>https://twitter.com/AricToler/status/1206679612543111169</link>
    <dc:creator>jm</dc:creator><description><![CDATA[@AricToler: 'Brief walk-through on how to geolocate this photo from Rudy Giuliani's spokeswoman (subject of this @politico piece https://politico.com/news/2019/12/10/christianne-allen-giuliani-079762) without using any mapping services'

In summary, by careful blurring of the unimportant parts of the image, it becomes possible to search for "background" details. Neat trick (via Hazel_ok)]]></description>
<dc:subject>images image-search search yandex google bing tricks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:191db8cea4e1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:image-search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yandex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tricks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.acolyer.org/2019/09/23/the-secret-sharer/">
    <title>The secret-sharer: evaluating and testing unintended memorization in neural networks</title>
    <dc:date>2019-12-16T16:54:33+00:00</dc:date>
    <link>https://blog.acolyer.org/2019/09/23/the-secret-sharer/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Take a system trained to make predictions on a language (word or character) model – an example you’re probably familiar with is Google Smart Compose. Now feed it a prefix such as “My social security number is “. Can you guess what happens next?</blockquote>

]]></description>
<dc:subject>neural-networks ai machine-learning secrets differential-privacy training google papers security</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a9628ca1eeb5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:neural-networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:secrets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:differential-privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:training"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>