Remove PlatformSection component from Native docs (#8746)

src/platform-includes/configuration/tags/defining-is-easy/native.mdx

@@ -0,0 +1 @@
+Defining tags is easy, and will bind them to the [current scope](../scopes/) ensuring all future events within scope contain the same tags.

src/platform-includes/debug-file-formats-mach-o-dsym/native.mdx

@@ -0,0 +1,123 @@
+## Mach-O and dSYM
+
+Executables, dynamic libraries and debug companions on all Apple platforms use
+the _Mach Object_, or short _Mach-O_, container format. This applies to iOS,
+iPadOS, tvOS, watchOS, macOS, and visionOS.
+
+- **Executables** do not carry a file extension. For desktop applications, they
+  are often placed in app bundle structures with the `.app` suffix. Unless
+  stripped manually, executables contain unwind information and a symbol table.
+  Debug information is never stored in executables.
+
+- **Dynamic Libraries** use the `.dylib` extension, and otherwise behave exactly
+  the same as executables.
+
+- **Debug Companions** are placed in a folder structure with the `.dSYM`
+  extension, and are located at `<name>.dSYM/Contents/Resources/DWARF/<name>`.
+  They usually contain a symbol table and debug information, but rarely unwind
+  information.
+
+When building an application with Xcode or with the `clang` compiler, debug
+information is automatically placed in a dSYM file. When linking manually,
+however, the dSYM file must be created using the following command:
+
+```bash
+dsymutil /path/to/output[.dylib]
+```
+
+## Executable and Linkable Format (ELF)
+
+On Linux distributions, executables and debug information are stored in _ELF_
+containers. Unlike other platforms, there is no dedicated container or specifier
+for debug companion files.
+
+Debug information is part of the binary (executable or library) and stripped
+when generating release builds due to their size. However, there is a way to
+retain them in a separate file (either in a different location or with `.debug`
+extension):
+
+```bash
+# There is an executable called "binary" in the CWD
+objcopy --only-keep-debug binary binary.debug
+objcopy --strip-debug --strip-unneeded binary
+objcopy --add-gnu-debuglink=binary.debug binary
+```
+
+This results in the following structure:
+
+- **Executables** do not carry a file extension. If stripped like above,
+  executables contain a symbol table, but no debug information. If the build
+  run omits frame pointers, unwind information will also be retained. Both can
+  be further stripped using flags like `--strip-all`.
+
+- **Shared Libraries** use the `.so` extension, and otherwise behave exactly
+  the same as executables.
+
+- **Debug Companions** do not carry a standard file extension, but are often
+  named `.debug`. If stripped like above, these files contain unwind
+  information, debug information and a symbol table.
+
+Shared libraries installed via package managers usually provide their debugging
+information in separate `*-dev` packages and put it in locations like
+`/usr/local/debug/...`. To receive symbolicated stack traces from those
+libraries, make sure to also upload their symbols in addition to your app’s
+symbols.
+
+ELF supports the compression of debug information which can significantly reduce
+the time required to upload debug information files to Sentry and thus improve
+build times. `gcc` (version 5 or newer) and `clang` (version 5 or newer) support
+this by passing the `-gz` flag to both the compiler and linker. The common way
+to compress debug information, however, is when stripping the executable:
+
+```bash
+# Note the --compress-debug-sections option
+objcopy --only-keep-debug --compress-debug-sections=zlib binary binary.debug
+```
+
+This can be verified by checking for the `C` flag in `readelf`, corresponding to
+`SHF_COMPRESSED`:
+
+```bash
+readelf -S path/to/file
+  ...
+  [21] .debug_info       PROGBITS         0000000000000000  00000370
+       000000000000e133  0000000000000000   C       0     0     1
+```
+
+## PE and PDB
+
+Executables and dynamic libraries on Microsoft Windows, and those created by the
+.NET platform on all operating systems, use the _Portable Executable_ (_PE_)
+container format. Associated debug information is stored in _Program Database_
+(_PDB_) files.
+
+- **Executables** use an `.exe` file extension. Only when compiled for 64-bit
+  architectures, they contain unwind information. Otherwise, they do not contain
+  any usable information and will be omitted for the upload to Sentry.
+
+- **Dynamic Libraries** use the `.dll` file extension, and otherwise behave
+  exactly the same as executables.
+
+- **Debug Companions** are stored in `.pdb` files. They usually contain debug
+  information and in most cases symbol tables. For 32-bit programs, they also
+  contain unwind information. In rare cases, they might have different file
+  names than their corresponding executable.
+
+- The .NET platform uses a variation of this format, called [Portable PDBs](https://github.com/dotnet/core/blob/main/Documentation/diagnostics/portable_pdb.md).
+  Portable PDBs are supported as of Sentry 22.11.0 (or Sentry CLI 2.8.0, or Symbolic 10.0.0).
+
+## Breakpad Symbols
+
+The Google Breakpad library has established a platform-independent ASCII format
+to store debug information. Such files are usually generated for applications
+using Breakpad, Crashpad, or the Electron Framework.
+
+The Breakpad repository includes `dump_syms` tools for each platform that can
+convert from native debug files to Breakpad symbols. These converters bundle all
+available information into one file, such that only one file needs to be
+uploaded.
+
+In contrast to native debug files, Breakpad symbols discard a lot of information
+that is not required to process minidumps. Most notably, inline functions are
+not declared, such that Sentry is not able to display inline frames in stack
+traces.

src/platform-includes/debug-file-formats-proguard-mappings/native.mdx

@@ -0,0 +1,5 @@
+## ProGuard Mappings
+
+ProGuard mapping files allow Sentry to resolve obfuscated Java classpaths and
+method names into their original form. In that sense, they act as debug
+information files for Java and Android applications.

src/platform-includes/debug-files-identifiers-gnu-build-identifiers/native.mdx

@@ -0,0 +1,15 @@
+## GNU Build Identifiers
+
+For ELF files on Linux, Sentry uses the GNU build identifier to compute the
+debug identifier. All recent compilers and linkers support the emission of build
+IDs, but sometimes they might require additional configuration. `gcc` does this
+by default, for `clang` use one of the following flags:
+
+- `--build-id=uuid` for a fast but non-reproducible random identifier.
+- `--build-id=sha1` for a slower but reproducible identifier generated by
+  hashing the first page of the code section.
+
+_The identifier needs to be present and identical in the binary as well
+as stripped debug information files._ If the ID is missing for some reason,
+upload the files before stripping so that `sentry-cli` can compute a stable
+identifier from the unstripped file.

src/platform-includes/debug-files-identifiers-pdb-age-mismatches/native.mdx

@@ -0,0 +1,22 @@
+## PDB Age Mismatches
+
+Microsoft PDBs compose their identifiers from two parts: A unique signature and
+an age field. The signature is generated when the PDB is written initially and
+usually changes with every build. The age is a counter that is incremented every
+time the PDB is modified.
+
+PE files, such as executables and dynamic libraries, specify the full identifier
+of the corresponding PDB in their header. This includes the age. If the PDB is
+modified after the PE has been generated, however, its age might diverge. This
+can lead to different identifiers:
+
+```
+PE:  3003763b-afcb-4a97-aae3-28de8f188d7c-2
+PDB: 3003763b-afcb-4a97-aae3-28de8f188d7c-4
+```
+
+`sentry-cli` can detect these differences during the upload process and
+associates the same identifier to both files. However, this requires that both
+files are uploaded in the same invocation of the upload command. Otherwise, the
+identifiers diverge and Sentry might not be able to resolve the correct file
+for symbolication.

src/platform-includes/debug-files-identifiers-proguard/native.mdx

@@ -0,0 +1,19 @@
+## ProGuard UUIDs
+
+Unlike other debug information files, ProGuard files do not have an intrinsic
+unique identifier. Sentry CLI assigns them a SHA1 UUID based on the checksum of
+the file. You can use `sentry-cli debug-files check` on a ProGuard file to see the
+generated UUID.
+
+If you need to generate the UUID yourself, you can do so with the following
+algorithm (Python code for reference):
+
+```python
+import uuid
+
+NAMESPACE = uuid.uuid5(uuid.NAMESPACE_DNS, "guardsquare.com")
+
+def get_proguard_uuid(filename):
+with open(filename, 'rb') as f:
+return uuid.uuid5(NAMESPACE, f.read())
+```

src/platform-includes/debug-information-files/_default.mdx

@@ -0,0 +1,13 @@
+Each major platform uses different debug information files. We currently support
+the following formats:
+
+- [_dSYM files_](./file-formats/#mach-o-and-dsym) for iOS, iPadOS,
+  tvOS, watchOS, macOS, and visionOS
+- [_ELF symbols_](./file-formats/#executable-and-linkable-format-elf) for Linux and
+  Android (NDK)
+- [_PDB files_](./file-formats/#pe-and-pdb) for Windows and .NET
+- [_Breakpad symbols_](./file-formats/#breakpad-symbols) for all
+  platforms
+- [_WASM files_](./file-formats/#wasm) for WebAssembly
+- [_ProGuard mappings_](./file-formats/#proguard-mappings) for
+  Java and Android

src/platform-includes/debug-information/_default.mdx

@@ -0,0 +1,5 @@
+In addition to Debug Information Files, Sentry needs _Call Frame Information_
+(CFI) to extract accurate stack traces from minidumps of optimized release
+builds. CFI is usually part of the executables and not copied to debug symbols.
+Unless you are uploading Breakpad symbols, be sure to also include the binaries
+when uploading files to Sentry.

src/platform-includes/debug-information/native.wasm.mdx

@@ -0,0 +1,12 @@
+For WASM, you need to provide both the debug information and the original code
+in the same debug information file. To do this, we provide a custom
+tool called [wasm-split](https://github.com/getsentry/symbolicator/tree/master/crates/wasm-split)
+that can do the splitting for you:
+
+```shell
+wasm-split /path/to/file.wasm -d /path/to/file.debug.wasm --strip
+```
+
+This command modifies the `file.wasm` in place to add the `build_id`, then removes all
+debug information. The debug information is put in a `file.debug.wasm` which
+then needs to be uploaded to Sentry.

src/platform-includes/sensitive-data/pii/native.mdx

@@ -0,0 +1 @@
+If you _do not_ wish to use the default PII behavior, you can also choose to identify users in a more controlled manner, using our [user identity context](../../enriching-events/identify-user/).

src/platform-includes/sensitive-data/scrubbing-data/native.mdx

@@ -0,0 +1,43 @@
+## Scrubbing Data
+
+### <PlatformIdentifier name="before-send" /> & <PlatformIdentifier name="before-send-transaction" />
+
+SDKs provide a <PlatformIdentifier name="before-send" /> hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. Some SDKs also provide a <PlatformIdentifier name="before-send-transaction" /> hook which does the same thing for transactions. We recommend using <PlatformIdentifier name="before-send" /> and <PlatformIdentifier name="before-send-transaction" /> in the SDKs to **scrub any data before it is sent**, to ensure that sensitive data never leaves the local environment.
+
+<PlatformContent includePath="configuration/before-send/" />
+
+Sensitive data may appear in the following areas:
+
+- Stack-locals → Some SDKs (Python, PHP and Node) will pick up variable values within the stack trace. These can be scrubbed, or this behavior can be disabled altogether if necessary.
+- Breadcrumbs → Some SDKs (JavaScript and the Java logging integrations, for example) will pick up previously executed log statements. **Do not log PII** if using this feature and including log statements as breadcrumbs in the event. Some backend SDKs will also record database queries, which may need to be scrubbed.
+- User context → Automated behavior is controlled via <PlatformIdentifier name="send-default-pii" />.
+- HTTP context → Query strings may be picked up in some frameworks as part of the HTTP request context.
+- Transaction Names → In certain situations, transaction names might contain sensitive data. For example, a browser's pageload transaction might have a raw URL like `/users/1234/details` as its name (where `1234` is a user id, which may be considered PII). In most cases, our SDKs can parameterize URLs and routes successfully, that is, turn `/users/1234/details` into `/users/:userid/details`. However, depending on the framework, your routing configuration, race conditions, and a few other factors, the SDKs might not be able to completely parameterize all of your URLs.
+
+For more details and data filtering instructions, see <PlatformLink to="/configuration/filtering/">Filtering Events</PlatformLink>.
+
+### Examples
+
+**Contextual information**
+
+Instead of sending confidential information in plaintext, consider hashing it:
+
+<PlatformContent includePath="sensitive-data/set-tag/" />
+
+This will allow you to correlate it within internal systems if needed, but keep it confidential from Sentry.
+
+**User details**
+
+Your organization may determine that emails are not considered confidential, but if they are, consider instead sending your internal identifier:
+
+<PlatformContent includePath="sensitive-data/set-user/" />
+
+Doing this will ensure you still benefit from user-impact related features.
+
+**Logging integrations**
+
+As a best practice you should always avoid logging confidential information. If you have legacy systems you need to work around, consider the following:
+
+- Anonymize the confidential information within the log statements (for example, swap out email addresses -> for internal identifiers)
+- Use <PlatformIdentifier name="before-breadcrumb" /> to filter it out from breadcrumbs before it is attached
+- Disable logging breadcrumb integration (for example, as described [here](/platforms/javascript/configuration/integrations/breadcrumbs/))