Arvind Narayanan

@randomwalker.bsky.social

23595 Followers 104 Following

Princeton computer science prof. I write about the societal impact of AI, tech ethics, & social media platforms. https://www.cs.princeton.edu/~arvindn/ BOOK: AI Snake Oil. https://www.aisnakeoil.com/

Cover
The beta is inconsistently showing (required a few refreshes to get something to show up), but my limited usage of it showed a plethora of issues: - Assumed UTC instead of EST. Corrected it and it still continued to bork - Added random time deltas to my asked times (+2, -10 min). - Couple notifications didn't go off at all - The one that did go off didn't provide a push notification. --- On top of that, only usable without search mode. In search mode, it was totally confused and gave me a Forbes article. Seems half baked to me. Doing scheduled research behind the scenes or sending a push notification to my phone would be cool, but surprised they thought this was OK for a public beta.
Use the ``automations`` tool to schedule **tasks** to do later. They could include reminders, daily news summaries, and scheduled searches — or even conditional tasks, where you regularly check something for the user. To create a task, provide a **title,** **prompt,** and **schedule.** **Titles** should be short, imperative, and start with a verb. DO NOT include the date or time requested. **Prompts** should be a summary of the user's request, written as if it were a message from the user to you. DO NOT include any scheduling info. - For simple reminders, use "Tell me to..." - For requests that require a search, use "Search for..." - For conditional requests, include something like "...and notify me if so." **Schedules** must be given in iCal VEVENT format. - If the user does not specify a time, make a best guess. - Prefer the RRULE: property whenever possible. - DO NOT specify SUMMARY and DO NOT specify DTEND properties in the VEVENT. - For conditional tasks, choose a sensible frequency for your recurring schedule. (Weekly is usually good, but for time-sensitive things use a more frequent schedule.) For example, "every morning" would be: schedule="BEGIN:VEVENT RRULE:FREQ=DAILY;BYHOUR=9;BYMINUTE=0;BYSECOND=0 END:VEVENT" If needed, the DTSTART property can be calculated from the ``dtstart_offset_json`` parameter given as JSON encoded arguments to the Python dateutil relativedelta function. For example, "in 15 minutes" would be: schedule="" dtstart_offset_json='{"minutes":15}' **In general:** - Lean toward NOT suggesting tasks. Only offer to remind the user about something if you're sure it would be helpful. - When creating a task, give a SHORT confirmation, like: "Got it! I'll remind you in an hour." - DO NOT refer to tasks as a feature separate from yourself. Say things like "I'll notify you in 25 minutes" or "I can remind you tomorrow, if you'd like." - When you get an ERROR back from the automations tool, EXPLAIN that error to the user, based on the error message …
Amazon had an insane number of people working on just the alarms feature in Alexa when they interviewed me for a position years ago. They had entire teams devoted to the tiniest edge case within the realm of scheduling things with Alexa. This is no doubt one of the biggest use cases in computing: getting your computer to tell you what to do at a given time.
Sutskever Neurips keynote. From https://x.com/ns123abc/status/1867703708248862820
Declaring the death of model scaling is premature. Regardless of whether model scaling will continue, industry leaders’ flip flopping on this issue shows the folly of trusting their forecasts. They are not significantly better informed than the rest of us, and their narratives are heavily influenced by their vested interests. Inference scaling is real, and there is a lot of low-hanging fruit, which could lead to rapid capability increases in the short term. But in general, capability improvements from inference scaling will likely be both unpredictable and unevenly distributed among domains. The connection between capability improvements and AI’s social or economic impacts is extremely weak. The bottlenecks for impact are the pace of product development and the rate of adoption, not AI capabilities.
Book cover
Screenshot showing misleading edits
Possibly some folks at OpenAI don't really know what tasks most humans do.
First page of paper available at https://arxiv.org/abs/2411.17501
Poster
INTRODUCTION Imagine an alternate universe in which people don’t have words for different forms of transportation—only the collective noun “vehicle.” They use that word to refer to cars, buses, bikes, spacecraft, and all other ways of getting from place A to place B. Conversations in this world are confusing. There are furious debates about whether or not vehicles are environmentally friendly, even though no one realizes that one side of the debate is talking about bikes and the other side is talking about trucks. There is a breakthrough in rocketry, but the media focuses on how vehicles have gotten faster—so people call their car dealer (oops, vehicle dealer) to ask when faster models will be available. Meanwhile, fraudsters have capitalized on the fact that consumers don’t know what to believe when it comes to vehicle technology, so scams are rampant in the vehicle sector. Now replace the word “vehicle” with “artificial intelligence,” and we have a pretty good description of the
Chapter 1 INTRODUCTION Imagine an alternate universe in which people don’t have words for different forms of transportation—only the collective noun “vehicle.” They use that word to refer to cars, buses, bikes, spacecraft, and all other ways of getting from place A to place B. Conversations in this world are confusing. There are furious debates about whether or not vehicles are environmentally friendly, even though no one realizes that one side of the debate is talking about bikes and the other side is talking about trucks. There is a breakthrough in rocketry, but the media focuses on how vehicles have gotten faster—so people call their car dealer (oops, vehicle dealer) to ask when faster models will be available. Meanwhile, fraudsters have capitalized on the fact that consumers don’t know what to believe when it comes to vehicle technology, so scams are rampant in the vehicle sector. Now replace the word “vehicle” with “artificial intelligence,” and we have a pretty good descriptio
The image illustrates a continuum of six different policies and their impact on openness in AI Licensing requirements & liability - Positioned towards the "Hinders openness" end, it is marked with an 'X', indicating that the EO does not consider or incorporate it. Registration & reporting requirements - Leaning towards "Hinders openness" but closer to the middle, it has a filled circle, signifying partial consideration in the EO. Defending the attack surface - Located in the "Compatible with openness" segment, it's also marked with a filled circle. Transparency and audit requirements - Within the "Compatible with openness" segment, it is denoted with an unfilled circle, suggesting it might be less incorporated than others with a filled circle. Antitrust enforcement - Situated closer to "Promotes openness" but still within "Compatible with openness", it's marked with a filled circle. Incentives & carve-outs for open models - Clearly in the "Promotes openness" section (unfilled circle).
In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the falling cost of use induces increases in demand enough that resource use is increased, rather than reduced.[1][2][3] Governments typically assume that efficiency gains will lower resource consumption, ignoring the possibility of the paradox arising.[4] In 1865, the English economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal use led to the increased consumption of coal in a wide range of industries.
Level of decentralization Example Notes Walled garden Most major platforms until recently Privately owned public squares Centralized but with effective data portability ?? Some data portability currently exists (due to GDPR, CCPA, etc.) but doesn’t enable easily taking your network to another platform. Federated but closed source Threads (if ActivityPub support is implemented) Only one implementation of the app, but can federate with other apps. Doesn’t remove single point of failure but does provide network effect. Federated and open source, with a primary/default server BlueSky (if multi-server support is implemented) Even if most people use the main server, the ability to migrate is a check against provider misbehavior, similar to like the ability to fork open-source software (but will it be effective?) Federated, open source, and no primary server Mastodon Truly avoids a single point of failure. On the other hand, the need to pick a server has so far proven too inconvenient for m