Yahoo! Groups

From Archiveteam
Jump to navigation Jump to search
Yahoo! Groups
Yahoo! Groups logo
Groups-yahoo-com.png
URL https://groups.yahoo.com/
Status Offline
Archiving status Partially saved
Archiving type Unknown
Project source yahoogroups-grab, yahoo-group-archiver
Project tracker yahoogroups, yahoo-groups-api
IRC channel #yahoosucks (on hackint)
Data[how to use] archiveteam_yahoogroups

Yahoo! Groups was Yahoo!'s combination mailing list service/web forum, the result of the acquisition of eGroups and some other Yahoo! stuff. In addition to archives of and a web interface for mailing lists, it offered file uploads, photo uploads, links, polls, and an events calendar. It had been stable since the late 90s, long enough for some specialised software to be developed to do backups of it. (Not many other websites can say that.) It was shuttered in stages over the course of 2019–2020.

Uploading of new content was disabled 2019-10-28, and all content, including message history, was made unavailable on 2019-12-14.[1] Group content was hidden from the web interface by 2019-12-21. After negative media attention, Yahoo announced that they were extending the deadline for users to use their official "GetMyData" export tool (which missed a plethora of attachments, databases, polls, photos, and metadata) to 2020-01-31.[2][3] They stopped accepting GMD requests on 2020-02-04.

Groups continued to function solely as mailing lists for a short period. However, the creation of new groups was disabled on 2020-10-12, and the web interface and mailing lists were shut down on 2020-12-16.[4]

Group admins and members, please see Yahoo! Groups/Archiving Project FAQ for group members or join IRC if you have questions.

The state of preservation

Yahoo Groups provenance.png

Summary

The remnants of Yahoo Groups information is split among several pieces, some of which are uploaded to IA, some of which will hopefully be publicly uploaded in the future, and some of which are not suitable to be made public and will presumably be kept darked or otherwise restricted on IA. The difficulty of sorting out group data between the last two categories is the chief obstacle to uploading what we have. There are also some privacy-ok files that never got uploaded, some of which we have, but some of which we have been unable to locate.

The ArchiveTeam capture of Yahoo groups took place in 4 parts:

Additionally, we worked closely with a "fandom project" that made its own GetMyData capture - which has already been shared with us insofar as is going to be shared - and received a few miscellaneous archived mailed in from various people.

Group Publicity

From our standpoint a group could be in one of the following categories with respect to privacy:

  • Public groups.
  • Groups we requested to join, whose join request was still pending and had not yet expired. (Obviously there are none of these left, but for reasons explained below this stage is of great importance.)
  • Groups we requested to join and got accepted to, either manually or automatically. ("Actively accepted")
  • Groups we requested to join and got rejected from ("Actively denied" or "denied")
  • Groups we requested to join, where the join request languished and expired after 2 weeks. ("Expired", "passively denied", or "timed out")

In any of the latter 3 cases the account requesting to join got an email. The privacy difficulty we have had with the GetMyData-derived archives arises from two points:

  • Many accounts used for that stage of the project were accounts at mail.com, which automatically deletes mailboxes after a period of inactivity, meaning the accept/deny/expire emails got deleted before we could gather them.
  • GetMyData incorrectly sent out GetMyData archives of groups to accounts that were in the "pending" stage of joining them.

The GetMyData process

After Yahoo closed the normal Groups interface as well as the API, there was only one avenue to continue to get information from it: "GetMyData", a process intended for people who were already in groups to get relevant records. ArchiveTeam, and parallel to it the fandom project, exploited this in order to try to get better coverage. "Get My Data files are a set of .zip files up to 2GB each. Each one has a variable number of groups in them (however many would fit in the 2GB). Each group has a messages .zip file with a number of .mbox files, a files .zip file with a backup of the group's file section, and a links .zip file with the group's links section. Yahoo unfortunately didn't bother sending other data in most cases, like attachments and photos, unless it was something the user requesting the backup personally posted".[5]

"The way Yahoo implemented their Get My Data utility, you would get backups for any group you were a member of and any group for which you had a pending request to join. So, we would occasionally get back data for groups that later actively denied the join request, and we would quite commonly get back data for groups that never responded, given that most groups were abandoned by 2019. This behavior was extremely consistent and applies to all private groups".[6]

Yahoo Groups

Forum/mailing list host that shut down in a process spanning late 2019 to early 2020.

2015-2018 API grab

Scrape of the Yahoo Groups API. Led, or perhaps done entirely, by PurpleSym. There is one WARC file per group, and several group-WARCs per IA item. The items are located in the IA collection archiveteam_yahoogroups, and are distinguishable from everything else in that collection by their upload date not later than 2018, and by their thumbnails being a photo of a "Yahoo!" sign (with the exception of something else from about 2 years later). Although they are in WARC format, they seem to use the resource record-type with synthetic URIs, meaning they will not work in the Wayback Machine.

Doranwen's metadata upload

An IA item located here created by the fandom project's Doranwen. Contains tables of group metadata, parsed from the 2015-2018 API grab and from their GetMyData collection.

Fandom GetMyData, not shared

Groups from the fandom project's GetMyData effort which were either "actively denied" or originated outside the normal GMD process, such as by a group member sending it to them. This also includes GMDs made by the fandom project on behalf of members of private groups, which it retains only as a backup in case the member loses their copy.[7] These have been kept with the fandom project.

Fandom GetMyData, shared

Groups from the fandom project's GetMyData effort which it decided were public enough to send to us, namely those which were public, accepted/approved, and "accepted" through the Groups permissions bug, as well as GMDs sent in by outside people to the fandom project[7]. A copy of these were sent to lennier1.

Fandom GetMyData

The fandom project conducted its own effort to collect GetMyData archives. Some of these the fandom project, acting by its own standards, has kept entirely private; some it has given to us. There was some overlap in Yahoo accounts (AKA IDs) with ArchiveTeam, possibly leading to mixing of data with our GetMyData process. [8]

2019 normal webpage grab

A regular, DPoS attempt at a grab of the Yahoo Groups website. As with many DPoS projects, navigation is somewhat broken in the WBM, but it does play back.[9]. Nonetheless the closest thing to sanity of any of the archiving attempts.

The repository is at ArchiveTeam/yahoogroups-grab. The data is on IA, in archiveteam_yahoogroups, prefixed simply by "Archive Team Yahoo! Groups", e.g. archiveteam_yahoogroups_20191214012211_24a04e36.

Combined GetMyData possessed by lennier1

A collection of GetMyData output files currently held by lennier1 and not uploaded anywhere. Contains the results from the ArchiveTeam GetMyData effort, as well as what the fandom project was willing to share with us. This with the addition of the data the fandom project didn't share with us would become the contents of Doranwen's GetMyData holdings.

Not all this data can be made public. A bug in Yahoo groups allowed execution of GetMyData on any restricted group merely by applying to join it, before being accepted or rejected. Additionally some of these files "were contributed by people who were ok making some groups (or data types) public but not others"[10]. As such the plan is to separate this out into a public segment and a darked segment before uploading both to IA.

Public ArchiveTeam GMD upload

A planned IA upload of GetMyDatas from the ones ArchiveTeam possesses, after it is sorted out which ones are public and private. As more than one group could fit into a GetMyData zip presumably the raw files we recieved cannot be uploaded; rather it will be necessary to extract the individual groups.

Darked ArchiveTeam GMD upload

A planned IA upload of GetMyDatas from the ones ArchiveTeam possesses, after it is sorted out which ones are public and private. Presumably just the zip files, but "darked", i.e. inaccessible to everything but privileged IA accounts (employees, and knowing them probably some other people as well).

PGOffline etc.

"[M]iscellaneous stuff like PGOffline data and people running the archiving program manually" sent into us, currently not uploaded, and held by lennier1. Presumably to be uploaded. As PGOffline did not suffer from the permissions bug presumably these are sufficiently privacy-safe.[11]

Upload of PGOffline to IA

Planned upload of data from PGOffline and other miscellaneous sources to IA.

Combined GetMyData posessed by Doranwen

Combination of the fandom project's public-access-ok and public-access-not-necessarily-ok GetMyData sets, as well as the ArchiveTeam one. This is the most comprehensive GetMyData collection there is; lennier1 has a version without the no-public access material. It appears this is eventually to be split up into a fairly processed public upload as well as a non-public set.

ArchiveTeam GetMyData

GetMyData archives collected by ArchiveTeam. Volunteers signed up for groups and then made GetMyData requests on the accounts; the results came by email, where they were sent to Marked. These are currently held by lennier1.

Doranwen's organized upload

The planned upload, by the fandom project leader Doranwen, of the GetMyData archives they possess, and wish to make public by their criteria (presumably a subset of what they've given to us). Much of the discussion in #yahoosucks in 2021 and 2022 has concerned cleaning up and categorizing this data, hence this page's label of it as "organized".

Private groups kept by Doranwen

The subset of the GetMyData archives possessed by Doranwen/the fandom project that they do not want to be made public. Indications are that these will be kept with people personally in perpetuity.

2019 API grab

Technically unusual Seesaw/tracker/DPoS project written and led by Marked to get data from the Groups API after the normal interface, and with it the DPoS project that gathered from it, had shut down. The GitHub repository is here. Marked has said that, of the data produced by this, "1/3 is in australia, 1/3 with me, and 1/3 on IA"[12]. As of September 2022 neither of the first two parts have been uploaded.

2019 API grab, portion with marked

Of the data from the 2019 API grab, "1/3" was with Marked. At some point between late 2020 and late 2022 this made its way to lennier1.

2019 API grab, portion with lennier1

Marked's 1/3 of the 2019 API grab data, sent to lennier1. Not yet uploaded; will hopefully be sent to IA eventually.

2019 API grab, portion on IA

Of the data from the 2019 API grab, "1/3" had been uploaded to IA in early 2020, and as of September 2022 that portion has remained unchanged. It is intended that the third originally with Marked and sent to lennier1, and if it can be located the third "in australia", be merged into this. These can be found in archiveteam_yahoogroups as items prefixed by "archiveteam_yahoogroups_api", e.g. archiveteam_yahoogroups_api_20191217011957_8a14e083.

2019 API grab, portion "in australia"

Of the data from the 2019 API grab, "1/3" was, per a few enigmatic remarks from Marked, "in australia". "[T]here was a volunteered target in Australia, I forgot their username atm"[13]. We have been unable to determine who this was, except that it seems unlikely to have been Kiska.

Submitting group data to the public archive

Were you a member of a public group (one that did not require administrator approval to join)? Were you an admin of a private group whose members consent to be part of the public archive? Did you save the group yourself, using GetMyData or any other method?

If so, we'd love to have your archives. Upload to a fileshare such as WeTransfer, Dropbox, Google Drive, or Mega.nz and email us a link.

Feel free to remove data which should remain private (such as private groups in mixed public/private GetMyData results, or message history from private groups whose members wish to make only files and photos public) before sending us a copy.

However, try to make sure the data is otherwise unmodified! In particular, there may be old malware in GMD ZIP files. Modern email software and operating systems are expected to be resistant to this old malware, but some antivirus software may see it and attempt to modify or delete the ZIP file. Please be careful of this!

Project history

Data collection for this project is over. Yahoo! Groups content is now inaccessible; although we continue to accept individual archives made by group members and admins, we can no longer archive additional groups.

While the project was active, volunteers could help in the following ways:

Nominating non-private groups for archival

Groups could be nominated for archival using this form. This was not used for groups that required administrator approval to join.

Submitting private groups for public archival

Administrators could request that their private group (we considered a private group to be one that required administrator approval of new members) be included in the public archive. We requested admins to ensure that the members of the group were happy about being part of the public archive.

To submit a group for archival, admins could send a membership invite to the email archiveteamprivateyahoogroup@gmail.com (without selecting the "Add only to mailing list" option). We monitored that email regularly to accept any membership requests we received, and scheduled the group for archival once our Yahoo account was a member.

Joining groups and submitting data

We used an extension for Chromium-based browsers to partially automate the process of joining groups (at first since some groups only made message history visible to members, and later because after the closure of the web interface GetMyData was the only way to access group content). There was at one time a leaderboard.

Volunteers who joined groups also made GetMyData requests from the accounts they used to join groups (in some cases, multiple requests, if they received results in time to continue joining groups or not all groups were included in the initial result). GMD requests could take up to 10 days to be processed; results were split into 2 GB ZIP files.

GMD results were emailed or rsynced to ArchiveTeam.

Private groups of interest

numberactivation (see all the press coverage; FOI request). Some external lists: List of groups with Fanlore pages (contains both private and public groups), Archive Trans Yahoo's list (all private at last check), Archive South Asian American Yahoo Groups (all public), and Queer Digital History Project (no groups listed, presumably all private).

Statistics

As of 2019-10-16 the directory lists 5619351 groups. 2752112 of them have been discovered. 1483853 (54%) have public message archives with an estimated number of 2.1 billion messages (1389 messages per group on average so far). 1.8 billion messages (86%) have been archived as of 2018-10-28.

The following graphs are slightly outdated:

Yahoo groups date created.png Yahoo groups messages per group.png Yahoo groups post date.png

Site structure

There was a convenient JSON API, most endpoints of which are now down. Some endpoints require logged-in group membership or other permissions (depending on group settings).

Groups

- Known params: maxHits, offset, query, sortBy (values: OLDEST, RELEVANCE, MEMBERS, LATEST_ACTIVITY, NEWEST)
- Known params: start, intlCode (au, in, sg, uk, us; ar, e1, es, mx; br; cf, fr; de; hk; it...)
- Pagination: Page size is 10. Does not have a count param. start is the result index, not the group id. start values 500 and up all return the same set of results.
Groups are listed in fixed but arbitrary order. /0/ is a special value that shows the root node; subcategories can be accessed by using the subcategory id instead (the full "idList" value is not required).
Defaults to the US view of the English directory tree. Different languages have different directory trees. Supplying a different intlCode parameter (list not exhaustive, must be lower case) accesses the corresponding view of the appropriate language's tree. Subcategory ids are language-specific and must be used with an appropriate intlCode. The intlCode -> language mapping may be checked at the /0/ endpoint; the root "name" is always "ROOT", but "id" is language-specific.[14] Different intlCode views of the same language list groups in a different order, may have slightly different category names, and appear to have slightly different numbers of categories in the full tree; their group overlap is about 99%.
The "count" field appears totally inaccurate.

Messages

- Known params: count, start, sortOrder (ASC, DESC), direction (1, -1)
- Pagination: Page size defaults to 10, with no known limit. start is the message id, not the result index. sortOrder adjusts the order of results in the json response's array, whereas direction determines which way to iterate through ids from start (default: DESC, -1).
Original email is largely recoverable from rawEmail field.
Message headers and textual body parts have email addresses redacted, with the hosts replaced with "...". For example, "From: ceo@ford.com" and "From: ceo@toyota.com" both get turned into "From: ceo@..." Some addresses may not have been redacted correctly.
Some messages may have encoding issues.[15] Sometimes (as in the linked case) the non-raw endpoint has the correct characters, sometimes it does not; this is likely related to the originating email client. Removing non-ASCII characters and ^M characters from the 7-bit text should result in valid RFC822 emails.
Some emails longer than 64kb (minus attachments) may be truncated. This truncation affects not just plain text, but also HTML and encoded Base64 content. Deleting the string "\n(Message over 64 KB, truncated)" from the end of the message part may help prevent parser breakage.
All attachments are separated, with attachment bodies replaced with the string "[ Attachment content not displayed ]". Recovering the emails involves finding those MIME parts, looking at the filenames, comparing with the list of filenames listed in the "attachmentInfo" section, matching on similarity, and replacing the contents with the downloaded attachments. In very rare cases where a matching MIME section isn't found, it may be necessary to append those attachments as new MIME attachments to the email while reconstructing.
- Known params: ts, tz, chrome
- Redundancy: Generatable from /messages data.

Topics

- Known params: count, startTopicId, sortOrder (ASC, DESC), direction (1, -1)
- Pagination: Page size defaults to 25, with a limit of 100. sortOrder and direction as for messages.
- Known params: maxResults.
- Pagination: Page size defaults to 30 (messages in topic), with no known limit (maximum tested: 57). No known start param.
- Redundancy: Generatable from /messages data.
"messages" field is an array, each element of which seems to have the same contents as the corresponding /message/<id>/ (non-raw) endpoint; metadata ("totalMsgInTopic", "prevTopicId", "nextTopicId") could be reconstructed. Not known whether a message can fail to be associated with any topic.

Attachments

- Known params: count, start, sort (TITLE, TIME), order (ASC, DESC)
- Pagination: Page size defaults to 20, with no known limit (maximum tested: 93).

Attachment may be of several types: photo, file, ...?

Files

- Known params: sfpath (pass in a pathURI to retrieve the file listings of this subdirectory)
- Pagination: None.
Entries with "type" 0 are files; 1, directories.

Photos

- Known params: count, start, orderBy (MTIME), sortOrder (ASC, DESC), ownedByMe (TRUE, FALSE), lastFetchTime, photoFilter (ALL, PHOTOS_WITH_EXIF "Originals", PHOTOS_WITHOUT_EXIF "Shared")
- Pagination: Page size defaults to 20, with no known limit.
"totalPhotos" field in response gives total in group.
- Known params: count, start, albumType (PHOTOMATIC, NORMAL), orderBy (MTIME, TITLE), sortOrder (ASC, DESC)
- Pagination: Page size defaults to 12, with no known limit.
albumType defaults to NORMAL. PHOTOMATIC albumType requires the "READ" permission for "ATTACHMENTS". "total" field in response gives total number of albums of the selected type in group; however, this seems to have an off-by-one error for the NORMAL type of albums.
- Known params: similar to /photos and /albums endpoints, with additional ordinal sortOrder option
Photomatic albums must be loaded with the albumType parameter set to PHOTOMATIC.

Links

- Known params: linkdir
- Pagination: None.
linkdir takes the folder parameter from a dir. Nested folders should be joined with '/'. You need to keep track of the path to a given folder yourself (eg, linkdir + '/' + folder).

Polls

- Known params: count, start
- Pagination: Page size defaults to 10, with no known limit. There is no "total" field in the response.
Polls return all votes cast, non-anonymised, including identifying metadata for all viewers.

Databases

- Pagination: None.
- Known params: format (CSV, TSV)

Members

- Known params: count, start, sortBy, sortOrder, ts, tz, chrome
- Pagination: Page size defaults to 10, with a limit of 100. No known limit on total results.
May be blocked for normal members (as may all the other members endpoints). Includes moderators and bouncing members, with identifying metadata.
Very often (always?) blocked for normal members.
Very often (always?) blocked for normal members.

Events

Overlaps with Yahoo Calendar API, check yahoo-group-archiver code.

Software for archiving groups

Python

  • yahoo-group-archiver scraped a group using the JSON API and (for private endpoints) the two cookies Yahoo uses to verify a logged-in user. Optionally, it could produce WARCs. ArchiveTeam's preferred tool and fully featured at the time of closure.
    • Yahoo Group Archive Tools (a Perl script) converts yahoo-group-archiver output into clean rfc822 and mbox files, with separated attachments correctly reattached, and many Yahoo truncation/redaction bugs corrected. It also turns list archives into PDF, using email2pdf, which many non-technical list owners prefer.
  • YahooGroups-Archiver is similar, but scraped only messages (not files or any other data). It has been deprecated in favor of the above.
  • yahoo-groups-backup scraped a group's messages and files (but not any other data) using Selenium, storing message info and metadata (both rendered message body and raw email) into a Mongo database. It also provides a script to dump its data to static HTML pages that can be viewed in the browser.

Other

  • PGOffline: Windows, proprietary. 14-day free trial, after which download and export is disabled (but view still works). Included attachments. Stores data in a SQLite database internally.
    • pgo2mbox converts PGOffline pg4 files to mbox.
  • Yahoo Messages Export: Chrome extension. Messages only. Saves as mbox.
  • Yahoo Group Archiver: Perl, defunct.

Software for viewing archives (in mbox format)

Other archiving efforts

External Links

Coverage

References

  1. https://web.archive.org/web/20201126125219/https://help.yahoo.com/kb/groups/SLN31010.html
  2. https://www.theverge.com/2019/12/10/21004883/yahoo-groups-extend-deadline-download-data-date-time[IAWcite.todayMemWeb]
  3. https://twitter.com/YahooCare/status/1204312076379926528[IAWcite.todayMemWeb]
  4. https://help.yahoo.com/kb/groups/SLN35505.html[IAWcite.todayMemWeb]
  5. #yahoosucks, September 2022, two messages merged together here
  6. #yahoosucks, September 2022, two messages merged together here
  7. 7.0 7.1 #yahoosucks, October 2022, "OrIdow6: The only part of that that..."
  8. #yahoosucks, September 2022, search "i am sure that at least some ids whose info"
  9. "(even the 'html' yahoogroups-grab", parenthesis and single quotes in original, #yahoosucks, September 2022
  10. #yahoosucks, September 2022
  11. #yahoosucks, "The API archiving program...", September 2022
  12. Quoted by thuban in #yahoosucks September 2022; timestamp indicates Marked originally sent this in March 2020
  13. #yahoosucks, June 2021
  14. This id can also be accessed with an appropriate intlCode, but contains the same twelve groups for all languages: the groups in the categories for musical artists "Roots, The" and "Rusted Root", three groups which appear to be Yahoo tests, and one group which appears to be a spam test.
  15. https://yahoo.uservoice.com/forums/209451-us-groups/suggestions/9644478-displaying-raw-messages-is-not-8-bit-clean