Webサービスは掲示板の域を抜け出せていない
インターネットの世界は進歩しているように見えて、ここ20年くらい大きな進歩はない。 数多くのインターネットサービスが生まれ、育ってきたが、どれも「すごい掲示板」にすぎない。 例えばメルカリ。 売りたいものをメルカリという「掲示板」に書く。 買いたい人は「掲示板」を見る。そして買いたいと「掲示板」に書く。 すると、買った人と売った人だけが見れる掲示板が新たに作られ、取引が終わる。 例えばクックパッド。 レシピを載せたい人が、レシピをクックパッドという「掲示板」に書く。 料理を作りたい人はクックパッドという「掲示板」を見る。 これだけ。 例えばYouTube。 動画を載せたい人が、動画をYouTubeという「掲示板」にアップする。 動画を見たい人は、すごい掲示板であるYouTubeで動画を再生する。 例えばInstagram。 自分の撮った写真を、Instagramという「掲示板」にアップする
徳丸さん、こんにちは。 読売のような大手メディアのサイトでもサポート詐欺の偽警告が表示されるようになってしまいましたし、今の時代は広告ブロッカーが必須と考えたほうが安全なのでしょうか？ | mond
徳丸さん、こんにちは。 読売のような大手メディアのサイトでもサポート詐欺の偽警告が表示されるようになってしまいましたし、今の時代は広告ブロッカーが必須と考えたほうが安全なのでしょうか？ 徳丸が書いていないことを質問いただくことが時々ありますが、私が書いてないのは書きたくない理由があるから（単にめんどうくさいも含む）です。ですが、せっかく質問いただいたので、思うところを書いてみようと思います。 まず、私自身は広告ブロッカーを使っていないです。その理由は、広告ブロッカーには危険なものがある（原理的にあり得るし、過去にあった）からです。過去には、広告ブロッカーが元の開発者から売却され、マルウェア化した例が複数あります。具体例は示しませんが、検索するとすぐに見つけられると思います。 広告ブロッカーがマルウェア化すると、これらはブラウザアドオンの形で動くため、非常に強い権限があり、すべてのサイトの情
ブラウザ開発者ツールのネットワークタブに表示されない情報送信手法 - Qiita
はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻き起こっていました。「盗み取られていない」側の主張は、ブラウザの開発者ツールのネットワークタブにリクエストを送信した形跡がないというものでした。ここで ブラウザの開発者ツールのネットワークタブに表示がなければ外部へデータを送信していないのか？ といった疑問が
ガチめのインターネット老人会クイズ
Q2.これらのマイクロバナーと呼ばれるバナーの標準的なサイズは？ 出典: cyber.dabamos.de × 87x30 ○ 88x31 × 89x32
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
わかりやすい文章の10大原則（第2回） | Web文章入門（全7回） | Web担当者Forum
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - w3c/jlreq-d: Requirements for Japanese Digital Text Layout
FediDB, Fediverse Network Statistics
ACA 80x15 Brilliant Button Maker: Make your antipixel button with one click!